5 exercises — choose the best-structured answer to common Linux Systems Administrator interview questions. Focus on precise vocabulary, correct use of technical terms, and demonstrating real diagnostic discipline.
Structure for Linux Sysadmin interview answers
Work in layers: interface → routing → DNS → reachability → port → firewall, not straight to conclusions
Name the exact command and flag: lsof +L1, df -i, systemd-analyze verify
Explain the underlying mechanism: why du misses an open-but-deleted file, why ICMP blocked doesn't mean unreachable
Separate stopgap from permanent fix, and describe removing the stopgap only after verification
0 / 5 completed
1 / 5
The interviewer asks: "A process is consuming high CPU. Walk me through how you would diagnose it." Which answer best demonstrates practical process-management expertise?
Option B is strongest: it starts with a live view but immediately checks process state, correctly identifying that D-state points to I/O contention rather than CPU work — a distinction many candidates miss — then layers in niceness, thread-level breakdown, and perf profiling for genuine deep diagnosis, and closes with a careful termination policy (SIGTERM before SIGKILL, with the specific reason SIGKILL is risky) plus a permanent fix (renice/cgroups) rather than repeated killing. Key structure: live view + state check (D-state = I/O, not CPU) → niceness and parent/child check → thread-level breakdown → perf profiling → SIGTERM-before-SIGKILL policy with reasoning → permanent fix via renice/cgroups. Option C covers the same tools accurately and concisely but omits the crucial D-state distinction that redirects the whole diagnosis. Option D jumps to a specific root-cause assumption (infinite loop/GC) without the systematic diagnostic process the question is actually testing for.
2 / 5
The interviewer asks: "How does systemd manage services, and how do you debug a service that fails to start?" Which answer best demonstrates systemd expertise?
Option B is strongest: it explains the unit file's three sections precisely, distinguishes Requires= from After= with the specific misconfiguration risk of conflating them (a genuinely common real-world systemd bug), gives a layered debugging sequence (status → journalctl -u -b → journalctl -xe) with the reasoning for each step, names specific concrete root causes to check (ExecStart path, User permissions, dependency target not actually ready), and adds a proactive syntax-validation tool (systemd-analyze verify). Key structure: unit file sections explained → Requires= vs. After= distinction with the misconfiguration risk → layered debugging sequence with reasoning → specific concrete root causes → proactive syntax validation tool. Option C covers the practical tools well but misses the Requires=/After= distinction and the proactive validation tool. Option D — restarting repeatedly and eyeballing the unit file — is an unsystematic approach that a strong sysadmin candidate should avoid stating as their process.
3 / 5
The interviewer asks: "A server is running out of disk space intermittently even though du shows plenty free. What's happening, and how do you investigate?" Which answer best demonstrates filesystem internals knowledge?
Option B is strongest: it precisely explains the underlying mechanism (open file descriptor keeps the inode and blocks allocated even after directory unlink, which is why du misses it — du walks the directory tree, not open descriptors), names the exact diagnostic command with the correct flag and what it means (lsof +L1, link count < 1), gives two concrete remediation options with a reason to prefer one over the other in a given situation, and adds the separate, easily-confused root cause of inode exhaustion with the distinct diagnostic command (df -i) and why it looks identical but needs a different fix. Key structure: mechanism (open fd keeps inode/blocks allocated, invisible to du) → precise diagnostic command and flag meaning → two remediation options with situational reasoning → separate inode-exhaustion cause with distinct diagnostic and why it looks the same. Option C reaches the same correct diagnosis and tools but is more compressed and doesn't explain why du specifically misses this. Option D misdiagnoses the described symptom (which explicitly says du shows free space, ruling out simple file growth) as a straightforward cleanup problem, missing the actual technical puzzle in the question.
4 / 5
The interviewer asks: "How do you troubleshoot network connectivity issues on a Linux server?" Which answer best demonstrates a systematic networking diagnostic approach?
Option B is strongest: it explicitly frames the approach as working outward in layers rather than jumping to conclusions, checks interface/routing with a specific note about verifying the route to the *specific* destination subnet (not just the default route), separates DNS resolution testing from connectivity testing explicitly, states the important nuance that ICMP being blocked doesn't mean the service is unreachable (a common source of false diagnosis), and extends the firewall check beyond the host to cloud-level security groups/NACLs — a step many candidates miss entirely. Key structure: explicit layered approach stated → interface/routing with specific subnet-route check → DNS resolution tested separately → ICMP vs. port-level distinction with reasoning → firewall check extended to cloud-level, outside the host → tcpdump for asymmetric/intermittent cases. Option C covers the same layered approach accurately and concisely but is more condensed and doesn't explicitly separate DNS testing or dwell on the cloud-security-group point as clearly. Option D jumps straight to firewall rules, skipping the systematic layer-by-layer elimination the question is specifically asking about.
5 / 5
The interviewer asks: "Describe a production system failure you investigated and resolved." Which answer best demonstrates real incident-response discipline?
Option B is strongest: it shows disciplined scope-narrowing before diving into logs (checking whether errors correlated with one host or spread across the fleet, ruling out hardware), correctly interprets a specific signal (steady climb vs. sudden spike) to distinguish a leak from a traffic burst, describes the actual root-cause isolation method (profiler during controlled load test, isolated to a specific error-retry code path), and — critically — distinguishes the immediate stopgap from the permanent fix and describes removing the stopgap only after verified production soak time, which is the mark of real incident-response discipline rather than a one-off restart-and-hope. Key structure: fleet-wide vs. single-host correlation check → OOM killer identified via dmesg → steady-climb signal distinguishing leak from burst → controlled profiling to isolate root cause to a specific code path → stopgap vs. permanent fix explicitly separated → stopgap removed only after verified soak time. Option C reaches the same correct diagnosis and resolution but is more condensed, losing some of the specific diagnostic reasoning (fleet correlation, steady-climb signal). Option D never identifies an actual root cause — restarting and monitoring for a few hours without a durable fix risks the same failure recurring, which is a meaningfully weaker incident-response story.
What does "Linux Systems Administrator Interview Questions — Best-Answer Practice" cover?
Practice answering Linux Systems Administrator interview questions in professional English. 5 exercises covering process diagnosis, systemd, filesystem internals, network troubleshooting, and production incident response.
How many questions are in this interview set?
This set has 5 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.