DevOps interview questions: reliability & postmortems
Reviewed by Mark Dickie · Last updated
10 questions on this page you can answer and see marked on the spot. Go to the first one
DevOps postmortems are structured reviews written after an incident to reconstruct the timeline, identify contributing causes, and record action items that prevent recurrence. For a reliability-focused DevOps interview, expect questions on SLOs and error budgets, how you run a blameless postmortem, the difference between correlation and cause, and how you prioritise remediation work against feature delivery. Interviewers want to see that you treat incidents as system failures, not people failures, and that you can turn a retrospective into concrete, owned, time-bound fixes.
The core areas you should be ready to answer on are below.
| Area | What an interviewer probes |
|---|---|
| SLOs & error budgets | How you set availability targets, define burn rate, and decide when to freeze features |
| Incident response | On-call structure, escalation paths, and how you communicate during a major outage |
| Postmortem process | Who writes it, who reviews it, and what a good one looks like |
| Root-cause analysis | Five whys, contributing factors, and the trap of stopping at a single cause |
| Remediation tracking | How action items get owners, deadlines, and follow-through |
What does a DevOps reliability interview typically ask?
- Walk through an incident you responded to end to end, including detection, mitigation, and what you changed afterward.
- Define an SLO and an error budget for a specific service, and explain what happens when the budget is spent.
- Describe how you run a blameless postmortem and how you keep the discussion focused on systems rather than individuals.
- Give an example of a postmortem action item that was too vague to act on, and how you would rewrite it.
- Explain how you balance remediation work against new feature work when the team is under delivery pressure.
How should you frame postmortem answers in an interview?
Talk about the system, not the person. A strong answer names the contributing factors in order, shows how each one alone would not have caused the outage, and connects each remediation item back to a specific layer of the system. Mention that you publish postmortems widely so other teams can learn from them, and that you track action items in the same issue tracker as feature work so they are not quietly dropped. If you have a concrete example of an error budget policy that paused deploys, use it; specifics beat generalities here.
Key facts
- Tarmac's DevOps interview questions cover 23 questions at difficulty 1–5 of 5.
- Tarmac tracked 2,209 job postings asking for DevOps in September 2026.
- Roles asking for DevOps advertise a median base salary of £80,000, across 763 job postings as of September 2026.
- Tarmac last reviewed these DevOps interview questions on 13 October 2026.
At a glance
| Questions | 23 |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | True / false, Short answer, Flashcard, Ordering, Multiple choice |
What you'll review
- postmortems
- incident response
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
In a postmortem, each action item should have a named owner and a target completion date.#
Options
Show answer
True. Every postmortem action item should name a specific owner and a target completion date. Items without an owner and a due date are easy to lose track of and often stay unfinished, so assigning both keeps corrective work tracked to completion.
Action items with no owner and no due date are easy to lose track of and often never get finished. Giving each one a specific person and a concrete completion date is standard postmortem practice, because it makes the corrective work trackable until it is done. The statement is therefore true.
What is the primary purpose of a blameless postmortem in DevOps?#
Show answer
A blameless postmortem focuses on identifying the systemic, tooling, and process factors that contributed to an incident so the team can implement action items that prevent recurrence, without assigning personal blame to individuals.
The question asks for an open-ended purpose, not a choice among given options, so it stays a short answer. A blameless postmortem shifts the focus from individual fault to systemic improvement: it examines the process, tooling, and system conditions that let an incident happen, and produces action items that prevent it from happening again. Keeping people from being blamed is the means that makes honest, complete incident analysis possible, not the end goal.
What is a blameless postmortem, and what is its core principle?#
Show answer
Blameless postmortems focus on identifying systemic causes and process failures rather than assigning personal blame, so that teams feel safe surfacing issues and learning from them.
A blameless postmortem shifts attention from individual fault to systemic improvement. The core principle is that people operate within systems; if you punish individuals, they hide problems, so removing blame encourages honest disclosure and better learning.
True or false: a blameless postmortem means that no one is held accountable for an incident.#
Options
Show answer
False. A blameless postmortem does not mean nobody is accountable for an incident. It shifts accountability from individuals to the systems, tooling, and processes that allowed the failure, and the team still assigns owned, time-bound action items to fix those gaps and prevent recurrence.
The statement is false. A blameless postmortem moves the focus of accountability from the individual who triggered the incident to the systems, tooling, and processes that allowed it to happen. The individual is not scapegoated, but the organisation still takes responsibility by assigning concrete action items, each with an owner and a deadline, to close the systemic gaps and prevent recurrence. Accountability is redirected, not eliminated.
In a blameless postmortem culture, what is the primary objective when reviewing an incident that caused a customer-facing outage?#
Show answer
The primary objective is to learn from the incident by identifying the systemic or organizational root causes without assigning individual blame, and to produce concrete preventive actions or remediation items that reduce the likelihood or impact of a recurrence.
A blameless postmortem deliberately separates the incident from personal fault so participants are candid. The goal is not punishment or simply re-testing systems, but learning: understanding how the system allowed the outage to happen (systemic causes such as missing alerts, unsafe defaults, or process gaps) and then implementing preventive improvements, such as remediation items, guardrails, or runbook changes, so that the same failure mode is less likely or less damaging next time.
In JavaScript, what value does typeof null evaluate to, and what is the historical reason for this behavior?#
Show answer
typeof null evaluates to 'object'. This is a long-standing bug from JavaScript's original implementation: values were stored with a type tag in the lower bits, the object type's tag was 000, and null was represented as a null pointer (0x00), which matched the object tag. The behavior was kept for backward compatibility and is now codified in the ECMAScript specification.
typeof null returns the string 'object' in JavaScript. In the original implementation, values carried a type tag in their lower bits, and the object type used the tag 000. Because null was represented as a null pointer (0x00), it matched the object tag, so typeof reported 'object'. The result was preserved for backward compatibility and is now specified in ECMAScript, so typeof null is still 'object' today.
Put these steps of the standard incident postmortem lifecycle in order, from earliest to latest.#
Put these in order
Show answer
The standard postmortem lifecycle runs: stabilize and resolve the incident, write the draft postmortem, hold the blameless review meeting, then assign and track remediation action items. Each stage depends on the previous one, since a review needs a written draft and action items come out of the review.
The lifecycle has a strict dependency chain. The incident must be stabilized and resolved before the team can write a factual account of it. The draft must exist before stakeholders meet to review it. Remediation action items come out of the review discussion, so they are assigned and then tracked to completion afterward. Swapping any adjacent pair breaks a dependency: a review cannot examine a document that has not been drafted, and action items cannot be identified before the review that produces them.
A deployment script lacked an automated guardrail that would have rejected an invalid configuration. An engineer ran the script, and the bad config reached production, causing a 30-minute outage. In a blameless postmortem, which framing reflects the correct approach?#
Options
Show answer
In a blameless postmortem, the missing automated guardrail should be named as the systemic root cause, not the engineer who ran the script. Any engineer running that script could have triggered the same outage, so the fix is adding validation that rejects invalid configuration before it reaches production.
Blameless postmortems look for causes in systems and processes rather than in the individual who triggered a failure. The script lacked a guardrail that would have rejected an invalid configuration, and because any engineer running that script could have caused the same outage, the gap lives in the system. The correct framing identifies the missing automated validation as the systemic root cause and addresses it so the failure cannot recur for anyone. Attributing the incident to the engineer's error, disciplining them, or dismissing the outage because it was short would leave the underlying vulnerability in place.
What makes a postmortem 'blameless', and why does blamelessness make an organization more reliable rather than less accountable?#
Show answer
A blameless postmortem reviews an incident by focusing on the systems, processes, and contributing causes that let the failure happen, never on punishing the individual who happened to trigger it. It assumes people act reasonably given the information, tools, and pressures they had at the time, so the question is 'what about the system made this mistake easy and its consequences severe?' rather than 'who screwed up?'. The payoff is psychological safety: when engineers know they won't be blamed, they report incidents and near-misses honestly and in full detail, which surfaces the real root and contributing causes instead of a sanitized story. That honest signal is what lets the team fix the system — add guardrails, automation, better alerts, safer defaults — and file durable, tracked action items that prevent recurrence. Blame does the opposite: it drives reporting underground, so the same latent failure stays hidden and recurs. Blamelessness is about accountability to fixing the system, not the absence of accountability.
Blamelessness shifts the postmortem's question from 'who caused this?' to 'what about our systems and processes made this failure possible and its blast radius large?'. It rests on the assumption that people generally do their best with the context they had, so a human error is treated as a symptom of a system that allowed it (a missing guardrail, a confusing UI, an alert that fired too late), not as the cause to be punished. The reliability payoff is mechanistic, not soft: blame creates fear, fear suppresses honest reporting, and suppressed reports hide the real contributing causes — so the latent fault recurs. Remove blame and you get psychological safety, which produces candid, detailed accounts that reveal the true systemic gaps, which in turn become concrete, tracked action items (automation, safer defaults, better detection) that actually prevent recurrence. A strong answer stresses systems-over-individuals, psychological safety enabling honest reporting, and that accountability is redirected to fixing the system, not removed.
Order the phases of a well-run production incident, from the moment something breaks to the work that prevents a recurrence.#
Put these in order
Show answer
A well-run incident moves through five phases in order. Detect: an alert tied to an SLI, or a user report, signals the service is out of bounds. Triage and declare: assess severity, declare an incident, and assign an incident commander. Mitigate: restore service by the fastest safe lever — roll back, fail over, or flip a flag — before chasing root cause. Resolve: confirm the SLI is healthy and stand the incident down. Postmortem: run a blameless review, find contributing causes, and file durable action items so it can't recur.
Incident response follows a deliberate order. First you must detect the problem — ideally an automated alert wired to an SLI breach, not a customer tweet. Then triage and declare: size up impact and severity, formally declare an incident so the right people engage, and name an incident commander to coordinate (separating coordination from hands-on debugging). Next comes the phase juniors most often get wrong: mitigate before you diagnose. The first duty is to stop user pain by the fastest safe lever — roll back the last deploy, fail over to a healthy region, or disable the feature flag — even if you don't yet understand the root cause. Only once the bleeding stops do you resolve: verify the SLI is back in bounds and stand the incident down. Finally, after the adrenaline fades, the postmortem extracts lasting value through a blameless review that identifies contributing causes and produces tracked action items so the same failure can't recur. The two classic mistakes are chasing root cause before mitigating, and skipping the postmortem so nothing is learned.
A team experiences a 45-minute outage when a single misconfigured load balancer rule directs all traffic to a backend that was being decommissioned. After resolving the incident, the team lead says: “We'll find out who pushed that bad config and make sure it doesn't happen again.” Which statement best describes why this approach conflicts with a blameless postmortem philosophy?#
Options
Show answer
A blameless postmortem focuses on systemic conditions — not individual culpability. The team lead's framing redirects attention to “who pushed the bad config,” which undermines the psychological safety needed for honest root-cause analysis. The real question is why the system allowed a decommissioned backend to receive traffic and why no guardrail caught the misconfiguration before it reached production.
The core of a blameless postmortem is to examine the systemic conditions — missing guardrails, inadequate process, lack of automated checks — that made it easy for a well-intentioned engineer to make a mistake and hard for that mistake to be caught before causing customer impact. The team lead's framing redirects energy toward identifying the individual who pushed the config, which suppresses the psychological safety required for honest root-cause analysis and discourages engineers from reporting problems openly. The option about monitoring gaps identifies one possible contributing factor but misses the central conflict: the approach focuses on who rather than why the system allowed it. The option about the vendor's documentation introduces an external cause that the scenario does not describe, and the option about a one-hour duration threshold asserts a principle that does not exist — there is no universal minimum incident duration required to conduct a postmortem.
In the context of incident postmortems, what distinguishes a well-formed remediation action item from a vague one? Provide a brief example of each.#
Show answer
A well-formed action item is specific, has a named owner, and is trackable to completion, ideally with a due date. For example: "Add a CI check that fails when a load balancer rule references a backend marked for decommissioning (owner: Alice, due: March 15)." A vague action item is unactionable and unverifiable, such as "Be more careful when editing load balancer rules" or "Improve our monitoring."
A well-formed remediation action item names a specific owner, describes a concrete and verifiable change, and has a due date or tracking mechanism so its completion can be confirmed. Vague items like "be more careful" or "improve monitoring" are unactionable because they cannot be implemented, tested, or marked complete; they depend on individual diligence rather than a systemic change. The CI check example is concrete, assignable, and verifiable, which is what makes it effective.
Which statement correctly describes the core principle behind a blameless postmortem?#
Options
Show answer
A blameless postmortem identifies systemic contributing factors, such as missing safeguards, tooling gaps, or unclear runbooks, rather than assigning personal blame. It assumes engineers acted in good faith with the information they had. This keeps participants candid, so the review surfaces real root causes and actionable fixes.
A blameless postmortem focuses on systemic contributing factors instead of individual fault. It rests on the assumption that engineers acted in good faith with the information, tools, and context they had at the time. This shifts the investigation toward causes like missing safeguards, inadequate tooling, and unclear runbooks. Blame-focused reviews make participants defensive, reduce information sharing, and yield less actionable findings. The options that assign responsibility to the triggering engineer, presume negligence, or avoid questioning decisions all contradict this principle.
After a production incident, your team conducts a blameless postmortem. Explain why removing individual blame is considered essential to the effectiveness of a postmortem, and identify two concrete outcomes a well-run postmortem should produce beyond merely documenting the timeline of events.#
Show answer
Removing individual blame is essential because it creates psychological safety: when people know they will not be punished for honest disclosure, they provide accurate, complete information about what occurred, which is necessary to uncover the true contributing factors. Most incidents stem from systemic vulnerabilities, such as interactions among tooling, processes, deployment practices, and the operating environment, rather than a single person's mistake. Blaming individuals suppresses the candor needed to find those systemic issues. Two concrete outcomes beyond the timeline are: (1) a prioritized list of action items with named owners and due dates that address the systemic root causes uncovered during analysis, and (2) identified gaps in detection, alerting, or runbooks that should be remediated to reduce time-to-detect or time-to-mitigate for similar future incidents.
Blameless postmortems rest on the premise that incidents are almost always the product of systemic conditions, such as misconfigured alerts, ambiguous runbooks, missing guardrails, and competing incentives, rather than individual carelessness. When blame is assigned to a person, teammates become defensive, withhold details, and the systemic causes go unfixed, making recurrence likely. Psychological safety is the mechanism that unlocks the honest, detailed reporting needed for accurate learning. Beyond the timeline, a strong postmortem produces (1) concrete, owned action items targeting the systemic causes and (2) improvements to detection, alerting, or mitigation so the organization recovers faster next time. These outcomes turn a postmortem from a documentation exercise into a reliability investment.
In a blameless postmortem for a major production outage, an executive demands that the team identify 'the root cause.' An experienced SRE pushes back, arguing that searching for a single root cause is an anti-pattern in modern SRE practice. Give two distinct reasons why the singular 'root cause' framing is considered counterproductive in complex sociotechnical systems, and name the alternative framing that SRE culture recommends instead.#
Show answer
First, in complex sociotechnical systems, incidents almost always emerge from multiple interacting contributing factors. A single root cause rarely exists, and stopping at one leaves latent systemic vulnerabilities unaddressed. Second, the 'root cause' framing tends to drive toward individual accountability and blame rather than systemic understanding, which suppresses the honest disclosure needed to improve the system. SRE culture instead recommends framing incidents in terms of contributing factors and proximate causes, and focusing on how the system as a whole failed to prevent or detect the problem rather than on who made the triggering mistake.
This question tests senior-level understanding of why 'root cause' is a problematic concept in SRE. The two distinct reasons are: (1) complex sociotechnical systems fail through multiple interacting factors rather than a single cause, a point developed in resilience engineering literature (Hollnagel, Woods, Allspaw); and (2) the 'root cause' framing naturally drives toward individual blame, which undermines the psychological safety needed for honest incident reporting. The recommended alternative is to analyze contributing factors and systemic conditions, examining how the system allowed or failed to prevent or detect the failure, rather than searching for a single triggering event. A strong answer names contributing factors as the alternative framing, identifies blame as the cultural problem, and mentions multiple causes, system complexity, or systemic conditions.
You are the SRE lead at a company that has grown from 30 to 200 engineers across 15 teams. Postmortems currently happen ad hoc: some teams write thorough blameless write-ups, others skip them entirely. Action items live in scattered spreadsheets nobody checks, and the same incident classes recur quarter after quarter. Leadership wants a company-wide postmortem program that scales without becoming bureaucratic theater. Design the program. Specify (1) the triggering criteria, (2) the structure of the postmortem itself, (3) the action-item lifecycle, including how overdue items are tracked and escalated, (4) cross-team learning mechanisms, and (5) how you will measure whether the program is actually working.#
Show answer
Triggering: a postmortem is mandatory for any incident that meets at least one criterion: customer-visible degradation over 15 minutes, data loss or corruption, a security breach, or an incident that paged more than one team. Near-misses are encouraged but optional. This keeps volume around 2-5 per week across 15 teams. Structure: a neutral facilitator who was not on call runs a blameless review within 5 business days. The write-up uses a standard template: impact summary, factual clock-time timeline with no attribution language (the deploy, not a person's name), contributing causes framed as systems and processes, action items with a single owner and due date, and a what-went-well / what-didn't section. Action-item lifecycle: each item is a ticket in the team's tracker tagged 'postmortem-action-item', with one owner, a default 30-day due date (extendable with written justification), and a priority. A weekly dashboard queries all tagged tickets across teams and surfaces overdue items to the SRE lead and the owning engineering manager; an item overdue by two weeks escalates to the team's director. An item judged unnecessary can be closed only with a documented reason in the ticket, never silently dropped. Cross-team learning: every postmortem is published to a searchable central wiki with a consistent tagging scheme (service, incident type, root-cause category). A monthly 45-minute review forum with rotating attendance (two people per team) looks for trends and recurring root-cause categories, checks whether past action items addressed them, and surfaces cross-team dependencies; its output is a short list of systemic themes for next quarter's reliability work. Measurement: (1) action-item completion rate, target 80%+ within 30 days; (2) recurring-incident rate, the fraction of incidents whose root-cause category appeared in a postmortem in the prior 12 months, trending down; (3) MTTR trend, to verify learning is speeding response; (4) postmortem coverage, the share of qualifying incidents that received a postmortem, target 95%+. A coverage drop triggers an investigation into ceremony overhead, unclear criteria, or under-resourced teams. The test of success is whether the data shows the organization is learning, not just writing documents.
This is an open design question with no single correct answer, so it stays a SHORT_ANSWER graded against its key. It tests whether a candidate can go beyond 'write blameless postmortems' and name concrete mechanisms: explicit triggering thresholds, a template with systems-focused causes, a tracked action-item lifecycle with owners, due dates and escalation, a searchable cross-team repository and review forum, and metrics such as completion rate, recurrence, MTTR and coverage that test whether the program itself works. A strong answer names a specific mechanism for each area rather than principles alone.
A team has run blameless postmortems for 6 months across 30 incidents. They have generated 140 action items but closed only 22. Mean time to recovery (MTTR) has not improved over the same period. Which change best addresses the gap between postmortem findings and measurable reliability improvement?#
Options
Show answer
Assigning each postmortem action item a single named owner, with remediation due dates and escalation for overdue high-priority items, closes the gap between postmortem findings and reliability work. A team with 140 items and only 22 closed has a follow-through problem, not an analysis problem, so ownership and deadlines matter more than broader or blame-focused analysis.
The data points to a follow-through problem, not an analysis problem: 30 postmortems producing 140 action items shows incidents are being diagnosed, but only 22 of 140 items are closed, and flat MTTR shows the remediations are not changing operational outcomes. Assigning each item a single named owner, triaging by severity so the highest-impact work comes first, and setting due dates with escalation for overdue high-priority items closes the loop between postmortem output and reliability work. Expanding to near-misses would add more items on top of an already large unclosed backlog. Naming individuals abandons the blameless principle, which exists so engineers report honestly, and it does nothing for the backlog. Routing items to a shared team queue diffuses accountability, which is the opposite of what the closure gap requires.
Design a blameless postmortem program for a 200-engineer organization running 50+ microservices in production with 3–5 SEV-1/SEV-2 incidents per month. Your design must specify: (1) objective criteria for when a postmortem is triggered, (2) who facilitates and how the blameless principle is enforced in practice, (3) how action items are tracked, prioritized, and held accountable to completion, (4) how lessons learned are disseminated to engineers who were not in the postmortem room, and (5) how you measure whether the program itself is effective at improving reliability over time. Address how you would handle a systemic root cause that recurs across multiple postmortems.#
Show answer
Our postmortem program operates as follows. Triggers: Any SEV-1 (customer-facing outage, data loss, or revenue impact) or SEV-2 (degraded service for >30 min or internal outage affecting >10% of users) incident automatically triggers a postmortem. The on-call SRE who responded opens the postmortem doc within 48 hours. Near-misses that nearly reached SEV-2 are optionally reviewed in a lightweight format. Blameless facilitation: Postmortems are facilitated by a trained, neutral facilitator, never the incident commander or anyone who made a decision during the incident. The facilitator reconstructs the timeline from objective artifacts: PagerDuty alerts, Slack threads, deployment logs, and monitoring dashboards. At the start of each session, the facilitator explicitly states the blameless principle: we assume everyone acted with good intent given the information available at the time, and we are here to understand what happened and why, not to assign blame. Action item tracking and prioritization: Action items are filed in a dedicated Jira project with these fields: a single named owner (never a team), a severity (P0 = prevents recurrence of SEV-1, P1 = mitigates recurrence, P2 = improves resilience), a due date (P0: 2 weeks, P1: 1 month, P2: 1 quarter), and a link to the originating postmortem. A weekly SRE leadership review checks for overdue items and escalates at-risk P0/P1 items to the relevant engineering manager. The escalation path is: SRE lead, then engineering manager, then VP of Engineering for items more than 2 weeks overdue. Knowledge dissemination: Completed postmortems are published to an internal wiki within one week. We maintain a searchable database (for example Notion) tagged by service, incident type, and root-cause category. Monthly postmortem review sessions present 1–2 recent incidents to the broader engineering org. New engineers read a curated set of 10 historical postmortems during onboarding. Effectiveness measurement: Quarterly metrics: (1) action item closure rate by severity (target: P0 >90%, P1 >75% within SLA); (2) recurrence rate, the percentage of incidents whose root-cause category matches a category from a postmortem within the prior 12 months (target: declining trend); (3) MTTR trend by service to verify learnings reduce recovery time. Systemic recurrence: If the same root-cause category appears in 3+ postmortems within a quarter, the SRE team files a systemic remediation proposal that is reviewed by the VP of Engineering. This proposal bypasses the normal team-level prioritization and is treated as a cross-org initiative with its own budget and timeline, because repeated recurrence signals that the fix exceeds any single team's capacity to address.
This design exercise tests a senior engineer's ability to design the full socio-technical system around postmortems: not just the meeting format, but the organizational machinery that turns learnings into lasting changes. A complete answer addresses all five required dimensions (triggers, facilitation and blameless enforcement, action-item accountability, dissemination, and effectiveness measurement) with concrete, operational detail, and also gives a specific mechanism for systemic recurring root causes.
You are joining a 200-engineer SaaS company as the first Site Reliability lead. The company has no formal postmortem process. When incidents happen, on-call engineers write a quick Slack summary and move on. The same classes of outage (cascading failures from a misconfigured deploy, lost customer data from a botched migration) recur every few months. Leadership has asked you to design a blameless postmortem program from scratch. Describe the end-to-end process: what triggers a postmortem, how it is conducted, how action items are tracked to completion, and how organizational learning compounds over time. Address how you will measure whether the program is actually working.#
Show answer
I would build a blameless postmortem program around four pillars: clear triggers, a structured but lightweight writing process, action-item accountability, and cross-team knowledge sharing. Triggering: a postmortem is mandatory for any user-visible outage whose SLO error budget burn rate exceeds 2x in a rolling 30-day window, any data-loss event, any P1 security incident, and any near-miss where one additional failure would have caused an outage. Team leads can also voluntarily request a postmortem for incidents below these thresholds. Process: within 5 business days of the incident, the incident commander drafts a postmortem in a shared template (timeline, impact, root causes, contributing factors, action items). The review meeting is held within 7 days, is attended by the service owners and on-call engineers involved, and is explicitly framed as systems-level analysis: no blame, no 'who did it.' The focus is 'what conditions made this failure possible?' Action items: every action item has a single named owner, a due date (default 30 days), and a linked ticket referenced from the postmortem. A weekly SRE steering review triages overdue action items and escalates chronically overdue ones to engineering leadership. Learning compounds through a searchable archive of postmortems, a recurring cross-team review of common root-cause categories, and new-hire training built from past incidents. Program health is measured by: (1) recurrence rate, the percentage of postmortems whose root cause category matches one from a prior postmortem in the preceding 12 months (target: declining trend); (2) action-item completion rate within SLA (target above 80%); (3) mean time to postmortem completion (target under 7 days); and (4) a quarterly survey of engineers on whether the process feels blameless and valuable. If recurrence rate stops declining, the action items are not addressing root causes and the program needs recalibration.
This is an open-ended design question with no single correct answer, so it stays a SHORT_ANSWER graded by keywords and by a reviewer against the sample answer. A strong answer covers triggers, a blameless review process, owned and tracked action items, how knowledge compounds, and measurable health metrics such as recurrence rate and action-item completion. The keywords check for the core vocabulary (blameless, action item, owner) and for at least one concrete trigger or measurement term.
In a blameless postmortem for a 47-minute outage, a deploy pushed a malformed configuration that bypassed canary. The cause was that the canary-to-production promotion gate auto-approved after 5 minutes had elapsed, regardless of any canary error-rate or latency signal. The on-call engineer took 12 minutes to roll back after the first page fired. Which of the following is the systemic (latent) failure condition, meaning the defect that must be corrected to prevent recurrence, as opposed to a proximate cause, a downstream symptom, a contributing factor, or a proposed compensating control?#
Options
Show answer
The systemic (latent) failure condition in this outage is a canary-to-production promotion gate that auto-approves a release after five minutes of elapsed time, without checking canary error-rate or latency signals. The malformed configuration was the proximate trigger, while the outage duration, the slow rollback, and a proposed manual-approval step are symptoms, contributing factors, or remediations rather than the defect itself.
The systemic (latent) failure condition is the design defect that lay dormant in the system and allowed the incident to occur: the canary-to-production promotion gate treated elapsed time alone as a sufficient promotion signal and ignored health metrics. The malformed configuration is the proximate cause, the specific bad input that triggered the incident. The 47-minute outage duration is a downstream symptom, the measured impact. The 12-minute rollback delay is a contributing factor to outage duration, not the defect that let the bad deploy bypass canary. Adding manual approval before every production deployment is a proposed compensating control, a remediation idea rather than the latent defect itself. Only the gate's elapsed-time-only logic is the condition whose correction, requiring health-signal verification before promotion, prevents recurrence.
You are the Staff SRE responsible for reliability across a 200-engineer organization running 15+ microservices. The team writes postmortems after major incidents, but an internal retrospective reveals three problems: (a) action items are frequently dropped or never closed, (b) the same classes of incidents recur across different teams, and (c) engineers are increasingly reluctant to surface their own mistakes in postmortems. In a short written answer, describe a postmortem and reliability-learning program that addresses all three. Your answer must cover: (1) the postmortem process itself and how it preserves psychological safety, (2) how action items are tracked, owned, and driven to closure, (3) how cross-cutting systemic patterns are identified across services and teams, and (4) how you measure whether the program is actually improving reliability over time.#
Show answer
I would build the program on four pillars: a blameless process, a durable action-item accountability loop, cross-cutting pattern analysis, and program-level metrics. (1) Process and psychological safety: every major incident (P1/P2 or customer-visible) gets a blameless postmortem within 72 hours, facilitated by a trained SRE from a team other than the one that caused the incident, which removes the pressure to self-protect. The write-up is timeline-first, reconstructed from monitoring, dashboards and chat logs, and identifies systemic contributing factors (missing alerts, fragile dependencies, deploy gaps) rather than individual blame. Safeguards include a written blameless norm that leadership signs and reinforces, an explicit rule that postmortem participation and action items are excluded from performance reviews, and leaders publicly sharing their own postmortems to model vulnerability. (2) Action items: every item gets a single named owner, a priority and a due date in a shared reliability tracker. The SRE team reviews open items weekly; items more than 30 days overdue escalate to the owning team's lead, and items more than 60 days overdue go to a monthly engineering-leadership reliability review. Completion rate by team is published on a dashboard so ownership is visible without being punitive. (3) Pattern detection: each postmortem is tagged with a fixed incident taxonomy (for example dependency failure, deployment-related, capacity exhaustion, config drift, alerting gap) plus the services and shared infrastructure involved. A quarterly cross-postmortem review aggregates these tags; if a large share of incidents across several teams trace to one shared dependency, that becomes a single prioritized platform investment instead of several scattered action items. (4) Metrics: MTTR trend over rolling 90-day windows to show whether response and recovery are improving; action-item completion rate (closed by due date) to show follow-through; same-class recurrence rate per tagged category per quarter to show whether systemic patterns are actually fixed; and the percentage of qualifying incidents that receive a postmortem within 72 hours to confirm the process is applied consistently.
This is an open design question with no single defensible key, so it stays a SHORT_ANSWER graded against the sample answer and keywords. A strong answer must address all four required parts: a blameless, timeline-first postmortem process with safeguards for psychological safety; named owners, due dates and escalation for action items; a shared incident taxonomy with cross-team pattern review; and concrete metrics such as MTTR trend, action-item completion rate, and same-class recurrence rate. The keywords check for the core ideas: a blameless process, single owners with due dates, and at least one measurable reliability outcome.
In blameless postmortems for software incidents, James Reason's accident causation model (the 'Swiss Cheese' model) distinguishes 'active failures' from 'latent conditions.' Which statement correctly captures this distinction?#
Options
Show answer
Active failures are the immediate unsafe acts committed by people or automated actors in direct contact with a system. Latent conditions are dormant design, construction, or management decisions made earlier that create the preconditions for those acts to cause harm. In Reason's Swiss Cheese model, latent conditions sit unnoticed until an active failure passes through the gaps they create.
The correct statement describes active failures as unsafe acts with immediate effects, committed by people or automated actors at the sharp end, and latent conditions as dormant decisions from design, construction, or management that create the preconditions for failure. This is the textbook formulation of Reason's model: a misconfigured deployment is an active failure, while the missing dependency documentation that made it possible is a latent condition that lay dormant until the active failure passed through the holes in the defenses. The option describing response-phase actions versus later review findings confuses process steps with the causal nature of the distinction. The option equating active failures with coding bugs and latent conditions with infrastructure defects loses the human and organizational dimension. The option calling active failures human errors by definition contradicts the blameless principle's focus on systemic analysis and ignores automated actors. Its counterpart, that latent conditions are the only causes worth analyzing, is also wrong because the model treats both as necessary parts of an accident.
You are the Head of SRE at a company with ~200 engineers across 15 product teams. Postmortems today are ad hoc: some teams write thorough ones, others skip them entirely, and the same classes of incident recur across teams because learnings never spread. The current action-item closure rate is roughly 30%. Leadership wants a structured, organization-wide postmortem program that (a) maintains a blameless culture across teams of varying maturity, (b) ensures action items are owned, tracked, and completed, (c) surfaces systemic patterns across incidents and teams, and (d) provides measurable evidence of program effectiveness. Design this program end to end: address the cultural, process, and tooling components. Specify how action items will be prioritized against feature work. Define how cross-incident patterns will be discovered. Propose at least three effectiveness metrics.#
Show answer
1. Blameless culture. A standard postmortem template separates the factual timeline ('what happened') from contributing factors and latent conditions ('why it was possible'), so attributing cause to an individual is structurally hard. Facilitators are trained through a shadowing program, with two rotating trained facilitators per team to spread the load. A review board of SRE leads and rotating senior engineers reviews each postmortem before publication and rejects blame language or individual attribution that skips the systemic conditions. All postmortems go to a company-wide knowledge base so every engineer can read them.
2. Action-item ownership and tracking. Every action item has exactly one named individual owner (never a team) and a target date agreed during the postmortem. Items live in one centralized tracker (e.g., a dedicated Jira project) with automated status updates and severity-linked SLAs: P0 (prevents recurrence of a SEV1) within two weeks, P1 within one quarter, P2 within two quarters. Overdue items auto-escalate to the owner's engineering manager and the SRE lead. To prioritize reliability work against feature work, adopt an error-budget policy: when a service's error budget is exhausted, that team's feature launches freeze and capacity shifts to reliability work, including postmortem action items, until the budget recovers. This makes reliability investment structural rather than renegotiated each time. A monthly review with SRE leads and engineering leadership tracks closure rates and overdue items.
3. Cross-incident pattern detection. Each postmortem is tagged with a structured taxonomy: incident type (cascading-failure, config-error, dependency-outage), affected services, contributing factors (missing-circuit-breaker, insufficient-monitoring, deployment-procedure-gap), and systemic themes (cross-team-dependency, capacity-planning). A quarterly cross-incident review aggregates the quarter's postmortems and looks for recurring incident types, contributing factors, or service clusters that single postmortems would not reveal. When a pattern appears (e.g., three incidents in a quarter involving missing circuit breakers on inter-service calls), commission a systemic postmortem that addresses the class of problem rather than each instance. A small working group maintains the taxonomy and refines categories monthly.
4. Effectiveness metrics. (i) Action-item closure rate within SLA, target above 80% (up from 30%). (ii) Incident recurrence rate: same incident type and contributing factor within six months, target below 10%. (iii) Time-to-postmortem: under five business days for SEV1, under ten for SEV2. (iv) MTTR trend by incident type, showing faster response to known incident classes even where prevention is not possible. (v) Error-budget burn correlation: whether services with completed action items show improved burn rates, linking the program to SLO performance.
This is an open design question with no single correct key, so it stays a SHORT_ANSWER graded against a reference design. A strong answer must cover all four dimensions the prompt names (blameless culture, action-item accountability, cross-incident pattern detection, and effectiveness measurement) with concrete mechanisms such as a template that separates timeline from contributing factors, single named owners with severity-based SLAs, an error-budget policy that ties prioritization to feature freezes, a structured taxonomy reviewed quarterly, and at least three measurable metrics with targets. Generic statements about fostering a learning culture do not earn credit on their own.
Related interview questions
Job market
See devops salaries and hiring demand from live job postings.
Practise these until they stick
That's every question we hold on this topic, and the page marks what you pick. What it can't do is remember. A free account keeps every answer, and what you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan