The 6-step CompTIA A+ troubleshooting methodology, in plain English

What are the six steps

CompTIA publishes them in the front matter of the 220-1201 objectives document, before domain 1 starts. There is no objective number attached and CompTIA says outright that the list is not a formal objective or part of the exam. The order still matters, because each step protects you from a mistake the next step would otherwise make. Skip step 2 and you fix the wrong thing. Skip step 5 and the ticket reopens.

1. Identify the problem. Talk to the user, gather symptoms, check what changed.
2. Establish a theory of probable cause. Question the obvious. Consider the simple before the exotic.
3. Test the theory to determine the cause. Confirm the theory. If wrong, form a new one or escalate.
4. Establish a plan of action. Decide what to do and implement the solution.
5. Verify full system functionality. Make sure the fix did not break something else. Apply preventive measures.
6. Document findings, actions, and outcomes. Write it down for the next tech and for the user.

If you have seen a seven-step version of this list, you were probably looking at Network+. N10-009 objective 5.1 splits the same flow into seven numbered steps and scores it. Study guides and course notes mix the two lists up constantly. For A+, six is what CompTIA publishes.

Step 1 and 2: how do you identify the real problem

A dental office calls. "The check-in laptop is slow." That is a symptom, not a problem. Identify means asking what slow looks like. When did it start. What did you change recently. Did anything else change at the same time. Cheap questions, expensive answers.

Once you have symptoms, theory of probable cause is where most newer techs get burned. They jump to the exciting answer, the rare driver bug or the obscure registry key, and miss the boring answer right in front of them. The boring answer is usually correct. A laptop that got slow last Tuesday probably picked up a Windows update last Tuesday. Start there.

Step 3 and 4: test before you fix

Testing the theory means you confirm the cause before you commit to the fix. On the dental office laptop, you check Update history, you see KB-something rolled out Tuesday afternoon, you compare to the timeline the user gave you, and now you know. The test confirmed it.

If the test fails, do not double down. Form a new theory or escalate. Stubbornly defending a wrong theory is the most expensive habit a new tech can build. The plan of action follows from the confirmed cause. For the bad update, the plan is roll back the update, hold it from reinstalling, document the workaround, and watch for the patched version.

Step 5: how do you actually verify the fix

Verify full system functionality is the step new techs skip and seasoned techs swear by. The dental office laptop boots faster now, sure, but does the check-in app still talk to the practice management server. Does the receipt printer still work. Did the rollback flip the network adapter into a weird state. You confirm the whole workflow, not just the symptom.

Preventive measures sit inside this step. If the bad update will keep trying to install, you hold it. If the user keeps clicking the same broken shortcut, you fix the shortcut. The point is the same problem should not visit twice for the same root cause.

Step 6: why documentation is the step that gets you promoted

Document findings, actions, and outcomes is the step nobody thanks you for and everyone reads later. A logistics firm with one IT manager and rotating help desk staff lives or dies on documentation. The next person who sees that printer offline ticket needs to find your note that says "bad switch port 14, moved to port 17, port 14 flagged for replacement, do not put printer back on 14."

Documentation is also the easiest step to talk yourself out of when the fix took two minutes. Write it anyway. Thirty seconds of notes is what turns a one-off save into something the next person can repeat.

Why interviewers and help desks care

Hiring managers ask about the methodology because they want to know whether you will close tickets or solve problems. Anyone can close a ticket. Solving the problem means the ticket does not come back. The methodology is shorthand for "I will not waste your senior tech's time fixing the same thing twice."

On the job, ticketing systems quietly mirror this flow. The fields you fill in on a ticket are usually identify, action taken, resolution, and notes. The hidden steps, theory and test and verify, are the ones that separate the techs who get promoted from the techs who plateau.

What this looks like in our platform

Our Study Mode decks for the Core 1 troubleshooting domain use this order as the frame around each scored topic, since the methodology itself is not a scored topic. The Help Desk Simulator grades you on whether you ran the steps in order, not just whether you got to the right fix. Closing a ticket with the right answer but no documentation costs you points, the same way it costs you a reopened ticket at a real shop.

If you are tracking toward the A+, the A+ track page has the full objective map and the troubleshooting domain is one of the heaviest weighted on Core 1.

What does the methodology look like on a hardware ticket

Run the same six steps on a hardware ticket and the order is even more obvious. A user at the dental office reports a monitor that flickers every few minutes. Identify the problem: when did it start, has the cable been moved, are other monitors on the same desk affected. Form a theory: cable, port, GPU output, monitor itself, in roughly that order of likelihood. Test the theory: swap the cable from the spare drawer. If the flicker stops, the cable was the cause.

Plan the action: order a replacement cable, hand the user the spare in the meantime. Implement: do it. Verify the whole workflow: does the monitor stay solid across a full shift, does the user see the same issue on the second monitor. Document: cable replaced, model and length noted, root cause confirmed. Now the next time this user opens a flicker ticket, the next tech knows the cable history.

Where to go next

The methodology has no objective number. The scored troubleshooting work on Core 1 is domain 5, and it runs 5.1 through 5.6: motherboards, RAM, CPUs and power (5.1), drives and RAID (5.2), video, projector and display issues (5.3), mobile devices (5.4), networks (5.5), and printers (5.6). There is no 5.7. The same six steps carry you through all six objectives, which is the point. CompTIA does not score the order. Help desks and hiring managers do.

About the authors

Nick Miller

Founder and Lead Author

IT Service Center Manager and former CTE / IT teacher. Owner of Revtek IT Solutions. Writes everything that ships under his name and reviews every line of Revy-assisted drafting before publish.

LinkedIn ↗

R

Revy

Study buddy · AI co-author

Revy helps draft and structure these posts. Every piece is reviewed, edited, and fact-checked by Nick before publish. We disclose this here because it is the right thing to do. See the AI Policy for the full stance.