5.1.1. The Eight-Step Troubleshooting Process

💡 First Principle: CompTIA's eight-step process is a formalization of the scientific method applied to IT problems. Each step has a specific purpose and output. Skipping steps creates ambiguity—you may fix the symptom without addressing the root cause, and the problem recurs.

⚠️ Exam Trap: Server+ uses eight steps, not the six you may have memorized for A+. Server+ splits "establish a plan of action" and "implement the solution" into two separate steps, and — uniquely — makes root cause analysis its own step (7), distinct from documentation (8). A+ has no separate root-cause step. If you carry the A+ list into this exam, you will miscount and mis-order.

Step-by-Step Detail

Step 1 — Identify the Problem and Determine Scope

• Question users and stakeholders: When did it start? What changed recently? Who else is affected?
• Identify changes to the server/environment before the problem appeared (patch, config change, new hardware)
• Collect additional documentation/logs (event viewer, syslog, application logs)
• If possible, replicate the problem — you can't fix what you can't reproduce
• If possible, perform backups before making changes — this step is explicitly in the CompTIA methodology and is tested
• Escalate if the problem is outside your scope or authority

Step 2 — Establish a Theory of Probable Cause

• Question the obvious first: Is it plugged in? Is the service started? Is the account locked out?
• Determine if there's a common element causing multiple problems (one misconfiguration causing cascading failures)
• Generate hypotheses ordered by probability (most likely cause first)

Step 3 — Test the Theory

• Test your theory to determine if it's the actual cause
• If confirmed: proceed to Step 4
• If not confirmed: establish a new theory (return to Step 2) or escalate

Step 4 — Establish a Plan of Action

• Define exactly what changes you'll make and in what order
• Notify impacted users of the plan and expected resolution time
• Prepare rollback procedures — know how to undo each change

Step 5 — Implement the Solution or Escalate

• Make one change at a time — if you change multiple things simultaneously and the problem resolves (or gets worse), you don't know which change was responsible
• Test after each change
• If a change doesn't fix the problem, reverse it before trying another

Step 6 — Verify Full System Functionality

• Confirm the original problem is resolved
• Check that the fix didn't break anything else
• Implement preventive measures where appropriate (patching, configuration hardening, monitoring)

Step 7 — Perform a Root Cause Analysis

• Distinct from Step 3. Step 3 found the cause — the thing that broke. Root cause analysis asks why that thing broke, which is a different question with a different answer
• Example: the cause was a full disk that stopped the database. The root cause is that no one configured log rotation or a capacity alert — so the disk will fill again next month
• Ask "why" until you reach something you can actually change: a missing control, a gap in a process, a design assumption that no longer holds
• Output: the preventive action that stops this class of problem from recurring, not just this instance of it
• Server+ makes this its own step — do not treat it as part of documentation

Step 8 — Document Findings, Actions, and Outcomes

• Record: what the problem was, what caused it, the root cause, what fixed it, and any preventive measures taken
• Update runbooks, KB articles, and asset documentation as needed
• This documentation is the next technician's starting point when they see the same problem
• Note the objective's wording: documentation happens "throughout the process", not only at the end — Step 8 is where you consolidate and publish it

⚠️ Exam Trap: The exam frequently tests Step 5's "one change at a time" rule. A scenario where a technician makes multiple simultaneous changes and something improves is not resolved troubleshooting — the technician cannot identify what fixed the problem or what may have been broken in the process.

Reflection Question: A technician suspects a server crash is caused by either a failing RAM module or a faulty power supply. To save time, they reseat both simultaneously, and the server stabilizes. What troubleshooting principle was violated, and why does it matter even though the problem appears resolved?