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: The Right Primitive Is a Correctness Decision, Not a Style Choice
You just built a one-shot Job and a scheduled CronJob for real. Take a few minutes to connect this to production thinking.
Reflection questions
- If your team accidentally deployed the database backup script as a Deployment instead of a CronJob, what's the FIRST symptom you'd likely notice — and would it look like a bug in the backup script itself, or something else?
- A CronJob that fails silently every night for a week is a real, common incident pattern. What would you want monitored to catch this quickly?
- Why does "it ran once and worked" not prove a CronJob is configured correctly?
Real Ops takeaway
Workload-primitive mistakes often look like application bugs at first. A backup script "crashing" every few minutes on a Deployment isn't a bug in the script — the script did exactly what it was told to do (exit when finished) and the Deployment is "correctly" restarting it according to its own contract. Recognizing "wrong primitive," not "buggy code," as the root cause saves real debugging time.
A schedule you never verify is a schedule you can't trust. A CronJob failing every single
run since deployment is easy to miss if nobody checks — unlike a Deployment's crash-looping
Pods, which are visible in kubectl get pods by default, a CronJob's failed history requires
someone to actually look at kubectl get jobs or the CronJob's own status. Real teams monitor
CronJob success/failure explicitly rather than assuming silence means success.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 1 is worth pushing on — many students' first instinct is to debug the "crashing" script rather than question the workload type it's running under.
Approximate timing: 8 minutes live discussion; 5 minutes self-paced writing.
Optional extension: ask students to name one alerting rule they'd add for a critical nightly CronJob (e.g. "alert if no successful completion recorded in the last 25 hours").