System Administrator Interview Questions

"I started on the help desk at a mid-sized company, resetting passwords and fixing laptops. I kept asking the server team why things worked the way they did, and after a year they let me take on user accounts and group policy changes. In my current role I look after about forty Windows servers and a small VMware cluster for around six hundred users. I own patching, backups and Active Directory day to day, and I've written a fair amount of PowerShell to cut down the repetitive work. What I want next is a bigger estate where I can go deeper on automation and on proper change control, rather than being the one person who knows everything."

"The job ad talks about moving more of your servers onto virtual hosts and tidying up group policy, and that's exactly the kind of work I've enjoyed most. It's a chance to leave things cleaner than I found them. Before my first week I'd want to know three things. First, is there an up-to-date list of servers and what each one does? Second, when did someone last test a restore, and did it work? Third, how are alerts handled and who gets called out of hours? Those answers tell me where the risk sits, so I know what to learn first and what not to touch until I understand it."

"I try to be helpful without letting the day disappear. If someone comes over, I ask quickly whether they're blocked right now. If they are, like they can't log in before a client meeting, I help. If it can wait, I ask them to raise a ticket, or I log it for them while they're there, and tell them roughly when it'll be done. That way it's tracked, a colleague can pick it up if I'm busy, and we can see patterns in what people keep asking for. On my current team we also agreed blocks of focus time for project work, with someone else covering the queue, and that made a big difference to getting projects finished on time."

"One Monday morning nobody could open the finance application. The server was up and pingable, so I logged on and found the application service had stopped. It wouldn't restart and the event log said the service account's password was wrong. Someone had reset that account over the weekend after a security review, not knowing it ran a service. I posted a quick update to the finance team, set a new password, updated it on the service and got it running within about half an hour. Afterwards I made a list of every service account and what depends on it, put it in our documentation, and we moved the ones that supported it to managed service accounts so passwords rotate without anyone typing them."

"The basics are whether the server is up, CPU, memory, disk space and disk latency. Beyond that I check the services that matter: that key Windows services are running, that the application actually answers, and on domain controllers that replication is healthy. I also watch things that fail quietly, like backup jobs, certificates about to expire and disks that are slowly filling, because those hurt later if nobody notices. For paging, my rule is simple: wake someone only if users are affected now or will be before the morning, like a server down or a disk that will fill tonight. High CPU for five minutes on a batch server isn't a page, it's a ticket or nothing. Too many night alerts and people start ignoring them."

"First I'd scope it: is it everyone, one site, or one user, and are other servers fine? Then I'd work from the outside in. Does the name resolve to the right IP? Does the server ping? If it doesn't answer at all, I'd get on its console through the hypervisor or the server's remote management card, because that works even when the network doesn't. Once I'm on, I'd check the event logs, disk space, whether the Server service is running, and whether it's frozen by memory or CPU. I'd also ask what changed recently, like patches, a new policy or a firewall rule. Meanwhile I'd post a short update to users so the help desk isn't flooded, and once it's fixed I'd write up the cause."

"A manager deleted a whole project folder on the file server, and nobody noticed for three days. I first checked shadow copies, but they only went back two days, so I went to the nightly backups. The restore itself worked, but it took far longer than anyone expected because the backup was on slow storage and the folder held thousands of small files. I restored it to a separate location first, had the manager confirm it was the right version, then copied it back. What went well was that I didn't overwrite anything in a panic. What I changed afterwards was keeping more shadow copies on that server and writing down realistic restore times, so we stopped promising quick recoveries we couldn't deliver."

"I'd start from what the business needs: how much data it can afford to lose, which sets how often we back up, and how quickly each system must be back, which sets how we restore. A common rule is three copies of the data, on two kinds of storage, with one kept offsite. These days I'd also want one copy that's offline or can't be changed, so ransomware can't wipe the backups too. But a backup that has never been restored is just a hope. So I'd schedule restore tests: a few files every month, and a full server or database into an isolated network every quarter, timing how long it takes. And I'd make sure failed or skipped jobs raise an alert, not just a line in a report nobody reads."

