All jobs

IT support / sysadmin interview questions

Questions an interviewer can ask a IT support / sysadmin, grouped by years of experience. Open one to see the strongest answer and why it works.

48 of the 140 questions our bank holds for this job. The rest are in the app.

By subject

0–1 years

  1. A ticket says “email is broken.” What do you ask first?

    The strongest answer: What they were doing, what they expected, what they saw, and on which device or account — not “I will just take a look”

    Why it works: Exactly. Repro, expected, actual, where. That is a ticket you can work.

    • Get steps, expected, actual, where.
    • Restart is a step, not the ticket.
    • Never take their password.
    • Do not bounce them for being unclear.
  2. A laptop that cannot reach anything has the address 169.254.12.40. What does that tell you?

    The strongest answer: It gave itself a link-local address because no DHCP server answered — so I check the cable or the wireless association, the switch port, and whether anyone else on that segment is failing too

    Why it works: Right — that range is the machine saying nobody answered, which points you at the path between it and the DHCP server.

    • That range means DHCP never answered.
    • Check cable, wireless, switch port.
    • Ask whether others are failing too.
    • Do not paper over it with a static.
  3. Someone calls: “Reset my password, I am the CFO.” First move?

    The strongest answer: Verify identity with the process you already have — callback, manager, or a known device — then reset. A title is not a badge

    Why it works: Exactly. Identity first. Urgency is how attackers sound.

    • Verify, then reset.
    • A job title is not identity.
    • Do not handle their new password.
    • Do not refuse all resets; use the process.
  4. You can do the task in the console in two minutes. Why would anyone write a script for it?

    The strongest answer: Because it comes out the same every time, whoever is on shift can reuse it, and it leaves a record of what ran — which matters the moment it has to happen on forty machines

    Why it works: Exactly. Consistency, reuse and a record are the reasons; saved minutes are a side effect.

    • Same result every time.
    • Anyone on shift can reuse it.
    • It leaves a record of what ran.
    • Repetition is the test, not pride.
  5. A user forwards a “payroll update” mail and asks if they should click. What do you say?

    The strongest answer: Do not click — report it with the company button or to the mailbox you name, and I will treat the sample as evidence, not as a link to try

    Why it works: Exactly. Report, do not detonate. Your curiosity is not a sandbox.

    • Do not click; report.
    • Keep the sample as evidence.
    • Do not open it “to see.”
    • Do not reply to the bait.
  6. An application’s Windows service is stopped and the application is down. What do you do?

    The strongest answer: Start it, then look at its startup type and recovery settings and read the System and Application logs around the time it stopped — a service that dies has a reason

    Why it works: Exactly. Restore service, then find out why it stopped and whether it is set to start itself next time.

    • Start it, then find out why.
    • Check the startup type and recovery.
    • Read System and Application logs.
    • Never run a service as domain admin.
  7. When is “have you rebooted?” the right move, and when is it a brush-off?

    The strongest answer: Right after I know what is failing and a reboot is a fair test — a brush-off when I have not heard the repro and I am emptying the queue

    Why it works: Exactly. A named test, not a reflex. Surprise reboots destroy work.

    • Reboot after you know the symptom.
    • Name it as a test.
    • Do not use it to empty the queue.
    • Do not reboot in secret.
  8. A desktop powers on — fans and lights — but the monitor stays blank. How do you work through it?

    The strongest answer: Check the monitor’s own power and selected input and try another cable and port, then whether the machine is posting at all: status lights or beeps, and reseat the memory and the graphics card before I suspect the board

    Why it works: Exactly. Cheapest and most reversible first, and “is it posting?” is the question that splits the search in half.

    • Cheapest and reversible first.
    • Monitor power, input, cable, port.
    • Then: is the machine posting?
    • Reseat memory and card before the board.
  9. You fixed a laptop after 40 minutes. What goes in the ticket?

    The strongest answer: What I tried, what worked, and what I told the user — so the next person is not starting from zero

    Why it works: Exactly. Notes are the handover. Clean queues with empty notes are a lie.

    • Tried / worked / told the user.
    • Do not write only “resolved.”
    • No jokes about people.
    • Memory is not a knowledge base.
  10. Someone describes your backups as “three copies, two kinds of media, one off-site”. What is each part for?

    The strongest answer: Three copies so losing one is survivable, two kinds of media so one failing technology cannot take both, and one copy off-site and out of reach so a fire or an encryption run cannot get them all

    Why it works: Exactly. Each number defends against a different way of losing everything at once, which is why all three are stated.

    • Each number covers a different loss.
    • Three copies: one can die.
    • Two media: one technology can fail.
    • One off-site and out of reach.
  11. How do you tell someone their VPN certificate expired?

    The strongest answer: In their words: the secure-office login on this laptop ran out, here is the one screen to refresh, I will stay until it works

    Why it works: Exactly. Outcome, one action, you stay. Jargon is how tickets bounce.

    • Say the outcome and the next click.
    • Stay until it works.
    • Keep jargon for other technicians.
    • Do not leave a silent expiry.
  12. You need a tool on a Linux server and the project’s website offers a one-line install script. What do you do?

    The strongest answer: Install it from the distribution’s package manager or the vendor’s signed repository, so it is recorded, patchable and removable — a piped script is unreviewed code running with your privileges

    Why it works: Exactly. The package manager is what will tell you next year that this is installed, at which version, and how to patch it.

    • Install what the system can track.
    • Prefer the distribution or a signed repo.
    • Untracked binaries never get patched.
    • Never pipe the web into a root shell.

