Linux Interview Questions

DNS resolution order in Linux (configured in /etc/nsswitch.conf):

1. /etc/hosts: Local overrides. Checked first. Maps hostnames to IPs without DNS lookup.
2. DNS servers (/etc/resolv.conf): The configured nameservers are queried via UDP port 53.

Common use cases for /etc/hosts: local development overrides, blocking domains by pointing to 127.0.0.1, testing service connectivity using a service name before DNS is configured. In containers, Kubernetes manages /etc/hosts via its own CoreDNS system.

A process is an independent program in execution with its own memory space, file descriptors, and system resources. Creating a new process (fork()) is expensive.

A thread is a unit of execution within a process. Threads within the same process share the same memory space and open file descriptors, making communication between them fast. Thread creation is lighter than process creation.

In Linux, threads are implemented as “lightweight processes” and managed with the clone() system call. Tools like htop can show threads per process.

Hard Link: A directory entry that points directly to the same inode as the original file. Both the original and the hard link are indistinguishable — deleting one doesn’t affect the other. Hard links cannot span filesystems or link to directories.

Symbolic (Soft) Link: A pointer to another file’s path. If the original is deleted, the symlink becomes a broken “dangling” link. Symlinks can cross filesystems and point to directories.

# Hard link
ln original.txt hardlink.txt

# Symbolic link
ln -s /etc/nginx/sites-available/mysite /etc/nginx/sites-enabled/mysite

Linux file permissions have three sets: owner, group, others. Each can have: read (4), write (2), execute (1).

-rwxr-xr-- = 754
# Owner: rwx (7), Group: r-x (5), Others: r-- (4)

chmod 755 script.sh   # Standard executable
chmod 644 config.yml  # Standard config file

Special bits:

• Sticky bit (1xxx): On directories (e.g., /tmp), only the file owner can delete their own files: chmod +t /shared
• Setuid (4xxx): File executes with the owner’s permissions (used by /usr/bin/passwd to write /etc/shadow as root). Use with extreme caution.

Load average in top or uptime shows three numbers: 1-minute, 5-minute, and 15-minute averages of the number of processes in a runnable or uninterruptible state.

Interpretation depends on the number of CPU cores. On a 4-core server:

• Load average of 4.0 = 100% utilization — every CPU busy but nothing waiting
• Load average of 8.0 = 200% utilization — 4 CPUs busy, 4 processes waiting in queue
• Load average of 0.5 = 12.5% utilization — plenty of headroom

Key insight: High load average is NOT always CPU. Uninterruptible sleep (disk I/O wait) also counts. Check iostat to distinguish CPU saturation from I/O saturation.

Namespaces provide isolation for system resources so each container sees its own view of the system:

• pid — isolated process tree (container sees its own PIDs starting at 1)
• net — isolated network stack (own IP, routing table)
• mnt — isolated filesystem mounts
• uts — isolated hostname
• user — isolated user/group IDs

cgroups (Control Groups) limit and account for resource usage (CPU, memory, I/O) per group of processes. This is how Docker enforces your CPU/memory limits.

Together: namespaces provide isolation (what can be seen), cgroups provide resource limits (how much can be used).

Password authentication: User provides a password. Vulnerable to brute-force attacks, password spraying, and phishing. Should be disabled for SSH in production.

SSH Key authentication: The client proves ownership of a private key without ever transmitting it. The server holds the public key in ~/.ssh/authorized_keys. Private key never leaves the client.

# Generate key pair
ssh-keygen -t ed25519 -C "anmol@devopsinterview.com"

# Copy public key to server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# Disable password auth in /etc/ssh/sshd_config
PasswordAuthentication no

Use ed25519 keys — they are faster and more secure than RSA 2048.

These three tools form the backbone of Linux log analysis:

# grep: Filter lines containing "ERROR"
grep "ERROR" /var/log/app.log

# awk: Extract specific fields (e.g., column 3 of an NGINX access log)
awk '{print $3}' /var/log/nginx/access.log

# sed: Replace or transform text
sed 's/ERROR/CRITICAL/g' app.log

# Combined pipeline: Find ERROR lines, extract IP (field 1), count by IP
grep "ERROR" /var/log/nginx/access.log \
  | awk '{print $1}' \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -10

The Linux kernel uses the page cache to cache file data in RAM to speed up I/O. When you read a file, the kernel copies it into page cache. Subsequent reads are served from RAM (microseconds) instead of disk (milliseconds).

Writes are also cached: data is written to the page cache first and then persisted to disk asynchronously (write-back). This is why free -h shows most RAM as “used” on a healthy server — the kernel aggressively caches. This is not a memory leak.

Relevant commands: vmstat, iostat, /proc/meminfo (Cached, Buffers), echo 3 > /proc/sys/vm/drop_caches to flush cache (dangerous in production).

#!/bin/bash
# Delete log files older than 30 days in /var/log/myapp

LOG_DIR="/var/log/myapp"
DAYS=30
DRY_RUN=false  # Set to false to actually delete

if [ ! -d "$LOG_DIR" ]; then
    echo "Directory $LOG_DIR does not exist"
    exit 1
fi

if [ "$DRY_RUN" = true ]; then
    echo "Dry run — files that would be deleted:"
    find "$LOG_DIR" -name "*.log" -mtime +$DAYS -print
else
    echo "Deleting log files older than $DAYS days..."
    find "$LOG_DIR" -name "*.log" -mtime +$DAYS -delete
    echo "Done. Freed up space:"
    df -h "$LOG_DIR"
fi

Always implement a dry run mode. Schedule this with cron or use logrotate for production systems.

Systematic disk investigation:

# Step 1: Check overall disk usage
df -h

# Step 2: Find which directory is consuming space
du -sh /* 2>/dev/null | sort -rh | head -20

# Step 3: Drill down into the problem directory
du -sh /var/* | sort -rh | head -10

# Step 4: Find specific large files
find / -type f -size +500M 2>/dev/null

# Step 5: Check for deleted-but-open files still consuming inodes
lsof | grep deleted

Common causes: application logs not rotating, large core dumps, MySQL/Postgres WAL overflow, old Docker images/volumes.

Systematic CPU investigation:

1. top / htop: Identify the process consuming CPU. Note: is it user space or kernel (%us vs %sy)?
2. ps aux –sort=-%cpu: Snapshot of top CPU consumers.
3. perf top: See which kernel functions are hot.
4. strace -p <PID>: Trace system calls to understand what a process is doing.
5. vmstat 1: Observe context switches (cs) and interrupts (in).

Common causes: runaway application bug, CPU-intensive query (full table scan), kernel work from high I/O (softirqs), insufficient CPU for the workload.