AI Prompts for System Administrators: Linux, Windows, Cloud, Automation

Published: July 2026 | 9 min read

System administrators keep the digital lights on. You manage servers, networks, storage, user accounts, and the inevitable 3 AM pages when something breaks. AI can help you write scripts, diagnose issues, plan migrations, and automate repetitive tasks — if your prompts understand the difference between a production server and a lab machine.

Scripting & Automation

1. Bash Script Generator

Role: Senior Linux sysadmin
Task: Write a bash script to [describe what the script should do].
Requirements:
- Input validation (check args, files exist, permissions)
- Error handling (set -euo pipefail, trap for cleanup)
- Logging (to syslog or file, with timestamps and log levels)
- Dry-run mode (show what would happen without making changes)
- Idempotent (safe to run multiple times)
- Configuration section at top (variables, paths, thresholds)
- Comments explaining non-obvious logic
Output: Complete bash script, ready to deploy.
Include: Usage examples in comments.
Constraint: No rm -rf without explicit confirmation. Use set -euo pipefail always.

2. PowerShell Script Generator

Role: Senior Windows sysadmin
Task: Write a PowerShell script to [describe what the script should do].
PowerShell version: [5.1 / 7.x]
Requirements:
- Parameters (with validation, types, default values, help text)
- Error handling (try/catch, $ErrorActionPreference, meaningful messages)
- Logging (Write-EventLog or file-based with timestamps)
- WhatIf/Confirm support (for destructive operations)
- Output formatting (object output for pipeline use, not just text)
- Module dependencies (check and import required modules)
- Comment-based help (synopsis, description, examples, parameters)
- Remote execution support (if applicable — Invoke-Command, PSRemoting)
Output: Complete PowerShell script ready for production.
Constraint: No plain text credentials. Use PSCredential or credential store.

3. Ansible Playbook Generator

Role: Ansible automation engineer
Task: Write an Ansible playbook to [describe what to automate].
Target hosts: [OS, inventory group, count]
Requirements:
- Inventory structure (groups, variables)
- Tasks with proper module usage (not shell when a module exists)
- Variables (defaults in defaults/main.yml, overrides in group_vars)
- Handlers (for service restart on config change)
- Templates (Jinja2 for config files)
- Tags (for selective execution)
- Error handling (failed_when, changed_when, ignore_errors where appropriate)
- Idempotency (can run multiple times without side effects)
- Pre-tasks (check connectivity, gather facts)
- Post-tasks (notify, cleanup)
Structure:
- roles/ with tasks, handlers, templates, vars, defaults
- site.yml (main playbook)
- inventory.yml (or ansible.cfg pointing to inventory source)
Output: Complete playbook structure ready for use.
Include: Requirements (collections, roles from Galaxy).

Troubleshooting & Diagnostics

4. Linux Performance Troubleshooting Guide

Role: Senior Linux sysadmin troubleshooting a performance issue
Task: Create a systematic troubleshooting guide for [symptom].
Symptom: [high CPU, high memory, slow disk I/O, network latency, slow application]
Troubleshooting sequence:
1. Quick assessment (top, htop, dmesg, /proc/loadavg — what does the system look like?)
2. CPU analysis (top, mpstat, pidstat — which process? user or system time?)
3. Memory analysis (free, vmstat, /proc/meminfo — real or cache? swap usage?)
4. Disk I/O (iostat, iotop, df, du — which device? read or write? queue depth?)
5. Network (ifstat, ss, tcpdump — bandwidth? connections? retransmits?)
6. Process-specific (strace, perf, gdb — what is the offending process doing?)
7. Kernel/system (dmesg, /var/log/messages — any kernel warnings?)
8. Application logs (where are they? what do they say?)
For each step:
1. Command to run (exact, with flags)
2. What to look for in output
3. What abnormal looks like
4. What action to take if abnormal
Format: Step-by-step troubleshooting playbook for on-call sysadmins.

5. Windows Server Troubleshooting

Role: Senior Windows sysadmin
Task: Create a troubleshooting guide for [Windows symptom].
Symptom: [high CPU, memory leak, service crash, boot issue, network problem, slow performance]
Troubleshooting steps:
1. Quick assessment (Task Manager, Event Viewer, Performance Monitor)
2. Process analysis (Get-Process, Process Explorer — who is consuming?)
3. Memory analysis (RAMMap, Poolmon — paged/non-paged pool? leak?)
4. Disk (diskmgmt, diskperf, Get-PhysicalDisk — queue length? latency?)
5. Network (netstat, Get-NetAdapter, pathping — connectivity? latency?)
6. Service status (Get-Service, sc query — is it running? auto-start?)
7. Event logs (Get-EventLog / Get-WinEvent — Application, System, Security)
8. Boot/BSOD (minidump analysis, bcdedit, sfc /scannow)
For each step:
1. Command/tool
2. What to look for
3. Common causes for this symptom
4. Fix for each cause
Format: Windows troubleshooting playbook for sysadmins.

