CompTIA A+ Core 1 Networking Tools: How to Choose the Right Tool for the Right Scenario

If you’re studying for CompTIA A+ Core 1 (220-1101), the big thing to keep in mind is actually pretty simple: when you get a symptom, can you choose the right networking tool without overthinking it? Honestly, that’s way more important than just memorizing definitions on their own.

Also, keep the exam scope straight. Core 1 focuses on practical support tools and common commands. Some items people discuss in real-world networking, like dig, port scanners, and network TAPs, are useful supplemental knowledge, but they are broader than the core A+ command list. I’ll flag those as real-world extensions so you don’t confuse “good to know” with “most likely tested.”

1. How to choose the right tool on A+

Honestly, I try to keep the workflow pretty simple: start with the symptom, figure out which layer is probably causing the trouble, try the least intrusive check first, confirm what’s actually broken, make the fix, verify it’s working, and then document what you changed. On exam questions, CompTIA often wants the best first step, not the deepest possible tool.

2. Objective mapping and exam scope

For 220-1101, know the tool categories CompTIA expects you to recognize: cable crimper, cable stripper, punchdown tool, tone generator/probe, loopback plug, cable tester, TDR, OTDR, Wi‑Fi analyzer, and common commands such as ping, ipconfig, ifconfig, netstat, nslookup, tracert/traceroute, arp, hostname, nbtstat, and net. Real-world additions like dig, ip addr, ss, port scanners, and network TAPs are useful context, but treat them as secondary for A+ prep.

3. Installation tools vs diagnostic tools

Crimper: used to attach an 8P8C modular connector, commonly called RJ-45, to twisted-pair copper cable. In other words, it helps you build or repair the end of the cable, but it won’t tell you whether that cable is actually performing the way it should.

Punchdown tool: seats conductors into a keystone jack or patch panel IDC. Usually, the permanent horizontal cabling gets terminated to jacks and patch panels, while stranded patch cables are the ones that typically end in modular plugs. And here’s the thing that catches people all the time: keep those pair twists as close to the termination as you can, because that really helps preserve performance.

Wire stripper / cable stripper: prep tools. A wire stripper removes insulation from a conductor; a cable stripper removes the outer jacket. These are installation tools, not troubleshooting tools.

Exam trap: if the problem is APIPA, DNS failure, or no link, eliminate crimpers and punchdown tools unless the scenario explicitly says you are terminating or repairing cabling.

4. Physical troubleshooting and cable test depth

Tone generator and probe: finds a cable. It traces an unlabeled jack or cable run, but does not prove the run is electrically healthy.

Loopback plug: a limited diagnostic aid that loops a signal back to a port or interface. It can help in some NIC/port diagnostics, but in modern endpoint support you’ll more often start with link lights, a known-good cable, another switch port, or built-in adapter diagnostics.

Basic cable tester: checks continuity and wiremap. It can commonly detect opens, shorts, and miswires. Some better units may detect split pairs, but not all do. A basic tester is not the same as a cable certifier.

Cable certifier/qualification tester: deeper than a basic tester. It validates performance characteristics against cabling standards and is more advanced than what A+ usually expects, but the distinction matters technically.

TDR: time domain reflectometer for copper. It sends out a signal, watches for reflections, and then estimates how far away a fault might be, like an open, a short, or some kind of impedance problem.

OTDR: optical time domain reflectometer for fiber. It looks at reflections and signal loss in optical cabling, which helps you track down breaks, bad splices, dirty connectors, and even bend loss. Never look into a fiber end or transceiver.

Typical results to recognize:

• Open pair: conductor broken or not terminated.
• Short: conductors touching.
• Miswire: pins terminated in the wrong order.
• Split pair: continuity may exist, but pairs are incorrectly matched, causing degraded signal quality.
• Distance to fault: TDR/OTDR estimate how far down the run the issue is, which helps decide whether to reterminate, replace a patch cord, or inspect a section of cable.

When I’m troubleshooting structured cabling, I like to isolate each segment one at a time: NIC, patch cable, wall jack, horizontal run, patch panel, and then the switch port. Replace patch cords first when practical; troubleshoot permanent runs when the issue stays with the jack/run.

5. When you’re troubleshooting wireless, a Wi‑Fi analyzer is honestly one of the most useful tools you can have.

A Wi‑Fi analyzer lets you see things like SSIDs, BSSIDs, signal strength, channel use, and, on some tools, even channel utilization. What it usually shows is RF conditions, not guaranteed throughput, and it won’t directly prove an ISP problem, an authentication failure, or a DHCP issue.

Key interpretation points:

• 2.4 GHz: fewer non-overlapping channels, so overlap and congestion are common.
• 5 GHz/6 GHz: more channels and different planning considerations; overlap is less of a problem, but distance and attenuation still matter.
• Weak RSSI: points toward distance, walls, poor AP placement, or client roaming to a weak BSSID.
• Crowded channel: suggests co-channel contention, especially in classrooms, apartments, and conference areas.

A Wi‑Fi analyzer is not a full spectrum analyzer. It can suggest interference, but advanced non-Wi‑Fi interference analysis usually requires more specialized tools.

6. Command-line tools that A+ actually cares about

Think of each command as answering one question.

