Network+ Network Troubleshooting: 398 practice questions

12 of the 398 Network Troubleshooting questions in the Certsqill Network+ bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for Network+? Take the free 5-min readiness check →

1. Compare current configuration and scanner behavior: Which action provides the strongest next evidence about th

1. Compare current configuration and scanner behavior with the prior baseline and the maintenance record. ✓

   This combines state, observed behavior, and documented maintenance to identify and corroborate the changed condition.
2. Compare current settings with the prior baseline.

   This is useful, but it omits behavior and the maintenance record that can correlate the configuration change with the symptom.
3. Review the change ticket.

   The ticket describes planned work but does not establish the current-versus-previous configuration.
4. Compare the current scanner setting.

   One setting may miss a network change affecting scanner behavior.

Compare current configuration and behavior with the known-good baseline and maintenance record.

2. Test one variable on the isolated terminal during: Which approach reproduces the issue safely?

1. Disable switching safeguards across the branch during the approved test window.

   Removing safeguards expands risk and is unnecessary when an isolated terminal is available.
2. Change wireless channels and firmware together during business hours.

   Simultaneous production changes increase impact and obscure which change affected disconnects.
3. Test one variable on the isolated terminal during the approved window. ✓

   An authorized, isolated, single-variable test limits impact and preserves causal clarity.
4. Reset every point-of-sale device before testing.

   A broad reset can disrupt operations and changes multiple device states without confirming the cause.

Use an isolated terminal during the approved window and change one variable at a time.

3. Test local addressing and routing before application: Which layered hypothesis should be tested first?

1. Disable endpoint protection before validating the path

   Security software may matter, but disabling it before validating addressing and routing introduces risk and skips lower-layer evidence.
2. Replace the application server before checking network reachability

   Other offices reach the service, so replacing the server is premature before testing the affected office’s network path.
3. Reconfigure every office gateway before comparing paths

   Changing all gateways expands scope and obscures causality when only one office currently shows the symptom.
4. Test local addressing and routing before application service behavior ✓

   With power and link confirmed, verifying local IP settings and routing narrows the problem before examining higher-layer service behavior.

After physical checks, test local addressing and routing before moving upward to application behavior or replacement.

4. Ping the default gateway from an affected terminal: Which test best meets that requirement?

1. Capture traffic from one external application session

   A capture may reveal application details but does not directly locate the boundary between local and upstream failure.
2. Restart every affected terminal and switch

   A broad restart changes multiple variables simultaneously, making the original fault harder to isolate accurately.
3. Replace the perimeter firewall configuration immediately

   Changing the firewall before isolating the fault introduces risk and does not distinguish endpoint from upstream causes.
4. Ping the default gateway from an affected terminal ✓

   Testing the gateway separates local connectivity from problems beyond the access layer and upstream network.

Testing the default gateway establishes whether local addressing and access-layer connectivity work before investigating upstream services.

5. Test that port with a known-good workstation: Which action most directly confirms or rejects the port theory?

1. Clear the workstation's local DNS cache and repeat application tests.

   This tests possible name-resolution state on the original endpoint, not the suspected switch port directly.
2. Reboot the access switch and compare all affected hospital workstations afterward.

   A reboot is disruptive and changes device state without providing a controlled endpoint comparison.
3. Replace the workstation's default gateway and retest internal application access.

   Changing the gateway tests host Layer 3 configuration rather than the suspected port's operation.
4. Test that port with a known-good workstation. ✓

   Keeping the suspected port constant while substituting a known-good workstation isolates the port from the original endpoint.

A known-good workstation on the same port isolates the port from the original workstation.

6. Verify the management session and inspect ICMP filtering: Which action best rejects that theory without making

1. Replace the terminal battery and retest ICMP

   Replacing the battery is disruptive and unnecessary because successful management traffic already demonstrates the terminal is active.
2. Reset the depot access switch to restore reachability

   Resetting the switch changes network state but does not address the contradiction between ICMP failure and management success.
3. Declare the terminal unreachable from the network

   The established management session demonstrates network reachability even though one diagnostic protocol receives no reply.
4. Verify the management session and inspect ICMP filtering ✓

   A successful management session proves the terminal responds, while filtering explains why ICMP testing failed.

Successful TCP management access rejects the powered-off theory; ICMP may be filtered independently of host availability.

7. Assess affected services: Which planning activity most directly addresses the requirement to understand operat

