From Dockerfile to Debugging Pods: 12 Prompts That Turn an LLM Into Your DevOps Partner

Most DevOps work isn't writing code from scratch — it's writing the same YAML, Dockerfiles, and CI pipelines for the hundredth time, then debugging them at 2 a.m. when a pod keeps restarting. An LLM is genuinely good at this kind of work: pattern-heavy, syntax-sensitive, and well-documented in its training data. The trick is asking correctly.

Below are 12 prompts covering the full cycle: Docker image building, local stacks, Kubernetes manifests, health checks, incident debugging, security audits, CI/CD, and Terraform. Each one is copy-paste ready. Drop it into ChatGPT, Claude, or any competent model, fill in the placeholders, and iterate.

Building and Shrinking Docker Images

1. Multi-stage Dockerfile from scratch

Task: you have a project and want a production-grade image, not a FROM node:latest with COPY . ..

Prompt:

Write a production multi-stage Dockerfile for a [Node.js 20 / Python 3.12 / Go 1.22] application.
Build stage: install dependencies with a lockfile, compile if needed.
Runtime stage: minimal base image, non-root user, only runtime artifacts copied.
Add .dockerignore content. Explain every stage and why the base image was chosen.
Project structure: [paste tree or describe].

Example output: a builder stage on node:20-alpine, a runtime stage on node:20-alpine with USER node, COPY --from=builder /app/dist ./dist, and an entrypoint. The model will also explain why npm ci beats npm install here.

Why it works: the model has seen thousands of these; the constraint "non-root user" and "only runtime artifacts" forces it away from the naive single-stage version.

2. Layer cache optimization

Task: builds take 6 minutes because every code change reinstalls dependencies.

Prompt:

Here is my Dockerfile. It reinstalls dependencies on every code change.
Reorder instructions so that dependency installation is cached independently of source code.
Show the before/after, explain which layer invalidates which, and flag anything that breaks caching silently (e.g. COPY . before install).
Dockerfile: [paste]

Example: moving COPY package*.json ./ and RUN npm ci above COPY . . drops rebuilds from minutes to seconds.

What to check first Ask the model to list which of your instructions bust the cache on every build. The usual culprits: COPY . . early, apt-get update without --no-install-recommends, and RUN lines that touch timestamps.

3. Image size reduction audit

Task: your image is 1.4 GB and pulls slowly in CI.

Prompt:

My image is [X] MB. Here is the Dockerfile and the output of `docker history`.
Identify the largest layers, suggest a smaller base image, and propose changes that cut size without breaking the app.
For each suggestion: estimated saving and the risk it introduces.

Example result: switching from python:3.12 (full) to python:3.12-slim, adding --no-cache-dir to pip, and using a .dockerignore to exclude .git and node_modules can cut a Python image roughly in half. The model estimates; you verify with docker images.

Trade-off to know: Alpine's musl libc breaks some prebuilt binaries (notably certain Python wheels). Slim Debian is often the safer cut.

Local Stacks and Compose

4. docker-compose for a full local environment

Task: new developers spend a day wiring up Postgres, Redis, and the app.

Prompt:

Generate a docker-compose.yml for local development with: [app, Postgres 16, Redis 7, a worker, optional Mailhog].
Requirements: named volumes for data, healthchecks with depends_on conditions, .env-driven secrets, ports only exposed where needed.
Add a short README section on how to start, reset, and tear down.

Example: depends_on: postgres: condition: service_healthy prevents the app from crashing on startup before the database accepts connections — a classic first-run failure.

Key distinction Compose healthchecks are not Kubernetes probes. condition: service_healthy only works in Compose v2 with the long-form depends_on. If you paste a Kubernetes-style readinessProbe into Compose, it silently does nothing.

Kubernetes Manifests

5. Deployment, Service, and Ingress together

Task: you need a coherent set of manifests, not three disconnected snippets.

Prompt:

