# ROOT 11 — DevOps & Platform Engineering: Scope Decision

Phase 6C's mandate for ROOT 11 was to stop it being an undefined `planned` placeholder by
making an explicit, evidence-based scope decision — not to fake seven hands-on labs the current
platform cannot honestly deliver. This document is that decision.

## Purpose and learning outcomes

ROOT 11 exists to give a student who has just finished ROOT 05-10 (Kubernetes hands-on) and
ROOT 12 (incident response) the vocabulary and mental model to see their skills as part of a
larger DevOps/platform engineering practice, and an honest map of what comes next once the
platform can support it hands-on. It is explicitly NOT meant to teach GitOps, CI/CD, or
Infrastructure as Code as hands-on skills in this phase.

## The seven proposed modules, evaluated against current architecture

| # | Proposed module | Classification | Why |
|---|---|---|---|
| 1 | Sysadmin → Platform Thinking | **READY TO AUTHOR NOW** | Pure orientation/reframing content. No new infrastructure needed — it's built entirely on ROOT_'s existing curriculum, referenced explicitly. Authored this phase as `root-11-m01-devops-platform-thinking`. |
| 2 | GitOps & Declarative Delivery | **REQUIRES FUTURE LAB ENVIRONMENT** | Needs a Git repository the student can push to and a deployment-automation controller (ArgoCD or Flux) watching it. The Lab platform provisions an isolated k3s VM per student today; it does not provision or wire a Git remote or a GitOps controller. Faking this with a Kubernetes-only scenario would teach "apply a manifest," not GitOps — a materially wrong mental model. |
| 3 | CI/CD Fundamentals | **REQUIRES FUTURE LAB ENVIRONMENT** | Needs a CI runner (even a minimal one) that can check out code, run a pipeline, and produce an artifact or trigger a deploy. No such runner exists in the Lab image or Platform API today. |
| 4 | Infrastructure as Code | **REQUIRES FUTURE LAB ENVIRONMENT** | Needs a provisioning target and a tool like Terraform/OpenTofu applying against it. Kubernetes objects are already declarative, but IaC's actual lesson is about provisioning infrastructure *below* Kubernetes — cloud resources, networking, the cluster itself — which this platform doesn't expose to a student sandbox. |
| 5 | Observability & SLO Thinking | **PARTIAL-LESSON-ONLY** | The conceptual half (what SLIs/SLOs are, error budgets, why "is the Pod Running" isn't observability) can be taught honestly without a metrics stack. A genuinely hands-on version needs Prometheus/Grafana (or equivalent) wired into the Lab VM, which doesn't exist today. Recommend authoring the lesson-only half in a future sub-phase; do not build the metrics stack this phase. |
| 6 | Platform Engineering & DX | **READY TO AUTHOR NOW** (folded into module 1) | Conceptually adjacent enough to module 1 that a separate module would duplicate content. Its core ideas (self-service, golden paths, reducing cognitive load) are already covered in `root-11-m01`. |
| 7 | Reliability / Automation / Operational Ownership | **PARTIAL-LESSON-ONLY** | Largely already covered hands-on by ROOT 12 (Real Ops incidents) and ROOT 10 (troubleshooting framework). A short lesson connecting those two courses' skills explicitly to "reliability engineering" as a named discipline is legitimate future content; a new hands-on lab would duplicate ROOT 12 rather than teach something new. |

## What was actually authored this phase

Only module 1 (folded with module 6's ideas) — `root-11-m01-devops-platform-thinking` — a
lesson, knowledge check, and reflection. No Lab activity exists for ROOT 11 and none was
faked. The lesson explicitly tells students which future topics (GitOps, CI/CD, IaC,
observability) require infrastructure this course doesn't yet provide, rather than staying
silent about the gap.

## What current infrastructure supports vs. what future modules need

**Supports today:** Kubernetes/k3s hands-on labs via the existing Lab VM provisioning
(Platform API → Provisioner → Lab Router), the existing assessment engine, and the existing
content/course model — sufficient for orientation and conceptual lesson content referencing
Kubernetes skills already taught.

**Would need building for modules 2-4, and the hands-on half of 5 and 7 (future phases,
NOT this phase):**
- A Git hosting target reachable from a student's Lab VM, plus a GitOps controller
  (ArgoCD/Flux) pre-installed or installable in that VM.
- A minimal CI runner (self-hosted GitHub Actions runner, Drone, or similar) wired to a
  student-scoped repository.
- A provisioning target IaC tooling can act against — even a scoped-down one (e.g., Terraform
  against a mock/local provider) — plus the tooling itself in the Lab image.
- A metrics/logging stack (Prometheus + Grafana at minimum) installed per-Lab-VM or shared with
  per-student scoping, for the hands-on half of Observability.

None of this was built in Phase 6C, per its explicit "do NOT build" list (Section 26).

## Pilot inclusion recommendation

Include `root-11-m01-devops-platform-thinking` in the first pilot as a **closing orientation
module** — no hands-on requirement, explicitly scoped as conceptual. Do not present ROOT 11 as
a complete course in pilot marketing or instructor materials; present it as "orientation now,
hands-on modules 2-7 in a future phase once the required lab environments exist." This keeps
the pilot honest about what ROOT 11 currently is versus what it will become.

See [`docs/ROOT_PILOT_CURRICULUM.md`](ROOT_PILOT_CURRICULUM.md) for how this fits the overall
pilot manifest.