ipconfig /all: “What is my local configuration?” On Windows, this is honestly one of the most useful commands you’ll use for A+ troubleshooting. When you run it, take a look at the IPv4 address, subnet mask, default gateway, DNS servers, whether DHCP is enabled, and the lease details.

ipconfig /all

If you see 169.254.x.x, that is a self-assigned link-local IPv4 address, commonly called APIPA on Windows. Most of the time, that means the client couldn’t get a DHCP lease. That does not automatically mean “the DHCP server is down”; it could also be a bad cable, wrong VLAN, failed relay, NAC issue, or local NIC problem. A few useful follow-ups are:

ipconfig /flushdns

ifconfig: older Unix/Linux command for interface details. A+ may still reference it, but on many modern Linux systems it is legacy or deprecated in favor of newer interface and routing commands.

ping: “Can I reach this target at a basic network layer?” Good first test, but not proof that the application works. Also, failed ping does not always mean the host is down, because ICMP may be blocked.

ping 8.8.8.8 ping server1

nslookup: “Can DNS resolve this name, and which server answered?” This is your primary exam-friendly DNS tool.

nslookup -type=mx example.com

That gives you a quick, practical way to check forward lookups, record types, and reverse lookups. If IP connectivity works but name resolution fails, suspect wrong DNS settings, unreachable DNS server, bad records, or stale cache.

tracert on Windows and traceroute on Linux and macOS answer: “Where along the path does traffic appear to fail?” They work by sending packets with increasing TTL values. Be careful interpreting results: missing replies or high latency at an intermediate hop do not always prove that hop is the problem, because routers often rate-limit or ignore TTL-expired responses.

netstat -an: “What local ports are listening, and what sessions exist?” This is local host visibility, not remote scanning. On modern Linux, ss often replaces netstat, but A+ still expects netstat recognition.

arp -a: “Has this host learned IPv4 local neighbor mappings?” ARP is an IPv4 thing, while IPv6 uses Neighbor Discovery instead.

hostname: “Which system am I on?” Simple, but useful in remote support.

nbtstat: NetBIOS-related information. This is legacy and often disabled in modern networks, but you should recognize it.

net use: network share and mapped drive management.

net use net use Z: \\fileserver\share net use Z: /delete

7. Two high-value workflows: APIPA and DNS

APIPA workflow: check link light, run ipconfig /all, confirm 169.254.x.x, verify DHCP enabled, try /release and /renew, test with known-good cable or port, confirm the correct VLAN/SSID, then escalate with evidence. And keep in mind that APIPA can still allow limited communication on the local link, but it won’t give you normal routed network access.

DNS workflow: ping a known IP, then test the hostname, then run nslookup. If IP works and name fails, check configured DNS servers in ipconfig /all, clear local cache with ipconfig /flushdns, and verify whether the record itself is wrong. And just because a browser fails doesn’t automatically make it a DNS problem — it could also be a proxy issue, a certificate issue, or something specific to that application.

8. Real-world extensions: packet capture, scanners, and TAPs

These are useful, but more supplemental than core A+ command knowledge.

Protocol analyzer: captures and inspects packets. On a switched network, you’ll usually need a host-based capture, a mirrored switch port, or some kind of traffic access device to see the traffic you actually care about. Packet capture is passive by itself, but the visibility method matters. Encrypted traffic may hide payloads even when you can see session setup.

Port scanner: probes a remote host for open, closed, or filtered ports. This is different from netstat, which shows local listeners and sessions. Open means a service answered; it does not guarantee the application is healthy.

Network TAP: commonly a passive way to copy traffic from a link, though implementations vary. Insertion into a production link may still require planning or a maintenance window.

9. Mini scenarios and answer elimination

Self-assigned 169.254.x.x address: start with ipconfig /all, not tracert.

Can ping printer IP but not print by name: start with nslookup, not a crimper.

No link light at desk: start with cable/port checks and a cable tester, not a protocol analyzer.

Need to find which patch panel port matches a wall jack: tone generator and probe, not TDR.

Need to know how far down a copper run the break is: TDR, not OTDR.

Fiber uplink flapping between closets: OTDR, and inspect for dirty connectors or bend radius problems.

One conference room has poor Wi‑Fi but the rest of the office is fine: Wi‑Fi analyzer, not ISP escalation.

Need to verify whether RDP is listening on a Windows PC: netstat -an locally; if checking remotely in an authorized environment, a port scan may help.

10. Security, compliance, and safe troubleshooting

Scanning, packet capture, and traffic interception require authorization. If you use them casually, they can definitely run into policy, legal, or compliance issues. Packet captures can expose credentials, session tokens, personally identifiable information, and sometimes even protected health information, so you’ve got to treat them carefully. Active scans can trigger intrusion detection or prevention alerts. Stick to least privilege, follow change control, and protect the evidence if there’s any chance the issue could turn into a security investigation.

Before you escalate, make sure you’ve gathered the useful evidence: the timestamp, hostname, IP configuration, MAC address, SSID or VLAN if that matters, the switch port or jack label, command output, cable test results, screenshots, and the exact error message.

11. Quick review for exam day

The exam mindset is simple: physical symptoms point to physical tools, wrong IP settings point to ipconfig/ifconfig, name problems point to nslookup, weak Wi‑Fi points to a Wi‑Fi analyzer, copper faults point to TDR, fiber faults point to OTDR. So when you’re reading the question, identify the symptom, think about the likely layer, and pick the least complicated correct tool first.