40 Linux system administrator interview questions for 2026

Linux system administrator interview questions should show whether a candidate can keep Linux servers running, secure and patched, and fix them calmly when something breaks. The 40 questions below are grouped into seven skill areas plus scenarios, each with what a strong answer includes, so you can build an interview kit for an L1 support hire, an L2 admin or a senior Linux engineer.

TL;DR / Key takeaways

• Strong Linux system administrator interview questions cover seven areas: fundamentals, users and access, processes and boot, storage, networking, security and patching, and automation.
• Scenario questions ("the disk is full", "SSH is down after a reboot") separate real admins from people who memorized commands.
• Match depth to level. L1 hires need fundamentals and safe habits; senior hires need automation, root cause analysis and change control.
• Score every answer from 1 to 5 against anchors written before the first interview, and score alone before the debrief.
• The best answers name specific commands, check the fix and mention rollback. Jumping straight to a reboot is the most common red flag.
• Put a Linux skills test before the interview, then use a short hands-on task on a broken test server to confirm what the interview suggests.

What should Linux system administrator interview questions test?

Linux system administrator interview questions should test seven skill areas: Linux fundamentals, users and access control, processes, services and the boot sequence, storage, networking, security and patching, and scripting and automation. On top of that, scenario questions check judgment: whether the candidate can find the cause of a problem on a live server without making it worse.

These areas follow the work itself. The US Bureau of Labor Statistics lists the core duties of systems administrators as installing and upgrading systems, keeping them secure, tuning performance, adding users and permissions, and fixing problems reported by users or monitoring. A good question set touches every one of those duties at least once.

This guide is about the Linux system administrator job: running servers in production. If you need broader questions on Linux as an operating system for developers, testers or DevOps hires, use our separate list of [Linux interview questions](/linux-interview-questions-to-ask-job-applicants/).

Which questions fit L1, L2 and senior Linux admin roles?

Linux admin interview questions fit a role when their depth matches the tickets the person will own. Use the table to choose sections, then add three or four questions about your own distributions, cloud provider and tooling.

A senior candidate who struggles with L1 questions is a warning sign, but do not spend senior interview time on them. A short skills test can cover the basics before the call.

Which Linux fundamentals questions should you ask?

Linux fundamentals questions check that the candidate understands how the system is laid out and how files really work. These are quick to answer for anyone who has administered servers, so slow or vague answers tell you a lot.

1. Walk me through the Linux file system hierarchy. What lives in /etc, /var, /proc and /opt? Listen for: /etc for configuration, /var for changing data such as logs and spools, /proc as a virtual file system for kernel and process data, /opt for add-on software. Strong candidates add /boot, /home and /tmp without being asked.

2. What is an inode, and what happens when a file system runs out of them? Listen for: An inode stores a file's metadata and data block locations, not its name. A disk can show free space while new files fail because all inodes are used, often from millions of small cache or session files. They should mention df -i.

3. What is the difference between a hard link and a symbolic link? Listen for: A hard link is another name for the same inode and cannot cross file systems; a symbolic link points to a path and breaks if the target moves.

4. Which Linux distributions have you run in production, and how do they differ for an admin? Listen for: Real distributions (RHEL, Rocky or Alma, Ubuntu, Debian, Amazon Linux) and real differences: package manager, release cycle, default firewall tool, SELinux vs AppArmor.

5. What does the load average in uptime or top tell you? Listen for: The average number of processes running or waiting over 1, 5 and 15 minutes, read against the CPU count. A load of 8 on a 16-core host is fine; on a 2-core host it is not. Bonus if they mention processes stuck waiting on disk I/O.

6. How do you find out why a command or service is behaving differently on two servers? Listen for: Comparing package versions, config files (diff, checksums), environment variables, kernel versions and recent changes. This shows method, not memory.

What user, permission and access questions should you ask?

User and permission questions reveal whether a candidate keeps access tight on shared servers. Weak answers here are a security risk, so ask at least two of them at every level.

