The troubleshooting methodology

Why this matters

Domain 5 is 24% of the exam — the largest single domain — and this objective is its spine. CompTIA's methodology is not a vague suggestion; it is a named, ordered list of steps, and the exam will give you a scenario, tell you which step has just been completed, and ask what comes next.

That means this is the one place where memorising an order is genuinely required. The good news is that the order is sensible, so once you understand why each step precedes the next you will not need to recite it.

The methodology is also the difference between engineers who fix things and engineers who change things until the symptom moves. Under pressure, the temptation is always to skip to a fix.

The lesson

The seven steps

CompTIA's methodology, in order:

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 implement preventive measures if applicable
7. Document findings, actions, outcomes, and lessons learned throughout the process

Each is expanded below with the sub-steps the objective names.

1. Identify the problem

You cannot fix what you have not defined. "The internet is down" is a report, not a problem statement.

Gather information. What exactly is failing, for whom, since when, and how widely? One user, one floor, or the site? All services or one application? The scope alone usually eliminates most possible causes — a fault affecting one user is not a core switch.

Question users. They are the only witnesses. Ask what they were doing, what the exact error said, when it last worked, and whether anything changed on their side. Ask without blame, because a user who fears being blamed will not mention that they moved the cable.

Identify symptoms. Distinguish the reported symptom from the observed one. "Email is broken" may be an expired password, a full mailbox, a DNS failure or a dead switch port, and they present identically to the person reporting it.

Determine if anything has changed. This is the highest-yield question in troubleshooting, because most faults follow a change — a deployment, a patch, a configuration edit, a new device, a cable moved. Check the change records from domain 3. "Nothing changed" is very often wrong, and usually means "nothing I did changed", which is a different statement.

Duplicate the problem, if possible. A fault you can reproduce is a fault you can test against and, afterwards, confirm fixed. One you cannot reproduce leaves you guessing on both ends. If it cannot be duplicated, find out what distinguishes the conditions where it occurs.

Approach multiple problems individually. If several things are broken, resist treating them as one. They may share a cause, and they may not — and changing several things at once means you will not know which change mattered. Separate them, and note that multiple simultaneous faults often do share an upstream cause, which is a theory to test rather than an assumption.

2. Establish a theory of probable cause

Now form a hypothesis. The objective names three approaches to generating one.

Question the obvious. Check the simple things first, because they are common and cost seconds. Is it plugged in? Is the port enabled? Is the account locked? Is there a link light? Experienced engineers skip these and lose hours; the step is in the list because it is so frequently skipped.

Consider multiple approaches. Do not commit to the first idea. Generate several candidate causes and rank them by likelihood and by cost to test. The best next test is usually the one that eliminates the most possibilities for the least effort, not the one that confirms your favourite theory.

Top-to-bottom/bottom-to-top OSI model. Work the layers systematically. Bottom-up starts at layer 1 — cable, link, interface — and works up; it suits hard failures where nothing works at all. Top-down starts at the application and works down; it suits cases where some things work and one application does not.

Divide and conquer is the third approach: start in the middle, typically at layer 3. Can you ping the gateway? If yes, layers 1 to 3 are healthy and the problem is above; if no, it is below. One test halves the search space, which is why this is usually the fastest approach when you have no strong prior.

3. Test the theory to determine the cause

Test the hypothesis, and the objective is explicit about both outcomes.

If theory is confirmed, determine next steps to resolve problem. You now know the cause; move to planning the fix.

If theory is not confirmed, establish a new theory or escalate. Go back to step 2 with what you have learned — a disproved theory is information, not failure — or escalate if the problem is outside your access, your expertise or your authority.

Escalation is a legitimate step and not an admission of defeat. The exam treats it as the correct answer when the scenario places the fault beyond the technician's remit — a carrier circuit, a vendor defect, a system owned by another team.

The discipline that matters here: change one thing at a time, and change it back if it did not help. A trail of undone speculative changes is how a simple fault becomes an unrecoverable mess.

4. Establish a plan of action and identify potential effects

Before touching production, decide what you will do and what it might break.

The plan covers the steps, the order, how long it takes, who is affected, whether a maintenance window is needed, and — most importantly — how to undo it. A fix with no rollback is a gamble.

"Identify potential effects" is the part people omit. Restarting a switch fixes the port and drops everyone else on it. Changing a DNS record fixes one service and is cached elsewhere for hours. Fixing a subnet mask on the gateway affects every host behind it. The question to ask is always: what else does this touch?

This is also where the change management process from domain 3 engages. Anything beyond a trivial fix goes through it, and an outage justifies an emergency change rather than skipping the process entirely.

5. Implement the solution or escalate as necessary

Carry out the plan, or hand it to whoever can.

Work in the planned order, verify each step before the next, and stop if behaviour departs from what you expected — an unexpected result means your understanding was incomplete, and continuing on a wrong model makes things worse.

6. Verify full system functionality and implement preventive measures

Full is the operative word. Confirm the original symptom is gone, confirm the user agrees it is fixed, and confirm you have not broken something adjacent. A fix verified only by the engineer who made it is verified by the person least able to see what they missed.

Implement preventive measures if applicable is what separates fixing from improving. If a link failed because it had no redundancy, add it. If a certificate expired, add monitoring for expiry dates. If an ACL change broke things because nobody could review it, put the configuration under version control. The fault has told you something about the system; acting on that is how the same incident stops recurring.

7. Document findings, actions, outcomes, and lessons learned

Record what was wrong, what you did, whether it worked, and what you learned.

This is last in the list and first to be skipped, and it is the step that compounds. Its value:

• The next person meeting the same symptom finds the answer in minutes.
• Recurring faults become visible as a pattern rather than a series of coincidences — three failures of the same model is a fleet problem.
• The knowledge stops living only in one person's head.
• It feeds the change and asset records that make the next fault easier.

Note the objective's wording: throughout the process, not at the end. Documenting as you go is more accurate and more likely to happen, because notes written at 4 a.m. while the fault is live contain detail that is gone by morning.

Using the methodology in exam questions

Two reliable patterns:

"What should the technician do NEXT?" Identify which step the scenario has just completed and pick the one that follows. The trap is an answer that is a perfectly good action from a later step — implementing a fix when the theory has not been tested is wrong even if the fix would work.

"A technician did X and it did not resolve the issue." The theory was not confirmed, so the answer is to establish a new theory or escalate — not to try another fix at random.

And the general principle underneath both: the methodology is about not skipping ahead. Almost every wrong answer in this objective is a step taken out of order.