Linux Interview Questions and Answers for Experienced Users

Linux admin interviews check whether you can keep servers running and fix them when they break—not whether you memorized every flag from every man page.

Interviewers listen for how you think: what you check first, what evidence you expect, and when you would escalate or roll back. A list of commands without context is a weak answer.

A strong answer is:

"Linux interviews test whether I can operate and debug real systems calmly—permissions, services, logs, performance, and networking—and explain my reasoning out loud, not just type commands."

Linux-heavy interviews commonly combine fundamentals, troubleshooting, automation, and—at senior levels—architecture or operations discussions. Exact format varies by employer.

The scenario round is usually where senior candidates separate themselves in 2026. You may get a broken VM, log snippets, or a verbal "users can't SSH" prompt. Interviewers want a ordered checklist, not random command spam.

A strong answer is:

"I expect a fundamentals round plus a live troubleshooting scenario—I'll narrate what I'm checking and why before I run each command, and I'll tie answers back to real on-call work I've done."

A good prep plan mixes reading, breaking things on a VM, and mock spoken answers. Flashcards alone rarely help for scenario rounds.

Use a disposable VM or cloud free tier. Pair hands-on work with shell scripting interview questions if automation comes up in your target role.

A strong answer is:

"I'd spend a few weeks on a lab VM—create users, break and fix services, practice disk and network scenarios, and rehearse explaining troubleshooting out loud, not only memorizing commands."

Beginner questions check whether you can do day-to-day tasks safely. Advanced questions check whether you can diagnose production failures without guessing and without unnecessary reboots.

Advanced network answers often pair ss with short tcpdump captures on the right interface — see the tcpdump command.

Advanced prompts often start as a story: "Checkout is slow at 9 AM." You are graded on order of checks, evidence, and communication—not one magic command.

A strong answer is:

"Junior rounds test whether I can administer accounts, services, and permissions. Senior rounds test whether I can walk through a production incident methodically—load, memory, disk I/O, logs—and explain trade-offs before taking action."

What interviewers are testing: Whether you can name current interview themes—systemd, ss, cgroups, observability—without neglecting fundamentals.

Core Linux skills are stable, but interview emphasis shifts with how teams run production today.

None of this replaces fundamentals: permissions, logs, and calm step-by-step troubleshooting still win most screens.

A strong answer is:

"I still need solid fundamentals—permissions, systemd, logs—but interviewers also expect ss command, journald, cgroup-aware debugging, and the ability to narrate a production incident without reaching for a reboot first."

What interviewers are testing: Whether you understand the boundary between kernel responsibilities and user-space command interpreters.

If you are new to Linux, it helps to separate who runs the hardware from who reads your typing.

The kernel is the core of the operating system. It schedules CPU time, manages RAM, talks to disks and network cards, and enforces security between programs. Everything privileged eventually goes through the kernel.

The shell (bash, zsh, fish, etc.) is a normal user program you interact with. It reads your command line, finds programs like ls or grep command, and asks the kernel to run them. The shell also handles pipes, redirects, variables, and scripts.

When you type ls, the shell searches $PATH, executes the binary, and the kernel performs the file reads. Output returns to the shell, which prints it on your terminal.

A strong answer is:

"The kernel is the OS core—it manages CPU, memory, and devices. The shell is my interface; it parses commands and launches programs, but the kernel does the real work of running them and accessing hardware."

What interviewers are testing: Whether you know why daily administration uses sudo and least privilege instead of shared root login.

root is the superuser account (UID 0) with full control over the system. sudo lets a normal user run specific commands as root—or another user—with logging and policy.

On Ubuntu and most enterprise Linux, admins use a personal account plus sudo. Auth events land in /var/log/auth.log or journalctl (search for sudo or sshd).

Least-privilege example in /etc/sudoers.d/:

deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp.service

That grants restart rights for one service—not a full root shell.

A strong answer is:

