The On-Call Engineer That Never Sleeps: Prompting ChatGPT Through Docker, Kubernetes, Terraform, and CI/CD

The On-Call Engineer That Never Sleeps: Prompting ChatGPT Through Docker, Kubernetes, Terraform, and CI/CD

It is 03:14. Your phone lights up with a PagerDuty alert: CrashLoopBackOff on the checkout-api deployment, and the error budget for the quarter is bleeding. You know the drill — SSH into a jump host, kubectl describe pod, scroll through 400 lines of YAML, and try to remember whether the readiness probe timeout is 5 seconds or 10. By the time you find the typo in the livenessProbe block, it is 04:30 and you have already missed the window to sleep.

This is the part of DevOps that nobody puts on a conference slide. Writing Terraform modules, wiring GitHub Actions, debugging Docker layer caching — these are not the glamorous 10% of the job. They are the 90% that eats your evenings. According to the 2024 State of DevOps / DORA report, elite teams still spend a meaningful share of their time on unplanned work and rework, and configuration drift is one of the recurring culprits.

Large language models will not replace your SRE judgment. But they are extraordinarily good at the mechanical parts: translating intent into HCL, spotting a missing USER directive in a Dockerfile, or explaining why a NetworkPolicy silently drops traffic. This article is a working collection of prompts — ordered from basic to expert — that turn ChatGPT into a competent pair-engineer for Docker, Kubernetes, Terraform, and CI/CD. Every example is real, runnable, and grounded in official documentation.

A note on how to use these prompts

Three rules keep LLM output trustworthy in infrastructure work:

1. Always paste the exact versions. Kubernetes 1.30 and 1.24 behave differently. Terraform 1.9 changed moved block ergonomics. Docker BuildKit is now the default builder. If you do not tell the model your versions, it will guess — and guess wrong.
2. Ask for the "why" before the "what." A generated manifest you do not understand is a liability. Prompt for reasoning, then for code.
3. Verify against the source of truth. The Kubernetes API reference, the Terraform Registry, and Docker docs are the only authorities. Treat the model as a fast first draft, not a compiler.

Basic level: stop googling the syntax

1. The Dockerfile reviewer

Task: Turn a messy, hand-grown Dockerfile into a lean, multi-stage build.

Prompt:

You are a Docker build expert. Review the Dockerfile below.
Target: production Node.js 20 API, image must stay under 150 MB.
Constraints:
- Use multi-stage build with node:20-alpine as builder and node:20-alpine-slim as runtime.
- Run as non-root user (UID 1001).
- Leverage layer caching: copy package.json and lockfile before source code.
- Do NOT use `npm install`; use `npm ci --omit=dev` in the runtime stage.
Explain every change you make in a table: line, original, new, why.

<paste Dockerfile here>

Example result (abridged):

# ---- builder ----
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# ---- runtime ----
FROM node:20-alpine AS runtime
ENV NODE_ENV=production
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev && npm cache clean --force
COPY --from=builder /app/dist ./dist
USER 1001
EXPOSE 3000
CMD ["node", "dist/server.js"]

The USER 1001 recommendation maps directly to the CIS Docker Benchmark control 4.1 ("Create a user for the container").

2. The Kubernetes manifest explainer

Task: Understand a manifest you inherited, field by field.

Prompt:

Act as a Kubernetes 1.30 tutor. Walk me through this Deployment manifest line by line.
For each field, state: (a) what it controls, (b) the default if omitted, (c) one failure mode if misconfigured.
Flag any field that is deprecated in 1.30.

<paste deployment.yaml here>

Example result: The model will typically highlight that spec.template.spec.containers[].resources.requests being absent means the scheduler treats the pod as BestEffort, making it the first eviction candidate under node pressure — a documented behavior in the Kubernetes QoS classes doc. It will also flag extensions/v1beta1 API versions as removed.

3. The Terraform formatter and linter

Task: Get HCL into terraform fmt-clean shape with sane naming.

Prompt:

Reformat the Terraform below to pass `terraform fmt` and `tflint`.
Rules:
- snake_case for all resource and variable names.
- Move hardcoded values into variables with descriptions and types.
- Add `default` only where a safe default exists.
- Output the final code plus a diff-style summary.
Target: Terraform 1.9, AWS provider 5.x.

This is the fastest way to clean up a config that a hurried teammate committed at 2 a.m.

Intermediate: generating infrastructure you can actually ship

4. The "golden path" Kubernetes Deployment

Task: Produce a production-grade Deployment with probes, resources, and security context.

Prompt:

