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]>
This commit is contained in:
Claude Sonnet 5
+88
@@ -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.
|
||||
+46
@@ -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.
|
||||
+45
@@ -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.
|
||||
Reference in New Issue
Block a user