"I avoid routine root login. I use my own account with sudo so actions are attributable, I can grant narrow permissions, and mistakes are less likely to take down the entire system."

What interviewers are testing: Whether you can explain hard links versus symlinks and when each breaks or survives target deletion.

Both create extra names for data, but they work differently under the hood.

A hard link is another directory entry pointing to the same inode (same underlying file data on disk). All hard links are peers—deleting one name does not delete the data until the link count reaches zero.

A symbolic link (symlink) is a small file whose content is a path to another file or directory. If the target is removed, the symlink becomes dangling.

Check inode and link count:

ls -li /etc/hosts /etc/hostname
stat /etc/hosts

Sample output:

786433 -rw-r--r-- 1 root root 258 Jun 30 08:54 /etc/hosts
786434 -rw-r--r-- 1 root root   9 Jun 30 08:54 /etc/hostname

Different inode numbers above mean these are separate files—not hard links to each other.

A strong answer is:

"A hard link is another name for the same inode—same data, same filesystem. A symlink is a pointer to a path—it can cross filesystems but breaks if the target is deleted. I'd mention inode for hard links and path indirection for symlinks."

What interviewers are testing: Whether you distinguish $PATH lookup from the current working directory and resolve commands safely with command -v.

New users often confuse where the shell looks for programs with where relative paths start.

$PATH is a colon-separated list of directories. When you type ls without a slash, the shell searches those directories left-to-right for an executable named ls.

The current working directory (pwd) is where relative paths resolve—./script.sh means "script in this folder." For security, modern systems usually exclude . from $PATH so you cannot trick someone into running a malicious binary in the current directory.

Resolve the executable path with command -v:

echo "$PATH"
pwd
command -v ls

which is also commonly available for executable PATH lookup; the which command explains PATH search order and differences from command -v.

Sample output:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/home/golinuxcloud
/usr/bin/ls

If command -v mytool prints nothing, either the package is not installed or its directory is not on $PATH. Fix by installing the package or adjusting PATH in the profile— not by putting untrusted directories first.

A strong answer is:

"$PATH tells the shell where to find command names I type without a path. The current working directory only affects relative paths like ./foo—and . should not be in $PATH for security."

What interviewers are testing: Whether you understand that shell metacharacters are parsed before ordinary variable expansion—and why eval is usually the wrong fix.

Shell metacharacters such as | are recognized during parsing, before normal parameter expansion. Therefore putting | inside a variable does not create a pipeline.

pipeline='|'
echo "$pipeline"

That prints a literal |—the shell does not reinterpret it as syntax.

Without a second parsing pass, this does not pipe:

pipeline='|'
ps aux $pipeline grep -c root

eval can force a second parsing pass:

eval "ps aux $pipeline grep -c root"

But eval is usually the wrong design and becomes an injection risk whenever any part of the string is not completely trusted. For production scripting, use explicit shell syntax, functions, arrays, or conditional branches instead.

A strong answer is:

"A variable containing | is just data—the shell does not treat it as a pipe during normal expansion. I write the pipeline explicitly rather than using eval, which is risky with untrusted input."

What interviewers are testing: Whether you can describe the compile-and-link steps that turn C source into a Linux executable.

Linux does not run .c source directly—you need a compiler and linker to produce an executable.

On Debian/Ubuntu install the toolchain:

sudo apt install build-essential

Then compile and run:

gcc myprog.c -o myprog
./myprog
echo $?

Sample output:

0

Exit code 0 means success. Interview follow-ups often include:

• gcc -Wall for warnings
• make for multi-file projects
• ldd myprog to see dynamic libraries linked at runtime

A strong answer is:

"I install build-essential, compile with gcc source.c -o binary, check the exit code, and use ldd if I need to verify shared library dependencies."

What interviewers are testing: Whether you can translate common octal permission modes into owner/group/other access in plain language.