Generate a production-ready Kubernetes Deployment + Service for a Python FastAPI app.
Requirements:
- 3 replicas, RollingUpdate with maxSurge=1, maxUnavailable=0.
- startupProbe (httpGet /healthz), readinessProbe, livenessProbe — justify the numbers.
- resources.requests and .limits for CPU and memory.
- securityContext: runAsNonRoot, readOnlyRootFilesystem, drop ALL capabilities.
- PodDisruptionBudget with minAvailable=2.
- topologySpreadConstraints across zones.
Output as one YAML file. Add a comment above every non-obvious field.

Why this works: you are not asking for "a deployment," you are specifying the contract. The model fills in the boilerplate while you keep the design decisions. The startupProbe guidance comes from the official Configure Liveness, Readiness and Startup Probes task page.

5. The Helm chart from scratch

Task: Wrap a set of manifests into a parameterized Helm chart.

Prompt:

Convert these raw manifests into a Helm chart (Helm 3.15).
- values.yaml must expose image.tag, replicaCount, resources, ingress.enabled.
- Use _helpers.tpl for common labels.
- Add a NOTES.txt that prints the service URL after install.
- Include a Chart.yaml with apiVersion v2.
Show the full directory tree, then each file.

6. The GitHub Actions pipeline

Task: Build a CI/CD workflow with caching, matrix builds, and environment gates.

Prompt:

Write a GitHub Actions workflow (.github/workflows/ci.yml) for a monorepo with a Node service and a Go service.
Steps required:
1. Lint and unit test each service in parallel (matrix).
2. Build and push Docker images to GHCR, tagged with the short SHA and `latest` only on main.
3. Use actions/cache for node_modules and Go modules.
4. Deploy to staging automatically; require manual approval for production via GitHub Environments.
5. Fail fast: cancel in-progress runs on the same branch.
Use pinned action versions, not floating tags. Explain the trigger strategy.

The "pin action versions" instruction reflects GitHub's own security hardening guidance, which recommends pinning to a full-length commit SHA rather than a mutable tag.

7. The Terraform module skeleton

Task: Scaffold a reusable module with validation and outputs.

Prompt:

Create a Terraform module `vpc` for AWS (provider 5.x, Terraform 1.9).
- Inputs: cidr_block, az_count, enable_nat_gateway (bool), tags (map).
- Use variable validation blocks (e.g., cidr_block must be a valid CIDR).
- Outputs: vpc_id, public_subnet_ids, private_subnet_ids.
- Add a README.md following the terraform-docs format.
- Include an `examples/complete` directory.

Variable validation blocks (validation { condition = can(cidrhost(var.cidr_block, 0)) ... }) are a real, documented feature added in Terraform 0.13 — see the Terraform input variables docs.

Advanced: incident response and debugging

8. The CrashLoopBackOff triage prompt

Task: Diagnose a failing pod from raw evidence.

Prompt:

You are an on-call SRE. A pod is in CrashLoopBackOff. Here is the evidence:
- `kubectl describe pod` output (below)
- last 100 lines of `kubectl logs --previous`
- the Deployment manifest
Give me a ranked list of hypotheses, the single command to confirm each, and the likely fix.
Do not guess past the evidence. If something is missing, tell me what to collect next.

Example result: Common verdicts include an OOMKilled container (exit code 137, visible in describe), a missing environment variable causing an immediate exit, or a readinessProbe pointed at the wrong path. The prompt's insistence on "do not guess past the evidence" is what separates a useful triage from a hallucinated one.

9. The Terraform plan decoder

Task: Translate a scary terraform plan into a human-readable change log.

Prompt:

Summarize this `terraform plan` output for a change-review meeting.
For each resource:
- Action (create / update / replace / destroy)
- Blast radius (does it require downtime?)
- Which change is the riskiest and why
End with a go / no-go recommendation and the exact command to roll back.

This is invaluable before a Friday deploy. A plan that shows forces replacement on a database resource should stop the release cold.

10. The Kubernetes NetworkPolicy debugger

Task: Figure out why traffic between two services is silently dropped.

Prompt:

Two pods in namespace `payments` cannot talk to `ledger` on port 5432.
Here are the NetworkPolicy manifests, the pod labels, and the namespace labels.
Trace which policy selects each endpoint and which rule (if any) permits the flow.
If no policy permits it, show the minimal NetworkPolicy to allow it.
Reference the Kubernetes NetworkPolicy semantics for default-deny.

NetworkPolicy behavior (once any policy selects a pod, that pod becomes isolated for the selected direction) is defined in the Network Policies concept doc. This is exactly the kind of rule humans forget at 3 a.m.

11. The Docker layer-cache forensics

Task: Find why CI rebuilds take 12 minutes instead of 90 seconds.

Prompt:

