Cloud Digital Leader Scaling with Google Cloud operations Practice Question
After a major production outage, the engineering team conducts a review of what happened, why it happened, and how to prevent it in the future. This document is shared with all engineering teams. What is this practice called, and why does Google's SRE culture emphasize it?
⚠ Common exam trap
Many exam-takers confuse a blameless postmortem with a performance review or a change management process, failing to recognize that the key differentiator is the absence of blame and the focus on systemic learning rather than individual accountability.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Blameless postmortem — documenting the incident, root causes, and preventive actions to drive systemic learning without individual blame.
A blameless postmortem is a core SRE practice that focuses on documenting incidents, root causes, and preventive actions without assigning individual blame. Google's SRE culture emphasizes this to foster psychological safety, enabling teams to openly share failures and drive systemic improvements, which is essential for maintaining high reliability in large-scale distributed systems.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Performance review — identifying which engineers caused the outage for disciplinary action.
Why it's wrong here
Performance reviews are periodic, forward-looking evaluations of an individual's contributions against agreed goals and competencies. Using them to assign blame for an outage promotes a punitive culture that discourages engineers from reporting incidents or sharing incomplete information, which substantially degrades the reliability of incident data. Unlike a postmortem, which analyzes the system and processes after an incident, a performance review judges the person and has no structured mechanism for capturing systemic contributing factors.
- ✓
Blameless postmortem — documenting the incident, root causes, and preventive actions to drive systemic learning without individual blame.
Why this is correct
A blameless postmortem is a retrospective, collaborative analysis of an incident that produces a written record containing a detailed timeline, impact assessment, root cause analysis (often using techniques such as '5 Whys' or cause-effect diagrams), and concrete preventive actions. The 'blameless' attribute ensures the investigation concentrates on systemic contributions — like incomplete monitoring, ambiguous runbooks, or brittle configurations — rather than punishing the operator who triggered the failure. This approach builds psychological safety, enabling honest reporting of contributing factors, and turns failures into opportunities for continuous improvement, which is a fundamental pillar of reliability engineering.
- ✗
Capacity planning review — ensuring enough servers are provisioned to prevent future outages.
Why it's wrong here
Capacity planning is a predictive engineering discipline that models future resource utilization — including CPU, memory, storage, and network bandwidth — based on historical trends and business growth forecasts, typically using load testing and demand prediction. It can indeed prevent certain outage classes caused by resource exhaustion, but it is not a diagnostic process for an incident that has already happened. A postmortem is a comprehensive retrospective that examines the full spectrum of contributing factors, from code defects to configuration drift to dependent-service failures, and capacity planning may be only one of many follow-up actions stemming from it.
- ✗
Change advisory board (CAB) review — approving that the outage fix is safe to deploy.
Why it's wrong here
A Change Advisory Board (CAB) is a governance body that performs a risk assessment on a proposed change before it is released into production, evaluating factors such as rollback strategy, testing evidence, and potential customer impact. Its perspective is forward-looking: it decides whether a change is safe to deploy. In contrast, a postmortem is a backward-looking review of an incident that has already occurred; while the postmortem may recommend a corrective change, that change would independently need CAB approval for deployment — the CAB meeting itself is not a postmortem substitute.
Go deeper
Related to this question
About these practice questions
Courseiva writes every GCDL question from scratch — 829 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This GCDL practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCDL exam.