Kubernetes and CI/CD Prompts: 12 Battle-Tested Scenarios That Quietly Replace the On-Call DevOps Engineer

Kubernetes and CI/CD Prompts: 12 Battle-Tested Scenarios That Quietly Replace the On-Call DevOps Engineer

It's 3:14 AM. PagerDuty fires. A deployment is stuck in CrashLoopBackOff, the Helm release is half-applied, and the on-call engineer is squinting at kubectl describe pod output through tired eyes. This is the reality of modern platform work — and it's exactly the kind of repetitive, high-context task where a well-crafted prompt to a large language model changes the game.

This isn't about "AI replacing DevOps." It's about something more subtle: LLMs are exceptionally good at pattern recognition across logs, YAML, and manifests — the exact material DevOps engineers drown in. A good prompt compresses an hour of tribal-knowledge-driven debugging into a structured first draft you can verify in minutes.

Below are 12 scenarios I've collected and stress-tested across Kubernetes, GitOps, and CI/CD workflows. Each one includes the task, the actual prompt, and a realistic example result. Treat the outputs as drafts to verify, never as unvetted production changes. Kubernetes documentation (kubernetes.io), the Helm docs (helm.sh), and the GitOps principles from the OpenGitOps project are your ground truth.

1. Diagnosing a CrashLoopBackOff from Raw Logs

Task: Turn a blob of kubectl output into a ranked list of probable causes with next diagnostic commands.

Prompt:

You are a senior Kubernetes SRE. Below is output from `kubectl describe pod`
and the last 50 log lines. Identify the most likely root cause of the
CrashLoopBackOff. Rank hypotheses by probability. For each, give the exact
kubectl or shell command to confirm it.

[paste logs here]

Example result: The model correctly identified that the container was exiting with code 1 due to a missing DATABASE_URL env var, then suggested kubectl exec -it <pod> -- env | grep DATABASE and checking the referenced Secret with kubectl get secret <name> -o jsonpath='{.data}'. The real win: it noticed the livenessProbe was hitting /health before the app finished migrations — a classic race condition.

Why it works: LLMs excel at correlating exit codes, probe configs, and log timestamps. You still verify — but you skip the first 10 minutes of manual grep.

2. Writing a Production-Ready Dockerfile for a Node.js Service

Task: Generate a multi-stage Dockerfile with security defaults.

Prompt:

Write a multi-stage Dockerfile for a Node.js 20 Express API.
Requirements:
- Final image based on node:20-alpine
- Non-root user (uid 1001)
- Only production dependencies in final layer
- Use `npm ci` not `npm install`
- Add a HEALTHCHECK using wget
- Explain each stage in a comment

Example result: Produces a two-stage build (builder → runtime), copies only node_modules and dist, sets USER 1001, and adds HEALTHCHECK CMD wget -qO- http://localhost:3000/health || exit 1. It also warns that Alpine's musl libc can break native modules — a nuance beginners miss.

3. Converting Imperative kubectl Commands into Declarative Manifests

Task: Reverse-engineer YAML from a set of ad-hoc commands.

Prompt:

Convert these imperative commands into a single multi-document YAML manifest.
Add resource requests/limits that seem reasonable and flag any assumptions.

kubectl create deployment web --image=nginx:1.27 --replicas=3
kubectl expose deployment web --port=80 --target-port=80

Example result: Returns a Deployment + Service pair, adds resources.requests.cpu: 100m, and explicitly flags: "I assumed a ClusterIP Service; change to LoadBalancer if external access is needed." The honest assumption-flagging is what separates a usable draft from a trap.

4. Generating a Helm Chart Skeleton with Values Schema

Task: Scaffold a chart with values.schema.json for validation.

Prompt:

Create a Helm chart named `payments-api` for a stateless HTTP service.
Include: Chart.yaml, values.yaml with image/replicaCount/resources,
templates/deployment.yaml, templates/service.yaml, templates/_helpers.tpl,
and a values.schema.json that enforces replicaCount as integer >= 1.
Use Helm 3 conventions.

Example result: A complete, lint-clean chart. The schema uses JSON Schema draft-07 ("type": "integer", "minimum": 1) — matching what helm lint and the Helm docs expect. Run helm lint ./payments-api to confirm before committing.

5. Reviewing a GitHub Actions Workflow for Security and Speed

Task: Audit a CI pipeline for common pitfalls.

Prompt:

Review this GitHub Actions workflow. Flag: (1) unpinned actions,
(2) missing concurrency controls, (3) secrets exposed to PRs from forks,
(4) unnecessary cache misses, (5) steps that could run in parallel.
Return a prioritized list with diffs.

[paste .github/workflows/ci.yml]

Example result: Flags actions/checkout@v4 as acceptable but recommends pinning to a SHA for supply-chain hardening — consistent with GitHub's own security hardening guidance. Suggests adding:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

This alone cuts redundant CI minutes on rapid pushes.

6. Designing a GitOps Promotion Strategy Across Environments

Task: Plan dev → staging → prod promotion using Argo CD or Flux.

