Kubernetes and Terraform in 2026: 10 Prompts That Turn One DevOps Engineer Into a Platform Team
YAML was never supposed to be a career. Yet here we are: in 2026 a single platform engineer is expected to ship a fault-tolerant Kubernetes cluster, wire up Terraform state across three environments, keep CI/CD pipelines green, and still answer Slack at 11 PM when a node cordons itself. The job didn't get easier — the tooling got deeper. CNCF's annual survey keeps showing Kubernetes adoption plateauing near ubiquity while the number of people running it per cluster keeps shrinking. Fewer humans, more surface area.
The way competent teams are closing that gap in 2026 is not by hiring a platform team of six. It's by treating an LLM as a senior pair-programmer who has read every page of the Kubernetes docs, the Terraform registry, and the last decade of Stack Overflow — and who never gets tired of kubectl explain. But raw chat with a model produces confident garbage: deprecated APIs, invented CRD fields, terraform apply flags that don't exist. The difference between a useful assistant and a liability is the prompt.
Below are ten prompts I actually use when building and operating clusters. Each one is written to be copy-pasted, each one assumes a real failure mode, and each one is followed by a short case study of where it saved time. Treat this as a cheat sheet you keep in a scratch file, not a blog post you read once.
1. The "Explain This Manifest Before It Bites Me" Prompt
Task: auditing a YAML file you inherited or generated, before it reaches a cluster.
You are a Kubernetes SRE reviewing a manifest for production readiness.
Analyze the YAML below against these criteria and output a table:
| Line | Issue | Severity (blocker/warning/nit) | Fix |
Check specifically:
- Deprecated or removed apiVersions for the target cluster version (state it).
- Missing resource requests/limits, or limits set without requests.
- Probes: are liveness and readiness both present and meaningfully different?
- SecurityContext: runAsNonRoot, readOnlyRootFilesystem, dropped capabilities.
- PodDisruptionBudget presence for multi-replica workloads.
- Any field that does not exist in the official API reference — flag it as INVALID, do not guess a replacement.
Manifest:
<paste yaml>
The critical instruction is the last bullet. Left unchecked, models will happily "fix" a typo by inventing a plausible-looking field. Forcing the model to label unknown fields as INVALID instead of silently correcting them keeps you honest.
Case study: A team migrating from extensions/v1beta1 Ingress discovered four manifests still using the removed API. The prompt caught them in review instead of at kubectl apply, where the error message is a single unhelpful line about no matches for kind.
2. The Terraform Module Skeleton Prompt
Task: scaffolding a reusable module that won't embarrass you in a code review.
Write a Terraform module for <resource, e.g. an AWS EKS node group>.
Requirements:
- Terraform >= 1.6, AWS provider >= 5.0.
- variables.tf with descriptions, types, and sensible defaults.
- outputs.tf exposing only what a caller needs.
- Use `validation` blocks for at least two variables.
- No hardcoded region, account ID, or AMI — everything parameterized.
- Include a `versions.tf` with required_providers.
- Add a README.md with a minimal working example.
Do not invent provider arguments. If unsure whether an argument exists,
write a comment `# VERIFY: <argument>` instead of using it.
The # VERIFY: convention is the single most useful trick in this whole article. It converts the model's uncertainty into a grep-able marker you can check against the official provider docs at registry.terraform.io in seconds.
Case study: Generating an EKS node group module from scratch took ~40 minutes of manual doc-reading. With the prompt, the first draft was usable in under five minutes, with three # VERIFY: comments that took another four minutes to confirm.
3. The State Surgery Assistant Prompt
Task: moving resources between states or workspaces without breaking production.
I need to move a resource in Terraform state. Current situation:
- Resource address now: <old address>
- Desired address: <new address>
- Backend: <e.g. S3 + DynamoDB lock>
Give me the exact sequence of commands, in order, including:
1. A state backup step I can roll back to.
2. The `terraform state mv` command with correct quoting.
3. A `terraform plan` I should expect to show zero changes afterward.
4. What to do if the plan shows destroy/create instead of a move.
Do not tell me to edit the state file by hand.
The last line matters. Models love suggesting `terraform state pull
| jq | terraform state push`, which works until it doesn't and you've corrupted a state file in a locked backend. Explicitly forbidding manual edits keeps the advice safe.
Case study: Refactoring a monolithic root module into child modules required moving 30+ resources. Doing it manually is error-prone; the model produced the full state mv sequence with correct escaping, and every plan came back clean.
4. The "Why Is This Pod Not Scheduling" Debugger
Task: turning a wall of kubectl describe output into an actual diagnosis.
A pod is stuck. Here is the output of:
- `kubectl get pod -o wide`
- `kubectl describe pod <name>`
- `kubectl get events --sort-by=.lastTimestamp`
<outputs>
Diagnose the root cause. Rank the three most likely causes.
For each, give the exact command to confirm or rule it out.
Then give the fix as a diff to the relevant manifest or a node-level action.
Do not suggest changing anything until a cause is confirmed.
"Do not suggest changing anything until a cause is confirmed" is what stops the model from recommending a cluster rebuild for what is actually a taint on one node.
5. The Helm-to-Kustomize Migration Prompt
Task: escaping a Helm chart you no longer control.
I want to migrate from a Helm chart to Kustomize for <app>.
Given this values.yaml and the rendered output of `helm template`,
produce:
- A base/ directory with the raw manifests.
- Overlays for dev/staging/prod with only the differences.
- A kustomization.yaml per directory.
- A list of values that had no effect in the original chart (dead config).
Flag any Helm-specific templating (e.g. `{{ .Values.x }}` inside annotations)
that has no Kustomize equivalent.
The "dead config" list is the sleeper feature — teams routinely carry values that stopped mattering two chart versions ago.
6. The CI/CD Pipeline Reviewer Prompt
Task: catching the pipeline that will fail at 3 AM on a Friday.
Review this CI/CD pipeline (GitHub Actions / GitLab CI) for reliability.
<yaml>
Check for:
- Missing concurrency controls (two deploys racing).
- Secrets echoed to logs or available to untrusted PRs.
- Jobs that assume a clean runner but mutate global state.
- No timeout on steps that can hang.
- Cache keys that never invalidate.
- Deploy step with no rollback path.
Output findings as a table, then rewrite the pipeline with fixes applied.
Case study: A pipeline used pull_request_target with a checkout of the PR head — a known privilege-escalation pattern. The reviewer caught it immediately; the fix was a two-line change with outsized security impact.
7. The Cost-Diff Prompt
Task: understanding what a plan change will cost before it ships.
Here is `terraform plan` output for a change to production.
<plan>
Estimate the monthly cost delta in USD, grouped by resource type.
State your assumptions (region, instance type pricing) explicitly.
Flag any change that creates a resource with no upper bound
(e.g. autoscaling with no max, unbounded log retention).
If you cannot estimate a resource, say so — do not guess.
Cloud pricing changes; the model's numbers will drift. The value here is not the exact dollar figure but the shape of the change — spotting the unbounded autoscaler before finance does.
8. The Runbook Generator Prompt
Task: writing the on-call doc you'll wish existed at 2 AM.
Write a runbook for the failure mode: <e.g. etcd quorum loss>.
Format:
## Symptoms
## Immediate triage (commands)
## Decision tree
## Mitigation steps
## Recovery verification
## Post-incident follow-ups
Use only commands that exist in the current stable Kubernetes release.
For any destructive step, add a WARNING line and a pre-check command.
The pre-check requirement is what separates a runbook from a foot-gun. "Run etcdctl member remove" is dangerous advice without "first confirm the member is actually down."
9. The Policy-as-Code Prompt (OPA / Kyverno)
Task: encoding your team's rules so humans stop being the enforcement mechanism.
Write a Kyverno ClusterPolicy that:
- Denies pods without resource limits in namespaces labeled `env=prod`.
- Requires `runAsNonRoot: true` on all containers.
- Warns (does not deny) on images using the `:latest` tag.
Provide the policy, a test manifest that should be denied,
and a test manifest that should pass.
Explain what a user sees when denied.
10. The "Explain This to My Manager" Prompt
Task: translating an incident or architecture decision for non-engineers.
Explain the following technical event to a non-technical stakeholder
in under 200 words. No jargon. Include: what happened, what the impact was,
what we did, and what we're doing to prevent recurrence.
<incident summary>
Underrated and genuinely useful. The ability to produce a clear stakeholder summary is half of what makes an engineer promotable.
The Pattern Behind the Prompts
Look at the ten prompts and a shape emerges. Every one does three things: it constrains the model's confidence ("do not guess," "mark as VERIFY," "say so if you can't"), it demands a verifiable artifact (a table, a diff, a command sequence), and it names the failure mode it's trying to prevent. That's the entire game. A prompt that says "help me with Kubernetes" gets you a tutorial. A prompt that says "diagnose this, rank causes, give me a command to confirm each, don't change anything until confirmed" gets you a colleague.
A few habits worth building around all of this. Keep the model's output in version control next to the code it describes — a runbook in a chat window is a runbook that doesn't exist. Always cross-check generated apiVersion values and provider arguments against the official docs at kubernetes.io and registry.terraform.io; the model is a fast first draft, not a source of truth. And treat every # VERIFY: you don't check as a future incident.
The cluster you run alone doesn't have to feel like it. It has to feel like you have a very fast, very well-read teammate who occasionally hallucinates and always needs a second pair of eyes. Prompt accordingly, and the YAML stops being the job — it becomes the thing you happen to be good at.
Comments