ced4568andClaude Sonnet 5
de6c5b3286
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]>
73 lines
3.8 KiB
Markdown
73 lines
3.8 KiB
Markdown
# 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.
|