DevOpsInterviewPrep logo

DEVOPS · SRE · PLATFORM ENGINEERING

Modern DevOps interview questions.
Understand the decisions.

Prepare for the questions that ask how you would operate a real system. Work through deployment failures, Kubernetes behavior, reliability tradeoffs and the projects you have owned. Explore 602 worked questions across 12 topics, with concepts and course exercises to help you explain why an answer works.

Start practising free →Build a study routine

18 answers per topic open to anyone · $25 or ₹2,000, paid once, for 6 months · nothing renews

Not sure this is where to begin? Follow the map instead: the four stages of preparing, and which one your background already puts you in.

questions with worked answers
602
concepts, one idea each
33
answers carrying a diagram
330
company interview guides
32
notes from the contributor network
296

RESEARCHED FROM HIRING LOOPS AT

All 32 company guides →

YOUR NEXT STUDY SESSION

Turn an hour of reading into a decision you can defend.

For engineers who already work with Linux, cloud or deployments. Choose one weak area, work through the evidence, and finish by explaining your decision without the answer open.

  1. 15 min

    Understand the mechanism

    Read one concept. Draw the request path or control loop from memory, then check where your explanation skipped a step.

  2. 25 min

    Work a scenario

    Attempt a question or course exercise before reading the solution. Write the evidence you need, your first action and what would make you stop.

  3. 10 min

    Handle the follow-up

    Change one assumption: double the traffic, lose a zone or remove the rollback option. Explain how your decision changes.

  4. 10 min

    Record and revisit

    Keep the mistake and its correction in your notes. Reattempt it next session, then again at the end of the week.

01Public lesson

CI/CD and release safety

Produce a release approval with artifact evidence, configuration changes and a usable recovery plan.

Work the release review
02Public answer

Kubernetes reasoning

Trace a manifest to a running pod. Explain which evidence distinguishes scheduling, startup and readiness failures.

Trace the control loop
03Public concept

SRE and incident response

Define a user outcome, calculate its error allowance and decide what an active incident changes about a release.

Work the budget calculation
04Public answer

Projects and ownership

Build an evidence card from your own work: your decision, the alternative, the user impact and what you completed afterwards.

Prepare an incident story

Use five sessions for one topic: learn, practise, take a harder case, connect it to your own project, then rehearse without notes. Repeat a topic when you cannot explain the failure mechanism or verify recovery. The timings are a suggested routine; substantial course exercises need longer.

DRAWN FOR THIS SITE

The stages, the mechanism, and the mistake, in one look.

Ask anywhere what happens between kubectl apply and a running pod and you get a paragraph. Here it is also a numbered spine: what happens, in order, with the mechanism under each stage and the correction you were about to need pinned beside it. 213 pages carry one, across the questions, the concepts and the course lessons.

  • Every annotation is a claim the answer defends. A number that moves with the version, the cloud or the workload says so rather than pretending to be a constant.
  • The picture is the page. Rendered on the answer itself, in your theme, at whatever width you are reading on, rather than a screenshot of a whiteboard.
  • Trace the point where progress stops. Use the stages to explain which component owns the next action and what evidence you would inspect there.

Read the whole answer →

What happens between kubectl apply and a running pod API SERVER: THE WHOLE WRITE PATH CONTROLLERS WATCH AND ACT ON THE NODE reconcile: drift starts this again 1 kubectl apply POST the desired object 2 Authenticate who is calling 3 Authorise RBAC: may they do this verb 4 Mutating admission webhooks and defaulting 5 Validating admission policy can reject outright 6 Persist to etcd apply returns success 7 Deployment controller creates a ReplicaSet 8 ReplicaSet controller creates Pod objects 9 Scheduler filter, score, write a binding 10 kubelet on that node sandbox, CNI, CSI, image pull 11 Containers start init, then app containers 12 Readiness passes EndpointSlice updated Where a sidecar appears that nobody wrote in the manifest, and where a default resource limit is stamped on. Your command is finished here, and nothing is running. Every stage below is a controller noticing a difference, not a component calling the next one. Filters out nodes that cannot run it at all, scores what survives, and writes a node name. It starts nothing. Pending: nothing survived filtering The pod IP is allocated here, by CNI, on the node. Not by the API server and not by the scheduler. ContainerCreating: CNI, CSI or pull CrashLoopBackOff: it started and died, so read the last terminated state A pod can be in the EndpointSlice before it is ready. Readiness is what makes the proxy select it. Running, no traffic: readiness or selector
From kubectl apply to a Running Pod, in Containers & Kubernetes. Free to read, no account.

WHY THIS BANK EXISTS

The five banks we reviewed cover Linux far more deeply than GPU operations.

