IT operations Interview Questions

Note: Operations interviews reward specifics about scale and consequence. "I supported the infrastructure" says nothing; "I was on call for 40 servers supporting 1,200 users, with a four-hour recovery objective" says everything.

Cover:

• The estate. How many servers, users, sites, and applications. On-premises, cloud, or hybrid.
• Your scope. Whether you owned the systems or supported someone who did. Be honest — this is easy to test with follow-up questions.
• The service commitments. Uptime targets, support hours, and recovery objectives. Working to a defined SLA is a different discipline from best-effort support.
• What you improved. Strong candidates: automating a manual build process, introducing monitoring where there was none, cutting ticket volume by fixing a root cause, or completing a migration without downtime.

Numbers matter here more than in most interviews — ticket volume, uptime achieved, time saved.

Tell it as a timeline, and separate the technical work from the coordination work — the second is what distinguishes senior operations people.

• Detection and initial assessment. How you found out, and how quickly you established scope: who is affected, how badly, and is it getting worse.
• Communication, started early. Notifying stakeholders and setting an update cadence before you have answers. Silence during an outage causes more damage than the outage.
• Restore service before finding the cause. Failing over, rolling back, restarting, or activating a workaround. Root cause analysis is for afterwards.
• The diagnosis and fix, and how you verified recovery rather than assuming it.
• The post-incident review. What the root cause was, what the contributing factors were, and the specific actions taken so it cannot recur.

Note: Naming an incident command structure — someone owning the technical fix, someone owning communication — is a strong signal. So is describing a blameless review, because it shows a culture where people report problems early rather than hiding them.

Give a framework, since triage under pressure is the core operational skill.

Prioritise on impact and urgency together:

• Scope of impact. An entire site down beats one user with a broken printer, regardless of who is shouting loudest.
• Business criticality. The system that processes revenue outranks the internal wiki. Knowing which systems are critical before an incident is what makes this fast.
• Is it getting worse? A disk filling up outranks a stable failure, because the window to act is closing.
• Is there a workaround? A severe problem with a viable workaround can wait behind a moderate one with none.
• Security incidents jump the queue, because the cost of delay compounds.

The management part: delegate what others can handle, communicate expected timelines to everyone waiting so they stop chasing, and escalate early rather than when it is already too late.

Note: Mentioning that you look for the common cause when several tickets arrive together is a good detail. Five unrelated-seeming issues at once are usually one underlying failure, and recognising that saves hours.

The skill is de-escalation without over-promising.

• Acknowledge the impact first, before explaining anything. People need to know you understand what it is costing them. Leading with technical detail reads as deflection.
• Never be defensive, even when the cause is on their side. Assigning blame during an incident helps nobody.
• Give a realistic timeline, or say honestly that you do not have one yet and commit to an update time. "I do not know the cause yet, I will update you at 3pm" is far better than an optimistic estimate you will miss.
• Offer a workaround where one exists. Partial function restored buys enormous goodwill.
• Follow up after resolution to confirm it is genuinely fixed and explain briefly what happened.

Note: The strongest version of this answer includes recognising when frustration is legitimate — the same problem recurring, or a known issue never fixed. In that case the right response is to escalate for a permanent fix rather than to manage the person's feelings. Interviewers value someone who advocates for users rather than only placating them.

Documentation is where operations teams most commonly fail, so a considered answer stands out.

• Write it for the person on call at 3am, not for an audit. Runbooks with exact commands, expected output, and what to do when it does not match. Prose explaining the architecture is separate and less urgent.
• Document at the moment you solve something. A fix written up while fresh takes ten minutes; reconstructed six months later it takes an hour or never happens.
• Keep it where people look. A wiki nobody opens is worse than nothing because it creates false confidence. Linking runbooks directly from alerts is the single most effective practice.
• Test the documentation. Have someone unfamiliar follow the runbook. Gaps surface immediately.
• Prune aggressively. Out-of-date documentation actively causes incidents.

On knowledge sharing: rotate who handles which type of ticket so knowledge does not concentrate in one person, review incidents as a team, and treat any system only one person understands as a risk to be scheduled away.

Note: Saying you would rather automate a procedure than document it — because automation cannot go stale unnoticed — is a strong closing point.

ITIL is a framework of best practices for IT service management, organising operations around defined processes with clear ownership and measurement.

The three terms are distinct and routinely confused:

• Incident — an unplanned interruption or reduction in service quality. The goal is to restore service as quickly as possible, by any means, including a workaround. Fixing the underlying cause is explicitly not the objective. "The email server is down."
• Problem — the underlying cause of one or more incidents. The goal is to find and eliminate the root cause, which is investigative work done on a longer timescale. "Email goes down every Monday because the backup job exhausts memory."
• Change — any addition, modification, or removal that could affect services. The goal is to make changes with minimum risk, through assessment, approval, scheduling, and a rollback plan.

Why the distinction matters practically: incidents are measured on speed of restoration, problems on preventing recurrence. A team that only does incident management fixes the same thing forever — high ticket volume with no improvement. Recognising that pattern is what problem management exists for.

