From de6c5b3286d15948f1225873397a9a8192c0cbee Mon Sep 17 00:00:00 2001 From: ced4568 Date: Wed, 26 Aug 2026 09:08:01 -0500 Subject: [PATCH] feat(root): build Real Ops and capstone readiness content MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit root-12-real-ops gains a Detect -> Triage -> Diagnose -> Mitigate -> Recover -> Verify -> Learn incident-response framing lesson at the front of the existing 4-incident module, and a post-incident reflection at the end — the incidents themselves are unchanged, still deliberately un-guided ('you are responsible for this environment,' not 'complete this exercise'). No fixes revealed; instructor notes carry the deeper solution guidance the student-facing lesson intentionally withholds. root-capstone-m02-capstone-readiness — a new READY orientation module: what the Capstone measures, how the timed/randomized draw works, time management and troubleshooting strategy under a clock, and a genuine self-assessment checklist. Never publishes the current draw or answers. See docs/ROOT_CAPSTONE_READINESS.md for why this module's completion is deliberately independent of the real capstone's server-side unlock gate. Co-Authored-By: Claude Sonnet 5 --- .../00-lesson-incident-response.md | 88 +++++++++++++++++++ .../99-reflection-post-incident.md | 47 ++++++++++ .../01-lesson-what-it-measures.md | 72 +++++++++++++++ .../02-lesson-time-management.md | 66 ++++++++++++++ .../03-knowledge-check.md | 58 ++++++++++++ .../04-reflection-readiness.md | 42 +++++++++ 6 files changed, 373 insertions(+) create mode 100644 content/root/root-12-real-ops/m01-real-ops-incidents/00-lesson-incident-response.md create mode 100644 content/root/root-12-real-ops/m01-real-ops-incidents/99-reflection-post-incident.md create mode 100644 content/root/root-capstone/m02-capstone-readiness/01-lesson-what-it-measures.md create mode 100644 content/root/root-capstone/m02-capstone-readiness/02-lesson-time-management.md create mode 100644 content/root/root-capstone/m02-capstone-readiness/03-knowledge-check.md create mode 100644 content/root/root-capstone/m02-capstone-readiness/04-reflection-readiness.md diff --git a/content/root/root-12-real-ops/m01-real-ops-incidents/00-lesson-incident-response.md b/content/root/root-12-real-ops/m01-real-ops-incidents/00-lesson-incident-response.md new file mode 100644 index 0000000..30ea2bb --- /dev/null +++ b/content/root/root-12-real-ops/m01-real-ops-incidents/00-lesson-incident-response.md @@ -0,0 +1,88 @@ +# The RootNode Incident-Response Framework + +## This module feels different on purpose + +Everything before ROOT 12 asked you to complete an exercise. This module asks something +different: **you are responsible for this environment.** The incidents in this module are +modeled on real operational failures — not textbook exercises designed to teach one clean +concept, but the kind of messy, "why is this actually broken" situations a real on-call engineer +gets paged for. + +## Detect → Triage → Diagnose → Mitigate → Recover → Verify → Learn + +This is a lightweight incident-response framework — not enterprise incident management +tooling, just a way of thinking that scales down to "one engineer, one broken thing" as well as +it scales up to a real incident-response team. + +**Detect** — something alerted you (a monitoring page, a user report, or in this Lab's case, +the scenario telling you something is wrong). You know an incident exists before you know what +it is. + +**Triage** — how bad is this, right now, before you dive into root cause? Is anything actively +getting worse? Is this affecting one thing or cascading into others? Triage decides how urgently +you act, before you fully understand why. + +**Diagnose** — this is where ROOT 10's troubleshooting framework (Observe, Gather Evidence, Form +Hypothesis, Test) does its work — the specific mechanics of finding the actual cause. + +**Mitigate** — the fastest safe action that stops things from getting worse, which is not always +the same as the final fix. Sometimes mitigation and repair are the same step; sometimes +mitigation buys time (e.g. temporarily reducing load) while a proper fix is prepared. + +**Recover** — restore the system to its actual working state — not just "stopped getting worse" +but genuinely operational again. + +**Verify** — confirm recovery with real evidence, the same discipline as ROOT 10's Validate +step. "I think it's fixed" is not the same as checking. + +**Learn** — what would prevent this exact class of incident from happening again? This is where +`rootnode-enforce-limits` picks up directly after `rootnode-runaway-monitor` — not a separate +topic, but the deliberate "Learn" step of the SAME incident, made into its own scenario. + +## What this module will NOT tell you + +The specific fixes for each incident are not in this lesson, and instructor notes on the +individual incident activities go deeper than what's shown here — this module gives you the +FRAMEWORK for approaching an unfamiliar incident, not a cheat sheet for these specific four. +That's deliberate: a framework you had to apply yourself is one you'll actually remember under +real pressure. + +## Instructor Notes + +**Lesson goal:** Set the tone shift for this entire module — from "complete an exercise" to +"you own this." This lesson is short by design; the real teaching happens through the incidents +themselves. + +**Approximate timing:** 15 minutes read; 10 minutes live framing discussion. + +**Preparation:** Read each incident's own instructor notes (in the Lab activities below) before +teaching this module live — several contain deeper solution guidance not repeated here, +specifically so students still have to work for it. + +**Demonstration plan:** Not applicable to this framing lesson — the four incidents themselves +serve as the demonstrations. + +**Likely misconceptions to watch for:** +- Students sometimes treat "Mitigate" and "Recover" as the same step. They can be, but aren't + always — worth naming a real-world example (rolling back a bad deploy mitigates immediately; + fully recovering might still require redeploying the CORRECT version afterward). +- "Learn" is the step most likely to get skipped once a Lab is marked complete. Explicitly + connect it to why `rootnode-enforce-limits` exists as its own scenario. + +**Questions to ask students:** "Which step of this framework do you think real teams are worst +at, under real pressure, and why?" (There's no single right answer — the goal is getting +students to reason about incident response as a discipline, not just a checklist.) + +**When to let a student struggle vs. provide a hint:** These incidents are intentionally less +guided than earlier modules. Let a student sit with "I don't know where to start" for a few +minutes before nudging — the discomfort of a genuinely unfamiliar failure is part of what this +module is teaching. Redirect toward the Diagnose step's ROOT 10 framework if truly stuck, rather +than pointing at the specific fix. + +**Optional extension:** ask students to write a two-sentence incident summary for +`rootnode-runaway-monitor` as if posting it to a real team channel — Detect/Diagnose/Recover in +plain language, no jargon. + +**Expected takeaway:** A framework applied under pressure beats improvisation, even for +engineers who are technically skilled enough to eventually stumble into the right answer anyway +— the framework is what makes the RIGHT answer arrive faster and more reliably. diff --git a/content/root/root-12-real-ops/m01-real-ops-incidents/99-reflection-post-incident.md b/content/root/root-12-real-ops/m01-real-ops-incidents/99-reflection-post-incident.md new file mode 100644 index 0000000..435a358 --- /dev/null +++ b/content/root/root-12-real-ops/m01-real-ops-incidents/99-reflection-post-incident.md @@ -0,0 +1,47 @@ +# Post-Incident Reflection: What Real Ops Actually Feels Like + +You just worked through four incidents that "own it, don't just complete it" framing described. +Take a few minutes to reflect on the module as a whole, not just any single incident. + +## Reflection questions + +1. Which of the four incidents took the longest to even understand what was actually wrong, + before you got to fixing anything? What made diagnosis slower there than the others? +2. `rootnode-runaway-monitor` and `rootnode-enforce-limits` are the same underlying incident, + split into "fix it now" and "prevent it forever." Which one did you find more satisfying to + solve, and why do you think real teams sometimes skip the second one under time pressure? +3. If you were handing these four incidents off to a teammate mid-shift, what's the one-sentence + summary you'd give for each, so they could pick up without re-diagnosing from scratch? +4. Compare how this module felt to the earlier, more guided modules in ROOT_. What specifically + was different about the experience, not just the difficulty? + +## Real Ops takeaway + +**"It's fixed" and "it won't happen again" are two different jobs, and skipping the second one +is how the same incident recurs.** `rootnode-enforce-limits` exists as its own scenario +specifically to make this point structurally, not just rhetorically — the immediate fix and the +prevention work are genuinely separate efforts, and a real team's incident isn't actually closed +until both are done. + +**Being handed an unfamiliar, under-specified problem is the actual job.** Every other module in +ROOT_ told you roughly what concept you were about to practice. This one didn't — and that gap +is deliberate, because real production incidents don't come with a syllabus telling you which +concept they're testing. The framework from this module's opening lesson is what you reach for +instead of a hint system. + +This module is complete. If a Capstone is part of your program, its readiness module is next. + +## Instructor Notes + +**Discussion questions for a live classroom:** question 2 is the module's core point — spend +real time on it rather than treating it as a quick check-the-box question. + +**Approximate timing:** 10-12 minutes live discussion; 8 minutes self-paced writing. + +**Optional extension:** ask students to identify which incident from this module most closely +resembles something they'd expect to encounter in an actual job, and why — grounds the module in +something beyond the classroom. + +**Expected takeaway:** Real operational work is less about knowing every possible failure mode +in advance and more about having a repeatable process for approaching the ones you've never +seen before. diff --git a/content/root/root-capstone/m02-capstone-readiness/01-lesson-what-it-measures.md b/content/root/root-capstone/m02-capstone-readiness/01-lesson-what-it-measures.md new file mode 100644 index 0000000..13c4dd4 --- /dev/null +++ b/content/root/root-capstone/m02-capstone-readiness/01-lesson-what-it-measures.md @@ -0,0 +1,72 @@ +# What the Capstone Measures & How the Draw Works + +## What the RootNode Capstone is actually testing + +The Capstone is not a test of memorized `kubectl` syntax. It's a 90-minute operational +assessment weighted heavily toward RootNode's own Real Ops incident scenarios — it's checking +whether you can DO the thing ROOT_ has been building toward: diagnose and repair real, +under-specified problems using the frameworks and skills from every course before it, under a +clock, without step-by-step guidance. + +If you've completed ROOT 05 through ROOT 12 honestly (not just clicked through), the Capstone is +testing exactly what you've already practiced — just without a lesson telling you which concept +is about to be tested. + +## How the scenario draw works + +The Capstone draws a mix of: + +- **Required scenarios** — every attempt includes RootNode's own Real Ops incidents (the same + scenarios from ROOT 12, though a fresh attempt against them, not literally the same completed + attempt carried over). +- **Randomly drawn scenarios** — a smaller number of additional scenarios, randomly selected + from broader pools spanning workloads, configuration, and troubleshooting. + +This means two students taking the Capstone will very likely see a different exact mix of +random scenarios, while both always face the same core Real Ops incidents. The exact scenario +IDs and the random draw itself are never published in advance — see the next lesson for why +that's intentional, not withheld information. + +## What "unlocked" actually means + +The Capstone doesn't unlock just because you decided you're ready — it unlocks when the +platform confirms, server-side, that you've genuinely completed every prerequisite stage +(Foundation, Workloads, Networking, Configuration, Troubleshooting, and Real Ops). This isn't a +UI suggestion you can bypass; it's enforced the same way everywhere you'd try to start it. If +you see a "locked" message, the platform is telling you something true about your actual +progress, not gatekeeping arbitrarily. + +## What completion means + +Passing the Capstone requires resolving every scenario in your specific draw — this is recorded +as a real, permanent achievement (`capstone_completed`) tied to your account, the same +achievement mechanism that recorded every stage completion before it. It's the platform's own +confirmation that you can operate a Kubernetes environment under exam conditions, not just that +you clicked through a curriculum. + +## Instructor Notes + +**Lesson goal:** Set accurate expectations before a student attempts the real assessment — +reduce anxiety from not knowing "what kind of thing" the Capstone tests, without revealing any +specific content. + +**Approximate timing:** 10 minutes read; 8-10 minutes live. + +**Preparation:** None beyond having completed ROOT 12 yourself if teaching this live, so you can +speak concretely about the Real Ops incidents' style without naming specifics from the current +draw pool. + +**Likely misconceptions to watch for:** +- Students sometimes think "random draw" means the Capstone is inconsistent/unfair between + attempts. Clarify: the REQUIRED Real Ops scenarios are constant across every attempt; only a + smaller supplementary set is randomized. +- "It's locked, so something's broken" — reinforce that a locked Capstone is the platform + correctly reporting incomplete prerequisites, not a bug. + +**Questions to ask students:** "Which ROOT_ course do you feel least confident about right now? +What would you do about that before attempting the Capstone?" — a good self-assessment prompt +that ties directly into the next lesson's time-management content. + +**Expected takeaway:** The Capstone measures real operational capability built across the whole +ROOT_ sequence — approaching it as "one more scenario to guess your way through" misses the +point of everything that led up to it. diff --git a/content/root/root-capstone/m02-capstone-readiness/02-lesson-time-management.md b/content/root/root-capstone/m02-capstone-readiness/02-lesson-time-management.md new file mode 100644 index 0000000..42ce88a --- /dev/null +++ b/content/root/root-capstone/m02-capstone-readiness/02-lesson-time-management.md @@ -0,0 +1,66 @@ +# Time Management & Troubleshooting Strategy Under a Clock + +## 90 minutes, several scenarios — budget before you start + +Once the Capstone begins, the clock is running against the whole attempt, not per scenario. +Spending 60 of your 90 minutes perfectly solving one incident, then rushing (or failing to +attempt) the remaining ones, is a worse outcome than solving most scenarios well within a +reasonable time each. Before diving into the first incident, take 60 seconds to look at how many +scenarios you're facing and roughly divide your available time — treat that budget as a real +constraint, not a suggestion. + +## Apply the frameworks you already have — don't invent a new approach under pressure + +You've already practiced two frameworks across ROOT_: + +- **Observe → Gather Evidence → Form Hypothesis → Test → Repair → Validate → Prevent Recurrence** + (ROOT 10) for the mechanics of diagnosing a specific technical failure. +- **Detect → Triage → Diagnose → Mitigate → Recover → Verify → Learn** (ROOT 12) for the + broader "you own this incident" framing. + +Under time pressure, the temptation is to abandon structure and start guessing. Resist it — the +frameworks exist precisely because they're FASTER than guessing once you've internalized them, +not slower. Reach for the same habits: read `kubectl describe`/Events before assuming, state +what you think is wrong before changing anything, verify after you fix. + +## When to move on + +If you're genuinely stuck on one scenario well past its budgeted time with no new evidence +emerging, it is a legitimate strategic choice to move to a different scenario and return later +if time allows — partial credit on more scenarios can beat a perfect score on fewer. This isn't +giving up; it's the same triage instinct from the incident-response framework, applied to your +own time as a resource. + +## What's genuinely allowed + +Everything you've used throughout ROOT_ Labs remains available: `kubectl` and its full command +set, the Lab's own in-context hints (if the specific scenario offers them), and your own notes +from earlier modules. There is no expectation of memorizing anything you'd normally look up — +the Capstone tests operational judgment and diagnostic process, not recall of obscure flags. + +## Instructor Notes + +**Lesson goal:** Reduce a common source of avoidable Capstone underperformance — poor time +allocation — separately from technical skill gaps. + +**Approximate timing:** 10 minutes read; 8 minutes live. + +**Demonstration plan:** If teaching this live, consider a quick show-of-hands: "who has ever +spent way too long on one problem and run out of time for an easier one elsewhere?" — normalizes +the behavior this lesson is trying to prevent. + +**Likely misconceptions to watch for:** +- Students sometimes think asking for more time or pausing mid-scenario is against the rules. + Clarify based on your actual classroom/platform policy rather than assuming — this varies by + delivery mode and isn't something this lesson should guess at. + +**Questions to ask students:** "If you had to guess right now, which TYPE of scenario (not a +specific one) do you think would eat the most of your time, and why?" — surfaces self-awareness +about weak areas before the real attempt. + +**When to let a student struggle vs. provide a hint:** This lesson itself needs no struggle — +it's orientation, not a challenge. Save "let them struggle" judgment for the actual Capstone +attempt. + +**Expected takeaway:** Time management under the Capstone's clock is a skill you can prepare for +explicitly, separate from and in addition to the technical skills the rest of ROOT_ built. diff --git a/content/root/root-capstone/m02-capstone-readiness/03-knowledge-check.md b/content/root/root-capstone/m02-capstone-readiness/03-knowledge-check.md new file mode 100644 index 0000000..f2492bd --- /dev/null +++ b/content/root/root-capstone/m02-capstone-readiness/03-knowledge-check.md @@ -0,0 +1,58 @@ +# Readiness Check: Are You Actually Ready? + +This isn't a graded quiz — it's a genuine self-assessment before you attempt something you can't +easily "retry with different answers memorized." Answer each honestly. + +--- + +**1. Can you explain, without looking it up, the difference between a liveness probe and a +readiness probe, and diagnose which one is failing from `kubectl get pods` output alone?** + +*If no:* revisit ROOT 10's gold-standard Health Probes module before attempting the Capstone — +this exact distinction shows up in Real Ops-style incidents. + +--- + +**2. Given a Service with zero Endpoints, do you know the first two commands you'd run to find +out why, without being told which module this relates to?** + +*If no:* revisit ROOT 07's Services & Service Discovery module. + +--- + +**3. Can you apply the Observe → Evidence → Hypothesis → Test → Repair → Validate → Prevent +framework to an unfamiliar failure you've never specifically seen before, not just to the exact +examples from the lesson?** + +*If no:* this is worth practicing deliberately — pick any Practice-tab scenario you haven't done +yet and narrate the framework out loud to yourself while solving it. + +--- + +**4. Have you completed the Real Ops incidents in ROOT 12 for real — diagnosed and repaired +them yourself, not looked up the answer?** + +*If no:* do this before attempting the Capstone. The required scenarios in every Capstone +attempt are drawn from exactly this style of incident. + +--- + +**5. Do you have a rough time-budget plan for a 90-minute, multi-scenario attempt?** + +*If no:* re-read the time-management lesson in this module before you begin. + +## What to do if you answered "no" to more than one + +That's genuinely useful information, not a failure — it tells you specifically where to spend +your remaining prep time. Go back to the relevant module, do the work for real, and come back +to this check again before attempting the Capstone. + +## Instructor Notes + +**Facilitation:** In a live classroom, this works well as private/individual reflection rather +than a group discussion — the value is honest self-assessment, not a public performance. + +**Approximate timing:** 5-8 minutes. + +**Expected takeaway:** Readiness is something a student can genuinely self-assess against +concrete, specific criteria — not a vague feeling of confidence. diff --git a/content/root/root-capstone/m02-capstone-readiness/04-reflection-readiness.md b/content/root/root-capstone/m02-capstone-readiness/04-reflection-readiness.md new file mode 100644 index 0000000..396d2a6 --- /dev/null +++ b/content/root/root-capstone/m02-capstone-readiness/04-reflection-readiness.md @@ -0,0 +1,42 @@ +# Readiness Reflection: What Completion Means + +Before you move toward the actual Capstone attempt, take a moment to reflect on the whole ROOT_ +journey up to this point. + +## Reflection questions + +1. Think back to ROOT 05's opening lesson on desired state. How differently would you explain + that concept now, after everything since, compared to how you understood it the first time? +2. Which single module across ROOT_ changed how you approach a problem the most — not which was + most interesting, but which actually changed your behavior when something breaks? +3. What does passing the Capstone mean to you, beyond a completion record on the platform? + +## What completion actually represents + +A `capstone_completed` achievement isn't a certificate claiming you've memorized Kubernetes +trivia. It's the platform's record that you demonstrated, under real time pressure, without +step-by-step guidance, that you can diagnose and repair real operational problems using +frameworks you internalized rather than looked up in the moment. That's a materially different +and more durable skill than passing a multiple-choice exam about Kubernetes objects. + +## When you're ready + +There's no "perfect" moment where every module feels fully mastered — that's normal. If the +readiness check in the previous activity mostly came back "yes," and you've done the Real Ops +incidents for real, you're ready to attempt it. The Capstone will unlock automatically once the +platform confirms your prerequisite stages are genuinely complete — when you see it unlocked, +that's the platform's own confirmation, not just this module's. + +This module is complete. Good luck. + +## Instructor Notes + +**Discussion questions for a live classroom:** question 2 tends to produce genuinely varied, +interesting answers across a cohort — worth having students share out loud if time allows. + +**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing. + +**Preparation:** None — this is a closing/orientation activity, not a technical one. + +**Expected takeaway:** Completing ROOT_'s Kubernetes sequence is a real, demonstrable skill +change, not just curriculum progress — the Capstone is where that becomes visible and provable.