rootnode-academy/docs/ROOT_CURRICULUM_COVERAGE_MATRIX.md

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