Write Kubernetes manifests for a stateless web app:
- Deployment: 3 replicas, resource requests/limits, rolling update strategy, labels
- Service: ClusterIP
- Ingress: host [app.example.com], TLS via cert-manager
Use a consistent label scheme (app.kubernetes.io/*).
Explain how the Service selector connects to the Deployment labels.

Example: the model produces app.kubernetes.io/name: myapp on both Deployment pods and the Service selector — the most common silent misconfiguration is a label mismatch that leaves the Service with zero endpoints.

6. HPA with sane thresholds

Task: autoscaling that doesn't thrash.

Prompt:

Create an HPA for [deployment] targeting 70% CPU, min 2, max 10 replicas.
Explain why the Deployment MUST have resource requests set for HPA to work, and what happens if they are missing.
Add a behavior block that limits scale-down rate.

Example: without resources.requests.cpu, the HPA reports <unknown> for utilization and never scales. The behavior.scaleDown.stabilizationWindowSeconds prevents flapping after a traffic spike.

Health Checks and Incidents

7. Liveness and readiness probes

Task: pods restart randomly or receive traffic before they're ready.

Prompt:

My app is [framework], startup takes ~[N] seconds, health endpoint at [/healthz].
Design liveness, readiness, and startup probes with initialDelaySeconds, periodSeconds, failureThreshold.
Explain the difference between liveness and readiness in terms of what Kubernetes does when each fails.

Example: a readiness probe failing removes the pod from Service endpoints; a liveness probe failing restarts the container. Mixing them up — putting a slow dependency check in liveness — causes restart loops under load.

8. CrashLoopBackOff diagnosis

Task: a pod keeps restarting and you have logs and kubectl describe output.

Prompt:

Diagnose this CrashLoopBackOff.
Here are the last 50 log lines and the Events section from `kubectl describe pod`:
[logs]
[events]
List the most likely causes ranked by probability, what each would look like in the evidence, and the exact next command to confirm.

Example: exit code 1 with OOMKilled in the last state means the container hit its memory limit — the fix is raising resources.limits.memory or fixing a leak, not restarting the deployment.

Where people go wrong Pasting only the logs. Events carry the reason (OOMKilled, Error, Completed) and the exit code — without them the model guesses.

9. ImagePullBackOff

Task: the pod never starts because the image can't be pulled.

Prompt:

Pod is in ImagePullBackOff. Events:
[events]
Image: [registry/image:tag]. Cluster: [managed cloud / self-hosted].
List the causes (wrong tag, missing imagePullSecret, registry auth, private network), and give the command to verify each.

Example: 401 Unauthorized points to a missing or expired imagePullSecret; manifest unknown points to a wrong tag. The model distinguishes them from the error string instead of suggesting a blind kubectl rollout restart.

Security and CI/CD

10. Container security audit

Task: pre-production hardening review.

Prompt:

Audit this Deployment for security:
[paste manifest]
Check: runs as non-root, readOnlyRootFilesystem, dropped capabilities, no privileged, secrets not in env plaintext, pinned image tag (no :latest).
Return a checklist with pass/fail and a fixed manifest.

Example: the model adds securityContext: {runAsNonRoot: true, allowPrivilegeEscalation: false, capabilities: {drop: [ALL]}} and flags secrets passed as plain env vars, recommending a Secret reference or external store.

11. GitHub Actions / GitLab CI pipeline

Task: build, test, scan, push, deploy — with caching.

Prompt:

Write a [GitHub Actions / GitLab CI] pipeline for a [stack] app:
stages: lint, test, build image, scan (Trivy), push to [registry], deploy to [k8s].
Use layer caching for Docker builds, pin action versions, run on PRs and main only.
Explain how secrets are injected safely.

Example: docker/build-push-action with cache-from: type=gha cuts CI build time noticeably; pinning actions to a commit SHA avoids supply-chain drift from mutable tags.

12. Terraform module for cluster resources

Task: infrastructure that's reviewable and reusable.

Prompt:

Write a Terraform module for [EKS / GKE / AKS] with a node group, variables for instance type and desired size, output kubeconfig context.
Follow best practices: variables with types and descriptions, no hardcoded values, remote state note.

Example: the model returns variables.tf, main.tf, outputs.tf, and a README — with instance_type typed and defaulted rather than hardcoded inside the resource.

How to Use These Without Getting Burned

An LLM writes plausible YAML fast, but it does not know your cluster. Treat its output as a first draft with a strong prior — usually correct on syntax, occasionally wrong on your specific version or cloud provider.

Prompt Best for Verify with
1–3 Dockerfile New images, size and cache docker build, docker history
4 Compose Local onboarding docker compose up
5–6 Manifests Standard workloads kubectl apply --dry-run=server
7–9 Debugging Live incidents kubectl describe, logs --previous
10–12 Security, CI, IaC Hardening and pipelines trivy, terraform plan, pipeline run

Three habits that separate useful results from garbage:

  1. Always paste real evidence. Logs, events, exit codes, and docker history output beat descriptions. The model reasons from data far better than from adjectives.
  2. Ask for the reasoning, not just the answer. "Explain why this layer invalidates the cache" surfaces wrong assumptions before you deploy them.
  3. Run dry first. kubectl apply --dry-run=server and terraform plan catch most hallucinated fields before they reach the cluster.

Non-obvious insight: the highest-value prompts are the diagnostic ones (8, 9). Writing a manifest is a solved problem most engineers can do; reading a wall of events at 2 a.m. and picking the right next command is where an LLM saves real time — because it doesn't get tired and it doesn't skip the boring parts of the evidence.

If you're building broader AI-assisted workflows, the same principle applies to code review and to frontend work — the prompt does the heavy lifting, and your judgment does the verification. The 12 prompts above cover the pipeline end to end: copy the one that matches your current blocker, fill in the placeholders, and keep the output as a draft you check, not a decree you trust.

← All posts

Ask AI about this article

Ask a question about this article — ASI Biont will answer based on its text.