30 Claude Prompts for Sysadmins

You are a senior Linux security administrator. <context> I am hardening a freshly provisioned Linux server before it goes into production and want a thorough checklist so nothing gets missed. </context> <inputs> - Distribution: [LINUX DISTRIBUTION AND VERSION] - Server role: [SERVER ROLE] - Compliance framework to align with: [CIS, NIST, OR NONE] - Remote access method: [SSH, VPN, OR BASTION HOST] </inputs> <task> Produce a hardening checklist covering account policy, SSH configuration, firewall rules, package minimization, logging, and patch management appropriate to the server role. </task> <constraints> Group items by category, and mark each item as required or recommended. Reference the compliance framework where relevant but keep language plain, not copied legal text. Keep the total list realistic for a single sitting, not exhaustive to the point of being ignored. </constraints> <format> Return the checklist as a markdown table with columns for category, item, and required or recommended. </format>

You are a senior Windows systems administrator focused on security. <context> I am preparing a Windows Server build standard for new deployments and need a hardening checklist that our team will actually follow. </context> <inputs> - Windows Server version: [WINDOWS SERVER VERSION] - Server role: [SERVER ROLE] - Domain joined: [YES OR NO] - Antivirus or EDR product in use: [PRODUCT NAME] </inputs> <task> Produce a hardening checklist covering local account policy, group policy settings, service minimization, Windows Firewall rules, and audit logging appropriate for the server role. </task> <constraints> Call out any setting that could break a common application if applied blindly. Avoid vague advice like enable security, name the actual setting or policy path. Keep the list to items a mid level administrator can execute without escalation. </constraints> <format> Return the checklist as a numbered list grouped under clear category headings. </format>

You are a senior systems administrator focused on remote access security. <context> I inherited a set of Linux servers with SSH configurations that have never been reviewed and I need to identify weak settings before an audit. </context> <inputs> - Current sshd_config settings I can share: [PASTE RELEVANT SSHD CONFIG LINES] - Number of servers affected: [NUMBER OF SERVERS] - Authentication method currently used: [PASSWORD OR KEY BASED] - Any bastion or jump host in place: [YES OR NO] </inputs> <task> Review the SSH configuration for weaknesses such as password authentication, root login, weak ciphers, or missing rate limiting, and produce a prioritized list of changes. </task> <constraints> Order recommendations by risk, highest first. Note which changes require a coordinated rollout because they could lock out active sessions. Do not recommend anything that needs a paid product. </constraints> <format> Return a table with columns for finding, risk level, and recommended fix. </format>

You are a senior network and systems administrator. <context> Our firewall rule set has grown over several years with rules added by different people and I need to clean it up without breaking anything in production. </context> <inputs> - Firewall platform: [FIREWALL PLATFORM] - Approximate number of rules: [NUMBER OF RULES] - Known critical services that must stay reachable: [LIST OF CRITICAL SERVICES] - Last audit date: [LAST AUDIT DATE OR NEVER] </inputs> <task> Produce a checklist and procedure for auditing the firewall rule set, identifying unused or overly broad rules, and documenting the intended purpose of each remaining rule. </task> <constraints> Include a safe rollback step before removing any rule. Flag any rule that allows access from any source address as high priority to review. Keep the process usable by someone who did not write the original rules. </constraints> <format> Return the checklist as numbered steps, with a separate short table template for documenting each rule reviewed. </format>

You are a senior database and systems administrator. <context> I am hardening a production database server and want to cover both the operating system and the database engine configuration. </context> <inputs> - Database engine: [DATABASE ENGINE] - Operating system: [OPERATING SYSTEM AND VERSION] - Network exposure: [INTERNAL ONLY OR INTERNET FACING] - Backup solution already in place: [BACKUP TOOL OR NONE] </inputs> <task> Produce a hardening checklist covering network exposure, authentication method, encryption at rest and in transit, least privilege for database accounts, and audit logging for the given database engine. </task> <constraints> Separate items that require a restart or downtime window from items that can be applied live. Avoid generic advice, name actual configuration parameters for the given engine. Flag anything that conflicts with the existing backup solution. </constraints> <format> Return the checklist as a markdown table with columns for area, setting, and whether it requires downtime. </format>

You are a senior systems administrator designing backup infrastructure. <context> I support a small IT team with limited budget and need a backup strategy that actually gets tested, not just configured and forgotten. </context> <inputs> - Systems to back up: [LIST OF SYSTEMS OR SERVERS] - Current backup tool if any: [CURRENT TOOL OR NONE] - Recovery time objective: [TARGET RECOVERY TIME] - Recovery point objective: [ACCEPTABLE DATA LOSS WINDOW] - Budget constraint: [BUDGET RANGE] </inputs> <task> Design a backup strategy including frequency, retention, storage location, and a testing cadence that fits the stated recovery objectives and budget. </task> <constraints> Follow the 3-2-1 backup principle explicitly and explain how each part is satisfied. Keep the plan realistic for a team without a dedicated backup administrator. Note the single biggest risk in the current setup if one is implied by the inputs. </constraints> <format> Return the strategy as a short document with headings for frequency, retention, storage, and testing. </format>

You are a senior systems administrator responsible for business continuity. <context> I need a disaster recovery runbook for a critical system so that whoever is on call can execute recovery without needing me on the call. </context> <inputs> - System name: [SYSTEM NAME] - Dependencies: [LIST OF DEPENDENT SYSTEMS OR SERVICES] - Backup location: [BACKUP STORAGE LOCATION] - Recovery time objective: [TARGET RECOVERY TIME] - Primary and secondary contacts: [ON CALL CONTACT NAMES] </inputs> <task> Draft a disaster recovery runbook with clear trigger conditions for when to invoke it, step by step recovery steps, verification steps to confirm the system is healthy, and rollback guidance if recovery fails. </task> <constraints> Write steps specific enough that someone unfamiliar with the system could follow them under pressure. Do not assume access to tools or credentials that are not listed in the inputs. Keep each step to one action. </constraints> <format> Return the runbook as numbered sections: trigger conditions, recovery steps, verification, and rollback. </format>

You are a senior systems administrator focused on backup verification. <context> We take backups regularly but have never formally tested a full restore and I want to fix that before we find out the backups do not work during a real incident. </context> <inputs> - System or database to test: [SYSTEM OR DATABASE NAME] - Backup tool: [BACKUP TOOL NAME] - Test environment available: [YES, NO, OR DESCRIBE] - Acceptable downtime for the test: [TIME WINDOW] </inputs> <task> Create a restore test plan that verifies both that the backup file is valid and that a full restore produces a working system, including data integrity checks. </task> <constraints> Specify exactly what counts as a passed test versus a failed one. Include a step to test restoring to an isolated environment when possible rather than production. Note how often this test should repeat. </constraints> <format> Return the plan as a checklist with a pass or fail column for each step. </format>

You are a senior systems administrator writing internal policy. <context> I need a written offsite backup policy so the organization has a documented standard instead of relying on tribal knowledge about where backups live. </context> <inputs> - Organization name: [ORGANIZATION NAME] - Current offsite location or provider: [OFFSITE LOCATION OR CLOUD PROVIDER] - Data classification levels in use: [DATA CLASSIFICATION LEVELS] - Retention requirement: [RETENTION PERIOD] </inputs> <task> Write an offsite backup policy document covering what data must be backed up offsite, how often, encryption requirements in transit and at rest, and who is responsible for verifying it happens. </task> <constraints> Write in plain policy language a non-technical manager could approve, but keep the technical requirements precise enough for an engineer to implement. Do not exceed two pages worth of content. </constraints> <format> Return the document with headings for scope, requirements, responsibilities, and review schedule. </format>

You are a senior systems administrator responsible for incident recovery. <context> I want a ransomware specific recovery playbook prepared in advance so the team is not improvising during an actual attack. </context> <inputs> - Critical systems in priority order: [LIST OF CRITICAL SYSTEMS IN ORDER] - Backup isolation method: [OFFLINE, IMMUTABLE, OR AIR GAPPED] - Incident response contact: [INCIDENT RESPONSE CONTACT] - Cyber insurance provider if any: [INSURANCE PROVIDER OR NONE] </inputs> <task> Draft a ransomware recovery playbook including immediate containment steps, how to verify backup integrity before restoring, restoration order for the listed critical systems, and communication steps for stakeholders. </task> <constraints> Assume the network may still be compromised during the first steps, so include isolation actions before any restoration. Do not recommend paying a ransom or negotiating, that decision sits outside this playbook. Keep legal and insurance notification as an explicit early step. </constraints> <format> Return the playbook as numbered phases: containment, verification, restoration, and communication. </format>

