TL;DR
- System administrator interviews reward a clear troubleshooting sequence: establish impact, collect evidence, narrow the fault and verify recovery.
- Distinguish a running process from a working user journey, and distinguish free disk capacity from the ability to create another file.
- Explain identity and configuration changes with a recovery path, especially when changing remote access to the machine you are using.
- A backup is useful only if the required data and dependencies can be restored within the business's recovery expectations.
Start with the environment and the user impact
“System administrator” can mean managing a Windows domain, a Linux fleet, mixed cloud infrastructure or a small organization's entire technical environment. Ask which operating systems, identity services, applications and operational responsibilities the role includes. If the role extends into cloud platforms and automation, also review DevOps and SRE interview questions covering infrastructure as code, observability and incident response.
The eight original questions below focus on general administration principles with a Linux and systemd troubleshooting example. They are not a universal interview script, and the example commands were checked against documentation rather than executed on a production server. Use them in a permitted lab with the service names and access appropriate to that environment.
A useful answer follows a repeatable sequence: describe who is affected, state what is known, name the next observation and explain what each possible result would change. This communicates more than reciting a long list of commands.
1. A service is unavailable. What do you check first?
Use this hypothetical incident: an internal invoice portal loads, but newly submitted invoices remain unprocessed. Establish when processing last worked, whether every customer is affected, whether old invoices are accessible and whether a deployment or configuration change occurred nearby.
The symptoms already narrow the investigation. The web page being reachable does not prove the background worker is running. A successful login does not prove the worker can reach its database or queue.
On a systemd host, these are example read-only starting points for a fictional service:
systemctl status invoice-worker.service --no-pager
systemctl show invoice-worker.service --property=ActiveState,SubState,ExecMainStatus
journalctl --unit=invoice-worker.service --since="30 minutes ago" --no-pagerstatus is intended for human inspection; show exposes named properties. Consult the systemctl manual for the installed version. The journalctl manual documents unit and time filters. Access to logs depends on the host's permissions and configuration.
Read the result before acting. A worker can be active while repeatedly failing a business operation. If logs show authentication failures after a credential rotation, restarting it several times will not explain which credential or permission is wrong.
2. How would you narrow the invoice-worker incident?
Build a small decision table rather than making several simultaneous changes. The following is an original investigation plan, not a record of a real outage.
| Observation | What it suggests | Next useful check |
|---|---|---|
| Worker unit failed immediately after deployment | Startup or configuration problem | First failure message and effective configuration |
| Worker active, queue age rising | Work is not completing fast enough | Processing rate, dependency latency and error categories |
| Only one tenant fails | Scope-specific data or authorization issue | Affected tenant's request and permission boundary |
| Database connection succeeds but writes fail | More than simple connectivity | Operation permissions, transaction errors and capacity |
| Recovery followed a credential rollback | Change-related cause is plausible | Confirm sustained processing and the exact permission difference |
Preserve a short timeline with consistent time zones. Avoid collecting secrets in an incident note; record identifiers and error categories instead of credentials or full sensitive payloads.
After a fix, submit or observe a representative permitted test transaction and confirm that it reaches the completed state. Also check whether the backlog drains and whether retries created duplicates. “The process is green” is weaker evidence than a restored business operation.
3. There is free disk space. Why can an application still fail to write?
Capacity has more than one dimension. The relevant filesystem may differ from the mount you inspected. A user or project quota may be exhausted. A filesystem may be read-only. File or directory permissions may prevent the operation. On filesystems that allocate a limited set of inodes, a very large number of small files can exhaust them while data blocks remain available. The GNU df manual distinguishes inode reporting from block usage.
Ask which exact path failed and which account attempted the write. Inspect the corresponding mount, capacity, inode availability where applicable, quotas and error message. Avoid treating every “cannot write” symptom as proof that the disk is full. Interviewers may then ask what an inode stores and how a filename maps to it; these operating systems interview questions on inodes and filesystems explain both.
Another useful distinction is between a deleted directory entry and storage still held by an open file. The Linux unlink documentation describes why the file can remain until the last relevant descriptor is closed. Investigate the process and its file handling before deciding how to release that space. A controlled service action may be appropriate after understanding impact; deleting more unrelated files is not a diagnosis.
For the interview, explain how retention, rotation and alerts would prevent recurrence. A one-time cleanup without identifying growth leaves the same incident waiting to happen again.
4. How do you distinguish DNS, network and application failures?
Start with the failing operation and its error. Name resolution, connecting to an address, negotiating TLS and receiving a valid application response are separate stages. Networking interview questions on DNS, TCP and TLS are a useful refresher on how each stage works.
Compare the failing client with a working one: resolver configuration, network location, requested hostname, destination address and time of failure. A hostname resolving does not prove that the intended service is reachable. A successful TCP connection does not prove that the certificate matches the requested hostname or that the application will authorize the request.
Use the tools approved for the environment to test one layer at a time. Keep the hostname and protocol context intact when investigating TLS; bypassing verification may hide the very configuration defect the user is experiencing.
If only one network path is affected, examine routing and filtering evidence. If every path reaches the service but one operation returns an application error, move the investigation upward. Explain why each observation changes the next step instead of repeatedly testing the same layer.
5. How would you change SSH access without locking yourself out?
First confirm an independent recovery method, such as a tested console path, and keep an existing authorized session available during the change. Back up the relevant configuration and identify which service manager and configuration files this host actually uses.
OpenSSH documents configuration validation with sshd -t and effective configuration output with sshd -T. Its daemon manual also explains how connection parameters can be supplied to evaluate applicable Match rules. These checks have different purposes from proving that a new user can successfully connect through the real network path.
After validating the intended change, apply it using the documented procedure for that operating system and test a separate new connection with the expected identity. Confirm both allowed and deliberately disallowed access cases before closing the recovery path.
Do not paste a generic restart command into an answer as though every distribution uses the same unit name. State how you would discover the actual service and how you would reverse a failed change.
6. What should an access review examine?
Begin with the person's role and required operations. Separate authentication, group membership and authorization to a particular resource. An account being valid does not mean it should administer every server or read every application's data.
For a departing employee, identify interactive accounts, remote access, application access and credentials or ownership associated with automation. Disabling one login may leave a separately issued token active. Follow the organization's approved offboarding process and preserve service continuity when transferring ownership.
For ongoing access, inspect excessive privileges, inactive accounts and exceptions that have no current owner. Explain how access is requested, approved, reviewed and removed. The objective is a manageable process with evidence, not a growing collection of one-off grants nobody remembers.
Use a concrete example in the interview: a support role needs to inspect job status but should not modify production billing data. Describe the boundary and how you would test it.
7. How do you know a backup can support recovery?
Clarify the business expectations first. How much data loss is acceptable, and how long can the service remain unavailable? Those questions shape backup frequency, retention, storage isolation and the restoration procedure.
For the invoice portal, the database alone may be insufficient. Recovery may also need object storage, encryption-key access, application configuration and a compatible application version. List those dependencies before declaring the backup complete.
Run a restoration exercise in an isolated environment, validate representative records and measure the time to a usable service. Check permissions and application behavior, not just whether the backup utility returned success. Record what was restored, from which point in time and which dependencies were required.
Also explain how the restore avoids accidentally sending emails, processing payments or connecting a recovered test system to production queues. Recovery rehearsal should prove readiness without creating a second incident.
8. How do you prioritize patching and operational work?
Balance the importance of the affected system, exposure, the nature of the issue, available mitigations and the consequences of downtime. A patch plan should include a representative test, a deployment window where needed, observability and a recovery method that is actually compatible with the change.
For a fleet, avoid treating a successful patch on one host as proof that every role is safe. Group systems by meaningful differences, stage the rollout and verify the functions each group provides. Configuration drift can make apparently identical machines behave differently.
Afterward, confirm the installed state and service health. Document exceptions with an owner and a review date. This makes the remaining risk visible instead of leaving a vague “we will patch later” note.
Rehearse with one incident and one change
Practise a five-minute explanation of the invoice-worker scenario and a five-minute explanation of the SSH change. Ask a partner to interrupt with new evidence, such as a working database connection but failing writes.
Use PhantomCodeAI during permitted preparation to refine how clearly you explain your decisions. Keep the answer anchored in observations, controlled changes and verification of the user's actual task.