1. Assess affected services, outage duration, dependencies, and rollback ✓

   Impact planning identifies affected services, expected disruption, dependencies, and recovery steps before implementation begins.
2. Capture authentication packets during peak admission

   Capturing traffic may provide evidence but does not itself estimate service impact or establish rollback planning.
3. Replace all venue access points before testing

   Replacing equipment expands scope and risk without analyzing which services the authentication change could affect.
4. Increase wireless transmit power across all access points

   Higher transmit power may alter coverage but does not evaluate authentication-change consequences or recovery requirements.

Impact assessment identifies affected services, dependencies, expected disruption, and rollback needs before a risky network change.

8. Modify only the approved deny rule and record the change: Which action is best?

1. Modify only the approved deny rule and record the change ✓

   A narrowly scoped, recorded change addresses the confirmed cause while preserving causality and limiting unintended impact.
2. Change routing, DNS, and firewall settings together

   Simultaneous changes obscure causality and make verification difficult if the update service remains inaccessible.
3. Replace the entire firewall policy with a standard template

   A full policy replacement introduces unrelated changes and can obscure whether the approved correction resolved the fault.
4. Disable firewall inspection for the affected subnet

   Disabling inspection weakens security controls and exceeds the approved correction without proving necessity.

Implement only the authorized rule correction, recording it so results can be attributed to one controlled change.

9. Test representative clients across affected locations: Which verification action best confirms full functional

1. Ping the access point from test laptops.

   This tests infrastructure reachability, not access to required learning systems.
2. Check the access point status light.

   A status light does not verify authentication, addressing, routing, or application access.
3. Confirm that each affected access point has obtained a management address.

   Management addressing verifies infrastructure configuration, not authentication or end-to-end access to learning services.
4. Test representative clients across affected locations, device types, authentication, addressing, and each required learning service. ✓

   This efficiently verifies end-to-end functionality across representative conditions and required services.

Use representative endpoints to test authentication, networking, and every required learning service.

10. Document symptoms: Which documentation entry best captures a reusable lesson?

1. Record only the final firewall rule value and its deployment timestamp

   A configuration snapshot lacks the symptoms, reasoning, and verification evidence needed for future troubleshooting.
2. Record that the outage was resolved successfully and close the ticket

   A closure statement provides no reusable information about diagnosis, corrective action, or validation.
3. Document symptoms, evidence, cause, fix, and verification ✓

   This preserves the diagnostic path and outcome so future technicians can recognize and reproduce the successful resolution.
4. Attach every unrelated alert generated during the entire outage window

   Unfiltered alerts add noise and can obscure the evidence that identified and resolved the fault.

Reusable lessons preserve the evidence-to-cause-to-fix chain and verification result.

11. Inspect or replace the damaged patch cable and retest: What is the most decisive next step?

1. Reset the access switch to factory defaults before collecting more evidence

   A factory reset is disruptive and cannot distinguish cable damage from port hardware or configuration faults.
2. Replace the server certificate and restart the application service

   A certificate or service issue would not normally create interface CRC errors limited to one access port.
3. Flush client DNS caches and renew every affected workstation lease

   DNS and DHCP renewal cannot explain CRC errors isolated to one switch interface and one physical connection.
4. Inspect or replace the damaged patch cable and retest the same port ✓

   The isolated port and CRC evidence strongly implicate the physical link, so replacing the cable tests that theory directly.

CRC errors isolated to one port make the cable or physical link the strongest testable hypothesis.

12. Define the change impact and obtain an approved: What is the best immediate action?

1. Define the change impact and obtain an approved maintenance window ✓

   Firmware work may interrupt critical sessions, so impact analysis and authorized scheduling must precede implementation.
2. Upgrade the switch immediately to test whether loss disappears

   Immediate firmware changes are disruptive and can obscure the original cause without approval or a rollback plan.
3. Disable monitoring alerts until the packet loss stops

   Suppressing alerts removes evidence and does not assess service impact or authorize a corrective change.
4. Replace all distribution switches before comparing symptoms

   Replacing multiple devices creates broad impact and prevents identifying whether one switch caused the loss.

Potentially disruptive firmware work requires impact assessment and approved scheduling before implementation.

Other Network+ domains

• Networking Concepts — 389 questions →
• Network Implementation — 348 questions →
• Network Operations — 316 questions →
• Network Security — 227 questions →
• All 1678 Network+ questions →