You are a senior systems administrator building operational documentation. <context> I do not have a reliable inventory of our servers and need a template to start capturing what exists before anything else can be planned properly. </context> <inputs> - Environment type: [ON PREMISE, CLOUD, OR HYBRID] - Number of servers roughly: [APPROXIMATE SERVER COUNT] - Fields already tracked somewhere: [EXISTING FIELDS IF ANY] - Tool this will live in: [SPREADSHEET, CMDB, OR OTHER TOOL] </inputs> <task> Design a server asset inventory template with the fields needed to track hostname, role, operating system, owner, location, and support status for each server. </task> <constraints> Keep the field list practical, no more than 15 columns, so people will actually keep it updated. Include a field for last verified date so staleness is visible. Avoid fields that require specialist tools to populate. </constraints> <format> Return the template as a table with column names and a one line description of what belongs in each column. </format>

You are a senior IT asset manager and systems administrator. <context> I suspect we are over licensed on some software and under licensed on others and need a structured way to find out before a vendor audit catches it first. </context> <inputs> - Software vendors in scope: [LIST OF VENDORS OR PRODUCTS] - Procurement records available: [YES, PARTIAL, OR NO] - Number of users or devices roughly: [APPROXIMATE COUNT] - Renewal dates known: [KNOWN RENEWAL DATES OR NONE] </inputs> <task> Create a license audit process that compares purchased licenses against actual deployed installs or active users, and flags both over licensing and under licensing risk. </task> <constraints> Note where estimates are being used because exact data is missing. Prioritize the vendors with the nearest renewal date first. Keep the process repeatable on a recurring schedule, not a one time exercise. </constraints> <format> Return the process as numbered steps plus a summary table template with columns for vendor, licensed count, actual usage, and status. </format>

You are a senior network and systems administrator. <context> Our network has never been formally diagrammed and I need a structured way to document it so new team members can understand the layout quickly. </context> <inputs> - Sites or locations: [LIST OF SITES OR LOCATIONS] - Key network devices: [LIST OF ROUTERS, SWITCHES, FIREWALLS] - VLANs in use: [LIST OF VLANS IF KNOWN] - Diagramming tool available: [TOOL NAME OR NONE] </inputs> <task> Produce a structured written description of the network topology, organized by site, that could be handed to someone to convert into a visual diagram, covering device roles, VLAN segmentation, and how sites connect to each other. </task> <constraints> Use plain descriptive language rather than diagram syntax since the output is text based. Call out anywhere information is missing or assumed rather than guessing silently. Keep each site section self contained. </constraints> <format> Return the description organized by site with a subsection for devices, VLANs, and interconnections. </format>

You are a senior systems administrator managing infrastructure lifecycle. <context> I need to track hardware approaching end of life or end of support so we can budget for replacements before something fails unexpectedly. </context> <inputs> - Hardware categories in scope: [LIST OF HARDWARE CATEGORIES] - Purchase or install dates known: [YES, PARTIAL, OR NO] - Typical lifecycle expectation: [YEARS EXPECTED IN SERVICE] - Budget planning cycle: [ANNUAL OR OTHER CYCLE] </inputs> <task> Design a tracking sheet for hardware end of life that flags items approaching or past their expected service life and supports budget planning conversations. </task> <constraints> Include a clear risk flag, such as a color or status label, for anything already past end of support. Keep the sheet simple enough to update during a routine hardware walkthrough. Tie each item to the budget planning cycle stated. </constraints> <format> Return the tracking sheet as a table with columns for item, install date, expected end of life, status, and replacement priority. </format>

You are a senior systems administrator handling vendor relationships. <context> Contracts and support agreements renew throughout the year and I keep finding out about renewals too late to negotiate or budget properly. </context> <inputs> - Vendors under contract: [LIST OF VENDORS] - Contract types: [SUPPORT, LICENSING, SERVICE, OR MIXED] - Notice period typically required: [NOTICE PERIOD IN DAYS] - Person responsible for renewals: [RESPONSIBLE PERSON OR ROLE] </inputs> <task> Create a vendor contract tracker that surfaces upcoming renewals early enough to act, including the notice period required to cancel or renegotiate each contract. </task> <constraints> Sort by nearest renewal date and highlight anything inside its notice window. Include a field for renewal decision, such as renew, renegotiate, or cancel. Keep it usable without a dedicated procurement system. </constraints> <format> Return the tracker as a table with columns for vendor, contract type, renewal date, notice deadline, and decision. </format>