Unix permissions control who can read, write, or execute a file. chmod sets them with either symbolic (u+x) or octal notation—octal is common in interviews.

Each digit is owner / group / others, built from:

stat -c '%a %n' /bin/ls /etc/passwd

For directories, r allows listing entry names, while x allows traversal/search. With execute but no read permission, you may access a file if you already know its name but cannot list the directory normally.

A strong answer is:

"755 means the owner can read, write, and execute; everyone else can read and execute—common for scripts and directories. 644 means the owner can read and write; everyone else read-only—typical for config files."

What interviewers are testing: Whether you can distinguish atime, mtime, and ctime, especially when troubleshooting backups or file changes.

Linux tracks three timestamps per file. They sound similar but mean different things—backup and forensic questions love this topic.

stat /etc/passwd

Sample output:

File: /etc/passwd
  Size: 2841      	Blocks: 8          IO Block: 4096   regular file
Access: 2026-07-01 12:41:54.707859222 +0530
Modify: 2026-07-01 12:41:54.358834731 +0530
Change: 2026-07-01 12:41:54.363031746 +0530

Backup tools usually key off mtime. Security reviews may compare all three after an incident.

A strong answer is:

"stat shows atime, mtime, and ctime—mtime is content change, ctime is metadata change including permissions, atime is last access. I'd use mtime for 'when did this file change' in most ops questions."

What interviewers are testing: Whether you know chattr +i is a safety guard against accidental modification, not an authorization boundary against root.

chattr +i prevents normal writes, deletion, renaming, and many metadata changes until the immutable flag is removed. Root—or a process with the appropriate capability—can clear the flag, so this is a safety guard, not an authorization boundary.

Use chattr:

sudo chattr +i /etc/important.conf

Edits and deletes fail until you remove the flag:

sudo chattr -i /etc/important.conf

Sample error when immutable:

touch: setting times of '/tmp/immutable-test.txt': Permission denied

This is not a substitute for Git or configuration management—it is a safety rail during change freezes or on fragile legacy systems.

A strong answer is:

"I can use chattr +i as a safety guard against accidental modification. It is not an authorization boundary against root, because a privileged administrator can remove the immutable flag."

What interviewers are testing: Whether you can diagnose missing or mismatched shared libraries with ldd or safer ELF inspection tools.

Most Linux programs are dynamically linked—they load shared libraries (.so files) at startup. If a library is missing or wrong version, the program fails before main() runs.

ldd prints required libraries and where the loader finds them:

ldd /usr/bin/vi

Sample output:

linux-vdso.so.1 (0x00007e330fc79000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007e330fb53000)
	libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007e330fb1b000)
	...

not found means a broken install or bad LD_LIBRARY_PATH. After package upgrades, ldconfig refreshes the system cache.

Do not blindly run ldd on an untrusted executable; for untrusted binaries, inspect ELF dependencies with tools such as readelf -d or objdump -p instead.

A strong answer is:

"I run ldd on trusted system or application binaries to see which shared libraries they need and whether any are missing—first step when a program won't start after an upgrade or custom install path. For untrusted binaries, I use readelf -d or objdump -p instead."

What interviewers are testing: Whether you can gather hardware and firmware inventory from DMI/SMBIOS without physical access.

When you need serial numbers, BIOS version, or memory slot layout without opening the case, DMI/SMBIOS tables expose hardware inventory to the OS.

dmidecode decodes those tables:

sudo dmidecode -t system | head -20

biosdecode summarizes firmware/ACPI presence:

sudo biosdecode | head -5

Sample output:

# biosdecode 3.6
ACPI 2.0 present.
	OEM Identifier: VBOX

Common interview uses: asset audits, verifying RAM population, confirming manufacturer before a firmware upgrade.

A strong answer is:

"For hardware inventory I'd use dmidecode—system serial, BIOS version, memory slots—without physical access. biosdecode gives a quick firmware summary."

