DevOps Prompts That Tame the YAML Beast: AI Workflows for CI/CD, Docker, Kubernetes, and Terraform

DevOps Prompts That Tame the YAML Beast: AI Workflows for CI/CD, Docker, Kubernetes, and Terraform

Nobody becomes a DevOps engineer because they love indentation. YAML's significance is whitespace, and a single misplaced space can take down a deploy at 2 a.m. That's why LLM assistants became so popular in platform teams: they generate boilerplate, explain cryptic errors, and translate intent into manifests faster than any snippet manager. But there's a catch — models hallucinate deprecated APIs, invent Helm values, and confidently produce apiVersion: apps/v1beta1 like it's still 2018.

This collection is built on a simple principle: treat the model as a fast junior engineer who never gets tired but always needs review. Every prompt below includes context you must supply, a concrete example, and the official source you should validate against. Commands and manifests are real and runnable; where APIs change between versions, I say so explicitly. The goal isn't to replace your judgment — it's to remove the boring 80% so you can focus on architecture.

A quick note on safety: never paste production secrets, kubeconfigs, or customer data into a chat model. Use placeholders, redact values, and keep credentials in your secret manager. With that out of the way, let's start with the basics.

Tier 1: Basic — From Zero to a Working Pipeline

1. Generate a GitHub Actions CI pipeline from scratch

Task: You have a Python or Node repo with no CI, and you need lint, test, and build stages.

Prompt:

You are a senior DevOps engineer. Generate a GitHub Actions workflow for a
Python 3.12 project using Poetry, with jobs: lint (ruff), test (pytest with
coverage), and build (docker image pushed to GHCR on tags only).
Use official actions with pinned major versions. Add caching for Poetry.
Output a single .github/workflows/ci.yml and explain each non-obvious line.

Example result (excerpt):

name: ci
on:
  push:
    branches: [main]
    tags: ['v*']
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pipx install poetry
      - run: poetry install --no-interaction
      - run: poetry run pytest --cov

Validate against the official docs at docs.github.com/en/actions. Ask the model to pin actions to major versions, not @master — floating refs are a supply-chain risk.

2. Explain a failing pipeline log

Task: CI fails with an opaque error, and you don't want to read 400 log lines.

Prompt:

Here is a failing CI log (redact secrets). Identify the root cause, the
exact file/line, and give me a minimal fix. If multiple causes are possible,
rank them by likelihood and tell me which log line proves each one.

<LOG>...</LOG>

This is the highest-ROI use of AI in DevOps: log triage. The model is genuinely good at pattern-matching stack traces. It is not good at knowing your private infrastructure — so always include the relevant config.

3. Turn a Dockerfile into a multi-stage build

Task: A naive Dockerfile ships build tools into production, bloating the image.

Prompt:

Rewrite this Dockerfile as a multi-stage build for a Go 1.22 app.
Goals: final image based on gcr.io/distroless/static, non-root user,
no build cache in final layer, reproducible build with -trimpath.
Explain the size impact of each change.

Result: Two stages — golang:1.22 for compilation, distroless for runtime. A typical Go binary drops from ~800 MB (full toolchain) to under 20 MB. Distroless images have no shell, which also reduces attack surface.

4. Generate a .dockerignore

Task: Builds are slow because the context includes node_modules and .git.

Prompt:

Generate a .dockerignore for a Node.js + TypeScript monorepo.
Include build artifacts, IDE folders, and secrets patterns.
Add a one-line comment explaining why each group is excluded.

Small prompt, real gains: Docker sends the entire context to the daemon before building, so excluding node_modules can cut build time dramatically on large repos.

5. Write a docker-compose.yml for local development

Task: You need a reproducible local stack: app, Postgres, Redis.

Prompt:

Write a docker-compose.yml for local dev: app (build from ./),
postgres:16-alpine, redis:7-alpine. Use named volumes, healthchecks,
and depends_on with condition: service_healthy. Add .env.example.
Do NOT use the deprecated top-level `version:` key.

Why it matters: Since Compose Spec, the version field is obsolete — many models still emit it. Healthchecks plus condition: service_healthy prevent the classic "app starts before DB is ready" race. Reference: docs.docker.com/compose/compose-file.

Tier 2: Advanced — Kubernetes, Terraform, and Secrets

6. Generate a Kubernetes Deployment with probes and limits

Task: You need a production-grade manifest, not a toy example.

Prompt:

Create a Kubernetes Deployment + Service for a stateless HTTP API.
Requirements: 3 replicas, liveness/readiness/startup probes,
resource requests and limits, securityContext (runAsNonRoot, readOnlyRootFilesystem),
PodDisruptionBudget, and topologySpreadConstraints across zones.
Use apiVersion apps/v1 and explain every field.

Example result (excerpt):

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  template:
    spec:
      securityContext:
        runAsNonRoot: true
      containers:
        - name: api
          readinessProbe:
            httpGet: { path: /healthz, port: 8080 }
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits:   { cpu: 500m, memory: 256Mi }

Caveat: readOnlyRootFilesystem: true breaks apps that write temp files. The model will happily add it; you must verify. Validate manifests with kubectl apply --dry-run=server and kubeconform. Reference: kubernetes.io/docs/concepts/configuration.

7. Translate a Helm values.yaml into plain manifests

Task: You inherited a chart and need to understand what it actually deploys.

Prompt:

Given this Helm chart (values.yaml + templates), render the effective
manifests for env=prod and explain the resulting resource requests,
replica counts, and any conditional logic. Flag values that look like
defaults you should override.

Helm's templating is where YAML becomes a programming language, and that's exactly where humans lose track. AI is excellent at flattening conditionals into a readable summary.