You are a senior systems administrator responsible for on call operations. <context> I want a general incident response runbook that applies to any major outage so the on call engineer has a consistent process to follow instead of improvising each time. </context> <inputs> - Systems typically affected: [LIST OF CORE SYSTEMS] - Monitoring or alerting tool: [MONITORING TOOL NAME] - Escalation contacts: [ESCALATION CONTACT LIST] - Status page or customer communication tool: [STATUS PAGE TOOL OR NONE] </inputs> <task> Draft an incident response runbook covering initial triage, severity classification, escalation criteria, and customer communication steps for a major outage. </task> <constraints> Define severity levels with concrete criteria, not vague terms like bad or critical without explanation. Keep the first ten minutes of the runbook focused only on triage and stabilization, not root cause analysis. Avoid assuming tools that were not listed in the inputs. </constraints> <format> Return the runbook as numbered phases: triage, classification, escalation, and communication. </format>

You are a senior systems administrator responsible for monitoring systems. <context> Our team is getting so many alerts that people have started ignoring them, and I need to identify which alerts are actually worth keeping. </context> <inputs> - Monitoring tool: [MONITORING TOOL NAME] - Approximate alerts per week: [ALERT VOLUME PER WEEK] - Sample of common alert types: [LIST COMMON ALERT TYPES] - Any alerts known to be noisy: [KNOWN NOISY ALERTS IF ANY] </inputs> <task> Review the listed alert types and propose which should be kept as is, which should be tuned with better thresholds, and which should be removed or downgraded to a log only entry. </task> <constraints> Justify each recommendation with a reason tied to whether the alert requires human action. Do not recommend removing anything tied to data loss or security without flagging it for a second review. Group recommendations so the team can act on the highest impact changes first. </constraints> <format> Return the review as a table with columns for alert type, recommendation, and reason. </format>

You are a senior systems administrator writing an incident postmortem. <context> We just resolved an incident and I need to turn my rough notes into a clear postmortem that the team can learn from without assigning blame to individuals. </context> <inputs> - Incident summary notes: [PASTE ROUGH INCIDENT NOTES] - Start and end time of impact: [START TIME AND END TIME] - Systems affected: [LIST OF AFFECTED SYSTEMS] - Immediate fix applied: [DESCRIBE THE FIX APPLIED] </inputs> <task> Write a blameless postmortem report from the notes provided, including a timeline, root cause analysis, impact summary, and a list of concrete follow up action items with owners left as placeholders. </task> <constraints> Keep the tone factual and blameless, describe what the system or process did, not who made a mistake. Separate immediate fix from long term preventive action items clearly. Keep the timeline in chronological order with timestamps. </constraints> <format> Return the report with headings for summary, timeline, root cause, impact, and action items. </format>

You are a senior systems administrator designing on call processes. <context> Our on call rotation exists but the escalation path is unclear and incidents sometimes sit too long before the right person is paged. </context> <inputs> - Team members in rotation: [LIST OF TEAM MEMBERS OR ROLES] - Current paging tool: [PAGING TOOL NAME OR NONE] - Business hours versus after hours difference: [YES OR NO, DESCRIBE IF ANY] - Maximum acceptable time to acknowledge: [ACKNOWLEDGEMENT TIME TARGET] </inputs> <task> Design an on call escalation policy that defines who gets paged first, how long to wait before escalating further, and what happens if nobody acknowledges within the target time. </task> <constraints> Keep the escalation chain no more than three levels deep before it reaches a manager. Account for the business hours versus after hours difference if one was stated. Make the acknowledgement target enforceable, not just aspirational language. </constraints> <format> Return the policy as a short document with a escalation chain table and a written explanation of the timing rules. </format>

You are a senior systems administrator focused on security monitoring. <context> I want a baseline set of log monitoring rules that catch common suspicious activity without requiring a full SIEM deployment. </context> <inputs> - Log sources available: [LIST OF LOG SOURCES] - Logging or SIEM tool: [TOOL NAME OR PLAIN LOG FILES] - Environment type: [SMALL BUSINESS, ENTERPRISE, OR CLOUD] - Known past incidents to guard against: [PAST INCIDENT TYPES IF ANY] </inputs> <task> Propose a set of log monitoring rules covering repeated failed logins, privilege escalation attempts, unusual outbound connections, and after hours access, tailored to the available log sources. </task> <constraints> Keep each rule specific enough to implement, naming the log field or event type it watches. Note which rules are high confidence versus likely to need threshold tuning after deployment. Do not assume a commercial SIEM if plain log files were stated. </constraints> <format> Return the rule set as a table with columns for rule name, log source, trigger condition, and response action. </format>

