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,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