Prompt:

Design a GitOps promotion flow using Argo CD. We have dev, staging, prod.
Requirements: prod requires manual approval, image tags are immutable
(SHA-based), and rollbacks must be a single git revert. Explain the
repository layout and the ApplicationSet structure.

Example result: Proposes a two-repo layout (app source + config), uses ApplicationSet with a list generator for environments, and sets syncPolicy.automated only for dev/staging. For prod, it recommends syncPolicy without automated plus a manual sync — the pattern the OpenGitOps principles describe as "declarative, versioned, pulled, continuously reconciled."

7. Writing a Terraform Module for an EKS Node Group

Task: Infrastructure-as-code for a managed node group.

Prompt:

Write a reusable Terraform module (v1.9+) for an AWS EKS managed node group.
Inputs: cluster_name, instance_types, min/max/desired size, subnet_ids.
Use the official terraform-aws-modules/eks conventions where possible.
Add tags for cost allocation.

Example result: Generates main.tf, variables.tf, outputs.tf, and versions.tf pinning required_version = ">= 1.9.0". It correctly uses aws_eks_node_group and warns about the desired_size vs. Cluster Autoscaler interaction — a real operational gotcha.

8. Explaining a Rejected Pod with Taints and Tolerations

Task: Debug scheduling failures.

Prompt:

This pod is stuck Pending. Events show:
"0/5 nodes are available: 3 node(s) had untolerated taint {workload: gpu}."
Explain what's happening and give me two fixes: one using a toleration,
one using nodeAffinity. Show the YAML.

Example result: Clearly distinguishes taints (repel) from tolerations (allow) — a distinction the official Kubernetes docs emphasize. Provides a tolerations block and, as an alternative, a nodeAffinity requiredDuringSchedulingIgnoredDuringExecution selector. Genuinely educational output.

9. Creating Prometheus Alerting Rules from SLOs

Task: Translate an SLO into PromQL alerts.

Prompt:

We have an SLO: 99.9% of HTTP requests to the `api` service must succeed
over 30 days. Write Prometheus alerting rules that fire on fast burn
(2% budget in 1h) and slow burn (5% budget in 6h).
Use the multi-window multi-burn-rate pattern from the Google SRE workbook.

Example result: Produces correct record and alert rules using rate(http_requests_total{code=~"5.."}[5m]) divided by total. The multi-window burn-rate approach is documented in the Google SRE Workbook — cite it when you file the PR so reviewers trust the math.

10. Writing a Kubernetes NetworkPolicy to Lock Down Egress

Task: Default-deny egress with explicit allowlist.

Prompt:

Write a NetworkPolicy for namespace `payments` that:
- denies all egress by default
- allows DNS to kube-system
- allows HTTPS (443) to CIDR 10.0.0.0/8
Explain why DNS must be explicitly allowed.

Example result: Correctly notes that once you select pods with an egress policy, all egress is denied until allowed — including DNS. Provides the kube-system allow rule on port 53 (UDP and TCP). This is a mistake many teams make exactly once, at 2 AM.

11. Optimizing a Slow CI Pipeline

Task: Identify bottlenecks and parallelize.

Prompt:

Here is our CI pipeline config. It takes 22 minutes. Identify the top 5
bottlenecks and propose concrete changes (parallel jobs, caching, matrix
builds). Estimate the time saved for each change.

[paste config]

Example result: Flags sequential test suites that could run as a matrix, a missing actions/cache for ~/.npm, and a Docker build without BuildKit cache mounts. Suggests docker/build-push-action with cache-from: type=gha. Honest caveat: estimates are directional, not guarantees.

12. Drafting a Runbook for a Rolling Deployment Rollback

Task: A copy-pasteable operational runbook.

Prompt:

Write a runbook for rolling back a failed production deployment on
Kubernetes with Helm. Include: detection signals, decision criteria,
the exact helm rollback command, how to verify, and a post-incident step.
Keep it under one page. Use numbered steps.

Example result: Produces helm history <release>, then helm rollback <release> <revision>, followed by kubectl rollout status deployment/<name>. It suggests verifying with kubectl get pods -w and checking the readiness probes. A solid starting draft you'd adapt to your environment.

Common Mistakes When Prompting for DevOps Work

Why This Works (and Where It Doesn't)

The strength of these prompts is compression of context. Kubernetes manifests, CI configs, and logs are highly structured — perfect for models trained on vast amounts of public code. The weakness is hallucination of API fields and versions. Always validate against the official Kubernetes API reference and Helm documentation. Never apply a generated manifest to production without a server-side dry run.

Think of the LLM as a very fast, very well-read junior engineer who never sleeps but occasionally invents a field that doesn't exist. Your job shifts from writing to reviewing — a higher-leverage position.

If you want to go deeper into Kubernetes, GitOps, and CI/CD automation — including how to structure these workflows end to end — the asibiont.com blog and course catalog cover the practical foundations. Start with the runbook prompt above, adapt it to your stack, and watch how much of that 3 AM toil quietly disappears.