6. Network Connectivity Diagnostic Script

Role: Network sysadmin
Task: Write a network diagnostic script for [scenario].
Scenario: [Server cannot reach [destination], intermittent connectivity, DNS issues, VPN problems]
Diagnostic steps (script should run all and report):
1. Local interface check (ip addr / ipconfig — is interface up? has IP?)
2. DNS resolution (nslookup / dig — can we resolve the target hostname?)
3. Ping (localhost, gateway, DNS server, target — where does it fail?)
4. Traceroute (traceroute / tracert — where is the path broken?)
5. Port check (nc / Test-NetConnection — is the specific port open?)
6. Firewall check (iptables -L / netsh advfirewall — is something blocking?)
7. Route check (ip route / route print — is there a route to destination?)
8. ARP check (arp -a — can we resolve MAC for gateway?)
9. MTU check (ping with large packets, fragmentation?)
10. Interface errors (ip -s link / netsh interface — errors? drops?)
Output: Script that runs all checks and produces a formatted report.
Format: Bash or PowerShell (specify which), with clear pass/fail for each check.

Server Configuration & Hardening

7. Linux Server Hardening Checklist

Role: Linux security sysadmin
Task: Create a server hardening checklist for [Linux distribution, version].
Categories:
1. Initial setup:
   - Update all packages (apt/yum update)
   - Disable unused services (systemctl disable)
   - Remove unnecessary packages
   - Set hostname, timezone, NTP
2. User management:
   - Disable root SSH login
   - Enforce SSH key auth (disable password auth)
   - Create admin user with sudo access
   - Set password policy (complexity, expiry, history)
   - Remove unused accounts
3. Network:
   - Configure firewall (ufw/firewalld/iptables — default deny)
   - Disable unused ports
   - Set SSH to non-standard port (optional)
   - Configure fail2ban
4. File system:
   - Set permissions on key directories
   - Mount /tmp with noexec, nosuid
   - Enable disk encryption if applicable
   - Set umask
5. Kernel:
   - sysctl hardening (network, memory, core dumps)
   - Disable unused kernel modules
6. Logging & monitoring:
   - Enable auditd
   - Configure rsyslog forwarding
   - Set log rotation
7. Services:
   - HTTPS only for web servers
   - Database: bind to localhost, not 0.0.0.0
   - Application: run as non-root user
For each item: command to check, command to fix, risk if not done
Generate 40-50 items.
Format: Hardening checklist ready for execution.

8. Backup Script Design

Role: Sysadmin designing a backup solution
Task: Design a backup script for [what to backup].
What to backup: [Files, database, configs, application state]
Requirements:
1. Backup method (rsync, tar, mysqldump, pg_dump, snapshot, etc.)
2. Schedule (full, incremental, differential — with retention policy)
3. Destination (local disk, NAS, cloud storage, offsite)
4. Compression and encryption (what algorithm? key management?)
5. Verification (how to test that backups are restorable)
6. Rotation (how many copies, how long kept)
7. Logging (what to log, where, alerting on failure)
8. Pre-backup checks (disk space, target availability, data consistency)
9. Post-backup checks (verify size, checksum, log analysis)
10. Restore procedure (step by step — how to restore from this backup)
11. Notification (email/Slack on success, failure, warning)
Output: Backup script + documentation with restore procedure.
Constraint: Untested backups are worthless — include a test-restore procedure.

Cloud & Migration

9. Cloud Migration Assessment

Role: Cloud migration architect
Task: Assess migration options for [on-prem system to cloud].
System: [Description, current infra, dependencies, performance requirements]
Assessment:
1. Current state:
   - Server specs (CPU, RAM, storage, network)
   - OS and software stack
   - Dependencies (other systems, databases, external APIs)
   - Data volume and growth rate
   - Network requirements (bandwidth, latency, firewall rules)
   - Compliance requirements (data residency, encryption, audit)
2. Cloud fit assessment:
   - Lift and shift (IaaS — easiest, least optimized)
   - Replatform (PaaS — some changes, better fit)
   - Refactor (re-architect for cloud-native)
   - Replace (SaaS — does a cloud service do this already?)
