ced4568andClaude Sonnet 5
7f6e1857c0
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.1 KiB
Reflection: Configuration Is Infrastructure, Secrets Are a Trust Boundary
You just externalized configuration and handled a real Secret. Take a few minutes to connect this to production practice.
Reflection questions
- Before this module, would you have assumed a Kubernetes Secret was encrypted? What's the real-world consequence of a team believing that when it isn't true?
- If your team's RBAC accidentally granted a low-trust role
get secretsaccess across an entire namespace, what's actually exposed — and would your team necessarily notice? - Why does separating configuration from the container image matter beyond convenience — think about what it enables for testing or incident response.
Real Ops takeaway
A misunderstood Secret is a false sense of security. Teams that believe Secrets are encrypted by default sometimes skip additional controls (proper RBAC scoping, external secrets management, encryption at rest) that they'd otherwise recognize as necessary. The gap between perceived and actual protection is exactly where real incidents happen.
Externalized configuration is what makes rollback and incident response fast. If a bad config value ships (a wrong feature flag, an incorrect log level flooding storage), fixing it means updating a ConfigMap/Secret and letting Pods pick up the change — not rebuilding and redeploying an entire image. This is a direct, practical payoff of the separation this module taught, not just an architectural nicety.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 2 works well as a small-group exercise — have students actually list what a namespace's Secrets typically contain in a real application (DB creds, API keys, TLS certs) to make the exposure concrete.
Approximate timing: 8 minutes live discussion; 5 minutes self-paced writing.
Optional extension: ask students to draft a one-line policy statement their hypothetical
team would adopt about who is allowed get/list access to Secrets in production namespaces.