The 7-step CompTIA A+ troubleshooting methodology, in plain English
The CompTIA A+ troubleshooting methodology is seven steps that every help desk and interviewer expects you to know cold. It is the spine of objective 5.1, the question shape that shows up in nearly every entry-level IT interview, and the structure most real ticketing systems quietly mirror. Memorize the order. Then learn what each step actually looks like on a live ticket.
What are the seven steps
CompTIA lists them in objective 5.1 of the Core 1 exam (220-1201). The order 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 6 and the ticket reopens.
- Identify the problem. Talk to the user, gather symptoms, check what changed.
- Establish a theory of probable cause. Question the obvious. Consider the simple before the exotic.
- Test the theory to determine the cause. Confirm the theory. If wrong, form a new one or escalate.
- Establish a plan of action. Decide what to do and implement the solution.
- Verify full system functionality. Make sure the fix did not break something else. Apply preventive measures.
- Document findings, actions, and outcomes. Write it down for the next tech and for the user.
CompTIA labels it as seven steps because verification and preventive measures are bundled into the same numbered slot in the current blueprint. Some study guides split that into two. The exam still treats the order as one continuous flow.
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."
On the exam, the documentation question often shows up as "what should the technician do after resolving the issue." The answer is document. Always document. Even when the fix was small.
Why interviewers and help desks care
Hiring managers ask about the seven steps 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
The Study Mode deck for objective 5.1 walks the seven steps with example tickets for each one. 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 seven 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
Objective 5.1 is the general methodology. Objectives 5.2 through 5.7 apply the same seven steps to specific domains, hardware, displays, mobile, printers, networking, storage. Once the methodology is automatic, every domain question becomes easier. The exam rewards the order. So does the job.
Sources
- CompTIA. CompTIA A+ certification overview. Exam codes 220-1201 (Core 1) and 220-1202 (Core 2). Objective 5.1 covers the troubleshooting methodology.
- AXELOS / ITIL 4. ITIL 4 service management framework. The incident-management process most enterprise help desks model their ticket flow on.
About the authors
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 ↗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.