# ROOT_ V1 Assessment Map

Phase 6F Step 8 — every formal assessment in ROOT_ V1, what it actually tests, and how it
relates to course completion. Formative checks (knowledge checks, guided exercises) exist inside
every module and are not separately catalogued here — see `docs/COURSE_CONTENT_MODEL.md` for
how they're modeled.

| Course | Assessment | Required scenarios | Random pool | Hints | Duration |
|---|---|---|---|---|---|
| ROOT 01 | `rootnode-linux-foundations-assessment` | linux-shell-basics, linux-permissions-foundations | 2 from a 4-task pool + 2 MCQ | disabled | 30 min |
| ROOT 02 | `rootnode-linux-networking-assessment` | linux-network-inspection, linux-troubleshooting-framework | 2 from a 4-task pool + 2 MCQ | disabled | 35 min |
| ROOT 03 | `rootnode-git-fundamentals-assessment` | git-everyday-basics, git-branching-and-merge | 1 task + 2 MCQ | disabled | 35 min |
| ROOT 04 | `rootnode-containers-assessment` | docker-cli-basics, docker-build-image | 2 from a 3-task pool + 2 MCQ | disabled | 40 min |
| ROOT 09 | `rootnode-security-assessment` | cks-pod-security-context, cks-rbac-least-privilege, cks-network-policy | 2+1+2 across three CKS-style pools | disabled | 60 min |
| — | `rootnode-capstone` | rootnode-runaway-monitor, broken-deployment, rootnode-probe-port-mismatch, rootnode-enforce-limits | 1 each from workloads/config/troubleshooting pools | flagged (visible but logged) | 90 min |
| — | `rootnode-quick-assessment` | none | draws from workloads/networking/troubleshooting/real-ops pools | disabled | 60 min |

`rootnode-quick-assessment` is a pre-existing, general Kubernetes proficiency check not wired to
any single course's completion — it predates the course-content-model layer and is left as-is
(unaffected by this phase, still reachable via `/api/assessments/rootnode-quick-assessment/start`
for practice/diagnostic use, e.g. by an instructor assessing a transfer student's baseline).

## Relationship to course completion

Every course-gating assessment (ROOT 01/02/03/04/09) is wired to exactly one `assessment`-type
activity (`completion_behavior = 'auto_assessment'`) inside that course's last module. Passing
it is derived the same way a scenario Lab's completion is derived — from a real
`achievements` row written on a real pass — never a second, independently-tracked flag
(`COURSE_CONTENT_MODEL.md` §4).

## What's a real, server-authoritative draw vs. fixed

Every assessment's `random` pool is drawn fresh per attempt, server-side, at `POST /api/
assessments/:id/start` — confirmed for ROOT 02's pool specifically in `e2e-phase6e.js`
("ROOT 02 assessment pool matches the documented design") and for the security assessment in
`e2e-phase6c.js` ("two independent students each get their own 9-scenario draw, and it is
server-authoritative"). `required` scenarios are always included, every attempt, for every
student — they are the non-negotiable floor of what "passing this course's assessment" means.

## Coverage gaps and redundancy, evaluated honestly

- **No assessment gap found** in the V1 required sequence: every required course (01-04, 09) has
  one, sized to its content (30-60 min matching course depth), and none were added merely for
  symmetry — `ROOT_PILOT_CURRICULUM.md`'s existing per-course rationale is unchanged this phase.
- **ROOT 05, 06, 07, 10, 12 have no formal timed assessment** — their real hands-on Labs plus the
  Capstone's own scenario pool (drawn partly from workloads/configuration/troubleshooting
  content) already exercise this material under timed, graded conditions at the end of the
  program. Adding a redundant mid-program timed exam for each would test the same skill twice
  without new instructional purpose — deliberately not built.
- **`rootnode-quick-assessment` and `rootnode-capstone` share scenario pools** with several
  course-level Labs (by original Phase 1-5 design, unchanged) — this is intentional reuse
  (`ROOT_CURRICULUM_COVERAGE_MATRIX.md`'s documented "scenario reused across activities" list),
  not accidental duplication.