CompTIA Troubleshooting Methodology

CompTIA A+ 220-1201 & 220-1202

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

About the CompTIA A+ Certification Exam Domains & Study Strategy

2 Core 1 Domain 1: Mobile Devices (13%)

Laptop Hardware & Components Laptop Features & Display Types Mobile Device Connectivity & Accessories Mobile Operating System Features Mobile Device Synchronization & Data Transfer

3 Core 1 Domain 2: Networking (23%)

TCP/IP Fundamentals & the OSI Model Common Ports & Protocols Wireless Networking Standards Network Hardware & Devices Network Configuration & Internet Connections Network Types & Topologies

4 Core 1 Domain 3: Hardware (25%)

Cables & Connectors RAM Types & Storage Devices Motherboards, CPUs & Power Supplies Printers & Multifunction Devices Peripheral Devices & Expansion Cards Network Cable Tools & Testing

5 Core 1 Domain 4: Virtualization & Cloud Computing (11%)

Virtualization Concepts Cloud Computing Models & Services Client-Side Virtualization in Practice

6 Core 1 Domain 5: Hardware & Network Troubleshooting (28%)

CompTIA Troubleshooting Methodology Hardware Troubleshooting Network Troubleshooting Printer Troubleshooting Display & Mobile Device Troubleshooting

7 Core 2 Domain 1: Operating Systems (28%)

Windows Editions & Features Windows Administrative Tools & Utilities Windows Command Line & PowerShell macOS & Linux Basics Windows Networking & File Sharing Windows Installation & Upgrade Methods

8 Core 2 Domain 2: Security (28%)

Physical & Logical Security Measures Malware Types & Threat Mitigation Wireless & Network Security Encryption & Data Protection

9 Core 2 Domain 3: Software Troubleshooting (23%)

Windows OS Troubleshooting Mobile OS & Application Troubleshooting Browser & Application Troubleshooting

10 Core 2 Domain 4: Operational Procedures (21%)

Documentation & Change Management Backup & Recovery Methods Safety & Environmental Procedures Scripting & Remote Access Technologies Privacy, Licensing & Organizational Policies

CompTIA Troubleshooting Methodology

Key Takeaways Explain This Topic AI

In the V15 Core 1 (220-1201) objectives, CompTIA prints the six-step troubleshooting methodology as a "competency standard" and says the methodology itself will not be tested; troubleshooting within the job role context remains a focus.

Step 1, Identify the problem, means questioning the user, gathering information, finding out what changed and reproducing the fault before you change anything.

Test the theory (Step 3) before the plan of action (Step 4); if the test proves the theory wrong, form a new theory or escalate — never skip straight to a fix.

Document findings/lessons learned, actions, and outcomes (Step 6) on every ticket, even trivial ones, because it builds the knowledge base and protects you in audits.

Use the method to reason through the scenario-based troubleshooting objectives (Core 1 domain 5, Core 2 domain 3), for example testing a theory with a known-good part before replacing anything.

Last updated: October 2026

The Six-Step Methodology (a Competency Standard)

The V15 Core 1 (220-1201) objectives describe troubleshooting as a 6-step methodology , printed as a "competency standard" rather than a formal objective. CompTIA's note says the methodology itself will not be tested, while troubleshooting within the job role context remains a focus, so treat the steps as the way to work a problem, not as a list to recite. The Core 2 (220-1202) objectives do not print the methodology; its troubleshooting sits in domain 3, Software Troubleshooting. CompTIA's own troubleshooting guidance adds two habits when you plan a fix: follow your change-management procedures and get any approval you need , and back up data that the fix could put at risk so a fix never destroys the user's work.

Step 1 — Identify the Problem

Gather information from the user: What happened? When did it start? What were you doing when it failed?

Question the user about environmental or infrastructure changes (new software, an OS update, a moved desk, a power outage).

Inquire regarding changes to the computer — recently installed drivers, hardware swaps, or pushed patches.

Reproduce the problem if possible, and review system, application, and security logs in Event Viewer.

Approach the problem with empathy — do not blame the user.

Step 2 — Establish a Theory of Probable Cause

Start with the most probable, simplest cause first (the "question the obvious" rule: is it plugged in, powered on, cable seated?).

