feat(content): author the ROOT_ V1 orientation module and three practice-bank intro lessons
- 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 <[email protected]>
This commit is contained in:
Claude Sonnet 5
+66
@@ -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.
|
||||
+55
@@ -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.
|
||||
+31
@@ -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.
|
||||
+39
@@ -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.
|
||||
+29
@@ -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.
|
||||
+30
@@ -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.
|
||||
Reference in New Issue
Block a user