GCP Professional Cloud DevOps Engineer Practice Question 4: SLO Burn Rate Alerting
Google Cloud Professional Cloud DevOps Engineer · Test 1 · question 4 of 10
An API team has a 99.9% availability SLO over a 28-day rolling window in Cloud Monitoring. Today they page the on-call engineer whenever the error ratio exceeds 0.1% in any 5-minute window. The on-call engineer is woken several times a week by brief error spikes that consume a negligible share of the budget, and last month a low-grade regression quietly burned two thirds of the budget over ten days without ever tripping the page.
Which alerting configuration best fixes both problems?
Show answer and explanation
Answer:
Burn rate expresses how fast the error budget is being consumed relative to the rate that would exactly exhaust it over the compliance period: a burn rate of 1 spends the budget precisely on schedule, and a burn rate of 10 spends a month's budget in about three days. Pairing two policies with different burn-rate thresholds and lookback windows is the standard pattern. The fast-burn policy (a high multiplier such as 10x over a short lookback of roughly an hour) catches sudden, severe outages quickly and justifies a page. The slow-burn policy (a low multiplier such as 2x over a lookback up to 24 hours) catches the quiet, grinding regression described in the stem and routes it to a ticket rather than a page, because a slow burn does not warrant waking anyone. Both conditions are tied to budget consumption, so short spikes that barely dent the budget stop generating pages.
Option A alerts only after the damage is complete. By the time the budget reads zero the SLO has already been missed for the window; alerting must give the team time to intervene, which is the whole reason burn rate is used instead of budget remaining.
Option C makes the noise worse. The alert is still a raw short-window error ratio with no notion of budget consumption, so it fires on the same transient spikes as before, twice as often now, and still cannot see a regression that stays below the instantaneous threshold while steadily eating the budget.
Option D is not something Cloud Monitoring supports. Burn-rate alerting policies cannot use a lookback period greater than 24 hours, since the lookback also acts as the evaluation period. Even if it were possible, paging on any burn rate above 1 would page on ordinary background error rates that the budget exists to absorb.
Reference: Alerting on burn rate