What interviewers are testing: Whether you understand secure-delete limits on modern storage and when shred is appropriate.

rm only unlinks a directory entry—the data may remain recoverable until overwritten. shred overwrites file contents in place:

shred -n 3 -z sensitive.txt
rm -f sensitive.txt

• -n 3 — three random overwrite passes
• -z — final pass of zeros to hide shredding

Senior nuance: on SSDs, TRIM, and copy-on-write filesystems, overwrite guarantees are weaker than on old spinning disks. Full-disk encryption and proper decommission procedures matter more at scale.

A strong answer is:

"For sensitive files on traditional disks I'd shred then rm. On SSDs or encrypted volumes I'd also mention encryption-at-rest and that shred alone may not be enough—process depends on threat model."

What interviewers are testing: Whether you know what kernel modules are currently loaded and how that relates to drivers.

The Linux kernel can load optional code modules—drivers for filesystems, network cards, virtualization, etc. lsmod lists modules currently loaded into the running kernel.

lsmod | head -5

Sample output:

Module                  Size  Used by
isofs                  61440  1
snd_seq_dummy          12288  0

Same information lives in /proc/modules; lsmod formats it as a table. Related tools:

A strong answer is:

"lsmod shows kernel modules loaded right now—drivers and filesystem support. If hardware isn't working I'd check whether the right module is loaded with modprobe or modinfo."

What interviewers are testing: Whether you attempt graceful process termination before resorting to an uncatchable SIGKILL.

Processes can receive signals—software interrupts asking them to change behavior. Two signals dominate admin interviews. The kill and pkill cheat sheet walks through TERM-first workflows on real PIDs.

kill -l | grep -E 'TERM|KILL'

Sample output:

9) SIGKILL	15) SIGTERM

Best practice: kill PID (defaults to SIGTERM), wait, then kill -9 PID only if the process ignores termination. Exit code 137 commonly means SIGKILL; OOM is one possible cause, so confirm it in kernel logs.

A strong answer is:

"SIGTERM requests a graceful shutdown and can be handled by the process. SIGKILL cannot be caught or ignored, so I reserve it for a process that will not terminate normally—but even SIGKILL cannot immediately remove a task stuck in uninterruptible kernel sleep."

What interviewers are testing: Whether you understand shell job control versus durable service management with systemd or a multiplexer.

Job control lets one terminal session manage multiple commands. If something long-running blocks your shell, you can suspend and background it.

1. Press Ctrl+Z — suspends the foreground job
2. Type bg — resumes it in the background
3. Use jobs to list; fg %1 to bring back

Or start directly in background:

long_running_command &

For production services, shell backgrounding is not enough—use nohup, screen/tmux, or a systemd unit so the process survives logout and gets proper logging and restart policy.

A strong answer is:

"Ctrl+Z suspends, then bg sends it to the background. For real servers I'd use systemd or a terminal multiplexer—not rely on shell jobs that die when I disconnect."

What interviewers are testing: Whether you can deprioritize a noisy process and know when cgroup limits are the real fix.

Linux schedules CPU with nice values from −20 (highest priority) to 19 (lowest). Regular users can only increase nice (lower priority); root can decrease nice.

Raise nice to deprioritize a CPU hog; the nice and renice reference covers -p, -u, and privilege rules for negative nice.

renice -n 10 -p 12345

Sample output:

12345 (process ID) old priority 0, new priority 10

renice is a quick relief valve. For sustained isolation on shared hosts, senior answers mention cgroups and systemd CPUQuota=—hard caps beat polite hints to the scheduler.

A strong answer is:

"I'd renice the noisy PID to give other workloads more CPU—but for production I'd also consider cgroup CPU limits so one runaway job cannot starve the whole node."

What interviewers are testing: Whether you know load is not CPU percentage and can distinguish CPU contention from tasks blocked in uninterruptible sleep.

