feat(curriculum): Phase 6C module upgrades, security assessment bank, ROOT 11 orientation

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]>
2026-08-26 11:20:17 -05:00
parent 2db136875f
commit 7f6e1857c0
26 changed files with 1716 additions and 0 deletions
@@ -0,0 +1,88 @@
+# DevOps as an Operating Model, Not a Job Title
+
+## You've already been doing this — just not naming it yet
+
+Every course before this one taught you a Kubernetes skill: declaring desired state, hardening
+a Pod, diagnosing a failure with a repeatable framework, running an incident with real
+discipline. This module doesn't teach a new hands-on skill — it names the OPERATING MODEL those
+skills are all part of, so you can recognize it and apply it beyond Kubernetes specifically.
+
+## DevOps: a set of practices, not a team you join
+
+"DevOps" is often misused as a job title ("I'm a DevOps engineer") or a team name ("throw it
+over to DevOps"). Properly understood, DevOps is a set of PRACTICES for how development and
+operations work together: shorter feedback loops, automation over manual process, and shared
+ownership of what happens after code ships — not a separate team that operations gets outsourced
+to.
+
+Concretely, you already practiced core DevOps ideas without the label:
+
+- **Declarative thinking** (ROOT 05) — describing desired state and letting a system enforce it,
+  instead of manually executing steps, is the same principle behind Infrastructure as Code.
+- **Fast, safe rollback** (ROOT 06) — treating recovery as a rehearsed, ordinary action rather
+  than a crisis is a direct DevOps practice (fast feedback, low-drama recovery).
+- **A repeatable troubleshooting framework** (ROOT 10) and **structured incident response**
+  (ROOT 12) — both are operational discipline, the "Ops" half of DevOps, practiced for real.
+
+## Platform Engineering: what DevOps looks like at scale
+
+**Platform engineering** is the next layer: instead of every application team reinventing how
+to deploy safely, monitor, and secure their own workloads, a platform team builds SELF-SERVICE
+tooling and golden paths that let other engineers move fast without needing deep infrastructure
+expertise themselves. The Kubernetes cluster, the CI/CD pipeline, the observability stack — all
+of it becomes a PRODUCT a platform team builds for INTERNAL customers (other engineers), not
+just infrastructure that happens to exist.
+
+A useful lens: platform engineering exists to **reduce cognitive load**. A developer who can
+deploy a well-configured, secure, observable service through a simple, guided path doesn't need
+to personally understand every Kubernetes concept from ROOT 05-10 to ship safely — the platform
+encodes that expertise once, for everyone.
+
+## Where Kubernetes fits in the larger picture
+
+Kubernetes is INFRASTRUCTURE, not the whole platform. A real platform engineering practice
+typically layers several things around it:
+
+- **Declarative delivery** — describing what should be deployed and letting automation apply it
+  (the GitOps model — future ROOT 11 content, requires a Git+deployment-automation environment
+  this course doesn't yet provide).
+- **Continuous integration/delivery** — automatically testing and shipping code changes (CI/CD —
+  future content, requires a CI runner environment).
+- **Infrastructure as Code** — declaring cloud/infrastructure resources the same way you declare
+  Kubernetes objects (future content, requires a provisioning environment like Terraform).
+- **Observability** — knowing what's actually happening in production beyond "is the Pod
+  Running" (future content, requires a metrics/logging/tracing stack).
+
+None of these require abandoning what you learned in ROOT 05-10 — they build directly on the
+same mental models (desired vs. actual state, evidence-based diagnosis, least privilege) applied
+to a wider set of systems.
+
+## Instructor Notes
+
+**Lesson goal:** Give students a name and a framework for practices they've already exercised,
+and an honest map of what ROOT 11 will eventually cover once appropriate lab environments exist —
+without pretending those labs exist today.
+
+**Approximate timing:** 20 minutes read; 15 minutes live with discussion.
+
+**Preparation:** None beyond having read `docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md` to speak
+accurately about what's planned versus what exists.
+
+**Likely misconceptions to watch for:**
+- "DevOps" as a job title/team is a very common prior belief — correct this directly and early,
+  it's the central point of the lesson.
+- Platform engineering is sometimes conflated with "just Kubernetes." Emphasize the self-service/
+  golden-path angle — the PRODUCT framing, not just the technology.
+
+**Questions to ask students:** "Which ROOT_ course so far most directly practiced a DevOps
+principle, even though it was never labeled that way?" (Most will cite ROOT 06's rollback
+discipline or ROOT 12's incident framework — both are legitimate, good answers.)
+
+**When to let a student struggle vs. provide a hint:** Not applicable — this is an orientation
+lesson with no hands-on task.
+
+**Optional extension:** ask students to name one manual process at a company they've worked for
+(or heard about) that platform engineering-style self-service tooling could have eliminated.
+
+**Expected takeaway:** DevOps and platform engineering are the organizing ideas behind almost
+everything ROOT_ has already taught — not a new, separate subject to learn from scratch.
@@ -0,0 +1,46 @@
+# Knowledge Check: DevOps & Platform Thinking
+
+---
+
+**1. A colleague says "DevOps is the team that handles our servers." What's wrong with that
+statement?**
+
+*Answer:* DevOps describes a set of PRACTICES (shared ownership, fast feedback loops,
+automation) for how development and operations work together — not a separate team that
+operations gets handed off to. Treating it as a team name misses the point that these practices
+are meant to be shared across engineering, not isolated in one group.
+
+---
+
+**2. Which ROOT_ course's central skill is most directly an example of "declarative thinking"
+applied outside Kubernetes objects specifically?**
+
+*Answer:* ROOT 05's desired-state model is the direct root of declarative thinking generally —
+Infrastructure as Code applies the exact same principle (describe what should exist, let
+automation enforce it) to cloud infrastructure rather than Kubernetes objects specifically.
+
+---
+
+**3. True or false: platform engineering's main goal is building the most technically
+sophisticated internal tooling possible.**
+
+*Answer:* False. Its main goal is reducing COGNITIVE LOAD for other engineers via self-service,
+golden-path tooling — sophistication that doesn't make another engineer's job easier isn't the
+point, even if it's technically impressive.
+
+---
+
+**4. Why can't this course build a hands-on GitOps or CI/CD Lab the same way ROOT 05-10 built
+Kubernetes Labs?**
+
+*Answer:* Those require different infrastructure the current Lab platform doesn't provide (a
+Git repository + deployment-automation tool like ArgoCD for GitOps; a CI runner for CI/CD) — see
+`docs/ROOT11_DEVOPS_PLATFORM_SCOPE.md`. Building a fake version of either would teach an
+inaccurate mental model, which is worse than honestly deferring the hands-on practice.
+
+## Instructor Notes
+
+**Facilitation:** Question 4 is worth stating plainly in a live classroom — students should
+understand this is a genuine platform limitation being handled honestly, not an oversight.
+
+**Approximate timing:** 5 minutes.
@@ -0,0 +1,45 @@
+# 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.