Troubleshooting Methodology
The seven steps, in order
A user reports "the internet is down," and the difference between a fast fix and a flailing one is whether you walk a fixed process or start randomly swapping parts. CompTIA defines that process as seven ordered steps, and objective 5.1 of the N10-009 exam objectives[1] expects you to know both the wording and the sequence. The steps are: (1) identify the problem, (2) establish a theory of probable cause, (3) test the theory to determine the cause, (4) establish a plan of action to resolve the problem and identify potential effects, (5) implement the solution or escalate as necessary, (6) verify full system functionality and, if applicable, implement preventive measures, and (7) document findings, actions, outcomes, and lessons learned.
The single most testable property of this list is its order. The investigation half (steps 1 to 3) always finishes before the action half (steps 4 to 7): you do not plan a change until a test has confirmed the cause, and you do not implement until you have a plan. Two boundaries trip people up. First, a theory (step 2) is a guess and a test (step 3) is what turns the guess into a confirmed cause; describing the cause is not the same as proving it. Second, implement (step 5) and verify (step 6) are separate steps, because applying a change is not evidence that the change worked. Reading a stem, ask "is this person gathering information, guessing, proving the guess, planning, doing, checking, or writing it up?" and the numbered step follows directly.
The same seven-step method appears on CompTIA A+; Network+ is the network-specific lens on it, so the layered approaches in the next section attach to step 2.
Step 1: identify the problem
Identifying the problem is information gathering, not fixing, and rushing past it is the most common way technicians waste an hour. CompTIA names six activities here: gather information (from log files and error messages), question users, identify symptoms, determine if anything has changed, duplicate the problem, and approach multiple problems individually.
"Did anything change?" earns its place first
A network that worked yesterday and fails today almost always broke because something changed: a config push, a firmware update, a new device, an expired certificate, a swapped cable. Asking what changed, and checking change records, points at the cause faster than any other single question, which is why it is a named activity and why change documentation feeds straight into this step.
Question users without trusting the diagnosis
Users report symptoms reliably ("I cannot reach the file share") but their guesses about cause ("the server is down") are unreliable. Capture the symptom, the scope (one user or many, one app or all), and the timing, then verify independently rather than acting on the user's theory.
Duplicate the problem and split multiple problems
Duplicating the problem proves the symptom is real and reproducible before you invest effort, and it gives you a test you can repeat after a fix. Approaching multiple problems individually matters when a user lists several complaints: treat each as its own problem with its own cause, because forcing them into one root cause invents a fault that does not exist. Narrowing scope here, one user versus a whole VLAN, local versus remote, wired versus wireless, is what makes the later theory step tractable.
Steps 2-3: theory, then a test that proves it
A theory is a guess about cause; a test is what turns the guess into a confirmed cause. Keeping those two steps distinct is the heart of the method, because acting on an unproven theory is how a confident technician makes things worse.
Step 2: establish a theory of probable cause
Start by questioning the obvious: an unplugged cable, a disabled interface, a wrong subnet mask, a tripped breaker. For layered technologies, CompTIA tells you to consider multiple approaches, including working the OSI model top-to-bottom or bottom-to-top, so the search is systematic instead of scattershot. The four named search tactics, covered in the next section, all live inside this step.
Step 3: test the theory to determine the cause
Testing means doing the minimum experiment that confirms or refutes the theory: swap the suspect cable into a known-good port, ping the gateway, move the laptop to a known-good jack. The branch after the test is the part the exam loves:
- Theory confirmed -> proceed to step 4 and plan the fix.
- Theory not confirmed -> re-establish a new theory (loop back to step 2), or escalate if the problem is beyond your knowledge, access, or authority.
The trap is treating a failed test as license to start changing things. A disproven theory sends you back to step 2 for a new one, never forward to implementing a change you have no evidence for. Escalation is a legitimate outcome here as well as at step 5: if testing reveals the issue sits with a carrier, a vendor, or a team you do not control, hand it off rather than guessing.
Choosing an approach: top-down, bottom-up, divide-and-conquer, follow-the-path
Inside step 2, four named approaches keep a layered investigation systematic. They are tactics for how to form and order your theories, not extra steps in the seven-step method, and the exam tests whether you can match an approach to a scenario.
- Top-down starts at the application layer (Layer 7) and works downward. Reach for it when the complaint is application-level, such as a web app that fails while the host clearly has network connectivity.
- Bottom-up starts at the physical layer (Layer 1) and works upward. It is the instinct for a suspected physical fault: no link light, a dead port, a damaged cable, a powered-off device.
- Divide-and-conquer starts in the middle of the stack (often the network or transport layer) and uses each test to eliminate half the remaining layers. A successful ping, for example, confirms Layers 1 to 3 in one test and lets you focus upward. It is fastest when you have no strong starting hypothesis.
- Follow-the-path traces the traffic hop by hop from source to destination, checking each switch, router, and firewall along the route. Reach for it when connectivity fails across multiple devices or segments and you need to find where the path breaks.
No approach is "correct" in the abstract; the right one is whichever matches the symptom. A stem that says "a user cannot load any website but can ping the default gateway" hands you connectivity at the lower layers, so top-down (or divide-and-conquer from a successful ping) is the efficient choice, while bottom-up would waste time re-checking a link you already know works.
Steps 4-7 and the exam-pattern recognition
With the cause confirmed, the remaining steps turn a diagnosis into a durable fix and a record others can use.
Step 4: plan of action and potential effects
Before touching anything, decide exactly what you will change and identify the potential effects, including the blast radius if the change goes wrong. This is also where change management belongs: a non-trivial fix gets a change request, a rollback plan, and a maintenance window so the fix itself does not cause a new outage.
Step 5: implement the solution or escalate
Apply the planned fix, or escalate if it exceeds your access, authority, or skill. Escalation is not failure; it is the correct move when the resolution sits with another team, a vendor, or a carrier.
Step 6: verify full system functionality and prevent recurrence
Confirm the problem is gone as the end user experiences it, not merely that the device you touched responds. "Full system functionality" means end to end. Then implement preventive measures so the same fault does not return: replace the marginal cable rather than reseating it, document the config so it survives a reboot, add monitoring on the failure point.
Step 7: document findings, actions, outcomes, and lessons learned
Write down what was wrong, what you did, the result, and what was learned. This feeds the knowledge base and change records that make the next similar incident faster, and it is a graded step, not optional cleanup.
How the exam asks it
Most methodology questions take one of three shapes. (1) Order: "Place these activities in the correct sequence" or "What is the next step after testing the theory?" The answer follows the fixed 1-to-7 order; after a confirmed test comes step 4 (plan), not step 5 (implement). (2) Classify one action: "A technician documents the fix in the ticket. Which step is this?" Map the verb to the step (here, step 7). (3) Choose an approach: "A user cannot reach an app but can ping the server. Which approach is most efficient?" Pick the approach that matches the known-good versus suspect layers (here, top-down, since lower-layer connectivity is already proven). The recurring distractors are swapping implement for verify, treating theory as if it were a confirmed cause, and listing a search approach (top-down, follow-the-path) as one of the seven steps.
The four troubleshooting approaches within step 2
| Approach | Where it starts | How it narrows | Reach for it when |
|---|---|---|---|
| Top-down | Application layer (L7) | Works down the OSI stack one layer at a time | The complaint is application-level (a service or app fails) |
| Bottom-up | Physical layer (L1) | Works up the OSI stack one layer at a time | You suspect cabling, ports, or physical media |
| Divide-and-conquer | A middle layer (often L3/L4) | Each test halves the remaining layers to check | You have no strong starting hypothesis and want speed |
| Follow-the-path | The source host | Traces traffic hop by hop toward the destination | Connectivity fails across multiple devices or segments |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Know CompTIA's seven troubleshooting steps in exact order
The methodology is a fixed sequence: (1) identify the problem, (2) establish a theory of probable cause, (3) test the theory to determine the cause, (4) establish a plan of action and identify potential effects, (5) implement the solution or escalate, (6) verify full system functionality and implement preventive measures, (7) document findings, actions, outcomes, and lessons learned. The order is the most-tested property, because most questions ask which step comes next or where a described action belongs.
Trap Reordering implement (step 5) before plan of action (step 4); you always plan the change and its effects before applying it.
- Investigation finishes before action: steps 1-3 then 4-7
Steps 1 to 3 are the investigation (identify, theory, test) and steps 4 to 7 are the action (plan, implement, verify, document). The dividing line is a confirmed cause: you never plan or implement a change until a test has proven the theory. Treat any stem that has someone changing configuration before testing as out of order.
Trap Acting on a theory before testing it; an unproven theory sends you back to step 2, never forward to a fix.
- Step 1 is information gathering, not fixing
Identifying the problem covers six activities: gather information from logs and error messages, question users, identify symptoms, determine if anything has changed, duplicate the problem, and approach multiple problems individually. No change is made at this step; its job is to define what is actually broken and how to reproduce it before any theory is formed.
- "Did anything change?" is the highest-yield first question
A network that worked yesterday and fails today almost always broke because of a recent change: a config push, a firmware update, a new device, an expired certificate, or a swapped cable. Determining what changed, by asking users and checking change records, points at the cause faster than any other single activity, which is why CompTIA names it explicitly inside step 1.
Trap Placing "determine if anything changed" under establish a theory (step 2); it is an information-gathering activity inside identify the problem (step 1).
- Duplicate the problem before you spend effort on it
Duplicating the problem proves the symptom is real and reproducible, and it hands you a repeatable test you can rerun after a fix to confirm it worked. If you cannot reproduce a reported fault, you have not yet defined the problem and should keep gathering information rather than guessing at a cause.
- Treat multiple reported faults as separate problems
When a user lists several complaints, approach each as its own problem with its own cause rather than forcing them into one root cause. Bundling unrelated symptoms invents a single fault that does not exist and sends you chasing it, where solving them individually keeps each diagnosis tractable.
Trap Assuming several simultaneous symptoms must share one root cause; unrelated faults solved as one waste time on a phantom cause.
- A theory is a guess; a test is what confirms the cause
Step 2 establishes a theory of probable cause and step 3 tests it to determine the actual cause. The two are deliberately separate because describing a likely cause is not the same as proving it. Question the obvious first (unplugged cable, disabled interface, wrong subnet mask) before reaching for exotic explanations.
Trap Treating the step 2 theory as the confirmed cause and skipping step 3; the cause is not established until a test confirms it.
- After testing, a confirmed theory advances; a disproven one loops or escalates
If the test confirms the theory, proceed to step 4 and plan the fix. If it does not confirm the theory, either re-establish a new theory (return to step 2) or escalate when the problem exceeds your knowledge, access, or authority. A failed test never licenses you to start making changes.
Trap Beginning to change configuration after a test disproves your theory; a disproven theory returns you to step 2 for a new one.
- For layered problems, work the OSI stack top-to-bottom or bottom-to-top
CompTIA's guidance for layered technologies is to consider multiple approaches, including working the OSI model top-to-bottom or bottom-to-top, so the search is systematic instead of random. This keeps step 2 disciplined: you eliminate layers in order rather than jumping between unrelated guesses.
- Bottom-up starts at Layer 1 for suspected physical faults
The bottom-up approach starts at the physical layer (Layer 1) and works upward through the OSI stack. Reach for it when the symptom points at hardware or media: no link light, a dead port, a damaged or wrong cable, or a powered-off device. It wastes time when lower-layer connectivity is already proven good.
- Top-down starts at Layer 7 for application-level complaints
The top-down approach starts at the application layer (Layer 7) and works downward. It fits a complaint about a specific service or app when the host plainly has network connectivity, for example a web app that fails even though the user can ping the server. Choosing it avoids re-checking lower layers that are already known good.
- Divide-and-conquer halves the layer search each test
Divide-and-conquer starts in the middle of the OSI stack (often the network or transport layer) and uses each test to eliminate half the remaining layers. A successful ping, for instance, confirms Layers 1 to 3 in one test and lets you focus upward. It is fastest when you have no strong starting hypothesis about which layer holds the fault.
Trap Calling a fixed Layer-1-upward sweep "divide-and-conquer"; that is bottom-up, while divide-and-conquer starts mid-stack and halves the search each test.
- Follow-the-path traces traffic hop by hop across devices
The follow-the-path approach traces the traffic from source to destination, checking each switch, router, and firewall along the route to find where the path breaks. Reach for it when connectivity fails across multiple devices or network segments rather than at a single host, because the break is somewhere along the route, not on one endpoint.
Trap Reaching for top-down or bottom-up on a single host when the fault spans the route between hosts; a multi-device path break is what follow-the-path is for.
- The four approaches are tactics inside step 2, not extra steps
Top-down, bottom-up, divide-and-conquer, and follow-the-path describe how to form and order theories within step 2 (establish a theory). They are not additional steps in the seven-step method, so a question asking for the methodology's steps never lists them.
Trap Listing a search approach such as top-down or follow-the-path as one of the seven methodology steps; the seven steps are fixed and these are tactics within step 2.
- Plan of action also identifies the potential effects of the fix
Step 4 is not just deciding what to change; it explicitly identifies the potential effects of that change, including the blast radius if it goes wrong. This is where change management lives for a non-trivial fix: a change request, a rollback plan, and a maintenance window so resolving one problem does not cause a new outage.
Trap Assuming identifying potential effects happens at verification (step 6); the effects of a change are weighed in the plan (step 4), before it is applied.
- Escalate when a fix exceeds your access, authority, or skill
Step 5 is implement the solution or escalate as necessary, and escalation is a legitimate outcome, not a failure. Hand the problem to another team, a vendor, or a carrier when the resolution needs access, approval, or expertise you do not have. Escalation can also occur at step 3 if testing reveals the issue sits outside your control.
Trap Forcing an unauthorized or risky change rather than escalating; when a fix is beyond your access, authority, or skill, escalation is the correct step-5 action.
- Verify full system functionality end to end, as the user sees it
Step 6 confirms the problem is gone as the end user experiences it, not merely that the device you touched responds. "Full system functionality" means end to end, so a partial check on one component can let a residual fault ship. This step also implements preventive measures so the same fault does not recur.
Trap Confirming only that the device you changed responds; verification must prove the user's full workflow works, or a residual fault survives.
- Implement does not equal verify; they are separate steps
Applying a change (step 5) is not evidence that the change fixed the problem; verification (step 6) is a distinct step that proves it. The exam routinely offers "implement" as a distractor for "verify" and vice versa, so map the action precisely: applying the fix is step 5, confirming it worked is step 6.
Trap Picking implement (step 5) when the stem describes confirming the fix worked; confirming functionality is verify (step 6).
- Preventive measures belong to step 6, not a separate step
Implementing preventive measures (replacing a marginal cable instead of reseating it, saving a running config so it survives a reboot, adding monitoring on the failure point) is part of step 6, verify full system functionality. It stops the same fault from recurring rather than just clearing the current symptom.
- Documentation is the final graded step, not optional cleanup
Step 7 documents findings, actions, outcomes, and lessons learned. It feeds the knowledge base and change records that make the next similar incident faster to diagnose, and it is a required step in the method. A fix is not complete until it is written down, even when the symptom is already gone.
Trap Treating documentation as optional once the problem is fixed; step 7 is part of the methodology, and skipping it forces the next technician to rediagnose from scratch.
- Match an action to its step by the verb in the stem
Many methodology items describe one activity and ask which step it is. Map the verb: gathering information or questioning users is step 1, guessing a cause is step 2, swapping a cable to confirm is step 3, deciding what to change is step 4, applying it is step 5, confirming end-to-end is step 6, and writing it up is step 7.
- The next step after a confirmed test is plan, not implement
When a stem says the technician has just tested and confirmed the cause and asks for the next step, the answer is step 4 (establish a plan of action and identify potential effects), not step 5 (implement). Jumping straight to implementing skips the plan, which is exactly the ordering error these questions probe.
Trap Choosing implement the solution as the step right after confirming the cause; the immediate next step is plan of action (step 4).
- No SYN-ACK means blocked; an immediate RST,ACK means no listener
In a capture, a client SYN that gets no SYN-ACK at all means the request never reached a responding service: the host is down, the service is not running, or a firewall is silently dropping the traffic. By contrast, an immediate RST,ACK in reply to the SYN means the host is up and its TCP stack actively refused the connection because nothing is listening on that port. The difference between silence and a reset tells you blocked-or-down versus port-closed.
Trap Treating an immediate RST,ACK the same as no reply, when a reset is an active refusal from a reachable host and silence suggests a drop or a down service.
4 questions test this
- A network technician uses Wireshark to investigate intermittent connection timeouts to an internal HTTPS server. The capture shows repeated…
- A technician is using Wireshark to troubleshoot a failed HTTPS connection. The capture shows the client sending a TCP SYN to port 443, and…
- A technician runs netstat -an on a workstation and observes numerous connections in the SYN_SENT state to a single remote IP address on…
- A technician captures traffic with Wireshark and observes a client sending a TCP SYN to a server on port 443. The server immediately…