D · Delivery and ongoing operations

Reliability and incidents

Observability, incident response, containment, and follow-through.

Classification boundary

Include: Include observability, incident response, containment, recovery, and post-incident actions.

Choose a neighboring leaf when: Use A quality/security for planned quality gates or controls and operational execution for business operating strategy.

This capability may appear in standards across different stages. Explore stage expectations

24 questions

Choose a group based on the evidence you need. Groups follow existing question formats, not difficulty or mandatory prerequisites. Each batch has up to eight questions.

Judgment and options24

Compare goals, constraints, options, and trade-offs.

Questions 1–8

A data-write incident has stopped and service metrics look normal, but users still report missing records. How would you organize recovery validation and follow-up communication?
A release project has capacity, vendor-delivery, and data-quality risks, each below its individual escalation threshold, but all may converge in the same week. How would you assess the combined risk and decide what action to take?
When a payment-risk dependency slows, checkout times out. The business wants to preserve conversion without bypassing critical safety checks. How would you decide which checkout functions can be temporarily disabled and which checks must remain?
A campaign goes live overnight, but heavy traffic stalls the system. Users cannot claim coupons and start complaining. As an engineer involved in the campaign, how would you coordinate with operations and support on temporary business measures while restoring the system?
A system keeps having problems again and again, and each fix is followed by another failure. How do you find the root cause, how do you move the team from firefighting to real repair, and how do you show it no longer recurs?
A production service suddenly fails widely. In what order do you act during the first hour?
A major incident produces 18 actions across architecture, monitoring, training, and process, but teams already have quarterly commitments. How would you select actions that reduce recurrence risk?
How do you keep the same kind of personal mistake from happening again? Did you improve the process and tooling, or just remind yourself to be careful? How do you know the improvement works?

Questions 9–16

During an outage, engineering wants to disable a feature, business wants to keep accepting orders, and support has promised a recovery time. Responders receive conflicting directions. How would you organize the response?
A mobile release goes to 5% of users. The crash rate appears to double, but active devices are few and mostly one older model; a marketing campaign is near. How would you limit harm, gather evidence, and decide whether to continue, pause, or roll back?
An incident is resolved, and the review lists more than ten actions for monitoring, capacity checks, and documentation; earlier actions were never verified. How would you assign owners and dates and confirm whether improvements worked?
After a mobile release, network failures rise while server metrics remain normal; affected users cluster on older OS versions and weak connections. How would you scope the incident, reduce impact, and decide whether to pause or roll back?
A core service is partially unavailable and the cause is unknown; customers, executives, and partners request updates, while the team worries that early communication could mislead. How would you separate known facts, hypotheses, actions, and the next update time?
A critical dependency vulnerability needs prompt remediation, but the patch may conflict with the current release candidate; delay prolongs exposure, while immediate rollout could disrupt service. How would you plan validation, temporary mitigation, and release authorization?
A consumer failure leaves a queue hours behind; after repair, many old messages will replay into billing, notifications, and analytics, which have different capacities and side effects. How would you control recovery rate and protect consumers?
After a core dependency outage, most functionality has returned, but errors remain above baseline and upstream backlogs keep growing. The business wants full traffic restored quickly. How would you set recovery criteria and traffic ramp-up?

Questions 17–24

A failure went unnoticed because monitoring missed a critical user path until support escalated it. The review calls for more monitoring, but the team must show it detects issues earlier without creating excessive noise. How would you validate the change?
After a release, login, payment, and notification services fail in succession. Each team believes its incident is most urgent, and some alerts may share one root cause. How would you coordinate response, prioritize, and avoid interference?
An outage did not meet the threshold for a major customer incident, but affected a small group and exposed process gaps. How would you decide whether and how much to publish?
Upstream events are delayed by hours, while downstream reports still show success and customers make incorrect decisions. How would you design freshness states and notifications?
The business depends on a third-party API with no formal SLA and inconsistent support. How would you set internal continuity goals and fallback options?
A third-party service has recovered, but callbacks may have been lost during the outage. Customer-visible state differs from the platform record. How would you confirm impact and communicate?
The outage is resolved, but some customers still have incorrect balances and promised compensation is pending. How would you define closure and continuing ownership?
A release breaks reads, but the previous version cannot read the new data format. How would you contain impact and compare rollback, forward fix, and a compatibility layer?

Back to the whole domain