Here is the Dockerfile and the BuildKit build log.
Identify which instructions bust the layer cache on every run.
Suggest a reordering that maximizes cache reuse.
Flag any RUN that combines unrelated steps (which hurts cache granularity).

Typical finding: a COPY . . placed before RUN npm ci, or a RUN apt-get update && apt-get install split across two layers. Both are classic anti-patterns documented in the Docker build cache best practices.

12. The CI/CD pipeline post-mortem

Task: Learn from a failed deployment.

Prompt:

A deploy to production failed at step "helm upgrade". Here is the full CI log.
Write a blameless post-mortem:
1. Timeline (from log timestamps).
2. Root cause.
3. Contributing factors.
4. Action items, each with an owner role and a measurable success criterion.
Keep it factual and free of speculation.

The "blameless post-mortem" format follows the Google SRE Book chapter on postmortem culture — a widely accepted industry standard.

Expert: policy, cost, and the hard edge cases

13. The OPA / Gatekeeper policy generator

Task: Turn a human rule into a Rego policy.

Prompt:

Write an Open Policy Agent (OPA) Rego policy for Kubernetes admission control.
Rule: every container in namespace `prod` must set resources.limits.memory, and must not run as root.
Use the `violation` convention for Gatekeeper constraint templates.
Include unit tests using `opa test`.

Rego is a real policy language; Gatekeeper is the CNCF-graduated admission controller. Both are documented at openpolicyagent.org and the Gatekeeper project.

14. The FinOps prompt: right-sizing from real data

Task: Cut cloud spend without breaking SLAs.

Prompt:

Here is a CSV of 30 days of pod CPU/memory usage (from Prometheus) and the current requests/limits.
For each workload, recommend new requests/limits using the p95 metric + 20% headroom.
Output a table: workload, current request, p95, recommended request, estimated saving.
Flag any workload where p95 is within 10% of the limit (risk of throttling).

Right-sizing based on p95 is a standard FinOps practice; the mechanics of CPU throttling are explained in the Kubernetes resource management docs.

15. The migration planner (Terraform state surgery)

Task: Move resources between modules without destroying them.

Prompt:

I am refactoring Terraform: moving `aws_s3_bucket.logs` from the root module into module `storage`.
Show me the exact `moved` block syntax (Terraform 1.9) and the alternative `terraform state mv` command.
Explain what happens to the resource ID and how to verify with `terraform plan` that no destroy is planned.

The moved block is a real language feature introduced in Terraform 1.1 — see the refactoring docs.

16. The chaos-engineering hypothesis generator

Task: Design a controlled failure injection.

Prompt:

Design a chaos experiment for a 3-replica service on Kubernetes using LitmusChaos or Chaos Mesh.
- Steady-state hypothesis (metric + threshold).
- Blast radius limited to one pod.
- Rollback trigger.
- Expected observation in Prometheus.
Output the experiment YAML and a one-paragraph runbook.

Chaos Mesh and LitmusChaos are both CNCF projects with public CRD references — verify field names against their current docs before applying.

17. The "explain the trade-off" prompt

Task: Make an architectural decision you can defend in a design review.

Prompt:

We are choosing between (A) a single EKS cluster with namespaces per team and (B) one cluster per team.
Team size: 40 engineers, 6 teams, moderate compliance needs (SOC 2).
Give me a decision matrix across: blast radius, cost, upgrade friction, IAM complexity, and observability.
End with a recommendation and the two strongest counter-arguments.

This prompt is less about code and more about reasoning. Asking for the counter-arguments is what forces the model to stop being a yes-man and surface the real risks.

Guardrails: keeping the model honest

A few habits make the difference between a helpful assistant and a confident liar:

For anything touching a real cluster, the loop is always the same: generate → read → plan/diff → apply in staging → apply in prod. The model accelerates the first step; you own the last four.

The takeaway

The night-shift DevOps life is not a badge of honor — it is a symptom of toil that has not been automated yet. The prompts in this collection will not write your architecture for you, and they will not know that your legacy service has a hard dependency on a deprecated API. But they will draft the Dockerfile, the Helm chart, the GitHub Actions workflow, and the Terraform module in seconds, leaving your attention for the parts that actually need a human: trade-offs, blast radius, and the judgment call at 03:14.

Start with the basic prompts this week. Pick one piece of your pipeline that you dread touching, and let the model produce the first draft. Then read it, verify it against the official docs, and ship it. The goal is not to remove the engineer from the loop — it is to remove the engineer from the boring parts of the loop.

If you want to go deeper — from container internals to Kubernetes operators and infrastructure-as-code patterns — explore the structured tracks at asibiont.com. The tooling changes fast; the way you think about systems does not.