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