Our review of 5 open-source DevOps question repositories found 657 distinct Linux prompts and two on AI infrastructure. The chart uses the corroborated subset: prompts also found in another repository or in our commissioned research. None of those two AI prompts met that corroboration rule.

This measures the selected repositories, not interview frequency. Our comparison uses editorial targets for a 300-question bank. Use your target role to choose which topics deserve the most time.

The 4 categories below our comparison threshold are where this bank spends its weight. There are 200 questions here across those categories.

Read the full argument →Go straight to the GPU questions →

CORROBORATED PROMPTS / OUR TARGET MIXour questions / target ratio
  • Linux, Networking & Scripting50 / 22.2×
  • Containers & Kubernetes78 / 15.2×
  • DevSecOps & Supply Chain Security41 / 10.5×
  • Cloud Platforms & Architecture54 / 10.3×
  • CI/CD, Release Engineering & GitOps53 / 10.0×
  • Infrastructure as Code & Configuration40 / 9.0×
  • Observability, SLOs & Reliability45 / 6.1×
  • Behavioral & Leadership41 / 4.2×
  • Platform Engineering & FinOps19 / 2.4×
  • DevOps System Design & Architecture55 / 2.3×
  • Incident Response & Production Debugging71 / 1.8×
  • AI & GPU Infrastructure55 / 0.0×

Bars show corroborated prompts divided by our editorial target for each topic, on a square-root scale. The tick is 1× our target; red marks ratios below our comparison threshold. The left figure counts questions written here today.

THE SHAPE OF EVERY ANSWER

Five parts, from the first decision to the follow-up.

Anyone can find the question. What decides the round is the reply: what you lead with, how deep you go before stopping, and whether you have already thought about the thing the panel asks next. So every answer here is assembled the same way, and 330 carry a diagram, because a scheduler decision or a request path is quicker to draw than to narrate.

Grounded in researched DevOps, SRE and platform engineering interview loops, written to a senior-engineer editorial bar, and never padded to hit a word count.

  1. 01TL;DRThe main decision and its assumptions, before the detailed explanation.
  2. 02How to approach itWhere to start, what to clarify, and which evidence to inspect first.
  3. 03A strong answerThe full working: the mechanism, the numbers that matter, the command you would actually run, and a diagram where one earns its place.
  4. 04What interviewers probe nextFollow-up questions with worked responses, so you can test the limits of your first answer.
  5. 05Common mistakesPlausible mistakes and the technical reasons they fail.
  6. No filler section exists. If a paragraph would sit just as well under a different question, it is cut before it ships.See it on a real answer →

FOUR WAYS IN

Four stages. The trick is knowing which one you are actually in.

  1. 01Start here →

    Orient. Find out what the loop actually contains.

    Preparation priorities and 32 company guides. 4 carry documented outlines; confirm the details for your role.

  2. 02Read the concepts →

    Understand. One idea per page, beneath the tooling.

    33 concepts across the 12 tracks the questions assume you already hold. Read the mechanism, then follow the links into practice.

  3. 03Open the bank →

    Practise. Work the questions in the order they get harder.

    602 questions, easy through expert within a topic. Nothing is left as a prompt: each carries the worked reply, the follow-up and the failure mode.

  4. 04See the courses →

    Build. Run the thing the interview is really about.

    4 courses with worked exercises and a final design or incident review. 4 lessons are free.

THE 12 TOPICS

Every topic, and how hard it gets inside each one.

easymediumhardexpert

PREMIUM

One payment for 6 months of full-library access.

  • ✓Every one of the 602 answers. Anyone gets 216; a free account raises that to 327; Premium is the remaining 275.
  • ✓All 33 concepts, with their worked explanations and practice links.
  • ✓The 32 company preparation guides, with evidence caveats and related practice.
  • ✓Mastery tracking that keeps a running estimate of what you recall per topic, and points at the weakest one.
  • ✓Content added during your 6 months is included. Hourly reading limits apply.
$25or ₹2,000
one payment · 6 months · no auto-renewal

Available payment methods are shown at checkout. The payment provider handles card details; this site does not store them. Nothing renews automatically. Access attaches to your Google account after the server confirms payment.

Unlock the whole bank →Or carry on free: 18 per topic now, 28 once you sign in

JUST ADDED

  1. How do you keep up with a field that changes this fast? What have you learned recently?
  2. What does a DevOps engineer actually do day to day? What do you think this job involves?
  3. Tell me about yourself. You are moving into DevOps from another field, so where do you start?
  4. How do you estimate what an LLM feature will cost to run?
  5. What is an AI agent, and what makes running one different from running a normal service?
  6. What is MLOps, and what does it add to a DevOps pipeline you already have?

THE REST OF THE SITE