Diagnose faults someone else planted, by method

applied · 80 min · Objective 6.2

Task

The hard part of troubleshooting is doing it without knowing the answer. Have the faults planted for you -- by a colleague, or by a script you wrote and then deliberately did not read -- and work the method.

Steps

  1. Write lab/net/plant.sh containing six possible faults, one selected at random per run: a removed route, an over-restrictive instance rule, a missing ephemeral range, a service bound to loopback, a wrong resolver, and an asymmetric return path. Run it WITHOUT reading which it chose.
  2. Work the method and record it live in lab/net/diagnosis.md: scope the problem precisely (from where, to where, which port, since when), then state a theory before testing it.
  3. Separate name resolution from connectivity FIRST: resolve the name from the affected host, then connect to the address directly. Record which of the three outcomes you got before doing anything else.
  4. Work the four layers in order, recording what you RULED OUT and the evidence for each -- this is the half that stops a second person retesting the same thing.
  5. Name the fault, then read the script to check. Record whether you were right, how long it took, and which step in your method was decisive. Repeat until you have done at least four different faults.

Verify

grep -Eci 'ruled out|eliminated' lab/net/diagnosis.md
grep -Eci 'resolve' lab/net/diagnosis.md
grep -Ec 'fault|round' lab/net/diagnosis.md
grep -Eci 'correct|wrong|decisive' lab/net/diagnosis.md

At least four rounds recorded with explicit eliminations. Being wrong on some rounds is a better outcome than being right on all of them -- it means the faults were genuinely unknown.

Notes

Not reading the planting script before diagnosing is the entire design. A troubleshooting exercise where you know the answer trains recall, not method.

This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.