Is the CompTIA Troubleshooting Methodology on the A+ Exam?

What CompTIA actually says about the methodology

The 220-1201 objectives, document version 3.0, include a short section on troubleshooting methodology on the test-details page. It says the subject matter experts in the job task analysis for the 220-1200 series saw the methodology as a useful best practice for new technicians. Then it says "the decision was made to not include it in the exam." The section stays in the document as part of CompTIA's competency standard. CompTIA states that it is not a formal objective, and it encourages training programs for beginners to keep teaching it.

The 220-1202 objectives have no methodology section at all.

Some prep sites and older books still present the six steps as a tested A+ objective. For V15, CompTIA's own document says otherwise. If a study source tells you to expect a question that asks for "step 4 of the methodology," check which exam version it was written for. The V15 vs V14 guide covers how to audit older material.

Do not overcorrect: troubleshooting is still a large share

"The methodology is not an objective" does not mean "troubleshooting is not tested." The V15 weights say the opposite:

Those domains are written as "given a scenario" objectives. The objectives document also says that troubleshooting in the context of the job role is still emphasized. So you will not be asked to recite the steps, but you will be asked what a technician should do about a symptom. That is where the steps earn their keep.

The six steps, in plain words

CompTIA's V15 list has six steps. Planning and implementing the fix are combined into one.

1. Identify the problem. What does the user see, since when, and what changed?
2. Establish a theory of probable cause. Start with the obvious. Research a knowledge base or vendor documentation if you need to.
3. Test the theory. If the test rules it out, go back to step 2 with a new theory.
4. Plan the fix and carry it out.
5. Verify full system functionality. Where it makes sense, add something that prevents a repeat.
6. Document what you found, what you did, and the outcome.

One practical habit is not in CompTIA's V15 wording: before you change anything that could touch the user's data, make sure that data is safe.

How the steps help on "what should the technician do next?" questions

Many scenario items give you a partial story and ask for the next or first action. The steps give you an order to check the answer choices against:

• Information before change. If the stem has not established what changed, an answer that replaces hardware is usually early.
• Test before you replace. "Swap in a known-good part" tests a theory. "Order a new motherboard" assumes one.
• Verify before you close. A fix is not finished until the original symptom is gone and nothing else broke.
• Document last, but always. Documentation is rarely the right "next" step in the middle of a story, and it is almost never skipped at the end.

These are habits, not answer keys. Each item still depends on its own facts. The three examples below are original and simplified.

Worked example 1: a desktop with no power

A user says her desktop "is dead" on Monday morning. The desk was moved over the weekend.

Notice what a scenario question would punish: replacing the motherboard first, or closing the ticket as soon as the fans spin. The hardware and network troubleshooting guide has more symptom-to-first-check tables like this one.

Worked example 2: Wi-Fi that drops at one desk

A laptop at one desk loses Wi-Fi several times each afternoon. Other laptops in the room are fine.

• Identify. Only this desk. The laptop is joined to the office's 2.4 GHz network. Nothing changed on the laptop. A new tenant moved in next door last month.
• Theory. Congestion or interference on the 2.4 GHz channel at that spot. Microsoft's support guidance notes that 2.4 GHz is more congested than 5 GHz, partly because household and Bluetooth devices share the band.
• Test. A Wi-Fi analyzer at the desk shows several strong networks on the same 2.4 GHz channel. Moving the laptop to the office's 5 GHz network stops the drops for a full afternoon.
• Plan and implement. Keep that desk on 5 GHz. Move the access point's 2.4 GHz radio to channel 1, 6, or 11, whichever the survey shows is clearest. Microsoft's guidance names those three channels because they do not overlap.
• Verify. No drops for a week, and the other users are still fine.
• Document. Record the channel change and the analyzer reading.

A distractor here would be "replace the laptop's wireless card." That would be worth testing if the drops followed this laptop to other desks. Here, the 5 GHz test already points to the band, not the card.

Worked example 3: a slow profile load

A user on a Windows 11 PC says sign-in now takes minutes. Slow profile load appears in the Core 2 Windows troubleshooting objective.

• Identify. Only her account is slow. Ask what changed. The department's old file server was retired last month.
• Theory 1. The problem is in her profile or her user-specific settings, not the PC. Test: a different account signs in quickly on the same PC. This narrows the problem to her account.
• Theory 2. Something tied to her account is waiting on a server that no longer exists. Test: net use lists her network connections and shows a persistent mapped drive to the retired server. A ping to that server name fails.
• Plan and implement. Confirm with her that she no longer needs that drive. Remove it with net use M: /delete, then map the new share if she needs one.
• Verify. Sign-in time is back to normal, and her files open from the new location.
• Prevent and document. Ask whoever maintains the sign-in scripts or policies to remove mappings to the old server for everyone. Then write up the fix.

A stale mapping is one plausible cause in this story, not the only cause of slow profile loads. The point is the order: narrow the problem to one account before you rebuild the profile. The Windows command-line guide explains net use, ping, and the other 220-1202 commands.

A three-question self-check

Cover the answers and decide the next step.

1. A printer shows "offline" on one user's PC. You have not yet asked what changed or checked whether anyone else can print. Next: ask the user what changed and check another user's PC. You are still identifying the problem.
2. You suspect a failing RAM module and have a known-good module on the shelf. Next: test the theory by swapping it in. Do not replace the motherboard.
3. You replaced the failed part, and the user says the PC "seems fine." Next: verify full functionality yourself, then document. Do not close the ticket first.

If you can explain each answer through the order of the steps, the method is working for you. Apply the same next-step reasoning to explained A+ scenario questions in Passy →, or start with the free A+ practice set. When a scenario type keeps tripping you up, rework that step in the examples above before you try another set.