You are a senior systems administrator managing identity and access. <context> Each new hire needs a consistent set of access granted on day one and I want a checklist that removes guesswork from the process. </context> <inputs> - Department or role: [DEPARTMENT OR JOB ROLE] - Systems typically needed: [LIST OF SYSTEMS OR APPLICATIONS] - Approval required from: [APPROVER ROLE OR NAME] - Start date: [START DATE] </inputs> <task> Create a provisioning checklist that lists every system access item needed for the given role, who must approve it, and confirms completion before the employee's first day. </task> <constraints> Separate items that can be pre staged before day one from items that must wait until the employee is verified present. Do not include any access beyond what the stated role needs, apply least privilege. Include a sign off line for the approver. </constraints> <format> Return the checklist as a table with columns for access item, approver, and status. </format>

You are a senior systems administrator managing identity and access. <context> Employees leaving sometimes retain access longer than they should because offboarding is handled inconsistently across teams. </context> <inputs> - Departure type: [VOLUNTARY, INVOLUNTARY, OR CONTRACTOR END] - Systems the employee had access to: [LIST OF SYSTEMS] - Last working day: [LAST WORKING DAY] - Manager or HR contact: [MANAGER OR HR CONTACT] </inputs> <task> Create an offboarding checklist that revokes access across all listed systems in the correct order, with special handling noted for involuntary departures where access should be cut immediately rather than at end of day. </task> <constraints> Flag any shared accounts or credentials the departing employee may have known, since those need a password reset, not just individual account disablement. Keep a clear distinction between immediate revocation items and standard end of day items. Include a final verification step confirming no access remains. </constraints> <format> Return the checklist as a table with columns for access item, revocation timing, and confirmed status. </format>

You are a senior systems administrator responsible for privileged access management. <context> I need to review who currently holds administrator or root level access across our systems, since these accounts carry the highest risk if compromised or misused. </context> <inputs> - Systems with privileged accounts: [LIST OF SYSTEMS] - Current privileged account holders: [LIST OF USERS OR PLACEHOLDER] - Last review date: [LAST REVIEW DATE OR NEVER] - Privileged access management tool if any: [PAM TOOL OR NONE] </inputs> <task> Design a privileged access review process that confirms each privileged account holder still needs that level of access, identifies any accounts that should be downgraded, and sets a recurring review schedule. </task> <constraints> Require a documented business justification for each privileged account that remains after review. Flag any shared or generic privileged account as high risk regardless of who uses it. Keep the review schedule recurring, not a one time cleanup. </constraints> <format> Return the process as numbered steps plus a review table template with columns for account, holder, justification, and decision. </format>

You are a senior systems administrator writing security policy. <context> I need an updated password policy that meets current best practice and satisfies an upcoming compliance review, replacing an outdated policy that still mandates frequent forced resets. </context> <inputs> - Compliance framework driving this: [FRAMEWORK NAME OR NONE] - Current password requirements: [PASTE CURRENT POLICY IF ANY] - Multi factor authentication status: [ENFORCED, PARTIAL, OR NOT DEPLOYED] - Systems this policy must cover: [LIST OF SYSTEMS] </inputs> <task> Draft a password policy aligned with current best practice, covering minimum length, multi factor authentication requirements, and when a reset is actually required versus not. </task> <constraints> Follow current guidance favoring length and multi factor authentication over frequent mandatory rotation, and explain briefly why the policy departs from any outdated current requirement listed. Write in policy language suitable for an employee handbook. Keep it to one page. </constraints> <format> Return the policy as a short document with headings for requirements, multi factor authentication, and reset conditions. </format>

You are a senior systems administrator responsible for access governance. <context> We need a recurring process where managers confirm their team's system access is still appropriate, instead of access accumulating indefinitely as people change roles. </context> <inputs> - Systems in scope for recertification: [LIST OF SYSTEMS] - Number of managers involved: [NUMBER OF MANAGERS] - Recertification tool available: [SPREADSHEET, IDENTITY GOVERNANCE TOOL, OR NONE] - Deadline for each cycle: [DAYS ALLOWED PER CYCLE] </inputs> <task> Design a quarterly access recertification plan where managers review their direct reports' access per system, confirm or flag it for removal, and a process for following up on non responses before the deadline. </task> <constraints> Keep the manager's task simple enough to complete without special software if none is available. Define exactly what happens to access that is flagged for removal, and by when. Include an escalation step for managers who miss the deadline. </constraints> <format> Return the plan as numbered steps plus a recertification table template with columns for user, system, manager decision, and due date. </format>