1–3 years

  1. Forty new tickets, one on-call. How do you order the morning?

    The strongest answer: Safety and identity first, then many-people down, then deadlines you can see, then the rest — I write the order so the queue is not my mood

    Why it works: Exactly. A written impact order. Mood and IM are not a service.

    • Safety, identity, blast radius, deadlines.
    • Write the order.
    • Not IM, not mood.
    • Do not only close the easy ones.
  2. A vendor article tells you to change a registry value on a production server. What do you do before and after?

    The strongest answer: Export the key first, write the old value into the ticket, make the change in a change window, restart whatever reads it, then confirm the symptom is actually gone

    Why it works: Right — the export is the way back, and the ticket is what tells the next person why the value is odd.

    • Export the key before you edit.
    • Record the old value in the ticket.
    • Change inside a window.
    • Restart the reader, then verify.
  3. A low-severity ticket is about to breach SLA. What do you not do?

    The strongest answer: I do not bump its severity to save the clock — I either work it, renegotiate, or accept the breach and say why

    Why it works: Exactly. Clocks measure; they do not rewrite impact. Green dashboards with lies train leadership to ignore you.

    • Do not relabel severity for SLA.
    • Work, renegotiate, or accept.
    • No close-reopen tricks.
    • No “file again” resets.
  4. What does RAID 1 protect you from that RAID 0 does not, and is an array a backup?

    The strongest answer: RAID 1 mirrors, so the volume survives a disk failure; RAID 0 stripes for capacity and loses everything if one disk dies. Neither is a backup — a deletion or a corruption is written to every member at once

    Why it works: Right. Redundancy protects against a disk dying; it does not protect against the wrong thing being written.

    • RAID survives disks, not mistakes.
    • RAID 1 mirrors; RAID 0 has no redundancy.
    • Every member gets the same bad write.
    • Say “RAID is not a backup”.
  5. A Windows box fails at login after a patch. Where do you look before you wipe it?

    The strongest answer: Event Viewer for the time of the failure, the patch log, and whether it is one box or many — wipe is a last write

    Why it works: Exactly. Time, patch, scope. Images are expensive hypotheses.

    • Logs and scope before wipe.
    • Match the failure time.
    • Do not fleet-rollback on one box.
    • Do not disable logging to look clean.
  6. You have a PowerShell command that will act on every account matching a filter. How do you check it before it runs for real?

    The strongest answer: Run the filter on its own and read the list it returns, then use -WhatIf on the command that changes things so it prints what it would do, then run it against one test account first

    Why it works: Right. The filter is where the mistake usually is, and one test account catches what the preview cannot.

    • Check the filter before the action.
    • Read the list it returns.
    • Preview the change with -WhatIf.
    • Run one test account first.
  7. A Linux user cannot write a share. You can. First read?

    The strongest answer: User, groups, mode, mount options, and whether they are who they think they are — I do not chmod 777 to test

    Why it works: Exactly. Identity then bits then mount. 777 is a hallway with the lights off.

    • Read identity, mode, mount.
    • No 777 tests.
    • Do not casual-chown.
    • Do not add root to “help.”
  8. A laptop blue-screens during boot right after a graphics driver update. What do you try before reimaging?

    The strongest answer: Get into the Windows recovery environment, start in Safe Mode, and roll back or uninstall that driver; if that fails, a System Restore point from before the update

    Why it works: Exactly. The recovery environment is the way in, and the driver you just changed is the first thing to undo.

    • Undo the change before you wipe.
    • Boot into the recovery environment.
    • Safe Mode, then roll back the driver.
    • System Restore if a point exists.
  9. An app needs a privileged action on 30 laptops. Better pattern?

    The strongest answer: A managed install, a privileged helper, or a group that the app actually needs — not local admin on 30 pets

    Why it works: Exactly. Package the privilege. Wikis of admin passwords are a museum of regret.

    • Package the privileged action.
    • No shared local-admin secrets.
    • No Domain Admin for an app.
    • Do not rely on a walk-up ritual.
  10. MFA device lost. User is travelling. What is the bar?

    The strongest answer: A stronger identity check than a password reset, a recorded exception, and a new factor they control — I do not email a bypass code to the ticket CC

    Why it works: Exactly. MFA reset is the keys. Record it. CC is not a safe channel.

    • Stronger check than a password reset.
    • Record the exception.
    • Do not mail bypass codes to a CC.
    • Do not disable MFA for everyone.
  11. Starting a service returns an error and it stays dead. Talk me through your next few steps.

    The strongest answer: The unit’s status for the exit code and last lines, the journal for that unit since boot, then the config it loads — usually a bad path, a permission, or the port already in use

    Why it works: Exactly — status, journal, then the config it reads. Those three cover almost every failed start.

    • Status, journal, config — in that order.
    • Read the exit code and last lines.
    • Check path, permission, port in use.
    • Auto-restart is not a diagnosis.
  12. Backups are “green” every night. What is still missing?

    The strongest answer: A restore you have actually done — a file, a mailbox, a box — green jobs can write junk forever

    Why it works: Exactly. Restore is the product. Green is a heartbeat, not a resurrection.

    • Test restores, not only jobs.
    • Green ≠ recoverable.
    • Retention ≠ a test.
    • Do not store the key beside the backup note.

