Files
rootnode-academy/docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md
ced4568andClaude Sonnet 5 87ad1251ce docs(phase6e): document the ROOT Foundations Completion milestone
Adds PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md (the phase's own record: what was authored, the
dash-vs-bash scenario bug found and fixed, the pre-existing lock-enforcement gap found and
fixed, the regression fallout that fix revealed in earlier suites and why each was a stale test
assumption rather than a platform bug, and honest test/rehearsal/regression results).

Updates ROOT_FOUNDATIONS_PILOT_READINESS.md (full re-audit: all 4 ROOT Foundations courses now
READY, not inherited blindly from Phase 6D), ROOT_PROGRAM_DURATION_MODEL.md (real ROOT 02-04
duration data: 24.7 combined hours, landing inside Phase 6D's own estimated range; 67.9 hours
across the full authored program), ROOT_PILOT_CURRICULUM.md (ROOT 02-04 move from NOT IN PILOT
to IN PILOT with full module-level detail; the pilot is now genuinely self-paced-capable for the
entire foundational half, not just instructor-led), ROOT_PROGRAM_ARCHITECTURE.md and
ROOT_CURRICULUM_COVERAGE_MATRIX.md (course/module/scenario totals), and
ROOT_FOUNDATIONS_ARCHITECTURE.md (marked as-built, not just as-designed).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 17:09:02 -05:00

16 KiB

ROOT_ Curriculum Coverage Matrix

Phase 6B §1 — maps every scenario Phase 6B puts to structured use, with an intentional reason for each placement (not coverage-percentage padding). Built from docs/ROOT_CURRICULUM_INVENTORY.md's evidence. Statuses: READY (meets docs/ROOT_PILOT_READINESS_STANDARD.md's bar), PARTIAL (real lesson + labs, missing one or more of demonstration/guided-exercise/reflection), PLANNED (structure only, no content), GAP (no suitable scenario exists at all).

Phase 6D addition

Phase 6D authored ROOT 01 (Computing & Linux Foundations) in full — 6 modules, 35 activities, 6 new hands-on Linux scenarios plus 2 MCQs, all READY. This is the program's first course outside the Kubernetes/CKS content this matrix was originally scoped to, so it is documented separately in docs/ROOT_FOUNDATIONS_ARCHITECTURE.md and docs/PHASE6D_ROOT_FOUNDATIONS.md rather than folded into the tables below, which remain the ROOT 05+ (Kubernetes) scenario-coverage record. Post-Phase-6D totals: 28 modules total across all courses with any content — 22 READY, 6 PARTIAL (Phase 6C's 22 modules — 16 READY, 6 PARTIAL — plus 6 new ROOT 01 modules, all READY). 106 scenario files (98 + 8 new).

Phase 6E addition

Phase 6E authored ROOT 02 (Linux Administration & Networking, 6 modules, 37 activities), ROOT 03 (Git & Collaborative Development, 6 modules, 31 activities), and ROOT 04 (Containers & Docker, 8 modules, 43 activities) in full — completing the entire ROOT_ Foundations sequence (ROOT 01-04). See docs/PHASE6E_ROOT_FOUNDATIONS_COMPLETION.md and docs/ROOT_FOUNDATIONS_PILOT_READINESS.md. 20 new hands-on/MCQ scenarios (6 Linux task + 2 Linux MCQ, 3 Git task + 2 Git MCQ, 5 Docker task + 2 Docker MCQ).

Post-Phase-6E totals: 48 modules total across all courses with any content — 42 READY, 6 PARTIAL (unchanged PARTIAL set: root-06-m01, root-07-m01, root-08-m01, root-08-m02, root-10-m02, root-11-m01 — none touched by this phase). 126 scenario files (106 + 20 new). The entire ROOT_ program now has a complete, READY, real path from Computing & Linux Foundations through the Capstone, excluding only the explicitly-deferred ROOT 08 and ROOT 11 modules 2-7 — see docs/ROOT_PILOT_CURRICULUM.md.

Phase 6C verification (superseding Phase 6B's own self-reported counts)

Baseline (start of Phase 6C), run directly against the database and filesystem (infra/scripts/validate-course-content.js, 0 errors) rather than trusted from Phase 6B's narrative report, which had miscounted: 21 modules total — 6 READY, 15 PARTIAL (Phase 6B's final report claimed 17 PARTIAL; the real count, re-verified here, was 15).

