ChatGPT Prompts for DevOps Engineers: CI/CD, Infrastructure, Monitoring

Published: July 2026 | 10 min read

DevOps engineers keep the systems running and the deployments flowing. You manage CI/CD pipelines, infrastructure as code, monitoring stacks, and incident response. This post focuses specifically on CI/CD, infrastructure automation, and observability — distinct from general software development prompts.

CI/CD Pipeline Design

1. CI/CD Pipeline Architecture

Role: DevOps architect designing a CI/CD pipeline
Task: Design a CI/CD pipeline for [application type — web app, microservice, mobile, library].
Tech stack: [Language, framework, build tool, container runtime]
Cloud/infra: [AWS/GCP/Azure/on-prem, Kubernetes, serverless]
Pipeline stages:
1. Source (trigger, branch strategy, PR checks)
2. Build (compile, lint, test, artifact creation)
3. Security scan (SAST, DAST, dependency check, container scan)
4. Package (container build, push to registry, tag strategy)
5. Deploy to dev (auto-deploy on merge, smoke test)
6. Deploy to staging (manual approval, integration tests, load test)
7. Deploy to production (blue-green, canary, or rolling? approval gate?)
8. Post-deploy (health check, rollback trigger, notification)
For each stage:
1. Tool (specific — not just CI/CD platform, which one and why)
2. Trigger (automatic, manual, scheduled)
3. Duration estimate
4. Pass criteria (specific, not "all tests pass")
5. Fail behavior (block, warn, retry, notify)
6. Artifacts produced
Output: Pipeline architecture document with YAML/template examples.
Include: Rollback strategy for each environment.

2. GitHub Actions Workflow Generator