"A snapshot isn't a separate copy of the VM. It freezes the original disk and writes new changes to a delta file, so it depends on that original disk and usually sits on the same storage. If the datastore fails or the disk gets corrupted, the snapshots go with it. Keeping them for days also hurts: the delta files keep growing, performance drops, and merging them back later can take a long time or fill the datastore. So I use snapshots as a short safety net, like right before a patch or an upgrade, and delete them once I know the change worked. Real backups go to separate storage, are kept on a schedule, and can be restored even if the host is gone."

"New starters took us about half an hour each: create the account, put it in the right OU, add the right groups, set up the home folder and mailbox. People forgot steps, so new staff often started without access to something. I wrote a PowerShell script that reads a CSV from HR and does all of it the same way every time. To test it, I first ran it against a test OU with made-up users and used the WhatIf switch on anything that changed existing objects. It logs every action to a file. The first real run was just two starters, and I checked each account by hand afterwards. Now it takes a couple of minutes, and the missing access tickets have mostly stopped."

"I'd use the Active Directory module and Search-ADAccount with the AccountInactive and UsersOnly switches and a ninety-day time span, then keep only enabled accounts and leave out the service accounts OU. Before changing anything, I export the list to a CSV so a manager or HR can check it, because the last logon date in AD can lag by days, some people are on long leave, and new accounts that haven't logged on yet can show up too. Then I run Disable-ADAccount with WhatIf to see what would happen, and only after the list is approved do I run it for real. I disable rather than delete, and usually move the accounts to a disabled users OU with a note of the date, so if someone comes back, it's a quick fix."

"We were upgrading the operating system on an old print server on a Saturday night, with a four-hour window. The upgrade finished, but half the printer drivers wouldn't load. Our plan said that if printing wasn't working two hours before the window closed, we'd roll back. I spent an hour on drivers and got some working, but at the agreed point we still had whole floors that couldn't print. So I stopped, reverted to the snapshot we'd taken before starting, tested printing, and told the change board it had failed and why. It was frustrating, but Monday morning was normal. Next time we built a new server alongside the old one and moved printers over in batches, which was far safer."

"A backup server started failing jobs, and the only person who'd set it up had left. Nothing was written down about which storage it used or how the credentials were stored, so I spent most of a day just working out how it was put together. Once it was fixed I wrote a one-page runbook: what the server does, where the backups land, which accounts it uses, how to check a job and how to do a restore. I also started a habit on our team that any change ticket isn't closed until the documentation is updated. It feels slow in the moment, but the next time something failed on that server, a colleague fixed it in twenty minutes using the page."

"First I'd read the advisory and work out exactly which servers run the affected component and which of those face the internet, because those are the urgent ones. If the vendor lists a workaround, like disabling a feature or blocking a port, I'd apply that straight away on the exposed servers. Then I'd raise an emergency change so the right people know and can approve it quickly. I'd patch a couple of less critical servers first, check they reboot cleanly and the apps work, then do the internet-facing ones that evening and the rest over the weekend. Finally I'd confirm every server shows the patch installed and send a short note saying what was done and what's left."

"I'd use a central tool like WSUS or Configuration Manager so updates are approved in one place and I get reports. After the monthly release, I'd read the notes for known problems, then approve updates to a test group that mirrors production. After a few days with no issues, a pilot ring of less critical servers gets them, and then production in agreed maintenance windows. Before each window I'd make sure backups are good, and for risky servers take a snapshot. Order matters, so clustered servers go one node at a time, and database and app servers go in an order that won't cause errors. Afterwards I check services and apps are running, then pull a compliance report and chase any servers that missed updates."

