A user calls the help desk and says "the internet is down." That one sentence could mean a dozen different failures: a loose patch cable, a laptop that never associated with the Wi-Fi, a Dynamic Host Configuration Protocol (DHCP) server that stopped handing out addresses, a dead router, a Domain Name System (DNS) outage, or a firewall rule blocking a single application. The technicians who close these tickets fastest aren't the ones who memorized the most command switches. They follow a workflow: a fixed sequence of checks that starts at the local machine and works outward, eliminating one layer at a time until the failure has nowhere left to hide.
CompTIA A+ Core 2 (220-1202) tests this workflow directly in the Software Troubleshooting domain. The exam rarely asks you to define a command in isolation; instead, a scenario describes a symptom, tells you what a technician has already checked, and asks for the next diagnostic step. The decision tree itself is the tested skill. This article walks that tree in order — local configuration, local network, remote connectivity, name resolution, then the application and port layer — and finishes with a worked end-to-end sequence. For deep syntax detail, pair this with our command-reference article; here the commands appear in the order you would actually run them.
Network problems live in layers, so troubleshoot from the inside out
Every connection depends on a stack of things working at once: a live physical or wireless link; a valid Internet Protocol (IP) configuration on top of it — address, subnet mask, default gateway, DNS server; packets actually reaching the local gateway and crossing to remote networks; names like google.com resolving to IP addresses; and finally the specific application's port open and its service running on the far end.
The workflow follows that stack from the bottom up, because each layer depends on everything below it. A test at a low layer rules problems in or out for every layer above. If the machine can't ping its own gateway, there is no point investigating DNS. If it can ping a public IP address on the internet, the link, the configuration, and the routing path are all proven good in one stroke.
Keep this map in your head as a table, because exam questions are built from its rows: a scenario gives you the symptom, and you name the layer and the command that tests it.
| Symptom | Likely layer | First command or check |
|---|---|---|
| Adapter shows "unplugged"; no Wi-Fi association | Physical link | Check cable, link lights, wireless connection |
| Address starts with 169.254 | IP configuration (DHCP) | ipconfig /all, then ipconfig /renew |
| Can't reach anything, config looks valid | Local network | ping the default gateway |
| Gateway replies, internet does not | Remote connectivity / routing | ping 8.8.8.8, then tracert |
| Ping by IP works, ping by name fails | Name resolution (DNS) | nslookup |
| Internet works, one application or site fails | Application / port | netstat, firewall and proxy settings |
Ask how many people are affected before you touch a command prompt
Before running a single command, establish scope, because scope tells you where the problem lives. One user unable to reach the file server while neighbors work fine means the fault is almost certainly on that client: its cable, adapter, configuration, or software. Nobody able to reach it means the clients are probably fine and the fault is shared infrastructure: the server itself, a switch, the router, or the DHCP or DNS service everyone depends on.
Testing from a second machine is the fastest scope check there is. If a neighboring computer reaches the resource, stop staring at the server and go back to the first client. If the second machine fails the same way, shift from "client problem" to "server or infrastructure problem" immediately.
Scope has a middle tier too: one department down while the rest of the building is fine points at what that department shares, typically its wiring-closet switch. On the exam, "several users in one area report..." means shared local infrastructure, not any individual desktop.
Check the physical link and wireless association before anything else
The bottom of the stack is the cheapest to check, so check it first. On a wired connection, look at the link light on the adapter and the switch port. A dark link light with a cable plugged in means no physical connection at all, and no software fix will help. Reseat the cable, try a known-good cable, or try a different port before going further.
On wireless, the equivalent check is association: is the laptop actually connected to the correct network? A machine that silently attached to a guest network or a neighbor's access point produces symptoms that mimic deeper failures. Confirm the Service Set Identifier (SSID), the signal strength, and that airplane mode or a physical wireless switch isn't engaged.
Windows adapter states tell you which layer to visit next. "Unplugged" or "disconnected" means a link problem. "Limited connectivity" means the link is up but the machine couldn't get a proper IP configuration, which points at DHCP. "No internet access" means the local configuration looks valid but Windows couldn't verify a path out — a check it makes by connecting to a Microsoft test URL and confirming DNS resolves it, so the cause can be the router, DNS, or both. Treat these messages as hints, not diagnoses.
ipconfig /all tells you whether the machine even has a valid identity
Once the link is confirmed, run ipconfig /all. Plain ipconfig shows the IP address, subnet mask, and default gateway; the /all switch adds what you actually need: whether DHCP is enabled, the DHCP server and lease times, the DNS servers, and the adapter's Media Access Control (MAC) address.
You're answering specific questions. Is the address from DHCP or set statically? If DHCP, is there a valid lease from the expected server? Do the address, mask, gateway, and DNS servers make sense for this network? A static machine carried in from another site, or a DHCP server handing out the wrong scope, shows up here as parameters that don't fit.