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: ConfigMap, Secret, Env Var, or Volume?
|
|
|
|
Paper-and-thinking exercise before the Labs.
|
|
|
|
## The scenario
|
|
|
|
Your application needs four pieces of configuration:
|
|
|
|
1. A log level (`debug`/`info`/`warn`) that ops sometimes needs to flip without redeploying.
|
|
2. A database password.
|
|
3. A large JSON config file the application reads from a specific path at startup.
|
|
4. A feature flag read once at container startup via an environment variable, per the
|
|
application's existing code.
|
|
|
|
## Your task
|
|
|
|
For each, decide: ConfigMap or Secret, and env var or volume mount — then justify each choice.
|
|
|
|
## A worked answer to check yourself against
|
|
|
|
1. **ConfigMap, env var.** Not sensitive; the application likely already reads it as an env var
|
|
(a common convention), and env vars are simple to change and trigger a rolling restart with.
|
|
2. **Secret, either — but env var is common here too**, since most applications expect
|
|
credentials via environment variables by convention. The KEY decision is Secret (sensitive),
|
|
not the delivery mechanism.
|
|
3. **ConfigMap, volume mount.** The application expects a FILE at a path, not an environment
|
|
variable — volume mount is the only mechanism that presents a ConfigMap as an actual file.
|
|
4. **ConfigMap (assuming not sensitive) or Secret (if it is), env var** — the application's
|
|
EXISTING code dictates this; you don't get to choose a mechanism the application wasn't
|
|
written to read.
|
|
|
|
## Self-check
|
|
|
|
If you chose "volume mount" for #4 or "env var" for #3, revisit the lesson — the deciding
|
|
factor here isn't which mechanism seems more "correct" in the abstract, it's what the
|
|
application actually expects. Getting this backwards means the application simply won't find
|
|
its configuration at all.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Emphasize that #4's answer depends entirely on EXISTING application
|
|
behavior — a good moment to note that platform engineers frequently have to adapt Kubernetes
|
|
config delivery to match an application's assumptions, not the reverse.
|
|
|
|
**Approximate timing:** 8-10 minutes live with discussion; 8 minutes self-paced.
|
|
|
|
**Optional extension:** ask what would happen if a ConfigMap consumed as a volume mount is
|
|
UPDATED after the Pod is already running — a good bridge to the real (if not hands-on-tested
|
|
here) behavior that mounted ConfigMap files update automatically after a short delay, while
|
|
env-var-injected values do NOT update without a Pod restart.
|