Linux System Admin Scenario-Based Interview Questions With Worked Answers

Key takeaways

• Structure beats speed: symptom, checks, decision, fix, prevention.
• Name the command and the output you expect, not just the tool.
• Never disable SELinux or restart first; preserve evidence and keep backups.
• Practise by breaking a VM and fixing it from the console.

How to answer a scenario question

Use the same four beats every time: symptom, first checks, how each result changes your next step, then how you confirm the fix and stop it recurring. Interviewers are listening for your reasoning order, not for one magic command.

Say your assumptions aloud ("I am assuming this is RHEL 9 with systemd and I have console access"). Mention backups and change control before anything destructive. If you do not know, say what you would look up and where. That honesty scores better than a confident wrong answer.

Scenario 1: server fails to boot after a kernel update

Pick the previous kernel from the GRUB menu, boot, then find out why the new one failed. Do not delete anything until the old kernel has booted cleanly.

1. At the GRUB menu, choose the older entry under the advanced options. If you have only console or iLO/iDRAC access, press a key early to stop the countdown.
2. Once up, read the failed boot: journalctl -b -1 -p err shows errors from the previous boot (this needs a persistent journal; check that /var/log/journal exists).
3. Check which kernel is installed and which is default: rpm -q kernel and grubby --default-kernel.
4. Typical causes: a missing or broken initramfs, a third-party module (NVIDIA, storage driver) not rebuilt for the new kernel, or a changed disk device name in /etc/fstab. Rebuild the initramfs with dracut -f /boot/initramfs-<version>.img <version>.
5. Set the working kernel as default with grubby --set-default until you have a fix, and raise the vendor ticket.

What a strong answer adds: you would test kernel updates on a non-production clone first, and keep at least two kernels installed (installonly_limit in /etc/dnf/dnf.conf).

Scenario 2: a critical server is out of disk space

Find which file system is full, then which directory or deleted-but-open file is eating it. Free space safely, then fix the cause.

df -hT
du -xh /var --max-depth=2 | sort -h | tail -15
df -i # inodes can run out even when space is free
lsof +L1 | head # deleted files still held open by a process

Illustrative output of the last check, where a rotated log is still open:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
java 2210 app 12w REG 253,2 18253611008 0 4194 /var/log/app/app.log (deleted)

Here df says the disk is full but du cannot find the files. The fix is to restart or signal the process so it releases the file, not to delete more. Then correct logrotate (for example use copytruncate or a postrotate reload), add a monitoring alert at 80 percent, and if growth is genuine, extend the logical volume with lvextend -r.

Scenario 3: SSH to a server suddenly stops working

Work from the network inwards: can you reach the host, is the port open, is the daemon healthy, is something rejecting you?

• ping and ss/nc -zv host 22 from your side tell you network versus service.
• On the console: systemctl status sshd and journalctl -u sshd -n 50.
• Check sshd -t for a config syntax error (a typo after an edit is a common cause).
• Firewall: firewall-cmd --list-all. SELinux: if the port was changed, semanage port -l | grep ssh must include it.
• Account issues: locked user (chage -l, faillock), wrong permissions on ~/.ssh (700) and authorized_keys (600).

Scenario 4: the server is slow and load average is high

Separate CPU, memory, disk and network. High load with low CPU use usually means processes waiting on disk.

uptime
top -o %CPU # or htop
vmstat 1 5 # watch 'wa' (iowait) and 'si/so' (swap)
iostat -xz 1 3 # %util and await per device
free -h
ss -s

If wa is high and one device shows high await, find the process with iotop or pidstat -d. If swap is active, look for a memory leak or an undersized VM. Explain what you would not do: killing random processes before you know which one is the cause.

Scenario 5: a service will not start

Let systemd tell you. Read the status, then the journal for that unit, then verify the config the daemon reads.

systemctl status myapp.service
journalctl -u myapp.service -b --no-pager | tail -40
systemctl cat myapp.service # see the real unit file and drop-ins
ausearch -m avc -ts recent # SELinux denials

Common roots: port already in use (ss -tlnp), wrong file ownership, a missing environment file, or an SELinux denial after files were moved instead of copied. Restore contexts with restorecon -Rv rather than disabling SELinux, and say so in the interview.

Scenario 6: a user deleted important files

Stop writes to that file system if you can, then check backups and snapshots before trying recovery tools. Every write lowers the chance of recovering the data.

Ask first: is there a backup, an LVM or XFS-compatible snapshot, or a Btrfs snapshot? Restore from there. Only if none exists would you consider forensic tools (extundelete works on ext3/ext4; XFS has no simple undelete). Then discuss prevention: backups with tested restores, restricted sudo, and avoiding rm -rf with variables that may be empty.

Scenario 7: lost root password

On RHEL, interrupt GRUB, add rd.break to the kernel line, remount the sysroot read-write, chroot, set the password, and trigger an SELinux relabel. This is a standard RHCSA task.

1. Reboot, press e at GRUB, append rd.break to the line starting with linux, press Ctrl+X.
2. mount -o remount, rw /sysroot then chroot /sysroot.
3. passwd root, then touch /.autorelabel.
4. Exit twice and let the system relabel and reboot.

A good candidate also notes this needs physical or console access, and that a GRUB password and disk encryption are the defences. Verify the exact steps against the documentation for your RHEL version before relying on them in production.

Common mistakes in these answers

• Jumping to a fix without asking what changed recently.
• Saying "I would restart the server" as the first step. Restarts destroy evidence.
• Disabling SELinux or the firewall to "make it work".
• Giving commands from memory without saying what output you expect.
• Forgetting to confirm the fix and write it up.

How to practise

Break a virtual machine on purpose. Fill a disk with fallocate, corrupt /etc/fstab, change a service port without telling SELinux, and fix it using only the console. Keep a note of each command and why you ran it. These scenarios map closely to the RHCSA objectives, which you can check on the Red Hat Training and Certification pages.

Next steps

If you want guided hands-on practice, see the Red Hat Linux RHCSA and RHCE course. For more questions in this style, read Troubleshooting Linux System Admin Interview Questions and the interview preparation guide.

Related reading

• [2026] Linux System Admin Certification Interview Questions