Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An enterprise is migrating its core transactional platform to Google Cloud. To meet aggressive release deadlines, the development team has increased deployment frequency, but consecutive unstable releases have caused major service disruptions and completely exhausted the service's monthly error budget.
The operations team wants to halt all cloud migrations and institute mandatory, multi-stakeholder manual change approval gates for every release, while the development team insists on maintaining release velocity.
Which approach aligns with Site Reliability Engineering (SRE) change management principles to resolve this conflict and balance innovation velocity with system stability?
Establish a permanent Change Advisory Board (CAB) to manually review and approve every code commit and infrastructure pull request before deployment.
Grant full administrative repository merge permissions and unrestricted production breakglass access to all developers to accelerate unblocked hotfixes.
Shift development focus to reliability improvements, technical debt reduction, and automated testing until the error budget recovers, while conducting blameless post-mortems for the outages.
Adjust the Service Level Objective (SLO) target to 100% availability and establish individual performance reprimands for developers responsible for failing commits.
Establish a permanent Change Advisory Board (CAB) to manually review and approve every code commit and infrastructure pull request before deployment.
Grant full administrative repository merge permissions and unrestricted production breakglass access to all developers to accelerate unblocked hotfixes.
Shift development focus to reliability improvements, technical debt reduction, and automated testing until the error budget recovers, while conducting blameless post-mortems for the outages.
In Site Reliability Engineering (SRE), the error budget represents the acceptable level of unreliability that a service can experience within a specific timeframe without violating its Service Level Objective (SLO). It acts as an objective, data-driven governance mechanism that balances product development velocity with infrastructure and service reliability.
When a service depletes its error budget, the pre-negotiated policy mandates an operational shift: instead of continuing rapid feature launches, the development team redirects engineering effort toward stabilizing the application. Conducting blameless post-mortems ensures that outages are treated as learning opportunities to uncover systemic weaknesses, process gaps, and missing automated guardrails rather than assigning individual fault.
This approach directly implements SRE best practices by using the error budget as an automated feedback loop. It guarantees that release velocity is constrained only when reliability falls below agreed thresholds, keeping the organizational transformation focused on automation and measurable quality.
Adjust the Service Level Objective (SLO) target to 100% availability and establish individual performance reprimands for developers responsible for failing commits.
StudyCerts
StudyCerts