GitHub Copilot for DevOps Engineers

DevOps engineers spend a surprising share of the week writing Bash, YAML, Python, Dockerfiles, Terraform, Kubernetes manifests, and GitHub Actions workflows — plus documentation and the endless troubleshooting commands in between. GitHub Copilot accelerates every one of those tasks, but generated infrastructure is a draft, not a decision: it must still be reviewed, validated, scanned, and tested before it touches production.

This is Part 2 of the GitHub AI Engineering Academy. Part 1, GitHub for AI Engineers, covered how GitHub works as the control center for AI-assisted delivery. This lesson is deliberately hands-on: real DevOps examples across the tools you actually use, each framed the same way — generate, then review before you ship.

What You’ll Learn

• What GitHub Copilot is — inline suggestions, Copilot Chat, and agent mode, and where each fits a DevOps workflow.
• Why Copilot suits DevOps — the natural-language-to-artifact loop, and why engineering review is the non-negotiable step in it.
• Copilot for Bash — turning a plain-English request into a correct, understandable shell pipeline.
• Copilot for Docker — writing a Dockerfile, then hardening it for size, security, caching, and a non-root user.
• Copilot for Docker Compose — scaffolding a multi-service local stack.
• Copilot for Terraform — drafting HCL safely, with terraform plan and review as hard gates.
• Copilot for Kubernetes — going from a bare Deployment to one with probes, limits, and a securityContext.
• Copilot for GitHub Actions — a real build-test-scan-publish pipeline with least-privilege permissions.
• Copilot for Python and Ansible — automation scripts and playbooks you can build on.
• Copilot for troubleshooting — interpreting failures across Linux, Docker, Kubernetes, CI, and Terraform.
• 20 prompts you can reuse today, and a clear-eyed look at why you must never blindly trust AI-generated infrastructure.

What Is GitHub Copilot?

GitHub Copilot is an AI pair programmer. It is powered by a selectable, rotating set of frontier models rather than a single fixed one, so the exact model behind a suggestion changes over time — check the current GitHub Copilot documentation references for what is available to your account rather than assuming a specific model.

In day-to-day use, Copilot shows up in two main forms inside your editor (VS Code, JetBrains IDEs, and others):

• Inline suggestions — as you type code or a comment, Copilot proposes the next lines. Write a comment describing what you want, and it drafts the implementation below.
• Copilot Chat — a conversational panel where you ask questions, request whole files, paste an error, or ask Copilot to refactor a selection. This is where most DevOps work happens, because our tasks are usually “write me a manifest that does X” or “why is this failing?”

There is also an agent mode — an autonomous multi-step mode that can edit files, run commands, and iterate on errors while you stay in control and approve what it does. That is powerful for larger refactors, but the reviewing engineer is still the one accountable for the result.

❗ Important — Copilot’s AI features change quickly. Treat exact commands, model names, and capabilities in this lesson as conceptual, and verify the current behavior against official GitHub documentation before you rely on it.

A dedicated command-line lesson, Part 3: GitHub Copilot CLI, is coming soon. If you see the CLI mentioned here, it means the current standalone agentic copilot command — not the retired gh copilot suggest extension, which you should not use. We keep CLI references brief until Part 3.

Why Copilot Is Useful for DevOps

DevOps is a translation job: you take an intent (“rotate these logs”, “deploy this service”, “provision that bucket”) and express it precisely in Bash, YAML, HCL, or Python. Copilot shortens the distance between the natural-language intent and a working first draft. But the draft is exactly that — the engineer’s review is what turns it into something you can run.

Natural-language instruction
          |
       Copilot
          |
 Bash / Python / YAML / HCL
          |
    Engineer Review   <-- required
          |
       Testing
          |
     Production

The middle step is not optional. Everything downstream — the security scan, the test environment, the approval — depends on a human having actually read and understood the generated artifact. Copilot makes you faster at producing candidates; it does not make you slower at reviewing them, and that review is where the real engineering happens.

🛠️ DevOps Tip — Write the comment or prompt as if you were briefing a capable junior engineer: state the goal, the constraints (base image, versions, non-root, region), and what “done” looks like. Specific prompts produce reviewable drafts; vague prompts produce plausible-looking guesses.

GitHub Copilot for Bash

Shell is where Copilot earns its keep fastest, because most of us can describe a pipeline in words far quicker than we can recall the exact find flags. Type a comment and let Copilot draft the command:

# Find the ten largest files under /var/log
sudo find /var/log -type f -printf '%s %p\n' | sort -nr | head -10

