See exactly what you get for ₹99

Say this as an ordered procedure — that's what's being scored: "First df -h to see which filesystem is full, because it's usually one mount rather than the whole disk. Then du -h --max-depth=1 and walk down into the biggest directory until I find it. Nine times out of ten it's /var/log or a runaway application log."

df -h                                    # which filesystem?
du -h --max-depth=1 /var | sort -h       # walk down to the culprit
find /var/log -type f -size +100M -exec ls -lh {} \;

The trap worth naming before they ask it: "If df says full but du doesn't add up, it's a deleted file that a process still holds open — the space isn't released until the handle closes. lsof | grep deleted finds it, and restarting that process reclaims it. That's the classic 'I deleted the log and nothing happened'."

Follow-up: "Disk isn't full but you still get 'No space left on device'?" → Inodes are exhausted. df -i. Millions of tiny session or cache files do it.

Follow-up: "How do you stop it recurring?" → logrotate with compression and a retention policy, plus a disk alert at 80% so you hear about it before it's 100%.

Don’t say: "Delete the logs." Say truncate — > /var/log/big.log — because deleting a file the application has open frees nothing at all.

Say the procedure: "docker ps -a to see it and its exit code — the code is the first clue. Then docker logs, which still works on a stopped container and usually holds the actual error. If the logs are empty, override the entrypoint and look around inside the image."

docker ps -a                          # exit code?
docker logs <id>                      # works after exit
docker run -it --entrypoint sh myimg  # get a shell instead of the app

Say the exit codes — this is where the marks are: "0 — the process finished normally; there was simply nothing to keep running. 1 — application error, check the logs. 127 — command not found, usually a typo or a binary missing from a slim base image. 137 — SIGKILL, nearly always the OOM killer."

The concept behind all of them: "A container lives exactly as long as its main process. If the command is a service that daemonises itself into the background, PID 1 exits and the container stops — which is why you see nginx -g 'daemon off;'. Containers must run their process in the foreground."

Don’t say: "Add restart: always." That converts a clear failure into an endless crash loop and hides the error — it's the wrong instinct and interviewers listen for it.

Say this: It gives the owner read and write, and the group and everyone else read only. The three digits are owner, group, others, and each is the sum of read 4, write 2, execute 1. So 6 is 4+2 = read-write, and 4 is read only — that's -rw-r--r--.

The numbers worth having ready: 755 for a script or directory — owner full, everyone else read and execute. 644 for a normal file. 600 for a private key; SSH refuses to use one that's more open than that. 777 essentially never.

Follow-up: "What does execute mean on a directory?" → Permission to enter it and access things inside by name. A directory with read but no execute lets you list the names and nothing else — which is why 644 on a directory looks fine and breaks everything.

Follow-up: "Symbolic form?" → chmod u+x script.sh adds execute for the owner; chmod -R g+w dir recurses. I prefer symbolic when I'm changing one bit and octal when I'm setting the whole thing.

Don’t say: "I'd just chmod 777 to get it working." Interviewers hear that as a security habit, and it comes up again in the AWS section.

Say this: A hard link is a second name pointing at the same inode — the same actual file. Delete the original name and the data survives, because the inode's link count is still above zero. A soft link is a small file containing a path; delete the target and the link is left dangling, pointing at nothing.

The practical difference: hard links can't cross filesystems and can't point at directories, because they're inode references and inode numbers are only unique within a filesystem. Soft links can do both, which is why almost everything in practice — /usr/bin/python3, a current symlink in a deploy directory — is a soft link.

Follow-up: "Where do you use a symlink in DevOps?" → Deployments. Releases go into /app/releases/2026-08-23/ and /app/current is a symlink you repoint. Switching versions is atomic and rolling back is one command.

Follow-up: "How do you tell them apart?" → ls -l shows l and an arrow for a symlink; ls -i shows two names sharing one inode number for a hard link.

Don’t say: "A hard link is a copy." A copy has its own inode and its own data; a hard link shares both, so editing through one name changes what you see through the other.

