Troubleshooting and Support
This domain rewards a repeatable method and clean evidence handling over lucky guesses. The exam likes scenarios where the obvious fix is not the correct first step.
The method
- Identify - gather symptoms, question the user in plain language, ask what changed recently.
- Theorise - establish the most probable cause, starting with the simplest and cheapest to test; work bottom-up through the layers if unsure.
- Test - confirm or discard the theory. If discarded, form a new one or escalate.
- Plan and act - change one variable at a time, with a rollback path and user agreement.
- Verify and prevent - confirm full function with the user, then address the cause recurring.
- Document - record symptoms, cause, action and outcome.
Evidence sources
Event Viewer on Windows, syslog or journalctl on Linux, application logs, uptime, ping and traceroute, ipconfig /all, vendor diagnostics, and the change calendar.
Worked example
Wi-Fi drops intermittently in one office. Reasoning: establish scope first. If only one laptop drops, suspect that adapter's driver, power saving or channel. If every device in the area drops together, suspect the access point, its PoE supply, interference or DHCP lease exhaustion. Check the access point logs before ordering replacement hardware.
Traps that cost marks
- Changing several settings at once, so you cannot tell which one worked.
- Reimaging as a first step, destroying the evidence of the real cause.
- Closing a ticket because the user stopped replying, without confirming resolution.
- Skipping documentation, so the same fault is re-diagnosed next month.