Docker, Kubernetes and CI/CD Under AI Control: 12 DevOps Prompts That Actually Ship Code

Docker, Kubernetes and CI/CD Under AI Control: 12 DevOps Prompts That Actually Ship Code

Most DevOps frustration isn't writing YAML — it's writing the right YAML the first time. A missing readinessProbe, a latest tag in production, a Terraform plan that quietly deletes a subnet: these are small details with expensive consequences. An LLM won't replace kubectl or your judgment, but it can produce a solid first draft in seconds — if you ask precisely.

The prompts below are built around one principle: make the model show its reasoning and cite the reference, then verify against the source. Kubernetes API reference (kubernetes.io/docs/reference), Dockerfile best practices (docs.docker.com/build/building/best-practices), Terraform registry docs and GitHub Actions documentation are the ground truth. Treat AI output as a pull request from a fast but overconfident junior — review it.

Below are 12 prompts for infrastructure, containers and pipelines, each with a usage example and a verification checklist.

1. Dockerfile audit against the official best-practices checklist

When to use: you inherited a fat image (800 MB+, root user, latest base) and need a prioritized fix list.

Prompt:

Act as a container security reviewer. Audit this Dockerfile against Docker's official
best practices (docs.docker.com/build/building/best-practices). For each finding:
1) line number, 2) risk (security/size/build speed), 3) concrete fix with code.
Output as a table, then a rewritten Dockerfile using a multi-stage build.
Dockerfile:
<<<
FROM python:latest
COPY . /app
RUN pip install -r /app/requirements.txt
CMD python /app/main.py
>>>

Example output fragment: the model flags python:latest (unpinned, non-reproducible), COPY . before dependency install (kills layer cache), and a root CMD. The rewrite uses python:3.12-slim as builder, pip install --no-cache-dir into a venv, then a slim runtime stage with USER app. Verify the base tag exists on Docker Hub before merging.

2. From Dockerfile to a minimal, non-root runtime image

When to use: you need a production-ready image but don't want to hand-write multi-stage logic.

Prompt:

Rewrite this Dockerfile into a two-stage build: builder installs deps, runtime is
slim and runs as UID 10001. Add a HEALTHCHECK using curl against /healthz.
Explain every instruction you add in one line. Then give the equivalent
.dockerignore file.

Tip: ask for .dockerignore explicitly — it's the most-forgotten file in the repo and the cheapest image-size win.

3. Docker Compose for local parity with a Kubernetes service

When to use: devs run Compose locally, prod runs K8s, and the two drift apart.

Prompt:

Generate docker-compose.yml for: app (build from ./app), postgres:16, redis:7.
Requirements: healthchecks for all three, app depends_on postgres with
condition: service_healthy, named volumes, .env file for secrets, no
container_name overrides. Add comments mapping each service to its future
Kubernetes Deployment/Service.

condition: service_healthy is a real Compose spec field (compose-spec.io) — good prompt detail, because without it depends_on only waits for container start, not readiness.

4. Kubernetes Deployment + Service + Ingress from a plain description

When to use: you know the app, not the manifest.

Prompt:

Write Kubernetes YAML (apps/v1, networking.k8s.io/v1) for: 3 replicas of
image registry.example.com/api:1.4.2, port 8080, env from Secret api-secrets,
CPU request 250m / limit 500m, memory 256Mi/512Mi, liveness+readiness probes
on /healthz, and an Ingress with host api.example.com and TLS.
Rules: no :latest, set runAsNonRoot: true, add resource limits, add
securityContext with readOnlyRootFilesystem. After the YAML, list every field
you set and the doc page that defines it.

Check: kubectl apply --dry-run=server -f manifest.yaml validates against the live API server's schema — the fastest catch for hallucinated fields.

5. Turn a Helm chart into a values checklist

When to use: you're reviewing a third-party chart and want to know what's tunable before touching it.

Prompt:

Given this values.yaml excerpt, produce a table: key

| type | default | what it
controls | production recommendation. Flag any key that, if changed, requires
a pod restart. Do not guess keys that are not present.

