feat(curriculum): Phase 6C module upgrades, security assessment bank, ROOT 11 orientation

Upgrades six PARTIAL modules to the gold-module standard (lesson/demonstration/ knowledge-check/guided-exercise/lab(s)/reflection), preserving every existing lab activity_id and scenario_id: root-06-m03 (jobs/cronjobs/daemonsets), root-07-m04 (ingress/networkpolicy), root-07-m02 (configuration/secrets, converted in place from a bare 5-lab bank), root-09-m02 (serviceaccounts/rbac), root-09-m03 (network/supply-chain security), root-10-m03 (troubleshooting framework). root-05-m01 (20-task kubectl-fluency bank) gets a minimal bookending lesson + reflection rather than a full redesign, since each task already carries its own explanation. root-12-m01, root-capstone-m01, and root-09-m04 are promoted to READY via documented exceptions (no new activities) where adding one would misrepresent their intentional design. Wires a new rootnode-security-assessment (exam, 60min, hint_policy disabled) using the existing Phase 3B assessment engine: 3 required hands-on CORE scenarios + 4 random-draw pools covering SecurityContext, RBAC, network policy, and the 7 previously-unwired CKS MCQs. Wires the previously-unwired readiness-probe-task scenario as an OPTIONAL practice lab in root-10-m01, using the existing is_required model. Adds root-11-m01-devops-platform-thinking — an honest, lesson-only ROOT 11 orientation module naming DevOps/platform engineering practices already exercised in ROOT 05-10/12, explicit that GitOps/CI-CD/IaC/observability need lab infrastructure this platform doesn't yet provide. No fake labs. Adds infra/scripts/validate-course-content.js: cross-checks the DB against scenario/content files for duplicate ids, orphans, invalid references, cycles, sequence collisions, instructor-notes leakage, and (new) self-paced content deferring explanation to a live instructor. 0 errors against the resulting 22 courses/modules, 163 activities, 98 scenario files. No application code changed — every gap was satisfiable with existing tables (course_modules, module_activities, assessment_definitions) and the existing content-delivery pipeline. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 11:20:17 -05:00
parent 2db136875f
commit 7f6e1857c0
26 changed files with 1716 additions and 0 deletions
@@ -0,0 +1,52 @@
+# Guided Exercise: Applying the Framework to a Broken Service, on Paper First
+
+Before the `endpoint-fix-task` Lab, walk through the framework yourself against a described
+symptom — no cluster needed yet.
+
+## The scenario
+
+A teammate says: "`my-svc` isn't routing any traffic to our Pods, and I don't know why — the
+Pods look healthy in `kubectl get pods`."
+
+## Your task
+
+Write out, step by step, what you would actually DO for each framework stage, before looking at
+the worked answer:
+
+1. **Observe** — what's the precise, specific symptom here (not "it's broken")?
+2. **Gather Evidence** — name the exact `kubectl` commands you'd run, in order, and what each
+   one is checking for.
+3. **Form Hypothesis** — based on what ROOT 07's Services lesson taught you, what's the most
+   likely cause of "Pods healthy, but Service routes nowhere"?
+4. **Test** — how would you CONFIRM that hypothesis before changing anything?
+5. **Repair** — what's the minimal fix, assuming your hypothesis is correct?
+6. **Validate** — what would you check afterward to PROVE the fix worked, not just assume it?
+
+## A worked answer to check yourself against
+
+1. Traffic sent to `my-svc` never reaches any Pod, despite the Pods themselves reporting
+   `Running`/`Ready` — this rules out "the Pods are unhealthy" as the cause.
+2. `kubectl get endpoints my-svc` (does it show any Pod IPs at all?), then `kubectl describe
+   service my-svc` (what selector is it actually using?), then `kubectl get pods --show-labels`
+   (what labels do the real Pods actually carry?).
+3. A Service-to-Pod label selector mismatch — exactly the failure mode ROOT 07's demonstration
+   walked through, where a Service's selector no longer matches the Pods' actual labels.
+4. Directly compare the Service's selector (from `describe service`) against the Pods' labels
+   (from `get pods --show-labels`) side by side — confirmed if they genuinely don't match.
+5. Correct the Service's selector (or the Pods' labels, whichever is actually wrong) so they
+   match again.
+6. `kubectl get endpoints my-svc` now shows the Pod IPs populated — not just "the YAML looks
+   right now," but the actual Endpoints object reflecting real, matched Pods.
+
+## Instructor Notes
+
+**Facilitation:** This exercise deliberately reuses ROOT 07's own content — a good moment to
+point out explicitly that the framework's value is applying PRIOR knowledge systematically, not
+learning something entirely new each time.
+
+**Approximate timing:** 10-12 minutes live with discussion; 10 minutes self-paced.
+
+**Optional extension:** ask what would change about steps 2-4 if the symptom were instead
+"Pods healthy, but ONE specific caller can't reach the Service while others can" — a good bridge
+to considering NetworkPolicy (ROOT 09) as an alternative hypothesis once the simpler
+selector-mismatch explanation is ruled out.
@@ -0,0 +1,45 @@
+# Reflection: A Framework You've Actually Used Is One You'll Trust Under Pressure
+
+You just solved two real, different failures — a CrashLoopBackOff and a broken Service
+selector — using the same seven-step framework both times. Take a few minutes to consolidate
+this.
+
+## Reflection questions
+
+1. Which framework step did you personally find easiest to skip or rush through across both
+   Labs? Why do you think that step specifically tempts shortcuts?
+2. Compare how you approached `crashloop-fix` versus `endpoint-fix-task`. What was IDENTICAL
+   about your process, and what was different only because the evidence looked different?
+3. Now that you've practiced this framework on two failures you'd never seen exact instructions
+   for, how confident do you feel applying it to a THIRD, completely unfamiliar Kubernetes
+   failure? What would you still want to double-check?
+
+## Real Ops takeaway
+
+**The framework's value shows up most on failures you've never seen before.** Anyone can
+memorize "if X symptom, do Y fix" for a handful of common problems — that knowledge doesn't
+transfer. Observe → Evidence → Hypothesis → Test → Repair → Validate → Prevent Recurrence
+transfers to failures nobody has specifically taught you, because it's a PROCESS, not a lookup
+table.
+
+**"Prevent Recurrence" is what separates incident response from firefighting.** Both Labs in
+this module had a real, nameable prevention practice (verify command strings before deploying;
+keep label keys consistent between a Deployment and its Service). Teams that consistently ask
+this question after every fix accumulate fewer repeat incidents over time — not because they got
+lucky, but because they closed the actual gap each time.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 1 tends to produce honest, useful
+answers — "Prevent Recurrence" and "Form Hypothesis" (skipping straight to a guessed fix) are
+the two most commonly admitted shortcuts, both worth normalizing as a real temptation to resist
+rather than treating as a personal failing.
+
+**Approximate timing:** 8-10 minutes live discussion; 5-7 minutes self-paced writing.
+
+**Optional extension:** ask students to apply the framework, from memory and without re-reading
+this module, to a THIRD failure type they haven't practiced yet (e.g., a Pod stuck `Pending` —
+not built as a hands-on Lab in this module, just a thought exercise) to test genuine
+transferability.