Common Scenarios

Scope first. Does it fail for everyone, or just this user? One user → check their print queue, driver, and permissions. Everyone → check the print server, the printer's network connection, and the printer's own physical status (paper, toner, error display) before assuming software. A print-server service that has stopped explains "everyone, all at once" instantly — and you'd never find that by reinstalling one user's driver.

Bottom-up, per Lesson 2: confirm the user has working internet at all (can they reach any website?). Then check whether the VPN gateway is reachable and healthy — is it just this user, or is the whole VPN concentrator down? Then check the user's credentials and MFA against the VPN specifically. Then check client-side certificate expiry or an outdated VPN client version. Each layer either clears the user or points you at the next one — you never guess at layer four before confirming layer one.

Confirm the user actually has network connectivity on their phone (airplane mode, Wi-Fi outage, dead battery are all common and boring). Confirm the authenticator app is signed into the correct account — a second registered device or a stale app install is a frequent cause. Check whether the identity provider's push service is experiencing a wider outage. Check whether the user's device or app needs re-registration after a phone replacement. Only after all of that would you escalate to the identity team about the push service itself.

Try the IP address directly (as in Lesson 2's divide-and-conquer example). If the IP works and the hostname doesn't, it's DNS — full stop, nothing else needs investigating on the application side. From there: nslookup/Resolve-DnsName/dig the hostname, check which DNS server answered, and check whether that record is stale, missing, or pointing at the wrong IP. This is one of the highest-value two-minute tests in all of troubleshooting.

Since it's one user and one application, steps 1–4 (lockout, password, MFA, IdP reachability) are less likely to be the whole story — if the IdP were down, everything would fail for everyone. The likely culprits are step 5 (a Conditional Access or authorization policy scoped to that specific application) or step 6 (the application itself rejecting a token it received correctly). Check the application's own sign-in logs for the exact error code before assuming it's an identity-layer problem at all.

"Down" usually gives you a clean error and a log entry. "Slow" needs timing evidence — browser DevTools' Network tab timing breakdown, database query duration, API response latency, and correlated timestamps across the request path (Lesson 3, §5) to find which single hop is disproportionately slow. A request that takes 30 seconds isn't uniformly slow everywhere — almost always one component (a query, an upstream call, a saturated link) accounts for nearly all of the delay, and your job is to isolate exactly which one.

Certificate expiry — check the expiry date on the certificate itself before anything else. This is a textbook "what changed" question from Lesson 1: nothing in the application changed, but time passed, and the certificate's own validity window ran out. If expiry isn't it, check for the wrong certificate being served, an incomplete certificate chain, or a hostname mismatch. Certificate problems are also a favourite exam and interview question precisely because the fix is usually simple once you check the one obvious thing first.