3–5 years

  1. A new SaaS wants its own password file. What do you push for?

    The strongest answer: SSO into your identity provider, with groups you already review — a second password pile is a second incident pile

    Why it works: Exactly. One identity, reviewed groups. Later-tidy is how you get shadow tenants.

    • SSO to the IdP you review.
    • No spreadsheet directories.
    • No shared SaaS passwords.
    • No souvenir team tenants.
  2. How do you know backups are a product, not a light?

    The strongest answer: A scheduled restore drill with a named owner and a leftover sentence — green jobs without a calendar are décor

    Why it works: Exactly. Drills make leftovers visible. Words like immutable are claims to test.

    • Calendar a restore drill.
    • Name an owner and a leftover.
    • Vendor words are claims.
    • Do not assume the cloud cannot lose mail.
  3. Full, incremental and differential — what changes about the restore?

    The strongest answer: A differential holds everything since the last full, so a restore needs the full plus the latest one. An incremental holds only what changed since the previous backup, so a restore needs the full plus every incremental since

    Why it works: Exactly. The trade is backup window against restore chain, and it is the restore chain that bites during an outage.

    • The trade is window versus restore chain.
    • Differential: full plus the latest one.
    • Incremental: full plus all of them.
    • Walk the chain before you need it.
  4. A phishing wave is hitting many inboxes. Beyond individual resets?

    The strongest answer: Block the campaign, hunt who entered secrets, tell people what to look for now, and fix the mail path that let it through — a single reset is not a wave plan

    Why it works: Exactly. Block, hunt, warn, fix the path. Shame and pretty reports help the next wave.

    • Block, hunt, warn, fix the path.
    • Do not roast clickers.
    • Do not turn mail off as a plan.
    • Do not hide the wave.
  5. A department head asks you to switch on a Microsoft 365 feature for their team this afternoon. What do you check before you say yes?

    The strongest answer: Whether the licences they already hold include it, how many spare licences the tenant has, what an upgrade would cost, and who approves that spend — then I come back with a date rather than a promise in the corridor

    Why it works: Exactly. Entitlement, spare capacity, cost and approval — and the date is what turns you into someone who can be planned around.

    • Check entitlement before you promise.
    • Count the spare licences.
    • Price the upgrade, name the approver.
    • Answer with a date, not a yes.
  6. What is a change advisory for, and what is it not?

    The strongest answer: To make blast radius, rollback, and who is awake explicit — not to collect signatures as theatre or to block tiny user fixes

    Why it works: Exactly. Awake people and a way back. Theatre and blanket-no both fail.

    • Blast, rollback, who is awake.
    • Not signature theatre.
    • Not a blanket no.
    • Not only after incidents.
  7. How do you find standing admin that nobody needs?

    The strongest answer: A recurring access review with managers who can say no, plus logs of use — I do not wait for an incident to notice a ghost admin

    Why it works: Exactly. Reviews and use. Friday mass-removals are how you earn a reputation for outages.

    • Recurring reviews + use logs.
    • Managers must be able to say no.
    • Do not Friday-strip as sport.
    • Do not assume leavers are clean.
  8. A workstation is beaconing like malware. First network move?

    The strongest answer: Isolate it — VLAN, wireless kick, or cable pull — then image-preserving forensics you are allowed to do; I do not keep it on “to watch”

    Why it works: Exactly. Pull it off the peers. Watching on the LAN is a lab you did not set up.

    • Isolate first.
    • Preserve if you can.
    • Do not watch on the LAN.
    • Do not reboot away evidence.
  9. Identity is down for the company. What roles do you name in the first ten minutes?

    The strongest answer: A commander, a tech lead, and a comms person — one throat for decisions, one for the work, one for the words

    Why it works: Exactly. Three jobs. A scrum of voices is how you lose twenty minutes.

    • Commander, tech, comms.
    • One decision throat.
    • Do not all-talk.
    • Do not leave comms empty.
  10. The policy works on every other laptop on the floor, and the user swears they have restarted.

    A Group Policy you linked is not taking effect on one laptop. How do you diagnose it?

    The strongest answer: Read the resultant policy on that machine to see what applied and what was filtered, then check which OU the computer object is really in, whether the setting is computer or user side, and security filtering, inheritance blocks and enforcement

    Why it works: Exactly. The resultant-policy report tells you whether it was never delivered or delivered and overridden — those are different faults.

    • Ask what actually applied, not what you linked.
    • Read the resultant policy on the machine.
    • Check the OU, and computer versus user.
    • Then filtering, inheritance, enforcement.
  11. What makes a runbook real?

    The strongest answer: An owner, a last-tested date, and a path that an on-call followed recently — a wiki novel from 2021 is décor

    Why it works: Exactly. Used and dated. Novels and farewell videos are museums.

    • Owner + last-tested date.
    • Someone on-call has followed it.
    • Pretty ≠ real.
    • Do not rely on a leaver’s video.
  12. An onboarding script stopped half-finished when the network dropped. The technician is about to run it again from the top.

    What should the script already do?

    The strongest answer: Check before it changes anything, skip what is already in place, and log what it did and did not do — so a second run finishes the job instead of creating a second mailbox and a duplicate group

    Why it works: Exactly. Check-then-change plus a log of what it skipped is what makes a half-finished run recoverable.

    • Check before you change.
    • Every step safe to repeat.
    • Log what was skipped and why.
    • There is no rollback to lean on.