7. Explain what the permission string -rwxr-x--- means, and how you would set it. Listen for: Owner read, write and execute; group read and execute; others nothing; chmod 750 or the symbolic form.

8. What are the SUID, SGID and sticky bits, and where would you see each one? Listen for: SUID runs a file as its owner (for example passwd), SGID applies group ownership (shared project directories), the sticky bit stops users deleting others' files in /tmp. Strong candidates say they audit SUID files.

9. What is the difference between /etc/passwd and /etc/shadow? Listen for: /etc/passwd holds account details and is world readable; /etc/shadow holds password hashes and ageing rules and is readable only by root.

10. How do you give a user limited administrative rights? Listen for: sudo with specific commands in a file under /etc/sudoers.d, edited with visudo, rather than sharing the root password or adding the user to a full admin group.

11. A developer has left the company. What do you do on the Linux servers? Listen for: Lock or remove the account, remove SSH keys from authorized_keys, check cron jobs and running processes owned by the user, reassign files, review sudo rules and rotate any shared secrets they knew.

Which process, service and boot questions should you ask?

Process, service and boot questions show whether a candidate understands what happens between power on and a working service. These questions matter most for L2 and senior roles, where the person owns outages.

12. Describe the Linux boot process from firmware to login prompt. Listen for: BIOS or UEFI, the boot loader (GRUB), kernel and initramfs, then systemd as PID 1 starting units by target. Strong candidates say where they would look when each stage fails.

13. How do you check why a systemd service failed to start? Listen for: systemctl status, journalctl -u <service> with time filters, checking the unit file and dependencies, systemctl daemon-reload after edits.

14. What is the difference between kill, kill -15 and kill -9? Listen for: SIGTERM (15, the default) asks a process to exit cleanly; SIGKILL (9) cannot be caught and skips cleanup, so it is a last resort.

15. What is a zombie process, and how do you deal with it? Listen for: A finished child process whose parent has not collected its exit status. You cannot kill a zombie; you fix or restart the parent.

16. What does the OOM killer do, and how would you find out it ran? Listen for: The kernel kills a process to free memory when it runs out; evidence in dmesg or the journal. Strong candidates talk about finding the memory hog and setting limits, not just adding swap.

17. When would you use a systemd timer instead of cron? Listen for: Timers log to the journal, can run missed jobs after downtime and handle dependencies; cron is simpler and everywhere. Either choice is fine if they can explain it.

What storage and file system questions should you ask?

Storage questions test the tasks that cause the most painful outages: full disks, failed mounts and resizing under pressure. Ask them with real numbers from your environment where possible.

18. What is the difference between df and du, and why might they disagree? Listen for: df reports file system usage; du adds up files it can see. They disagree when a deleted file is still held open by a process, which lsof +L1 shows.

19. Explain LVM. How do you extend a logical volume that is almost full? Listen for: Physical volumes, volume groups and logical volumes; lvextend then grow the file system (xfs_growfs or resize2fs), or lvextend -r. Strong candidates check free space in the volume group first.

20. How do you add a new disk and mount it permanently? Listen for: Partition, create the file system, mount, then add an /etc/fstab entry by UUID and test with mount -a before rebooting.

21. A server will not boot after an fstab change. What do you do? Listen for: Use the console or rescue mode, mount the root file system read-write, fix or comment out the line, and use the nofail option for non-critical mounts in future.

22. How do you plan backups and prove that they work? Listen for: What is backed up, how often, where copies are kept (one off site), retention, and regular restore tests. "We have backups" without restore tests is a weak answer.

Which networking and troubleshooting questions should you ask?

Networking questions check whether a candidate can tell a Linux problem from a network problem. The best answers work layer by layer instead of guessing.

23. How do you check IP addresses, routes and listening ports on a modern Linux server? Listen for: ip addr, ip route, ss -tulpn. Candidates who only know ifconfig and netstat may have stopped learning a while ago.

24. A service is running, but users cannot reach it. How do you troubleshoot? Listen for: Check that it listens on the right address and port, then the local firewall, then security groups or network ACLs, then DNS, then test from another host with curl or nc.