Role: GitHub Actions workflow specialist
Task: Write a GitHub Actions workflow for [task description].
Trigger: [push to main / PR / schedule / manual / workflow_dispatch]
Jobs needed:
1. [Job name] — runs-on, steps, dependencies
2. [Job name] — runs-on, steps, dependencies
For each job:
1. Runner (ubuntu-latest, self-hosted, specific labels)
2. Steps (checkout, setup, cache, build, test, deploy)
3. Environment secrets needed (list names, not values)
4. Condition (which branches? which events?)
5. Timeout (minutes)
6. Matrix strategy (if testing multiple versions/platforms)
Requirements:
- Caching for dependencies (reduce build time)
- Conditional execution (skip deploy on PR, only deploy on main)
- Environment protection (staging/production with approval gates)
- Concurrency control (cancel old runs on same branch)
- Artifact upload (for debugging failed builds)
Output: Complete .github/workflows/*.yml file ready to commit.
Constraint: Use current GitHub Actions syntax, not deprecated versions.

3. Deployment Strategy Design

Role: Deployment strategy consultant
Task: Recommend and design a deployment strategy for [application/service].
Current state: [How do you deploy now? Manual, scripted, CI/CD?]
Constraints:
- Downtime tolerance: [zero, minutes, hours acceptable]
- Traffic pattern: [steady, peak hours, seasonal]
- Database migrations: [needed? backward compatible?]
- Rollback speed requirement: [how fast must we roll back?]
- Team size: [how many people involved in deployment?]
Compare strategies:
1. Rolling deployment (pros, cons, when it fits)
2. Blue-green (pros, cons, infrastructure cost)
3. Canary (pros, cons, routing complexity, monitoring needs)
4. Feature flags (pros, cons, code complexity, testing)
5. Shadow deployment (pros, cons, when useful)
Recommendation:
1. Best strategy (with rationale based on constraints)
2. Implementation plan (step by step)
3. Monitoring plan (what to watch during/after deploy)
4. Rollback procedure (specific steps, who executes, how fast)
5. Risk mitigation (what could go wrong, how to prevent)
Format: Deployment strategy document for engineering leadership.

Infrastructure as Code

4. Terraform Module Generator

Role: Terraform infrastructure engineer
Task: Write a Terraform module for [infrastructure component].
Provider: [AWS / GCP / Azure / multi-cloud]
Component: [VPC, EKS cluster, RDS, S3, Lambda, etc.]
Requirements:
1. Module structure (main.tf, variables.tf, outputs.tf, versions.tf)
2. Variables (all configurable inputs with type, default, description, validation)
3. Resources (with proper naming conventions, tagging, encryption by default)
4. Outputs (what other modules need to consume)
5. Data sources (if referencing existing resources)
6. Locals (for computed values, name formatting)
7. Provider configuration (version constraints, region, assume_role)
Best practices:
- Naming: [project]-[env]-[resource]-[name] convention
- Tags: environment, project, managed-by, cost-center
- Encryption: enable at rest and in transit
- Least privilege IAM
- Modular and reusable (no hardcoded values)
Output: Complete Terraform module files ready for use.
Include: Example usage (how another module would call this one).

5. Kubernetes Manifest Generator

Role: Kubernetes YAML engineer
Task: Write Kubernetes manifests for [workload description].
Application: [Name, container image, port, resource needs]
Manifests needed:
1. Namespace (if applicable)
2. Deployment (replicas, strategy, container spec, probes, resources)
3. Service (ClusterIP / NodePort / LoadBalancer, port mapping)
4. Ingress (host, path, TLS, annotations)
5. ConfigMap (non-sensitive config)
6. Secret (sensitive config — note: use external secrets in production)
7. HorizontalPodAutoscaler (min/max replicas, CPU/memory target)
8. PodDisruptionBudget (minAvailable or maxUnavailable)
9. NetworkPolicy (if needed — restrict traffic)
10. ServiceAccount (with proper RBAC)
For the Deployment:
- Liveness probe (what endpoint, interval, failure threshold)
- Readiness probe (what endpoint, interval, failure threshold)
- Resource requests and limits (CPU, memory — based on app needs)
- Rolling update strategy (maxSurge, maxUnavailable)
- Graceful shutdown (terminationGracePeriodSeconds, preStop hook)
Output: Complete YAML files ready for kubectl apply.
Constraint: Follow Kubernetes best practices — no hostPath, no privileged, no latest tag.

6. Dockerfile Optimizer

Role: Container optimization specialist
Task: Review and optimize this Dockerfile for [application].
Current Dockerfile: [Paste it]
Application: [language, framework, what it does]
Review checklist:
1. Base image (is it minimal? alpine? distroless? pinned version?)
2. Layer caching (are COPY instructions ordered for cache efficiency?)
3. Multi-stage build (can we separate build from runtime?)
4. Image size (what can be removed? dev dependencies, docs, caches)
5. Security (non-root user? no secrets in layers? .dockerignore?)
6. Health check (HEALTHCHECK instruction? or rely on orchestration?)
7. Build context size (.dockerignore file? what is being sent?)
8. Build args vs env vars (build-time config vs runtime config)
9. .dockerignore (what should be excluded from build context?)
Output:
1. Optimized Dockerfile (with comments explaining changes)
2. .dockerignore file
3. Before/after image size estimate
4. Security improvements list
5. Build time improvement estimate
Format: Complete optimized Dockerfile ready for use.

Monitoring & Observability

7. Monitoring Stack Design

Role: Observability architect
Task: Design a monitoring and alerting setup for [infrastructure/application].
Stack components:
1. Metrics (collection, storage, visualization — Prometheus + Grafana? CloudWatch? Datadog?)
2. Logs (aggregation, search, retention — ELK? Loki? Cloud logging?)
3. Traces (distributed tracing — Jaeger? OpenTelemetry? X-Ray?)
4. Alerts (rules, routing, escalation — Alertmanager? PagerDuty? Opsgenie?)
5. Dashboards (who needs what? SRE vs dev vs product vs exec)
For each component:
1. What to collect (specific metrics, log sources, trace points)
2. Tool selection (with rationale and cost estimate)
3. Configuration approach (agents, exporters, instrumentation)
4. Retention policy (how long to keep data, why)
5. Access control (who can view, who can modify)
Alert design:
1. Alert rules (what triggers, threshold, duration)
2. Severity levels (critical, warning, info)
3. Routing (which team, which channel, which hours)
4. Escalation (if not acknowledged in X minutes, escalate to Y)
5. Runbook links (each alert links to remediation steps)
Format: Observability architecture document with implementation plan.

8. SLA/SLO/SLI Definition

Role: Site Reliability Engineer
Task: Define SLIs, SLOs, and error budgets for [service].
Service: [Name, what it does, user expectations]
SLIs (Service Level Indicators) to define:
1. Availability (successful requests / total requests)
2. Latency (p50, p95, p99 — what is the target?)
3. Throughput (requests per second, target capacity)
4. Error rate (% of failed requests)
5. Data durability (for storage services)
For each SLI:
1. Definition (exact formula)
2. Measurement method (where does the data come from?)
3. Good events vs bad events (how do we classify?)
4. Target SLO (the objective — e.g., 99.9% availability)
5. Error budget (what is allowed? — 0.1% per period = X minutes/month)
6. Consequences of burning budget (freeze deploys? escalate?)
Error budget policy:
1. How is the budget tracked? (daily, weekly, monthly)
2. What happens when 50% consumed? (notify, review)
3. What happens when 100% consumed? (freeze, post-mortem, re-plan)
4. How does this affect deployment velocity?
Format: SLO document for the service, ready for stakeholder agreement.

9. Incident Response Runbook

Role: SRE creating an incident runbook
Task: Create an incident response runbook for [scenario — service down, high error rate, database outage, etc.].
Scenario: [What is the situation?]
Severity: [SEV1 / SEV2 / SEV3 — based on user impact]
Runbook sections:
1. Detection (how do we know? alert name, dashboard link)
2. Assessment (how to confirm the incident is real)
3. Triage (who to page, who leads, who communicates)
4. Immediate Actions (first 15 minutes — specific steps to stabilize)
5. Investigation (where to look, what logs, what metrics)
6. Common Causes (top 5 likely causes with specific checks)
7. Resolution (step-by-step fix for each common cause)
8. Post-Incident (when is it safe? how to verify recovery?)
9. Communication (status page, customer notice, internal updates)
10. Escalation (who to call if you cannot fix it)
For each action step:
1. What to do (specific command or click)
2. Who does it (role)
3. Expected result
4. If it does not work (next step / alternative)
Format: Runbook that a new on-call engineer can follow at 3 AM.

Automation & Scripting

10. Infrastructure Cost Optimization Audit

Role: Cloud cost optimization specialist
Task: Audit cloud infrastructure spend for [project/account/region].
Data: [Monthly spend, breakdown by service, trend over 6 months]
For each optimization opportunity:
1. Resource (what is being spent on)
2. Current cost (monthly, annualized)
3. Issue (overprovisioned, idle, wrong tier, no reserved capacity)
4. Recommendation (specific action — resize, terminate, reserved instance, spot)
5. Expected savings (monthly, annualized, % of current)
6. Risk (what could break if we change this?)
7. Implementation effort (hours to implement)
Output:
1. Cost optimization report (ranked by savings)
2. Quick wins (can do in 1 day, low risk)
3. Strategic savings (requires planning, high impact)
4. Total potential savings ($ and % of current spend)
5. Rightsizing recommendations (specific resource changes)
6. Reserved capacity analysis (which resources are stable enough for commitments?)
Format: Cost audit report for engineering/finance leadership.

11. Backup and Disaster Recovery Plan

Role: DevOps resilience engineer
Task: Create a backup and DR plan for [system/infrastructure].
Components: [databases, file storage, configs, secrets, code repos]
For each component:
1. Backup method (snapshot, dump, replication, versioned storage)
2. Frequency (real-time, hourly, daily, weekly)
3. Retention (how many copies, how long kept)
4. Storage location (same region? cross-region? cross-cloud?)
5. Encryption (at rest, in transit, key management)
6. Verification (how do we test that backups work? frequency?)
7. Recovery procedure (step by step, RTO, RPO)
DR scenarios:
1. Single service failure (how to recover, RTO, RPO)
2. Availability zone outage (failover plan)
3. Region outage (cross-region recovery plan)
4. Data corruption (point-in-time recovery)
5. Ransomware/malicious deletion (air-gapped backups?)
For each scenario:
1. Trigger (how we detect)
2. Decision authority (who declares DR)
3. Recovery steps (ordered, specific)
4. RTO target
5. RPO target
6. Communication plan
Format: DR plan document for review and regular testing.

12. Security Hardening Checklist

Role: DevSecOps engineer
Task: Create a security hardening checklist for [infrastructure/platform].
Scope: [Kubernetes cluster / cloud account / Linux server / container]
Checklist categories:
1. Access Control (IAM least privilege, MFA, key rotation, service accounts)
2. Network Security (security groups, NACLs, VPC config, DNS, ingress)
3. Data Protection (encryption at rest, in transit, key management, secrets)
4. Container Security (image scanning, base image, non-root, read-only fs)
5. Compliance (audit logs, config standards — CIS, NIST)
6. Secrets Management (vault, external secrets, no plaintext)
7. Dependency Security (scanning, patching policy, vulnerability management)
8. Runtime Security ( Falco, OPA, network policies, seccomp)
9. Monitoring (security events, anomaly detection, alerting)
10. Incident Readiness (forensics, logging, IR plan)
For each item:
1. What to check
2. How to check (command or console steps)
3. Pass criteria
4. Risk if not addressed
Generate 40-50 items.
Format: Security hardening checklist ready for audit execution.

Best Practices

For more infrastructure content, see our AI prompts for system administrators and AI prompts for cybersecurity analysts.