Note: Change types are worth knowing: standard (pre-approved, low risk, such as a routine password reset), normal (assessed and approved by a change advisory board), and emergency (expedited to fix an incident, reviewed afterwards).

RTO (Recovery Time Objective) — how long you can afford to be down. It drives your recovery infrastructure.

RPO (Recovery Point Objective) — how much data you can afford to lose, measured in time. It drives your backup frequency. An RPO of one hour means backing up at least hourly.

Both are business decisions, not technical ones. The cost rises steeply as either approaches zero, so the conversation is about what an hour of downtime or an hour of lost data actually costs.

Designing the strategy:

• The 3-2-1 rule — three copies of the data, on two different media types, with one off-site. It survives hardware failure, site loss, and most ransomware.
• Match backup type to RPO. Full backups are simple to restore but slow and large; incremental are fast to take but slower to restore; differential sit between. A common pattern is weekly full plus daily incremental.
• Immutable or air-gapped copies. This is now essential — ransomware specifically targets backups, and a backup an attacker can delete is not a backup.
• Retention aligned to legal and regulatory requirements, not to disk convenience.

Note: The point to emphasise above all: an untested backup is not a backup. Restore drills on a schedule, timed against the RTO, are what turn a backup policy into a recovery capability. A great many organisations discover their backups were unusable only when they need them.

Work methodically from the symptom outwards rather than guessing.

First, define the problem precisely: who is affected, since when, is it one application or everything, one site or all, and what changed recently. "Everything is slow" and "one application is slow for one office" have entirely different causes.

Then check the resource layers on the server:

• CPU — top or htop. High load average relative to core count, and whether one process dominates.
• Memory — free -h. The critical thing is swap usage; a server swapping is catastrophically slow, and this is often the real answer.
• Disk — iostat and df -h. High I/O wait, or a full filesystem. A full /var from unrotated logs is a classic.
• Network — netstat or ss for connection counts, and interface error counters.

For network problems specifically: ping for reachability and latency, traceroute or mtr to find where latency appears, and DNS resolution time — slow DNS presents exactly like a slow network and is a very common cause.

Note: Two points that impress. First, check monitoring history to see whether this is new or normal, rather than judging from a single snapshot. Second, always ask what changed — a recent deployment, a patch, or a configuration edit explains far more incidents than genuine capacity exhaustion.

Active Directory Domain Services is Microsoft's directory service — a central database of users, computers, groups, and other objects, providing authentication and authorisation across a Windows network. It means one identity instead of a separate account on every machine.

The structure:

• Forest — the top-level security boundary, containing one or more domains.
• Domain — an administrative boundary with its own policies and its own directory partition.
• Organisational Unit (OU) — a container for organising objects, and the unit that Group Policy and delegated administration are applied to.
• Domain Controller — a server hosting the directory and handling authentication, using Kerberos.

Group Policy Objects (GPOs) apply configuration centrally to users and computers: security settings such as password policy and account lockout, software deployment, mapped drives, firewall rules, and desktop restrictions. They are what makes managing thousands of machines feasible.

How GPOs apply — remembered as LSDOU: Local, then Site, then Domain, then OU, with later ones overriding earlier. gpupdate /force forces a refresh and gpresult /r shows what actually applied, which is the first troubleshooting step.

Note: Design OUs around how you administer and apply policy, not around the company org chart. Mirroring the org chart is a common mistake that makes policy application awkward as the organisation reshuffles.

DHCP assigns IP configuration — address, subnet mask, gateway, and DNS servers — to devices automatically through a lease. Without it every device needs manual configuration.

DNS resolves names to addresses. A client asks its configured resolver, which either answers from cache or walks the hierarchy from root to top-level domain to authoritative server.

The record types worth knowing:

• A — name to IPv4 address. AAAA — to IPv6.
• CNAME — an alias pointing to another name.
• MX — mail servers, with priority values.
• TXT — arbitrary text, used for SPF, DKIM, and domain verification.
• NS — the authoritative name servers for a zone.
• PTR — reverse lookup, address to name.

Troubleshooting name resolution, in order:

• Can you reach the IP directly? If yes, it is definitively DNS, not connectivity.
• nslookup or dig against the configured resolver, then against a public one such as 8.8.8.8. A difference means an internal DNS problem.
• Check the client's configured DNS servers — ipconfig /all or resolv.conf. Pointing at a public resolver instead of the domain controller breaks internal name resolution and is a very common misconfiguration.
• Flush the cache — ipconfig /flushdns — since stale entries persist after a record changes.
• Check TTL when a record was recently changed; propagation is really cache expiry.

Patch management balances security against stability, and needs a defined process rather than ad hoc updating.

• Maintain an inventory. You cannot patch what you do not know you have, and unknown systems are where breaches start.
• Categorise by risk. Critical and actively exploited vulnerabilities get an expedited path; routine updates follow the normal cycle.
• Test in rings. A pilot group, then a wider group, then production. This catches the patch that breaks a line-of-business application before it breaks everyone's.
• Schedule a maintenance window with communication and a rollback plan — including a snapshot or backup taken immediately before.
• Verify and report. Compliance reporting shows what remains unpatched and why.

