SRE Postmortem Triggers: External Stakeholders and Data Loss

PCDOE By islever Editorial Last updated

Balancing change, velocity, and reliability of the service.

Short answer

AB An external stakeholder asking for a postmortem and data loss due to an incident are the two triggers defined in the postmortem policy based on SRE practices.

Question

Your team is writing a postmortem after an incident on your external facing application. Your team wants to improve the postmortem policy to include triggers that indicate whether an incident requires a postmortem. Based on Site Reliability Engineering (SRE) practices, what triggers should be defined in the postmortem policy? (Choose two.)
  1. An external stakeholder asks for a postmortem Correct Answer
  2. Data is lost due to an incident. Correct Answer
  3. An internal stakeholder requests a postmortem.
  4. The monitoring system detects that one of the instances for your application has failed.
  5. The CD pipeline detects an issue and rolls back a problematic release.

Key Takeaways

The question tests knowledge of SRE postmortem culture, specifically distinguishing between significant incidents requiring review (user impact, data loss) and routine operational events.

This page explains which events should trigger a postmortem in Google Cloud SRE practices, identifying external stakeholder requests and data loss as the correct triggers.

Common mistake: Choosing E (CI/CD rollback) is a common mistake because it involves an automated process, but rollbacks are often successful mitigations that don't necessarily indicate a system failure requiring a full postmortem if no user impact occurred.

Expert Analysis

In Google Cloud Site Reliability Engineering (SRE) practices, a postmortem is a structured review of an incident to identify root causes and implement preventive measures. The key principle is that postmortems should be triggered by events that have significant user impact or result in data loss, rather than routine operational noise.

According to the official SRE book (Section on Postmortem Culture), common triggers include:

  1. Data loss of any kind: This is always a critical event requiring investigation to ensure data integrity and prevent recurrence.
  2. User-visible downtime or degradation beyond a certain threshold: While not explicitly listed as "external stakeholder," external stakeholders (customers/users) are the primary indicators of user-visible impact. If an external stakeholder complains or requests a postmortem, it signifies a service failure that affected users.
  3. On-call engineer intervention: Such as release rollbacks or traffic rerouting. However, automated rollbacks that resolve issues quickly without manual heavy lifting may not always require a full postmortem unless they indicate a deeper systemic flaw.
  4. Resolution time above a threshold.
  5. Monitoring failures.

Let's evaluate the options:

  • A. An external stakeholder asks for a postmortem: This indicates that the incident had a tangible negative impact on customers or users. In SRE culture, customer feedback is a vital signal of service health. External complaints often correlate with user-visible degradation or downtime. Therefore, this is a valid trigger because it highlights a breach in service quality perceived by the user.
  • B. Data is lost due to an incident: Data loss is universally considered a severe incident in SRE. It compromises data integrity and trust. The SRE book explicitly lists "data loss of any kind" as a standard trigger for a postmortem. This is definitely correct.
  • C. An internal stakeholder requests a postmortem: While internal stakeholders can request reviews, the primary objective triggers are based on system impact and user experience. Internal requests might be less reliable indicators of actual user harm compared to external ones.
  • D. The monitoring system detects that one of the instances for your application has failed: Instance failures are often handled automatically by auto-healing mechanisms or load balancers. If the system recovers gracefully without user impact, a full postmortem may not be necessary. This is a routine operational event rather than a significant incident.
  • E. The CI/CD pipeline detects an issue and rolls back a problematic release: Automated rollbacks are a feature of robust CI/CD pipelines. They prevent bad code from reaching production. While the underlying defect needs attention, the rollback itself is a successful mitigation strategy. Unless the rollback caused significant user disruption or occurred repeatedly, it may not automatically trigger a full incident postmortem in the same way data loss or major outages do.

Comparing A and B: Both represent significant impacts. B is an objective technical failure with severe consequences. A represents subjective but critical user-perceived failure. The SRE book emphasizes that postmortems are for learning from significant failures. Data loss is unequivocally significant. User-visible impact (signaled by external stakeholders) is also significant. Internal stakeholders (C) and routine technical events like instance failures (D) or automated mitigations (E) are less definitive triggers for a formal postmortem policy focused on high-impact incidents.

Therefore, the two most appropriate triggers based on SRE principles of focusing on user impact and data integrity are A and B.

Official Reference

https://sre.google/sre-book/postmortem-culture/

This link opens the official vendor documentation in a new tab.

Exam Strategy

When answering SRE-related questions, prioritize triggers that indicate significant user impact or data integrity issues. Distinguish between 'noise' (routine failures, automated recoveries) and 'signal' (outages, data loss, customer complaints). Remember that SRE culture encourages blameless postmortems for learning, so focus on events that provide valuable lessons about system reliability.

Frequently Asked Questions

Why is data loss always a postmortem trigger?

Data loss is a critical failure that compromises user trust and system integrity. It requires thorough investigation to understand the root cause and implement safeguards to prevent recurrence.

Does every instance failure require a postmortem?

No. If instances fail and are automatically replaced by auto-healing systems without user-visible impact, it is considered routine operation. Postmortems are reserved for events with significant user impact or data loss.

More PCDOE FAQ →

Community Votes

