Service Desk Interview Questions — Answers, Scenarios & Cheat-Sheet

① ITIL & ITSM basics — the concept round

Before any troubleshooting, interviewers check that you speak the language of a service desk. The single most-asked question is the difference between an incident, a service request, a problem and a change. Get this clean and the rest of the interview relaxes.

The four words every interview starts with

90% of service desk interviews open by checking if you can tell these four apart. Tap each card.

Two more terms come up constantly. An SLA is the promise IT makes to the business (e.g. "P1 resolved in 4 hours"). An OLA is the internal promise between IT teams that makes the SLA achievable. If the Network team's OLA slips, your SLA to the user breaks too — that's why the desk chases other teams.

Change management: the three change types and the CAB

Once you nail the four record types, interviewers go one level deeper into Change, because it is the one a careless agent can use to take down production. There are three types of change in ITIL 4, sorted by risk. Tap each.

The submission that asks for a change is the RFC. A clean answer ties it together: "A standard change is pre-approved so it skips the CAB; a normal change is risk-assessed by the CAB; an emergency change is fast-tracked through the ECAB to fix a major incident and is reviewed afterwards."

Problem vs Known Error, and what RCA really means

The other concept interviewers probe is the difference between a Problem and a Known Error. A Problem is the suspected root cause of one or more incidents that is still under investigation. The moment you have identified the root cause and a workaround, it is promoted to a Known Error and recorded in the KEDB so the desk can apply the workaround instantly next time. RCA (Root Cause Analysis) is the structured "why did this really happen" investigation — techniques like the 5 Whys or a fishbone diagram — that turns a Problem into a fix.

Add the proactive/reactive distinction and you sound senior: reactive problem management starts after incidents have already hit users; proactive problem management spots trends and patterns (e.g. the same printer failing weekly) and removes the cause before the next incident. Reactive puts out fires; proactive stops them starting.

② The ticket lifecycle, priority & the tool

Next, interviewers want to see that you understand how a ticket moves and how its priority is decided. Recite the lifecycle, then prove you know that priority is a calculation — not a feeling.

Priority is the most tested — and most failed — concept. It is Priority = Impact × Urgency. Impact is "how big / how many"; urgency is "how fast". You read the cell where they meet off a matrix.

These SLA numbers are illustrative — every organization tunes them to its own contracts and business hours. Say that in the interview; it shows maturity.

You'll spend your whole day inside a ticketing tool. ServiceNow is the market leader, so know its incident form cold.

③ The technical / troubleshooting round

Now the hands-on round. Freshers panic and reach for memorized commands. What interviewers actually score is your thought process — can you isolate a problem layer by layer? The classic test is connectivity.

Know these three commands and exactly what each tells you:

ipconfig /all          # see your IP, gateway, DNS
ping 192.168.1.1       # reach your gateway?  (LAN)
ping 8.8.8.8           # reach the internet?  (link)
ping google.com        # resolve a name?      (DNS)
ipconfig /flushdns     # clear a bad DNS cache

Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 8.8.8.8: bytes=32 time=14ms TTL=117
Ping request could not find host google.com.   <-- IP works, name fails = DNS

The other evergreen technical topics: an AD account lockout (check ADUC, unlock, hunt the stale cached password), an Outlook sync issue (OST vs PST — run scanpst.exe or rebuild the OST), a VPN that won't connect (internet first, then client, credentials, MFA, cert), and a stuck printer (restart the Print Spooler service).

Networking fundamentals: DHCP, DORA & that 169.254 address

Almost every L1 interview asks how a PC gets its IP. The answer is DHCP, and the four-step handshake is DORA: Discover (the PC shouts "any DHCP servers?"), Offer (a server offers an IP), Request (the PC says "I'll take it"), Acknowledge (the server confirms and leases it). Memorize DORA — it is a guaranteed question.

The follow-up: "what does a 169.254.x.x address mean?" That is APIPA — the PC failed to reach a DHCP server and self-assigned a fallback address, so it has no real network. Cause: DHCP server down, cable/switch issue, or exhausted scope. Fix: check the link, then ipconfig /release and ipconfig /renew.

ipconfig /release      # drop the current (or APIPA) address
ipconfig /renew        # ask DHCP for a real one again
ipconfig /all          # confirm you now have a 10.x / 192.168.x address, not 169.254.x

The OSI model — and how to use it as a checklist

You will be asked to name the OSI model's seven layers. The classic mnemonic (bottom→top) is "Please Do Not Throw Sausage Pizza Away": Physical, Data Link, Network, Transport, Session, Presentation, Application. The senior move is to use it as a fault-finding ladder: cable unplugged = Layer 1; wrong VLAN/MAC = Layer 2; bad IP/gateway/routing = Layer 3; blocked port = Layer 4; the app itself failing while the network is fine = Layer 7. Saying "I'd work up from Layer 1" beats reciting the list.

OST vs PST — finally explained

"What's the difference between OST and PST?" is a near-certain Outlook question, and most freshers fumble it. An OST is an offline cached copy of your mailbox — it syncs back to the Exchange/M365 server, so it is never the only copy of your mail; if it corrupts you just rebuild it. A PST is a standalone local archive that lives only on that PC and does not sync to the server — lose the file and the mail is gone. Rule of thumb: OST = live, server-backed, safe to delete; PST = archive, local-only, back it up.

