Objective 5.1: Given a scenario, apply the best practice methodology to resolve problems

Cert: CompTIA A+ Core 1 (220-1201) V15 Domain: 5.0 Hardware and Network Troubleshooting Weight: ~28% of Core 1 (largest domain) Depth: Given a scenario, apply. The candidate must walk a problem through the documented six-step methodology in the correct order and recognize when to escalate.

What this objective tests

You should be able to walk any hardware or network problem through CompTIA's six-step troubleshooting methodology in the correct order. The objective tests whether you know which step comes next, what each step requires, and why skipping a step (especially the early ones) leads to wasted effort or new problems.

This is the foundation objective for the entire 5.x troubleshooting domain. Every other 5.x objective (motherboards, drives, video, mobile, printers, network) assumes you apply this methodology to whatever symptom is in front of you.

The six steps in order

CompTIA's troubleshooting methodology is six steps. Memorize the order. The exam will ask you to identify which step you are on, which step comes next, or which step a technician skipped.

1. Identify the problem.

• Gather information from the user. What were they doing when it broke? What changed recently?
• Ask open-ended questions first ("walk me through what happened") then narrow ("did the screen go dark before or after the click").
• Identify symptoms specifically (not "it's slow" but "Outlook takes 30 seconds to open and other apps are responsive").
• Determine if the problem is reproducible. Reproducible problems are far easier to diagnose.
• Approach multiple problems individually. If the user reports three symptoms, treat each as its own ticket until you've proven they share a root cause.
• Document any user changes (driver they installed, setting they changed). Often the root cause.
• Back up data before making changes if data loss is possible.
• Be aware of corporate policies (you may not be allowed to image a drive, escalate certain ticket types, or touch certain user data).

1. Establish a theory of probable cause (question the obvious).

• Form one hypothesis at a time based on the symptoms. Lead with the most likely cause.
• "Question the obvious" means: if a printer is offline, check that it's powered on and connected before assuming a firmware bug.
• If the obvious cause turns out to be wrong, move to less obvious theories. Don't skip the obvious one because it feels too simple.
• Use vendor documentation, KB articles, and prior tickets to inform the theory. Don't theorize in a vacuum when documented patterns exist.

1. Test the theory to determine the cause.

• Run a specific diagnostic that would prove or disprove the hypothesis.
• If the theory is confirmed: move to step 4 (plan a fix).
• If the theory is not confirmed: form a new theory (back to step 2), or escalate if you've exhausted your scope or knowledge.
• Escalation is part of this step. A technician who escalates after two failed theories did the methodology correctly. A technician who flails through ten random changes without escalating violated this step.

1. Establish a plan of action to resolve the problem and implement the solution.

• Write down the plan before acting. The plan should reference vendor docs or internal SOPs where available.
• Communicate the plan to the user if it will cause downtime, data risk, or restart the device.
• Implement the fix following the plan. Avoid scope creep ("while I'm in here, I'll also...") that creates new variables.
• One change at a time when possible. If the fix doesn't work, you can identify which change caused or failed to cause the resolution.

1. Verify full system functionality and, if applicable, implement preventive measures.

• Test the original symptom is resolved.
• Test adjacent functionality the fix could have affected (replaced a power supply? Verify USB, video, network, and storage all come back up).
• Ask the user to test from their workflow (open the app they were using, run the report they ran). User-facing verification beats technician-only verification.
• Implement preventive measures where applicable (firmware update, monitoring alert, scheduled maintenance, documentation update).

1. Document the findings, actions, and outcomes.

• Record root cause, what you tried, what worked, and any preventive measures you took.
• Note any conditions for future tickets (firmware version, OEM bulletin number, customer-specific quirk).
• Update the relevant KB article if the resolution pattern is new, or create a new KB if no existing article covered it.
• Documentation is what turns a one-off fix into institutional knowledge. Skipping this step is the most commonly skipped step and the most costly.

Special considerations

Always consider corporate policies, procedures, and impacts before implementing changes. This appears throughout the methodology, not just in one step. Changes that violate corporate policy (touching unauthorized systems, bypassing change management, restarting servers without approval) are wrong regardless of whether they fix the symptom.

Always back up data before making changes when data loss is possible. Examples: any storage operation, BIOS/UEFI firmware update, OS reinstall, RAID rebuild, any operation that involves the boot device.

Common methodology violations the exam tests

The exam frequently tests scenarios where a technician violated the order:

• Skipping step 1: Acting on the user's first description without asking clarifying questions. Symptom: misdiagnosis because the user used imprecise language.
• Skipping step 2 / 3: Jumping straight to "establish a plan of action" without forming and testing a theory. Symptom: applying fixes that don't address root cause; the symptom recurs.
• Implementing without a plan (step 4): Making changes without writing down the plan first. Symptom: no rollback path when the fix fails.
• Skipping step 5: Calling the ticket resolved without user-facing verification. Symptom: the user reports the same problem the next day.
• Skipping step 6: Not documenting. Symptom: the next technician faces the same problem from scratch and the org loses the institutional fix.

Pairs with

This methodology applies to every other 5.x objective:

• 5.2 (motherboards, RAM, CPUs, power)
• 5.3 (drives and RAID)
• 5.4 (video, projector, display)
• 5.5 (mobile devices)
• 5.6 (printers)
• 5.7 (network)

The 5.x troubleshooting objectives test specific symptoms. 5.1 tests the workflow you use to address any symptom.