Linux Interview Questions & Answers — DevOps Engineer
A 1-on-1 practice format. Cover the answer, ask yourself the question, then check.
Q1: What happens between pressing the power button and getting a login prompt? A: Firmware (BIOS/UEFI) runs POST, hands off to the bootloader (GRUB), which loads the kernel and initramfs. The kernel initializes hardware and mounts the real root filesystem, then hands control to systemd (PID 1), which brings the system up to its default target (usually multi-user.target on a server).
Q2: What’s the difference between systemctl disable and systemctl mask? A: disable removes a service from starting automatically at boot but still allows manual starts. mask creates a symlink to /dev/null, preventing the service from being started at all, even manually, until unmasked.
Q3: A service won’t start. Walk me through your troubleshooting steps. A: Start with systemctl status <service> to see the immediate error and recent log lines. Then journalctl -u <service> -n 50 or -b for more context since the current boot. Common causes in order of likelihood: config syntax error (usually named in the log), port already in use (ss -tulnp), permission issue (check ls -l on relevant files), or a missing dependency that hasn't started yet.
Q4: What’s a zombie process, and should you worry about it? A: A zombie is a finished child process whose exit status hasn’t been read (wait()) by its parent yet. A few zombies briefly are normal. A growing number indicates the parent process has a bug — it's not reaping its children — and that's worth investigating, since zombies can eventually exhaust the process table.
Q5: kill vs kill -9 — what's actually different? A: Plain kill sends SIGTERM, which a process can catch and use to clean up (close files, finish writes, deregister) before exiting. kill -9 sends SIGKILL, which can't be caught or ignored — the process is terminated immediately without any cleanup. Always try SIGTERM first; reserve -9 for processes that don't respond.
Q6: How does a container’s memory limit actually get enforced by the kernel? A: Through cgroups (control groups). Docker/Kubernetes set a memory limit on the container’s cgroup; when the cgroup hits that limit, the kernel’s OOM killer selects a process within that cgroup to terminate — the host may have plenty of free RAM, it’s the cgroup boundary that triggered it. Confirm this by checking dmesg | grep -i oom.
Q7: “No space left on device” but df -h shows free space. What's going on? A: Likely inode exhaustion, not block exhaustion. Check df -i — if inodes are at 100% but blocks aren't, you have too many small files (a common cause: unrotated logs, session files, or a cache directory generating huge numbers of tiny files).
Q8: Explain LVM in one or two sentences, and why you’d use it. A: LVM adds an abstraction layer — physical volumes are grouped into volume groups, which are carved into logical volumes. It lets you resize storage (grow, and in some cases shrink) without being constrained by the underlying physical partition layout, and without downtime in most cases.
Q9: What’s the difference between a Security Group-style stateful firewall and a stateless one like NACLs? A: A stateful firewall automatically allows return traffic for an already-permitted outbound/inbound connection. A stateless firewall evaluates every packet independently in both directions — so you must explicitly allow both the request AND the response, or connections will silently fail one way.
(Note: NACLs are AWS-specific, but the stateful vs stateless concept applies to Linux firewalls too — iptables conntrack tracking is what makes it stateful.)
Get Krishnaachauhan’s stories in your inbox
Join Medium for free to get updates from this writer.
Q10: What’s the difference between iptables rule order mattering and firewalld zones? A: In raw iptables, rules are evaluated top to bottom, and the first matching rule wins — so a broad DROP placed before a specific ACCEPT will block traffic even though the ACCEPT rule "looks" correct. firewalld abstracts this into zones (e.g., public, internal) with named services/ports, reducing the chance of this ordering mistake, though the same fundamental first-match logic exists underneath.
Q11: How do you check what’s listening on a given port, and what’s using it? A: ss -tulnp — shows TCP/UDP listening sockets along with the owning process ID and name. It replaced the older netstat command on most modern distros.
Q12: What’s SELinux, and why shouldn’t you just disable it when something breaks? A: SELinux enforces mandatory access control — policy-based restrictions that apply even to root, beyond standard file permissions. When something “just works” after disabling SELinux, that’s usually a real policy gap, not proof SELinux was wrong. The correct fix is to check ausearch -m avc -ts recent for the denial and either adjust a boolean (setsebool) or generate a proper policy exception (audit2allow) — disabling it removes a whole layer of defense-in-depth.
Q13: Describe your general root cause analysis approach for an unfamiliar production issue. A: First establish a timeline by correlating system logs, application logs, and monitoring alerts to find what happened first, not just what was noticed first. Separate symptom from cause — an application error is often downstream of something in dmesg, a resource limit, or a config change minutes earlier. Check the boring things first (disk space, memory, recent deploys) before assuming something exotic. Reproduce narrowly once you have a hypothesis, then document both the fix and what would have caught it sooner.
Q14: What does set -euo pipefail do at the top of a Bash script, and why does it matter? A: -e exits the script immediately on any command failure, -u errors on use of an undefined variable, and -o pipefail makes a pipeline fail if any command in it fails (not just the last one). Without these, a script can silently continue past a failure — the classic example is a failed cd followed by a rm -rf * executing in the wrong directory.
Q15: How would you find what’s eating disk space in /var/log without guessing? A: du -sh /var/log/* | sort -h to sort folders/files by size descending, or find /var/log -type f -size +100M to find specifically large files. Then check if logrotate is actually configured for whatever's growing unchecked — uncontrolled log growth is one of the most common causes of a disk-full incident.
Q16: What’s the practical difference between /etc/passwd and /etc/shadow? A: /etc/passwd holds basic user account info (username, UID, GID, home directory, shell) and is world-readable. /etc/shadow holds the actual hashed passwords and is restricted to root — separating the two means any process that needs to look up a username doesn't need access to password hashes.
Q17: A colleague says “the server won’t boot.” What’s your first move? A: Get console access (not SSH, since the system may not have networking up). At the GRUB menu, check if there’s an obvious kernel panic message. If needed, edit the boot entry to add init=/bin/bash to boot to a minimal shell, remount root as read-write (mount -o remount,rw /), and investigate from there — commonly a bad /etc/fstab entry or a failed kernel update, in which case booting the previous kernel from the GRUB menu is often the fastest fix.
Q18: What’s the difference between hard links and symbolic links? A: A hard link is another directory entry pointing to the same inode — it has no concept of a “target path” and survives even if the original file name is deleted (the data persists until all hard links are removed). A symbolic link is a separate file containing a path to the target — it breaks if the target is moved or deleted (a “dangling” symlink).
Q19: How does tail -f differ from journalctl -f, and when would you use each? A: tail -f follows a plain text log file and works for anything writing to a traditional file (e.g., an app writing directly to /var/log/myapp.log). journalctl -f follows the structured systemd journal, which is where most modern service output goes by default (stdout/stderr of systemd-managed services). Use journalctl -f -u <service> when you want logs for one specific systemd-managed service without noise from everything else.
Q20: What questions would you ask before troubleshooting “the application is slow” on Linux? A: Is it CPU-bound, memory-bound, I/O-bound, or network-bound? Start with top/htop for CPU/memory, iostat or vmstat for I/O, ss for network connections. Also ask: did this start after a recent deploy or config change? Is it slow for all requests or specific ones? Narrowing the category first prevents chasing the wrong layer.
Practice tip: don’t just memorize these answers — pick one, explain it out loud in your own words, then try to think of a real example from your own work (a migration, an incident, a project) that demonstrates it. Interviewers remember specific stories far more than textbook definitions.
