All jobs / DevOps / SRE / cloud

Linux interview questions

Linux questions a DevOps / SRE / cloud can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. `./deploy.sh` says “Permission denied” and `ls -l` shows `-rw-r--r--`. What do you do?

    The strongest answer: Add the execute bit for the owner — `chmod u+x deploy.sh` (or 755 if others run it) — and commit the mode so the pipeline gets the same file

    Why it works: Right — r, w and x are separate bits, and the file needs x to be run directly. Fixing the mode fixes it for everyone who checks it out.

    • Read the mode before you change it.
    • r, w, x — owner, group, others.
    • Add only the bit that is missing.
    • Never reach for 777.

  2. A VM was rebooted for patching. The API on it did not come back; a teammate says systemd is broken.

    What do you check, and what was the likely mistake?

    The strongest answer: `systemctl status api` and `journalctl -u api -b` first; most likely the unit was started but never enabled, so it does not start at boot — `systemctl enable --now` fixes both

    Why it works: Exactly — start is for now, enable is for boot, and the journal tells you whether it tried and failed or never tried.

    • Start is now; enable is at boot.
    • Check status and the unit’s journal.
    • Enable what must survive a reboot.
    • Do not bolt cron onto systemd.

  3. Everyone SSHes as root with the same key. What do you change first?

    The strongest answer: Named users or a break-glass role, no shared root key, and audit who did what — I do not “wait until we are bigger”

    Why it works: Exactly. Identity and audit. A shared root key is a shared incident.

    • Named identities.
    • No shared root key.
    • Keep a break-glass path.
    • Do not publish the key.

  4. A service fails to start with “address already in use” on port 8080. How do you find out what holds it?

    The strongest answer: `ss -ltnp` (or `lsof -i :8080`) shows the listening socket and the owning PID; then I decide whether it is a stale copy of the same service or something that belongs there

    Why it works: Right — the socket table tells you exactly who listens; guessing from process names does not.

    • Ask the socket table, not the process list.
    • ss -ltnp or lsof -i :port.
    • Identify before you kill.
    • Do not reboot to avoid looking.

  5. A runbook installs a CLI on every server with `curl https://… | sudo bash`. What do you prefer, and why?

    The strongest answer: A package from a trusted repository, or a pinned release whose checksum or signature we verify, baked into the image — reviewable, reproducible and upgradable

    Why it works: Right — package management gives you versions, verification and an upgrade path; a pipe to root gives you whatever the server sent today.

    • Install from a repo or a verified pin.
    • Pin the version.
    • Verify checksum or signature.
    • Bake it into the image.

  6. A deploy script failed on step two (the build), carried on, and pushed an empty artifact to production.

    What do you change in the script?

    The strongest answer: Start it with `set -euo pipefail` so a failed command, an unset variable or a failed pipeline stage stops the script, and quote every variable expansion

    Why it works: Exactly — -e stops on error, -u catches typos in variable names, pipefail stops a pipeline hiding a failure. It is the first line of every serious script.

    • Fail fast: set -euo pipefail.
    • Quote every expansion.
    • Check exit codes you depend on.
    • Never silence errors to look green.

  7. `df -h` says the root volume is 100% full. `du -sh /` adds up to less than half of that.

    What is going on, and what do you do?

    The strongest answer: A deleted file is still held open — usually a rotated log — so its space is not freed; `lsof +L1` finds the holder, then reopen or truncate via /proc/PID/fd. Also check `df -i` for inodes

    Why it works: Exactly — unlinked-but-open files are the classic df/du gap. Find the holder, release it properly, and fix the log rotation so it does not recur.

    • df sees the disk; du sees the tree.
    • Look for deleted-but-open files.
    • Check inodes too.
    • Fix the rotation, not just the symptom.

  8. Load average is 40 on an eight-core VM, yet `top` shows CPU mostly idle and the app is crawling.

    What does that combination tell you?

    The strongest answer: Linux load counts runnable and uninterruptible tasks, so this is processes stuck waiting on I/O — I look at iowait in top, `iostat -x`, processes in D state and dmesg for disk or NFS trouble

    Why it works: Right — load without CPU use means blocked tasks. Disk saturation, a hung network mount or a failing volume are the usual culprits.

    • Load counts runnable plus blocked.
    • Idle CPU and high load means I/O.
    • Check iowait, iostat, D-state.
    • Read dmesg before you resize.