Top Linux Admin Interview Questions & Answers (2026)
17 questions Linux System Administrator interviewers actually ask, with the strong answer, the weak one, and the follow-up that comes next.
- Linux SysadminRole
- $80K-$120KTypical US pay
- 3-4 roundsInterview loop
- Nice to haveCert in hiring
- UsuallyHands-on test
Table of Contents
Linux system administrators keep servers running for hosting providers, banks, telecoms, universities, government agencies and any company with its own infrastructure or cloud VMs. The job covers patching, users and permissions, storage, services, security hardening and a lot of troubleshooting, increasingly with automation tools like Ansible doing the repetitive parts.
Linux interviews in 2026 are practical. Most loops include a technical round of rapid how-would-you questions, and many add a live session on a real server or a shared terminal where something is broken. Interviewers listen for the commands you would actually type and the order you would check things in. CompTIA Linux+ shows you have covered the breadth of the job across distributions, and some employers, especially government contractors, ask for it. Red Hat's RHCSA is often weighted more for RHEL shops, so be ready to prove hands-on skill either way.
What the Linux System Administrator interview loop looks like
Most Linux System Administrator hiring runs 4 rounds. Each one is testing something different, so prepare for each separately.
The 17 questions, with answers
Each card shows the question as it is usually asked, what the interviewer is really checking, a strong answer, the weak answer they hear most often, and the follow-up that comes next. Say the strong answers in your own words — a memorised script sounds memorised.
- Basic · 4
- Core · 5
- Advanced · 3
- Scenario · 3
- Behavioural · 2
Walk me through what happens from pressing the power button to getting a login prompt on a Linux server.
What they are testing: A clear mental model of the boot chain that lets you troubleshoot each stage
The firmware, UEFI on most modern servers, runs its hardware checks and loads the boot loader, usually GRUB 2, from the EFI system partition. GRUB loads the selected kernel and the initramfs into memory and passes kernel parameters. The kernel initialises hardware, and the initramfs provides the drivers and tools needed to find and mount the real root filesystem, including LVM or encrypted volumes. Then the kernel starts systemd as PID 1. systemd reads its units and works toward the default target, usually multi-user.target on a server, mounting filesystems from fstab and starting services like networking and sshd in dependency order, and finally getty gives me a login prompt on the console.
Explain what permissions 750 mean on a directory, and what the SUID, SGID and sticky bits do.
What they are testing: Accurate permission knowledge, including special bits that matter for security
750 means the owner has read, write and execute, the group has read and execute, and others have nothing. On a directory, execute means you can enter it and access files by name, and read means you can list it. SUID on an executable makes it run with the file owner's privileges, which is how passwd can update the shadow file; Linux ignores it on scripts. SGID on an executable runs it with the file's group; on a directory, new files inherit the directory's group, which is great for shared team folders. The sticky bit on a directory, like /tmp, means users can only delete their own files even though everyone can write there. I audit SUID files regularly with find, since they are a privilege escalation risk.
How do you manage a service with systemd, and how would you change its settings without editing the vendor unit file?
What they are testing: Practical systemd use, including enable versus start and drop-in overrides
systemctl status shows whether it is running, its main PID and the last few log lines. start and stop affect it now, while enable and disable control whether it starts at boot; enable with the now flag does both. journalctl -u with the unit name shows its full logs, and I add the since flag or b for the current boot to narrow it down. To change settings, I never edit the file under /usr/lib/systemd/system, because a package update overwrites it. I use systemctl edit, which creates a drop-in override under /etc/systemd/system and reloads systemd for me. If I do edit unit files by hand, I run systemctl daemon-reload before restarting the service.
What is the difference between kill, kill -9 and kill -HUP? And what is a zombie process?
What they are testing: Signals, graceful shutdown and process states, not just how to force-kill things
kill with no signal sends SIGTERM, which asks the process to shut down cleanly, so it can finish writes, close connections and remove lock files. kill -9 sends SIGKILL, which the kernel enforces and the process cannot catch, so there is no cleanup. I use it only after SIGTERM fails. SIGHUP originally meant the terminal hung up, but many daemons treat it as reload your configuration. A zombie is a process that has already exited, but its parent has not collected its exit status. It uses no CPU or memory, just a process table entry, and you cannot kill it because it is already dead. The fix is to get the parent to reap it, or restart or stop the parent.
You get an alert that the root filesystem is at 100 percent. Walk me through what you do.
What they are testing: Calm, safe investigation, including inodes and deleted-but-open files
First df -h to confirm which filesystem is full, and df -i, because running out of inodes looks the same to applications. Then I find what grew, using du with the x flag to stay on one filesystem and a max depth of one, sorted by size, and drill down. The usual suspects are logs under /var/log, the journal, old kernels, package caches, core dumps or an application writing temp files. If df says full but du cannot account for the space, a process is holding a deleted file open, and lsof +L1 shows it. Restarting that process, or truncating the file, frees the space. I clean up safely, never deleting unknown files blindly, then fix the cause, like log rotation or journald size limits.
The /data filesystem is on LVM and needs another 50 GB. A new disk has been attached. How do you extend it?
What they are testing: Correct LVM workflow and filesystem-specific growth, done online
First I confirm the new disk with lsblk and make sure it is the empty one, because picking the wrong disk is the real risk here. Then pvcreate on the new disk, and vgextend to add it to the volume group that holds /data. vgs confirms the free space. Then lvextend with the size flag set to plus 50G and the r flag, which resizes the filesystem as well as the logical volume. If I do it separately, XFS grows with xfs_growfs on the mount point, and ext4 with resize2fs. Both can grow while mounted, so no downtime is needed. One thing to remember: XFS cannot be shrunk, so I do not over-allocate. Afterwards I check df -h to confirm the new size.
A web app on this server is not reachable from other machines. How do you check networking on the server itself?
What they are testing: Use of modern tools like ip and ss, and working from listener to firewall to route
First I check the service is listening and on which address: ss -tulpn shows listening ports and the owning process. If it is bound to 127.0.0.1, it only accepts local connections, so I fix the app's bind address. Then I test locally with curl against localhost and the server's own IP. Next, the host firewall: firewall-cmd with list-all on RHEL-family systems, or nft list ruleset, to see whether the port is allowed. I check ip addr for the right address and ip route for a default route, and confirm from a client with curl or a TCP connection test. If the host looks right, I look upstream: a cloud security group, network ACL or load balancer health check.
How would you harden SSH on a new server?
What they are testing: Sensible hardening that does not lock you out, with a reason for each change
Key-based authentication first: I install my ed25519 public key and confirm I can log in with it. Then in sshd_config, or a drop-in file under sshd_config.d, I set PermitRootLogin to no, disable PasswordAuthentication and keyboard-interactive auth, and restrict who can log in with AllowGroups. I keep the crypto settings at the distribution's secure defaults rather than inventing my own. I validate the config with sshd -t before reloading, and I keep my current session open while I test a new login in a second terminal, so a mistake does not lock me out. Around it, the firewall limits SSH to management networks or a bastion, and something like fail2ban adds rate limiting. Changing the port alone is not real security.
When would you use a cron job versus a systemd timer for a scheduled task?
What they are testing: Knowing both tools, their gotchas, and how to observe scheduled jobs
Cron is simple and everywhere: a line in a crontab with minute, hour, day, month and weekday fields. The gotchas are that cron runs with a minimal environment and PATH, so scripts that work in my shell can fail, the percent sign needs escaping, and output goes to local mail unless I redirect it. A systemd timer pairs a .timer unit with a .service unit. It costs a bit more setup, but the job's output goes into the journal, I can see last and next runs with systemctl list-timers, run it by hand with systemctl start, and apply resource limits. Persistent=true runs a missed job after downtime. For new server tasks I usually choose timers, while respecting what the team already uses.
You moved a website to /srv/web and a new port 8081, and now Apache gets permission denied, but file permissions look fine. What is going on?
What they are testing: SELinux troubleshooting with the right tools, instead of disabling it
On a RHEL-family system with SELinux enforcing, that is almost certainly SELinux labels. Apache runs in the httpd_t domain and can only read files labelled for web content and bind to ports labelled as HTTP ports. I confirm with getenforce, then search the audit log with ausearch for recent AVC denials, and sealert explains them if setroubleshoot is installed. For the files, ls -Z shows the wrong label, so I add a file context rule for /srv/web and everything below it with semanage fcontext, then apply it with restorecon -Rv. For the port, semanage port adds 8081 to the http_port_t type. If Apache also needs outbound connections, that is a boolean set with setsebool -P. I do not set SELinux to permissive as the fix.
A server has a load average of 30, but top shows the CPUs mostly idle. Explain what is happening and how you investigate.
What they are testing: Understanding that Linux load includes I/O wait, and the tools to find the bottleneck
On Linux, load average counts processes that are running or waiting to run, plus those in uninterruptible sleep, the D state, which usually means waiting on disk or network storage. So high load with idle CPUs points to I/O, not CPU. In top I check the wa figure for I/O wait. vmstat 1 shows the b column for blocked processes, and iostat with the x flag shows per-device utilisation and wait times. ps can list processes in D state to see what is stuck. Common causes are a slow or failing disk, a saturated storage array, a hung NFS mount, or heavy swapping. If it is NFS, every process touching that mount piles up, so I check the mount and the NFS server.
A package update last night broke an application on 40 servers. How do you recover, and how would you patch more safely in future?
What they are testing: Package manager skills, rollback options, and a mature patching process
Recovery first. On RHEL-family servers, dnf history shows the transaction, and dnf history undo with its ID rolls it back if the old packages are still available. On Debian or Ubuntu there is no transaction undo, so I install the previous version explicitly with apt and hold it with apt-mark hold. Across 40 servers I do this with Ansible, not by hand, testing on one server first. Then I find the cause in the changelog and decide on a pin or a fix. For the future: patch in rings, starting with test servers, then a small production group, then the rest, use a staged mirror so every server gets the same tested packages, and keep a monitoring check that would have caught the break quickly.
You cannot SSH into a server that worked fine yesterday. What do you check, in what order?
What they are testing: Structured triage from network reachability to sshd to authentication, plus console access
I start with what the error says. A timeout means a network or firewall problem, connection refused means nothing is listening, and permission denied means authentication. For a timeout I check whether the host responds at all and whether anything changed in firewalls or security groups. Then I get console access through the hypervisor, cloud serial console or out-of-band management, because I need to see the server itself. On the console I check systemctl status sshd and journalctl -u sshd. A full disk, a bad config change or a failed update are common causes. For permission denied, I check the account is not locked or expired, the home directory and .ssh permissions, and whether a tool like fail2ban has banned my IP.
After a reboot, a server stops in emergency mode. Someone added a new mount to /etc/fstab yesterday. What do you do?
What they are testing: Recovery from boot failures with access to only the console
Emergency mode after an fstab change usually means systemd could not mount something it was told was required, often a wrong UUID, a missing disk or a typo. I log in with the root password at the console, and run journalctl -xb to confirm which mount failed. The root filesystem may be read-only, so I remount it read-write with mount and the remount,rw options on /. Then I fix or comment out the bad line in /etc/fstab, checking UUIDs with blkid. Before rebooting, I run systemctl daemon-reload and mount -a to test the whole file. For non-critical mounts like network shares or extra data disks, I add the nofail option so a missing device does not stop the boot again.
An application process keeps getting killed overnight with no error in its own logs. How do you find out why?
What they are testing: Recognising the OOM killer and handling memory problems properly
A process disappearing with nothing in its own logs is often the kernel's out-of-memory killer. I check the kernel log with journalctl -k, or dmesg, for out of memory messages naming the killed process and how much memory it used. If it is OOM, I look at what else was running then: a nightly backup, a cron job or a report that pushes memory over the edge. sar, if installed, shows historical memory use. Then I fix the cause, not just the symptom. That could be fixing a memory leak with the developers, moving the overnight job, setting MemoryMax in the systemd unit so the right thing gets limited, or adding memory or swap if the workload simply needs it.
Tell me about a time a change you made caused an outage or nearly did. What happened?
What they are testing: Ownership, honesty and the safeguards you now use
This is a template; fill it with your own story. Situation: the system and the change, for example a firewall rule, kernel update or config push that went wrong. Task: what you owned. Action: show that you noticed quickly, told people instead of hiding it, rolled back or restored service first, and only then dug into the root cause with logs and evidence. Result: how long it lasted and the impact, stated honestly. Then the most important part: what you changed in your process, such as testing in staging first, a peer review for production changes, keeping a second session open, or a rollback plan written before the change. Interviewers trust people who learned from a mistake more than people who claim none.
Tell me about something repetitive you automated. How did you decide it was worth it?
What they are testing: Automation mindset, judgement about effort versus payoff, and sharing the result
This is a template for your own story. Situation: the repetitive task, for example creating user accounts, rotating logs on many servers, or applying the same patch steps by hand each month. Task: why it mattered, such as hours lost every week or mistakes from manual steps. Action: what you built, like a Bash script, an Ansible playbook or a systemd timer, how you made it safe to run twice, how you tested it, and how you documented it so others could use it. Result: time saved or errors avoided, with real numbers if you have them. Mention one thing you deliberately did not automate, because judgement about when not to automate matters too.
Get the theory airtight before the interview
Interviewers build follow-ups on the fundamentals. ExamCert AI has exam-style CompTIA Linux+ questions with an explanation for every option, so the basics stay automatic when the questions get harder.
Practise on ExamCert AIFree CompTIA Linux+ practice testThe practical task
Expect some version of this. Companies vary the details, not the shape.
You get SSH access to a RHEL-family VM with SELinux enforcing. Nginx should serve a site from /srv/site on port 8080 but does not start. The /var filesystem is also at 100 percent, and a nightly backup timer has stopped running. Fix all three, explain each root cause, and make sure the fixes survive a reboot.
- Start with systemctl status nginx and journalctl -u nginx, and check df -h and df -i before changing anything
- Free space safely: find the growth with du, check lsof +L1 for deleted open files, then set limits
- Check SELinux denials with ausearch, then fix labels with semanage fcontext and restorecon and add the port
- Inspect the timer with systemctl list-timers and the service journal, fix it and run the service once by hand
- Confirm fixes are persistent: enabled units, permanent SELinux rules, and a clean reboot test if allowed
Hire vs no-hire:Hires read status and logs before acting, never disable SELinux, explain each root cause in a sentence, and prove every fix with a check, including that it will survive a reboot.
Questions to ask them
"Do you have any questions for us?" is still being scored. Four that land well for a Linux System Administrator role:
Mistakes that sink candidates
What the CompTIA Linux+ does and does not prove
What the CompTIA Linux+ gets you
CompTIA Linux+ covers the full sysadmin job across distributions and appears in some postings, especially government and defence contractor roles where CompTIA certifications satisfy workforce requirements. It helps people moving from help desk or Windows administration show they have studied Linux properly. Many RHEL-focused employers weight Red Hat's RHCSA more, because it is a fully hands-on exam.
What it does not prove
Linux+ is mostly multiple choice with some performance-based questions, so it does not prove you can fix a broken server under time pressure in a live terminal, which many interviews test directly. It also does not show depth in a specific environment: running a fleet with Ansible, cloud VMs, monitoring stacks, or real on-call experience. Build a lab and practise breaking and fixing things.
Pay:Range draws on the BLS May 2025 median for network and computer systems administrators ($99,130) and Indeed's October 2026 US average for systems administrators ($95,755). Automation skills, cloud experience, security clearance, on-call and location move it most.
Still sitting the CompTIA Linux+?
Pass it first time and walk into the interview with the credential on your CV. ExamCert AI has exam-style CompTIA Linux+ questions with an explanation for every option.
Practise on ExamCert AIFree CompTIA Linux+ practice testFAQ
Should I get Linux+ or RHCSA for a Linux admin job?
It depends on the employers you target. RHCSA is a hands-on exam on Red Hat Enterprise Linux and is highly regarded in RHEL shops. Linux+ is vendor-neutral and is accepted for many government and contractor roles. If you can do one, read local job postings first. Many people take Linux+ for breadth and RHCSA later for proof of hands-on skill.
Will I have to use a live terminal in the interview?
Often, yes. Many teams give you SSH access to a broken VM, or share a screen and ask you to type commands. Others ask you to describe commands and outputs out loud. Practise both: fix things in a home lab against a timer, and practise explaining each command and what you expect it to show.
Do I need scripting for a Linux sysadmin role?
Yes, at least solid Bash: variables, loops, conditionals, exit codes and working with text using grep, awk and sed. Many teams also expect Python basics and Ansible. You do not need to be a developer, but you should be able to automate a repetitive task safely and explain how your script handles errors.
How important is cloud experience for Linux admin jobs now?
Increasingly important. Many Linux servers now run as cloud VMs, so knowing how cloud networking, security groups, disks and images relate to the Linux side helps a lot. You do not need to be a cloud architect, but being able to talk about resizing a cloud disk or troubleshooting a security group is a real advantage.
What home lab is worth building before interviews?
Two or three VMs with a RHEL-compatible distribution and Ubuntu. Practise LVM, systemd units and timers, SELinux contexts, SSH hardening, firewall rules and log analysis, and then break things on purpose: fill a disk, corrupt fstab, misconfigure a service. Manage them with an Ansible playbook in Git, and you will have real stories for every question.
Sources
Figures on this page come from CompTIA and the other primary sources below:
- CompTIA Linux+ Certification - CompTIA
- Network and Computer Systems Administrators - BLS Occupational Outlook Handbook
- Systems Administrator salaries in the United States - Indeed
- Troubleshooting problems related to SELinux - Red Hat Enterprise Linux 9 documentation
Checked November 4, 2026. Fees, outlines and eligibility rules change — confirm with CompTIA before you book.