5+ years

  1. Three directories, three “sources of truth.” What do you standardise?

    The strongest answer: One joiners/movers/leavers throat and which system is authoritative for which fact — I do not standardise every GUI skin

    Why it works: Exactly. Authority and JML. Pretty GUIs and fourth syncs are how you get a fifth.

    • One JML throat; name authoritative facts.
    • Do not buy a GUI.
    • Do not add a fourth sync.
    • Spreadsheets are not a directory.
  2. Staff are signing in to company mail and files from personal laptops at home. Files are leaving the managed fleet and nobody can say where they have gone.

    What do you put in place?

    The strongest answer: Make access conditional on the device being managed and meeting a policy — encryption, patch level, screen lock — with the browser without downloads for personal devices. The rule belongs at sign-in, not in a handbook

    Why it works: Right — a rule enforced at sign-in is the only one that holds, and the browser-without-downloads path is what makes it liveable.

    • Enforce the rule at sign-in.
    • Require managed and compliant devices.
    • Give personal devices a safe path.
    • Handbooks are not controls.
  3. The board asks if we can “restore everything.” Your sentence?

    The strongest answer: What we have restored in a drill, to what point in time, and what we have never tried — I do not say yes to “everything”

    Why it works: Exactly. Drilled, point-in-time, untested leftover. Vendors and clouds are not a spell.

    • Say drilled / point-in-time / untried.
    • Do not say “everything.”
    • No vendor-as-yes.
    • No invented percentile.
  4. What does a senior IT person change besides filters?

    The strongest answer: How easy it is to report, how people are treated when they do, and whether leaders click the same tests — filters without culture leak

    Why it works: Exactly. Reporting must be safe and easy. Rankings and invented cuts are how you teach silence.

    • Easy, safe reporting.
    • Leaders take the same tests.
    • No public clicker ranks.
    • No invented training %.
  5. Your change policy is unread. What do you cut it to?

    The strongest answer: What needs a window, what is standard, what is emergency, and who can say go — a novel nobody opens is not a policy

    Why it works: Exactly. Operable categories. Signatures and RACIs are how you fake control.

    • Window / standard / emergency / who.
    • Cut the novel.
    • Do not add signature theatre.
    • Do not run on vibes.
  6. Everything the company runs sits on two virtualization hosts, both at about 80% memory. Both domain controllers are on the same host.

    What do you argue for?

    The strongest answer: Enough spare capacity that one host can fail and everything still runs, and rules that keep paired services on separate hosts — starting with splitting the two domain controllers, which costs nothing and can be done this week

    Why it works: Right — and leading with the free half of the fix is what gets the paid half funded.

    • Capacity to lose one host.
    • Do not count headroom you cannot use.
    • Split paired services across hosts.
    • Lead with the free fix.
  7. What does least privilege look like as a program, not a slogan?

    The strongest answer: Default-deny grants, expiring exceptions, reviews managers finish, and a backlog to remove standing admin — a poster is not a program

    Why it works: Exactly. Defaults, expiry, finished reviews, a backlog. Slogans and fake percents are décor.

    • Defaults, expiry, finished reviews, backlog.
    • Posters ≠ a program.
    • Do not neuter the desk.
    • No invented zero-trust %.
  8. You will be the incident commander for a company-wide identity outage. What do you refuse to do yourself?

    The strongest answer: The deep technical fix — I keep time, decisions, and comms; I pull a tech lead so I am not typing and commanding

    Why it works: Exactly. Command is a job. Hands on the keys make you late and mute.

    • Command ≠ typing the fix.
    • Name a tech lead.
    • Own the comms clock.
    • Do not wait for a perfect RCA.
  9. The team’s automation lives in a folder on one technician’s laptop, runs under their own account, and nobody else knows which scripts still matter.

    What do you change?

    The strongest answer: A repository with an owner and review, run from a server under a service account with least rights, each script carrying a purpose and a review date — and anything nobody can explain gets switched off and watched

    Why it works: Right. Ownership, an identity that is not a person, and a way to retire the unexplainable — that is what turns scripts into a service.

    • Automation needs an owner.
    • Repository, review, stated purpose.
    • Run under a service identity.
    • Retire what nobody can explain.
  10. Legal asks for the story of an access change. What should already exist?

    The strongest answer: Tickets with asker, approver, artefact, and time — I do not reconstruct from chat folklore the week of a demand

    Why it works: Exactly. Build the trail in peacetime. Memory weeks are how you fail a simple question.

    • Peacetime tickets: who / approve / artefact / when.
    • Do not reconstruct from chat.
    • Do not raid private messages as the plan.
    • Trust ≠ “we have no logs.”
  11. An auditor asks who added an account to a privileged group four months ago. That laptop was reimaged in March.

    Every Windows log lives only on the machine that wrote it, and machines get reimaged. What do you build, and what do you collect?

    The strongest answer: Central collection off the endpoints with a retention the business has agreed to, carrying sign-in successes and failures, account and group changes, service installations and PowerShell activity — the rest is noise you pay to store

    Why it works: Right — off the box, kept for an agreed period, and deliberately scoped. A chosen subset you can search beats everything you cannot afford.

    • Logs must outlive the machine.
    • Collect centrally, retain by agreement.
    • Scope it: sign-ins, accounts, services.
    • Noise you cannot afford is not coverage.