You are staring at a computer that will not turn on, or a network connection that keeps dropping, and you have no idea where to start. How do you fix something when you cannot even see the problem? The troubleshooting methodology gives you a proven, step-by-step process to diagnose and resolve any hardware or network issue. For the 220-1201 exam, you must memorise this process inside out because every scenario question tests your ability to apply it, not just remember what it is called.
Jump to a section
A simple way to picture Troubleshooting Methodology and Tools
You pop two slices of bread into the toaster and crank the dial to 'max'. Five minutes later, your kitchen fills with grey smoke and you are staring at two blackened bricks. Why did this happen? You have a problem: burnt toast. Your goal? Edible toast.
You start troubleshooting. First, you identify the symptoms. Black smoke. Charred smell. Toast that crumbles like charcoal. Second, you establish a theory of probable cause. You think: 'I turned the dial too high.' That is your best guess. Third, you test that theory. You take a new slice of bread, set the dial to 'low', and wait. If it comes out pale and doughy, your theory was wrong. If it comes out perfect, you found the cause. Fourth, you implement a solution. You now know the correct dial setting for your preferred doneness. Fifth, you verify full system functionality. You make a third piece of toast at that setting and eat it. Sixth, you document your findings. You tell your flatmate, 'Do not use max — it burns everything.'
This is exactly how an IT pro tackles a broken computer. The burnt toast scenario maps to every phase of the CompTIA troubleshooting methodology. You do not panic. You do not guess blindly. You follow a repeatable process to isolate the variable that caused the failure. That process is the difference between a chaotic random fix and a reliable repair.
The CompTIA A+ troubleshooting methodology is a structured, repeatable process used by IT professionals to diagnose and fix problems. It ensures you do not waste time on random guesses. Think of it as a recipe for problem-solving. Every step builds on the last, so skipping a step or jumping to conclusions leads to mistakes.
The official steps are:
Step 1: Identify the problem. This means gathering information from the user, asking questions, and classifying the symptoms. For example, a user says 'my email is slow'. You ask: 'When did it start? Does it happen with all emails or just ones with attachments?' You also check the system yourself. Is the CPU utilisation high? Is the network cable unplugged? This step establishes the 'what' of the problem.
Step 2: Establish a theory of probable cause. Based on the symptoms, you form a hypothesis about what is wrong. A theory is not a fact — it is your educated guess. Commonly, this involves the phrase 'question the obvious'. Did you check the power cable? Did you check if the monitor is on? For a network issue, possible theories might be a bad cable, a faulty router, or a misconfigured IP address.
Step 3: Test the theory to determine the cause. You now perform a specific test to confirm or disprove your theory. If you think the cable is bad, swap it with a known good cable. If the problem goes away, the cable was the cause. If the problem persists, your theory was wrong, so you go back and establish a new theory. This step separates guessing from real diagnosis.
Step 4: Establish a plan of action to resolve the problem and implement the solution. Once you know the cause, you decide what fix to apply. For a bad cable, you replace it. For a software conflict, you might uninstall an update or reinstall a driver. You plan the fix carefully — sometimes the simplest fix is the best, but sometimes you need a more complex solution like restoring from a backup.
Step 5: Verify full system functionality and implement preventive measures. After you apply the fix, you must confirm that the entire system works normally, not just the part you fixed. For example, you replace a network cable, then check that the user can access the internet, their email, and their shared folder. You also look for residual issues. Then you add preventive measures, like labelling cables or setting up automatic driver updates, to stop the same problem happening again.
Step 6: Document findings, actions, and outcomes. This is often the step beginners forget. You write down what was wrong, what you did, and the result. In a corporate environment, this creates a knowledge base for future technicians. It also helps you spot patterns — if you keep seeing the same problem on the same model of computer, you might report it to the vendor.
The troubleshooting methodology replaces ad-hoc, uncontrolled problem solving. Without it, a novice might replace a motherboard when a simple cable reseat would have fixed the issue. The methodology forces you to think before you act. It exists because IT systems are complex — a single symptom can have dozens of possible causes. The process narrows the field efficiently.
For the 220-1201 exam, the scenario questions will describe a problem and ask you what the technician should do NEXT. The answer is always aligned to the correct step of the methodology. If the problem has just been identified, the next step is to establish a theory. If the theory has been tested and confirmed, the next step is to implement a solution. Traps include 'skip straight to replacing hardware' or 'ask the user irrelevant questions'. The exam loves to test that you know the order and that you never jump steps.
Identify the problem
You gather information from the user and from the system itself. Ask open-ended questions like 'What were you doing when it stopped working?' and 'Has anything changed recently?' You also examine the system logs, error messages, and physical connections. This step defines the scope of the problem so you do not chase the wrong issue.
Establish a theory of probable cause
You form an educated hypothesis about what is causing the symptoms. Begin by questioning the obvious — check the simplest explanations first, like loose cables, power issues, or user errors. Write down your top theory and any alternative theories. This gives you a starting point for testing.
Test the theory to determine the cause
You perform a specific test to confirm or disprove your theory. For example, if you think a network cable is bad, swap it with a known-good cable. If the problem goes away, the theory is confirmed. If it does not, the theory is wrong and you return to step 2. This step prevents you from implementing the wrong fix.
Establish a plan of action to resolve the problem and implement the solution
Once the cause is confirmed, you decide what to do. The plan might be a simple hardware replacement, a software reconfiguration, or a more complex procedure like restoring from backup. Then you carry out the plan carefully. If the fix is complicated, you may need to schedule downtime or back up data first.
Verify full system functionality and implement preventive measures
After the fix, you test that the entire system works normally. For instance, after replacing a failed power supply, boot the computer, check the operating system loads, open applications, and confirm network access. Then add preventive measures, such as installing a surge protector or updating drivers, to reduce the chance of recurrence.
Document findings, actions, and outcomes
You write a clear record of the problem, the cause, the steps taken, and the result. This documentation goes into a ticket or knowledge base. It helps other technicians in the future and provides data for trend analysis. Never skip this step — even for simple fixes.
Sarah is a junior IT support technician at a medium-sized accounting firm. At 9:15 am, a frantic call comes in from a partner, Mark. Mark says: 'My desktop PC just went black and now it won't boot. I have a deadline in two hours.' Sarah follows the CompTIA methodology from her training.
First, she identifies the problem. She asks Mark three things: 'Did you hear any strange noises before it shut down?', 'Was the computer plugged into a surge protector?', and 'Has anyone changed anything on the PC recently?' Mark says no to all, but he mentions the office lights flickered earlier. Sarah notes that symptom. She then goes to Mark's desk, checks the PC, and sees the power LED on the monitor is green but the PC case has no lights at all.
Second, she establishes a theory of probable cause. Given the lights flickered and the power LED on the monitor is on, she suspects the PC's power supply unit (PSU) may have failed, or the power cable to the PC is loose or dead. She decides to question the obvious first: she checks the power cable connection to the PC and the wall outlet. It is secure, but she does not have a multimeter to test the outlet.
Third, she tests her theory. She swaps the known-good power cable from her own laptop charger with Mark's PC cable. The PC still does not turn on. Now she suspects the PSU itself. She has a spare known-good power supply in the IT closet. She swaps the PSU inside Mark's PC. This is not a quick job — it takes 15 minutes. She powers on the PC, and it boots successfully.
Fourth, she implements a solution. The old PSU is dead, so she replaces it permanently with the spare. She orders a new replacement PSU for the spare inventory.
Fifth, she verifies full system functionality. She boots into Windows, logs into Mark's account, opens his spreadsheet application, accesses the network drive, and prints a test page. Everything works. She also checks that the PC's time and date are correct because a PSU replacement can sometimes affect BIOS settings.
Sixth, she documents everything. She enters a ticket in the helpdesk system: 'PC not booting — PSU failure confirmed by swap test. Replaced PSU with spare (Part #XYZ). Verified system fully functional. Ordered replacement PSU for spare inventory. Recommend surge protectors for all partner offices.' This documentation means if another partner's PC fails the same way next week, the team already knows the likely cause.
Sarah's methodical approach saved time. She did not replace the motherboard, CPU, or RAM. She did not reinstall Windows. She followed the steps, isolated the fault to the PSU in under 20 minutes, and had Mark back to work before his deadline. That is the real value of the troubleshooting methodology — it turns a chaotic emergency into a controlled procedure.
The 220-1201 exam will hammer you with scenario-based questions about the troubleshooting methodology. You will see a paragraph describing a technician facing a hardware or network issue, and then a question like 'What should the technician do NEXT?' or 'Which step is the technician performing?'.
The specific exam objectives for this topic (5.1) state you must be able to 'apply the troubleshooting methodology to resolve hardware and network issues'. That means you need to:
Memorise the six steps in order and what each step means.
Understand that you never skip steps. The exam loves to present an answer choice that jumps straight to replacing a component without testing a theory first. That is always wrong.
Recognise the difference between 'establish a theory' (step 2) and 'test the theory' (step 3). Many students blur these two.
Know the phrase 'question the obvious'. This is a core concept within step 2. The exam may ask: 'A technician cannot determine why the monitor is blank. Which action is most appropriate next?' The correct answer is 'Check that the monitor is plugged in and turned on' — not 'Replace the video card' or 'Reinstall the operating system'.
Understand that documentation (step 6) is not optional. Traps will suggest that the technician can skip documentation if they are busy. The correct answer always includes documentation.
Common question types:
'A user reports that their computer is slow. Which of the following should the technician do FIRST?' The answer is always 'Identify the problem' (step 1). Not 'Run a diagnostic' (which is step 3) or 'Reinstall the OS' (which is step 4).
'A technician has identified that a faulty hard drive is causing errors. What is the NEXT step?' The answer is 'Establish a plan of action to resolve the problem' (step 4).
'After replacing a failed network card, the technician verifies internet access. What is the LAST step?' The answer is 'Document findings, actions, and outcomes' (step 6).
Key definitions to memorise for the exam:
Symptoms: what the user reports or what the technician observes (e.g. no power, error messages, strange noises).
Theory of probable cause: your educated hypothesis based on symptoms.
Questioning the obvious: starting with the simplest, most likely causes.
Verification of full system functionality: making sure the entire system, not just the repaired component, works correctly.
Preventive measures: actions taken to avoid the same problem in the future (e.g. installing a surge protector, updating drivers).
The most common trap in exam questions is the 'reset everything' answer. A question will present a network connectivity issue and an answer choice that says 'Reset the router and the modem'. Sometimes that is correct, but only after you have identified the problem and formed a theory. If the question says 'what should the technician do first?' and 'reset everything' is an option, that is almost always the wrong answer because you have not gathered enough information yet.
Another classic trap: 'Ask the user what they were doing before the problem occurred.' That is actually a valid part of step 1 (identify the problem), so if the question is about step 1, that is correct. But if the question has already moved past step 1, then asking the user again is wasting time. Pay attention to where in the process the question places you.
Finally, the exam will sometimes give you a scenario where the technician has already tested a theory and it failed. The correct response is to go back to step 2 and establish a new theory of probable cause. Never choose an answer that says 'implement the original plan anyway' or 'give up and escalate without a documented theory'.
The six-step CompTIA troubleshooting methodology must be applied in order: identify problem, establish theory, test theory, plan and implement solution, verify functionality, document everything.
Step 2 includes the crucial instruction to 'question the obvious' — always check the simplest, most likely causes first, like unplugged cables or disabled settings.
Testing a theory (step 3) is a diagnostic action to confirm the cause, not a permanent fix — swapping a known-good component is testing, not implementing.
Verification of full system functionality (step 5) means checking that the entire system and all related services work correctly after the repair, not just the single component you fixed.
Documentation (step 6) is mandatory and includes findings, actions taken, and outcomes — skipping documentation is never the correct answer on the exam.
If a theory is tested and fails, you must return to step 2 to establish a new theory — you never implement a solution based on an unconfirmed or disproven theory.
Scenario questions on the 220-1201 exam will test your ability to identify the next correct step in the process, so memorise the exact phrasing and order of each step.
These come up on the exam all the time. Here's how to tell them apart.
Identify the problem (Step 1)
Gathering information from the user and system.
Determining symptoms and scope of the issue.
Asking open-ended questions about recent changes.
Establish a theory (Step 2)
Forming a hypothesis about the root cause.
Starting with the most obvious possible causes.
Listing one or more theories to be tested.
Test the theory (Step 3)
A diagnostic action to confirm or disprove the theory.
Often involves swapping a component or running a tool.
Does NOT permanently fix the problem.
Implement a solution (Step 4)
The actual repair or fix based on a confirmed cause.
May involve replacing hardware or changing software settings.
Permanently resolves the root issue.
Trial and error (not recommended)
Randomly trying fixes without a plan.
Often wastes time and can cause additional problems.
No documentation of what was tried or what worked.
CompTIA troubleshooting methodology
Structured, logical, repeatable process.
Efficiently isolates the cause through hypothesis testing.
Includes final documentation for future reference.
Verification of functionality (Step 5)
Testing that the entire system works after the fix.
Checking related services and applications.
Performed immediately after implementing the solution.
Documentation (Step 6)
Recording the problem, cause, and actions taken.
Creating a record for the knowledge base.
Performed after verification is complete.
Mistake
Troubleshooting means trying random fixes until something works.
Correct
Troubleshooting is a structured, step-by-step process. You identify the problem, form a theory, test it, then act. Random guessing wastes time and can cause more damage.
Beginners often panic under pressure and resort to trial-and-error because they do not trust the process. The exam tests your discipline to follow the steps in order.
Mistake
Step 3 (test the theory) and Step 4 (implement a solution) are the same thing.
Correct
Testing a theory is a diagnostic check to confirm the cause. Implementing a solution is the permanent fix. For example, swapping a cable to see if connectivity returns is testing. Replacing the cable with a new one is implementing.
The wording in some study guides blur the two. Students memorise the steps but cannot distinguish between a diagnostic test and a fix. Exam questions specifically test this difference.
Mistake
If you know the cause immediately, you can skip to implementing the solution.
Correct
You must still test your theory to confirm it. Even if you are 99% sure, a simple test can save you from replacing the wrong part. The process requires verification.
In real life, experienced techs sometimes skip the test because they are confident. The exam tests the ideal process, not shortcuts. Always choose the answer that includes testing.
Mistake
Documentation is only for big companies with formal IT departments.
Correct
Documentation is a required final step for every fix, regardless of company size. It helps you remember what you did, helps other techs, and provides evidence if the problem recurs.
Beginners see documentation as optional paperwork. The exam treats it as a mandatory step — questions will have 'document the solution' as the correct answer when the scenario reaches the final step.
Mistake
'Full system functionality' means the computer turns on.
Correct
Full system functionality means all relevant services and applications work as expected. If you fix a hard drive, you must also verify that the user can access files, run programs, and connect to the network.
Beginners think 'it boots' equals 'it is fixed'. The exam often presents a scenario where a fix was applied but the user still cannot log in or access email — the answer is to verify full system functionality.
Mistake
The methodology is a linear process that never loops back.
Correct
The methodology is iterative. If you test a theory and it fails, you return to step 2 and form a new theory. You may cycle through steps 2 and 3 multiple times before you find the cause.
Beginners memorise the steps as a one-way checklist. The exam tests your understanding that troubleshooting is a loop, not a straight line.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Establishing a theory is forming a hypothesis about the cause. Testing the theory is actively checking that hypothesis with a diagnostic action, like swapping a component or running a software diagnostic. They are separate steps — you cannot test without a theory, and you should not implement a fix without testing.
No. The CompTIA methodology requires documentation as a final step for every incident, no matter how simple. Skipping documentation is a common trap answer on the exam. Always document findings, actions, and outcomes.
It means before you assume a complex hardware failure, check the simple, likely causes. For example, if a monitor is blank, check that it is plugged in and turned on before replacing the video card. The exam loves to test that you start with the obvious.
You go back to step 2 and establish a new theory of probable cause. You do not implement a solution based on an incorrect theory. The troubleshooting process is a loop — you keep forming and testing theories until you find the real cause.
It means checking that the entire system works correctly, not just the component you repaired. For example, after fixing a network card, you should confirm internet access, email, file sharing, and any other applications the user relies on. The exam sees this step as critical.
No. The same six-step process applies to hardware issues (like a failed power supply) and network issues (like a broken cable). The tools and specific tests may differ, but the logical flow of steps is identical.
You've just covered Troubleshooting Methodology and Tools — now see how well it sticks with free 220-1201 practice questions. Full explanations included, no account needed.
Done with this chapter?