Same seven-block shape as every session in this program:

• Pain first — the world without the thing.
• What it is, and where it sits on the architecture map.
• Why this choice, and which alternatives were rejected, with reasons.
• Six-pillar scorecard — operations, security, reliability, performance, cost, sustainability.
• Code walk — the real declaration, not a screenshot of one.
• Lab — you run it, in your own sandbox account.
• Break it — the instructor breaks it, the room debugs it.

Session 1 has no cloud lab. It has calculators and steppers, and a self-check gate at the bottom you must clear before session 4.

• TTL set too high before a cutover. You cannot revoke a cached answer. Drop the TTL to 60 seconds at least one full old-TTL period before the change window, then raise it after.
• Negative caching. A failed lookup during a brief outage is cached as “does not exist”. The fix lands and the name stays broken for the negative TTL.
• Split-horizon surprises. A private zone answers differently inside the network than outside it. “It resolves from my laptop” proves nothing about the cluster.
• Apex records. The root of a domain cannot hold a CNAME. Providers work around this with a proprietary alias record — which is why apex behaviour differs per provider.
• Registrar and zone disagree. The zone can be flawless and still invisible if the registrar points at different nameservers.

Inside a cluster, service discovery is this same protocol with a very short TTL — which is why a resolver problem there looks like every service failing at once.

• The server sends leaf and intermediates. It never sends the root.
• Hostname matching uses the SAN list. The legacy common name is ignored by modern clients.
• Validity is checked against the client's clock. A drifted clock is a TLS outage.
• Renewal must be automated. Short validity windows make manual renewal a scheduled outage.
• Never disable verification to clear an error. It converts “encrypted and authenticated” into “encrypted to someone unknown”, and the flag always outlives the debugging session that introduced it.
• Validate the served chain from outside your network. A machine that already trusts your internal certificate authority cannot detect a missing intermediate.

• Pick non-overlapping ranges across every environment and region — and write them down somewhere authoritative before anyone provisions. Two networks that must one day talk cannot share a single address.
• Leave room. A /16 per network costs nothing and removes the worst class of migration. Being thrifty with private address space buys you nothing.
• Three tiers, one per availability zone — internet-facing, private application, data. Nine subnets is the usual baseline.
• Container networking is hungry. Some cluster networking modes give every pod a real address from the subnet. A /24 that looks generous holds far fewer pods than you expect.
• Five addresses per subnet are reserved by the platform. A /28 yields 11 usable addresses, not 16.

• Processes and signals. A graceful shutdown is a termination signal the process chose to handle. Ignore it and the platform escalates to a kill that cannot be caught — which is how in-flight requests get dropped during every deploy.
• Exit codes. 0 is success. 137 means killed — usually the out-of-memory killer. 143 means it was asked to stop and complied. These three explain most restart loops.
• File descriptors. Sockets and files share one per-process limit. A leak surfaces as “too many open files” under load, never in testing.
• Namespaces and control groups. Namespaces limit what a process can see; control groups limit what it can consume. That is the whole of containerisation — session 10 only adds packaging on top.
• Standard output is the log. Anything a container writes elsewhere is invisible to the platform's log pipeline.
• Users. Running as the root user inside a container is a real privilege in most configurations, not a cosmetic one.

• A commit is the deployable unit. From session 9 onward the repository is the only write interface to infrastructure. “What is running in production” must be answerable as a commit identifier.
• A branch is a movable pointer, not a copy. That is why creating one is free and why deleting one destroys nothing that was merged.
• Rebase produces new commits. Same changes, different identity. Rebase your own unpublished work; merge anything others have already pulled.
• Merge keeps an honest record that two lines of work existed separately. Rebase keeps a linear story that is easier to read and easier to bisect.
• Tags mark releases and must be immutable. Moving a tag breaks every deployment record that referenced it.

At large scale these genuinely are separate teams. Below that scale, splitting them creates the exact handoff problem the practice exists to remove: the people who build something are no longer the people who are woken by it, so nothing gets built to be operable.

