Network+ Network Troubleshooting: 502 practice questions

12 of the 502 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. Interview affected users about timing and location: Select TWO actions that directly collect useful evidence.

Select two. More than one option is correct — every correct one is ticked below.

1. Clear wireless event logs before comparing user reports.

   Clearing logs destroys potentially useful timing and failure evidence instead of gathering it.
2. Interview affected users about timing and location. ✓

   Interviews reveal timing, locations, devices, and reproducible conditions.
3. Reset student wireless profiles before measuring scope.

   A disruptive client change assumes a cause before the symptom pattern is established.
4. Replace every access point before collecting reports.

   This changes the environment before evidence is gathered and may remove useful clues.
5. Compare affected and unaffected devices under similar conditions. ✓

   This helps distinguish a shared network condition from a client-specific issue.

Interview users and compare affected with unaffected cases before changing the environment.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

9. Request approval for the specific change and rollback plan: Select TWO actions that best support escalation.

Select two. More than one option is correct — every correct one is ticked below.

1. Close the incident because the technicians cannot implement the fix.

   Lack of implementation authority requires escalation, not closure, when a corrective path exists.
2. Apply the firewall change during a quiet period without approval.

   A low-usage period does not authorize a security change or remove its associated risk.
3. Request approval for the specific change and rollback plan. ✓

   Requesting authorized approval with rollback preserves governance and supports controlled recovery if the change fails.
4. Submit the evidence and reproducible symptom to the security manager. ✓

   Providing evidence and reproduction details enables the authorized owner to evaluate the proposed correction.
5. Send the incident summary to the security manager.

   A summary alone may omit the reproducible evidence needed for an informed decision.

Escalation should transfer reproducible evidence and request authorized approval for a specific reversible change.

10. 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.

11. 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.

12. 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.

Other Network+ domains

• Networking Concepts — 483 questions →
• Network Implementation — 420 questions →
• Network Operations — 399 questions →
• Network Security — 294 questions →
• All 2098 Network+ questions →
• Network+ certification: requirements, cost and exam format →