THE DevOps CURRICULUM
Learn the idea first, then drill the questions that use it
An ordered route through what these loops assume you brought with you. Every page holds one idea, taken below the tooling, with a worked example, the trade-off a panel pushes on, and links out to the questions where it turns up. Read it start to finish, or drop into whichever track you know you are weakest in.
33 concepts across 12 tracks · foundational concepts are free · see them as a map
Begin the curriculum →01
🐧 Systems Foundations
What a container actually is once you strip the branding: namespaces, cgroups, signals, process state, and the TCP and DNS behaviour every incident eventually bottoms out in.
START HERE
01Namespaces and cgroups: what a container actually isFree
A container is not a thing the kernel knows about. It is an ordinary process with two kernel features applied to it: namespaces, which change what it can see, and cgroups, which change what it can use. Understanding that split explains most container behaviour that otherwise looks like magic, including why a container can see the host's memory and size itself wrong.02Everything is a queue, and the queue is where the latency livesFree
A packet queues at the NIC, a connection queues in the accept backlog, a request queues for a worker, a query queues for a connection, a write queues at the disk. Queueing is one source of latency; service time, fan-out and network delay matter too. A queueing model is useful only when its assumptions match the workload.02
☁️ Cloud Architecture
Accounts, identity and the network before anything else. Least-privilege IAM, subnet and routing design, private connectivity, and the failure domains a region gives you for free.
01Failure domains: what a region, a zone and a cell actually buy youFree
Cloud availability is sold as a set of boundaries, and the whole discipline is understanding what each boundary contains. A zone separates physical infrastructure; a region adds geographic separation. Neither stops a bad deploy propagated to every replica.02The cloud control plane is a dependency you forgot to design aroundFree
Every recovery plan that involves launching instances, updating DNS or changing a load balancer depends on an API that may be impaired during the outage. Static stability means a system holds its current state without needing that API, which is what separates a plan that works during a bad day from one that only works during a rehearsal.03
☸️ Containers & Kubernetes
The control loop model, the scheduler's actual decision, how a pod gets an IP, why storage is the hard part, and where Kubernetes stops helping you.
01The control loop: the one idea Kubernetes is built onFree
Kubernetes controllers reconcile desired and observed state through the API. That model explains many stuck objects, while runtime operations still use direct calls to container runtimes, networking and storage systems.02CFS quotas and throttling: what a CPU limit really enforcesPremium
A CPU limit bounds CPU bandwidth over an accounting period; runnable work can be throttled when the group or an ancestor exhausts its quota. This concept gives the exact arithmetic, the diagnostic reading of cpu.stat, and the remediation debate that separates senior candidates.03Requests are what the scheduler believes, limits are what the kernel enforcesFree
Two numbers that look like a pair are read by two different systems for two different purposes. Requests decide placement and are a claim about the future. Limits decide runtime enforcement and are a cgroup setting. Nearly every strange capacity problem in Kubernetes comes from conflating them.04
🏗️ Declarative Infrastructure
State as the source of truth, why drift is inevitable, module boundaries that survive a second team, and the difference between idempotent and merely repeatable.
01State and drift: why infrastructure as code needs a ledgerCore
Terraform state is not a cache and not an optimisation. It is the mapping between the names in your configuration and the identifiers in the provider, and without it there is no way to know whether a resource in your code is the same resource that exists in the cloud. Every confusing Terraform behaviour, from destroy and recreate to import, follows from what state is for.02Immutable infrastructure, and the replacement nobody planned forFree
Immutability means a change produces a new resource rather than an edited one, which supports reproducibility when definitions and inputs are controlled. It also means some innocuous-looking edits destroy and recreate a live resource, and knowing which ones is the difference between a routine plan and an outage.05
🚀 Delivery & GitOps
Getting a change to production safely: build once and promote, the four deployment strategies and what each one buys, reconciliation loops, and rollback you have actually rehearsed.
01GitOps: reconciliation, not deploymentCore
GitOps is the Kubernetes control loop applied to your deployments: a controller compares live resources to versioned desired state and reconciles configured differences. The distinction from a pipeline that runs kubectl apply is not tooling preference. It changes what happens when someone edits the cluster directly, and it changes who holds cluster credentials.02Deploying is not releasingFree
Deployment puts code on a machine. Release exposes behaviour to a user. Treating them as one event is why rollbacks are frightening, why releases happen at night, and why a bad feature requires an emergency deploy instead of a config change.03Build once, and let the artifact be the unit that movesFree
Independent builds can differ even at the same commit. Promoting one artifact by digest makes it clear which bytes were tested, while configuration and runtime differences still need validation.04Delivery metrics: measure rework alongside speedFree
A team can deploy more often because it ships useful changes or because it keeps repairing broken ones. DORA's five-metric model separates delivery throughput from instability so those two stories do not look identical.06
📈 Observability & Reliability
Choosing indicators a user would recognise, the arithmetic of an error budget, why cardinality is the cost driver, and alerting on symptoms instead of causes.
01Error budgets: the arithmetic and the decision it forcesFree
An error budget turns reliability from an opinion into a number, and the number is only worth having if spending it changes a decision. The arithmetic takes ten seconds; the policy is the hard part, and the burn-rate alerting that falls out of it is what fixes on-call noise.02Cardinality and label discipline: why metrics explodeCore
Each observed label combination creates a series; independent dimensions can multiply the total, while correlated labels do not necessarily do so. This concept gives the arithmetic, the symptoms of cardinality blowups, and the discipline rules that keep dashboards fast and bills sane.03Alert on symptoms, not causesFree
A cause alert fires when something inside the system looks wrong. A symptom alert fires when users are affected. One of those is always going off and the other is worth waking someone for, and the difference explains most of what is wrong with a noisy on-call rotation.07
🚨 Debugging Production
A repeatable diagnostic method rather than a list of commands: narrowing the blast radius, reading the evidence a failure leaves behind, mitigating before root-causing.
01Diagnostic method: how to debug a system you did not buildFree
The troubleshooting round is not testing which commands you know. It is testing whether you narrow a search space deliberately, and whether you protect users before you satisfy your curiosity. The sequence below gives you a practical structure for impact assessment, hypothesis testing and recovery.02Cascading failure mechanics: how one slow dependency kills healthy servicesCore
Overload spreads through systems by arithmetic, not bad luck: latency multiplies in-flight work, exhausted pools stall every caller, and retries add load exactly when capacity is lowest. Knowing the three mechanisms and the budget that breaks each one turns the resilience chapter of any interview from vocabulary into reasoning.03Mitigate before you diagnoseFree
Understanding a failure and stopping it are different goals, and during an incident only one of them is urgent. The instinct to find the cause first is what turns a five-minute outage into an hour, and it is a useful failure mode to practice avoiding in an incident round.08
🛡️ Security in the Pipeline
Where each scanner belongs and what it cannot see, secrets that are never in an image, provenance you can verify, and identity-based controls that hold inside a cluster.
01Identity, not network position: the idea zero trust is actually aboutFree
Perimeter security assumed that being inside the network meant you were trusted. That assumption failed because the perimeter dissolved and because one compromised host inside it inherited everything. Zero trust replaces network position with verifiable identity as the basis for every decision, and almost every modern security control is an instance of that swap.02Your supply chain is a graph, and you only see the first layerFree
A service declares a dozen dependencies and ships a thousand. Every build tool, base image, CI action and transitive package is code you execute with your privileges, and the practical question is not how to trust all of it but how fast you can answer which parts you have.09
⚙️ Infrastructure at Scale
Napkin math before architecture, replication and consistency choices you can defend, capacity planning against growth, and designing for the failure you expect to have.
01Napkin math: sizing a system before you draw itCore
Design rounds put a number in the prompt on purpose. Arithmetic done in the first two minutes eliminates whole classes of architecture and is the difference between designing something and describing something. These are the reference figures and the method for using them.02Saturation and utilisation targets: why systems fall over before they are fullCore
Little's law relates average concurrency, throughput and residence time. Queueing models explain why variable demand needs headroom; measurements and the failure case determine the utilization target.03Idempotency is a design property, not a retry settingFree
Any network call can fail after the work was done and before the answer arrived, leaving the caller uncertain whether retrying will duplicate an effect. That fact makes duplicate delivery structural rather than exceptional, and the only durable answer is receivers that tolerate it.10
🧰 Platform & Cloud Economics
Treating infrastructure as a product with users, golden paths that people choose voluntarily, and the unit economics that decide whether a platform survives a budget review.
01Platform as a product: measuring adoption and developer outcomesCore
Treat the platform as a service for developers. Adoption reveals demand when teams have a choice; delivery outcomes, task completion and feedback reveal whether it helps, including where security or compliance requires its use.02A total nobody can divide is unmanageableFree
Cloud spend rising is not information. Cost per unit of business value is, because it separates a growing company from a leaking one, and those need opposite responses. Getting to that number is mostly an attribution problem, which is why tagging is the first project and not the tedious one.11
🤖 AI Infrastructure
Why GPU workloads break the assumptions Kubernetes was built on: scheduling whole devices, memory that cannot be overcommitted, and serving models with predictable latency.
01Why GPUs break the assumptions schedulers are built onCore
GPU scheduling must account for device memory, sharing boundaries and interconnect topology. Device plugins, MIG, DRA and gang scheduling address different constraints; none makes accelerators behave like interchangeable CPU millicores.02The KV cache is what decides how many users you can serveFree
Model weights, runtime memory and the KV cache compete for GPU memory. Estimate the cache budget and memory per sequence, then check whether that concurrency also meets your latency target.03Prefill and decode are two different workloads on one GPUFree
Prefill builds prompt state; decode extends each sequence token by token. Their bottlenecks depend on model, batch size and context length. Measure first-token and inter-token latency separately before choosing batching or disaggregation.04Model quality degrades without touching a single infrastructure metricFree
Classical dependencies and models can both return incorrect results without an error. A model fails by returning something plausible and wrong, which every status-code-based metric records as a success. Quality needs its own signals, its own threshold and its own budget, or it is unobservable until a customer complains.05Tokens are the unit of cost, latency and capacity at onceFree
Requests per second is the wrong unit for anything involving a model. Tokens determine what you pay, how long a request takes, and how many users fit on a GPU, which is why capacity, cost and latency stop being three separate conversations.06An agent can act as a confused deputyFree
The confused deputy is a longstanding security problem: a privileged program acting on instructions from someone less privileged. An agent that reads untrusted text and holds credentials is exactly that, which is useful, because it means the defences are known and none of them is a better prompt.12
🤝 The Engineering Craft
The half of the loop most engineers under-train: telling an incident story that shows judgement, quantifying risk in business terms, and driving change without authority.