Linux Interview Questions and Answers

I start with top or htop for live CPU and memory, then use targeted commands.

top                      # live CPU/memory per process (press M or P to sort)
ps aux --sort=-%cpu | head    # top CPU consumers
free -h                  # memory and swap
df -h                    # disk usage per filesystem
du -sh /var/log/*        # folder sizes
uptime                   # load average
kill <PID>               # polite stop (SIGTERM)
kill -9 <PID>            # force kill (SIGKILL), last resort

Find a process by name with pgrep -a nginx or ps aux | grep nginx. Check logs with journalctl -u <service>. For storage problems, df -h shows which filesystem is full and du pinpoints the folder.

What they are checking: Whether you have day-to-day Linux troubleshooting habits

Each file has permissions for three classes: owner, group and others. Each class gets read (4), write (2) and execute (1), added together.

chmod 755 deploy.sh
chmod u+x,g-w file
chown appuser:appgroup file
ls -l file

chmod changes permissions and chown changes owner and group. 777 is a security risk because any user can modify or replace the file. Use the least permission that works.

What they are checking: Whether you can read and set permissions and avoid dangerous defaults

Create a user for each developer and add their public key to that user's authorized_keys. Never share one private key.

sudo adduser alice
sudo mkdir -p /home/alice/.ssh
echo "ssh-ed25519 AAAA... alice@laptop" | sudo tee -a /home/alice/.ssh/authorized_keys
sudo chmod 700 /home/alice/.ssh
sudo chmod 600 /home/alice/.ssh/authorized_keys
sudo chown -R alice:alice /home/alice/.ssh
sudo usermod -aG sudo alice      # only if needed

The developer generates the pair with ssh-keygen -t ed25519 and sends only the public key. Open port 22 only from trusted IPs. For many users, use SSM Session Manager, EC2 Instance Connect, or central user management (LDAP/SSO). Remove keys when people leave.

What they are checking: Whether you handle SSH access securely and per user

A short set covers most cases:

df -h                  # filesystem usage
du -sh /var/*          # size of folders
du -ah . | sort -rh | head   # biggest items
lsblk                  # block devices and volumes (EBS disks)
sudo ss -tulpn         # listening ports + process
sudo lsof -i :8080     # who uses port 8080
sudo netstat -tulpn    # older alternative

To then manage the process found: ps -p <PID> -o pid,cmd and kill <PID>. lsblk shows attached EBS volumes and their size even if they are not mounted yet. df -h shows only mounted filesystems.

What they are checking: Whether you can quickly find disk, port and process information

SSH key authentication uses a key pair: the private key stays with the user and the public key is placed on the server. The user proves they own the key without sending the private key.

1. Client connects and the server verifies its host key (known_hosts).
2. Client says it wants to use a public key. The server checks ~/.ssh/authorized_keys.
3. The server sends a challenge; the client signs it with the private key.
4. The server verifies the signature with the public key and allows login.

ssh-keygen -t ed25519
ssh-copy-id user@server
ssh -i ~/.ssh/id_ed25519 user@server

Private key permissions must be 600. Disable password login (PasswordAuthentication no in /etc/ssh/sshd_config) for better security.

What they are checking: Whether you understand asymmetric keys in practice

A private instance has no public IP. So you connect through a bastion/jump host, a VPN, or AWS Systems Manager.

# via bastion with ProxyJump
ssh -J ec2-user@<bastion-public-ip> [email protected]

# via SSM, no open port 22 needed
aws ssm start-session --target i-0123456789abcdef0

• The private instance's security group allows port 22 only from the bastion's security group (or VPN range).
• To log in, you need the key pair used at launch (-i key.pem, permission 400) or a user added with your own public key.
• With SSM the instance needs the SSM agent and an IAM role with AmazonSSMManagedInstanceCore.

What they are checking: Whether you know the secure ways into private servers

First find the PID. Then send SIGTERM so the process can clean up. Use SIGKILL only if it does not stop.

pgrep -a nginx            # find by name
sudo ss -tulpn | grep :8080   # find by port
sudo lsof -i :8080
kill <PID>                # SIGTERM (15), graceful
kill -9 <PID>             # SIGKILL (9), forced, no cleanup
pkill -f myapp            # by name pattern

For services managed by systemd prefer systemctl stop <service>, otherwise it may restart automatically. A process stuck in state D (uninterruptible I/O) may not die even with -9.

What they are checking: Whether you know graceful versus forced termination

A DevOps engineer should be comfortable with the shell, files, users, processes, networking and services.

ls, cd, pwd, cp, mv, rm, mkdir, cat, less, tail -f   # files
grep, find, sed, awk, cut, sort, uniq                # text search and processing
chmod, chown, sudo, useradd                           # permissions and users
ps, top, kill, systemctl, journalctl                  # processes and services
df, du, free, lsblk                                   # resources
ip a, ss -tulpn, curl, ping, dig                      # networking
ssh, scp, rsync, tar                                  # remote and archives
apt / yum                                             # packages (Ubuntu / RHEL)

Also know the filesystem layout (/etc config, /var/log logs, /home, /tmp). Know how to edit files with vim or nano. Know basic bash scripting with variables, loops and conditions.

What they are checking: Whether you have a working command-line foundation

SSH uses TCP port 22 and encrypts all traffic. Telnet (port 23) sends everything, including passwords, as plain text.

Structure for the answer: level, 2 or 3 concrete examples, impact, and how you keep scripts safe.

A hard link is another name for the same inode. A soft link is a small file that stores the path to another file.

Use grep for text, find for files, and awk or sed for transforming lines.

Pipes send the output of one command into the next command. Redirection sends a stream to or from a file.

Every process has three streams: stdin (0), stdout (1) and stderr (2).

A crontab line has five time fields followed by the command: minute, hour, day of month, month, day of week.

systemd is the init system (PID 1) on most modern Linux distributions. It starts services, manages dependencies and collects logs.

Traditional logs are text files under /var/log, and systemd services also log to the journal.

Work from the bottom up: interface, route, DNS, then the port.

Write a script that dumps the database, compresses it, uploads it, and removes old copies. Then schedule it with cron.

A daemon is a background process that starts at boot (or on demand). It gives a service without a user screen, such as sshd, nginx or cron. Their names often end in d.

Batch (.bat / .cmd) runs in the Windows command prompt. Bash runs on Linux and macOS (and on Windows through WSL or Git Bash).

A zombie is a process that has finished running. It still has an entry in the process table because its parent has not read its exit status.

chmod changes who can read, write or execute. chown changes the owner and group. umask sets the default permissions for new files.

Ubuntu and Debian use apt, RHEL, CentOS, Rocky and Amazon Linux use dnf (or yum).

Everything hangs off a single root /, and each top-level directory has a conventional purpose.

su switches to another user with that user's password. sudo runs a single command with extra rights, using your own password and a policy.

Environment variables are named values that a process gets from its parent. PATH is the list of directories searched when you type a command.

top shows live processes. The three load average numbers are the average count of running plus waiting tasks over the last 1, 5 and 15 minutes.

On a directory, execute (x) means you can traverse it: cd into it and access items inside by name. Read (r) means you can list its names.

• r only (e.g. chmod 400 dir): ls dir shows names. But you cannot cd into it, read file details, or open files inside.
• x only: you can cd and open a file if you know its exact name, but cannot list.
• r + x: the normal read-only access (r-x): list and enter.
• w + x: needed to create, delete or rename files in it.

So to cd into a folder you need x on it and on every parent directory. Read permission alone is not enough to enter or properly list contents.

What they are checking: Whether you understand that directory permissions differ from file permissions

Use groups and standard permissions first, and ACLs when the simple owner/group/others model is not enough.

# group-based: team A writes, team B reads
groupadd teama; groupadd teamb
chown -R deploy:teama /srv/app
chmod -R 2775 /srv/app          # setgid keeps the group on new files
setfacl -R -m g:teamb:rX /srv/app          # B: read + traverse
setfacl -R -d -m g:teamb:rX /srv/app       # default ACL for new files

# single user, read-only
setfacl -m u:alice:rX /srv/data
getfacl /srv/data

Capital X gives execute only on directories. So the user can enter the folder and read files, but cannot change them. Without execute on the directory, the user could not enter it even with read permission. Mind the ACL mask and parent directory traverse rights.

What they are checking: Whether you know groups, setgid and ACLs for multi-team access

set -e makes the script exit at once when a command fails (non-zero status). So errors are not ignored quietly.

Create a .service file under /etc/systemd/system/ with [Unit], [Service] and [Install] sections, then reload and enable it.

Start the app under PM2 and save the process list. Then make the startup script, so systemd starts PM2 at boot.

The s is the setuid or setgid bit. The program runs with the permissions of its file owner (setuid) or group (setgid), not the user who starts it.

DNS servers are set in /etc/resolv.conf (on modern Ubuntu it is managed by systemd-resolved, check with resolvectl status). Local name overrides go in /etc/hosts.

CPU use is the share of time the cores are busy. Load average counts tasks that are running or waiting to run. On Linux it also counts tasks stuck in uninterruptible IO wait.

Deny inbound traffic by default. Then open only the ports you need. Prefer the tool your distro ships with.

Use strace for system calls, lsof for open files and sockets, perf for CPU profiling, and tcpdump for network packets.

Fail fast, quote everything, validate input and clean up after yourself.

ulimit sets per-process limits such as open files. sysctl tunes kernel settings. For services, set the limit in the systemd unit.

Both are access control systems that limit what a process can do, even if it runs as root. SELinux is the default on RHEL-family distributions and AppArmor on Ubuntu and SUSE.

The usual cause is a deleted file that a running process still holds open. The space is not freed until the process closes it.

Find out which resource is saturated first: CPU, memory, disk IO or network, then which process is responsible.

Read the unit status and the journal. Then check the command, user, paths and environment the unit uses.

Run the client in verbose mode to see which key is offered. Then check the key, the permissions and the server logs.

Avoid storing changing state on the instances, and pick a shared or build-time approach.

Manage access in one place instead of copying keys by hand. Keep a second way in, so a lost key does not lock you out.

Check the kernel log for the out-of-memory killer, then fix the memory demand or limits.

Check inode exhaustion: a filesystem can run out of inodes (file entries) before it runs out of bytes.

Another process is already listening on that port. Find it, then decide whether to stop it or change the port.

Cron runs with a very small environment and no terminal. So most failures are path, permission or environment problems.

First stop the damage and check what changed. Then restore the right modes from a known good source, instead of guessing.

High wa means the CPUs are idle and waiting for storage. Find the device, then the process, then the reason.

Use logrotate to rotate, compress and expire logs automatically, and handle the live file correctly.

Grow the block device first, then the partition or logical volume, then the filesystem. You can do all this while it is mounted.