Official Troubleshooting Methodology and Evidence Handling
Key Takeaways
- The troubleshooting process starts with identifying the problem and gathering information before changing the environment.
- A theory should be tested before a plan of action is implemented, and a disproven theory loops back to step two.
- Escalation is appropriate when the issue is outside authority, skill, access, safety, or business-impact limits.
- Verification includes confirming full system functionality and implementing preventive measures when appropriate.
- Evidence handling requires accurate documentation, timestamps, preservation, and chain of custody when security or legal review may be involved.
Troubleshooting Methodology
Troubleshooting is a repeatable decision process, not a guessing game. On the CompTIA Network+ N10-009 exam, Domain 5 (Network Troubleshooting) carries the single largest weight at 24%, so methodology questions appear frequently. The exam rewards the answer that follows the documented method, not the answer that jumps directly to a favorite fix. Expect performance-based questions (PBQs) that ask you to drag the steps into order, plus multiple-choice items that ask "what should the technician do next?" The almost-always-correct early move is to gather facts, define scope, and avoid unnecessary change.
The full exam is up to 90 questions in 90 minutes; with a passing score of 720 on a 100-900 scale, mastering this domain's logic is high-yield.
The Seven Standard Steps
| Step | What it means | Example |
|---|---|---|
| 1. Identify the problem | Gather information, question users, identify symptoms, determine if anything changed, approach multiple problems individually | Ask who is affected, what changed, and exactly when the issue began |
| 2. Establish a theory | Question the obvious; use symptoms to form a likely cause; consider OSI top-to-bottom or bottom-to-top | Suspect DNS if users can ping an IP but not a hostname |
| 3. Test the theory | Confirm or reject the cause; if confirmed, move on; if not, re-establish or escalate | Query DNS directly with nslookup and compare expected records |
| 4. Establish a plan | Choose a fix and identify potential effects | Schedule a firewall rule change in a maintenance window |
| 5. Implement the solution | Apply the approved fix, or escalate if needed | Change a route, renew a certificate, replace a transceiver |
| 6. Verify functionality | Confirm the service works and implement preventive measures | Test the user workflow, monitor logs, update alerting |
| 7. Document findings | Record cause, actions, results, and lessons learned | Close the ticket with evidence and the final state |
The steps loop. If a theory is disproven in step 3, return to step 2 and establish a new theory (or escalate). If a fix in step 5 creates a new symptom, roll back under change control and continue with evidence-based testing. A trap answer reverses verification and documentation, or skips testing the theory.
Two phrases inside the official steps are exam targets: in step 1, "determine if anything has changed" and "approach multiple problems individually," and in step 2, "if necessary, conduct external or internal research based on symptoms." When a scenario describes two simultaneous complaints, the correct early action is to treat each as a separate problem rather than assuming one root cause; bundling unrelated symptoms is a classic wrong answer.
Likewise, when a fix succeeds, step 6 explicitly pairs verifying functionality with implementing preventive measures, so an answer that stops at "it works now" without prevention or documentation is incomplete on Network+.
Identifying Scope
Scope dramatically narrows the likely cause, and scope questions are a Network+ favorite.
| Scope clue | Likely direction |
|---|---|
| One user affected | Endpoint, NIC, cable, switch port, user account, local DNS cache |
| One VLAN affected | Default gateway, VLAN assignment, DHCP scope, ACL, trunk config |
| One site affected | WAN link, edge router, site firewall, local ISP, power |
| One application affected | DNS record, certificate, load balancer, server pool, firewall rule |
| All Internet access affected | Default route, ISP, edge firewall, NAT, DNS forwarders |
Do not assume the largest possible outage. A single disconnected patch cable and a failed core switch can both produce "cannot connect" reports, but the correct scope, and the correct fix, differ.
Change Management and Escalation
Recent changes are the strongest clues. Firmware updates, firewall edits, new switch deployments, DHCP scope changes, certificate renewals, routing changes, and ISP maintenance all explain sudden symptoms. But correlation is not proof; verify before changing more. Escalate when:
- The issue exceeds your access or authorization level.
- The impact is high or safety-critical.
- The action requires a change window or business approval.
- Evidence suggests a security incident.
- Specialized vendor, cloud, or carrier support is required.
- You have tested reasonable theories and need additional expertise.
Evidence Handling
Some troubleshooting produces evidence for security, compliance, or legal review: packet captures, firewall and authentication logs, switch port mappings, wireless association logs, screenshots, exported configurations, and device images.
| Evidence practice | Why it matters |
|---|---|
| Preserve original data | Prevents accidental alteration |
| Record timestamps and time zone | Supports a reliable timeline |
| Document who collected the evidence | Supports accountability |
| Hash files (e.g., SHA-256) when appropriate | Demonstrates integrity |
| Maintain chain of custody | Tracks possession and transfer |
| Work on copies, not originals | Protects source artifacts |
| Limit access | Reduces disclosure and tampering risk |
In a routine performance ticket, evidence handling may be simple documentation. In a suspected compromise, preserve logs and captures before making destructive changes when feasible, and escalate to incident response if policy requires.
Common Traps
- Rebooting a device before checking logs or scope.
- Implementing a fix before testing a theory.
- Ignoring recent changes because they came from another team.
- Failing to verify from the user's perspective after a fix.
- Closing a ticket without documenting what changed.
- Altering security-sensitive evidence without recording who handled it and when.
PBQ style: Put the troubleshooting steps in the most appropriate order.
Arrange the items in the correct order
A technician suspects a recent firewall rule change caused an outage but has not yet confirmed scope or gathered logs. What should happen next?
Which practices support evidence handling during a suspected security incident? Select three.
Select all that apply