Professional Cloud DevOps Engineer
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
A DevOps team manages a high-traffic microservices application running on Google Cloud and connected via Cloud Service Mesh. The service has a defined 30-day rolling Service Level Objective (SLO) of 99.9% availability, leaving an error budget of 0.1%.
The team needs to design an automated error budget policy and alerting mechanism that achieves the following requirements:
Which strategy should the team implement?
Monitor raw error counts per instance in Cloud Logging, and automatically dispatch every raw error log directly to executive management via email to manually approve or pause each CI/CD deployment pipeline.
Implement multiwindow, multi-burn-rate alerting in Cloud Monitoring using short and long lookback windows, and establish an error budget policy that automatically freezes feature rollouts to focus development effort on reliability engineering when the budget is exhausted.
Alert on total cumulative error budget consumption only when 100% of the budget has been exhausted in the 30-day window, and trigger an automated rollback of all software releases deployed during that month.
Configure a single-window static error threshold alert in Cloud Monitoring that triggers when 5xx HTTP response codes exceed 0.1% over a 5-minute window, and revoke all deployment permissions for engineering teams until the end of the 30-day period.
Monitor raw error counts per instance in Cloud Logging, and automatically dispatch every raw error log directly to executive management via email to manually approve or pause each CI/CD deployment pipeline.
Implement multiwindow, multi-burn-rate alerting in Cloud Monitoring using short and long lookback windows, and establish an error budget policy that automatically freezes feature rollouts to focus development effort on reliability engineering when the budget is exhausted.
Multiwindow multi-burn-rate alerting is a Site Reliability Engineering (SRE) best practice that measures the rate of error budget consumption (burn rate) across multiple time horizons and short/long confirmation windows. A burn rate of 1 means the entire error budget will be consumed exactly over the SLO period (e.g., 30 days). Higher burn rates (such as 14.4x consuming 2% of budget in 1 hour, or 6x consuming 5% in 6 hours) represent urgent, rapid degradation that requires immediate intervention, while lower burn rates (such as 1x to 2x over several days) represent slow degradation.
This approach solves the trade-off between alert precision and recall while providing an actionable, organizational framework to maintain service stability without stalling long-term velocity.
Alert on total cumulative error budget consumption only when 100% of the budget has been exhausted in the 30-day window, and trigger an automated rollback of all software releases deployed during that month.
Configure a single-window static error threshold alert in Cloud Monitoring that triggers when 5xx HTTP response codes exceed 0.1% over a 5-minute window, and revoke all deployment permissions for engineering teams until the end of the 30-day period.