Cloud Digital Leader Scaling with Google Cloud operations Practice Question
An SRE team has a monthly error budget of 43 minutes (99.9% SLO). In the first week of the month, a deployment causes a 50-minute outage. What should the SRE team do for the remainder of the month, and why?
⚠ Common exam trap
The GCDL exam often tests the misconception that you can 'negotiate' or 'increase' the SLO to fix an error budget deficit, but increasing the SLO actually tightens the budget, and the correct response is to halt feature deployments until the next budget window.
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
✓
Freeze feature deployments for the rest of the month, focus on reliability improvements, and investigate the deployment process that caused the outage.
The team has already consumed more than the entire monthly error budget (50 minutes used vs. 43 minutes allowed). To avoid violating the 99.9% SLO for the rest of the month, they must freeze feature deployments and focus on reliability improvements. This is a core SRE practice: when the error budget is exhausted, the team shifts from feature velocity to stability, investigating the root cause and hardening the deployment process.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Immediately deploy a hotfix to restore features that were rolled back during the outage.
Why it's wrong here
A hotfix is still a deployment, and any deployment during budget exhaustion consumes additional risk budget without addressing the root cause. The previous rollout already caused an outage; re-deploying the same feature set, even as a hotfix, reintroduces the exact change that failed. Error budget exhaustion is a trigger to freeze all non-essential changes, and a rush to restore features often bypasses the postmortem and change-management controls needed to prevent recurrence.
- ✓
Freeze feature deployments for the rest of the month, focus on reliability improvements, and investigate the deployment process that caused the outage.
Why this is correct
With the error budget exhausted, the SLO is already at risk of being violated; continuing to ship features would only deepen the reliability debt. An SRE response to budget exhaustion is to declare a freeze on feature deployments and redirect all engineering effort to reliability improvements and root-cause analysis. Investigating the deployment process—not just the immediate failure—prevents the same defect from recurring, while reliability work replenishes the budget by reducing future error rates. This is the correct, disciplined response because it treats the budget as a hard control, not a suggestion.
- ✗
Negotiate with stakeholders to increase the SLO to 99.5% to get more error budget.
Why it's wrong here
Raising the SLO from 99.9% to 99.5% artificially inflates the error budget, but it does not fix the underlying defect that caused the outage; the service will still have the same failure rate, just with a larger allowance. SLOs are supposed to reflect user expectations and business requirements, not be changed to accommodate poor reliability—doing so is a form of 'budget gaming' that destroys the accountability the error budget is meant to create. Even if stakeholders accepted the change, the root cause would remain latent, and the increased budget would simply mask the problem until the next, likely more severe, outage occurs.
- ✗
Continue deploying features normally — the outage was a one-time event and won't happen again.
Why it's wrong here
Treating an outage as a one-time event without systemic follow-up is a classic reliability anti-pattern; it ignores the fact that error budget exhaustion is a measurable signal that the current system is not meeting its SLO. Continuing to deploy features normally while the budget is depleted means the team is literally compounding risk on top of an already failing service. The error budget mechanism exists to force a deliberate pause after failures, and skipping that pause because the event seems unique makes the next outage more likely to occur under a different trigger.
Go deeper
Related to this question
Learn chapter
ML Lifecycle: Data, Training, Deployment
Key term
SLO
A Service Level Objective is a measurable target for a specific aspect of a service's performance or reliability that a team commits to meeting over a defined period.
Key term
Error budget
An error budget is the maximum amount of acceptable downtime or failure a system can experience within a specified period while still meeting its Service Level Objective (SLO).
About these practice questions
One of 829 original GCDL practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.