8. Terraform module for a VPC (AWS)

Task: You need Infrastructure as Code (IaC) that follows best practices.

Prompt:

Write a reusable Terraform module for an AWS VPC using the official
terraform-aws-modules/vpc style: 3 AZs, public/private subnets, NAT gateway,
flow logs enabled. Pin the AWS provider to ~> 5.0. Output a variables.tf,
main.tf, outputs.tf and a usage example. Explain cost implications of NAT.

Reality check: NAT Gateways are billed hourly plus per GB processed — a detail AI often omits unless asked. Always run terraform plan and review the diff; never apply unreviewed AI output. Reference: developer.hashicorp.com/terraform.

9. Convert a kubectl command into a manifest

Task: You built something imperatively and want it as code.

Prompt:

I ran: kubectl create deployment web --image=nginx --replicas=3
Show me the equivalent YAML, cleaned up: add resource limits,
remove status and metadata noise (uid, resourceVersion, creationTimestamp).

Use kubectl get deploy web -o yaml --export is deprecated — instead ask the model to strip status and server-managed fields manually, or use tools like kubectl-neat.

10. Secrets management strategy

Task: You need to stop putting secrets in Git.

Prompt:

Compare three approaches for Kubernetes secrets: Sealed Secrets,
External Secrets Operator with AWS Secrets Manager, and SOPS with age.
For each: threat model, operational overhead, GitOps compatibility.
Recommend one for a small team on EKS and justify it.

Result: A decision table. Note honestly: this is a design question without a single right answer, and the model's recommendation should be treated as a starting point for team discussion, not gospel.

Tier 3: Expert — Observability, Cost, and Incident Response

11. Prometheus alerting rules from SLOs

Task: Turn an SLO into actionable alerts, not noise.

Prompt:

Write Prometheus alerting rules for a 99.9% availability SLO on an HTTP API.
Use multi-window multi-burn-rate alerts (fast burn 14.4x over 1h, slow burn 6x over 6h).
Output valid PromQL and explain the math behind each threshold.

Why this is expert-level: Burn-rate alerting is the Google SRE approach and dramatically reduces false pages compared to static thresholds. The math (error_budget, burn rate) is something AI explains well but gets subtly wrong — verify against the SRE Workbook.

12. Diagnose a CrashLoopBackOff

Task: A pod won't start and you have limited time.

Prompt:

Pod is in CrashLoopBackOff. Here's `kubectl describe pod` output and
last 50 log lines. Give me a ranked differential diagnosis, the exact
next command to run for each hypothesis, and the most likely fix.

Result: A triage tree — OOMKilled (check Last State: Terminated, Reason: OOMKilled), bad config map mount, failing readiness probe, missing secret. This is where AI genuinely saves on-call time.

13. Cost optimization review

Task: Your cloud bill grew and nobody knows why.

Prompt:

Review this list of Kubernetes workloads (requests/limits, node types)
and suggest cost optimizations: right-sizing, spot instances for stateless
work, HPA/VPA settings, and identifying over-provisioned requests.
Quantify potential savings as ranges, not exact figures.

Caveat: Ask for ranges, not precise percentages — precise savings claims from a model that can't see your billing data are fiction.

14. Generate a runbook from an incident

Task: Post-incident, you need documentation before memory fades.

Prompt:

Turn this incident timeline into a runbook: symptoms, detection signal,
mitigation steps, root cause, and prevention actions. Format as Markdown
with a checklist a junior on-call engineer can follow at 3 a.m.

Documentation is the task engineers postpone most. AI turns a messy Slack thread into a structured runbook in minutes.

15. GitOps repo structure review

Task: Your Argo CD repo is a mess of environments and overlays.

Prompt:

Review this directory tree for a GitOps repo (Argo CD + Kustomize).
Suggest a structure that scales to 3 environments and 20 services.
Explain trade-offs between app-of-apps and ApplicationSets.

Result: A recommended layout with base/ and overlays/ per environment, plus a note that ApplicationSets reduce duplication for many similar services. Reference: argo-cd.readthedocs.io.

16. Security scan integration

Task: You want image and IaC scanning in CI.

Prompt:

Add Trivy image scanning and Checkov IaC scanning to this GitHub Actions
workflow. Fail the build on HIGH/CRITICAL vulnerabilities. Add a
scheduled weekly full scan. Explain how to handle false positives
without disabling the gate entirely.

Result: Two jobs with aquasecurity/trivy-action and bridgecrewio/checkov-action, plus an allowlist file. A practical point AI often misses: a gate with no exception process gets disabled by frustrated engineers within weeks.

A Reality-Check Table: What AI Does Well vs. Where It Fails

Practical Rules for Using These Prompts

Always pin versions in your prompt. "Kubernetes 1.30", "Terraform 1.9", "Postgres 16" — otherwise you get whatever the model's training data favored.

Always validate. kubeconform, terraform validate, docker build --check, actionlint. Never merge AI-generated infra without a dry run.

Never paste secrets. Use <REDACTED> placeholders.

Ask for explanations, not just output. A manifest you don't understand is a future incident.

Where to Go Next

The real value of AI in DevOps isn't generating YAML faster — it's compressing the loop between "I have an idea" and "it's running in staging." The engineers who benefit most treat the model as a tireless pair who never reads the changelog, and therefore always gets a second opinion from the official docs.

Start with one prompt from Tier 1 today. Pick your messiest pipeline, ask the model to explain it, then ask it to improve one thing. If you want a structured path through CI/CD, containerization, Kubernetes, and IaC — with AI-assisted practice rather than passive reading — explore the DevOps track at asibiont.com/blog and build the habit of validating every generated line.