What this track is, and when the cluster earns its keep
Class Twenty-Six taught you what a container image carries. Now you need a service to run it. Azure offers several options, including App Service, Container Apps, and Azure Kubernetes Service (AKS). This track focuses on AKS: a managed Kubernetes control plane plus the nodes and workloads your team configures. Learn its boundaries first so you can choose it for a real requirement, rather than because a job posting mentions it.
AKS gives a team Kubernetes APIs and control over cluster configuration, node pools, networking, and operators. That control also brings work: upgrades, workload security, monitoring, capacity, and incident response. A custom operator or platform requirement may justify it; a simple web app may be easier to run on a more managed service. Compare the requirement with the operating effort before creating a cluster.
Decline it from knowledge, not from fear.
A cluster, drawn once — the line Azure runs, and the line you run
A cluster has two key parts. The control plane receives requests through the API server, schedules workloads, and stores desired state. Azure manages those components in AKS. The Free tier has no cluster-management charge, but no uptime SLA.1 A node pool contains Azure VMs that run pods. Your team chooses capacity, upgrades supported versions, and secures its workloads. Node compute is billable, and a lab may also create billable disks, networking, logs, or other resources. “Free tier” describes the management tier, not the whole cluster.
For normal application management, kubectl talks to the API server. A Deployment can state that three replicas should exist. If you delete one of its pods, the Deployment controller notices the gap and creates a replacement, provided the cluster has capacity and the image can start. A pod created without such a controller would not be replaced automatically. This is the reconciliation loop: compare desired state with observed state and act on the difference.
The track — seven parts, beginner to production
The rest of Class Twenty-Seven is seven pages, each a full class in its own right with its own drills and its own lab notes. Read them in order the first time; they are built to be read that way, each one standing on the last. Later they work as reference — the page you reopen the week you actually have to do the thing.
- 27a · Fundamentals
- Clusters and node pools, kubectl, pods, Deployments, Services, and namespaces. The nouns, made concrete by deploying something and watching the reconciliation loop heal it. Paired with the free-tier lab.
- 27b · Workloads & config
- ConfigMaps and Secrets, liveness and readiness probes, resource requests and limits, and the two autoscalers — the Horizontal Pod Autoscaler for pods and the cluster autoscaler for nodes. How a workload behaves under load and failure.
- 27c · Networking
- How traffic gets in and how pods reach each other: cluster DNS, Services, ingress controllers, the Azure CNI Overlay networking mode, network policies, and private clusters. The half of Kubernetes that breaks most confusingly.
- 27d · Storage
- Why a pod's disk vanishes when it restarts, and the fix: persistent volumes, claims, storage classes, and the Azure Disk and Azure Files CSI drivers — including the one-writer-versus-many rule that decides which you pick.
- 27e · Security
- Who may touch the cluster and what a pod may touch back: Microsoft Entra integration and Azure RBAC, Workload Identity instead of stored secrets, image scanning with Defender for Containers, and Pod Security Admission.
- 27f · Operations
- Keeping it alive and affordable: cluster and node-image upgrades, the managed Prometheus and Grafana stack with Container Insights, and reading a cluster's cost before it reads your budget.
- 27g · Production & GitOps
- The step from "it runs" to "a team can run it": Helm for packaging, blue/green and canary releases, and GitOps with Argo CD or Flux so the cluster's state lives in Git, not in someone's shell history.
The one habit that makes the rest cheap to learn
Beginners fight Kubernetes by memorising commands. Engineers who get good at it internalise one habit instead: write down the desired state, apply it, then ask the cluster what it observes. Almost every command you will meet is one of those three moves. kubectl apply -f submits desired state. kubectl get and kubectl describe ask what the cluster observes and why it disagrees with you. Debugging is reading the gap between the two out loud — "I asked for three, it has two, describe says the third is Pending because no node has room" — and that sentence, not a memorised flag, is what fixes the outage.
This is why the track spends its first lab making you delete a pod and watch it return. It is a small trick and a large idea: you are not managing containers, you are managing a statement of intent that a machine defends on your behalf. Everything after — probes, autoscalers, ingress, upgrades — is more intent, defended the same way. Learn the loop in §27a and the remaining six parts cost a fraction of what they cost the engineer who is still memorising.
Your first cluster, with a cost check
The linked lab creates an AKS cluster, deploys an app, and removes the lab resources. The Free management tier has no cluster-management charge, but the node VM and any storage, public IP, load balancer, logging, or network usage can be billed. Check current Azure prices and your subscription's quota before starting; monitor the resource group until deletion completes.
Open the lab — First AKS cluster →The interview, and why this track is worth the weeks
Kubernetes fluency is one of the widest pay gaps a cloud engineer can close, precisely because so many people list it and so few can draw the picture in Figure 1 without hedging. The senior signal is not reciting that etcd stores cluster state; it is the shape of your judgement. You can say what a cluster is in two sentences, you know the one habit that makes it debuggable, and — the part that wins the room — you know when not to reach for it, because you learned the last class first. That combination, competence without evangelism, is rarer than either half alone and is exactly what a hiring manager is straining to detect.
So treat the seven parts as an investment with a legible return: each one is a paragraph you can say in an interview and a task you can do on the job, and together they move you from "I've heard of Kubernetes" to "I can run one and I know when I shouldn't." The rest of this hub — the drills below, the case file — rehearses the judgement. The parts build the hands.
The requirement that finally names Kubernetes
For four classes Campux was right to avoid Kubernetes, and it did. Then a business fact arrives that no amount of Container Apps discipline routes around: a wholesale partner will integrate only against a platform that runs a specific open-source API gateway and its custom Kubernetes operators, deployed the partner's way, with network policies the partner audits. This is not fashion. It is a signed requirement that names Kubernetes' surface — operators, fine-grained network policy, a portability mandate — and for the first time the answer to "do we need a cluster?" is an honest yes.
So Campux's first cloud engineer — you — does the grown-up version of the enthusiast's mistake. Not "we heard Kubernetes is the standard", but "a contract requires this surface, here is the smallest cluster that satisfies it, here is who operates it, and here is the cost of that person's time." The storefront stays on App Service; the batch job stays on Container Apps; only the partner integration moves to a small, deliberately boring AKS cluster. This class is how you build that cluster without it becoming the pager that eats the team — the exact fate §3 of the last class warned about, now met on purpose and on budget.2
The engineer who can run it, and won't unless asked
A contract, not a trend, has made a cluster the right answer. You stand one up that is small, boring, and exactly the size of the requirement — free control plane, a couple of nodes, upgrades scheduled, cost watched. You can do this because you learned it in order, from the picture up; and you are trusted with it because everyone watched you decline it four times when the requirement wasn't there.
Examination
Four drills, then two situations. These test the judgement the track is built on; the hands are built in the seven parts. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. The managed control plane — API server, scheduler, store — is Azure's to patch and size, and free on the Free tier; the nodes are ordinary VMs in a scale set, and they bill whether busy or idle. C is the expensive misreading that ends careers of clusters: "the control plane is free" gets remembered as "AKS is free", a demo node is left running over a weekend, and Monday brings a bill for a workload that served nobody. A and D invert who runs what. The whole cost discipline of this class is the one word C drops: the node is never free.
B. This is the reconciliation loop you will spend the track internalising. You did not delete "the app"; you deleted one pod out of a desired-state document that says three should exist. A controller compared "should be three" with "is two" and closed the gap — new pod, new name. This is not a bug to route around; it is the entire point, and the reason you scale a Deployment by editing its desired count rather than starting containers by hand. C invents a cache that does not exist. D is close enough to sound right but wrong in mechanism: it is not the node restarting a container, it is a controller recreating a pod to satisfy intent.
The mandate, the exposed-surface need, and the portability requirement. Each names something Kubernetes' full surface provides and a managed platform does not — that is what a real reason looks like: a requirement, not a mood. The two rejects are the two most common ways clusters get built by accident. "Industry standard" is the sound a decision makes when nobody priced it, and résumé-driven infrastructure spends the company's headcount to decorate an individual's CV. Both feel like reasons and are not; catching the difference in a design review is precisely the judgement that gets you promoted past the person who built the accidental cluster.
# plan: AKS cluster for the partner API-gateway integration
1. Control plane on the Free tier while we build; move to
Standard for the SLA on the day the partner goes live.
2. One system node pool, two small nodes, cluster autoscaler on.
3. Leave the dev cluster running full-time so it is always
ready for a demo.
4. Upgrades scheduled monthly; node images on an auto channel.
Line three. The control plane is free, so the instinct "the cluster is basically free, leave it up" feels harmless — and it is exactly the trap Drill 01 set. A dev cluster's nodes are VMs; left running full-time they bill twenty-four hours a day to be ready for a demo that happens for ten minutes a week. The fix is the one this bootcamp has taught since Class One: stop paying for idle. Start the dev cluster when someone needs it, or scale its user pool to zero between demos, and reclaim the other twenty-three-and-a-half hours.
The other lines are healthy. Line one costs nothing, so under this drill's own test — which line pays for nothing? — it cannot be the answer (A). It is also a defensible call while the integration is still being built and carries no partner traffic, and it names its own upgrade trigger: Microsoft positions the Free tier for development and test, so the day the partner starts sending real requests you move the cluster to Standard for the API-server SLA. That is a scheduled upgrade, not a day-one reflex. Two small nodes with the autoscaler on is a sane starting shape that grows on demand (B). And scheduled upgrades with an auto node-image channel is the §27f discipline working as designed, not a hazard (D). When a plan mentions "leave it running", the reviewer's reflex question is the same every time: which line pays for idle? Here, line three.
Praise the energy before you touch the premise. Someone who spent three days learning Kubernetes and immediately tried to apply it is exactly who you want on a team; open by saying so, because the goal is to redirect the enthusiasm, not extinguish it. Then name the premise under review: "one platform is simpler" is true for the operator's mental model and false for almost everything else that matters. Consolidating onto AKS does not remove complexity; it moves the storefront and the batch job from platforms Azure operates for free onto a platform your team now operates — upgrades, nodes, ingress, the pager — for work that never needed it.
Count the cost in the currency the last class taught: people. The storefront is happy on App Service with no cluster to tend; the batch job scales to zero on Container Apps and bills eight minutes a day. Move them to AKS and they bill nodes around the clock and inherit every upgrade and incident the cluster has. "Simpler" would have made the case-file requirement — a partner mandate — the reason the whole estate got more expensive and more fragile. The cluster exists to satisfy one contract; it should stay exactly the size of that contract.
Close with the rule, so the next PR writes itself. Workloads live on the lowest-operations platform that meets their requirement, and they move up only when a requirement forces them. The partner integration was forced; the storefront and batch job are not. Offer the teammate the good version of their instinct: keep the cluster boring and small, and point that appetite at making it excellent — the §27g GitOps, the §27f cost dashboard — rather than at feeding it workloads that were already fine. That is the difference between a platform and a pet.
Draw the two boxes before you say a word. The whole answer is Figure 1, and drawing it first proves you hold a model rather than a vocabulary list. Top box: the control plane — "the brain: one API server everything talks to, a scheduler that places work, a store that remembers what you asked for. On AKS, Azure runs this and it's free." Bottom box: node pool — "ordinary VMs that run the containers; these are mine and they cost money whether they're busy or not." A line between them: "this boundary is who gets paged." Ninety seconds, two boxes, one line — you have already outperformed most candidates.
Then give them the one idea, not the noun zoo. "The thing that makes it click: you don't command it, you declare to it. I hand the API server a document that says 'three copies of this should exist', and a controller spends forever making reality match — delete one and it comes back. Everything else — health checks, autoscaling, ingress — is more of that same loop." Naming the reconciliation habit is what a senior does; reciting that etcd stores state is what someone who read the glossary does.
Land it with judgement, because that is what they are buying. Close on the sentence the rest of the field forgets: "And I reach for it when a requirement actually needs its surface — operators, mesh, fine-grained policy — not by default, because for most workloads a managed platform is the same containers without a cluster to run." Competence plus restraint, in ninety seconds, drawn not recited: that is the answer that ends the Kubernetes question early and moves the interview to salary.
Five things worth carrying out of this hub
- A cluster is two halves: the control plane Azure runs for free, and the node pool of VMs you pay for by the hour. An idle cluster with a running node is never free — the node is.
- You manage a statement of intent, not containers. Submit desired state, and a reconciliation loop defends it forever — delete a pod and it returns. Debugging is reading the gap between desired and observed out loud.
- Reach for AKS only when a requirement names Kubernetes' surface — operators, mesh, fine-grained policy, GPU pools, portability. "Industry standard" and "for our résumés" are not requirements.
- The track is seven parts, beginner to production: fundamentals, workloads & config, networking, storage, security, operations, and production & GitOps. Read them in order once, then keep them as reference.
- The interview reward is competence plus restraint: draw the two boxes, name the loop, and say when you would decline. Rarer than either half alone, and exactly what closes the pay gap.
- "Free" means the Free tier, which gives you a managed control plane with no charge for cluster management and best-effort uptime — no financially backed SLA. Microsoft positions it for development, test, learning and other non-production work, and recommends it for clusters under ten nodes. The Standard tier turns on the uptime SLA for the API server — 99.95 per cent with availability zones, 99.9 per cent without — for a per-cluster hourly fee, and is the tier for production. The Premium tier adds that SLA plus twenty-four-month Long Term Support on the Kubernetes version. None of these tiers touch the node bill, which is separate and always present. Quote the current Azure pricing page before you promise a number; tiers and prices move. ↩
- The "small and boring" instinct is doing real work in that paragraph, and it is worth distrusting your own excitement to keep it. Every operational feature the next seven parts add — autoscaling, ingress, mesh, GitOps — is capability you must also operate. Add only what the requirement names, when it names it. A cluster that grows by appetite rather than by requirement is how the people-price in the last class stops being a warning and becomes your calendar. ↩
Choose between Container Apps, AKS and App Service for containers, and stand up a first AKS cluster.