Load average is often misunderstood. It is not CPU percent—it is the average number of tasks either running or waiting uninterruptibly (often disk I/O) over time.

uptime
nproc

Sample output:

12:48:48 up  3:54,  8 users,  load average: 0.54, 0.92, 0.91
2

The three numbers are 1-, 5-, and 15-minute averages.

vmstat 1 5    # watch the wa column for I/O wait

A strong answer is:

"Load average counts runnable and uninterruptible tasks—if it's above core count I'd check whether we're CPU-bound or I/O-bound with top and vmstat, not assume CPU saturation."

What interviewers are testing: Whether you can recognize system-wide and cgroup OOM events and confirm them in kernel logs.

When the kernel cannot satisfy a memory allocation—either because the host is under severe memory pressure or a workload reaches a cgroup memory limit—OOM handling may kill one or more processes.

dmesg | grep -i 'out of memory' | tail -3
journalctl -k | grep -i oom | tail -5
free -h

Sample kernel line:

Out of memory: Killed process 6736 (python3) total-vm:4013968kB, anon-rss:3936336kB ...

Fix path: right-size apps, fix leaks, set cgroup MemoryMax, add RAM—do not treat unlimited swap as a solution.

A strong answer is:

"OOM kill means the kernel ran out of memory and sacrificed a process—I'd confirm in dmesg or journalctl -k, identify the victim's RSS, then fix sizing, leaks, or cgroup limits rather than only adding swap."

What interviewers are testing: Whether you can query DNS record types such as NS with dig during name-resolution troubleshooting.

DNS maps names to records. NS (name server) records say which servers are authoritative for a zone—useful when mail works but web does not, or after a domain migration.

dig is the standard DNS debugging tool:

dig google.com NS +short

Sample output:

ns2.google.com.
ns1.google.com.
ns4.google.com.

Other useful variants: dig MX example.com, dig +trace example.com to walk delegation from root.

On desktops with systemd-resolved, compare against resolvectl query example.com if local caching confuses results.

A strong answer is:

"I'd use dig for DNS debugging—dig domain NS for name servers, MX for mail, +trace when delegation looks wrong—and compare with what our resolver returns."

What interviewers are testing: Whether you prefer ss for socket inspection on modern systems where legacy netstat may be absent.

netstat comes from the older net-tools suite and is absent by default on many modern distributions; ss (socket statistics) reads kernel socket data directly and is faster on busy hosts. When you still need netstat, the netstat command documents -tulnp listener syntax.

ss -tuln | head -5
ss -s

Sample summary:

Total: 831
TCP:   29 (estab 17, closed 1, orphaned 0, timewait 1)

ss -tulnp answers "what is listening on which port?"—a daily production question. TIME_WAIT storms show in ss -s.

A strong answer is:

"I normally use ss -tulnp for listeners and ss -s for socket-state summaries. netstat is older tooling and may not even be installed on modern systems."

What interviewers are testing: Whether you can explain ICMP firewall direction, persistence, and out-of-band safety before changing remote rules.

Ping uses ICMP echo-request/reply. Blocking it is a policy choice—some networks require ICMP for path MTU discovery; others block it for hygiene.

On a host whose firewall policy is managed directly with nftables, assuming an inet filter table and output base chain already exist:

sudo nft add rule inet filter output ip protocol icmp icmp type echo-request drop

Classic iptables equivalent:

sudo iptables -A OUTPUT -p icmp --icmp-type echo-request -j DROP

Always explain direction (outgoing echo-request here) and verify persistence—temporary CLI rules vanish on reboot unless saved to distro netfilter config. Have out-of-band console before experimenting on remote servers.

A strong answer is:

"I'd add an output rule dropping ICMP echo-request—nftables or iptables depending on the host—and confirm persistence and that I'm not breaking required ICMP types for MTU discovery."

What interviewers are testing: Whether you delegate admin rights with narrow sudo rules instead of sharing the root password.

