rootnode-academy/docs/ROOT_V1_ASSESSMENT_MAP.md

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.