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 (a student can actually learn from it end to end — see docs/COURSE_AUTHORING_STANDARD.md's bar), PARTIAL (real lesson + labs, missing one or more of demonstration/knowledge-check/guided-exercise), PLANNED (structure only, no content), GAP (no suitable scenario exists at all).

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.