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]>
5.1 KiB
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.