GCP Professional Cloud DevOps Engineer Practice Question 2: Incident Command Roles

Google's incident management model separates *command*, *operational work*, and *communication*. The incident commander holds the state of the incident and delegates; the operations lead is the only person touching production, which eliminates the duplicated and conflicting actions described in the scenario; the communications lead absorbs stakeholder pressure so responders are not interrupted. A live incident document gives everyone, including people joining late, a single shared view of what has been tried, so responders stop rediscovering each other's work. Roles are explicitly recognized and handed off, never assumed implicitly.

Option A is the anti-pattern the model exists to fix. One person cannot debug a production failure and simultaneously brief executives; whichever task is more urgent starves the other, and this is precisely why the communications role is separated out.

Option B describes the uncoordinated free-for-all that caused the problem. Without a commander there is no single owner of the mitigation plan, no deconfliction of changes, and no way to know whether an observed improvement came from a fix or from something else someone did.

Option C fails twice. Silence during an incident amplifies stakeholder anxiety and generates more interruptions, not fewer, and naming an individual as the cause is the opposite of a blameless postmortem; it teaches engineers to hide their involvement, which destroys the information the postmortem is supposed to surface. Blameless postmortems assume the individual acted reasonably given the information available and look for the systemic gaps that let the change reach production.

Reference: Managing Incidents (Site Reliability Engineering)