Interview drill — rapid-fire across the stack + scenario walk-throughs

How a DevOps interview actually runs: rapid-fire, then the scenario

Section 1 of 5 · ~3 min

Ninety days of work only pays off if you can talk about it under pressure. A DevOps technical interview almost always takes two shapes, and they reward opposite instincts — knowing which one you’re in is half the battle.

The rapid-fire round is breadth. The interviewer fires short questions across the whole stack — “what does chmod 640 mean?”, “liveness versus readiness probe?”, “blue-green versus canary?” — and wants a quick, correct, concrete answer. The trap is treating each one as an essay. The winning pattern is crisp answer first, then one concrete detail, then stop and let them pull for more. “A readiness probe removes a pod from the Service until it can serve; liveness restarts a hung one — I used both on linkstash.” Twelve seconds, correct, and a hook they can follow. Rambling buries the right answer, and a wall of hedging reads as uncertainty even when you’re right.

The scenario round is depth and method. “The site is down — walk me through it.” “You deploy and now everything 500s.” Here they don’t much care whether you guess the cause; they care whether you have a structure. The one that never fails is a four-beat loop: check the layer — where in the stack does the symptom live, edge, app, or data? read the signal — logs, status, metrics: what is the system actually telling you? form a hypothesis — one testable guess, said out loud; verify — run the single command that confirms or kills it. If it’s killed, drop to the next layer and loop. Narrating that loop calmly beats blurting the right answer, because in the real job the answer is unknown and the loop is what finds it.

Real world: the rapid-fire round is a doctor’s reflex test — tap the knee, expect the kick, move on; a slow or rambling reflex is itself the worrying sign. The scenario round is the diagnosis: nobody wants a doctor who guesses, they want one who examines, reads the chart, forms a differential, and orders the one test that settles it.

A named example makes it concrete. The most famous scenario question in the industry is Google’s classic “what happens when you type google.com into your browser and press Enter?” It looks like trivia, but it’s the triage loop run forward: DNS resolves the name, TCP connects and TLS handshakes, an HTTP request goes out, a load balancer routes it, a server responds, the browser renders. A strong candidate walks the layers in order and stops at whatever depth the interviewer probes. That is exactly what the scenario round tests: can you traverse a whole system, one layer at a time, without losing the thread?

Both rounds run on the same fuel — the three projects you actually shipped. linkstash in Docker, then on AWS, then on Kubernetes gives you a real story behind every definition, so “what’s a readiness probe?” becomes “here’s the one I wrote, and why.” Today you drill both rounds until the crisp answer and the triage loop are reflex, not recall.

Hands-On Lab

Section 2 of 5 · ~4 min

Budget about 25 minutes. This is a drill, not a setup — the first half needs no terminal, only your voice. Part A is the rapid-fire round: read a question, cover the answers block below it, say your answer out loud in one breath, then reveal and check. Part B is one worked scenario using the four-beat loop. The goal isn’t to memorise these ten answers — it’s to feel the shape of a crisp answer and a calm triage, so any question in that shape comes out right on interview day.

Part A — rapid-fire. Say each answer out loud, then reveal the next block to check.

