Labs & the Ticket Queue Simulator

Title: "Microsoft 365 authentication failure affecting corporate users." Priority: P1 (high impact — company-wide; high urgency — blocks core productivity tools). Description: should state exactly what's failing (sign-in, not just "M365 broken"), start time in UTC, an example affected user, and whatever the first triage step showed (e.g. "Entra ID sign-in logs show 90%+ failure rate starting 09:03 UTC across multiple regions"). Next action: something concrete and owned, e.g. "Identity team to review Entra ID service health and recent Conditional Access changes."

A — P4: one user, low urgency. B — P1: company-wide impact, high urgency. C — P3 (not P1): a failed backup with a healthy backup from the night before is real but not urgent — there's no immediate data-loss exposure, so it needs prompt attention, not an emergency response. D — P1, and likely reclassified as a security incident: per Lesson 2's "security priority can be different" — a compromised admin account carries critical impact even with zero visible outage. E — P4 or P3: a dev environment being down rarely justifies urgency unless it's actively blocking a release.

Add: environment (which VPN gateway/platform, production vs. test), impact (how many users, which locations), start time in UTC, troubleshooting already performed (specifically, not "checked server"), logs or error messages, any recent changes, and a clear next action with an owner. This is the same transformation Lesson 3's escalation example walked through — the content the customer already gave you ("VPN broken," "users complaining") survives, it's just surrounded by the facts that let someone else actually act on it.

Response SLA: met (22 minutes, inside the 30-minute target). Resolution SLA: breached — 5.5 hours elapsed against a 4-hour target. This is Lesson 2's response-vs-resolution distinction made concrete: responding on time says nothing about resolving on time, and real SLA tracking (with pending states and business hours) gets considerably more complex than this simplified version.

Symptom: application timeouts / high CPU. Workaround: restarting the application (which is why CPU climbs again at 13:00 — the underlying cause was never touched). Likely root cause: the 08:00 deployment introduced something CPU-intensive or leaking (a runaway process, an infinite retry loop, a bad query plan). Required investigation: diff the deployment, profile CPU usage post-deploy, correlate with application logs from 10:15 onward. Preventive action: load testing before release, and CPU-trend monitoring that alerts well before 100%.

Current status, impact, findings so far, actions completed, next action, owner, and next update time — compressed to what the next engineer needs to act, not a re-read of the full timeline. This is exactly how real 24×7 support teams operate: nobody reads two pages of history before picking up a live P1.

Severity: high/critical — administrator-level "impossible travel" (London to an unknown location in 6 minutes is not physically possible). Evidence: the two login events with timestamps, IPs and locations. Hypothesis: the second login is not the legitimate user — likely session/credential compromise. Validation: contact Alice directly through a separate channel to confirm. Containment: disable the account, revoke active sessions, force a credential reset, review what the admin session accessed. Escalation: straight to SOC/security team, immediately — this is not a helpdesk ticket.

"Root Cause: TLS certificate for [service] expired at [time]. Resolution: new certificate issued and installed on [servers]. Validation: successful HTTPS connections confirmed from test and production clients post-install. Customer Confirmation: customer confirmed service access restored at [time]. Preventive Action: certificate expiry monitoring/alerting to be added, tracked under [problem record]." Every field earns its place — nothing here is padding, and "Fixed" alone would have told the next reader almost nothing.

The ServiceNow interface is incidental — the real skill is the workflow: triage discipline, deciding ownership without ping-pong, writing a pending note that states exactly what's needed (Lesson 5), escalating with evidence rather than "please investigate," and closing with a real root cause. That workflow transfers directly to Jira Service Management, Zendesk, Remedy, or any future platform you haven't seen yet.

It's written for someone who will read code, not explain the issue to a customer — exact reproduction steps and reproduction rate matter far more here than business framing. This connects straight back to Module 17, Lesson 4: the same incident described very differently depending on whether the reader is Engineering or the customer.

Public reply: calm, factual, no jargon — acknowledge impact, state what's confirmed so far, ask only for what's needed, commit to a next update time (Lesson 1's public-vs-internal distinction, and Module 17's angry-customer guidance). Internal note: can be terser and more technical — suspected cause, similar past tickets, what needs confirming before anything gets said to the customer. Mixing the two up is exactly the mistake Lesson 1 warned about.

• #1 P1, Incident. Company-wide authentication outage — the textbook P1 from Lesson 2. Declare a major incident immediately and open a bridge (Module 17, Lesson 3).
• #2 P4, Incident (or service request). One user, vague symptom, no error. Per Module 16's troubleshooting scenarios, ask for specifics before doing anything else — don't escalate on "a bit slow."
• #3 P1, Security Incident — escalate to SOC immediately. Same "impossible travel" pattern as Lab 7. No production outage, but critical security impact (Lesson 2, §5).
• #4 P2–P3, Jira Bug → Engineering. Reproducible defect, not customer-blocking in itself unless the missing header is common in production traffic — check that before finalising priority.
• #5 P2 (probably not P1) — verify before trusting the customer's framing. "COMPLETE DOWN" in caps doesn't set priority on its own (Lesson 2, §3) — check whether it's actually down for everyone or just this account, then set priority on what you find, not on the tone of the message.
• #6 P3, Incident. Failed backup with a good backup from the night before is real but not urgent — same as Triage Lab 2's Ticket C.
• #7 P4, Incident. One user, everyone else fine — this is Module 16 Lesson 4's VPN scenario almost exactly; check the user's device/credentials/MFA before assuming anything wider.
• #8 Internal note — not customer-visible. This is the public-vs-internal distinction from Lesson 1: never let this text reach a customer-facing reply until Engineering confirms.
• #9 P1–P2, and link to #1 and #12 if the timing lines up. A certificate change two hours ago followed by TLS errors is a "what changed" match (Module 16, Lesson 1) — check whether this is actually the root cause behind ticket #1's company-wide outage, and whether tonight's maintenance in #12 is related or coincidental.
• #10 P4, Service Request-adjacent. No production impact, no urgency — do not let this compete with #1, #3 or #9 for attention today.
• #11 Duplicates of #1 — link them to the same parent, don't investigate separately. Fifteen "can't log in" tickets in ten minutes during a company-wide outage is exactly Lesson 5's duplicate-ticket pattern; link all fifteen (and any more that arrive) to the #1 major incident record rather than triaging each individually.
• #12 Change record, not an incident — but now highly relevant context. Once #1 and #9 look connected to authentication server certificates, this scheduled maintenance needs to be checked against timing and potentially paused or coordinated with the live incident, not treated as routine.

The real lesson of the queue: three tickets that look unrelated at first glance (#1, #9, #12) are very plausibly the same incident once you read for "what changed" — and one alarming-sounding ticket (#5) needed verification, not immediate escalation, while a quiet-sounding one (#3) needed the fastest possible response of the entire queue. Triage is pattern recognition across the whole board, not scoring each ticket in isolation.