In this article
  1. How this list is ordered
  2. Files, directories and permissions
  3. Processes, users and signals
  4. Services, logs and scheduled jobs
  5. Performance and troubleshooting
  6. Follow-up questions
  7. Sources

How this list is ordered

The questions run from the structure of the system to the work of keeping it healthy. Files and permissions come first because every later topic uses them, and troubleshooting comes last because it draws on all of the others. For general technical preparation, see the coding interviews guide; Linux questions usually sit inside a DevOps or site reliability loop, so see also the DevOps and cloud guide and the interview loops guide. The answers cite the Linux man-pages project, the systemd manual and the GNU (GNU's Not Unix) coreutils manual, all read in October 2026.

Files, directories and permissions

What do /etc, /var/log and /tmp hold?

The directory /etc holds configuration files local to the machine, /var/log holds miscellaneous log files, and /tmp holds temporary files that may be deleted with no notice (hier(7), man-pages 6.19). Also useful: /proc exposes information about running processes and the kernel, and /home holds users' home directories, though the layout is left to local choice.

Why it is asked: it shows whether you can find things on an unfamiliar machine.

What is an inode, and what does it not store?

An inode is the per-file record in which a Linux filesystem keeps a file's metadata: its type and mode, link count, owner and group, size and timestamps. The file name is not among the listed fields (inode(7)); a name is an entry in a directory that refers to the inode, which is why a hard link is a second name for the same inode number (symlink(7)).

Why it is asked: it separates a file from its name, which explains links and deletion.

A hard link is another name for the same inode, so every hard link to a file refers to the same inode number, and hard links cannot point to directories or cross filesystems. A symbolic link is a special file whose contents are the path of another name, so it can point to directories and across filesystems, and it dangles if the target is removed (symlink(7)).

Why it is asked: it checks the inode model against practical behavior.

How do Linux file permissions work, and what does mode 755 mean?

A file's mode holds read, write and execute bits separately for the owner (0700), the group (0070) and others (0007) (inode(7)). Each digit adds read as 4, write as 2 and execute as 1, so 755 means the owner can read, write and execute, and the group and others can read and execute: rwxr-xr-x.1

Why it is asked: it is the most common hands-on test of permission basics. Read the full explanation: Linux commands from zero.

Each octal digit is the sum of read 4, write 2 and execute 1, so the mode maps to one symbolic string for each class.
Octal modeSymbolic form
0755rwxr-xr-x
0644rw-r--r--
0600rw-------
0750rwxr-x---

What are the setuid, setgid and sticky bits?

They are three extra mode bits: set-user-ID (04000), set-group-ID (02000) and sticky (01000) (inode(7)). Setuid makes a program run with its owner's user ID (execve(2), man-pages 6.19). Setgid on a directory makes new files there inherit the directory's group. Sticky on a directory such as /tmp lets only the file's owner, the directory's owner or a privileged process delete or rename a file in it (inode(7)). A mode of 4755 reads rwsr-xr-x, and 1777 reads rwxrwxrwt.1

Read the full explanation: Linux commands from zero.

Why it is asked: it tests whether you know why privileged programs need careful review.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.

Start Free Trial →

Processes, users and signals

What is the difference between a process and a thread?

A process is a running program with its own address space, and a thread is an execution path inside a process. Threads of one process share the same global memory, process ID, open file descriptors and user and group IDs, but each thread has its own stack and thread ID (pthreads(7)).

Why it is asked: it separates shared state from private state, the root of most concurrency bugs.

What is the difference between SIGTERM and SIGKILL?

A signal is a numbered notification the kernel delivers to a process. SIGTERM (15) is a termination request that a process can catch and use to clean up, while SIGKILL (9) terminates it and cannot be caught, blocked or ignored (signal(7)). Send SIGTERM first so the program can flush data and release locks, and use SIGKILL only if it does not exit.

Why it is asked: it tests whether you stop services safely, not only quickly.

What is a zombie process, and how do you get rid of one?

A zombie is a child that has terminated but has not been waited for. The kernel keeps its process ID (PID), termination status and resource usage until the parent calls a wait function, and the zombie holds a slot in the process table until then (wait(2)). Killing a zombie does nothing; fix or restart the parent, and init adopts and reaps orphaned children.

Why it is asked: it checks that you understand the parent-child lifecycle.

What do user IDs mean to a process?

Each process carries a real user ID, which says who owns it, an effective user ID that the kernel uses for permission checks on shared resources, and supplementary group IDs used with the filesystem IDs when it accesses files (credentials(7)). File access therefore depends on the process's IDs, not on the name of the person who typed the command.

Why it is asked: it explains most "permission denied" puzzles for services.

Services, logs and scheduled jobs

What is the difference between systemctl start and systemctl enable?

Starting a unit runs it now, while enabling it sets it to start later, for example at boot, without running it now. The systemd manual states that units may be enabled without being started and started without being enabled, and adding --now does both (systemctl, systemd 262). A unit is an object that systemd manages, such as a service, a mount or a timer; most units are described by a unit file, a short configuration file (systemd(1), systemd 262).

Why it is asked: it is the standard check of service-management basics.

What is systemd, and what does it do at boot?

systemd is a system and service manager for Linux; when it runs as the first process, PID 1, it acts as the init system that brings up and maintains userspace services (systemd(1), systemd 262). It does some boot tasks itself, then activates default.target, which pulls in the on-boot units through their dependencies.

Why it is asked: it shows you know what starts, and in what order, when a server comes up.

How do you read the logs of one service?

Use journalctl with -u and the unit name to show messages for that unit, -b to limit output to one boot, -f to follow new entries as they arrive, and -p to filter by priority, for example err for errors and worse (journalctl, systemd 262). A good answer names the unit, the time range and the priority, not just "look at the logs".

Why it is asked: it tests a repeatable way to start an investigation.

How does a cron entry work, and where does its output go?

A crontab entry has five time fields in this order: minute (0-59), hour (0-23), day of month (1-31), month (1-12) and day of week (0-7), then the command. Cron mails the output to the address set in the MAILTO (mail-to) variable or, if it is not set, to the crontab's owner, and an empty MAILTO sends no mail (crontab(5)).

Why it is asked: silent failures of scheduled jobs are a common operations bug.

Performance and troubleshooting

What does load average mean on Linux?

The load average is the average number of jobs that are runnable or waiting for disk input and output, over the last 1, 5 and 15 minutes, as in /proc/loadavg and uptime (proc_loadavg(5)). Because it includes jobs waiting on disk, a high load does not always mean a busy processor, so check both central processing unit (CPU) use and disk waits before drawing a conclusion.

Why it is asked: it is a classic trap for candidates who treat it as CPU use.

A disk shows free space but writes fail. What do you check?

Check inodes as well as blocks: df normally reports space, and df -i lists inode information instead of block usage (df(1), GNU coreutils 9.12). A filesystem holding millions of tiny files can run out of inodes while blocks remain free, and it also pays to check that the right filesystem is being written to.

Why it is asked: it tests whether you know that files need an inode as well as space.

How do you troubleshoot a slow server?

This is one common order, from the cheapest check to the most detailed. Name the symptom, then read the load average with uptime. Next check CPU, memory and input/output (I/O) wait with top or vmstat 1 and free -m, then disk I/O and space with iostat -xz 1, df -h and df -i. Then look at the service with systemctl status, and last at its logs with journalctl -u for the service or journalctl -k for the kernel. Change one thing at a time and write down what you saw, so that you can say when you started and what changed.

One common order for triaging a slow serverSix boxes in order: symptom, load average, CPU memory and I/O wait, disk I/O and space, service state, logs.Symptomwhat is slowLoad averageuptimeCPU, memory, I/O waittop, vmstat 1, free -mDisk I/O and spaceiostat -xz 1, df -h, df -iService statesystemctl statusLogsjournalctl -u, journalctl -kDiagram: Interview Clozo, CC BY 4.0 ·interview.clozo.ai/blog/system-admin-linux-interview-questions.html
One common order, from the cheapest check to the most detailed; stop at the first stage that explains the symptom.CC BY 4.0 — source: System admin Linux interview questions and answers
Text description of the diagram
  • Name the symptom, then read the load average with uptime.
  • Then check CPU, memory and I/O wait, then disk I/O and space, then service state with systemctl status, then logs.

Why it is asked: it reveals your method under pressure; see the site reliability engineering guide for how the same habits are used in production operations.

How do you make Secure Shell (SSH) logins safer?

Disable direct root login and password logins where keys are used, and enable public-key authentication. In sshd_config, PermitRootLogin takes yes, prohibit-password, forced-commands-only or no, with prohibit-password the default, while PasswordAuthentication and PubkeyAuthentication both default to yes (sshd_config(5), OpenBSD, October 2026). Test the file with sshd -t, reload the service (sshd re-reads its configuration on a reload) and keep a second session open. These are upstream OpenSSH defaults; a distribution's sshd_config can override them.

Why it is asked: it tests whether you know the defaults you are changing.

Follow-up questions

A disk is full, but du cannot find the files. What next?

A file that was deleted while a process still holds it open keeps using space until that process closes it: unlink removes only the name, and the space is freed when the last open file descriptor, the handle a process uses for an open file, is closed (unlink(2), man-pages 6.19). Find the process that holds it open (lsof lists open files), then reload or signal it so it closes the file, or restart it if it cannot. Say that df counts blocks in use and du counts files it can reach by name.

Which process is listening on a port?

Run ss -ltnp to list listening Transmission Control Protocol (TCP) sockets with the owning process, or lsof -i with the port number. Name the process and its unit with systemctl status before you stop anything.

You find a zombie whose parent is PID 1. What is wrong?

Normally init adopts orphans and reaps them with wait (wait(2)), so a long-lived zombie under PID 1 points to an init that is not reaping, which is common in some containers. Restart the container or the init process rather than the zombie.

Key takeaways
  • Separate a file from its name: the inode holds the metadata, the directory holds the name.
  • Send SIGTERM before SIGKILL, and fix the parent of a zombie.
  • Starting a service and enabling it are different actions.
  • Read load average as runnable plus waiting for disk, not as CPU use.
  • Troubleshoot from the cheapest check to the most detailed, one change at a time.

Sources

  1. hier(7) - description of the file system hierarchy (Linux man-pages 6.19) — Linux man-pages project, 8 Feb 2026
  2. inode(7) - file inode information (Linux man-pages 6.19) — Linux man-pages project, 8 Feb 2026
  3. symlink(7) - symbolic link handling (Linux man-pages 6.19) — Linux man-pages project, 8 Feb 2026
  4. signal(7) - overview of signals (Linux man-pages 6.19) — Linux man-pages project, 8 Feb 2026
  5. credentials(7) - process identifiers (Linux man-pages 6.19) — Linux man-pages project, 2 Jul 2026
  6. execve(2) - execute program (Linux man-pages 6.19) — Linux man-pages project, 8 Feb 2026
  7. pthreads(7) - POSIX threads (Linux man-pages 6.19) — Linux man-pages project, 8 Feb 2026
  8. wait(2) - wait for process to change state (Linux man-pages 6.19) — Linux man-pages project, 5 Jun 2026
  9. proc_loadavg(5) - /proc/loadavg (Linux man-pages 6.19) — Linux man-pages project, 8 Feb 2026
  10. unlink(2) - delete a name and possibly the file it refers to (Linux man-pages 6.19) — Linux man-pages project, 8 Feb 2026
  11. systemd(1), systemd 262 manual — systemd project, 24 Oct 2026
  12. systemctl, systemd 262 manual — systemd project, 24 Oct 2026
  13. journalctl, systemd 262 manual — systemd project, 24 Oct 2026
  14. crontab(5), cronie manual page — cronie project, 3 Aug 2026
  15. df(1), GNU coreutils 9.12 — GNU coreutils (Arch Linux manual pages), 1 Sep 2026
  16. sshd_config(5), OpenBSD manual pages — OpenBSD project, 9 Oct 2026