ChatGPT for DevOps: Prompts That Speed Up Infrastructure Work

Dockerfile Review and Optimization

Kubernetes YAML From Plain English

CI/CD Pipeline Explanation

Postmortem Writing From Log Dumps

Infrastructure Security Audit

Converting Bash Scripts Into Readable Form

Treating the Output as a Starting Point DevOps work has a particular texture that's different from application development. You're often reading something unfamiliar — a Kubernetes YAML someone else wrote, a Dockerfile from three years ago, a Bash script that's grown beyond anyone's ability to reason about — and you need to understand it quickly, modify it safely, or diagnose what went wrong. ChatGPT is well-suited for this. Infrastructure configurations are highly structured, the problem domain is well-documented in its training data, and the tasks are often translational: "plain English to config" or "config to plain English." Here's how I've integrated it into my DevOps workflow. Dockerfiles accumulate bad patterns over time. Layers that bust cache unnecessarily. Running as root. Installing tools that were needed for a build step but end up in the final image. Most teams have at least one Dockerfile nobody wants to touch. Prompt: "Review this Dockerfile for a Node.js application. Identify any security issues, layer caching problems, image size inefficiencies, and best practice violations. For each issue, explain the problem and show the specific fix. Also tell me if there's anything that would cause this to behave differently between development and production environments. Here's the Dockerfile: [paste Dockerfile]" The "explain the problem" instruction is important if you want to actually learn from the review rather than just apply the fix. I've caught real security issues with this — exposed secrets in ENV instructions, base images that haven't been updated in two years, unnecessary packages that expand the attack surface. Writing Kubernetes YAML from scratch is where I spend more time than I'd like to admit reading the docs. This prompt lets me describe what I want and get a starting point. Prompt: "Generate Kubernetes YAML for a Node.js API service with the following requirements: 3 replicas, resource limits of 512Mi memory and 500m CPU per pod, environment variables loaded from a Secret named 'api-secrets', a readiness probe that checks /health every 10 seconds, and a horizontal pod autoscaler that scales between 3 and 10 replicas when CPU hits 70%. Include comments in the YAML explaining each non-obvious configuration choice. Target Kubernetes 1.28." Always specify the Kubernetes version. Config that works on 1.24 can be deprecated by 1.28, and ChatGPT won't warn you unless you anchor it to a specific version. The comments instruction is also worth keeping — they help you understand what to change when requirements evolve. GitHub Actions workflows, especially ones you've inherited, can be dense. This prompt is my first move when I need to understand a pipeline quickly. Prompt: "Explain what this GitHub Actions workflow does, step by step. For each job and each step, describe what it's doing and why it would be there. Note any potential issues: steps that could fail silently, missing error handling, security concerns with how secrets or permissions are handled, or anything that looks like a workaround for a deeper problem. Here's the workflow YAML: [paste workflow]" The "workaround" instruction is underrated. Sometimes you look at a CI config and there's something that seems weird — an extra checkout step, a manual cache key that shouldn't need to be there — and it turns out to be papering over a real issue. ChatGPT will sometimes catch these. Incident postmortems are important and almost always written badly, usually because they're written after an already exhausting incident by people who want to go home. Here's a prompt that gives you a structured draft to work from. Prompt: "Here are the logs and timeline from a production incident where our API service started returning 500 errors for authenticated users. Write a postmortem in the format used by Google's SRE handbook: an incident summary, the timeline of detection and response, the root cause analysis, the contributing factors, and the action items with owners and due dates. Leave the owners and due dates as placeholders. Stick to facts — don't assign blame. Logs and timeline: [paste raw material]" "Don't assign blame" is not just a nicety — it's a quality instruction. Blame-focused postmortems produce worse root cause analysis because they stop at the human action instead of the system condition that made that action possible. This prompt is not a replacement for a real security audit, but it's a fast way to catch low-hanging misconfigurations before they become incidents. Prompt: "Review these Terraform files for security misconfigurations. Focus on: publicly exposed resources that shouldn't be, overly permissive IAM policies, missing encryption at rest or in transit, security group rules that are too broad, and any credentials or sensitive values that appear to be hardcoded. For each issue, rate the severity as high/medium/low and explain the potential impact. Terraform files: [paste files]" I run this before every infrastructure PR review. It catches the kind of mistakes that are easy to make when you're moving fast — an S3 bucket left public, a security group rule that opens 0.0.0.0/0 on a port it shouldn't. Legacy Bash scripts are their own genre of horror. Dense one-liners, no comments, variables named tmp2. This prompt is how I make them reviewable. Prompt: "Refactor this Bash script to be readable and maintainable. Add comments explaining what each section does and why. Break long one-liners into multiple lines with intermediate variables that have meaningful names. Add error handling for the operations that could fail silently. Do not change the behavior — only improve readability and robustness. After the refactored script, give me a plain-English summary of what the entire script does, what it assumes about the environment, and what could go wrong at runtime. Here's the script: [paste script]" The "do not change the behavior" instruction is critical. Without it, ChatGPT will sometimes decide it knows a better way to accomplish something and silently change logic. For Bash especially, that's dangerous. The common theme across all of these is that ChatGPT gives you a first draft or a review, not a finished product. For infrastructure work, that's especially important to internalize — a misconfigured Kubernetes resource or a missed security issue can cause real problems. The pattern that works: use ChatGPT to get to 80% quickly, then apply your own knowledge of your specific environment to close the gap. The 80% speedup is real and meaningful. The remaining 20% is still your job. I've put together 200 prompts that cover the full DevOps and developer workflow — from infrastructure to debugging to code review to deployment automation. Get 200 ChatGPT Prompts for Developers — $19 instant download Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or