Discuss Google Professional Cloud DevOps Engineer Exam Topic 1 Question 85

Your CTO has asked you to implement a postmortem policy on every incident for internal use. You want to define what a good postmortem is to ensure that the policy is successful at your company. What should you do?

Choose 2 answers

A. Ensure that all postmortems include what caused the incident, identify the person or team responsible for causing the incident. and how to prevent a future occurrence of the incident.

BEnsure that all postmortems include what caused the incident, how the incident could have been worse, and how to prevent a future occurrence of the incident.

CEnsure that all postmortems include the severity of the incident, how to prevent a future occurrence of the incident. and what caused the incident without naming internal system components.

DEnsure that all postmortems include how the incident was resolved and what caused the incident without naming customer information.

EEnsure that all postmortems include all incident participants in postmortem authoring and share postmortems as widely as possible,

Suggested Answer: B, E

The correct answers are B and E

A good postmortem should include what caused the incident, how the incident could have been worse, and how to prevent a future occurrence of the incident1. This helps to identify the root cause of the problem, the impact of the incident, and the actions to take to mitigate or eliminate the risk of recurrence.

A good postmortem should also include all incident participants in postmortem authoring and share postmortems as widely as possible2. This helps to foster a culture of learning and collaboration, as well as to increase the visibility and accountability of the incident response process.

Answer A is incorrect because it assigns blame to a person or team, which goes against the principle of blameless postmortems2. Blameless postmortems focus on finding solutions rather than pointing fingers, and encourage honest and constructive feedback without fear of punishment.

Answer C is incorrect because it omits how the incident could have been worse, which is an important factor to consider when evaluating the severity and impact of the incident1. It also avoids naming internal system components, which makes it harder to understand the technical details and root cause of the problem.

Answer D is incorrect because it omits how to prevent a future occurrence of the incident, which is the main goal of a postmortem1. It also avoids naming customer information, which may be relevant for understanding the impact and scope of the incident.

Get Premium Professional Cloud DevOps Engineer Questions as Interactive Web-Based Practice Test or PDF Real Exam Format Detailed Explanations Instant Access Get Your Practice Test

35 comments · newest first

Lashaunda 11 months ago

E is nice, but do we really need everyone involved in writing?

Annabelle 11 months ago

B sounds good too, but how could it have been worse?

Virgie 11 months ago

Wait, how can we not name internal components? Seems risky.

Cortney 11 months ago

Totally agree with A! Accountability is key.

Cordell 12 months ago

A is a must! We need to know the cause and prevention.

Gwenn 12 months ago

I feel like involving all incident participants in the postmortem is crucial for a comprehensive review. Option E seems like a strong choice, but I’m not sure about the second option to pair it with.

Alease 1 year ago

I think I saw a practice question that mentioned including the severity of the incident. So, maybe option C could be a good choice too, but I'm not completely confident.

Danica 1 year ago

I'm not entirely sure, but I feel like identifying the responsible person or team is important for accountability. That makes me lean towards option A.

Cammy 1 year ago

I remember we discussed that a good postmortem should definitely include what caused the incident and how to prevent it in the future. So, I think options A and B might be right.

Brett 1 year ago

This is a tricky one. I want to make sure the postmortems are comprehensive, but also sensitive and constructive. I think the key is to emphasize process improvements and systemic changes, rather than individual accountability.

Leslie 1 year ago

I've got a few ideas here. First, I'd focus on the root causes and learnings, not just the immediate triggers. Second, I'd make sure to include steps to prevent future incidents, but without calling out specific people or systems. And third, I'd consider involving the whole team in the postmortem process.

Tamekia 1 year ago

Okay, let's think this through step-by-step. I'd want to make sure the postmortems cover what happened, how it could have been prevented, and how to avoid similar issues in the future. But I also don't want to place blame or reveal sensitive information.

Phillip 1 year ago

Hmm, this is an interesting one. I think the key is to strike the right balance between being thorough and not being overly punitive. We want to identify the root causes, but not single out individuals.

Scot 1 year ago

This seems like a straightforward question, but I want to make sure I understand the requirements correctly. I'll need to focus on defining the key elements of a good postmortem policy.

Davida 2 years ago

Option E is crucial - getting everyone involved in the postmortem process will help foster a collaborative spirit and shared ownership of solutions.

Wayne 2 years ago

↳ replying to Davida

E. Ensure that all postmortems include all incident participants in postmortem authoring and share postmortems as widely as possible.

Daren 2 years ago

↳ replying to Davida

A. Ensure that all postmortems include what caused the incident, identify the person or team responsible for causing the incident. and how to prevent a future occurrence of the incident.

Gracia 2 years ago

Haha, I bet the CTO is hoping for a 'no-blame' culture, but good luck with that! People are gonna want to know who screwed up.

Romana 2 years ago

↳ replying to Gracia

B) Ensure that all postmortems include what caused the incident, how the incident could have been worse, and how to prevent a future occurrence of the incident.

Adaline 2 years ago

↳ replying to Gracia

A. Ensure that all postmortems include what caused the incident, identify the person or team responsible for causing the incident, and how to prevent a future occurrence of the incident.

Cherry 2 years ago

Option C is interesting - it avoids naming internal components, which could be sensitive information. And focusing on the severity and prevention is important too.

King 2 years ago

↳ replying to Cherry

C. Ensure that all postmortems include the severity of the incident, how to prevent a future occurrence of the incident, and what caused the incident without naming internal system components.

Elli 2 years ago

↳ replying to Cherry

A. Ensure that all postmortems include what caused the incident, identify the person or team responsible for causing the incident, and how to prevent a future occurrence of the incident.

Lonny 2 years ago

I prefer option C. It focuses on the severity of the incident and prevention without naming internal system components.

Twana 2 years ago

I agree with Chantell. Option A covers all the important aspects of a good postmortem.

Brent 2 years ago

I'm not sure about naming the person or team responsible. That could create a blame culture, which is the opposite of what we want. Maybe we could focus more on the systemic issues that led to the incident.

Nan 2 years ago

↳ replying to Brent

E. Ensure that all postmortems include all incident participants in postmortem authoring and share postmortems as widely as possible.

Terina 2 years ago

↳ replying to Brent

I agree, focusing on systemic issues is key to improving processes and preventing future incidents.

Herman 2 years ago

↳ replying to Brent

C. Ensure that all postmortems include the severity of the incident, how to prevent a future occurrence of the incident, and what caused the incident without naming internal system components.

Tennie 2 years ago

↳ replying to Brent

A. Ensure that all postmortems include what caused the incident, how the incident could have been worse, and how to prevent a future occurrence of the incident.

Chantell 2 years ago

I think option A is the best choice. We need to identify the root cause and the responsible party to prevent future incidents.

Elenor 2 years ago

Option A seems the most comprehensive, as it covers the key elements of what caused the incident, who was responsible, and how to prevent it from happening again. This will help ensure the postmortem is actionable and effective.

Alease 2 years ago

↳ replying to Elenor

Sharing postmortems widely can also help prevent similar incidents in the future by increasing awareness.

Margot 2 years ago

↳ replying to Elenor

I think including the person or team responsible for causing the incident is crucial for accountability.

Craig 2 years ago

↳ replying to Elenor

I agree, option A covers all the important aspects of a good postmortem.

Google Professional Cloud DevOps Engineer Exam - Topic 1 Question 85 Discussion