From f695b7c95d467ec04eae6248ba4c16d495692472 Mon Sep 17 00:00:00 2001 From: ced4568 Date: Wed, 26 Aug 2026 18:33:09 -0500 Subject: [PATCH] feat(content): author the ROOT_ V1 orientation module and three practice-bank intro lessons MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - root-01-m00-welcome-to-root: program overview + Lab-lifecycle orientation (disposable Labs, permanent progress, hints, reset/recreate, help-requests). - One short intro-lesson activity for each of the three bare practice-bank modules (root-06-m01, root-07-m01, root-10-m02), explaining what the bank is and why it has no per-scenario teaching of its own — the minimum real authoring needed for genuine self-paced readiness without reclassifying them optional (see the curriculum migrations). Co-Authored-By: Claude Sonnet 5 --- .../01-lesson-welcome-to-root.md | 66 +++++++++++++++++++ .../02-lesson-your-disposable-lab.md | 55 ++++++++++++++++ .../m00-welcome-to-root/03-knowledge-check.md | 31 +++++++++ .../00-lab-bank-intro.md | 39 +++++++++++ .../00-lab-bank-intro.md | 29 ++++++++ .../00-lab-bank-intro.md | 30 +++++++++ 6 files changed, 250 insertions(+) create mode 100644 content/root/root-01-computing-linux-foundations/m00-welcome-to-root/01-lesson-welcome-to-root.md create mode 100644 content/root/root-01-computing-linux-foundations/m00-welcome-to-root/02-lesson-your-disposable-lab.md create mode 100644 content/root/root-01-computing-linux-foundations/m00-welcome-to-root/03-knowledge-check.md create mode 100644 content/root/root-06-kubernetes-application-workloads/m01-deployments-and-workloads/00-lab-bank-intro.md create mode 100644 content/root/root-07-kubernetes-networking-config/m01-services-and-networking/00-lab-bank-intro.md create mode 100644 content/root/root-10-kubernetes-troubleshooting-observability/m02-general-troubleshooting/00-lab-bank-intro.md diff --git a/content/root/root-01-computing-linux-foundations/m00-welcome-to-root/01-lesson-welcome-to-root.md b/content/root/root-01-computing-linux-foundations/m00-welcome-to-root/01-lesson-welcome-to-root.md new file mode 100644 index 0000000..df37a50 --- /dev/null +++ b/content/root/root-01-computing-linux-foundations/m00-welcome-to-root/01-lesson-welcome-to-root.md @@ -0,0 +1,66 @@ +# Welcome to ROOT_ + +ROOT_ is RootNode Academy's path from "I can use a computer" to "I can run and repair real +infrastructure." It's built for anyone roughly high-school age and up — including college +students, career changers, help-desk technicians, junior sysadmins, and working developers who +want to move into DevOps, cloud, or platform engineering. There's no strict age cutoff: what +matters is whether you're ready for the material, not how old you are. + +## Where ROOT_ goes + +``` +ROOT 01 Computing & Linux Foundations +ROOT 02 Linux Administration & Networking +ROOT 03 Git & Collaborative Development +ROOT 04 Containers & Docker +ROOT 05 Kubernetes Foundations +ROOT 06 Kubernetes Application Workloads +ROOT 07 Kubernetes Networking & Configuration +ROOT 09 Kubernetes Security +ROOT 10 Kubernetes Troubleshooting & Observability +ROOT 12 RootNode Real Ops +CAPSTONE Operate and Recover a Production-Like Environment +``` + +Each course builds on real skill from the one before it — you won't be asked to use a tool or +concept that a previous course didn't already teach you. By the end, you'll have operated a real +Kubernetes cluster, diagnosed and fixed real incidents, and demonstrated it in a hands-on +capstone — not answered multiple-choice questions about it. + +## How you'll actually learn + +Every module follows the same rhythm: + +**Learn → Practice → Lab → Troubleshoot → Validate** + +- **Learn** — a short lesson introduces one real concept, plainly, with no unexplained jargon. +- **Practice** — a demonstration or guided exercise lets you see the concept applied before + you're on your own with it. +- **Lab** — you do the real thing yourself, in your own disposable Lab environment: a real + Linux shell, real Git, real Docker, and (from ROOT 05 onward) a real Kubernetes cluster. +- **Troubleshoot** — Labs are built to sometimes not go as planned on the first try, on purpose. + Figuring out why something didn't work is as much the skill as doing it right the first time. +- **Validate** — your Lab checks its own result. You'll know immediately whether you actually + solved it, not just whether you think you did. + +## Self-paced or instructor-led + +ROOT_ is built to work either way. If you're going through it on your own, every module gives you +everything you need without a teacher in the room. If you're in an instructor-led class or camp, +your instructor can see your progress, help when you're stuck, and add their own pacing and +discussion on top of the same real curriculum — nothing about the platform changes between the +two, only who else is watching your progress. + +## Assessments and the Capstone + +A few courses end in a short formal assessment — a handful of real, timed Lab tasks (not a +multiple-choice quiz) that check you can actually do what the course taught, not just recognize +the right answer. The program ends with the **Capstone**: no more new teaching, just a +production-like environment with real incidents to find and fix, the same way you would on the +job. + +## Your progress is permanent — your Lab is not + +One thing to know before you start: the Lab environment you work in is disposable and can be +recreated at any time. Your academic progress is not. The next module covers exactly what that +means and why it's nothing to worry about. diff --git a/content/root/root-01-computing-linux-foundations/m00-welcome-to-root/02-lesson-your-disposable-lab.md b/content/root/root-01-computing-linux-foundations/m00-welcome-to-root/02-lesson-your-disposable-lab.md new file mode 100644 index 0000000..7fd79bc --- /dev/null +++ b/content/root/root-01-computing-linux-foundations/m00-welcome-to-root/02-lesson-your-disposable-lab.md @@ -0,0 +1,55 @@ +# Your Disposable Lab + +Every hands-on Lab in ROOT_ gives you a real, isolated environment — a real Linux shell from +ROOT 01 onward, real Git and Docker from ROOT 03-04, and a real Kubernetes cluster from ROOT 05 +onward. It's yours alone while you're working in it. Here's what you need to know before your +first one. + +## Disposable means disposable + +Your Lab environment can be recreated at any time — when you start a new Lab, when an +instructor resets a classroom session, or if the environment needs to be refreshed. When that +happens, **anything that only exists inside the Lab disappears**: files you created in the +terminal, a local Git repository you initialized, a Docker container or image you built, a +Kubernetes object you deployed. None of that is backed up, and none of it needs to be — it was +never the point. + +## Your academic progress is not disposable + +What IS permanent, stored on RootNode's servers the moment you earn it: which lessons you've +read, which Labs you've completed, your assessment results, and your position in the course +sequence. Recreating your Lab never erases any of that. You can lose a Lab entirely and pick up +exactly where you left off in the course. + +## How you know you actually solved it + +Every Lab task validates itself — when you think you're done, you run the check and get a real +pass/fail answer immediately, based on the real state of your environment, not on your own +guess. If it fails, that's useful information, not a penalty: it's telling you specifically what +isn't right yet. + +## If you get stuck + +Most Labs have hints available, revealed one at a time so you can try the next step yourself +before seeing more. Using a hint doesn't cost you anything or affect your result — it's there to +keep you moving, not to be avoided on principle. A formal, timed assessment may disable hints; +if so, the assessment will tell you plainly before you start. + +If a Lab's environment itself seems broken rather than the task being hard (a command that +should work doesn't, the environment won't start), use **Reset Scenario & Environment** to tear +down and rebuild it cleanly rather than fighting a broken environment. + +## If you're in an instructor-led session + +Your instructor can see your progress in real time and gets notified the moment you use **Need +Help** — no need to wait to be noticed. Use it for anything: a Lab that seems broken, a concept +that didn't click, or just wanting a second pair of eyes before you second-guess a working +solution. + +## Returning to the course + +When you're done with a Lab — pass or still stuck — you can always return to the course view and +come back to it later. Nothing about leaving a Lab mid-task loses your place. + +You're ready. Let's start with how a computer actually runs the software you're about to spend +this program controlling. diff --git a/content/root/root-01-computing-linux-foundations/m00-welcome-to-root/03-knowledge-check.md b/content/root/root-01-computing-linux-foundations/m00-welcome-to-root/03-knowledge-check.md new file mode 100644 index 0000000..04253dd --- /dev/null +++ b/content/root/root-01-computing-linux-foundations/m00-welcome-to-root/03-knowledge-check.md @@ -0,0 +1,31 @@ +# Knowledge Check: Welcome to ROOT_ + +--- + +**1. If your Lab environment is recreated, what happens to a file you saved inside it, and +what happens to your completed Labs so far?** + +*Answer:* The file disappears — nothing inside the Lab persists across a recreation. Your +completed Labs and course progress are unaffected — those are stored on RootNode's servers, not +in the Lab, and survive regardless of what happens to any Lab environment. + +**2. A Lab task fails your validation check. What should that tell you?** + +*Answer:* Specifically what isn't correct yet, based on the real current state of your +environment — it's diagnostic information to act on, not a penalty. + +**3. Name one thing to try before assuming a Lab is "just broken."** + +*Answer:* Check the available hints (revealed one at a time), and if the environment itself +genuinely seems broken rather than the task being hard, use Reset Scenario & Environment to +rebuild it cleanly. + +--- + +## Instructor Notes + +**Facilitation:** This is a good moment to actually demonstrate a Lab reset live if you have +time — students remember "I saw it happen and nothing bad occurred" far better than being told +it's safe. + +**Approximate timing:** 3 minutes. diff --git a/content/root/root-06-kubernetes-application-workloads/m01-deployments-and-workloads/00-lab-bank-intro.md b/content/root/root-06-kubernetes-application-workloads/m01-deployments-and-workloads/00-lab-bank-intro.md new file mode 100644 index 0000000..c71091a --- /dev/null +++ b/content/root/root-06-kubernetes-application-workloads/m01-deployments-and-workloads/00-lab-bank-intro.md @@ -0,0 +1,39 @@ +# Practice Bank: Deployments & Workloads + +This module is different from the ones before it. There's no new lesson here — you already got +the real teaching in **Deployments, Scaling & Updates** and **Jobs, CronJobs & DaemonSets**. This +is eight short, focused Labs that drill the exact same skills at speed: deploy, scale, roll +forward, add a liveness probe, edit a live object, and reason about Jobs/CronJobs/DaemonSets +without a guided walkthrough alongside you. + +## Why this exists + +Real fluency with `kubectl` comes from repetition, not from reading about it a second time. Each +Lab here is a small, self-contained task — no long setup, no new concepts — so you can move +quickly and build the kind of muscle memory that matters when you're troubleshooting a real +cluster under time pressure later in this program. + +## How to use it + +Work through the eight Labs in order. If one takes you more than a few minutes, that's useful +information — it usually means the earlier module's concept hasn't fully clicked yet, and it's +worth a quick re-read of that lesson before continuing rather than pushing through by trial and +error. + +## Instructor Notes + +**Delivery:** This module has no lesson/demonstration/knowledge-check scaffolding by design — it +is the original Phase 1-5 "workloads" scenario bank, reused here as a self-paced speed-practice +set once the real teaching (root-06-m02/m03) has already landed. In an instructor-led cohort, +this is a good candidate for a timed "workloads sprint" between the teaching modules and Jobs. + +**Capstone note:** These eight scenarios are also the exact set the pre-existing +`rootnode-path.json` "workloads" stage requires to unlock the Capstone assessment (a separate, +older mechanism from this course's own prerequisite chain — see +docs/ROOT_V1_CURRICULUM_MANIFEST.md). Do not mark this module optional/is_required=false without +re-checking that gate; a student can only be told to skip it if the Capstone gate itself is +intentionally changed too. + +**Common mistake to watch for:** students treating the MCQ-style activities +(jobs-cronjobs-mcq, daemonset-mcq, deployment-strategy-mcq) as throwaway trivia — they're +checking the same conceptual judgment calls the reflection in root-06-m03 raised, just faster. diff --git a/content/root/root-07-kubernetes-networking-config/m01-services-and-networking/00-lab-bank-intro.md b/content/root/root-07-kubernetes-networking-config/m01-services-and-networking/00-lab-bank-intro.md new file mode 100644 index 0000000..79bd7f1 --- /dev/null +++ b/content/root/root-07-kubernetes-networking-config/m01-services-and-networking/00-lab-bank-intro.md @@ -0,0 +1,29 @@ +# Practice Bank: Services & Networking + +Like the workloads practice bank before it, this module has no new lesson. **Services & Service +Discovery** and **Ingress & NetworkPolicy Foundations** already taught the concepts. This is four +short Labs that drill exposing a Deployment, reasoning about a NodePort, and resolving a Service +by DNS from inside the cluster — the everyday networking moves you'll use constantly from here on. + +## How to use it + +Work through the four Labs in order. Two of them (`services-mcq`, `expose-service-basics`) will +feel familiar — you did a close variant of `expose-service-basics` in the earlier teaching +module. That's intentional: it's the same skill under slightly different conditions, checking +that it generalizes rather than that you memorized one exact command. + +## Instructor Notes + +**Delivery:** No lesson/demonstration/knowledge-check scaffolding by design — this is the +original Phase 1-5 "networking" scenario bank plus two extra Labs (`nodeport-task`, +`dns-resolution-mcq`) not part of that original set, reused here as self-paced speed practice. + +**Capstone note:** `services-mcq` and `expose-service-basics` are the exact pair the +pre-existing `rootnode-path.json` "networking" stage requires to unlock the Capstone assessment +— a separate, older mechanism from this course's own prerequisite chain (see +docs/ROOT_V1_CURRICULUM_MANIFEST.md). Do not mark this module optional/is_required=false without +re-checking that gate. + +**Common mistake to watch for:** confusing a NodePort's cluster-internal ClusterIP with the +node-level port it also opens — the DNS-resolution Lab is a good moment to have a student narrate +out loud which address they expect to work from where. diff --git a/content/root/root-10-kubernetes-troubleshooting-observability/m02-general-troubleshooting/00-lab-bank-intro.md b/content/root/root-10-kubernetes-troubleshooting-observability/m02-general-troubleshooting/00-lab-bank-intro.md new file mode 100644 index 0000000..469aba8 --- /dev/null +++ b/content/root/root-10-kubernetes-troubleshooting-observability/m02-general-troubleshooting/00-lab-bank-intro.md @@ -0,0 +1,30 @@ +# Practice Bank: General Troubleshooting Operations + +**Kubernetes Health Probes & Troubleshooting** and **The RootNode Troubleshooting Framework** +already taught you how to *think* about a broken cluster. This module is six short Labs that +drill the individual `kubectl` operations you'll reach for while doing that thinking: pulling +logs, copying files in and out of a container, running a one-off exec, cordoning a node, and +reasoning about pod-to-node placement and log output. + +## How to use it + +Work through the six Labs in order. None of them require the full Observe/Evidence/Hypothesis/ +Test/Repair/Validate/Prevent framework from the previous module — they're deliberately narrower, +so you can build raw command fluency without also holding the whole framework in your head at +the same time. + +## Instructor Notes + +**Delivery:** No lesson/demonstration/knowledge-check scaffolding by design — this is the +original Phase 1-5 "troubleshooting" scenario bank plus one extra Lab (`container-logging-mcq`) +not part of that original set, reused here as self-paced speed practice. + +**Capstone note:** The five original Labs (`extract-logs-basics`, `kubectl-cp-basics`, +`exec-command-basics`, `node-cordon-basics`, `pod-node-assignment-mcq`) are the exact set the +pre-existing `rootnode-path.json` "troubleshooting" stage requires to unlock the Capstone +assessment — a separate, older mechanism from this course's own prerequisite chain (see +docs/ROOT_V1_CURRICULUM_MANIFEST.md). Do not mark this module optional/is_required=false without +re-checking that gate. + +**Common mistake to watch for:** running `kubectl cp` with the source/destination arguments +reversed — a good moment to have a student read the command back out loud before running it.