feat(root): build Real Ops and capstone readiness content
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 <[email protected]>
This commit is contained in:
Claude Sonnet 5
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user