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]>
46 lines
2.3 KiB
Markdown
46 lines
2.3 KiB
Markdown
# Reflection: Where You Already Practiced This
|
|
|
|
You've now named the operating model behind most of what ROOT_ taught. Take a few minutes to
|
|
trace it back through your own experience in this program.
|
|
|
|
## Reflection questions
|
|
|
|
1. Pick one specific moment from ROOT 05-10 or ROOT 12 where you practiced a DevOps/platform
|
|
engineering principle without it being labeled that way. Name the principle explicitly now.
|
|
2. If you were designing a platform team's "golden path" for deploying a new service safely,
|
|
which THREE things from ROOT_ (health probes, RBAC, resource limits, NetworkPolicy, etc.)
|
|
would you bake in as defaults rather than leave to each team to remember?
|
|
3. What's one thing about GitOps, CI/CD, Infrastructure as Code, or observability you're
|
|
genuinely curious about, now that you have the Kubernetes foundation to eventually build
|
|
hands-on skill in it?
|
|
|
|
## Real Ops takeaway
|
|
|
|
**The skills you already have transfer further than "just Kubernetes."** Desired-state
|
|
thinking, least privilege, evidence-based troubleshooting, and structured incident response
|
|
aren't Kubernetes-specific facts — they're how experienced platform engineers reason about ANY
|
|
complex system. Recognizing that transfer is what turns "I learned Kubernetes" into "I think
|
|
like a platform engineer."
|
|
|
|
**Honest scope beats fake completeness.** This course didn't pretend to teach you GitOps or
|
|
CI/CD hands-on today — it told you exactly what's missing and why, and pointed at what it would
|
|
take to build it for real. That's the same standard the rest of ROOT_ held itself to
|
|
throughout — a module that doesn't exist yet is more useful, honestly labeled, than one that
|
|
exists in name only.
|
|
|
|
This module is complete.
|
|
|
|
## Instructor Notes
|
|
|
|
**Discussion questions for a live classroom:** question 2 works well as a small-group exercise —
|
|
have groups compare their "golden path defaults" lists and discuss disagreements.
|
|
|
|
**Approximate timing:** 10 minutes live discussion; 8 minutes self-paced writing.
|
|
|
|
**Optional extension:** ask students to research (outside class) one real company's public
|
|
engineering blog post about their platform engineering practice, and bring one concrete example
|
|
to share next session.
|
|
|
|
**Expected takeaway:** ROOT_ built real, transferable engineering judgment — this module makes
|
|
that transfer explicit rather than leaving students to discover it on their own.
|