Read it left to right before running it:

• sudo find /var/log -type f — search under /var/log, matching regular files only (-type f), using sudo because some log files are not world-readable.
• -printf '%s %p\n' — for each file, print its size in bytes (%s), a space, then its path (%p), one per line. This avoids parsing ls, which is fragile.
• | sort -nr — sort numerically (-n) and in reverse (-r), so the biggest sizes come first.
• | head -10 — keep only the top ten lines.

What to check: %s is bytes, so divide by 1048576 for MB if you want friendlier output; and confirm you actually want /var/log and not, say, a mounted volume. This command only reads, so it is safe — but the habit of reading before running is what keeps the destructive ones from slipping through.

🔍 Troubleshooting — If Copilot hands you a command with rm, dd, mkfs, > /dev/, or --force, stop and read every flag. Test it against a throwaway directory or with a dry-run flag first. A wrong path in a shell one-liner has no undo.

GitHub Copilot for Docker

Ask Copilot for a Dockerfile for a small Python service and you will get something like this:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000
CMD ["python", "app.py"]

This works, and it is a reasonable starting point: a slim base image, dependencies installed from a pinned requirements.txt, and a clear entrypoint. But “works” is not “production-ready.” The container still runs as root, has no health check, and rebuilds all dependencies whenever any source file changes.

Now ask Copilot to improve it — for example, “make this smaller and more secure: multi-stage build, non-root user, health check, better layer caching.” A stronger version:

# Build stage: install dependencies into a virtualenv
FROM python:3.12-slim AS build
WORKDIR /app
COPY requirements.txt .
RUN python -m venv /opt/venv \
    && /opt/venv/bin/pip install --no-cache-dir -r requirements.txt

# Runtime stage: copy only what we need
FROM python:3.12-slim AS runtime
ENV PATH="/opt/venv/bin:$PATH"
WORKDIR /app

# Create and switch to a non-root user
RUN useradd --create-home --uid 10001 appuser
COPY --from=build /opt/venv /opt/venv
COPY . .
USER appuser

EXPOSE 8000
HEALTHCHECK --interval=30s --timeout=3s \
  CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')" || exit 1
CMD ["python", "app.py"]

What changed and why it matters:

• Multi-stage build — dependencies are built in one stage; only the finished virtualenv and app code land in the final image, keeping it small.
• Layer caching — copying requirements.txt and installing before copying source means dependency layers are reused when only code changes, so rebuilds are fast.
• Non-root user — appuser (UID 10001) means a container escape does not start as root. This is one of the highest-value container hardening steps.
• Health check — Docker (and orchestrators) can tell whether the app is actually serving, not just whether the process is alive.

Review the base image tag, decide whether to pin a digest, and scan the built image before pushing. For deeper container work, the Docker error and how-to guides and the hands-on Docker Academy go well beyond a single Dockerfile.

✅ Best Practice — Ask for the naive version first to understand the shape, then ask Copilot to harden it explicitly. “Add a non-root user, a health check, and multi-stage caching” is a prompt it handles well — but you still confirm each change does what you think.

GitHub Copilot for Docker Compose

For local development you often want an app plus its backing services. Describe the stack — “web app on port 8000, PostgreSQL, and Redis, with named volumes” — and Copilot drafts a Compose file:

services:
  app:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgresql://app:${DB_PASSWORD}@db:5432/appdb
      REDIS_URL: redis://cache:6379/0
    depends_on:
      - db
      - cache

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data

  cache:
    image: redis:7
    volumes:
      - redisdata:/data

volumes:
  pgdata:
  redisdata:

Things to check before you run docker compose up:

• Secrets — the password comes from ${DB_PASSWORD}, read from a local .env file that you add to .gitignore and never commit. Do not let Copilot inline a literal password; if it does, replace it.
• Image tags — postgres:16 and redis:7 are pinned to major versions, which is fine for local work. For anything shared, pin more tightly.
• depends_on — this controls start order, not readiness. If the app needs the database to be accepting connections, add a retry in the app or a healthcheck-based condition.

This stack is for local development. Do not carry these defaults into production unchanged — exposed ports, default users, and unauthenticated Redis are all fine on your laptop and dangerous on a server.

GitHub Copilot for Terraform

Copilot is genuinely helpful with Terraform: it drafts resources, wires up variables and outputs, scaffolds module structure, and explains HCL errors in chat. Here is a small, self-contained example — an S3 bucket with versioning — of the kind of first draft you might get:

