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.