Research the knowledge base/internet , if applicable — vendor knowledge base, manufacturer documentation, or your ticketing history.

Hold multiple candidate theories ; do not fixate on the first idea.

Step 3 — Test the Theory to Determine the Cause

Run a targeted, low-risk test that confirms or rejects the theory.

If confirmed , move to Step 4 to plan the resolution.

If not confirmed , re-establish a new theory or escalate to a higher tier — do not improvise a fix.

Step 4 — Establish a Plan of Action and Implement the Solution

Build a plan that fixes the root cause , weigh the impact on other users/systems , back up data at risk , get any approval the change needs, and refer to vendor documentation for the exact procedure.

Step 5 — Verify Full System Functionality

Confirm the original symptom is gone, test related features, and implement preventive measures (patching, driver updates, scheduled backups) where applicable.

Step 6 — Document Findings, Actions, and Outcomes

Record symptom, cause, resolution, and any preventive steps in the ticket/knowledge base — required on every ticket.

Quick-Reference Order Table

# Step What you do
1 Identify the problem Gather, question, ask what changed, reproduce
2 Establish a theory Question the obvious; research
3 Test the theory Confirm OR re-theorize/escalate
4 Plan of action & implement Consider impact; back up ; get approval; follow docs
5 Verify full functionality Test related systems; prevent
6 Document Symptom, cause, resolution
Worked Scenario

A user says Outlook "stopped working this morning." A weak technician reinstalls Office immediately. The correct play: Step 1 — ask what changed (the user mentions a Windows update overnight). Step 2 — theory: the update broke the mail profile. Step 3 — test by launching Outlook in safe mode ( outlook /safe ); it opens, confirming a profile/add-in fault. Step 4 — back up the PST/profile, then disable the offending add-in. Step 5 — verify send/receive and calendar. Step 6 — log it. Reinstalling first would have been a Step-4 action taken before any theory was tested.

Why Each Step Matters

Identifying the problem is the step technicians most often shortcut. A reported symptom ("the Internet is down") is rarely the real fault ("the Wi-Fi adapter is disabled"). Gathering precise information, learning what changed, and reproducing the failure converts a vague complaint into a testable hypothesis. This is also where you decide whether the issue is even in your scope or must be escalated under company policy.

Establishing a theory is governed by Occam's razor: the simplest explanation that fits the symptoms is the most probable. A printer that "won't print" is far more likely out of paper or offline than suffering a fried formatter board. CompTIA's phrase "question the obvious" is a direct hint that the simplest causes — power, cables, switches, settings — come first.

Testing the theory must be a discrete, reversible action that yields a clear yes/no. Booting into Safe Mode, swapping a cable for a known-good one, or pinging a gateway are good tests because each one isolates a single variable. A test that changes three things at once tells you nothing about which one mattered.

Planning and implementing is where impact analysis lives: a fix that requires a reboot in the middle of the workday, or one that touches a shared server, must be scheduled and communicated. Verifying full functionality prevents the classic callback where the original issue is fixed but a side effect (no audio, no printer mapping) was introduced. Documentation turns one technician's work into institutional knowledge and is the evidence trail an audit relies on.

A Second Scenario

Three users on one floor lose network access. A novice resets each PC. The methodology says otherwise: identify — all three sit on the same switch, so the common factor is infrastructure, not the PCs. Theory — the access switch or its uplink failed. Test — check the switch's link lights and ping it; the uplink port is dark. Plan — replace the patch cable to the distribution switch, considering that the swap briefly drops the segment. Verify — all three regain access and can reach shared drives. Document — note the bad cable and the port.

Recognizing the common element among affected users is a recurring Domain-5 reasoning pattern.

Common Troubleshooting Traps

In a troubleshooting scenario, start by identifying the problem / gathering information , not with a hardware swap or reboot.

Backing up data that a fix could put at risk belongs to the plan step, before you implement — losing data because you skipped it is a policy failure.

After a failed test of theory , the next step is a new theory or escalation , never "document and close."

When multiple users share one symptom, look for the common element (switch, server, DHCP scope, recent patch) before touching individual devices.

Do not skip Steps 5 and 6: verify and document even after a trivial fix.