AI in DevOps and platform engineering

AI tools can now read logs, write Dockerfiles, draft Terraform, explain Kubernetes errors and summarise incidents. They save real time, and they can also delete a production database if you give them the keys. This lesson shows where AI helps in DevOps, where it is risky, and the working habits that keep you safe.

It builds on everything in this track: you need to understand Docker, CI/CD, cloud and Kubernetes well enough to *judge* what the AI writes. AI does not replace that knowledge; it makes it more valuable.

Notice the pattern: AI is strongest at drafting and explaining and weakest at knowing your actual system. It has never seen your cluster, your IAM rules or your bill.

Invented details. Models sometimes produce commands, flags, resource arguments or API versions that do not exist, or that existed in an old version. A made-up Terraform argument fails loudly, but a made-up security setting may look fine and do nothing.

Unsafe defaults. AI often gives the shortest working answer: a security group open to the whole internet (0.0.0.0/0), an IAM policy with * on everything, a container running as root, a hard-coded password in the example. It works, so it ships.

Destructive commands. rm -rf, terraform destroy, kubectl delete, DROP TABLE, force-push. An AI agent with shell access and production credentials can run these in seconds, including by misunderstanding.

Leaking secrets. Pasting .env files, kubeconfigs, access keys or customer logs into a public chatbot sends them to a third party. Logs often contain emails, phone numbers and tokens.

Outdated advice. Cloud services and free tiers change quickly. Ask for the official docs link and check it.

Suppose an AI gives you a Dockerfile for the Brew & Bean API. A quick review might find three things: the base image is python:latest (not repeatable; pin a version), the container runs as root (add a non-root user), and COPY . . runs before pip install (slow builds because the dependency layer is never cached). Because you studied *Docker: images and containers*, you can spot these. Someone who has not would paste and deploy.

# Typical AI draft, with issues marked
FROM python:latest            # unpinned: builds change over time
WORKDIR /app
COPY . .                      # copied before install: poor layer caching
RUN pip install -r requirements.txt
CMD ["uvicorn", "main:app", "--host", "0.0.0.0"]   # runs as root

# Reviewed version
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
RUN useradd --create-home appuser
USER appuser
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

The comments in the first half are explanations and would not be valid on the same line as an instruction in a real Dockerfile; they are shown here for learning only.

You are a senior DevOps engineer. My [GitHub Actions / GitLab CI / Jenkins] pipeline failed.

Context: [one or two lines about the project and what changed]

<log>
[paste the last 50 to 100 lines of the failed step, secrets removed]
</log>

Tell me: (1) which step failed and the most likely cause, in plain English; (2) two other possible causes; (3) the exact commands I can run to confirm each; (4) the smallest fix. Do not suggest disabling tests or security checks.

What to expect: A good answer quotes the line that shows the failure, ranks the causes and gives commands. If it suggests skipping a check, push back.

You are a cloud security engineer. Review the following [Terraform / Kubernetes YAML / Dockerfile / GitHub Actions workflow] for security and reliability problems.

For each problem give: the line, why it is risky, and the corrected code. Pay special attention to public exposure, over-broad permissions, secrets in plain text, missing resource limits, unpinned versions and missing backups. At the end, list anything you were unsure about and tell me which official documentation page to check.

<code>
[paste here]
</code>

What to expect: A good review is specific and ends with honest uncertainty. Cross-check each recommendation with the official docs before applying it.

You are an SRE. Convert this incident chat into a blameless postmortem with Summary, Impact, Timeline (with times), Contributing factors, What went well, What went badly and Action items. Use only facts from the chat; list missing information as questions.

<chat>
[paste chat export, remove personal data]
</chat>

What to expect: The result is a draft. Add what the chat could not capture and have the people involved correct it.

Platform engineering is the practice of building an internal platform (templates, a self-service portal, standard pipelines and clusters) so that product developers can ship without learning every detail of the cloud. The platform team treats developers as customers.

AI is arriving here in two ways. First, assistants inside developer portals and chat tools answer questions such as 'how do I add a database?' and generate configuration from the company's approved templates. Second, AI agents that can run tools: read logs, query metrics, open a ticket, propose a fix or even deploy it. Some teams use them to investigate alerts and post a summary before a human wakes up.

Agents are useful when the actions are narrow and reversible, and dangerous when the access is broad. Good design looks like normal security: least privilege (read-only by default), a human approval step for any change, an audit log of every action, and guardrails such as policy checks that block risky changes no matter who wrote them. Tools and names in this area change fast, so rely on the principles rather than product names. The protocol that lets models call tools is covered in *Model Context Protocol (MCP): connecting AI to tools* in the AI Engineering track.

Expect interviewers to ask how you use AI, not whether. Good answers show judgement: 'I use it to draft and to explain errors. I never run what I have not read, I check flags in the docs, I keep secrets out of prompts and I rely on the plan, tests and linters before anything reaches production.'

Skills that stay valuable: understanding networking, Linux, containers, cloud permissions and failure modes; debugging from evidence; writing clear runbooks and postmortems; and knowing what 'safe to change' means. People with these skills get more from AI because they can aim it and catch it when it is wrong.