Week 17 · lesson

Lesson 2: Choose the Evidence

Core path: 42 minutes

A technician does not prove competence by opening every tool.

The better question is:

What is the smallest piece of evidence that can meaningfully test my current theory?

Evidence should answer a specific question

Bad tool choice:

Open Task Manager because Task Manager is useful.

Better tool choice:

The system is slow only after sign-in. Use Task Manager startup/performance evidence to test whether startup workload is creating the delay.

The tool follows the question.

Evidence categories

Physical evidence

Examples:

  • link/activity indicators;
  • cable/connector state;
  • POST indicators;
  • temperature or visible damage;
  • printer/device control-panel state;
  • known-good substitution under safe procedure.

Firmware/device evidence

Examples:

  • UEFI/BIOS device detection;
  • boot order;
  • hardware diagnostics;
  • Device Manager or equivalent device state.

Storage evidence

Examples:

  • SMART status;
  • RAID/controller state;
  • capacity/free-space evidence;
  • Disk Management or platform equivalent;
  • filesystem/mount state.

Network evidence

Examples:

  • interface/link state;
  • IP configuration;
  • gateway reachability;
  • DNS lookup;
  • route/path evidence;
  • service/port state in supplied scenarios.

OS/application evidence

Examples:

  • Event Viewer/logs;
  • Task Manager/Activity Monitor/process tools;
  • service state;
  • update history;
  • application-specific logs/settings;
  • Safe Mode/recovery behavior.

Virtualization/cloud evidence

Examples:

  • host CPU/RAM/storage pressure;
  • guest virtual NIC state;
  • virtual network mode;
  • snapshot/backup location;
  • provider status and responsibility boundary.

Security/operations evidence

Examples:

  • endpoint protection state;
  • firewall/policy state;
  • account/permission state;
  • change/ticket history;
  • backup verification;
  • authorization and remote-support record.

Scenario A: storage warning

Ticket:

File server VM feels slow and the user thinks the network is bad.

Supplied evidence:

  • network latency is normal;
  • host CPU/RAM are normal;
  • storage controller reports degraded RAID state;
  • disk SMART data on one member shows a warning;
  • application logs show storage timeout events.

Best next evidence is not another DNS test. Stay at the storage boundary.

Scenario B: DNS vs gateway

Evidence:

local IP: valid
gateway: reachable
remote IP: reachable
hostname lookup: fails

A cable tester is not the smallest useful next tool. DNS configuration/service evidence is.

Scenario C: Windows login is slow

Evidence:

  • boot completes normally;
  • delay occurs only after user sign-in;
  • Task Manager shows multiple high-impact startup applications;
  • disk free space is healthy;
  • Event Viewer has no supplied storage faults.

A firmware update is not the strongest next move.

Scenario D: one VM cannot reach the internet

Evidence:

  • host network is healthy;
  • other VMs reach the internet;
  • affected guest has a connected virtual NIC;
  • guest is attached to host-only/internal networking.

The virtual network configuration already explains the behavior.

Reject irrelevant tools

For every incident, include one tool you will not use yet and explain why.

That matters because unnecessary tools cost time and can create noise or risk.

Student action

Complete this matrix for all four scenarios:

current theory:
question that must be answered:
best evidence/tool:
expected result if theory is right:
expected result if theory is wrong:
irrelevant tool rejected:
why rejected:

Success criteria

You pass when every evidence choice has a clear diagnostic purpose and can change what you believe about the incident.

Component explorer

Server rack and network closet inspection board

Identify the role of each rack component, then use physical placement and dependency clues to choose the next evidence source during an incident.

Unlabeled equipment rack showing a patch panel, Ethernet switch, firewall or router appliance, rack server, cable-management section, UPS, and vertical power distribution unit.
Selected component

Patch panel

Job: Terminates permanent building cabling and presents ports for patching into active network equipment.

Service clue: A link problem can exist in the horizontal cable, jack, patch panel, patch cord, or switch port; the patch panel itself does not route traffic.

Read the inspection board as text
  1. Patch panel: Terminates permanent building cabling and presents ports for patching into active network equipment. Service clue: A link problem can exist in the horizontal cable, jack, patch panel, patch cord, or switch port; the patch panel itself does not route traffic.
  2. Ethernet switch: Provides active Layer-2 connectivity between local Ethernet devices and uplinks. Service clue: Check link/activity state, port/VLAN configuration, PoE where relevant, and whether the problem is one port or the whole switch.
  3. Firewall / router appliance: Connects networks and enforces the approved routing/security boundary. Service clue: If local switching works but remote access fails, gateway, route, firewall policy, NAT, or upstream service evidence becomes more important.
  4. Rack server: Hosts an application, service, storage role, or virtualized workload for clients. Service clue: Reachable host does not prove the application service is listening; separate hardware, OS, network, and service evidence.
  5. Cable management: Keeps patch cords routed and strain-controlled so service changes remain traceable. Service clue: Good cable management reduces accidental disconnects and makes port tracing more reliable during troubleshooting.
  6. UPS: Provides battery-backed power and short-term continuity for supported rack equipment. Service clue: UPS alarms, load state, battery health, and outlet groups matter when multiple devices lose power together.
  7. Vertical PDU: Distributes rack power from the approved source/UPS to installed equipment. Service clue: A single dead device can still be a local power cord or outlet-group problem; do not assume the entire rack lost power.
Ghostty terminal simulation

Narrow a network failure from surviving behavior

Local addressing and routing work, but name resolution does not. Use the evidence to avoid the lazy diagnosis: 'the internet is down.'

Ghostty Web renders the terminal, but this lesson still uses a controlled Robotnix command engine. No unrestricted operating-system shell is connected.

Commands worth trying
  • ip addr
  • ip route
  • ping -c 2 192.168.10.1
  • nslookup example.test
  • curl -I https://example.test
  • curl -I http://203.0.113.10
Read a deterministic terminal transcript

This fallback runs the same bounded Robotnix simulation against the suggested command sequence. It does not connect to an operating-system shell or network.

Robotnix network diagnosis simulation
The failure is deterministic and isolated to lesson state. Type 'help' for available evidence commands.

$ ip addr
2: eth0: <UP> mtu 1500
    inet 192.168.10.25/24

$ ip route
default via 192.168.10.1 dev eth0
192.168.10.0/24 dev eth0 scope link

$ ping -c 2 192.168.10.1
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.9 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.8 ms
2 packets transmitted, 2 received, 0% packet loss

$ nslookup example.test
;; connection timed out; no servers could be reached

$ curl -I https://example.test
curl: (6) Could not resolve host: example.test

$ curl -I http://203.0.113.10
HTTP/1.1 200 OK
content-type: text/html
server: robotnix-sim

Read it. Prove it.

Lesson knowledge checks

Answer from the lesson you just completed. Results stay in this browser and are not submitted.
Knowledge check 1

A wired client has no link light. Which evidence source is more useful than checking DNS first?

Knowledge check 2

What makes an evidence source relevant?