The root password is not how most teams delegate admin work. sudo (superuser do) lets normal users run approved commands as root with their own password (or passwordless rules where policy allows).

Add a rule with visudo or a file in /etc/sudoers.d/:

deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart myapp.service

The user runs:

Control the running service with systemctl start, stop, or restart; see the systemctl command for try-restart and dependency behavior.

sudo systemctl restart myapp.service

Principles interviewers expect:

• Least privilege — one command or service, not blanket ALL
• Logging — sudo events in auth log / journal
• No shared root password — individual accountability

A strong answer is:

"I grant sudo rights in /etc/sudoers.d/ for specific commands—never hand out the root password. Narrow rules, logged actions, individual accounts."

What interviewers are testing: Whether you understand when LD_LIBRARY_PATH helps debugging and why production should avoid casual overrides.

When a program starts, the dynamic linker loads shared libraries (.so files). LD_LIBRARY_PATH prepends extra directories to that search path—handy for private installs, dangerous if misused.

Troubleshooting: ldd ./myapp and LD_DEBUG=libs ./myapp to trace loader decisions.

A strong answer is:

"LD_LIBRARY_PATH tells the dynamic linker where to find extra shared libraries—fine for dev or private installs, but in production I'd use ldconfig and proper package layout instead of global overrides."

What interviewers are testing: Whether you use systemd unit state commands instead of legacy SysV chkconfig thinking.

Older Red Hat systems used SysV init and chkconfig --list. Modern distros use systemd—services are units with explicit enabled/disabled state.

systemctl list-unit-files --type=service --state=enabled | head -10
systemctl get-default

Sample output:

graphical.target
UNIT FILE                                  STATE   PRESET
accounts-daemon.service                    enabled enabled
ssh.service                                enabled enabled

A strong answer is:

"On systemd hosts I use systemctl list-unit-files for enabled services and systemctl status for runtime state—chkconfig is legacy SysV."

What interviewers are testing: Whether you gather status, logs, and configuration-validation evidence before repeatedly restarting a broken service.

This is one of the most common live troubleshooting prompts. Work top-down—do not restart blindly.

sudo systemctl status myservice
sudo journalctl -u myservice -n 50 --no-pager
sudo myservice-binary -t    # if supported

Sample systemctl status snippet:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled)
     Active: active (running) since Wed 2026-07-01 08:54:37 IST
    Process: 1677 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)

A strong answer is:

"I'd read systemctl status for the failure reason, pull journalctl -u for details, run a config syntax test like sshd -t if available, fix or roll back, then restart—never restart without knowing why it failed."

What interviewers are testing: Whether you know Python's module HTTP server is for temporary local sharing, not production hosting.

Python ships a tiny HTTP server for lab and ad-hoc file sharing—not production hosting.

cd /home/user/downloads
python3 -m http.server 8080

Browse http://server-ip:8080/ from another machine on a trusted network. Stop with Ctrl+C when done.

Limitations to mention in interviews:

• No production-grade authentication or access control
• No production TLS setup by default
• Minimal security and operational controls
• No reverse proxy, rate limiting, process supervision, or production observability
• Intended for simple local or testing use

A strong answer is:

"For temporary local file sharing I can run python3 -m http.server 8080. I would not expose it as a production web service because it lacks the security, policy, observability, and operational controls of a proper server."

What interviewers are testing: Whether you can capture live log output to a file while still watching it with tee.

During incidents you often need to watch logs live and keep a snippet for a ticket. tee copies stdin to stdout and a file simultaneously.

sudo journalctl -f -u myapp | tee /tmp/myapp-live.log

Classic syslog tail:

tail -f /var/log/syslog | tee found.log

Only lines that pass through the pipe are saved—unlike redirecting only at the end. Pair with tee for more patterns.

A strong answer is:

"I pipe live output through tee so I still see it on screen while saving a copy to a file—handy during incidents when I need evidence for the postmortem."

