DevOps is often less about engineering and more about context switching: writing a Dockerfile, debugging a CrashLoopBackOff, patching a GitHub Actions pipeline, then explaining to a manager why the deploy failed. ChatGPT will not replace your pager, but it can absorb most of the routine work — if you ask correctly.
Below are 10 working prompts that help a DevOps engineer or backend developer keep infrastructure under control through dialogue with AI: from image optimization to incident analysis. Each prompt is copy-paste ready, with an example input, expected output, and a note on when to use it. Remember the main rule: AI generates a draft, you review it. No prompt replaces code review or GitOps.
1. Multi-stage Dockerfile with security in mind
For what: turning a "works on my machine" build into a production image without root and with a minimal attack surface.
You are a senior DevOps engineer. Write a multi-stage Dockerfile for a [stack] application. Requirements: non-root user, pinned base image versions, .dockerignore, healthcheck, minimal final image. Explain each stage and list potential vulnerabilities.
Example input: Python 3.12 + FastAPI + uvicorn, dependency installation via pip install -r requirements.txt.
Expected result: a two-stage Dockerfile (builder + runtime), a USER app directive, a pinned python:3.12-slim digest, and a HEALTHCHECK calling /health. The model will usually suggest --no-cache-dir and cleaning up apt lists — verify that yourself.
2. Debugging docker-compose that "doesn't start"
For what: local environment that breaks after someone added a service.
Here is my docker-compose.yml and the error output. Diagnose the problem step by step: check service dependencies, healthchecks, networks, volumes, environment variable substitution. Suggest a minimal fix, not a rewrite.
Example input: docker compose up fails with dependency failed to start: container db is unhealthy. In 90% of cases the model correctly points to a missing healthcheck on the database or a wrong depends_on condition (service_healthy instead of service_started).
3. Kubernetes manifest review before apply
For what: catching errors at the manifest stage, not in prod.
Act as a Kubernetes reviewer. Analyze this Deployment/Service manifest against production best practices: resource requests/limits, liveness/readiness/startup probes, securityContext (runAsNonRoot, readOnlyRootFilesystem), PodDisruptionBudget, topologySpreadConstraints. Output a table: issue
| severity | fix.
Expected result: a table with specific YAML patches. The model reliably catches missing resources and readinessProbe — the two most common causes of failed rolling updates.
4. Explaining CrashLoopBackOff from logs
For what: when kubectl describe pod shows a restart loop and you have no idea why.
Here are the events from kubectl describe pod and the last 100 lines of container logs. Determine the root cause of CrashLoopBackOff. List hypotheses in order of probability and a command to verify each (kubectl logs --previous, kubectl get events, etc.).
Tip: pipe the output of kubectl logs --previous — logs from the crashed container instance are more informative than current ones. The model often correctly identifies OOMKilled (exit code 137) versus application error (exit code 1).
5. GitHub Actions pipeline from scratch
For what: CI that builds, tests, and deploys without copy-pasting from Stack Overflow.
Generate a GitHub Actions workflow for a [stack] project: lint, tests with caching, build Docker image, push to GHCR, deploy to Kubernetes via kubectl. Use official actions, pin versions by SHA, store secrets in GitHub Secrets. Add a job dependency diagram in text form.
Expected result: a .github/workflows/ci.yml file with actions/checkout@v4, docker/build-push-action, and caching via actions/cache. Always verify pinned action versions — supply chain attacks on Actions are a real threat.
6. GitLab CI with rules and environments
For what: migration from GitHub Actions or setting up a pipeline with manual gates for prod.
Convert this GitHub Actions workflow to .gitlab-ci.yml. Preserve stages, caching, and secrets (use CI/CD variables). Add rules: run tests on merge requests, deploy to staging automatically, deploy to prod only with a manual trigger. Explain the differences in approach.
Expected result: a pipeline with stages, rules:if, and when: manual for prod. The model knows the only/except syntax is legacy and will use rules.
7. Terraform module with variables and outputs
For what: infrastructure as code without a 300-line main.tf.
Write a Terraform module for [resource, e.g., an S3 bucket with versioning and encryption]. Structure: variables.tf with descriptions and validation, main.tf, outputs.tf, a usage example, and a note on which provider version is required. Follow the terraform-aws-modules style.
Tip: ask the model to add validation blocks to variables — this catches errors at the plan stage rather than apply. And always run terraform plan before apply, even if the code looks perfect.
8. Incident log analysis and timeline
For what: post-mortem after an incident, when logs are scattered across services.
Here are logs from three services with timestamps (UTC). Build an incident timeline: first anomaly, propagation, peak, recovery. Identify the likely trigger and contributing factors. Format as a table: time
| service | event | significance.
Expected result: a structured timeline you can paste into a post-mortem. AI is good at correlating timestamps — but check time zones, the model sometimes confuses UTC and local time.
9. Runbook for on-call
For what: so the person on duty at 3 AM doesn't have to think, just follow steps.
Write a runbook for the alert "[alert name, e.g., HighErrorRate on api-gateway]". Structure: what the alert means, impact on users, first 5 diagnostic commands, decision tree (rollback / scale / escalate), contacts, rollback procedure. Write for an engineer who sees this service for the first time.
Tip: ask the model to add a "do not do" section — actions that make things worse (e.g., kubectl delete pod on a StatefulSet). This is exactly what new on-call engineers most often get wrong.
10. Cost optimization for the cluster
For what: when the cloud bill arrives and you need to find what's eating the budget.
Here is the output of kubectl top pods and the requests/limits from all Deployments. Find resources where requests are significantly higher than actual consumption. Estimate potential savings and suggest right-sizing with a new values.yaml. Consider HPA and VPA.
Expected result: a table with current requests, actual usage, and recommendations. Reality check: the model doesn't see your billing, so the final savings estimate must be verified against the provider's calculator.
What to remember
These prompts save hours on routine: a Dockerfile in 5 minutes instead of 40, a runbook in one evening instead of a week. But AI does not see your cluster, does not know about the legacy service that "must not be touched," and does not bear responsibility for prod. The working pattern is: AI generates a draft → you review → GitOps applies → monitoring confirms. That's how you cut reaction time to incidents without losing control. Start with one prompt — say, the Dockerfile one — and see how much time it frees up for the tasks that actually require an engineer.
Comments