Phase 1 review — Linux interview drill

The Phase-1 muscle: read and operate any Linux box

Section 1 of 5 · ~3 min

Twenty days in, you have a drawer full of commands — ls, cd, cat, chmod, ps, kill, grep, sed, awk, systemctl, journalctl, ss, dig, ssh — plus your first shell scripts, git commits, and a systemd timer. Today adds nothing new. It’s the day that drawer becomes one reflex: dropped onto any Linux server, you can read it, control it, and automate it — no GUI, no panic.

The whole of Phase 1 stacks into five moves, and you now own the tools for each:

Navigate and read. Where am I, what’s here, what does this file say? pwd, ls, cd and cat/less (days 1–4) let you orient on a box you’ve never seen and read any config or log by hand.

Control. chmod/chown (day 5) fix the “it can’t write because it doesn’t own the file” class of bug; ps and kill (day 6) show what’s really running and stop the one that’s on fire.

Wrangle text. A log too big to read becomes answers: grep finds the lines, sed rewrites them, awk pulls the columns (day 8), and pipes and redirection chain them into one query (day 9).

Check services and the network. systemctl says whether a service is up and journalctl says why not (day 10); dig, ping and ss walk a request from name to open port (days 11–12); ssh (day 13) runs all of it on a box that isn’t your laptop.

Automate. A shell script turns your one-liners into something repeatable (days 15–16), git versions and shares it safely (days 17–18), and a systemd timer — the modern cron — runs it on schedule with its output in the journal (day 19).

Real world: A good field engineer can be dropped at a substation they’ve never seen and, within minutes, know what’s running, what’s wrong, and what’s safe to touch — not because they memorised that station, but because every station shares one layout. Twenty days in, a Linux box is your substation: unfamiliar hostname, identical layout. You orient, read, check, and act without panic because the map never changes.

A named example makes it concrete. When you launch an Amazon EC2 instance, AWS hands you a bare Ubuntu 24.04 box reachable only over SSH — no dashboard, no GUI, just a prompt. Everything you do to it is a Phase-1 skill: read the filesystem, fix a permission, check why nginx won’t start in journalctl, confirm port 443 is listening with ss, script the fix, commit it to git. The reason this phase comes first is blunt — every later phase, containers and Kubernetes and Terraform included, ultimately runs on exactly this box, and the interview for the job is mostly questions about it.

That reflex is why today is a drill, not a lecture. Reading the list doesn’t prove you own it — running a mixed self-check does, and saying the answers out loud does. The lab below is a rapid pass across the whole phase; the interview section drills what a Linux screening round actually asks. No new tools — just proof the muscle holds.

Hands-On Lab

Section 2 of 5 · ~2 min

Budget about 20 minutes. Open your WSL2 Ubuntu 24.04 terminal. This is a rapid self-check — roughly one command per Phase-1 skill. Run each from memory first if you can; the block you have to look up is the exact day to revise before Phase 2.

# 1. Orient (days 1–3): who am I, where am I, what kernel is this?
whoami && pwd && uname -sr
# Output:
# pushkar
# /home/pushkar
# Linux 6.6.87.2-microsoft-standard-WSL2

# 2. Files (days 3–4): build a tiny log to interrogate, then count its lines.
cat > ~/review.log <<'EOF'
10:01 INFO GET /home 200
10:02 ERROR POST /login 500
10:03 WARN GET /cart 200
10:04 ERROR GET /pay 503
10:05 INFO GET /home 200
EOF
wc -l ~/review.log
# Output:
# 5 /home/pushkar/review.log

# 3. Permissions (day 5): read the mode string, then lock the file down to 640.
ls -l ~/review.log
# Output:
# -rw-r--r-- 1 pushkar pushkar 128 Jul 11 09:14 /home/pushkar/review.log
chmod 640 ~/review.log && ls -l ~/review.log
# Output (group loses read of nothing, others lose read entirely):
# -rw-r----- 1 pushkar pushkar 128 Jul 11 09:14 /home/pushkar/review.log

# 4. Text + pipes (days 8–9): how many ERROR lines? grep finds them, the pipe feeds wc.
grep ERROR ~/review.log | wc -l
# Output:
# 2

# 5. Extract + rank (days 8–9): which status code appears most? $NF is the last field.
awk '{print $NF}' ~/review.log | sort | uniq -c | sort -rn
# Output (200 leads with three hits):
#       3 200
#       1 503
#       1 500

# 6. Processes (day 6): find the shell process and read its PID.
pgrep -a bash
# Output (PID, then the command line):
# 287 -bash

# 7. Networking (days 11–12): resolve a name to an IP the way DNS actually answers.
dig +short one.one.one.one
# Output (a stable, well-known name → IP mapping):
# 1.1.1.1
# 1.0.0.1

# 8. Git (days 17–18): version today's work, then read the history back.
git init -q -b main ~/drill && cd ~/drill
cp ~/review.log . && git add review.log
git -c user.name=pushkar -c user.email=pushkar@example.com commit -q -m "Add review log"
git log --oneline
# Output:
# a1b2c3d (HEAD -> main) Add review log

# 9. Scheduling (day 19): a fresh user has no cron jobs — the modern equivalent is a systemd timer.
crontab -l
# Output:
# no crontab for pushkar

Read those nine outputs back as one line each — you oriented, read a file, fixed its permissions, counted and ranked its lines, found a process, resolved a name, versioned the work, and checked the schedule. Any block that felt shaky names the exact day to reopen before Phase 2 begins.

Common Errors & Fixes

Section 3 of 5 · ~3 min

These three cut across the whole phase — they mix permissions, scripting, git and SSH, which is exactly how mistakes show up once the tools combine. Read the error text slowly; parsing it is the skill.

Common error: Making a first commit on a fresh box before telling git who you are:

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'pushkar@DESKTOP-4F2K9.(none)')

Why: git stamps every commit with an author name and email, and a freshly installed git has neither configured. Rather than invent one, it refuses to commit and prints the exact commands to fix it, along with the placeholder it tried to guess from your username and hostname.

Fix: Set the identity once with git config --global user.name "..." and git config --global user.email "...", or scope it to one repo by omitting --global (that’s the -c user.name=… -c user.email=… form the lab used inline).

How you’d spot it in prod: A CI job that commits generated files — a changelog, a lockfile — fails with this the first time it runs on a clean runner. The fix is a config step in the pipeline, not a human retrying by hand.

Common error: Writing a shell script, then running it straight away without an execute bit:

bash: ./deploy.sh: Permission denied

Why: Creating a file with an editor gives it read/write but not execute, so the kernel refuses to run it directly. Permission denied here is not about ownership — it’s the missing x bit from day 5, applied to a program instead of a file you want to read.

Fix: Add the execute bit with chmod +x deploy.sh, then ./deploy.sh runs. Confirm with ls -l that the mode now shows -rwxr-xr-x. (You can also run it without the bit via bash deploy.sh, which hands the file to the interpreter explicitly.)

How you’d spot it in prod: A pipeline step that clones a repo and runs a helper script fails with Permission denied because the execute bit was never committed. Either commit the mode with git update-index --chmod=+x, or invoke it as bash script.sh in the job.

Common error: Copying a private SSH key into place with the wrong permissions, then watching ssh refuse to use it:

Permissions 0644 for '/home/pushkar/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/pushkar/.ssh/id_ed25519": bad permissions

Why: A private key readable by the group or anyone else is a security hole, so OpenSSH deliberately ignores it rather than trust it. A default 644 (readable by all) trips this every time — the same permissions rule from day 5, now enforced by ssh itself.

Fix: Tighten the key to owner-only with chmod 600 ~/.ssh/id_ed25519 (and 700 on ~/.ssh). ssh then loads it and authentication proceeds.

How you’d spot it in prod: A deploy that authenticates with a key baked into an image or checked out by CI fails with bad permissions while the same key works from your laptop. The mount or checkout widened the bits — chmod 600 the key in the job before you use it.

Linux Interview Questions

Section 4 of 5 · ~1 min

These five are the highest-yield Phase-1 questions a Linux screening round actually asks — permissions, services, git, scheduling and ports, one from each corner of the phase. The answer bank renders right after this note. Cover each answer, say your own version out loud first, then compare — recalling before revealing is what makes it stick for interview day.

Go Deeper

Section 5 of 5 · ~1 min

Optional extras if you have ~30 more minutes:

• 5 min — Redo any lab block you stumbled on from memory, no notes — the one you have to look up is your revision target before Phase 2.
• 10 min — Reread the Linux for DevOps guide end to end; on this pass every command means something, and that’s where the phase consolidates into one mental model.
• 10 min — Skim the DNS and ports sections of the Networking for DevOps guide, then re-run dig +short and ss -tln until the output reads instantly.
• 5 min — Run man on the one command you leaned on most today and read its OPTIONS section — depth on your daily tools compounds faster than breadth on new ones.