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]>
51 lines
2.4 KiB
Markdown
51 lines
2.4 KiB
Markdown
# Guided Exercise: Choosing the Right Workload Primitive
|
|
|
|
Paper-and-thinking exercise before the Labs.
|
|
|
|
## The scenario
|
|
|
|
Your team needs four things running in the cluster:
|
|
|
|
1. A nightly database backup that must run at 2am and finish before morning.
|
|
2. A log-shipping agent that must run on every node, including nodes added later.
|
|
3. A one-time script to backfill a new database column, run once during this deploy.
|
|
4. The main web application, always up, serving live traffic.
|
|
|
|
## Your task
|
|
|
|
For each of the four, name the correct primitive (Deployment, Job, CronJob, or DaemonSet) and
|
|
answer: what would go wrong if you used a Deployment for it instead?
|
|
|
|
## A worked answer to check yourself against
|
|
|
|
1. **CronJob.** A Deployment has no concept of "run on a schedule" — you'd need external
|
|
tooling to trigger it repeatedly, reinventing what CronJob already does. Using a bare Job
|
|
would run it once; CronJob is what recreates that Job on schedule.
|
|
2. **DaemonSet.** A Deployment's replica count is a number, not "one per node" — nothing
|
|
guarantees even coverage, and a newly added node wouldn't automatically get a copy the way a
|
|
DaemonSet guarantees.
|
|
3. **Job.** A Deployment expects its Pod to run forever; a script that's SUPPOSED to exit when
|
|
done would be treated as a crash and restarted forever, which is wrong for a one-time task.
|
|
4. **Deployment.** This is the actual always-on, N-replicas case the other three are explicitly
|
|
NOT designed for.
|
|
|
|
## Self-check
|
|
|
|
If you answered "Job" for #4 or "Deployment" for #1-3, revisit the lesson's decision table
|
|
before the Labs — getting this choice right the first time avoids building something that
|
|
technically runs but behaves wrong in a way that's easy to miss until it causes a real problem
|
|
(a backup CronJob accidentally deployed as a Job that only ever runs once, for example).
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Good as a quick individual exercise before revealing the answer — the "what
|
|
would go wrong" framing forces reasoning about the CONSEQUENCE of a wrong choice, not just
|
|
recall of a definition.
|
|
|
|
**Approximate timing:** 8-10 minutes live with discussion; 8 minutes self-paced.
|
|
|
|
**Optional extension:** ask what would need to be true for #1 (the nightly backup) to actually
|
|
be SAFE to run as a plain Job triggered manually once, instead of a CronJob — a good check that
|
|
students understand CronJob's value is specifically the SCHEDULING, not something inherent to
|
|
backups.
|