After Phase 6C's upgrades: 22 modules total — 16 READY, 6 PARTIAL. (22, not 21: Phase 6C added root-11-m01-devops-platform-thinking, ROOT 11's first real module — see docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md.) 75 activities now carry content_path (up from 73), 163 activities total (up from 140), and unwired scenarios dropped from 10 (Phase 6B) to 2 (cluster-upgrade-mcq, etcd-backup-mcq — both Cluster Administration/CKA-track content with no current ROOT module to host them; see docs/ROOT_PILOT_CURRICULUM.md's "not in pilot" section). Full before/after detail and rationale per module is in docs/PHASE6C_CURRICULUM_COMPLETION.md.

READY (16): root-05-m00-kubernetes-mental-model (Phase 6A gold standard, unchanged), root-05-m01-pods-and-kubectl-basics (Phase 6C: added bookending lesson + reflection around its 20-task kubectl-fluency bank), root-06-m02-deployments-scaling-updates (unchanged), root-06-m03-jobs-cronjobs-daemonsets (Phase 6C: added demonstration, guided exercise, reflection — full gold pattern), root-07-m02-configuration-and-secrets (Phase 6C: added lesson, demonstration, knowledge check, guided exercise, reflection — was a bare 5-lab bank), root-07-m03-services-and-service-discovery (unchanged), root-07-m04-ingress-networkpolicy-foundations (Phase 6C: full gold pattern added), root-09-m01-security-model-and-securitycontext (unchanged), root-09-m02-serviceaccounts-and-rbac (Phase 6C: full gold pattern added), root-09-m03-network-and-supplychain-security (Phase 6C: full gold pattern added), root-09-m04-cluster-hardening-and-runtime (Phase 6C: documented exception — survey depth by design, now anchored by a real security assessment), root-10-m01-health-probes-and-troubleshooting (Phase 6A gold standard; Phase 6C added one optional practice lab), root-10-m03-troubleshooting-framework (Phase 6C: added guided exercise + reflection), root-12-m01-real-ops-incidents (Phase 6C: documented exception — deliberately unguided by design, status promoted with no new activities), root-capstone-m01-operate-and-recover (Phase 6C: documented exception — the capstone exam IS the module), root-capstone-m02-capstone-readiness (unchanged).

PARTIAL (6, all with a documented pilot disposition in docs/ROOT_PILOT_CURRICULUM.md): root-06-m01-deployments-and-workloads, root-07-m01-services-and-networking, root-10-m02-general-troubleshooting (all three: dense practice banks, sibling module in the same course already carries the taught concept — instructor-led only for the first pilot, self-paced deferred), root-08-m01-storage-fundamentals, root-08-m02-scheduling-resource-governance (ROOT 08 does not gate the capstone; deferred as optional supplementary content this phase), root-11-m01-devops-platform-thinking (honest, lesson-only by design — no hands-on Lab exists for ROOT 11 yet).

Duplicate concepts identified (handled explicitly, not silently mapped twice)

  • pod-security-context (generic) vs. cks-pod-security-context (CKS-flavored) — same concept. cks-pod-security-context is the CORE guided lab (ROOT 09 m01); pod-security-context is classified INDEPENDENT PRACTICE (a second, optional rep).
  • rbac-clusterrole (generic) vs. cks-rbac-clusterrole (CKS-flavored) — same concept. cks-rbac-clusterrole is CORE (ROOT 09 m02); rbac-clusterrole is INDEPENDENT PRACTICE.
  • network-policy (generic, foundational) vs. cks-network-policy (CKS default-deny framing) vs. networkpolicy-egress (generic egress) — three related but distinct angles, deliberately split across two courses: network-policy teaches the ARCHITECTURAL concept in ROOT 07 (what a NetworkPolicy is/does); cks-network-policy/cks-egress-namespace/networkpolicy-egress teach it as a SECURITY CONTROL in ROOT 09 (default-deny posture, least-privilege network access) — not a duplicate once the teaching angle is made explicit, so both are CORE in their respective course, not one marked redundant.

ROOT 05 — Kubernetes Foundations

Module Objective Lesson Demo KC Guided Scenario(s) Assessment Real Ops Status
m02 Kubernetes Mental Model & Core Objects (NEW) Explain what Kubernetes solves, the control-plane/worker/desired-state model, and navigate Pods/Namespaces/labels with kubectl Yes Yes Yes Yes pod-basics-mcq, namespaces-basics, labels-selectors-mcq, kubectl-essentials-mcq (existing, re-sequenced as this module's guided path) — "declarative config drifts back to desired state after manual edits" READY
m01 Pods & kubectl Basics (existing) Mechanical kubectl fluency across the Foundation stage's 20 scenarios No No No No all 20 Foundation scenarios — — PARTIAL (unchanged from Phase 6A — m02 above is the new front door; m01's labs remain a practice bank behind it)

m02 is sequenced BEFORE m01 (prerequisite: none; m01's prerequisite becomes m02) so a student meets the mental model before the bare-lab bank, per this phase's core principle.

ROOT 06 — Kubernetes Application Workloads

Module Objective Lesson Demo KC Guided Scenario(s) Real Ops Status
m02 Deployments, Scaling & Updates (NEW) Explain why Deployments/ReplicaSets exist, perform a rolling update, and reason about rollback Yes Yes Yes Yes deploy-nginx, scale-deployment, rolling-update-task, deployment-rollback (newly wired — Workloads & Scheduling bucket, belongs here not ROOT 08) "a bad rollout with no rollback plan turns a deploy into an outage" READY
m03 Jobs, CronJobs & DaemonSets (NEW) Distinguish one-shot Jobs, scheduled CronJobs, and per-node DaemonSets from long-running Deployments Yes No Yes No job-task, cronjob-task (newly wired), jobs-cronjobs-mcq, daemonset-mcq "a cleanup Job that never completes silently exhausts cluster resources" PARTIAL (lesson+KC authored; no separate demo/guided — labs carry the practice)
m01 Deployments & Workloads (existing) Bare-lab bank, Workloads stage's original 8 scenarios No No No No (unchanged) — PARTIAL (unchanged)

ROOT 07 — Kubernetes Networking & Configuration

Module Objective Lesson Demo KC Guided Scenario(s) Real Ops Status
m03 Services & Service Discovery (NEW) Explain the Service/Endpoints/DNS request path and choose the right Service type Yes Yes Yes Yes services-mcq, expose-service-basics, nodeport-task, dns-resolution-mcq (newly wired) "a Service with zero endpoints looks identical to network failure from the outside" READY
m04 Ingress & NetworkPolicy Foundations (NEW) Explain how Ingress routes external traffic and what a NetworkPolicy architecturally does Yes No Yes No ingress-task, network-policy (newly wired) "traffic reachability should be intentional, not incidental" PARTIAL
m02 Configuration & Secrets (existing) Bare-lab bank No No No No (unchanged) — PARTIAL (unchanged)
m01 Services & Networking (existing) Bare-lab bank, folded conceptually under m03 above No No No No (unchanged) — PARTIAL (unchanged)

ROOT 08 — Kubernetes Storage & Scheduling (newly wired this phase — was PLANNED)

Module Objective Lesson Demo KC Guided Scenario(s) Real Ops Status
m01 Storage Fundamentals (NEW) Explain ephemeral vs. persistent storage and how PV/PVC/StorageClass fit together Yes No Yes No emptydir-pod, pv-pvc-mount, pvc-dynamic-task, storageclass-mcq "a Pod restart on ephemeral storage silently loses data no one told the team about" PARTIAL
m02 Scheduling & Resource Governance (NEW) Explain how the scheduler places Pods and how quotas/limits/priority shape that placement Yes No Yes No node-label-selector, node-taint-toleration, pod-affinity-mcq, priority-class-task, pod-disruption-budget-task, resource-quota-ns, limitrange-task "an eviction during a voluntary disruption without a PDB can take down every replica at once" PARTIAL

cluster-upgrade-mcq and etcd-backup-mcq (Cluster Administration bucket) are left PRACTICE-ONLY — they're genuine cluster-operator content but conceptually belong with ROOT 11 (DevOps & Platform Engineering, out of Phase 6B's authoring scope per the authorization), not storage/scheduling. Mapping them here just to raise a coverage number would violate this document's own "quality over percentage" rule.

ROOT 09 — Kubernetes Security (newly wired this phase — was PLANNED)

Not built as 22 disconnected CKS tasks. Four modules, foundational → advanced:

Module Focus Classification of its scenarios Status
m01 Security Model & SecurityContext (NEW) Defense in depth, least privilege, non-root/capabilities/read-only-fs CORE: cks-pod-security-context, cks-non-root-enforce, cks-drop-capabilities, cks-readonly-filesystem. GUIDED: cks-seccomp-profile. ADVANCED: cks-apparmor-profile. INDEPENDENT: pod-security-context (dup, see above) READY
m02 ServiceAccounts & RBAC (NEW) Identity for workloads, least-privilege permissions CORE: serviceaccount-pod, cks-automount-token, rbac-role, cks-rbac-clusterrole, cks-rbac-least-privilege. INDEPENDENT: rbac-clusterrole (dup, see above) PARTIAL (lesson authored; no separate demo/guided)
m03 Network & Supply Chain Security (NEW) NetworkPolicy as a security control, image/registry trust, TLS ingress CORE: cks-network-policy, cks-egress-namespace, cks-tls-ingress, cks-image-pull-secret. GUIDED: networkpolicy-egress. ADVANCED: cks-network-policy-metadata. ASSESSMENT BANK: cks-mcq-image-footprint PARTIAL
m04 Cluster Hardening & Runtime Security (NEW) Pod Security Admission, audit policy, runtime sandboxing — survey-level, not daily-driver core CORE: cks-psa-namespace, cks-immutable-secret. ADVANCED: cks-audit-policy, cks-runtime-class. ASSESSMENT BANK: cks-mcq-api-server, cks-mcq-audit-policy, cks-mcq-kubelet-auth, cks-mcq-psp-replacement, cks-mcq-runtime-security, cks-mcq-sandboxing PARTIAL

"ASSESSMENT BANK" scenarios are intentionally NOT wired as required module activities — they're recall-style MCQs well suited to a future structured exam pool (rootnode-quick-assessment-style definition), not hands-on core teaching. Not wired into module_activities this phase; flagged here so a future phase doesn't have to re-discover them.

ROOT 10 — Kubernetes Troubleshooting & Observability

The gold-standard Health Probes module (root-10-m01) is preserved unmodified — it's the template, not a page to be made "consistent" with anything else.

Module Objective Lesson Demo KC Guided Scenario(s) Real Ops Status
m01 Health Probes & Troubleshooting (existing, UNCHANGED) — Yes Yes Yes Yes rootnode-probe-port-mismatch Yes READY
m03 The RootNode Troubleshooting Framework (NEW) Apply Observe→Evidence→Hypothesis→Test→Repair→Validate→Prevent to a CrashLoopBackOff and a broken Service Yes Yes Yes No crashloop-fix, endpoint-fix-task, container-logging-mcq (newly wired) "a repeatable framework beats guessing under a 2am page" PARTIAL (no separate guided exercise — the framework lesson + demo carry that role)
m02 General Troubleshooting (existing) Bare-lab bank No No No No (unchanged) — PARTIAL (unchanged)

ROOT 12 — RootNode Real Ops

Module Objective Lesson Scenario(s) Framing Status
m01 Real Ops Incidents (existing, extended with framing) Apply Detect→Triage→Diagnose→Mitigate→Recover→Verify→Learn to real incidents Yes (new incident-response framework lesson) rootnode-runaway-monitor, broken-deployment, rootnode-probe-port-mismatch (reused), rootnode-enforce-limits Each lab gets a short incident-context intro + post-incident reflection (not full lesson/demo/KC per incident — see docs/PHASE6B_ROOT_CURRICULUM_EXPANSION.md for why) PARTIAL

rootnode-real-ops bundle contains exactly these 4 scenario ids (verified against scenarios/bundles/rootnode-real-ops.json) — no additional upstream scenario was intentionally included there beyond what rootnode-path.json's real-ops stage already lists.

ROOT CAPSTONE

Module Content Status
m01 Operate and Recover (existing) The real rootnode-capstone assessment PARTIAL (unchanged — assessment engine, not lesson content)
m02 Capstone Readiness (NEW) What the capstone measures, prerequisites, how the timed/random draw works, time management, troubleshooting strategy, what completion means — derives real readiness from curriculum state, never publishes the draw or answers READY

Scenarios deliberately left out of structured curriculum entirely

cluster-upgrade-mcq, etcd-backup-mcq (ROOT 11 territory, out of scope), and the 6 ASSESSMENT-BANK-classified CKS MCQs above (not yet wired to an actual assessment definition — future work, not silently dropped). All remain reachable via the existing Practice tab/bundles, unaffected by any of this.