• The rule that makes it work: whoever writes it, runs it. Being paged by your own design is the fastest feedback loop in the industry.
• The rule that keeps it survivable: blameless review. A culture that punishes the engineer who broke production is a culture where nobody reports the near-miss, and near-misses are the cheapest data you will ever get.
• What this program does not cover: people management, hiring, and vendor negotiation — real parts of the seat, but not engineering skills.

• Nested boxes are trust and blast-radius boundaries — the cloud account, the private network inside it, the cluster inside that. Crossing an inward boundary should always cost you an authorisation check.
• Two front doors, deliberately. Console and authoring traffic enters through the firewall and load balancer into the cluster. High-volume runtime events enter through the API gateway into the stream. Neither can starve the other.
• Static delivery bypasses compute entirely. Runtime bundles are served from object storage through the delivery network, so page views do not become origin load.
• The three flows have three different cost shapes — authoring scales with authors, runtime with page views (mostly cached), analytics with event volume. The third is the one that grows without anyone deciding to grow it.

• Score honestly or do not score. A rubric filled in optimistically is worse than no rubric, because it converts an unknown into a false assurance.
• Every low score gets a priority, not an apology. The output of the exercise is a short ordered list of things to fix, most of which will never be fixed — and that is fine, as long as the decision was made deliberately rather than by forgetting.
• Compliance is an output, not a pillar. Audit evidence falls out of doing these six things and writing down that you did them. It is not separate work bolted on before a customer questionnaire.
• Do not publish a filled-in scorecard. A scored gap list is an ordered map of your weakest controls. Share the blank rubric; keep the answers internal.

• One artefact, promoted — never rebuilt. The thing tested in the first environment must be the identical thing that reaches the last one, addressed by content digest rather than by a tag someone can move. Rebuild per environment and production runs software that no environment ever tested.
• Every step reversible, and rehearsed. Deploys are reversible by rolling back to the previous artefact; schema changes are reversible by being backward-compatible for one release. A rollback path that has never been exercised is a belief, not a capability.
• Automated verdicts, not human judgement, at the gates. If passing a gate depends on somebody deciding, then under time pressure it will be decided in favour of shipping. Gates that block by themselves are the only ones that hold.

Sessions 10, 12 and 13 build this chain. Session 7 covers the migrate stage, which is the one that most often removes the ability to roll back.

• 3 is not a pass mark, and it is not a failure either. It means you have done what the industry considers the minimum. Most rows in a healthy estate sit at 3, and a scorecard that is mostly 4s and 5s on first attempt is almost always a scoring problem rather than an engineering achievement.
• The gap between 2 and 3 is documentation and repeatability, not cleverness. A thing one person does correctly from memory is a 2. The same thing written down and done the same way by anyone is a 3.
• The gap between 4 and 5 is external verifiability. A 5 means someone outside the team could confirm it without asking you a single question. That is a much higher bar than “we are confident”, and very few rows deserve it.
• “We deliberately chose not to” is a 3 with a note, not a 1. A 1 means nobody considered it. Recording the difference is the whole value of the exercise.

Twenty-five minutes, one component, six rows. One person drives, everyone argues. Write the evidence phrase before choosing the number — doing it the other way round invites the number to pick its own justification.

• Optimistic scoring. The most common failure by a wide margin. Symptom: no row below 3. Remedy: for any score of 4 or 5, the person proposing it must state what an outsider could check.
• Scoring without priority. Produces a wall of numbers nobody acts on. Every row below 4 gets a priority, including P3 — which explicitly means “we know, and we are deliberately not doing it”. That is a legitimate and useful answer.
• Treating recovery as tested because it is configured. The Reliability row is where this hides. “Backups are enabled” is a 2. “We restored on this date and it took this long” is a 4.
• Publishing the result. A filled scorecard is an ordered map of your weakest controls. It is internal. The blank rubric can be shared with anyone; the answers cannot. The Markdown export carries that warning in its footer for exactly this reason.

From session 4 onward this same card appears in every session with one component already selected. By session 13 the room will have scored twelve of them, and the pattern in which pillar is consistently weakest is usually more informative than any individual score.