# 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.