The problem: a cluster that is always one bad kubectl apply away from trouble
Anyone who has run Kubernetes in production knows the pattern. A pipeline is green, the deployment says Running, and two hours later the pod is in CrashLoopBackOff because the liveness probe was set to 2 seconds and the JVM takes 40 to warm up. Or a Terraform plan quietly proposes to replace the node pool, and you catch it only because you happened to read the diff.
AI doesn't remove the operational responsibility from you. But it removes the boring 80%: writing yet another Dockerfile layer, debugging a ImagePullBackOff, translating a YAML manifest into a readable checklist, or explaining why terraform plan wants to destroy a database. Below are 12 prompts I actually use — each one with a real scenario, the exact prompt, and what comes back. Treat them as templates, not magic: garbage in, garbage out.
A word of warning up front: LLMs hallucinate flags and API versions. Always verify against the official docs — kubernetes.io, developer.hashicorp.com/terraform, docs.docker.com. The prompts below are written to force the model to cite the version it assumes.
1. The manifest auditor: "find what will break at 3 a.m."
Scenario: a Deployment inherited from a colleague. It works, but you suspect it is fragile.
Prompt:
You are a Kubernetes SRE. Review this manifest for a production cluster
running Kubernetes 1.30. For each field, tell me whether it is missing,
unsafe, or fine. Specifically check: resource requests/limits, probes
(readiness vs liveness vs startupProbe), PodDisruptionBudget, securityContext
(runAsNonRoot, readOnlyRootFilesystem), and topologySpreadConstraints.
Output a table: Field
| Current value | Risk | Recommended value | Why.
Do not invent API fields — if unsure, say so and link to kubernetes.io docs.
MANIFEST:
<paste YAML>
Result: the model reliably flags the classic killers — no startupProbe on slow-starting apps, livenessProbe identical to readinessProbe, no resources.requests (which makes the scheduler blind). It does not replace kube-score or kubeconform, but it explains why those tools complain, which is what actually teaches you.
2. CrashLoopBackOff triage without the guesswork
Scenario: a pod restarts every 30 seconds and kubectl logs shows nothing useful.
Prompt:
A pod is in CrashLoopBackOff on Kubernetes 1.30. Here is the output of
`kubectl describe pod` and `kubectl logs --previous`. Give me a ranked list
of the 5 most likely root causes, and for each: the exact kubectl command
or log line that confirms or rejects it. No generic advice — commands only.
DESCRIBE:
<paste>
LOGS:
<paste>
Why it works: kubectl logs --previous is the key flag most people forget — it shows the logs of the crashed container, not the current one. The prompt makes the model reason over exit codes (OOMKilled = 137, application error = 1) instead of guessing.
3. Dockerfile slimming with a diff
Scenario: a Node.js image is 1.4 GB and the CI cache is useless.
Prompt:
Rewrite this Dockerfile for a multi-stage build. Requirements:
- base image: node:20-alpine (explain if a different tag is better)
- non-root user
- separate dependency install layer so it caches
- final image must not contain devDependencies or build tools
Output: (1) the new Dockerfile, (2) a table of layers removed and why,
(3) the exact `docker build` command to verify size with `docker image ls`.
ORIGINAL:
<Dockerfile>
Result: the classic fix — copy package*.json and npm ci in their own layer before copying source — appears almost every time. It is not novel, but having the model produce the diff plus the verification command saves the ten minutes of context-switching.
4. The Terraform plan translator
Scenario: terraform plan outputs 200 lines and you need to know if anything is being destroyed.
Prompt:
Here is a `terraform plan` output (Terraform 1.9). Summarize it as a table:
Resource
| Action (create/update/replace/destroy) | Destructive? | Why.
Then list only the resources marked `-/+` (replace) or `-` (destroy)
and explain what triggers the replacement. Flag anything touching
stateful resources (databases, volumes, DNS records).
PLAN:
<paste>
Why it matters: replacements (-/+) are the silent killers — Terraform shows them as "will be updated in-place" in a quick skim but actually destroy and recreate. The prompt forces the model to isolate them.
5. CI/CD pipeline review: "what fails on the second run?"
Scenario: a GitHub Actions workflow passes locally, fails in CI.
Prompt:
Review this GitHub Actions workflow. List every step that is not
idempotent (would fail on a second run without cleanup), every secret
that is logged, and every step that assumes a specific runner OS.
For each issue, output: Line
| Problem | Fix | Confidence (high/medium/low).
WORKFLOW:
<YAML>
Result: catches docker login without logout, artifacts that collide on re-run, and ${{ secrets.X }} echoed into logs. The confidence column is important — it stops the model from pretending certainty.
6. The Helm values explainer
Scenario: a third-party chart has 400 lines of values.yaml and no docs.
Prompt:
Explain this values.yaml for a Helm chart. Group the keys into:
(1) safe to change, (2) requires understanding of the app, (3) dangerous.
For each key in group 2 and 3, explain the effect and the default.
Do not guess keys that are not present — say "not defined".
VALUES:
<YAML>
7. The root-cause prompt for ImagePullBackOff
Scenario: the image exists in the registry. The pod still won't pull it.
Prompt:
Pod is in ImagePullBackOff. Here is the event log and the `imagePullSecrets`
config. List the 4 most likely causes in order, and for each give the
one-liner to test it (kubectl, docker, or registry API). Check: image tag
vs digest, secret in the right namespace, secret type (dockerconfigjson),
and node-level pull policy.
EVENTS:
<paste>
Why it works: the top cause is almost always a secret created in the wrong namespace — kubectl get secret regcred -n <ns> catches it in one line.
8. Terraform module interview
Scenario: you found a module on the registry and want to know if it's safe.
Prompt:
Here is the source of a Terraform module. Answer:
1. What resources does it create, and are any of them stateful?
2. Does it hardcode any values that should be variables?
3. Does it manage resources it should not own (e.g. IAM, networking)?
4. Is the provider version pinned? If not, what is the risk?
Be concise. If something is ambiguous, say so.
MODULE:
<HCL>
9. The "explain this to my manager" prompt
Scenario: an incident postmortem needs a one-paragraph summary for non-engineers.
Prompt:
Turn these technical incident notes into a 3-sentence summary for a
non-technical manager. First sentence: what happened and for how long.
Second: the root cause in plain language. Third: the concrete change
that prevents recurrence. No jargon, no blame.
NOTES:
<paste>
Result: consistently produces something usable, which is rare for incident comms.
10. The Docker Compose → Kubernetes migration prompt
Scenario: a docker-compose.yml needs to become a Deployment + Service.
Prompt:
Convert this docker-compose.yml to Kubernetes 1.30 manifests.
Rules:
- one file with --- separators
- no hardcoded secrets — use Secret references and show the
`kubectl create secret` command instead
- add resource requests/limits and readinessProbe from the healthcheck
- explain any Compose feature that has no Kubernetes equivalent
COMPOSE:
<YAML>
Why it works: Compose features like depends_on have no clean K8s equivalent — the prompt forces the model to say so instead of inventing an init container that doesn't work.
11. The Kubernetes YAML linter-as-a-teacher
Scenario: you want to learn why a manifest is wrong, not just get a fix.
Prompt:
Act as a Kubernetes reviewer. I will paste manifests. For each, don't
fix them — instead ask me questions that lead me to the fix. Ask about
probes, resources, security context, and update strategy. Only after
I answer, confirm or correct.
MANIFEST:
<YAML>
Result: this is the Socratic mode — slower, but it's the one prompt that actually builds skill rather than dependency.
12. The "explain this Terraform error" prompt
Scenario: Error: Cycle: aws_security_group.a, aws_security_group.b — a classic.
Prompt:
Terraform 1.9 error: <paste error>. Explain the cause in 2 sentences,
then give the minimal change to fix it. Do not restructure the whole
config. If the fix requires a state move, show the exact
`terraform state mv` command.
Why it works: dependency cycles in security groups are a known Terraform trap — the model reliably points to aws_security_group_rule as the escape hatch, and the state mv command is real.
What this actually buys you
None of these prompts write your infrastructure for you. What they do is collapse the distance between "something is broken" and "here is the one command that tells me why." The pattern across all twelve is the same: constrain the model, force it to cite versions, and demand commands, not prose. The moment you let it free-associate, you get hallucinated API fields and confident lies.
Pick two or three from this list and run them against your current cluster and repo this week. You will find at least one missing resources.requests and one non-idempotent CI step. If you want to go deeper on the DevOps toolchain, asibiont.com/blog has more breakdowns on Docker, CI/CD, and infrastructure-as-code — and the prompts only get sharper once you know what the tools actually do under the hood.
Comments