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]>
67 lines
3.6 KiB
Markdown
67 lines
3.6 KiB
Markdown
# 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.
|