3. For each option:
   - Effort (hours, days, weeks)
   - Cost (migration cost + ongoing cloud cost vs current cost)
   - Risk (what could go wrong)
   - Benefit (what do we gain?)
4. Recommendation (which option, why, what is the business case?)
5. Migration plan (if proceeding):
   - Phases (what moves first, what depends on what)
   - Testing plan (how to verify in cloud)
   - Cutover plan (how to switch with minimal downtime)
   - Rollback plan (if migration fails)
Format: Migration assessment document for IT leadership.

10. User Lifecycle Automation

Role: Identity and access management sysadmin
Task: Design a user lifecycle automation for [organization].
IAM system: [Active Directory / Okta / Google Workspace / JumpCloud / custom]
Lifecycle stages:
1. Onboarding:
   - Trigger (HR system, ticket, API)
   - Account creation (which systems? what groups? what licenses?)
   - Email setup (mailbox, alias, signature)
   - Device provisioning (laptop, phone — enrollment)
   - Access requests (default access based on role)
   - Welcome communication (credentials, setup guide, IT contacts)
2. Role change:
   - Trigger (HR system, manager request)
   - Access review (what should be removed? what should be added?)
   - Group membership update
   - License adjustment
   - Communication to user and manager
3. Offboarding:
   - Trigger (HR termination, resignation, contractor end)
   - Immediate actions (disable login, revoke tokens, remote wipe device)
   - Data handling (email forward, file ownership transfer, backup)
   - Access removal (all systems, all groups, all VPN)
   - License recovery (deallocate from user pool)
   - Audit trail (what was accessed, what was removed, when, by whom)
4. Access review:
   - Quarterly review (who has access to what? is it still needed?)
   - Automated certification (manager approval for continued access)
   - Removal of stale access (90 days unused)
Output: User lifecycle automation plan with workflow diagrams (text) and script structure.

11. Patch Management Strategy

Role: Systems patching specialist
Task: Create a patch management strategy for [environment].
Environment: [Number of servers, OS mix (Linux/Windows), criticality levels, compliance requirements]
Patch categories:
1. Security patches (critical, high — fast track)
2. Bug fixes (medium — normal track)
3. Feature updates (low — scheduled track)
For each category:
1. Patch identification (how do we know a patch is available?)
2. Testing (where do we test? how long? what do we verify?)
3. Deployment window (when? how fast after release?)
4. Rollback (if the patch breaks something, how do we revert?)
5. Verification (how do we confirm the patch is applied?)
6. Compliance reporting (who needs what report? how often?)
Deployment strategy:
1. Pilot group (1-2 servers, low criticality)
2. Test environment (full test, acceptance criteria)
3. Staging (production-like, final validation)
4. Production rollout (canary — 10%, then 50%, then 100%)
5. Post-patch verification (health checks, monitoring)
Tools: [WSUS / Spacewalk / Foreman / Ansible / Tanium / ManageEngine]
Output: Patch management policy with deployment runbook and compliance reporting.

12. Monitoring & Alerting Setup Guide

Role: Sysadmin setting up server monitoring
Task: Design a monitoring and alerting setup for [server fleet].
Fleet: [Number of servers, OS mix, applications, criticality]
Monitoring stack: [Zabbix / Nagios / Prometheus+Grafana / Datadog / CloudWatch]
Metrics to collect:
1. System health:
   - CPU usage (per core, load average)
   - Memory (used, cached, available, swap)
   - Disk (usage %, IOPS, latency, inodes)
   - Network (bandwidth, errors, drops, connections)
2. Service health:
   - Process running? (systemd status, supervisor)
   - Port listening? (TCP check)
   - HTTP health endpoint (status code, response time)
   - Database connectivity and query time
3. Logs:
   - Error rate (errors per minute)
   - Security events (failed logins, sudo usage, file changes)
   - Application-specific (custom log patterns)
4. Business metrics (if applicable):
   - Active users, transactions/sec, queue depth
Alert rules:
For each alert:
1. Metric and threshold (with sustained period — no flapping)
2. Severity (Critical / Warning / Info)
3. Notification channel (PagerDuty / Slack / email / SMS)
4. Escalation (if not acknowledged in X min, escalate to Y)
5. Runbook link (what to do when this alert fires)
Output: Monitoring configuration spec + alert rule definitions + dashboard layout.

Best Practices

For more infrastructure content, see our ChatGPT prompts for DevOps engineers and AI prompts for cybersecurity analysts.