Say this as an ordered procedure — that's what's being scored: "First, df -h to see which filesystem is actually full, because it's usually one mount, not the whole disk. Then du -sh /* 2>/dev/null | sort -h and walk down into the biggest directory until I find it. Nine times out of ten it's /var/log or a runaway application log."

df -h                                    # which filesystem?
du -h --max-depth=1 /var | sort -h       # walk down to the culprit
find /var/log -type f -size +100M -exec ls -lh {} \;

The trap worth naming, unprompted: "If df says full but du doesn't add up, it's usually a deleted file still held open by a process — the space isn't released until the file handle closes. lsof | grep deleted finds it, and restarting that process reclaims the space. That's the classic 'I deleted the log and nothing happened'."

Follow-up: "Disk isn't full but you still get 'No space left on device'?" → Inodes are exhausted. df -i. Millions of tiny session or cache files do this.

Follow-up: "How do you stop it recurring?" → logrotate with compression and a retention policy, plus a disk-usage alert at 80% so you hear about it before it's 100%.

Don’t say: "Delete the logs." Say truncate — > /var/log/big.log — because deleting a file an application has open frees nothing.

Say this: A zombie is a process that has finished but whose parent hasn't read its exit status yet, so the kernel keeps its entry in the process table. It shows as Z or <defunct> in ps. It uses no CPU and no memory — just a slot in the table.

The key point: you can't kill a zombie, it's already dead. You fix the parent — it's the parent's failure to call wait() that leaves it there. Kill or restart the parent, and the zombies get re-parented to init/systemd, which reaps them immediately.

Follow-up: "When does it actually matter?" → Only when a buggy parent leaks thousands of them and fills the process table, at which point nothing new can fork. A handful of zombies is harmless.

Follow-up: "What's an orphan then?" → The opposite — the parent died first, so the child is adopted by init. Orphans are normal; that's how daemons are created.

Follow-up: "Why does this come up with Docker?" → A process running as PID 1 in a container doesn't reap children by default, so containers accumulate zombies. That's what docker run --init and tini solve.

Don’t say: "kill -9 the zombie." It has no effect, and saying it confidently is the tell.

Say this: grep -rc gives a count per file; to get one total number I want -o so every occurrence is printed on its own line, then wc -l.

# total occurrences across all .log files
grep -roh "ERROR" --include="*.log" /var/log | wc -l

# count per file, useful for finding the noisy one
grep -rc "ERROR" --include="*.log" /var/log | grep -v ":0$"

# how many lines contain it (not the same number!)
grep -rh "ERROR" --include="*.log" /var/log | wc -l

The distinction to state — it's the actual mark: "Occurrences and matching lines are different numbers if a line contains ERROR twice. -o counts occurrences; without it you're counting lines."

Follow-up: "Case-insensitive, and errors from the last hour only?" → Add -i, and filter by timestamp with awk, or use journalctl --since "1 hour ago" | grep -i error if it's a systemd service.

Follow-up: "What are the flags?" → -r recursive, -c count, -o only matching parts, -h suppress filenames, -i ignore case, -v invert, -E extended regex.

Don’t say: grep -c "ERROR" *.log — that misses subdirectories and prints a per-file breakdown rather than the total they asked for.

Good answer hits: 750. Owner has read, write, execute (7); group has read and execute (5); others have nothing (0). Read is 4, write 2, execute 1.

One-liner: "750 — owner full, group read and execute, others nothing."

Follow-up they add: "And 644?" → rw-r--r--, the normal file default. 600 for a private key, 755 for a script or directory.

Good answer hits: tail -f /var/log/app.log. Better: tail -F, capital F, which keeps following after a logrotate replaces the file — plain -f silently follows the old, now-deleted inode and shows nothing.

One-liner: "tail -f, or -F to survive log rotation."

Follow-up they add: "Filter while following?" → tail -f app.log | grep -i error. For a systemd service, journalctl -u app -f.

Good answer hits: df -h for free space per filesystem — the "how full am I" view. du -sh * for what's consuming it — the "why" view. free -h is memory, not disk.

One-liner: "df for free space, du for usage. Different questions."

Follow-up they add: "df says full, du doesn't add up." → A deleted file still held open by a process. lsof | grep deleted, then restart that process.