"I like change control when it's sized right. The point isn't the form, it's that someone else knows what I'm changing, when, and how I'll undo it. More than once a change review has caught a clash, like two teams planning work on the same system the same night. The best setups I've worked in had pre-approved standard changes for routine things like adding a user to a group, so nobody wastes time there. A quick fix with no ticket is only okay in a real emergency, when something is down and waiting would make it worse. Even then I'd tell my lead, log an emergency change as soon as it's stable, and make sure it gets reviewed."

"We had two old domain controllers on hardware that was out of support, and I replaced them with two new virtual ones. First I checked replication was healthy with repadmin and dcdiag, because moving onto a broken base just spreads the problem. I built the new servers, promoted them, and let replication settle. Then I moved the FSMO roles and pointed DHCP scopes and static servers at the new DNS addresses. The part people forget is everything hard-coded to the old IPs, so I searched configs and found printers and an app server still using them. Only after a week with no traffic hitting the old servers did I demote them properly and clean up DNS. Nobody noticed the move, which was the goal."

"When lots of VMs on one host slow down together, the problem is usually shared, so I look at the host, not inside the guests. A VM can show low CPU use while it's actually waiting for a physical core, so in VMware I'd check CPU ready time, and the equivalent counters on Hyper-V. Next I'd check whether the host is short of memory, because ballooning or host swapping makes guests slow while they look fine inside. Then storage: if the datastore latency is high, every VM on it suffers. Often one VM is the cause, like a backup or a runaway job hammering the disk. I'd move some VMs to another host to relieve it now, then fix the noisy one or rebalance the cluster."

"Live migration, called vMotion in VMware, moves a running VM from one host to another while it keeps working. Users don't notice, so I use it for planned work, like emptying a host before patching it. High availability is for unplanned failures. If a host dies, the cluster notices and starts that host's VMs on the surviving hosts. That's a restart, so the VMs go down for as long as it takes them to boot, and anything not saved is lost. Both need the cluster set up properly: storage the other hosts can reach, compatible CPUs for live migration, and enough spare capacity on the remaining hosts to take the load if one fails."

"Repeated lockouts almost always mean something is still using an old password, like a phone syncing mail, a mapped drive with saved credentials, a scheduled task or a service. I'd ask when they last changed their password, because it usually lines up. Then I'd look in the Security event log on the domain controllers, starting with the one holding the PDC emulator role, for event 4740, which records the lockout and the caller computer name. That tells me which machine is sending the bad attempts. If it's their own laptop, I check Credential Manager, mapped drives and scheduled tasks. If it's a mail server, it's usually a phone. Once I clear the stale password, I watch the account for a day to confirm it's fixed."

"Every domain-joined computer has its own account and password in Active Directory, and it changes that password on its own every so often. This error means the password on the machine no longer matches the one the domain holds. It often happens when a PC or VM is rolled back to an old snapshot or image, or when someone reset or deleted the computer object. To fix it, I log on with a local admin account and run Test-ComputerSecureChannel with the Repair switch and domain credentials, or Reset-ComputerMachinePassword. If that fails, I remove it from the domain and rejoin it. Because it's several users, I'd look for the common thing, like a batch of VMs restored from an old snapshot, and fix that process."

"I'd say no to Domain Admins, but yes to solving the actual problem. Domain Admins can do anything in the domain, including changing security settings and other admins' accounts, and that's a big risk for a password reset. Instead, I'd create or use a help desk security group and use Delegation of Control on the OUs where normal staff accounts live, giving that group only the right to reset passwords and unlock accounts. I'd leave out the OUs with admin and service accounts. Then I'd add my colleague to that group, test it with them, and write it down. They get what they need, I stop getting escalations, and nobody has more access than the job needs."

"A domain is the main boundary: it holds users, computers and groups, domain controllers replicate it, and people log on to it. Inside the domain, OUs are like folders. I use them to organise objects so I can link group policies to them and delegate admin work, for example letting a site's IT person manage only their site's computers. Security groups are different: they collect accounts so I can give access to things like a shared folder or an application. You can't give an OU permission on a file share, and a user can only sit in one OU but be in many groups. So my rule is OUs for policy and delegation, groups for access to resources."