variable "bucket_name" {
  description = "Name of the S3 bucket"
  type        = string
}

resource "aws_s3_bucket" "artifacts" {
  bucket = var.bucket_name
}

resource "aws_s3_bucket_versioning" "artifacts" {
  bucket = aws_s3_bucket.artifacts.id
  versioning_configuration {
    status = "Enabled"
  }
}

output "bucket_arn" {
  description = "ARN of the artifacts bucket"
  value       = aws_s3_bucket.artifacts.arn
}

This shows the pieces Copilot handles well: a typed variable, resources that reference each other (aws_s3_bucket.artifacts.id), and an output that exposes the ARN for other modules. Copilot is also good at the mechanical parts of HCL — extracting repeated blocks into a module, adding for_each, or telling you why terraform validate is unhappy.

What it cannot know is your account: which bucket names already exist, what your organization’s tagging and encryption policy requires, or whether a change quietly forces resource replacement. That is where AI-generated IaC gets dangerous.

⚠️ Warning — Never run AI-generated Terraform against production without review and a terraform plan. A plausible-looking change can propose destroying and recreating stateful resources, widening IAM, or removing protections. Read the plan output line by line, apply in a non-production workspace first, and require human approval before terraform apply.

For more on infrastructure as code, see the Terraform guides and the OpenTofu guides; the broader IaC category covers patterns that apply regardless of which tool you use.

GitHub Copilot for Kubernetes

Ask for a Deployment and Copilot gives you a valid, minimal manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ai-api
  template:
    metadata:
      labels:
        app: ai-api
    spec:
      containers:
        - name: ai-api
          image: myorg/ai-api:1.0.0
          ports:
            - containerPort: 8000

This will schedule and run — but it is missing everything that keeps a service healthy under load. There are no probes (Kubernetes cannot tell if a pod is ready or stuck), no resource requests or limits (one pod can starve its neighbors), and no securityContext (the container may run as root with more privileges than it needs). Ask Copilot to “add readiness and liveness probes, resource requests and limits, and a hardened securityContext”:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ai-api
  template:
    metadata:
      labels:
        app: ai-api
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: ai-api
          image: myorg/ai-api:1.0.0
          ports:
            - containerPort: 8000
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 5
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 15
            periodSeconds: 20
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]

Each addition is a production requirement, not a nicety:

• Probes let Kubernetes hold traffic until a pod is ready and restart it if it hangs.
• Requests and limits give the scheduler what it needs to place pods and protect the node from a runaway container.
• securityContext drops root, blocks privilege escalation, makes the root filesystem read-only, and drops all Linux capabilities — a strong default for most services.

Validate before you apply: kubectl apply --dry-run=server -f deployment.yaml catches schema and admission errors without changing the cluster. The Kubernetes and Helm guides go deeper on probes, resources, and rollout strategy.

GitHub Copilot for GitHub Actions

CI/CD is where a lot of DevOps time goes, and Copilot drafts workflows well. Describe the pipeline — “on push and PR: check out, install Python deps, run tests, build a Docker image, scan it, and publish” — and refine what it returns. A workflow with the stable, verified building blocks:

name: build-test-publish

on: [push, pull_request]

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: pip install --no-cache-dir -r requirements.txt

      - name: Run tests
        run: pytest -q

      - name: Build Docker image
        run: docker build -t myorg/ai-api:${{ github.sha }} .

      - name: Scan image for vulnerabilities
        run: |
          # Run your image scanner here (e.g. Trivy) and fail on findings
          echo "scan the built image before publishing"

      - name: Publish image
        if: github.ref == 'refs/heads/main'
        run: |
          echo "${{ secrets.REGISTRY_TOKEN }}" | docker login -u "${{ secrets.REGISTRY_USER }}" --password-stdin
          docker push myorg/ai-api:${{ github.sha }}

The parts worth checking in any Copilot-generated workflow:

• Pinned action versions — actions/checkout@v4 and actions/setup-python@v5 are current, verified versions. Do not accept an unversioned or made-up action; confirm every uses: is real and pinned.
• Least-privilege permissions — the top-level permissions: contents: read block means the workflow starts with minimal access; grant more only where a step needs it. Copilot often omits this — add it.
• Secrets, never literals — registry credentials come from ${{ secrets.REGISTRY_TOKEN }}, configured as repository or environment secrets. Never let a token appear as plain text in the file.
• Scan before publish — the scan step must actually fail the build on serious findings; a placeholder that always passes is worse than none.

For more CI/CD patterns, see the CI/CD guides and, for the security scanning side, the security hardening guides.

