Systems Administrator interview questions and answers

"A user cannot log in to their computer on the domain. How do you troubleshoot?"

Start with the simplest explanations and the ones that affect only this user. Is the account locked or disabled, or has the password expired? Is Caps Lock on? Then widen the search. Can other users log in on the same computer? Does the computer reach the network and a domain controller?

Then mention the less obvious causes that show experience. DNS may point at the wrong server, so the domain controller cannot be found. The clock may have drifted far enough to break Kerberos authentication, or the trust relationship between the computer and the domain may be broken. Say how you would confirm each, such as checking the event logs.

"A Linux server's disk is full. What do you do?"

First, restore service without deleting anything important. Use df -h to confirm which file system is full, then du -sh on its directories to find what is growing. Log files under /var/log and old backup archives are common culprits. Compress or move old logs, or clear space you are certain is safe to remove.

Then fix the cause. Configure log rotation if it is missing, add monitoring that alerts well before the disk fills, and plan more storage if the growth is genuine. Note that a deleted file keeps using space while a process holds it open, which lsof helps you find.

"Explain your approach to backups."

Describe a strategy rather than a product. Decide what must be protected, and how much data loss and downtime the organisation can accept for each system. Choose backup types and schedules that meet those targets, keep copies off-site or in a separate cloud account, and follow the 3-2-1 principle.

Then say the most important sentence: a backup that has never been restored has not been proven. Describe testing restores on a schedule and recording the results.

"How do you keep servers patched without breaking things?"

Explain a routine. Updates are reviewed when released, applied first to test or less critical systems, then rolled out to production in a maintenance window. Before patching an important server, take a snapshot or confirm a recent backup exists. Afterwards, check that services started and applications work.

Add how you handle urgent security patches, which may need to skip part of the cycle, and how you track which servers are up to date.

"What do you do when you set up a new server?"

Talk about hardening. Apply all updates, remove software and services that are not needed, and change default credentials. Configure the firewall to allow only the required ports, use SSH keys instead of passwords on Linux, and give administrator rights only to the named accounts that need them. Enable logging and monitoring, add the server to the backup schedule, and record it in the documentation.

"Tell me about a time a system failed and you were under pressure."

Use a real story with a clear shape: the situation, what you did, and the outcome. Panels listen for whether you kept users and managers informed during the outage, whether you worked methodically instead of trying random fixes, and whether you followed up afterwards to prevent a repeat.

If the honest answer includes a mistake, include it and explain what you learned. That is more convincing than a story in which everything went perfectly.

"How do you manage administrator access?"

Give each administrator a named account instead of sharing one password, and keep day-to-day work on a normal account, using elevated rights only when needed. Require multi-factor authentication for privileged access, review who holds administrator rights regularly, and remove access promptly when people change roles or leave.