Every infrastructure engineer knows the 2 a.m. feeling: a pod is stuck in CrashLoopBackOff, the CI pipeline is red, and the Terraform plan wants to destroy a database. AI won't put out that fire for you — but it can hand you the right commands, a hypothesis list, and a second pair of eyes in seconds. Below is a working set of prompts I actually use, each with a real example and a way to verify the output before it touches production.
A word of caution first: LLMs hallucinate flags, image tags, and provider arguments. Treat every generated Dockerfile, manifest, and curl as a draft, not as truth. Verify against official docs — Docker reference, Kubernetes API, Terraform Registry, and the HashiCorp provider docs.
1. The Dockerfile audit: "explain, don't rewrite"
Ask the model to critique, not to generate blindly. That keeps you in control.
Prompt:
You are a Docker reviewer. Here is my Dockerfile. Do NOT rewrite it. Instead:
1) List every layer and its approximate size impact.
2) Flag anti-patterns: running as root, COPY . . before dependency install, missing .dockerignore, apt-get without --no-install-recommends, no cache cleanup.
3) For each issue, give a one-line fix with the exact instruction.
Dockerfile:
<PASTE>
Example answer it should produce: COPY . . placed before RUN pip install -r requirements.txt busts the layer cache on every source change — move the copy after install. apt-get install without rm -rf /var/lib/apt/lists/* leaves ~30–50 MB of package lists in the image.
Verify: run docker build --progress=plain . and check layer cache hits; run docker history <image> to see real layer sizes. Also add USER app and confirm with docker run --rm <image> whoami.
2. Multi-stage build from a bloated image
When an image is 1.2 GB and you need it lean, ask for a multi-stage rewrite with a hard constraint on the base image.
Prompt:
Rewrite this Dockerfile as a multi-stage build targeting a slim runtime image.
Constraints: pin base image by digest, use a non-root user, no build tools in the final stage, add a HEALTHCHECK.
Show the before/after size estimate and explain each stage.
<PASTE>
Example: a Go service gets FROM golang:1.22 AS build → FROM gcr.io/distroless/static final stage. The final image drops from hundreds of MB to a few MB because only the static binary ships.
Verify: docker images before/after; docker scout cves <image> (or trivy image <image>) to confirm the vulnerability count actually dropped, not just the size.
3. Diagnosing CrashLoopBackOff without guessing
This is where AI saves the most time — turning a wall of events into a ranked hypothesis list.
Prompt:
A pod is in CrashLoopBackOff. Here are `kubectl describe pod` and the last 100 log lines.
Do not guess blindly. Produce:
1) Top 3 likely root causes, ranked, each with the exact command to confirm it.
2) The single most informative next command.
3) What NOT to do (e.g., deleting the pod, which hides the cause).
<PASTE>
Example output: "Exit code 137 → OOMKilled. Confirm with kubectl get pod <name> -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'. Check current limits: kubectl describe pod <name> | grep -A3 Limits. Don't just bump memory — check for a memory leak first."
Verify: exit code 137 is SIGKILL, commonly OOM — the Kubernetes docs on pod lifecycle confirm the semantics. Cross-check kubectl top pod and node pressure events.
4. The "explain this Terraform plan" prompt
terraform plan output is long; the dangerous lines hide in the middle. Ask the model to diff semantically.
Prompt:
Here is a `terraform plan` output. Summarize it as a table:
| resource | action (create/update/replace/destroy) | risk | why |
Highlight anything that forces replacement on a stateful resource (RDS, EBS, S3) and anything with `# forces replacement`.
Call out resources being destroyed that I might not expect.
<PASTE plan>
Example: it flags aws_db_instance with ~ update in-place vs -/+ replace — replacement means downtime and a new endpoint. That single line is the difference between a boring deploy and a 3 a.m. incident.
Verify: always re-run terraform plan -out=tfplan and grep for forces replacement yourself: `terraform show -json tfplan
| jq '.resource_changes[] | select(.change.replace_paths)'`. Never approve a plan you haven't read.
5. Writing a Terraform module skeleton the right way
Don't ask for "a Terraform module" — ask for the interface first.
Prompt:
Design a reusable Terraform module for an S3 bucket with versioning, SSE-KMS encryption, and block-public-access.
Output: variables.tf (with types, descriptions, defaults), main.tf, outputs.tf, and a README with usage example.
Use only arguments that exist in the current hashicorp/aws provider. If unsure about an argument, mark it `# VERIFY`.
Example: variables like bucket_name (string), kms_key_arn (string, optional), enable_versioning (bool, default true). The # VERIFY markers let you grep for anything the model wasn't certain about.
Verify: terraform init then terraform validate; run terraform providers schema -json | jq to confirm each argument exists in the provider you pinned. A missing argument fails at validate, not at apply — good.
6. CI/CD log triage
Pipelines fail with noise. Ask for the signal.
Prompt:
Here is a failing GitHub Actions / GitLab CI log. Find the FIRST error that actually broke the build (ignore trailing noise and cascading failures).
Then: root cause, the minimal fix, and the command to reproduce locally.
<PASTE>
Example: "The real failure is npm ci at line 214: lockfileVersion 3 not supported by npm 8 in this runner. Fix: update the runner image or regenerate the lockfile with the matching npm. Reproduce: npx npm@8 ci."
Verify: re-run with set -x or --verbose; confirm the fix on a branch before merging. Don't let the model touch secrets in logs — scrub them first.
7. The "make it idempotent" prompt for scripts
Bash scripts that half-run and leave broken state are a classic. Ask for idempotency explicitly.
Prompt:
Rewrite this shell script to be idempotent and safe to re-run. Requirements: `set -euo pipefail`, check before create, no silent failures, log each step.
Explain each guard you added.
<PASTE>
Example: guard kubectl get ns foo || kubectl create ns foo instead of a bare kubectl create ns foo that fails on second run.
Verify: run it twice in a row in a scratch cluster — the second run must exit 0 and change nothing.
8. Kubernetes resource requests/limits sanity check
Prompt:
Given these pod specs and node types, flag containers with no requests/limits, requests > limits, or limits far above typical usage. Suggest realistic requests based on the app type.
<PASTE>
Verify: check actual usage with kubectl top pods --containers over a few days before trusting a suggestion. Guessed numbers are guesses — this is why you measure first.
9. The post-mortem skeleton
After an incident, AI is a fast structuring tool.
Prompt:
Turn these incident notes into a blameless post-mortem: timeline, impact, root cause, detection gap, action items with owners and dates. Keep it factual, no blame.
<PASTE notes>
Verify: a human must own each action item. The model drafts; you decide.
10. The "what could go wrong" red-team prompt
Before a risky deploy, ask the model to attack your plan.
Prompt:
Here is my deploy plan. Act as a skeptical SRE. List the 5 most likely failure modes, the blast radius of each, and a rollback step for each. Assume worst case.
<PASTE plan>
Verify: every rollback step must be a real, tested command — not "just revert."
The discipline that makes this safe
AI is a fast first draft and a tireless reviewer, not an authority. The pattern that works: generate → read → verify against official docs → test in a non-prod environment → only then ship. Keep secrets out of prompts, pin your provider and image versions, and treat every # VERIFY marker as a to-do, not decoration. Used this way, these prompts cut the boring parts of infrastructure work — reading logs, drafting manifests, explaining plans — and leave the judgment calls where they belong: with you. Want to go deeper into prompt patterns for engineering? Explore more guides at asibiont.com/blog.
Comments