Adds all 6 ROOT 02 modules (Linux system administration, storage & filesystems, the Networking Mental Model, Linux network inspection, DNS & HTTP, Linux troubleshooting) — 37 activities, each with a real lesson, demonstration/guided exercise, knowledge check, hands-on Lab, and reflection. The Networking Mental Model module (M3) gets deliberately extra depth per its "critical module" designation, with no lab by design — conceptual mastery via knowledge check and guided exercise, matching root-05-m00's own precedent. Adds 6 new hands-on Linux/networking scenarios plus 2 MCQs: linux-service-inspection (inspects the platform's own real nginx without touching it — a genuinely safe, real service-inspection target that avoids ever risking the Lab's own connectivity), linux-service-lifecycle (start/ verify/stop a fully controllable service), linux-storage-inspection, linux-network-inspection (ip/ss/getent/curl, each framed as answering one specific diagnostic question), linux-dns-http-diagnosis (a genuine DNS-resolves-but-wrong-port failure, diagnosed and fixed), and linux-troubleshooting-framework (a real missing-config-file failure, resolved via the RootNode Observe/Evidence/Hypothesis/Test/Repair/Validate/Prevent framework). All tested end-to-end via the real scenario-validation API, including negative tests confirming they fail when unsolved. Wires rootnode-linux-networking-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. Co-Authored-By: Claude Sonnet 5 <[email protected]>
23 lines
1.4 KiB
JSON
23 lines
1.4 KiB
JSON
{
|
|
"id": "linux-service-state-mcq",
|
|
"title": "Verifying a Service Is Actually Running",
|
|
"category": "Linux Administration",
|
|
"isolation_type": "shared_namespace",
|
|
"difficulty": "Easy",
|
|
"type": "mcq",
|
|
"weight": 3,
|
|
"description": "## Verifying a Service Is Actually Running\n\nA colleague says \"I restarted the service, it should be fine now.\" What's the single most reliable way to actually confirm the service is both running AND reachable on its expected port, without asking them?",
|
|
"options": [
|
|
{ "id": "a", "text": "Trust their statement — restarting almost always works" },
|
|
{ "id": "b", "text": "Check that its process exists (e.g. via ps/pgrep) AND that its expected port is in LISTEN state (e.g. via ss) — a running process alone doesn't guarantee it bound its port successfully" },
|
|
{ "id": "c", "text": "Check the service's source code for bugs" },
|
|
{ "id": "d", "text": "Wait 24 hours and see if anyone complains" }
|
|
],
|
|
"correct_option": "b",
|
|
"explanation": "A process can be running (visible in ps) while having failed to bind its expected port (e.g. it's already in use, or it crashed after startup logging but before binding) — checking both facts independently is what actually confirms \"running and reachable,\" not either one alone.",
|
|
"hints": [],
|
|
"setup_commands": [],
|
|
"default_namespace": "default",
|
|
"teardown_commands": []
|
|
}
|