25. How do you troubleshoot DNS resolution on a Linux host? Listen for: /etc/resolv.conf or systemd-resolved, dig or host, /etc/hosts overrides and the order in /etc/nsswitch.conf.

26. How do you make SSH access safer on a public server? Listen for: Key-based login only, no root login, limited users or groups, non-default rules in the firewall, fail2ban or similar, and keeping the OpenSSH package patched.

27. What is the difference between firewalld, iptables and nftables? Listen for: nftables is the current kernel packet filtering framework; iptables is the older interface; firewalld is a management layer with zones, common on RHEL-family systems.

What security, patching and hardening questions should you ask?

Security and patching questions show whether a candidate treats updates as routine work or as something to avoid. NIST's guide to enterprise patch management frames patching as preventive maintenance with a planned, company-wide process, and strong candidates describe exactly that.

28. How do you run patching across a fleet of Linux servers? Listen for: Inventory, a test or staging group first, maintenance windows, automation (Ansible, a patch manager or cloud tooling), reboots where the kernel changes, and a report of what was patched.

29. A critical vulnerability is announced in a package you run. What do you do in the first 24 hours? Listen for: Confirm which hosts and versions are affected, check exposure, apply the fix or a mitigation in priority order, verify, and record what was done.

30. What is SELinux, and what do you do when it blocks an application? Listen for: Enforcing, permissive and disabled modes; reading denials with ausearch or the audit log; fixing contexts or booleans. Turning SELinux off as the fix is a red flag.

31. What are the first hardening steps on a new server? Listen for: Remove unused packages and services, patch, configure SSH, set up the firewall, enable logging and time sync, apply a baseline such as CIS benchmarks.

32. How do you find out who changed a file or ran a command on a server? Listen for: auditd rules, sudo logs, shell history (with its limits), central logging, and configuration management history.

What scripting and automation questions should you ask?

Scripting and automation questions separate admins who fix the same issue every week from admins who fix it once. Shell skills are common in technical teams: Bash and Shell were used by 48.7% of respondents in the Stack Overflow Developer Survey 2025, so expect at least working Bash from every candidate.

33. Write a one-line command that deletes .log files older than seven days in /var/log/app. Listen for: find /var/log/app -name "*.log" -type f -mtime +7 -delete, and a habit of running it without -delete first to see what would go.

34. What do you put at the top of a Bash script to make it safer? Listen for: A shebang, set -euo pipefail, quoting variables, and logging. Strong candidates mention ShellCheck.

35. How would you automate a configuration change across 200 servers? Listen for: Configuration management (Ansible, Puppet, Chef or Salt), version control, a test group, idempotent tasks and a rollback plan, not a loop of SSH commands.

36. What does idempotent mean in automation, and why does it matter? Listen for: Running the same task twice gives the same result with no extra changes, so automation is safe to rerun after a failure.

Which scenario-based Linux admin interview questions separate strong candidates?

Scenario-based Linux admin interview questions show how candidates think under pressure, which is the closest you get to watching them on call. Give the scenario, then answer their questions as the server would.

Pro tip: Keep a few facts ready for each scenario (what df -h shows, what the journal says) and only reveal them when the candidate asks. The questions they ask tell you as much as their final answer.

37. A production web server is slow. Walk me through your first ten minutes. Listen for: Check load, CPU, memory and swap (top or htop, free), disk I/O (iostat, iotop), recent changes and logs before restarting anything.

38. Monitoring says the root file system is 100% full. What do you do? Listen for: Find the cause with du on the big directories, look for deleted but open files, clear or rotate logs safely, then fix the cause (log rotation, retention or a bigger volume).

39. After a reboot, a server answers ping but not SSH. What could be wrong? Listen for: sshd not started or failing on a config error, firewall rules not persisted, a failed mount that holds up boot, or a full disk. They should ask for console access.

40. You made a change and the application broke. What happens next? Listen for: Roll back first, restore service, tell people, then find the cause and write it up. Owning the mistake openly is a strong signal for senior roles.

