Network+ troubleshooting questions are where memorized definitions start falling apart. The exam does not just ask what DNS is. It asks what you should check when a laptop can ping 8.8.8.8 but cannot open intranet.company.local.
The short version: for Network+ troubleshooting, practice reading symptoms, isolating the layer, choosing the next best test, and avoiding random fixes. Start with scope, confirm the physical or wireless connection, check IP addressing, test DNS, verify routing/default gateway, look at VLAN/firewall boundaries, then document what changed.
Use these questions like mini help desk escalations. Pick the best answer, read the explanation, and pay attention to the troubleshooting order. If you need more targeted practice, pair this with the Network+ common ports practice questions, Network+ routing practice questions, Network+ wireless practice questions, and Network+ network security practice questions.
Quick troubleshooting flow before the questions
| Layer | What to ask | Common clue |
|---|---|---|
| Scope | One user, one subnet, one app, or everyone? | Saves you from rebuilding a laptop during an outage |
| Physical/wireless | Is the link real and stable? | No link light, weak Wi-Fi, wrong SSID, bad cable |
| IP addressing | Does the client have a valid IP, gateway, and mask? | APIPA, wrong subnet, duplicate IP, expired DHCP lease |
| DNS | Do names resolve to the expected address? | IP works, name fails |
| Routing | Can traffic leave the local network? | Local resources work, remote resources fail |
| Filtering | Is a firewall, ACL, VLAN, proxy, or VPN rule blocking it? | One subnet/group works while another fails |
| Performance | Is it slow because of latency, loss, duplex, congestion, or Wi-Fi quality? | Works, but painfully |
That order is not sacred, but the idea is: prove where the failure lives before changing things.
Practice question 1: IP works, names fail
A user says they cannot open any websites. You remote in and find that ping 8.8.8.8 works, but ping example.com fails with a name-resolution error. Other users on the same network are fine.
What should you check first?
A. DNS configuration on the user’s device
B. The monitor cable
C. Whether HTTPS uses TCP 443
D. The user’s keyboard layout
Answer: A. DNS configuration on the user’s device.
If an IP address responds but names do not resolve, DNS is the first suspect. Check the DNS servers assigned to the client, whether a VPN changed DNS settings, whether the adapter has a stale static DNS entry, and whether the client can query the expected DNS server.
Do not start by replacing hardware. The network path exists. The name-to-address lookup is the broken part.
For a deeper name-resolution workflow, use the DNS troubleshooting guide.
Practice question 2: APIPA address after moving desks
A desktop is moved to a different cubicle. It shows an IP address of 169.254.18.44, cannot reach the internet, and cannot reach internal file shares.
What is the most likely issue?
A. The device did not receive a DHCP lease
B. The browser cache is stale
C. The printer queue is paused
D. The user needs a stronger password
Answer: A. The device did not receive a DHCP lease.
An address in the 169.254.x.x range usually means the client assigned itself an APIPA address because it did not get DHCP. Check the switch port, cable, wall jack, VLAN assignment, DHCP scope, and whether other devices on that jack get a normal address.
A good next test is to connect a known-good laptop or cable, or move the desktop back to the original jack. You are trying to separate device, cable, port, and DHCP scope without guessing.
Practice question 3: wrong default gateway
A laptop has a valid-looking IP address, subnet mask, and DNS server. It can reach devices on the same subnet, but it cannot reach anything outside that subnet.
Which setting should you verify next?
A. Default gateway
B. Screen resolution
C. Browser homepage
D. Printer toner level
Answer: A. Default gateway.
The default gateway is where the client sends traffic destined for other networks. If local subnet communication works but off-subnet communication fails, check the gateway address, route table, VPN routes, and whether the gateway is reachable.
This is the difference between “the network is down” and “this client does not know where to send non-local traffic.” Network+ loves that distinction because real tickets do too.
Practice question 4: one VLAN cannot reach the server
Users in the Sales VLAN can reach an internal app server. Users in the Support VLAN cannot. Both groups can access the internet, and the app server is online.
What is the best next area to investigate?
A. Routing, ACL, or firewall rules between the Support VLAN and the server network
B. Reinstall every browser in Support
C. Replace the app server keyboard
D. Disable DNS for Sales
Answer: A. Routing, ACL, or firewall rules between the Support VLAN and the server network.
When one network segment works and another does not, compare the path and policy between those segments. Check VLAN interface configuration, inter-VLAN routing, firewall zones, ACLs, and whether Support is supposed to reach that server.
Do not treat it like a random endpoint problem when the symptom lines up cleanly by subnet. That pattern is useful evidence.
If VLAN logic feels fuzzy, review the Network+ VLAN practice questions.
Practice question 5: Wi-Fi connects but keeps dropping
A user reports that Wi-Fi connects, drops every few minutes, and works better when they sit near the access point. Other users near the same desk report weak signal too.
What is the best first direction?
A. Check signal strength, interference, roaming, and access point coverage
B. Reset the user’s password
C. Change the file server name
D. Assume DNS is broken
Answer: A. Check signal strength, interference, roaming, and access point coverage.
The clue is location and signal quality. If multiple users in the same area have weak or unstable Wi-Fi, investigate coverage, channel overlap, interference, access point placement, and roaming behavior.
DNS failures usually do not improve when you move closer to an access point. Password resets do not fix radio problems. Start with the evidence the environment is giving you.
For a support-focused flow, use the Wi-Fi troubleshooting checklist.
Practice question 6: duplicate IP symptoms
Two users report intermittent access to a shared app. Sometimes it works, sometimes it times out. The help desk notices duplicate IP address warnings for one workstation address.
What should you suspect?
A. Two devices may be using the same IP address
B. HTTPS is disabled everywhere
C. The app requires a new logo
D. The keyboard batteries are low
Answer: A. Two devices may be using the same IP address.
Duplicate IPs can create weird, intermittent failures because traffic may go to the wrong device or ARP entries may flip back and forth. Find both devices, check whether one has a static address inside the DHCP pool, and correct the reservation or static configuration.
This is also why “it works sometimes” should not be dismissed as user drama. Intermittent network issues often have real causes; they just make everyone look foolish for a while.
Practice question 7: firewall rule has the wrong port
A monitoring server needs to check an internal web app over HTTPS. A firewall rule was added for TCP 80, but the check still fails. The app URL starts with https://.
What should you verify?
A. Whether TCP 443 is allowed from the monitoring server to the app server
B. Whether the mouse is plugged in
C. Whether FTP port 21 is open
D. Whether the user’s wallpaper changed
Answer: A. Whether TCP 443 is allowed from the monitoring server to the app server.
HTTPS commonly uses TCP 443. If the rule only allows TCP 80, it may allow plain HTTP while blocking the actual HTTPS check. Verify source, destination, protocol, port, direction, and whether the app redirects from HTTP to HTTPS.
Port memorization is not the end goal. The goal is connecting the port to the symptom. If the port table is still mushy, review the Network+ common ports practice questions.
Practice question 8: VPN connects but internal names fail
A remote user connects to VPN. They can reach an internal server by IP address, but the internal hostname does not resolve. Public websites work.
What should you check first?
A. VPN DNS settings or split-DNS configuration
B. The user’s desk phone ringtone
C. Whether the server has a newer monitor
D. The printer paper tray
Answer: A. VPN DNS settings or split-DNS configuration.
VPN being “connected” does not guarantee DNS is configured correctly. The client may need internal DNS servers, a DNS suffix, or split-DNS rules for corporate names. If internal IP works and internal name fails, focus on DNS over the VPN path.
For full remote-access triage, use the VPN troubleshooting checklist.
Practice question 9: slow file transfer after switch change
After a switch replacement, a workstation can access the network, but file transfers to a local server are extremely slow. Pings show occasional packet loss. The issue affects only devices connected to one switch port group.
What should you investigate?
A. Cabling, port errors, speed/duplex negotiation, and switch interface statistics
B. The user’s email signature
C. Whether DNS has too many vowels
D. The browser’s saved passwords
Answer: A. Cabling, port errors, speed/duplex negotiation, and switch interface statistics.
When connectivity exists but performance is terrible after a physical network change, check the physical and data-link clues: bad patch cables, damaged runs, interface errors, speed/duplex mismatch, overloaded uplinks, or a misconfigured port.
“Slow” is not automatically an app problem. If packet loss and port-specific patterns appear, chase the network evidence.
Practice question 10: traceroute stops at the edge
Users can reach internal resources and the local gateway. They cannot reach any internet sites. A traceroute reaches the internal gateway and then stops at the firewall/edge device. Multiple users are affected.
What is the best next step?
A. Check the edge firewall, upstream connection, NAT, or ISP path
B. Clear one user’s browser cache
C. Replace one user’s keyboard
D. Ask everyone to reboot three times
Answer: A. Check the edge firewall, upstream connection, NAT, or ISP path.
Multiple users failing beyond the edge points away from a single endpoint. Check firewall status, WAN interface, default route, NAT policy, ISP circuit, and recent changes. If internal access still works, the LAN may be fine while the internet edge is broken.
This is why scope matters. One user is a ticket. A whole office is an incident.
Copy-paste Network+ troubleshooting checklist
Scope:
[ ] Who is affected: one user, subnet, site, app, or everyone?
[ ] Wired, wireless, VPN, or all paths?
[ ] What changed recently?
[ ] Exact error, destination, and impact captured?
Client/path checks:
[ ] Valid IP, mask, gateway, and DNS servers
[ ] Can reach local gateway
[ ] Can resolve destination by hostname
[ ] Ports/protocols confirmed for the app
[ ] Firewall, ACL, VLAN, or VPN policy checked if issue follows a group
[ ] Switch/AP/interface errors checked if issue follows a location
Closeout:
[ ] Fix verified with the original failed action
[ ] Root cause or best evidence documentedFAQ
Is Network+ troubleshooting mostly command memorization?
No. Commands help, but the exam usually tests judgment: what symptom points to DNS, DHCP, routing, wireless, firewall rules, or physical connectivity? You should know common tools, but the bigger skill is choosing the right next test.
Should I troubleshoot from Layer 1 every time?
Not literally every time. If the clue screams DNS, check DNS. If a switch was just replaced and half the office is dropping, check the switch. The layered model is a map, not a ritual you must perform like a sleepy robot.
Are these questions enough to pass Network+?
No single page is enough. Use this for troubleshooting practice, then add subnetting, ports, wireless, routing, security, and real labs. Passing is easier when the concepts connect to realistic support scenarios.
Bottom line
Network+ troubleshooting is about disciplined narrowing. Scope the problem, prove what works, test the next likely layer, and avoid changes you cannot explain later.
If you can read a messy ticket and say, “This smells like DNS,” “This is probably DHCP,” or “This follows the VLAN boundary,” you are studying the right way. That skill helps on the exam and on the job, which is the whole point.