The 3 A.M. Problem
Ask any DevOps engineer what they actually do, and you'll get the same answer between yawns: they wait. They wait for a failing pipeline, a CrashLoopBackOff pod, a disk that filled up on a Tuesday. According to the classic Google SRE book, the ideal operational load for a team is around 50% — the rest should go to engineering work. In practice, firefighting eats the day, and infrastructure as code gets written in the gaps between alerts.
This is exactly where a large language model earns its keep — not as an oracle, but as an infinitely patient rubber duck that knows Docker's reference docs and the Kubernetes API by heart. The trick is that ChatGPT will not write a good Deployment manifest for you unless you force it to state constraints, versions and rollback paths up front. Vague prompts produce YAML that looks plausible and breaks in staging.
The 12 prompts below are written for exactly that: give the model a role, bounded inputs and a required output format, so the answer is a diff you can apply — not a lecture. Each one maps to a real task in the Docker → Kubernetes → CI/CD chain, and every example is copy-paste ready. Treat every generated command as untrusted until you've read it — kubectl delete and docker system prune don't ask twice.
Docker: From Dockerfile to a Smaller, Safer Image
1. The Dockerfile Auditor
The problem: a 1.2 GB Node image with latest tags, root user, and a COPY . . that invalidates the cache on every commit.
Prompt:
You are a Docker image optimization expert. Audit this Dockerfile.
For each issue, output a table: line number
| issue | severity (critical/major/minor) | fix.
Then provide a rewritten multi-stage Dockerfile targeting <base image, e.g. node:22-alpine>,
using a non-root USER, a .dockerignore, and BuildKit cache mounts for package managers.
Explain each change in one sentence. Do not invent flags that don't exist.
Dockerfile:
<paste>
Example output fragment:
FROM node:22-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm npm ci
FROM node:22-alpine AS runner
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
USER node
CMD ["node", "server.js"]
The --mount=type=cache syntax requires BuildKit (default in Docker Engine 23+), so mention your engine version in the prompt to avoid legacy-mode errors.
2. The Compose Debugger
The problem: docker compose up starts, but the API container can't reach Postgres. Usually it's localhost inside a container, a missing depends_on healthcheck, or a network mismatch.
Prompt:
Act as a Docker Compose troubleshooter. Here is my compose.yaml and the error log.
1) List the 3 most likely root causes, ranked by probability.
2) For each, give the exact command to verify it (docker compose ps, docker inspect, etc.).
3) Provide a corrected compose.yaml using a healthcheck with condition: service_healthy,
and explain why depends_on alone does not wait for readiness.
compose.yaml:
<paste>
Log:
<paste>
Key fact the model should state: depends_on without condition: service_healthy only waits for container start, not for the database to accept connections — a documented Compose behavior that explains a huge share of "works on my machine" bugs.
3. The Image Diet
Prompt:
My image is <size> GB. Analyze the likely bloat sources for a <stack> app,
suggest a distroless or alpine base, and show how to compare layers with
docker history and dive. Give a before/after size estimate and the trade-offs
(debugging without a shell, glibc vs musl).
Use docker history <image> to verify the model's guesses — it shows each layer's size and the command that created it.
Kubernetes: YAML That Actually Schedules
4. The Manifest Generator With Guardrails
The problem: LLMs love to invent apiVersion: apps/v1beta1 or omit resources.
Prompt:
Generate Kubernetes manifests for <app>. Constraints:
- Target Kubernetes v1.30, use only stable API versions.
- Include Deployment, Service, Ingress, HPA, PodDisruptionBudget.
- Set resources.requests and limits, readiness and liveness probes,
securityContext with runAsNonRoot: true and readOnlyRootFilesystem: true.
- Output one file per resource, then a kubectl apply -k kustomization example.
For every apiVersion, add a comment with the Kubernetes version it became stable in.
The comment requirement is a cheap hallucination trap: if the model claims autoscaling/v2 is beta in 1.30, you know the rest of the YAML deserves suspicion.
5. The CrashLoopBackOff Interrogator
Prompt:
A pod is in CrashLoopBackOff. Here is `kubectl describe pod` and `kubectl logs --previous`.
Work through: exit code meaning, last state reason, event timestamps.
Then give a ranked hypothesis list, one diagnostic command per hypothesis,
and the fix. If the exit code is 137, explain OOMKilled vs SIGKILL from a probe.
Exit code 137 = 128 + 9 (SIGKILL) — usually the OOM killer or a failed liveness probe, and the model will separate the two cases if you ask.
6. The Resource Rightsizer
The problem: everyone sets cpu: 100m by copy-paste and wonders why latency spikes.
Prompt:
Here is the output of `kubectl top pods` for 24h and my HPA config.
Recommend requests/limits per container using the pattern
requests = p50 usage, limits = p99 with headroom. Explain the risk of CPU limits
(throttling via cfs_quota) vs memory limits (OOMKill). Output a table and a patch command.
Ask for kubectl patch or kubectl set resources syntax so the fix is one command, not a manual YAML hunt.
7. The RBAC Least-Privilege Builder
Prompt:
I need a ServiceAccount for <component> that only reads ConfigMaps in namespace <ns>
and creates Jobs there. Generate Role + RoleBinding, then a `kubectl auth can-i --list`
check to verify. Flag anything broader than necessary.
Verify with kubectl auth can-i create jobs --as=system:serviceaccount:<ns>:<sa> -n <ns> — a real, built-in impersonation check.
CI/CD: Pipelines That Fail Fast and Explain Why
8. The Pipeline Translator
The problem: migrating Jenkins to GitHub Actions without rewriting everything by hand.
Prompt:
Convert this Jenkinsfile to GitHub Actions (.github/workflows/ci.yml).
Preserve: stages, caching, secrets usage, matrix builds.
Use actions/checkout@v4, actions/setup-node@v4, and pin third-party actions to a commit SHA.
Add `permissions: contents: read` at the workflow level. Comment each step's purpose.
Jenkinsfile:
<paste>
Pinning to a SHA is a real supply-chain hardening practice recommended by GitHub's security docs — a nice detail the model includes only when prompted.
9. The Failing-Build Coroner
Prompt:
This CI job failed. Here is the log tail and the workflow file.
Identify the failing step, quote the exact error line, and classify the cause:
code / environment / flaky test / permissions / network.
Give the minimal fix and a guard so this class of failure is caught earlier next time.
10. The Cache Strategist
Prompt:
My CI takes 18 minutes. Here is the workflow. Propose a caching plan:
which paths to cache, cache key strategy (hash of lockfile), and what NOT to cache.
Estimate savings per stage. Warn me about cache poisoning risks for PRs from forks.
11. The Secrets Sweep
Prompt:
Scan this repo structure and CI config for hardcoded secrets and risky patterns
(echo $TOKEN, secrets in logs, overly broad OIDC trust).
Output: file
| line | risk | remediation. Suggest gitleaks pre-commit config
and OIDC-based cloud auth instead of long-lived keys.
12. The Runbook Author
Prompt:
Write a runbook for "<service> is down". Sections: symptoms, dashboards to check,
first 5 commands, escalation path, rollback procedure, postmortem template.
Keep it under one page. Assume the reader is on-call for the first time.
What the Prompts Have in Common
| Ingredient | Why it matters | Example |
|---|---|---|
| Role + constraints | Narrows the output space | "Target Kubernetes v1.30, stable APIs only" |
| Required format | Makes output diffable | "table: line | issue | severity | fix" |
| Verification step | Turns answers into checks | "one diagnostic command per hypothesis" |
| Hallucination trap | Exposes invented facts | "comment the K8s version each API became stable" |
| Blast-radius warning | Prevents disasters | "flag anything broader than necessary" |
A pattern worth internalizing: ask the model to separate diagnosis from prescription. When it lists hypotheses first and commands second, you can reject a wrong theory before running a single destructive command. The same discipline applies to infrastructure as code generally — the model drafts, the pipeline and the cluster verify.
For deeper grounding, point the model at primary sources: the Dockerfile reference and Compose file spec on docs.docker.com, the Kubernetes API reference on kubernetes.io, and the GitHub Actions documentation. If a prompt's answer contradicts those, the docs win, not the model.
The real shift isn't that ChatGPT writes your YAML — it's that the boring 40% of DevOps work (translating, auditing, explaining, drafting runbooks) stops consuming your evenings. You still own the judgment call: read the diff, run the check, apply the change. Start with prompts 1, 4 and 9 — they cover the three places teams burn the most time — and keep the verification commands in your team wiki. Night shifts get shorter when the first responder is a prompt that already knows what to ask next.
Comments