Lab Practical Labs 1–7
Work each lab the same way: state the problem precisely, form a hypothesis, decide the one test that would confirm or rule it out, then reveal the walkthrough and compare your reasoning to it.
Lab 1 — The Locked-Out User
A user calls in a panic: "I've been locked out and I need to log in right now." Before you touch anything, what three facts do you need from them?
What do you ask, in order?
Reveal the walkthrough
1) Which system or application, specifically — "locked out" of Windows, VPN, and an internal app are three different tickets. 2) What error message or screen do they actually see — a lockout notice, an MFA failure, and a "account disabled" message point at different causes. 3) When did it start, and did anything change right before (password reset, new device, travel). With those three answers you can check the directory (AD/Entra) for lockout status directly instead of guessing.
Lab 2 — One Site, One Browser
A user reports one internal website is broken — but only in Chrome. It works fine in Edge on the same machine.
Given it's browser-specific, what's your leading hypothesis and first check?
Reveal the walkthrough
Browser-specific strongly suggests client-side state, not server or network — a cached asset, a stale cookie, a browser extension, or a client certificate stored per-browser. First check: open DevTools in Chrome and look at the Network tab for failed requests or console errors, then try an incognito window (rules out extensions and most cached state in one step, per Lesson 2's divide-and-conquer idea).
Lab 3 — Works From Home, Fails at the Office
A laptop user can reach an internal application fine from home, but the exact same login fails from the office network.
What's different between those two environments that's worth checking first?
Reveal the walkthrough
Home and office differ in network path, source IP, and often DNS server. Leading suspects: a Conditional Access policy that treats office IP ranges differently (unlikely to be the blocker, but worth ruling out), an internal DNS record only reachable/resolved differently on the corporate network, or a proxy/firewall rule on the office network intercepting the request. Compare nslookup results and a packet capture from both locations side by side (Lesson 3, §5) rather than guessing which one it is.
Lab 4 — The 2 AM Batch Job Failure
An overnight batch job that authenticates using a service account has started failing every night at roughly 2:15 AM. It was working fine for the past year.
"Working for a year, then suddenly failing" — what's the first thing this pattern should make you check?
Reveal the walkthrough
Service account password or certificate expiry (Module 9/10) — credentials issued a year ago with a 365-day validity period expiring on schedule is one of the most common "mysteriously started failing" causes in enterprise environments. Check the account's credential expiry date before investigating the batch job's code at all; this is the "what changed" question from Lesson 1, except the change is time itself passing a threshold.
Lab 5 — The Ticket With No Error Message
A user says an application "just doesn't do anything" when they click submit. No error, no crash, nothing on screen.
With zero error message to go on, where do you look for evidence?
Reveal the walkthrough
A silent failure in a web application is a strong hint to open browser DevTools' Console and Network tabs (Lesson 3, §3) — a JavaScript error or a failed background request is very often happening silently even though the page shows nothing. If DevTools shows nothing either, check application server logs for that user's session around the timestamp they clicked. "No error visible to the user" almost never means "no error occurred."
Lab 6 — Everyone in One Building, No One Else
Users in a single branch office report they can't access anything on the internet. Every other office and all remote users are fine.
Scoped to exactly one physical location — what does that tell you, and what do you check first?
Reveal the walkthrough
A single-site outage affecting everyone there points at something local to that site's infrastructure — the site's internet circuit, its local firewall/router, or its ISP — rather than anything central like identity or a shared application (which would affect every site equally). Check the site's edge device status and circuit status first; this is scope-first thinking (Lesson 1, §2) at the network layer.
Lab 7 — The Fix That Didn't Fix It
You applied what you were sure was the correct fix for a failing login. The user tries again and it still fails, with what looks like the same error.
Before trying a second fix, what should you confirm?
Reveal the walkthrough
Confirm it's actually still the same error, not a different one that merely looks similar — ask for a fresh screenshot or reproduce it yourself rather than trusting memory. Also confirm your fix actually applied (cache, replication delay, a config that needs a service restart to take effect). Stacking a second fix on top of an unconfirmed first fix is exactly the "change one variable at a time" principle from Lesson 2 being violated under pressure.
Lab Advanced Multi-System Capstone
Capstone Scenario
9:02 AM: Support tickets start arriving from multiple departments — users report they can log into the company portal, but several downstream applications (expenses, HR self-service, internal wiki) show "access denied" once they get there. Not everyone is affected. IT chat is starting to fill with speculation.
Work this the way Lessons 1–5 taught you: what's your very first move, before you open any tool?
Reveal the walkthrough
Step 1 — scope, not tools. Get precise: which applications exactly, which users exactly, and is it 100% of those users or a subset? "Portal login succeeds, downstream app access fails" is a strong signal by itself — it points at authorization (what you're allowed to do) rather than authentication (who you are), since identity clearly already succeeded.
Step 2 — what changed. Check recent changes: a Conditional Access policy update, an authorization/claims configuration change, a token lifetime change, or a permissions/group sync job that ran overnight (Module 10's IAM content). A change window around midnight to early morning, combined with symptoms appearing at 9 AM as people start their day and their existing sessions expire, is a classic signature of an overnight policy or sync change.
Step 3 — test the hypothesis. Pick one affected user and one affected application, check their group memberships and the application's authorization logs for the exact denial reason (Lesson 3's log-correlation approach), and compare against a working user in the same group.
Step 4 — communicate and decide. Post a status update even before you have the root cause pinned down. If a specific overnight change is identified as the likely cause, rolling it back (Lesson 5, §4) is very likely faster and safer than trying to patch authorization rules live while people are still locked out.
This capstone deliberately combines: scope-first thinking (Lesson 1), the authentication-vs-authorization distinction (Lesson 4, §6), "what changed" (Lesson 1), log correlation (Lesson 3), and rollback (Lesson 5) — because real incidents never arrive pre-sorted into one lesson's topic.
1 The 13-Step Troubleshooting Decision Model
A single checklist that folds this entire module into one sequence you can genuinely carry into your first job:
You won't consciously walk through all thirteen steps on a five-minute password reset ticket — and that's fine. The value of the model is that on the hard tickets, the ones that would otherwise eat an entire afternoon of guessing, you have an explicit sequence to fall back on instead of flailing.
2 Real-World Enterprise Example: The HR Application Outage
A mid-sized company's HR self-service application went down company-wide at 8:45 AM on a Monday — the first business day of open enrollment, with hundreds of employees expected to log in and select benefits before a hard deadline. Here's how it actually unfolded, mapped against the framework:
- Problem statement (step 1): "HR application returns a 503 Service Unavailable for 100% of users, company-wide, since approximately 8:40 AM."
- Scope (step 2): Confirmed as global — not one region, one department, or one user group. This ruled out a Conditional Access or authorization issue immediately, since those almost never fail for literally everyone at once.
- Last known good / what changed (steps 3–4): The application was healthy at the 8:00 AM automated check. A scheduled database maintenance job had run at 8:30 AM as part of routine patching.
- Hypothesis and test (steps 7–9): Thinking bottom-up, the team checked the database first rather than the application code — the database maintenance job had failed partway through and left the database in a state where new connections were being rejected.
- Decision (step 11): With open enrollment's deadline looming, the team chose rollback over root-cause investigation in the moment — reverting the maintenance job's changes restored service in nine minutes. Root-cause analysis of why the maintenance job failed happened afterward, without users still locked out while it ran.
- Escalation and communication (steps 12–13): Given the business impact (a hard compliance deadline, hundreds of affected employees), the incident was escalated to major-incident status immediately, with status updates posted every fifteen minutes even during the nine minutes where there was genuinely nothing new to report.
Notice what made this fast: the team didn't start by reading application code. They scoped it, checked what changed, tested the layer most likely to be at fault first, and chose the safe, reversible option under time pressure — then did the deeper analysis once people could actually use the system again.
3 Final Principle
Every module in this course — networking, authentication, IAM, SOC operations, incident response, APIs, logs, PowerShell — has been building toward this one skill, because troubleshooting is where all of that knowledge actually gets used under pressure. The engineers who become genuinely trusted on a team aren't the ones who happen to know the most facts; they're the ones who stay calm, work systematically, and can be handed an ambiguous, half-described problem and reliably turn it into a precise, correctly diagnosed, well-documented resolution.
That's a learnable skill, not a talent you either have or don't. Every scenario and lab in this module was a rehearsal for exactly that.
Module 16 Complete
You've now worked through the full troubleshooting methodology — framework, techniques, tools, real scenarios, professional practice, and hands-on labs — and completed the final module of Section 03: Authentication & MFA. Mark this lesson complete to close out Module 16, and continue to Section 04: Professional Communication.