1 Timestamps, Time Sync & Comparing Configs
Clock drift breaks more things than people expect — Kerberos tickets fail outside a five-minute skew (Module 9), TOTP MFA codes fail outside roughly thirty seconds, TLS certificate validation fails if a device's clock is wrong enough, and log correlation across systems becomes impossible if their clocks disagree. When timestamps in a correlated log trail don't line up the way you'd expect, check NTP sync before assuming the logs are lying to you.
Comparing configuration between a working system and a broken one is one of the fastest root-cause techniques available: a working server's config file against a broken server's, a working user's group memberships against a broken user's, a working device's settings against a broken device's. The difference — often one line — is usually the answer. This is the same "known-good comparison" idea as the "last known good state" concept from Lesson 1, applied laterally across systems instead of across time.
2 Intermittent, Clustered & Cloud Troubleshooting
Intermittent issues are the hardest category: they can't be reliably reproduced. Focus on capturing evidence the moment they occur — timestamps, error messages, screenshots — rather than waiting for a clean reproduction, and look for a pattern across occurrences (same time of day, same user population, same downstream system) rather than a single root cause.
Clustered and load-balanced environments add a layer: the problem might affect only one node in a cluster of ten, which explains why "it works when I try it" and "it's broken for the user" are both true at once — you and the user were quietly routed to different nodes. Cloud environments introduce their own failure modes on top of everything else — auto-scaling events, regional outages, IAM permission changes, and API rate limiting can all present as generic application slowness or failure with no obvious on-box cause at all.
3 Security-Aware Troubleshooting & the Workaround/Fix/Root-Cause Model
Never disable a security control just to make troubleshooting easier without going through a proper change process — turning off MFA, opening a firewall rule, or disabling logging "temporarily" to unblock a ticket is exactly the kind of shortcut that turns into an incident later (Module 12 covers this from the containment side).
It also helps to separate three distinct outcomes explicitly, rather than treating them as the same thing:
- Workaround — the user can work again right now, but the underlying cause is still there.
- Fix — the specific instance of the problem is resolved for this user or system.
- Root cause resolution — the underlying cause is resolved so the problem can't recur elsewhere.
All three are legitimate, professional outcomes — a workaround to unblock a VIP during a live incident is often exactly the right call. The professional failure isn't choosing a workaround; it's calling a workaround "resolved" and moving on without tracking the real fix.
4 Rollback
If a recent change caused the problem (Lesson 1's "what changed" question), rolling that change back is very often faster and safer than trying to fix forward under pressure. Always know your rollback plan before making a risky change in the first place — deciding how to undo something after it's already broken production is the wrong time to design that plan.
5 Escalation, Documentation & Communication
Escalate when you've exhausted your knowledge, when the issue affects many users or a critical system, when you suspect a security incident (escalate to the security team immediately — see Module 12), or when you're approaching an SLA deadline. Escalating isn't failure; it's professional judgment, and a good escalation includes everything you've already ruled out so the next person doesn't repeat your steps.
Document what you tried, in order, even for approaches that didn't work — that saves the next engineer (possibly you, in six months) from repeating the same dead ends. And communicate proactively: update the ticket and the affected users regularly, even when there's no new information yet. "Still investigating, no update" is far better than silence, which reads as "nobody is working on this."
6 Major Incidents, Common Mistakes & Mindset
During a major incident: follow the organisation's major incident process, focus on restoring service first and finding root cause second (Module 12's containment-before-full-analysis pattern applies here too), communicate status at agreed intervals even without new findings, and don't work in isolation — coordinate with the incident commander or lead.
Common troubleshooting mistakes worth naming so you can catch yourself doing them: changing multiple things at once (Lesson 2, §5), skipping the "what changed" question, not reading the actual error message carefully, assuming instead of verifying, not checking the simple things first, and giving up on the systematic approach the moment something feels urgent — urgency is exactly when discipline matters most, not when it's safe to abandon.
Above all, troubleshooting is a skill built through deliberate practice, not something you're either naturally good at or not. Every engineer who is fast and calm under pressure got there by working through hundreds of real problems, methodically, one at a time — exactly what Lesson 6's labs are designed to start you doing.
Lesson Outcome
You can now separate workaround from fix from root cause, know when and how to escalate well, understand why documentation and proactive communication matter as much as the technical work, and know how to conduct yourself during a major incident. Lesson 6 puts everything from this module together in seven hands-on labs and a capstone scenario.