Intro: AI as a Very Well-Read Junior Engineer

This course builds a complete Kubernetes platform and runs it the way production should be run: infrastructure as code, GitOps, encrypted secrets, CI gates, network policies, resource limits, availability, observability, backups and incident response. Each of these is a best practice on its own. Together they answer one question: when someone makes a mistake, how far can it spread?

More and more of those mistakes will not be typed by a person. AI already writes manifests, runs kubectl and opens pull requests. So the course also shows how to use AI in DevOps / SysOps / SRE work while keeping the blast radius small - how far one mistake reaches: which services, environments, users and data - not how to write prompts. It starts with a mental model of what AI is.

The Mental Model

AI is the most well-read junior engineer you will ever work with:

• Knows tooling, flags, YAML, Terraform, Helm.
• Works fast and in parallel.
• Sounds confident.

And that is exactly why it is dangerous:

• It has low context.
• It has no production scar tissue.
• It does not feel risk.
• It does not care if it is prod or dev.

Now multiply it. One junior with a bad idea breaks one thing, slowly enough that someone notices. An AI agent does not work alone: it can dispatch fifty brave juniors at once, each with small hands and very fast fingers, each touching a different cluster. Every change looks small and plausible. Each one can pass CI. If even a few of them are wrong in the same way, you do not have one incident - you have fifty, all at the same time - and nobody can review fifty changes at once.

The humans who do review are pulled the same way: a confident proposal with a clean diff and green CI invites a quick Approve. That is automation bias - trusting a result because a machine produced it and it looks sure - and it is why this course never relies on review alone.

A small example. A deploy fails with forbidden. The fastest fix a brave junior finds is a ClusterRoleBinding that gives its ServiceAccount cluster-admin: the error disappears, the tests pass - and the blast radius is now the whole cluster. The narrow fix is one Role with the one permission that was missing, bound with a RoleBinding in that one namespace. Much of this course is about making the narrow fix the easy one.

Speed and parallelism are what make AI useful. They are also what turn a small mistake into a fleet-wide one.

The Rule

AI does not decide. AI proposes. Humans own decisions and accountability.

The system must be designed so that even a brave junior (or a tired on-call engineer) cannot break production by default.

Working Principles

• AI proposes; what it may do on its own is decided in advance. In production an agent acts only through narrow, pre-approved actions with only the permissions they need - every action logged, with a known way back. Everything else is a proposal a human approves.
• Nothing reaches production unreviewed and untested. The one exception is an emergency fix during an incident: made by the on-call engineer - a person, not an agent - with the separate break-glass credential, not the everyday one, and recorded in the incident timeline - and the same day it goes into code through the normal review and tests.
• Aim for one failure domain per change and one blast radius per rollout. Not every change can be split; the test is whether it has a single clean rollback.

What this means in practice:

• When the platform changes, AI writes proposals - code, manifests, pull requests - and each goes through the same hooks, CI and human review as a person’s.
• When the platform runs or is failing, AI reads - logs, metrics, traces - and suggests runbook steps. Where an action is pre-approved, it may take exactly that action and nothing more: the AI SRE Guardian in Chapter 14 can read Kubernetes resources but not change them - no writes, not even Events, and no Secrets. It reports its findings - to Slack where a webhook is configured, to its own log on a local cluster - and a person decides.

Decision Flow

What You Will Build

By the end of this course you will have a platform built with production practices running end to end - practised on a local kind cluster on your own machine, with Hetzner as the optional Cloud track. The practices are production’s; the topology is a training one: one worker node, databases with one or two instances, backups with the same provider as the cluster (on kind, on your own machine). The chapters say where that matters, and what running real users’ production on it would add - more nodes, more instances, a second place for the backups. The dashed boxes are the Advanced track:

• Provision — infrastructure as code with Terraform (a local kind cluster; Hetzner as the optional Cloud track)
• Store & Version — Git workflows, secrets management with SOPS
• Build & Gate — CI/CD pipelines with pre-merge guardrails
• Deploy — GitOps via Flux, continuous reconciliation
• Harden — network policies, security contexts, resource limits; admission policies in the Advanced track (Chapter 16)
• Promote — the image tested in staging goes to production as it is: retagged, never rebuilt
• Observe — metrics, logs, traces; backup and restore
• Break & Heal — chaos engineering to prove resilience
• Automate — AI SRE guardian for 24/7 operations
• Keep Over Time (Advanced) — signed images, safe rollbacks and canaries, platform upgrades, credentials and access with an end, disaster recovery (Chapters 17-22)

How Every Lesson Works

1. What would AI propose (the brave junior)?
2. What should we not allow?
3. What guardrail stops it?
4. What is the safe workflow?

Next Steps

The course assumes you are comfortable with Docker, Git and a terminal, and know the Kubernetes basics - Pods, Deployments, Services and kubectl.

1. Set up your lab - Chapter 00: Your Lab Environment. Every hands-on chapter from 02 onwards runs on it. make check-tools tells you first whether your machine is ready; the build then takes 30-45 minutes, mostly waiting for images.
2. Then read Chapter 01: Blast Radius & the Shape of Safety, once your cluster is green and the Chapter 00 quiz is done. About 15 minutes, almost no commands: one incident, the four rules for every change, and the layers of the platform that stop a mistake - the ideas every later chapter uses.