What interviewers are testing: Whether you triage a slow host systematically across CPU, memory, I/O wait, and network before rebooting.

Scenario questions test process, not one command. Narrate what you check and what each result would mean.

Step 1 — System overview

uptime                  # load vs CPU count
nproc
top -b -n 1 | head -20  # top CPU/memory consumers
free -h                 # RAM and swap pressure
vmstat 1 5              # run queue, I/O wait (wa column)

Sample vmstat line:

r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0 1221808 1811260  79816 1881380    0    0     0     0 1266  329  0  2 98  0  0  0

Step 2 — Branch on evidence

Senior signal: no reboot first—gather evidence, then act.

A strong answer is:

"I'd start with uptime and nproc, then top and free for CPU and memory, vmstat for I/O wait—if disk is the bottleneck I'd go to iostat. I'd narrate each step and avoid rebooting until I understand the cause."

What interviewers are testing: Whether you investigate inode exhaustion, quotas, and filesystem context when writes fail despite apparent free space.

df -h reports free disk blocks, not every reason a write can fail. For this scenario—the app reports ENOSPC but df still shows free space—check:

Inode exhaustion (millions of tiny files):

df -h /
df -i /

Sample:

/dev/mapper/ubuntu--vg-ubuntu--lv   58G   20G   36G  36% /
/dev/mapper/ubuntu--vg-ubuntu--lv 3833856 306903 3526953    9% /

Space looks fine on the first line—but if IUse% hits 100% on the second, you cannot create new files even with free GB.

Also verify user/group/project quotas, whether the app writes to a different filesystem than the one you checked, reserved blocks, and filesystem-specific limits.

Related scenario: if df says the disk is full but du cannot account for usage, look for deleted-but-open files—a process still holds an unlinked file descriptor, so blocks stay allocated until it exits:

sudo lsof +L1 | grep deleted | head -5

A strong answer is:

"If writes fail but df -h shows space I'd check df -i for inode exhaustion, quotas, and whether the app is on a different mount. Deleted-open files are a separate classic case where df is full but du looks low—then I'd use lsof and fix the holding process."

What interviewers are testing: Whether you troubleshoot connectivity layer by layer: process → listening socket → local request → firewall/routing → external client.

"The process is running" does not mean "the service is reachable." Work from the app outward toward the client.

Confirm the service responds on localhost with curl; see the curl command for verbose mode, timeouts, and follow-redirect flags.

ss -tulnp | grep -E ':80|:443'
curl -v http://127.0.0.1:8080/
sudo nft list ruleset | head -20    # or iptables -L -n

Read journalctl -u myapp for bind errors ("Address already in use").

A strong answer is:

"I'd confirm the process is listening on the right address and port with ss, test locally with curl, then check host firewall and cloud security groups—connection refused and timeout mean different layers."

What interviewers are testing: Whether you identify a CPU hog, classify intent, and terminate gracefully before escalating force.

First identify and classify intent—not every hot CPU is a fire drill.

Rank processes by CPU with ps -eo and --sort; the ps command documents column sets and one-shot snapshots for load triage.

top -b -n 1 -o %CPU | head -15
ps -p PID -o pid,user,cmd,%cpu,%mem,etime
cat /proc/PID/status | grep -E 'Name|Threads'

Always try SIGTERM before SIGKILL. On shared nodes mention cgroup CPUQuota to cap blast radius without killing unrelated services.

A strong answer is:

"I'd identify the PID and owner, decide if it's expected work or a runaway, gather a quick profile if needed, try graceful termination first, and use cgroup limits on shared infrastructure so one job cannot starve everything."

What interviewers are testing: Whether you validate sshd configuration and disk space with console access before locking yourself out.

If SSH is your only entry, use out-of-band access first—cloud serial console, IPMI, hypervisor console—so you cannot lock yourself out further.

