DevOps interview questions
Thirteen interview questions for DevOps engineer roles — role-specific, AI, behavioral, and situational — each with what to listen for, an example answer, and red flags. No tool trivia: definitions are easy to rehearse, which makes them a weak signal on their own. These probe what actually predicts performance — incident judgment, deploy discipline, and cost awareness.
All 13 questions
Role-specific DevOps interview questions
- 01What would have to be true about your pipeline before you'd deploy on a Friday afternoon without a second thought? How close has any team of yours come?
- 02How do you decide what should page a human at 3 a.m. and what can wait until morning? Tell me about an alert you deleted.
- 03You find that production no longer matches the infrastructure code — someone changed things by hand during last month's outage. What do you do about the drift, and about the habit?
- 04Our cloud bill has doubled in a year while traffic grew maybe twenty percent. Where do you look first, and what do you usually find?
AI questions for DevOps candidates
- 05Your engineers increasingly generate infrastructure code and pipeline configs with AI assistants. What has to happen between that output and production?
- 06A vendor wants to replace your threshold alerts with AI anomaly detection. How do you decide whether to let it page your on-call?
- 07Mid-incident, an AI assistant summarizes the logs and names a probable root cause. How do you use that without getting led down the wrong path?
Behavioral DevOps engineer interview questions
- 08Walk me through the worst production incident you've owned, from the first page to the postmortem it produced.
- 09Tell me about a time an engineer's mistake caused a serious outage. What happened to the engineer, and what happened to the system?
- 10Tell me about a guardrail or platform change you introduced that developers initially resisted. How did you get real adoption?
Situational DevOps interview questions
- 11It's your company's biggest sales day of the year, and a product manager needs a revenue-affecting fix deployed mid-afternoon. What do you actually do?
- 12A developer just pushed a commit with a live cloud credential to a public repository. Walk me through your first hour.
- 13Teams have started rerunning the deploy pipeline until it goes green — failures are intermittent, and nobody trusts the red anymore. What do you do?
Questions 1–4
Role-specific DevOps interview questions
What would have to be true about your pipeline before you'd deploy on a Friday afternoon without a second thought? How close has any team of yours come?
A strong answer names concrete safety mechanisms — small batches, automated tests they trust, staged rollout, fast rollback, alerting that would catch a regression — and honestly says which of those their last team actually had.
What to look for
- Names specific mechanisms: small changes, canary or staged rollout, one-command rollback.
- Trusts the pipeline for reasons — test coverage and alert history — not optimism.
- Honest about the gap between the ideal and their last team's reality.
Example answerRed flags
Example answer
At my last company we got there in about a year. Deploys went from weekly batches to twenty small releases a day, each behind a canary that watched error rates for ten minutes and rolled back on its own. Friday deploys stopped being a debate — the pipeline didn't know what day it was.
Red flags
- Treats a Friday deploy freeze as the goal rather than a symptom.
- Confidence comes from personal heroics — "I stay online after every deploy".
How do you decide what should page a human at 3 a.m. and what can wait until morning? Tell me about an alert you deleted.
A strong answer reserves pages for user-facing symptoms that need action within minutes, routes everything else to daytime queues, and includes a real story of pruning an alert nobody ever acted on.
What to look for
- Pages on user impact and urgency, not on every threshold crossing.
- Has actually deleted or downgraded alerts, with the reasoning.
- Connects alert noise to on-call burnout and slower incident response.
Example answerRed flags
Example answer
A page means a human must act within minutes — checkout erroring, latency users can feel. CPU at 80% is a dashboard, not a page. At my last job I audited three months of pages: 60% were acknowledged and closed with no action taken, so we deleted or downgraded them. On-call went from dreaded to tolerable.
Red flags
- Has never removed an alert — every signal added stays forever.
- Talks only about tooling, never about what the on-call human experiences.
You find that production no longer matches the infrastructure code — someone changed things by hand during last month's outage. What do you do about the drift, and about the habit?
A strong answer detects drift systematically, reconciles code to reality before anything else breaks, and fixes the incentive — making the correct path fast enough that hand edits stop being tempting — rather than hunting for a culprit.
What to look for
- Reconciles deliberately: codifies the change or reverts it, never leaves both versions live.
- Treats emergency hand edits as a process signal, not an individual failure.
- Makes the pipeline fast enough that the correct path wins during the next incident.
Example answerRed flags
Example answer
First, reconcile: run a plan, see what drifted, decide change by change whether to codify it or revert it. Then the habit — someone bypassed the pipeline because it was too slow at 2 a.m., which is rational. We added a break-glass path that allows manual changes but files an issue automatically. Drift stopped recurring.
Red flags
- Focuses on who made the change rather than why the pipeline lost.
- Would revert production blindly without checking why the hand edit was made.
Our cloud bill has doubled in a year while traffic grew maybe twenty percent. Where do you look first, and what do you usually find?
A strong answer breaks the bill down by service and team before touching anything, and knows the usual suspects: oversized instances, unattached storage, forgotten environments, egress, and logging costs growing quietly.
What to look for
- Starts with attribution — tagging and per-team breakdown — before optimization.
- Names the usual offenders from experience, with rough percentages.
- Balances savings against engineering time; won't chase every small line item.
Example answerRed flags
Example answer
First, attribution — you can't fix a bill nobody owns, so I'd get tagging to where each team sees its own spend. In my experience the money hides in three places: nonproduction environments running nights and weekends, storage nobody deleted, and observability ingestion. At my last job log ingestion alone was 18% of the bill.
Red flags
- Jumps straight to reserved-instance purchases without understanding usage.
- Treats cost as finance's problem, not an engineering signal.
Questions 5–7
AI questions for DevOps candidates
2026 · AIYour engineers increasingly generate infrastructure code and pipeline configs with AI assistants. What has to happen between that output and production?
A strong answer treats AI-generated infrastructure like any junior engineer's change — plan output read line by line, blast radius understood, security defaults checked — because one bad config can take everything down at once.
What to look for
- Reads the plan or diff and can explain every resource it touches.
- Checks the defaults AI tends to fumble: permissions, public exposure, deletion policies.
- Same review bar regardless of who or what wrote the change.
Example answerRed flags
Example answer
Same gate as human-written changes, applied more suspiciously. AI configs look plausible and fail in the defaults — a storage bucket public, an IAM role wildcarded, a deletion policy missing. I read the plan output line by line, and once caught a generated change that would have recreated — briefly destroyed — our production database.
Red flags
- Trusts generated configs because "the pipeline would catch it".
- Can't name a single class of error AI makes in infrastructure code.
A vendor wants to replace your threshold alerts with AI anomaly detection. How do you decide whether to let it page your on-call?
A strong answer runs the new system in shadow mode against real incidents first, measures false positives and misses over weeks, and keeps deterministic alerts on the few signals that matter most.
What to look for
- Insists on a shadow period measured against real incident history.
- Asks how the model explains a page — on-call can't debug "anomaly detected".
- Keeps simple deterministic alerts for the highest-stakes symptoms.
Example answerRed flags
Example answer
I'd run it in shadow for a month: every alert it would have fired, logged next to what actually happened. When we did this, the tool caught one real issue early and would have paged us forty extra times. We kept it for daytime triage and left 3 a.m. paging on plain symptom thresholds.
Red flags
- Adopts or rejects it on principle, with no measurement plan either way.
- Would let an unexplainable alert page people at night.
Mid-incident, an AI assistant summarizes the logs and names a probable root cause. How do you use that without getting led down the wrong path?
A strong answer uses AI to compress information — timelines, log summaries, similar past incidents — but verifies the suggested cause against live system evidence before acting, because a confident wrong theory costs precious minutes.
What to look for
- Treats the suggestion as one hypothesis, checked against real telemetry before acting.
- Uses AI for the clerical load: timelines, comms drafts, log condensation.
- Has a story where the confident suggestion was wrong.
Example answerRed flags
Example answer
I treat it like a smart teammate shouting a theory — worth thirty seconds to check, never worth skipping verification. In one incident the assistant blamed a config change that turned out to be a red herring; the real cause was a certificate expiry two layers down. It writes my timeline and stakeholder updates, though. That part I keep.
Red flags
- Would act on the suggested fix directly to save time.
- Dismisses AI in incidents entirely, including for summaries and comms.
Questions 8–10
Behavioral DevOps engineer interview questions
Walk me through the worst production incident you've owned, from the first page to the postmortem it produced.
A strong answer shows incident command under pressure — clear roles, honest stakeholder updates, mitigation before root cause — and ends with a postmortem that changed the system, not a promise to be more careful.
What to look for
- Structured response: someone led, someone fixed, someone communicated.
- Mitigated user impact first and diagnosed second.
- The postmortem produced a system change you can point at.
Example answerRed flags
Example answer
A bad database migration locked our main table during peak hours — checkout down 47 minutes. I ran comms and coordination while two engineers worked mitigation; we restored from a replica rather than wait on the fix. The postmortem gave us migration rehearsals against a production clone, which caught two similar problems in the next year.
Red flags
- The story has no numbers — no duration, no impact, no timeline.
- Postmortem output was "we told people to be more careful".
Tell me about a time an engineer's mistake caused a serious outage. What happened to the engineer, and what happened to the system?
A strong answer holds the blameless line in practice: the engineer stayed, the postmortem asked why the system let one person's error become an outage, and a guardrail exists today because of it.
What to look for
- Blames the missing guardrail, not the person — in a real story, not a slogan.
- The engineer's later trajectory reflects a healthy culture.
- Can articulate why punishing errors makes future outages worse.
Example answerRed flags
Example answer
A teammate dropped a production table thinking he was on staging. We restored from backup in an hour. The postmortem's question wasn't why he did it — it was why staging and production credentials sat in the same terminal profile. He wrote the fix himself: color-coded prompts and a confirmation gate. He's a lead now.
Red flags
- Tells the story with contempt for the person who erred.
- "Blameless" in vocabulary, but the engineer got quietly pushed out.
Tell me about a guardrail or platform change you introduced that developers initially resisted. How did you get real adoption?
A strong answer wins adoption by making the safe path also the fast path — paved-road tooling, migration help, a pilot team — rather than by mandate, and can name adoption numbers.
What to look for
- Understood the resistance instead of overriding it.
- Made compliance cheaper than the workaround.
- Measured adoption instead of declaring victory at rollout.
Example answerRed flags
Example answer
I introduced review gates on infrastructure changes and two teams revolted — it added a day to their lead time. Fair complaint. We built pre-approved modules for the common cases so 80% of changes passed automatically, and piloted with the loudest critic's team. Within a quarter all six teams were on it voluntarily.
Red flags
- Adoption came from escalation to management alone.
- No curiosity about why developers resisted.
Questions 11–13
Situational DevOps interview questions
It's your company's biggest sales day of the year, and a product manager needs a revenue-affecting fix deployed mid-afternoon. What do you actually do?
A strong answer refuses both reflexes — neither auto-blocking nor rubber-stamping — and instead sizes the risk: what the change touches, how it rolls back, what monitoring will catch, then decides with the product manager on the record.
What to look for
- Asks what the fix touches and what waiting costs, before answering.
- Names the safeguards a peak-day deploy needs: staged rollout, eyes on dashboards, rehearsed rollback.
- Makes the risk trade-off jointly and visibly, not unilaterally.
Example answerRed flags
Example answer
Depends what it is. A copy change behind a feature flag ships; a payment-path change gets a harder look. I'd ask what waiting until tomorrow costs, deploy to 5% first with someone watching dashboards, and rehearse the rollback before we start. If it's genuinely risky, the product manager and I decide together, in writing.
Red flags
- A freeze is a freeze — no engagement with the business cost.
- Ships it because the product manager insisted, with no added safeguards.
A developer just pushed a commit with a live cloud credential to a public repository. Walk me through your first hour.
A strong answer revokes the credential immediately — before cleanup, before conversation — then checks audit logs for use, rotates the secrets the key could actually read or change, and closes with prevention: secret scanning in the pipeline and short-lived credentials.
What to look for
- Revokes first; history rewriting comes later and is treated as insufficient.
- Checks access logs to see whether the key was already used.
- Ends in prevention: pre-push scanning, short-lived credentials.
Example answerRed flags
Example answer
Minute one: revoke the key — scrapers find public credentials in under five minutes, so deleting the commit fixes nothing. Then audit logs: was it used, what could it reach? Rotate what the logs show was reachable. Then, with the developer, add pre-push secret scanning. No blame conversation; if a push can leak a key, the gap is ours.
Red flags
- First instinct is rewriting git history rather than revoking.
- Frames the whole hour around disciplining the developer.
Teams have started rerunning the deploy pipeline until it goes green — failures are intermittent, and nobody trusts the red anymore. What do you do?
A strong answer treats a distrusted pipeline as an outage of its own: quantify the flake rate, quarantine the worst offenders visibly, fix or delete them, and restore the norm that red means stop.
What to look for
- Measures which tests or stages flake and how often, before moralizing.
- Quarantines flaky tests openly instead of letting reruns hide them.
- Understands the cultural cost: every ignored red trains people to ship blind.
Example answerRed flags
Example answer
That's a broken smoke detector — worse than none, because it feels like coverage. I'd pull two weeks of pipeline data and rank stages by flake rate; it's usually a handful of timing-dependent tests and one under-resourced runner. Quarantine those visibly, fix or delete each within a sprint, and track rerun counts until they hit zero.
Red flags
- Responds with a policy memo banning reruns while the flakes remain.
- Accepts flakiness as inherent to integration testing.
Scoring rubric
| Score | Evidence anchor |
|---|---|
| 1 | Recites tool names and definitions. No incident stories, no numbers; deploys and outages described only in the abstract. |
| 2 | Has operated real systems but reacts rather than designs: alerts stay noisy, deploys stay scary, and AI questions get buzzwords or a shrug. |
| 3 | Solid operator: diagnoses before acting, has owned at least one incident end to end, and applies a real review bar to infrastructure changes regardless of author. |
| 4 | Strong across all four sections: designs guardrails developers actually adopt, prunes alerts and costs with evidence, and verifies AI output through a specific, tested routine. |
| 5 | Platform thinker who teaches you something: numbers from their own incidents and bills, a paved-road philosophy that made whole teams ship faster, and a tested point of view on where AI belongs in operations. |
Frequently asked questions
Which devops engineer interview questions work for a first-round interview?
The credential-leak scenario, the 3 a.m. paging question, and one AI question give a strong 20-minute signal — they're hard to bluff. Kira can run this subset as a voice interview with every applicant before you spend an engineer's hour.
What should senior devops interview questions add to this set?
Scope, mostly. Ask the same questions but push each answer up a level: incidents they commanded rather than joined, platforms other teams build on, guardrails set org-wide. A senior with only participant stories is mid-level with tenure.
What do strong devops interview questions and answers have in common?
Numbers and consequences. Strong answers carry deploy frequencies, outage durations, and bill percentages, and end with something that changed. Questions that admit a memorized textbook answer — define this tool, explain that acronym — predict almost nothing.
Can a hiring team without deep DevOps expertise use these questions?
Yes — each question comes with what to listen for and red flags that need no operating experience to spot: missing numbers, blame-shifting, fixes proposed before any diagnosis. For the final round, add one practicing engineer to the panel.
Why are there no Kubernetes or Terraform trivia questions here?
Definitions are the easiest answers to memorize and the first thing candidates can rehearse with AI. Judgment about incidents, deploy risk, and cost has to come from experience — and it transfers to whatever stack you actually run.
Seniority notes
- Junior (0–2 years)
- Weight the role-specific section, accept lab or home-lab evidence in place of war stories, and probe whether they understand why each safeguard exists rather than reciting that it should.
- Mid-level (2–5 years)
- The full set applies as written — expect at least one owned incident with real numbers, and honest answers about the gaps in their current team's pipeline.
- Senior (5+ years)
- Senior DevOps interviews should probe scope: systems owned end to end, incident command rather than incident participation, and platform decisions that changed how other teams ship.