CompTIA A+ Training Course

More questions on A+ turn on this methodology than on any single piece of hardware. It is tested directly — name the step, put the steps in order, identify which step an action belongs to — and indirectly, because scenario questions ask what you would do next, and the correct next action is usually the next step in this process rather than the fix you already suspect.

The six steps

• Identify the problem.
• Establish a theory of probable cause, questioning the obvious.
• Test the theory to determine the cause.
• Establish a plan of action to resolve the problem and implement the solution.
• Verify full system functionality and, if applicable, implement preventive measures.
• Document the findings, actions, and outcomes.

Learn them in order and learn the qualifying clauses, because the clauses are what the exam tests.

Step 1 — Identify the problem

This is not the same as observing a symptom. Identifying the problem means gathering information until you know what is actually wrong and what changed.

• Gather information from the user and identify user changes. Ask what the machine was doing, what they were doing, and when it started. Users omit the relevant detail not out of dishonesty but because they do not know it is relevant.
• Inquire regarding environmental or infrastructure changes. A problem that started for six people on Monday morning is not six independent hardware faults. Weekend maintenance, a firmware update, a new firewall rule, or a power event explains it more economically.
• Review system and application logs, which contain the timeline you are trying to reconstruct.
• Back up before making changes. This belongs here, before anything is modified. The exam places it in step 1 deliberately, and a question that offers backing up as an option in a scenario with irreplaceable data is usually testing exactly this.

Step 2 — Establish a theory of probable cause

Form a hypothesis that explains all the symptoms, and start with the simplest explanation. The objectives say question the obvious, which cuts two ways: check the cable and the power switch first, and do not assume the exotic cause when a mundane one fits.

Two disciplines matter here. Consider multiple approaches — divide and conquer, which halves the problem space with each test, and top-to-bottom or bottom-to-top through the layers of a system. And conduct external or internal research based on symptoms: vendor knowledge bases, error code references, and your own organization's ticket history frequently identify a known issue in less time than the first test would take.

Step 3 — Test the theory to determine the cause

Test it before you act on it. A theory that survives a test is a cause; a theory that has not been tested is a guess, and acting on guesses is how a support call turns into three unrelated changes and a machine nobody can restore.

The objectives add the crucial branch: if the theory is confirmed, determine the next steps to resolve the problem; if it is not confirmed, establish a new theory or escalate. Escalation is a legitimate outcome, not a failure. Knowing when to escalate — time limits, scope beyond your authority, risk to data, or a problem outside your competence — is a professional skill the exam rewards.

Step 4 — Establish a plan of action and implement the solution

Plan before you touch. The plan accounts for what the fix will affect, when it can be applied, how long it will take, and how to reverse it if it fails. Where a change touches shared systems, it goes through the organization's change management process before it happens, not after — a link this module shares with Core 2's operational procedures domain.

Change one thing at a time. Making three changes at once and finding the problem resolved teaches you nothing and leaves two unnecessary modifications in place.

Step 5 — Verify full system functionality

Verify the whole system, not the symptom. A replaced network cable that restores connectivity but leaves the printer mapping broken is not a completed repair. Where possible, have the user confirm the original task now works, since they know what normal looks like on their machine and you do not.

Then implement preventive measures where they apply: replacing a failing part rather than reseating it again, adding a surge protector after a power event, scheduling the cleaning that would have prevented the overheating, or correcting the process that produced the fault.

Step 6 — Document findings, actions, and outcomes

Write down what the symptom was, what you found, what you did, and what happened. This step is skipped more than any other and is the one that compounds: it turns your ticket into the answer for the next person who sees the symptom, supports warranty and asset records, reveals patterns across many incidents, and protects you when someone asks what changed.

How the methodology shows up in questions

Consider a scenario: a user reports their computer is slow, and you have restarted it and confirmed it is still slow. What do you do next? The tempting answers are actions — run antimalware, add memory, replace the drive. The correct answer is usually the next methodological step: gather more information about when it started and what changed, or form and test a theory. When several answers all look technically reasonable, ask which step of the process you are actually on. That single habit converts a substantial number of questions on both Core exams.

What you should be able to do

• State the six steps in order, with their qualifying clauses.
• Place backing up data in step 1, before any change is made.
• Recognize escalation as a valid outcome of a disconfirmed theory.
• Choose the next methodological step over a plausible-sounding fix when a question asks what to do next.