{
  "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": []
}