🤖 AI Infrastructure Tip — Copilot sometimes suggests third-party actions by name. Before adding one, confirm the action exists, is maintained, and is pinned to a specific version or commit SHA. An unverified action in your pipeline runs with access to your repo and secrets.

GitHub Copilot for Python Automation

A large amount of DevOps automation is small Python scripts that call an API or process infrastructure data. Copilot writes these quickly, including the error handling that people often skip. Ask for “a script that fetches open GitHub issues for a repo and prints their titles, with error handling”:

import os
import sys
import urllib.request
import urllib.error
import json

REPO = "myorg/ai-api"
TOKEN = os.environ.get("GITHUB_TOKEN")  # never hard-code tokens

def fetch_open_issues(repo: str) -> list:
    url = f"https://api.github.com/repos/{repo}/issues?state=open"
    request = urllib.request.Request(url)
    request.add_header("Accept", "application/vnd.github+json")
    if TOKEN:
        request.add_header("Authorization", f"Bearer {TOKEN}")
    try:
        with urllib.request.urlopen(request, timeout=10) as response:
            return json.loads(response.read().decode())
    except urllib.error.HTTPError as exc:
        print(f"HTTP error {exc.code}: {exc.reason}", file=sys.stderr)
    except urllib.error.URLError as exc:
        print(f"Network error: {exc.reason}", file=sys.stderr)
    return []

def main() -> None:
    issues = fetch_open_issues(REPO)
    for issue in issues:
        # Pull requests also appear in this endpoint; skip them
        if "pull_request" in issue:
            continue
        print(f"#{issue['number']}: {issue['title']}")

if __name__ == "__main__":
    main()

What to review here:

• No embedded credentials — the token is read from the GITHUB_TOKEN environment variable, not written into the file. This is the single most common security bug in AI-generated scripts; always check for it.
• Explicit error handling — HTTP and network errors are caught and reported to stderr, and the function returns an empty list rather than crashing.
• A real API detail — GitHub’s issues endpoint also returns pull requests, so the code filters them out. Copilot got this right here, but this is exactly the kind of behavior you verify against the GitHub REST API docs rather than trusting blindly.

For more scripting patterns, see the Bash and Python automation guides.

GitHub Copilot for Ansible

Configuration management is another good fit. Ask for “an Ansible playbook that installs Docker on Ubuntu” and Copilot scaffolds the tasks:

---
- name: Install Docker on Ubuntu
  hosts: servers
  become: true
  tasks:
    - name: Install prerequisite packages
      ansible.builtin.apt:
        name:
          - ca-certificates
          - curl
          - gnupg
        state: present
        update_cache: true

    - name: Add Docker APT repository
      ansible.builtin.deb822_repository:
        name: docker
        types: [deb]
        uris: "https://download.docker.com/linux/ubuntu"
        suites: ["{{ ansible_distribution_release }}"]
        components: [stable]
        signed_by: "https://download.docker.com/linux/ubuntu/gpg"

    - name: Install Docker Engine
      ansible.builtin.apt:
        name:
          - docker-ce
          - docker-ce-cli
          - containerd.io
        state: present
        update_cache: true

    - name: Ensure Docker is running and enabled
      ansible.builtin.service:
        name: docker
        state: started
        enabled: true

Review points that matter with Ansible:

• Fully-qualified module names — ansible.builtin.apt, ansible.builtin.service, and the repository module are namespaced, which is current best practice. If Copilot emits bare apt:, that still works but the FQCN form is clearer and future-proof.
• become: true — this runs as root, so read the tasks with that in mind.
• Idempotence — Ansible tasks should be safe to run repeatedly; confirm each task uses state: rather than shelling out to imperative commands, so re-runs don’t cause drift.

Test against a throwaway VM or container before pointing this at real servers, and confirm the release variable resolves to a supported Ubuntu suite. The Ansible guides and the Linux admin guides cover this in more depth.

GitHub Copilot for Troubleshooting

Some of the best DevOps value from Copilot is not writing new code — it is making sense of failures. Paste an error into Copilot Chat and ask what it means and what to try next. It handles a wide range of DevOps failure output:

• Linux — a cryptic systemd or permission error, or an unfamiliar exit code.
• Docker — a build that fails on a layer, or a container that exits immediately.
• Kubernetes — kubectl describe pod events like ImagePullBackOff, CrashLoopBackOff, or failed probes.
• Failed CI — a stack trace or a dependency resolution error from a workflow run.
• Terraform — a state lock, a provider error, or a plan that wants to destroy something unexpected.

