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]>
41 lines
1.4 KiB
Markdown
41 lines
1.4 KiB
Markdown
# Knowledge Check: DNS and HTTP
|
|
|
|
---
|
|
|
|
**1. Name the four failure categories this module introduced.**
|
|
|
|
*Answer:* DNS failure, routing/connection failure, TCP-succeeds-but-application-never-responds,
|
|
and HTTP/application failure (a full response comes back but it's wrong).
|
|
|
|
---
|
|
|
|
**2. A request returns HTTP 500. What does that tell you about DNS and TCP connectivity?**
|
|
|
|
*Answer:* Both worked completely — a 500 means a full HTTP response was received, so the failure
|
|
is purely inside the application's own logic, not the network path to reach it.
|
|
|
|
---
|
|
|
|
**3. Why is "connection refused" a MORE specific diagnosis than "timed out"?**
|
|
|
|
*Answer:* "Refused" means a packet reached the destination and was actively rejected (almost
|
|
always: nothing listening on that port) — you know the destination is reachable. "Timed out"
|
|
means no response at all, which could mean unreachable, no route, or silently blocked —
|
|
genuinely less specific.
|
|
|
|
---
|
|
|
|
**4. A teammate says "DNS must be broken" because a request fails. What should you check
|
|
BEFORE agreeing?**
|
|
|
|
*Answer:* Whether the name actually resolves at all (`getent hosts` or `dig`) — many failures
|
|
that "feel like DNS" are actually one layer downstream (routing, port, or application), and
|
|
DNS itself may be working perfectly.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 4 mirrors this module's own Lab almost exactly — a good moment to
|
|
preview it if not already started.
|
|
|
|
**Approximate timing:** 5 minutes.
|