DevOps routine looks romantic only in job postings. In reality it is a Dockerfile you rewrite for the fifth time because the image weighs 1.4 GB, a pod in CrashLoopBackOff at 2 a.m., and a Terraform plan that wants to recreate a production database because someone forgot lifecycle rules. The documentation is open in 14 tabs, and you have already forgotten what you actually wanted to find.
Below is a working set of 12 prompts I use in my own workflow. Each one has a template, a real input/output example, and a note on what routine it kills. Copy, substitute your values, apply. All technologies are real: Docker BuildKit, Kubernetes 1.30+, Terraform 1.9+, GitHub Actions — syntax checked against official docs (docs.docker.com, kubernetes.io, developer.hashicorp.com, docs.github.com).
1. Dockerfile from scratch with multi-stage build
What it kills: half an hour of googling best practices and a 1 GB image.
Template:
Write a production multi-stage Dockerfile for [stack].
Requirements: non-root user, pinned base image tag,
BuildKit cache mounts, .dockerignore, HEALTHCHECK,
final image under [X] MB. Explain each layer.
Example input: Node.js 20 + TypeScript, final image under 200 MB.
Output (fragment):
FROM node:20.11-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm npm ci
COPY . .
RUN npm run build
FROM node:20.11-alpine
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=build --chown=app:app /app/dist ./dist
COPY --from=build --chown=app:app /app/node_modules ./node_modules
USER app
HEALTHCHECK CMD wget -qO- http://localhost:3000/health || exit 1
CMD ["node", "dist/main.js"]
Cache mounts (--mount=type=cache) are a BuildKit feature enabled by default since Docker 23; the --chown flag on COPY is documented in the Dockerfile reference and removes the need for a separate chown layer.
2. Explain why the image is huge
What it kills: blind guessing about what bloats the layer.
Here is my Dockerfile and the output of `docker history --no-trunc`.
Find the three largest layers, explain the cause, and suggest fixes
with exact commands.
The trick: ask for docker history --no-trunc output — it shows the real size of each layer, including commands hidden behind RUN.
3. Docker Compose for a local environment
What it kills: manual assembly of a stack of five services.
Compose file for [services]. Requirements: healthchecks,
depends_on with condition: service_healthy, named volumes,
.env for secrets, no version key (Compose Spec).
Since Compose v2 the top-level version: key is deprecated — the Compose Specification reads it as obsolete. The model often still adds it; the prompt above explicitly forbids it.
4. Diagnosing CrashLoopBackOff
What it kills: an hour of kubectl describe and reading events by eye.
Pod in CrashLoopBackOff. Here is describe, logs (--previous),
and events. List hypotheses in order of probability,
for each — a verification command.
Typical output is a table: OOMKilled → check resources.limits.memory; failed probe → check initialDelaySeconds; missing env → check ConfigMap. The key value is not the diagnosis but the chain of verifiable commands.
5. Explaining a Terraform plan before apply
What it kills: the "why is it recreating the database" panic.
Here is the output of terraform plan. Find resources marked
for replacement (forces replacement). Explain the reason for each
and how to avoid it (lifecycle, ignore_changes, state mv).
Most often the culprit is a changed immutable attribute (for example, name on a resource that requires new). lifecycle { ignore_changes = [...] } is documented in the Terraform language reference and is the correct tool here.
6. Terraform module from a description
What it kills: writing variables.tf and outputs.tf by hand.
Terraform module for [resource]. Structure: main.tf, variables.tf,
outputs.tf, versions.tf with required_providers pinning.
All variables with type, description, default where sensible.
Ask explicitly for versions.tf with a pinned provider version — otherwise the model produces floating versions that break on the next terraform init.
7. Remote state and locking
What it kills: errors when two engineers run apply at the same time.
Backend configuration for S3 + DynamoDB locking
(or GCS / AzureRM). Explain state locking and encryption.
S3 backend with dynamodb_table for locking is the classic scheme from HashiCorp docs; newer Terraform supports native S3 locking via use_lockfile — worth asking the model to compare both options.
8. GitHub Actions CI pipeline
What it kills: assembling a workflow from snippets across five blogs.
GitHub Actions workflow: lint, test, build Docker image,
push to GHCR with tags from metadata-action, cache layers
via cache-from/cache-to type=gha. Pin action versions by SHA.
Layer caching via cache-from: type=gha works with docker/build-push-action and BuildKit — this is the official recommended approach in the Docker documentation for GitHub Actions.
9. Secrets in CI without leaks
What it kills: tokens in logs and repository variables.
Review this workflow for secret leaks: echo, set -x,
passing secrets as build-args. Suggest fixes with masking
and OIDC instead of long-lived keys.
OIDC for cloud authentication without static keys is described in the GitHub docs (permissions: id-token: write) — the model knows the pattern, but it needs to be pointed at it.
10. Kubernetes manifests with resource limits
What it kills: copy-paste of YAML with no requests/limits.
Deployment + Service + HPA for [app]. Set requests/limits,
readiness and liveness probes, securityContext (runAsNonRoot,
readOnlyRootFilesystem). Explain how HPA uses requests.
Important point the model usually gets right only when prompted: HPA calculates load percentage from requests, not from limits.
11. RBAC and ServiceAccount
What it kills: cluster-admin "just to make it work".
Role + RoleBinding for a service that only needs to read
pods and logs in namespace [X]. Explain why ClusterRole is not needed.
12. Post-mortem of a failed deploy
What it kills: the same incident twice.
Here are the timeline, logs, and deploy diff. Write a post-mortem:
what happened, root cause, contributing factors, action items
with owners and deadlines. No blame on people.
How to not waste these prompts
| Task | Model mistake | How to catch it |
|---|---|---|
| Dockerfile | Unpinned latest tag |
Require a version tag in the prompt |
| Compose | Adds version: |
Compose Spec deprecates it |
| Terraform | Floating provider versions | Ask for versions.tf |
| Kubernetes | HPA without requests | Check resources.requests |
| CI | Secrets in echo |
Ask for a leak review |
General rule: the model is strong at generating templates and weak at knowing your context. Give it real command output — docker history, kubectl describe, terraform plan — and it turns from a text generator into a diagnostic tool. And always run terraform plan before apply and kubectl diff before kubectl apply. AI drafts, you verify.
These 12 prompts cover most of the daily routine: image assembly, debugging pods, infrastructure as code, and pipelines. Start with the ones where you lose the most time — most likely CrashLoopBackOff and Terraform plan. And if you want to go deeper systematically, look at the practical AI-learning tracks on asibiont.com — but the prompts above work today, without any setup.
Comments