The Blue Screen of Death (BSOD) walk-through

"Walk me through troubleshooting a BSOD" tests whether you panic or follow a method. Lead with the method, not a guess: (1) read and note the stop code on screen (e.g. MEMORY_MANAGEMENT, DRIVER_IRQL_NOT_LESS_OR_EQUAL) — it names the culprit area. (2) Ask "what changed?" — a new driver, update, or hardware. (3) Boot into Safe Mode to get a stable session. (4) Roll back the recent driver/update; check Event Viewer for the failing component. (5) Run sfc /scannow then DISM /Online /Cleanup-Image /RestoreHealth to repair system files. (6) Test the RAM (Windows Memory Diagnostic) if the code points at memory. Last resort: re-image the machine.

sfc /scannow                                   # scan & fix protected system files
DISM /Online /Cleanup-Image /RestoreHealth     # repair the underlying Windows image
# then: Safe Mode → roll back the recent driver → check Event Viewer

Workgroup vs domain, joining a PC, and GPO

A workgroup is peer-to-peer: every PC manages its own local accounts, with no central control — fine for a home or tiny office. A domain is centrally managed by Active Directory: one login works on any domain PC, and IT controls everything from one place. You join a PC with System → About → Rename this PC (advanced) → Domain, enter the domain name and a privileged account, then reboot.

Central control is enforced by GPO (Group Policy Object) — rules AD pushes to every domain machine. Have one concrete example ready: "a GPO that maps the Finance shared drive automatically," "one that enforces a password-complexity and lockout policy," or "one that sets the corporate screen-lock timeout." Run gpupdate /force to apply changes immediately and gpresult /r to see which policies a machine actually received.

Identity & cloud: MFA, conditional access and the modern stack

Modern desks run on Microsoft 365 / Entra ID (the new name for Azure AD), so know the cloud basics. MFA adds a second factor (an authenticator-app prompt, a code, or biometrics) on top of the password, so a stolen password alone can't log in. Conditional access is the rule engine that decides when to demand it — e.g. "require MFA from outside the office, block sign-ins from risky countries, allow trusted compliant devices through."

The L1 gotcha: "what if the user is locked out of MFA — lost the phone?" You never just disable MFA. You verify their identity out-of-band (a manager confirms, or ID check), then in the M365/Entra admin centre you re-require MFA registration so they enrol a fresh device on next sign-in — you don't leave the account unprotected. Bonus vocabulary that lands well in 2026: company devices are managed and pushed apps/policies/compliance via Intune, the cloud successor to GPO for managing laptops and phones.

④ Scenarios, behaviour & standing out

The final round is scenarios and soft skills — where most freshers are actually decided. The secret is a repeatable structure you apply to any "what would you do if…" question: Clarify → Triage (scope) → Isolate → Resolve or Escalate → Document. Memorize that chain and you'll never freeze.

Escalation is a favourite gotcha. Functional escalation moves a ticket to more skill (L1→L2→L3). Hierarchical escalation moves it up the management chain for authority or visibility. On a P1, you do both at once.

To stand out, talk in metrics. FCR (resolve on first contact), MTTR (resolve faster), CSAT (keep users happy), and shift-left (resolve more at L1 with KB + automation). A fresher knows the terms; an experienced hire shows how they moved the numbers.

The STAR method and the classic behavioural questions

For any "tell me about a time…" question, never ramble — use the STAR frame: Situation (set the scene briefly), Task (what you had to do), Action (what you specifically did), Result (the outcome, ideally with a number). The trap is spending all your time on Situation; interviewers want the Action and the Result. End every story on a positive, measurable result.

These openers are still asked in almost every interview — have one tight answer ready for each:

• "Tell me about yourself." A 60-second pitch: who you are, your relevant skills/lab, and why this role — not your life story. Finish with "…which is exactly why I'm excited about this service desk role."
• "What's your biggest weakness?" Pick a real but non-fatal one and show you're fixing it: "I used to over-document and slow myself down; now I use KB templates to stay both thorough and fast." Never say "I'm a perfectionist" — it's the answer everyone fakes.
• "Tell me about a conflict with a colleague / a difficult customer / a mistake you made." Run it through STAR, own your part, and land on what you learned and changed. Owning a mistake calmly scores higher than pretending you've never made one.
• "How do you handle multiple urgent tickets at once?" Prioritise by impact × urgency, communicate ETAs, and escalate/ask for help early rather than silently dropping one.

How AI and copilots are reshaping the service desk (2026)

A genuinely current question in 2026 is "how is AI changing the service desk, and how would you use it?" Don't say "it'll take my job" — show you understand the shift. There are two levels: an assistive copilot helps the agent (drafts replies, summarises a noisy ticket, suggests the right KB article), while an agentic AI actually does the work end-to-end — it can reset a password, run the workflow, then close the ticket and confirm. In production, AI now deflects 50–85% of routine, high-volume requests, dropping first response to seconds.

The interview-winning framing: "AI handles the repetitive password-reset and access tickets so the desk can shift-left even harder and spend human time on judgement, complex incidents and the customer relationship." That ties the new tech straight back to shift-left and FCR — you sound like someone who'll embrace the tools, not fear them. Add that AI is only as good as the KB feeding it, so writing clean KB articles matters more than ever.