Taming the Beast: 12 Battle-Tested Prompts That Keep Kubernetes Deployments, Debugging, and Security Under Control

Kubernetes rewards precision and punishes improvisation. A missing resource limit, a NetworkPolicy with the wrong selector, or an HPA that scales on the wrong metric can turn a calm Friday into a pager storm. ChatGPT won't run kubectl for you, but it can compress hours of manifest writing, log archaeology, and security review into minutes — if you ask the right way.

Below are 12 prompts I use as a DevOps engineer, grouped into three tiers: basic (day-to-day manifests), advanced (debugging and autoscaling), and expert (Helm, DevSecOps, policy). Each comes with the exact request, expected output, and the caveat that keeps you in control. Treat every answer as a draft to review, never as a merge request rubber stamp.

Basic Tier: Manifests Without the Boilerplate

1. Production-Ready Deployment from a One-Liner

Task: generate a Deployment with probes, limits, and security context.
Prompt: "Write a Kubernetes Deployment for a Node.js 20 service named payments-api on port 8080. Include liveness and readiness probes on /healthz, resource requests/limits (250m/512Mi and 500m/1Gi), runAsNonRoot: true, readOnlyRootFilesystem: true, and three replicas with topologySpreadConstraints across zones."
Result: a complete YAML with securityContext, resources, and topologySpreadConstraints using topologyKey: topology.kubernetes.io/zone. Verify probe paths against your actual app — a wrong path causes restart loops, not health.

2. ConfigMap and Secret Split Done Right

Task: separate non-sensitive config from secrets.
Prompt: "Take this env list and split it into a ConfigMap and a Secret. Secrets must use stringData for authoring but I want to know how to seal them with kubeseal afterward. Show envFrom wiring."
Result: two manifests plus a note that stringData is write-only convenience and base64 in data is encoding, not encryption. Point the model at Sealed Secrets or External Secrets Operator for Git-safe storage.

3. Resource Requests Calibrated to Reality

Task: avoid the classic over-request.
Prompt: "Here are kubectl top pod outputs for a week. Suggest requests and limits. Explain the difference between CPU throttling and OOMKilled and which one my 90th percentile data implies."
Result: a table of suggested values with reasoning. CPU limits cause throttling (see the kernel's CFS quota behavior), memory limits cause OOM kills — the model should recommend limits on memory, requests-only on CPU for latency-sensitive services.

Advanced Tier: Debugging and Autoscaling

4. CrashLoopBackOff Triage

Task: structured diagnosis instead of guessing.
Prompt: "My pod is in CrashLoopBackOff. I'll paste kubectl describe pod output and the last 100 log lines. Give me a ranked checklist: exit code meaning, probe failures, missing env vars, image pull issues. Ask for anything you still need."
Result: exit code 137 → OOMKilled or SIGKILL; 1 → app error; Back-off restarting failed container with clean logs often means a failing liveness probe. The model should request kubectl get events --sort-by=.lastTimestamp next.

5. ImagePullBackOff and Registry Auth

Task: untangle auth vs. typo.
Prompt: "Pods fail with ErrImagePull. Walk me through distinguishing a wrong tag from a missing imagePullSecrets from a private registry rate limit, with the exact kubectl commands for each branch."
Result: commands like kubectl get pod X -o jsonpath='{.status.containerStatuses[*].state.waiting.message}' and a check of the ServiceAccount's imagePullSecrets. Concrete, copy-pasteable.

6. HPA on Custom Metrics

Task: scale on requests per second, not CPU.
Prompt: "Write an HPA v2 manifest targeting 100 req/s per pod via a Prometheus Adapter custom metric http_requests_per_second. Include the behavior block with scale-down stabilization of 300 seconds and explain why CPU-based HPA fails for I/O-bound services."
Result: autoscaling/v2 manifest with metrics[].pods.metric and behavior.scaleDown.stabilizationWindowSeconds: 300. Reminder: the metric must exist in the adapter's rules config first.

7. NetworkPolicy That Doesn't Break DNS

Task: default-deny without shooting yourself in the foot.
Prompt: "Create a default-deny ingress/egress policy for namespace backend, then allow: ingress from frontend on 8080, egress to postgres on 5432, and DNS to kube-system on 53 UDP/TCP. Explain why DNS egress is the #1 cause of mysterious timeouts."
Result: three policies with podSelector, namespaceSelector, and ports. The DNS allowance uses namespaceSelector matching kubernetes.io/metadata.name: kube-system. Test with kubectl exec ... -- nc -zv before rollout.

Expert Tier: Helm, CI/CD, and DevSecOps

8. Helm Chart Skeleton with Values Discipline

Task: scaffold a chart that won't rot.
Prompt: "Generate a Helm chart for a stateless web app: Chart.yaml, values.yaml, deployment, service, ingress, HPA, and _helpers.tpl. Use helm lint-clean conventions, quote all values in templates, and add a NOTES.txt. Explain helm template vs helm install --dry-run for CI."
Result: a chart tree plus the reminder that helm template renders locally while --dry-run=server validates against the API server's admission chain.

9. CI/CD Pipeline with Rollback Gate

Task: deploy with a safety net.
Prompt: "Write a GitHub Actions workflow: build image, push to GHCR, helm upgrade --install --atomic --timeout 5m, then kubectl rollout status. Add automatic helm rollback on failure and explain what --atomic actually does."
Result: a workflow using azure/setup-helm and --atomic, which rolls back on failed upgrade automatically. The model should mention --wait semantics and why rollout status is still worth a step.

10. Manifest Security Review

Task: catch privileged containers before the audit does.
Prompt: "Audit this manifest against the NSA/CISA Kubernetes Hardening Guide and Pod Security Standards restricted profile. Flag: privileged, hostPath, hostNetwork, missing seccompProfile, capabilities, and writable root FS. Return a table with severity and fix."
Result: a findings table referencing Pod Security Standards and the NSA/CISA guide. Pair with kubesec or Trivy in CI for deterministic checks.

11. RBAC Least Privilege

Task: a ServiceAccount that can only read what it needs.
Prompt: "Create a Role and RoleBinding so ci-deployer can only get,list,watch pods and patch deployments in namespace staging. Explain why ClusterRole for this is a smell and how kubectl auth can-i --as verifies it."
Result: namespaced Role plus the impersonation check kubectl auth can-i patch deployments -n staging --as=system:serviceaccount:staging:ci-deployer.

12. Incident Postmortem Skeleton from Events

Task: turn chaos into a document.
Prompt: "Given these kubectl get events and deployment history entries, draft a blameless postmortem: timeline, impact, root cause hypothesis, detection gaps, and three preventive actions with owners as placeholders."
Result: a structured markdown postmortem. The model should separate facts from hypotheses — verify timestamps against your monitoring before publishing.

What Actually Matters

Use these as accelerators, not autopilot. Always run kubectl diff, helm template, and a policy engine like Kyverno or OPA Gatekeeper on whatever the model produces. The engineer who reviews still owns the cluster — the prompt just buys back the evening.