Copilot is good at pattern-matching these to likely causes and suggesting the next diagnostic command. But treat its answers as hypotheses to confirm, not conclusions — it is guessing from text, without seeing your cluster or your state.

⚠️ Warning — Logs, stack traces, and error output frequently contain sensitive data: API tokens, connection strings, internal hostnames, IP addresses, and personal data. Redact secrets before pasting anything into a chat, and follow your organization’s policy on where that data is allowed to go.

20 GitHub Copilot Prompts for DevOps Engineers

These are reusable starting prompts. Each produces a first draft — read, validate, and test before shipping.

Containers and images

1. “Write a multi-stage Dockerfile for a Python 3.12 service that runs as a non-root user.”
2. “Reduce the size of this Docker image and add a health check.”
3. “Add a .dockerignore that excludes build artifacts, caches, and secrets.”
4. “Explain why this container exits immediately and how to debug it.”

Kubernetes

5. “Add readiness and liveness probes and resource requests and limits to this Deployment.”
6. “Write a Kubernetes Service and Ingress for this Deployment on port 8000.”
7. “Add a hardened securityContext that drops all capabilities and disallows privilege escalation.”
8. “Explain this CrashLoopBackOff from kubectl describe pod output.”

Infrastructure as Code

9. “Draft a Terraform module for an S3 bucket with versioning, encryption, and blocked public access.”
10. “Convert these repeated resource blocks into a for_each.”
11. “Explain what terraform plan is proposing to destroy and why.”
12. “Write the variables and outputs for this Terraform module.”

CI/CD and Actions

13. “Write a GitHub Actions workflow to test, build, scan, and publish a Docker image, with least-privilege permissions.”
14. “Add a job that only publishes on pushes to the main branch.”
15. “Explain why this GitHub Actions run failed from the log output.”

Shell and automation

16. “Write a Bash script to rotate and compress logs older than seven days, with a dry-run flag.”
17. “Write a Python script that calls an API, handles errors, and reads its token from an environment variable.”
18. “Write an Ansible playbook to install and enable a service on Ubuntu, idempotently.”

Review and safety

19. “Review this manifest for security issues before I apply it.”
20. “What are the risks of running this command in production, and how would I test it safely first?”

Notice that the last group flips the tool around — using Copilot to critique its own or your output. That is one of the more valuable habits, as long as you remember its review is an assist, not a sign-off.

Never Blindly Trust AI-Generated Infrastructure

Everything above assumes one thing: a human reviews the output. AI-generated infrastructure fails in specific, recognizable ways, and knowing the failure modes is how you catch them:

• Destructive Terraform — a change that replaces or deletes stateful resources.
• Over-permissive IAM — wildcard actions or * resources that grant far too much.
• Privileged containers — privileged: true, running as root, or mounted host paths.
• Exposed Services — a LoadBalancer or NodePort open to the world when it should be internal.
• Wrong shell commands — a subtly incorrect flag or path that damages data.
• Embedded credentials — tokens or passwords written directly into code or manifests.
• Deprecated syntax — API versions or fields that no longer exist in current tooling.
• Nonexistent packages — dependencies or Actions that simply do not exist.
• Vulnerable dependencies — real packages with known CVEs pulled in without a scan.
• Excessive Actions permissions — a workflow granted write access it never needed.

The defense is the same pipeline you would apply to any pull request, whether a person or a model wrote it:

AI generates code
      |
Engineer reviews
      |
Lint / validate
      |
Security scan
      |
Test environment
      |
Human approval
      |
Production

This philosophy recurs across the entire GitHub AI Engineering Academy: AI accelerates the work, but review, validation, scanning, testing, and human approval are what make the output safe to run. Copilot is a very fast, very well-read colleague who has never been on call for your systems — useful, and never the final authority.

What’s Next

You now have Copilot working across the full DevOps surface: Bash, Docker, Compose, Terraform, Kubernetes, Actions, Python, and Ansible — with review as the constant. The next lesson, Part 3: GitHub Copilot CLI (coming soon), takes Copilot out of the editor and onto the command line with the standalone agentic copilot command. Later parts cover GitHub Models, the Copilot coding agent, and end-to-end automated delivery.

If you skipped it, start with Part 1, GitHub for AI Engineers, and you can always return to the GitHub AI Engineering Academy home to see the full path. To go deeper on the tools in this lesson, the hands-on Docker Academy and the Ubuntu AI Infrastructure series are good next steps.