This prompt's power is the last sentence — it stops the model from inventing resources.limits.gpu.count-style keys that don't exist.

6. Terraform module review with a blast-radius report

When to use: before terraform apply touches a shared account.

Prompt:

Review this Terraform plan output (text). Classify each change as
create/update/replace/destroy. Flag: (a) any destroy of stateful resources
(RDS, S3, EBS), (b) changes to security groups opening 0.0.0.0/0,
(c) IAM policy widening. For each, give the resource address and a safer
alternative (e.g. lifecycle { prevent_destroy = true }).
Plan:
<<<
<paste plan>
>>>

Reality check: terraform plan is the source of truth; the model only reads it. Never let an LLM write a plan — it can't, and any "AI terraform apply" claim is a red flag.

7. GitHub Actions pipeline with caching and least-privilege permissions

When to use: you're writing CI from scratch and want the boring parts right.

Prompt:

Write .github/workflows/ci.yml: on pull_request to main. Jobs: lint (ruff),
test (pytest, matrix python 3.11/3.12), build (docker/build-push-action,
push only on main). Use actions/setup-python with pip cache, set
permissions: contents: read at the top, and pin every action to a major
version. Explain each job in a comment.

Verify: action names and version tags against github.com/marketplace — a hallucinated action like actions/setup-docker@v1 fails at runtime, not at review.

8. Pipeline failure triage from logs

When to use: 2 a.m., red build, 400 lines of log.

Prompt:

You are a CI debugger. Here is the failing job log. Identify the root cause,
quote the exact log line, and give 3 ranked hypotheses if ambiguous. Then write
a fix and a one-line check to confirm it. Do not suggest re-running without
stating what you expect to change.
Log:
<<<
<paste log tail>
>>>

9. Kubernetes incident triage: CrashLoopBackOff runbook

When to use: pods are cycling and you need a triage sequence, not a guess.

Prompt:

Act as an SRE on call. Pod is in CrashLoopBackOff. Give an ordered diagnostic
checklist: kubectl commands, what each output tells you, and decision branches
(image pull error vs OOMKilled vs failed probe vs bad config). Format as a
table: symptom

| command | interpretation | next step.

Expect real commands: kubectl describe pod, kubectl logs --previous, kubectl get events --sort-by=.lastTimestamp. If the model invents a flag, kubectl <cmd> --help kills the idea in seconds.

10. Right-sizing requests and limits from real usage

When to use: every pod requests 1 CPU "to be safe" and the bill shows it.

Prompt:

Here are kubectl top pod outputs for 7 days for service checkout. Recommend
CPU/memory requests and limits per container. Use P95 as request, 1.5x as
limit, explain the tradeoff between throttling and bin-packing, and give the
resulting YAML diff. State assumptions explicitly.

11. Terraform → Kubernetes handoff consistency check

When to use: infra is split between Terraform (clusters, IAM, DNS) and K8s manifests, and names drift.

Prompt:

Compare these Terraform resource names (EKS cluster, node group, IAM role,
DNS zone) with these Kubernetes manifests. List mismatches that will break
deployment: wrong cluster name in kubeconfig context, IAM role not matching
service account annotation, DNS record pointing to wrong LB. Output a
mismatch table with file and line.

12. Cost and security review of a whole namespace

When to use: monthly review, before the finance team asks.

Prompt:

Given these manifests for one namespace, produce two lists: (1) cost risks —
missing limits, oversized requests, no HPA, LoadBalancer per service;
(2) security risks — privileged containers, hostPath mounts, missing
networkPolicy, secrets in env vars instead of Secret refs. For each item:
severity, fixed snippet, and a one-line policy to prevent recurrence.

How to get reliable answers from these prompts

A pattern across all 12: the model is best at structure and checklists, weakest at exact syntax of fast-moving APIs. Use it to draft, enumerate and triage — then let kubectl, terraform and docker be the judge. Pair these with a disciplined prompt-engineering habit (explicit constraints, pasted artifacts, verification steps) and your DevOps loop shortens from hours to minutes without trading away safety. Try one prompt on your messiest manifest this week — the audit in #1 is usually the highest-return starting point.