"I'd go to an affected computer and run gpupdate /force, then gpresult /r, or gpresult /h for a full report. That shows which policies applied and which were filtered out, and often why. The common causes are scope: the policy is linked to an OU the computer isn't actually in, security filtering doesn't include it, a WMI filter doesn't match, or inheritance is blocked higher up. Another classic is putting a computer setting in a policy linked to an OU of users, or the other way round. If the policy is only missing on some sites, I'd check replication between domain controllers, because a DC that hasn't got the new policy yet will hand out the old one."

"There are five roles that only one domain controller can hold at a time. Two are forest-wide: the schema master and the domain naming master. Three are per domain: the RID master, which hands out pools of IDs for new objects, the PDC emulator and the infrastructure master. If a role holder dies, the PDC emulator is the one users notice first, because it's the main time source for the domain and it's involved in password changes and lockouts. The others can often wait a while. If the old DC can come back, I'd fix it and transfer the roles cleanly. If it's gone for good, I'd seize the roles onto a healthy DC, clean up its metadata, and make sure that old server is never switched back on."

"I'd treat it as ransomware until proven otherwise, so speed matters. On the file server I'd check open files and sessions to see which user account and which computer are modifying the files. I'd disable that account and pull that computer off the network, and if it's still spreading, take the share offline or disconnect the file server from the network rather than power it off, so we don't lose evidence in memory. Then I'd call our security lead and start the incident plan, because this needs a coordinated response. Next is scoping: which other shares and servers are hit, and are our backups untouched. Only once the source is cleaned and we know how it got in would I restore from backups taken before the infection."

"Share permissions only apply when someone connects over the network, while NTFS permissions apply whether you're local or remote. When both apply, the user gets the more restrictive of the two. A lot of teams keep share permissions simple, like authenticated users with change, and do the real control in NTFS, so there's one place to look. For the finance folder, I'd create a group for finance edit access, give it modify on the folder in NTFS, and add the finance team's group into it. I'd remove broad entries like domain users, and avoid giving anything to single users. Then I'd check with the effective access tab on a finance user and a non-finance user to prove it works."

"I start by keeping it small: only the roles and features the server needs, because everything else is more to patch and attack. I patch it fully before it goes live. Then I apply a security baseline, like the published Microsoft or CIS baselines, through group policy so it's consistent and doesn't drift. I make sure old protocols like SMB version 1 are off and the firewall is on with only the ports it needs. For access, I use LAPS so every server has a unique local admin password, limit who can log on over RDP, and use separate admin accounts rather than everyday ones. Finally it goes into patching, endpoint protection, backups and monitoring, with its security logs sent to our central log system."

"A 169.254 address means the PC broadcast a DHCP request, got no offer back, and gave itself an address. Since it's only one floor, I'd guess the DHCP server itself is fine, and I'd check that other floors are getting addresses. Then I'd open the DHCP console and look at the scope for that floor's subnet. If it's full, the fix might be shortening the lease time or finding what's eating the addresses. If the scope has room, the next suspect is the network: the DHCP relay on that floor's router interface, or a switch problem. I'd ask the network team whether anything changed on that floor. Once it's fixed, I'd have a user run ipconfig /renew to confirm they get a proper address."

"Domain-joined machines don't have a list of domain controllers built in. They ask DNS for special SRV records that say which servers offer logon and directory services, and domain controllers register those records themselves. If a PC is pointed at a public DNS server, even as the second choice, it can't see those internal records, so logons get slow or fail, joining the domain fails and group policy stops applying. The right setup is that every domain machine uses only internal DNS servers, usually the DCs, and those servers forward other names to the internet. When I suspect DNS, I use nslookup to check the SRV records resolve, and dcdiag with the DNS test on the domain controllers."