Back to sections

Linux Interview Questions & Answers

A sample of real Linux interview questions with full answers and explanations - practice for interviews or certification exams.

easy

1. A new teammate asks why they can't run their deployment script with `./deploy.sh`, even though the file exists and looks correct. What is most likely missing?

The read permission on the file
The file needs to be owned by root
A valid shebang line pointing to /bin/bash
The execute permission on the fileCorrect

Linux checks for the execute permission bit before it will run a file directly. Even if the script is readable and syntactically fine, without execute permission (chmod +x) the shell refuses to run it as a program. Ownership by root isn't required, any user with execute permission on a file they own can run it.

medium

2. `df -h` shows plenty of free space on a filesystem, but an application still fails to write new files with 'No space left on device'. What's the likely cause?

The application has a memory leak
Inode exhaustion - check with df -iCorrect
The filesystem needs to be remounted read-write
The disk needs to be defragmented

df -h only tells you about raw disk SPACE, it says nothing about inodes, the separate, limited pool of 'slots' a filesystem has for tracking individual files. A directory packed with huge numbers of tiny files can exhaust every available inode slot while the actual disk space sits mostly empty, and df -i is what reveals that specifically.

hard

3. /proc file shows per-CPU softirq statistics (critical for NIC tuning)?

/proc/softirqsCorrect
/sys/class/net/eth0/queues/rx-0/rps_cpus
/proc/interrupts
/proc/net/softnet_stat

/proc/softirqs specifically breaks down how many times each type of software interrupt (like the ones networking cards generate) has fired, per CPU core. That per-core, per-type breakdown is exactly what you need to tune which CPUs handle NIC traffic, something /proc/interrupts can't give you since it only covers hardware IRQs.

easy

4. You downloaded a large ISO from two different mirrors and need to confirm they're byte-for-byte identical. What's the standard way to verify this quickly?

Open both in a text editor and scroll through
Compare file sizes with ls -l only
Run cat on both and see if the terminal looks the same
Compare sha256sum output for both filesCorrect

Matching file sizes alone doesn't guarantee the CONTENTS are identical, corruption can happen without changing a file's size. A cryptographic checksum like sha256sum produces a unique fingerprint of the actual content, so comparing those fingerprints is the fast, reliable way to confirm two large files are truly byte-for-byte the same.

medium

5. What does SO_REUSEADDR vs SO_REUSEPORT do for a TCP server?

EUSEADDR: allows bind to TIME_WAIT sockets; REUSEPORT: allows multiple identical binds (for multi-process load balancing)Correct
Both do the same thing
REUSEPORT disables Nagle’s algorithm
REUSEADDR enables keepalive

These sound similar but solve different problems: REUSEADDR just lets a NEW process bind to a port that's still lingering in TIME_WAIT from an old one that used it, while REUSEPORT lets MULTIPLE processes bind that exact same port AT THE SAME TIME, with the kernel spreading incoming connections across all of them, which is how you'd run several worker processes load-balancing one port.

hard

6. After rotating SSH host keys across a fleet, every connection now prompts a host key warning. Rather than disabling StrictHostKeyChecking fleet-wide, what's the more security-conscious fix?

Distribute the updated known_hosts entries via configuration management, or move to SSH certificates signed by a trusted CACorrect
Delete each user's known_hosts file before every connection via a script
Switch all servers to password authentication instead
Set StrictHostKeyChecking=no globally in ssh_config

Host key warnings exist specifically to protect you from man-in-the-middle attacks, so turning that checking off everywhere throws away the exact protection host keys provide. Pushing the correct, updated known_hosts entries out to everyone (or moving to CA-signed SSH certificates) fixes the warnings without giving up that protection.

easy

7. A sysadmin wants to quickly check how full each mounted drive is on a server, in an easy to read format like GB and percentages. Which command should they run?

du -sh /
df -hCorrect
free -h
top

df -h reports disk space usage per mounted filesystem in a human-readable format (KB, MB, GB) along with percentage used. du -sh measures the size of a specific directory's contents rather than whole filesystems, free -h shows memory usage, and top shows running processes, not disk space.

medium

8. Which file shows current TCP memory usage (in pages)?

/proc/net/sockstatCorrect
/proc/sys/net/ipv4/tcp_mem
ss -m
/sys/kernel/slab/tcp/

/proc/sys/net/ipv4/tcp_mem only stores the CONFIGURED thresholds (low, pressure, high), it's a setting, not a live reading. /proc/net/sockstat is the one that actually reports real-time, current socket statistics, including how much TCP memory is allocated right now, in pages.

hard

9. An engineer runs `ulimit -n 65535` in their SSH session to raise the file descriptor limit, but the systemd managed application service still crashes with 'too many open files' shortly after restart. What's the likely reason the change didn't help?

ulimit set in a shell session doesn't apply to services started by systemd; the limit needs to be set with LimitNOFILE in the unit fileCorrect
65535 is below the application's actual requirement, so a higher number is needed
ulimit changes only take effect after a full server reboot
The application ignores file descriptor limits entirely

A ulimit set interactively in a shell only affects processes started from that shell session, not services launched independently by systemd at boot or via systemctl. To raise the limit for a systemd managed service, you need to set LimitNOFILE= in that service's unit file (or a drop in override) and then reload systemd and restart the service. It's not about needing a reboot or a bigger number, the setting simply never reached the service in the first place.

easy

10. What does chmod 600 ~/.ssh/id_rsa enforce?

All users can read
File is immutable
Owner can read/write; group/others have no accessCorrect
Owner can execute; group can read

600 breaks down as: owner gets read and write, and literally everyone else (group, other) gets nothing at all. SSH actually enforces this for private keys specifically, it will flat-out refuse to use a key file that's readable by anyone besides its owner.

Want to practice under real conditions?

Try the full timed Linux quiz.

    Welcome to OpsQuiz!

    Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.