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]>
3.6 KiB
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.