ced4568andClaude Sonnet 5
e007bcf000
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-troubleshooting-order-mcq",
|
|
"title": "Where Does the Failure Actually Live?",
|
|
"category": "Troubleshooting",
|
|
"isolation_type": "shared_namespace",
|
|
"difficulty": "Medium",
|
|
"type": "mcq",
|
|
"weight": 4,
|
|
"description": "## Where Does the Failure Actually Live?\n\n`getent hosts myapp.internal` correctly returns an IP address. `curl http://myapp.internal:8080/` returns \"Connection refused.\" What does this combination actually tell you?",
|
|
"options": [
|
|
{ "id": "a", "text": "DNS is broken — fix the hosts file or DNS server first" },
|
|
{ "id": "b", "text": "The name resolves correctly, so the problem is downstream of DNS — most likely nothing is listening on port 8080 at that address" },
|
|
{ "id": "c", "text": "The application returned an error page" },
|
|
{ "id": "d", "text": "The network cable is unplugged" }
|
|
],
|
|
"correct_option": "b",
|
|
"explanation": "A successful DNS resolution proves the name-to-IP step works — it tells you nothing about whether anything is listening on the port you're trying to reach. \"Connection refused\" specifically means a TCP SYN reached the destination and was actively rejected, most commonly because no process is listening on that port. This is exactly the kind of layer-by-layer reasoning the module's framework teaches: never re-diagnose a layer that already gave you a clean answer.",
|
|
"hints": [],
|
|
"setup_commands": [],
|
|
"default_namespace": "default",
|
|
"teardown_commands": []
|
|
}
|