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]>
49 lines
2.1 KiB
Markdown
49 lines
2.1 KiB
Markdown
# Knowledge Check: Configuration & Secrets
|
|
|
|
---
|
|
|
|
**1. A teammate says "our database password is safe because it's stored as a Kubernetes
|
|
Secret." What's missing from that statement?**
|
|
|
|
*Answer:* A Secret's data is base64-ENCODED, not encrypted — anyone who can read the Secret
|
|
object at all can trivially decode it. The real protection is RBAC (who is allowed to read
|
|
Secrets in that namespace) and, on a properly configured cluster, encryption at rest — not the
|
|
Secret object type itself.
|
|
|
|
---
|
|
|
|
**2. Why does Kubernetes have two separate objects (ConfigMap and Secret) instead of one
|
|
"Config" object with a sensitivity flag?**
|
|
|
|
*Answer:* Keeping them separate makes the distinction enforceable via RBAC — a role can grant
|
|
"read ConfigMaps" without granting "read Secrets" — and makes it visible at a glance
|
|
(`kubectl get configmaps` never risks accidentally listing something sensitive).
|
|
|
|
---
|
|
|
|
**3. An application needs its configuration to change without rebuilding its container image
|
|
across dev/staging/production. Which Kubernetes mechanism solves this, and why not just bake
|
|
different configs into three separate images?**
|
|
|
|
*Answer:* ConfigMaps (and Secrets, for sensitive values) injected at runtime via env vars or a
|
|
mounted volume. Baking config into the image means maintaining three separate images for what
|
|
should be identical application code — externalizing configuration lets the SAME image run
|
|
correctly in every environment.
|
|
|
|
---
|
|
|
|
**4. True or false: mounting a ConfigMap as a volume and consuming it as environment variables
|
|
are functionally identical from the application's perspective.**
|
|
|
|
*Answer:* False. An application reading environment variables needs code that reads env vars; an
|
|
application expecting a config FILE on disk needs the volume-mount approach. The right choice
|
|
depends on how the application itself is written to read configuration, not just personal
|
|
preference.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 1 is the single most important takeaway from this module — confirm
|
|
it's genuinely understood, not just correctly guessed, before moving to the Labs.
|
|
|
|
**Approximate timing:** 5-7 minutes.
|