AB
79%
AE
10%
BE
11%

79% of anonymous learners picked answer AB. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 16 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 16

  1. d78a2b9 👍 5
    A over D because An external stakeholder requesting a postmortem indicates a significant impact from their perspective. This highlights the need for a thorough investigation to understand the customer experience, mitigate future issues, and potentially regain trust. Not D because Instance failures often happen, and automated systems should handle them gracefully. A postmortem is warranted only if customer impact occurs despite the redundancy and recovery mechanisms.
  2. cachopo 👍 4
    Based on the SRE postmortem culture guidelines, the triggers for writing a postmortem should be objective events that signal significant service impact or loss. In this context, the most appropriate triggers are: • A. An external stakeholder asks for a postmortem • B. Data is lost due to an incident These triggers reflect situations where customer or external impact is evident (as in A) or when there is a clear degradation in service reliability (as in B). External requests indicate that the incident affected users or partners enough to demand transparency and learning, while data loss is a critical failure that warrants a detailed investigation to prevent recurrence.
  3. Andrei_Z 👍 4
    E is expected behaviour if you set up the pipelines properly so I would go for A and B.
  4. xhilmi 👍 3
    Choose B & E. In accordance with Site Reliability Engineering (SRE) practices, the triggers defined in a postmortem policy should be focused on incidents that have significant impact and provide valuable learning opportunities. Option B, "Data is lost due to an incident," is a critical trigger as data loss is a severe consequence that necessitates a thorough examination to prevent future occurrences. Option E, "The CD pipeline detects an issue and rolls back a problematic release," is a crucial trigger indicating that the continuous delivery (CD) pipeline has identified an issue and initiated a rollback, pointing to potential challenges in the release process. These triggers highlight impactful incidents with potential systemic issues, aligning with SRE principles to conduct postmortems for events that contribute to system resilience and reliability.
  5. ecece4d 👍 3
    should be A and B, SRE book says: common postmortem triggers include: User-visible downtime or degradation beyond a certain threshold (N/A) "Data loss of any kind" <----------------------------- (B) On-call engineer intervention (release rollback, rerouting of traffic, etc.) (N/A) A resolution time above some threshold (N/A) A monitoring failure (which usually implies manual incident discovery) (N/A) not manual incident discovery here It is important to define postmortem criteria before an incident occurs so that everyone knows when a postmortem is necessary. In addition to these objective triggers, "any stakeholder may request a postmortem for an event." <-------------------------- (A)
Show 11 more comments
  1. Jason_Cloud_at 👍 3
    Right answer
  2. nhiguchi 👍 2
    Answer should be BE.
  3. ManishKS 👍 2
    Answer should be BE
  4. LaxmanTiwari 👍 2
    that's right.
  5. surfer111 👍 1
    https://sre.google/sre-book/postmortem-culture/ suggests B and E as objective triggers. On a side note, it says any stakeholder can request but that would qualify A and C also but we objectively know B is an answer by the docs. "In addition to these objective triggers, any stakeholder may request a postmortem for an event. Blameless postmortems are a tenet of SRE culture." "On-call engineer intervention (release rollback, rerouting of traffic, etc.)" E is also a toss up since it doesn't state any manual intervention was required and the rollback happened by itself. BE & AB are solid choices. But I would lean more to BE since they are listed under objective requirements although no manual intervention was required for the rollback..
  6. gaurav517 👍 1
    Option A: An external stakeholder asks for a postmortem ✅ Important for customer trust and transparency ✅ Valid trigger - external impact is significant ✅ SRE practice: Customer-impacting events warrant postmortems Option B: Data is lost due to an incident ✅ High impact - could be customer data, transactions, etc. ✅ SRE best practice: Data loss always triggers postmortem ✅ One of the most serious incident types Option E: CD pipeline detects issue and rolls back ⚠️ Might warrant lightweight review, not full postmortem ❌ Not significant enough for formal postmortem ✅ Good CI/CD practice, but not postmortem-worthy
  7. cachopo 👍 1
    Options C, D, and E represent either subjective triggers or events that are more routine or automatically handled. Internal requests (C) are less objective; instance failures (D) may be common in a resilient, auto-healing system; and automated rollbacks (E) are part of normal operational processes that don’t always result in significant impact.
  8. BlackCoffee 👍 1
    Postmortem policies are internal operational guidelines. While an external customer might request a root cause analysis (RCA), internal postmortems are triggered by internal policy and stakeholders, not external parties directly.
  9. Srikantha 👍 1
    The correct choices are B. Data is lost due to an incident and C. An internal stakeholder requests a postmortem.
  10. mshafa 👍 1
    Answer is BE Because those are major incident that disrupted our service.
  11. PGontijo 👍 1
    BE for sure.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Mitigating Downstream Service Failures with Circuit Breakers

S-grade

Error Budget Exhausted: Should You Deploy an Urgent Customer Feature?

S-grade

Choosing a Latency SLO from Measured p90/p95 Performance

S-grade

Centralizing Production Folder Logs with an Aggregated Log Sink

S-grade

Practice All PCDOE Questions

Access 75 questions with complete answers and detailed explanations.

View Full PCDOE Practice Test →

← Back to PCDOE Study Guide