RAPID-FIRE (cover the answers block until you've spoken all ten):
 1. Linux: what does `chmod 640 file` set the permissions to?
 2. Processes: SIGTERM vs SIGKILL — what's the difference?
 3. HTTP: what does a 502 tell you versus a 504?
 4. Docker: image vs container, in one sentence?
 5. Docker: why not run the app as root inside the container?
 6. CI/CD: what is a blue-green deployment?
 7. AWS: security group vs network ACL?
 8. Kubernetes: what is CrashLoopBackOff telling you?
 9. Kubernetes: liveness probe vs readiness probe?
10. Terraform: what does `terraform plan` do?

CHECK YOURSELF — crisp answer + at most one detail. If yours ran long, cut it.
 1. Owner read+write, group read, others nothing — rw-r----- .
 2. TERM asks the process to stop and can be caught to clean up; KILL (9) is forced by the kernel and can't be caught.
 3. 502 = the proxy got a bad reply from the upstream; 504 = the upstream didn't reply in time. Both point past the proxy to the backend.
 4. An image is the read-only template; a container is a running instance of it with a writable layer.
 5. A container escape would land as root on the host — drop privileges with a non-root USER.
 6. Two identical environments; you cut traffic to the new one at once and roll back by cutting it back.
 7. A security group is stateful and per-instance (allow rules only); a NACL is stateless and per-subnet (allow AND deny).
 8. The container starts, exits, and Kubernetes restarts it on a growing back-off — read logs and describe for why.
 9. Liveness restarts a hung container; readiness pulls a pod out of the Service until it can serve.
10. It diffs your config against the recorded state and shows what apply WOULD change — it changes nothing.

Part B — the scenario round. The prompt: “You deploy linkstash and now every request 500s.” Don’t guess — run the four-beat loop out loud as you go. This drives the Project 3 k3s stack from Day 85; hostnames, pod suffixes and IDs are yours and will differ.

# CHECK THE LAYER — a 500 (not a 502/504) means the app itself answered, so it's the app or its data, not the edge.
curl -s -o /dev/null -w '%{http_code}\n' https://links.example.com/healthz
# 500

# READ THE SIGNAL — are the pods actually up, and what do the logs say?
kubectl get pods -l app=linkstash
# NAME                        READY   STATUS    RESTARTS   AGE
# linkstash-7c9b6d4f8-2k4mn   1/1     Running   0          4m
kubectl logs deploy/linkstash --tail=5
# sqlalchemy.exc.OperationalError: (psycopg2.OperationalError)
# FATAL:  password authentication failed for user "linkstash"

# FORM A HYPOTHESIS (say it out loud): pods are Running and answering 500 — the app is up but can't
#   authenticate to Postgres. The deploy changed DATABASE_URL and the new password is wrong.

# VERIFY — what changed in this rollout, and does undoing it fix the symptom?
kubectl rollout history deploy/linkstash
# REVISION  CHANGE-CAUSE
# 3         helm upgrade linkstash
# 4         kubectl set env deploy/linkstash DATABASE_URL=...   <- this deploy
kubectl rollout undo deploy/linkstash
curl -s -o /dev/null -w '%{http_code}\n' https://links.example.com/healthz
# 200

Read the loop back to yourself: you checked the layer (a 500 means the app answered, so skip the edge), read the signal (Running pods plus a Postgres auth error — up, but can’t reach its data), formed one testable hypothesis (the deploy set a bad DATABASE_URL), and verified it with a rollback that returned 200. That four-beat loop is the answer to every “walk me through it”: the specifics change, the structure never does.

Common Errors & Fixes

Section 3 of 5 · ~2 min

These are the interview mistakes that sink otherwise-capable engineers — not gaps in knowledge, but in delivery. Read each slowly and notice which one is your own default under pressure.

Common error: Answering a rapid-fire question with a two-minute essay instead of a crisp answer, then depth on request.

Why: rapid-fire rounds test breadth and composure across many topics; a long answer eats the clock, buries the correct part, and reads as “isn’t sure which bit matters.” An interviewer often can’t tell a right-but-rambling answer from a wrong one — both sound like uncertainty.

Fix: answer in one or two sentences — the direct answer plus one concrete detail — then stop. The silence is a cue for them to probe if they want; let them pull. Practise with a timer until the crisp version is your default, not the padded one.

How it reads to the interviewer: they start finishing your sentences or cutting in with “right, and…” — that’s the room telling you you’re over-explaining. Land the answer and pause.

Common error: Bluffing a confident but wrong answer instead of saying how you’d find out.

Why: nobody knows the entire stack, and interviewers know it. A wrong answer stated with certainty is worse than an honest one, because it signals you might do the same in a real incident — guess and act instead of check. The job is finding answers, not having them all memorised.

Fix: when you don’t know, say so and show method: “I don’t remember the exact flag, but I’d check --help or the docs and confirm it in a scratch cluster before I trusted it.” That answer often scores higher than a lucky guess, because it is the on-the-job skill.

How it reads to the interviewer: a candidate who never says “I’m not sure — here’s how I’d check” looks like they can’t tell what they don’t know, which is the scariest trait in an on-call engineer.

Common error: Freezing — or instantly guessing a random cause — on a “walk me through it” scenario because there’s no structure to fall back on.

Why: scenario questions are open-ended on purpose. Without a method the mind either blanks or jumps to a favourite culprit (“must be DNS”) and defends it — the exact anti-pattern that turns a ten-minute outage into an hour of chasing the wrong layer.

Fix: fall back on the four-beat loop every single time — check the layer, read the signal, form a hypothesis, verify — and narrate it out loud. You don’t need the right answer immediately; you need to be visibly moving toward it one layer at a time.

How it reads to the interviewer: a long silence, or someone who names a cause in the first five seconds and then can’t say how they’d confirm it. A calm “let me start at the edge and work inward” is the exact tell they’re hiring for.

DevOps Interview Questions

Section 4 of 5 · ~1 min

These four are the meta-questions this whole day drills — how to answer rapid-fire, how to open a scenario, how to tell a “broke prod” story, and the classic URL walk-through. Cover each answer, say your own version out loud first, then compare — recalling before revealing is what makes it hold up when you’re asked cold. The four questions and answers render right after this note.

Go Deeper

Section 5 of 5 · ~1 min

Optional extras if you have ~25 more minutes today:

• 10 min — Re-run the Part A rapid-fire set out loud with a timer. Anything that runs past ~15 seconds, cut it down to the crisp answer plus one detail and say it again until it fits.
• 10 min — Pick one of your three linkstash projects and draft the “tell me about a time you broke prod” answer in the STAR shape: Situation, Task, Action, Result — four sentences, ending with what you changed so it can’t recur.
• 5 min — Skim the well-known What happens when you type google.com walkthrough and note which layers you can already narrate cold from Phases 1–4, and which one you’d say “I’d look that up” for.