Problem solving, troubleshooting and technical support
What this domain covers
Troubleshooting is a systematic process, not guesswork. Candidates should know a structured methodology: gather information and reproduce the problem, identify recent changes, establish a theory, test it, plan and implement a solution, verify full functionality, and document the outcome. Understand how to prioritise by impact and urgency, when to escalate, and how to use logs, error messages, event viewers and vendor knowledge bases. Support models include first, second and third level support, remote versus on-site support, and the role of a ticketing system in tracking history and building a knowledge base.
Concepts to know
- Questioning the user: what changed, when did it start, does it affect others, can it be reproduced.
- Isolation: swap known-good components, test one variable at a time, check the simplest causes first.
- Root cause versus symptom: fixing the symptom may leave the fault to recur.
- Documentation: steps taken, outcome, time, parts used, follow-up.
- Communication during outage: status updates, workarounds, expected resolution.
Traps
Questions penalise random part-swapping without a theory, and penalise skipping verification after a fix. Another trap is escalating too early or too late; escalation should follow agreed criteria such as time spent, skill required or risk. Do not assume a reboot is a solution rather than a diagnostic step. Also remember to check the obvious: power, cables, and whether the issue affects one user or many.
Worked example / rule of thumb
Rule of thumb: one change at a time, then verify. If a printer is offline, check power and cabling, confirm the correct printer and driver, clear the queue, test a page, then document. If several users on one switch lose connectivity, treat it as a network-wide fault and escalate rather than rebuilding each PC.
Study tip
Write troubleshooting as a numbered sequence with a verification step at the end. Markers look for process, evidence and documentation.