Hardening reduces the attack surface:

• Remove what is not needed — unused services, default applications, and open ports. The most reliable security measure is absence.
• Change every default credential, and disable default accounts.
• Least privilege — users are not local administrators, and service accounts get only the rights they need.
• Enable host firewall and disk encryption, enforce secure protocols, and disable legacy ones such as SMBv1 and TLS 1.0.
• Centralise logging so evidence survives the compromise of the host.

Note: Cite a baseline standard such as CIS Benchmarks. Working to a published benchmark rather than personal preference is what makes hardening auditable.

Virtualisation runs multiple isolated systems on one physical host through a hypervisor, which allocates CPU, memory, storage, and network to each guest. Type 1 hypervisors — ESXi, Hyper-V, KVM — run directly on hardware; Type 2 run on a host operating system.

The operational benefits are consolidation (better hardware use), isolation, snapshots for safe rollback, and live migration allowing hardware maintenance with no downtime.

Virtual machines versus containers:

• A VM virtualises hardware. Each has its own complete guest operating system, so it is heavy — gigabytes, and tens of seconds to boot — but strongly isolated and able to run any OS.
• A container virtualises the operating system. Containers share the host kernel and package only the application and its dependencies, so they are megabytes and start in under a second. Isolation is process-level, which is weaker than a hypervisor boundary.

How to choose: VMs for running different operating systems, for legacy applications, and where strong isolation is a security requirement — such as multi-tenant workloads. Containers for application deployment, microservices, and anywhere consistency between development and production matters.

Note: They are complementary rather than competing. In practice containers usually run on VMs — a Kubernetes cluster is typically a set of virtual machines — combining the isolation of one with the density and portability of the other.

Monitor at layers, because a symptom at one level usually has a cause at another:

• Infrastructure — CPU, memory, disk space and I/O, network throughput and errors, and hardware health.
• Service — is the process running, is the port listening, is the certificate about to expire, is the backup job succeeding.
• Application — request rate, error rate, and response time percentiles.
• End-user experience — synthetic checks that perform a real transaction from outside your network. This catches what internal monitoring misses entirely.
• Logs — centralised, so evidence survives the failure of the host that produced it.

Alerting is where most teams go wrong. The principles:

• Alert on symptoms, not causes. Alert that the site is returning errors, not that CPU is at 80%. High CPU with everything working is not an incident.
• Every alert must be actionable and have a documented response. An alert nobody acts on trains people to ignore all alerts, which is worse than no monitoring.
• Use severity tiers. Page for something that needs waking someone; email or ticket for what can wait until morning.
• Use trends for capacity. Alerting when a disk will be full in five days beats alerting when it is full.

Note: Naming alert fatigue as the main failure mode, and reviewing alerts periodically to delete noisy ones, is exactly what experienced operations people say.

Least privilege means every user, account, and process gets the minimum access needed to do its job, and no more. It limits both accidental damage and the blast radius of a compromised account.

How to implement it:

• Role-based access control. Define roles matching job functions, assign permissions to roles, and users to roles. Never assign permissions to individuals — it becomes unmanageable and unauditable within months.
• Separate administrative accounts. Administrators get a normal account for daily work and a separate privileged account used only for administrative tasks. Browsing email as a domain administrator is how domains fall.
• Just-in-time elevation. Privileged access granted temporarily and automatically revoked, rather than standing rights.
• Service accounts with only the specific rights required, non-interactive logon, and managed or rotated credentials.

The lifecycle is where this usually fails:

• Joiners — provisioned from a role template, not by copying an existing user's access. Copying is how permissions accumulate across an organisation.
• Movers — old access removed when someone changes role. Privilege creep from people who have moved teams three times is a real and widespread risk.
• Leavers — disabled immediately, ideally automatically from the HR system.
• Periodic access reviews where managers confirm their team's access is still appropriate.

RAID combines physical disks for redundancy, performance, or both.

• RAID 0 (striping) — data split across disks. Fast, full capacity, and no redundancy at all: one disk failing loses everything. Only for scratch data you can recreate.
• RAID 1 (mirroring) — identical copies on two disks. Survives one failure, gives fast reads, but costs 50% of capacity.
• RAID 5 (striping with distributed parity) — survives one disk failure, with the capacity of n-1 disks. The concern is rebuild time: on large modern drives a rebuild takes many hours under full load, and a second failure during it loses the array.
• RAID 6 — dual parity, surviving two simultaneous failures. The sensible choice for large arrays precisely because of the rebuild risk.
• RAID 10 — mirrored pairs, striped. Best performance and fast rebuilds, at 50% capacity cost. Standard for databases.

Capacity planning: baseline current usage, measure the growth rate over several months rather than guessing, project forward, and add headroom — filesystems degrade well before 100%, and 80% is a common trigger point. Plan procurement lead time into the threshold, so the alert fires early enough to actually order hardware.

Note: The essential point: RAID is availability, not backup. It protects against disk failure only — not deletion, corruption, or ransomware, all of which replicate instantly across every disk in the array.