Linux admin interview questions and answers: what does a strong answer sound like?

A strong answer to a Linux admin interview question is specific, checks its own fix and considers risk. Here are two worked examples to calibrate interviewers.

Question: "The root file system is full. What do you do?"

• Strong answer (5): "First I check what is growing with du -xh --max-depth=1 / and look for deleted files still held open with lsof +L1. If a log is the cause, I truncate it rather than delete it while the process runs, then fix log rotation. I confirm space is back with df -h and add an alert at 80%."
• Weak answer (2): "I would delete some old files or reboot the server."

Question: "SELinux is blocking our application. What do you do?"

• Strong answer (5): "I check the denial in the audit log, see whether a file has the wrong context or a boolean is off, and fix that with restorecon or setsebool. I would only write a custom policy if neither works, and I would not leave the server in permissive mode."
• Weak answer (2): "I would disable SELinux."

How do you score Linux system administrator interview answers?

Linux system administrator interview answers are easiest to compare when every interviewer scores them from 1 to 5 against the same written anchors. Score each answer on its own, write one line of evidence, and only then compare notes.

• Use the same questions: Ask every candidate for the same level the same core questions, in the same order.
• Write anchors first: Agree what a 5, a 3 and a 1 sound like for each question before the first interview.
• Score before the debrief: Collect scores before discussion, so the loudest opinion does not set the result.
• Weight by level: For an L1 hire, fundamentals and access count most; for a senior hire, scenarios and automation count most.

What are the red flags in a Linux admin interview?

Red flags in a Linux admin interview are habits that would cause outages or security gaps on your servers. One alone may be nerves; two or more is a pattern.

• Reboot first: Restarting the server or service before looking at logs or metrics.
• Security as an obstacle: Disabling SELinux or the firewall as the standard fix.
• No verification: Never mentioning how they would check that the fix worked.
• Tool lists without depth: Naming Ansible, Kubernetes and Terraform but unable to describe one real change they made.
• No backups talk: Making risky changes with no mention of backups, snapshots or rollback.
• Blaming others: Every past incident was someone else's fault, with nothing learned.

How should you structure the hiring process for a Linux system administrator?

The hiring process for a Linux system administrator works best in four steps: a skills test, a structured scenario interview, a short hands-on task and a scored debrief. Testing first means interview time goes on judgment rather than basic commands.

1. Skills test: Send a [Linux Systems Administrator test](/test-library/linux-systems-administrator/) to every applicant who meets the basic requirements. Add a [Bash test](/test-library/bash-test/) for roles with heavy scripting, or the [System Administrator (Advanced) test](/test-library/system-administrator-advanced-test/) for senior hires.
2. Scenario interview: Pick 8 to 12 questions from the sections above that match the level, plus two or three scenarios, and score them with the rubric.
3. Hands-on task: Give a 30 to 45 minute task on a test virtual machine with a planted fault, such as a failed service or a full disk. Watch the method, not only the result.
4. Debrief: Compare written scores and evidence, then decide.

Key takeaway: The test filters on skill, the interview checks judgment and the task proves it on a real server. Skipping any one of the three leaves a gap.

This matters because good admins are hard to hire. In SHRM's 2025 Talent Trends research, 69% of organizations said they still struggle to fill full-time roles. A clear, scored process shortens time-to-hire and makes the offer decision easier to defend. Before you post the role, set expectations with a [Linux administrator job description](/job-description-templates/linux-administrator/), and for adjacent hires see our [DevOps engineer interview questions](/interview-questions-for-devops-engineer/).

Ready to hire your next Linux system administrator?

Choose the questions that match your level, write your 1 to 5 anchors and put a Linux skills test in front of the interview. Testlify gives you 3,500+ tests, including Linux, Bash and system administrator tests, with automated scoring and 20+ proctoring checks, so your team only interviews candidates who have already shown the skills. Start a 7-day free trial with no credit card, or [book a demo](/book-a-demo/) to see how it fits your hiring process.

Frequently asked questions