sudo systemctl status ssh
sudo sshd -t
sudo journalctl -u ssh -n 30 --no-pager
df -h / /var

Validate with sshd -t before systemctl restart ssh.

A strong answer is:

"From console I'd check systemctl status ssh and journalctl -u ssh, validate config with sshd -t, verify disk isn't full on / or /var, then fix config or free space before restart—always with a recovery path open."

What interviewers are testing: Whether you can generate random values from /dev/urandom without mistaking bash $RANDOM for cryptographic strength.

The kernel exposes a cryptographically suitable random pool at /dev/urandom. Read a few bytes and format as a number:

od -N2 -tu2 -vAn < /dev/urandom | tr -d ' '

Sample output:

29661

For the no-extra-tool shell/Linux example, read /dev/urandom. If OpenSSL is installed and you need token material, openssl rand is more convenient. For security-sensitive values, never rely on $RANDOM alone.

A strong answer is:

"For a quick random number I'd read from /dev/urandom with od. For passwords or tokens I'd use openssl rand when available—bash $RANDOM is not strong enough for secrets."

What interviewers are testing: Whether you know zombies are already exited and must be fixed by correcting the parent process.

A zombie (state Z in ps) is a process that already exited but whose parent has not called wait() to collect its exit status. The kernel keeps a tiny PCB entry until the parent reaps it.

ps aux | awk '$8 ~ /Z/ {print}'

Orphan children get adopted by init (PID 1), which reaps them—zombies usually mean a parent bug ignoring SIGCHLD.

A strong answer is:

"A zombie has already exited, so sending it SIGKILL does nothing. I identify its parent and determine why it is not calling wait(); persistent or growing zombie counts point to an application or process-management bug."

What interviewers are testing: Whether you can outline the boot chain from firmware through initramfs and PID 1 to login.

Interviewers want a high-level map, not kernel source detail. Walk through who runs what:

1. Firmware (UEFI/BIOS) — POST, pick boot device
2. Bootloader (GRUB) — load kernel + initramfs into memory
3. Kernel — initialize hardware, mount temporary root from initramfs if needed (LVM, encryption, missing drivers)
4. initramfs — early userspace scripts to find real root filesystem
5. PID 1 (systemd on modern distros) — start units toward default.target
6. Services — network, sshd, databases per unit dependencies
7. Login — getty on console or sshd accepting remote sessions

Bonus tools: systemd-analyze blame for slow boot, dmesg for hardware probe failures.

A strong answer is:

"Firmware hands off to GRUB, GRUB loads the kernel and initramfs, initramfs finds root, then systemd as PID 1 brings up the default target and services until I get a login prompt or SSH."

What interviewers are testing: Whether you understand how systemd, container runtimes, and Kubernetes organize cgroup resource limits.

cgroups (control groups) let the kernel limit and account CPU, memory, I/O, and PIDs for groups of processes. cgroups v2 uses one unified hierarchy—default on modern Linux.

cat /sys/fs/cgroup/cgroup.controllers
systemctl show user.slice -p MemoryCurrent -p CPUUsageNSec

Connect to operating system interview questions for virtual memory theory; here the ops angle matters: cgroup limit hits versus whole-node memory pressure.

A strong answer is:

"cgroups v2 group processes for resource limits—systemd puts each service in a cgroup, containers nest cgroups per workload. I'd tune MemoryMax on the unit or container before the whole node hits OOM."

What interviewers are testing: Whether you would automate cross-distro configuration with idempotent tooling instead of manual SSH to many hosts.

This tests automation thinking, not whether you remember apt vs dnf spellings.

Manual SSH to 100 hosts is a weak answer. Senior candidates mention drift detection, canary deploy, and secrets outside Git.

A strong answer is:

"I'd use Ansible or similar with OS-specific package names and shared templates, test on both distros in CI, deploy in waves with health checks, and keep config in Git so rollback is a revert—not 100 manual SSH sessions."