Upgrades six PARTIAL modules to the gold-module standard (lesson/demonstration/ knowledge-check/guided-exercise/lab(s)/reflection), preserving every existing lab activity_id and scenario_id: root-06-m03 (jobs/cronjobs/daemonsets), root-07-m04 (ingress/networkpolicy), root-07-m02 (configuration/secrets, converted in place from a bare 5-lab bank), root-09-m02 (serviceaccounts/rbac), root-09-m03 (network/supply-chain security), root-10-m03 (troubleshooting framework). root-05-m01 (20-task kubectl-fluency bank) gets a minimal bookending lesson + reflection rather than a full redesign, since each task already carries its own explanation. root-12-m01, root-capstone-m01, and root-09-m04 are promoted to READY via documented exceptions (no new activities) where adding one would misrepresent their intentional design. Wires a new rootnode-security-assessment (exam, 60min, hint_policy disabled) using the existing Phase 3B assessment engine: 3 required hands-on CORE scenarios + 4 random-draw pools covering SecurityContext, RBAC, network policy, and the 7 previously-unwired CKS MCQs. Wires the previously-unwired readiness-probe-task scenario as an OPTIONAL practice lab in root-10-m01, using the existing is_required model. Adds root-11-m01-devops-platform-thinking — an honest, lesson-only ROOT 11 orientation module naming DevOps/platform engineering practices already exercised in ROOT 05-10/12, explicit that GitOps/CI-CD/IaC/observability need lab infrastructure this platform doesn't yet provide. No fake labs. Adds infra/scripts/validate-course-content.js: cross-checks the DB against scenario/content files for duplicate ids, orphans, invalid references, cycles, sequence collisions, instructor-notes leakage, and (new) self-paced content deferring explanation to a live instructor. 0 errors against the resulting 22 courses/modules, 163 activities, 98 scenario files. No application code changed — every gap was satisfiable with existing tables (course_modules, module_activities, assessment_definitions) and the existing content-delivery pipeline. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2.2 KiB
Reflection: Reachability and Trust Are Decisions You Make on Purpose
You just applied default-deny NetworkPolicy, egress restriction, TLS ingress, and image-pull authentication for real. Take a few minutes to connect these to a single underlying principle.
Reflection questions
- Four different mechanisms in this module (NetworkPolicy ingress, NetworkPolicy egress, TLS, image-pull secrets) all express the same underlying idea in a different layer. What is that idea, stated in one sentence?
- If you had to prioritize implementing ONLY ONE of this module's controls on a brand-new, unsecured cluster, which would you pick first, and why?
- How would you explain, to someone who thinks "our cluster is internal, so it doesn't need this," why internal-only still benefits from all four controls?
Real Ops takeaway
Trust should be explicit, narrow, and verifiable — never assumed from proximity. A Pod on the same cluster, a request from inside the corporate network, an image from "a registry we usually use" — none of these are actually trustworthy by default. Every control in this module replaces an assumption ("it's internal, it's probably fine") with an explicit, checkable decision (this specific Pod can reach this specific destination; this specific registry is authenticated; this specific connection is encrypted).
Supply-chain and network security compound. A compromised image with unrestricted egress on an open network is a far worse incident than the same compromised image on a hardened one — the controls in this module don't individually prevent every incident, but together they dramatically shrink what any single failure can turn into.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 1 is the module's thesis — make sure students can actually articulate it in their own words, not just recognize it when stated.
Approximate timing: 8-10 minutes live discussion; 5 minutes self-paced writing.
Optional extension: ask students to rank this module's four controls by how much IMPLEMENTATION EFFORT each typically requires on a real team, separately from security value — a good exercise in real-world prioritization tradeoffs.