First tool to investigate shared-drive network latency

Governing principle: match the tool to the symptom

The scenario asks for the first tool when the symptom is lag on a shared drive and the administrator is specifically investigating network latency. The relevant CompTIA Network+ troubleshooting doctrine, particularly the tool-selection objective in the Network Troubleshooting domain, is to choose the diagnostic that directly measures the suspected condition before moving to deeper or broader tools. Here the suspected condition is path latency, so the first step should be a path-latency measurement rather than packet capture, flow accounting, or device polling.

Why traceroute fits first

Traceroute sends probes toward the shared-drive server and reports each hop along the path with round-trip times. That makes it the most direct first check for where latency appears: on the local switch/router, an internal route, or a WAN link. The supplied reasoning makes the same point, noting that traceroute tracks the path packets take and measures round-trip time per hop, which is the best way to pinpoint where latency is occurring. This maps cleanly onto the scenario and makes option C the correct first tool.

Why the other options are weaker first choices

A Wireshark capture can reveal TCP retransmissions, slow application responses, and request/response gaps, but it requires a capture point, can generate large amounts of data, and does not directly map per-hop path latency. NetFlow (B) describes traffic conversations and volumes, not per-hop round-trip time. SNMP (D) is useful for polling interface counters, errors, and device health, but it does not trace the path to the shared drive. These tools are valuable after traceroute narrows the suspect segment.

Exam takeaway

When the question says “network latency” and asks what to use first, prefer the tool that shows the path and per-hop delay. Use Wireshark later to inspect application or TCP behavior once the latency location is narrowed.