Cloud Digital Leader Scaling with Google Cloud operations Practice Question

A SRE team wants to alert when their service is consuming error budget faster than expected, rather than alerting only when the SLO threshold is crossed. Which Cloud Monitoring alerting strategy supports this approach?

⚠ Common exam trap

Candidates often confuse threshold alerting on a static error rate with SLO burn rate alerting, mistakenly thinking a fixed percentage threshold (like 0.1%) is sufficient to catch fast error budget consumption, when in fact burn rate alerting is the only method that measures consumption velocity relative to the SLO 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

✓

SLO burn rate alerting — alert when error budget is being consumed faster than the measurement window allows.

B is correct because SLO burn rate alerting is specifically designed to detect when error budget is being consumed faster than the measurement window allows, enabling proactive alerts before the SLO threshold is breached. This approach uses a burn rate (e.g., 2x, 10x) to trigger alerts when the error budget depletion rate exceeds a predefined multiple of the expected rate, allowing the team to respond early. It directly addresses the requirement of alerting on error budget consumption speed rather than waiting for a hard SLO violation.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Threshold alerting — alert when error rate exceeds 0.1%.
Why it's wrong here
Threshold alerting fires only after a fixed error rate (here 0.1%) is breached, making it inherently reactive. Because it does not consider the SLO measurement window or how much error budget remains, it cannot predict whether the budget will be exhausted by the end of the period. Moreover, a static threshold may cause alert fatigue from transient spikes or miss sustained lower-level consumption that cumulatively drains the budget.
✓
SLO burn rate alerting — alert when error budget is being consumed faster than the measurement window allows.
Why this is correct
SLO burn rate alerting continuously calculates the rate at which errors occur relative to the SLO's error budget and the remaining time in the measurement window. When the current burn rate projects that the budget will be exhausted before the window ends, an alert triggers promptly, enabling teams to respond before the SLO is actually violated. This approach is predictive rather than reactive, and can be tuned with fast and slow burn rates to detect both acute and chronic budget consumption, making it the correct mechanism for SLO compliance monitoring.
✗
Uptime check alerting — alert when health checks fail.
Why it's wrong here
Uptime check alerting only verifies that a service is reachable via synthetic probes, returning a binary pass/fail status. It cannot detect gradual degradation, partial outages, or the rate at which errors accumulate, so it provides no visibility into error budget consumption against an SLO. Thus, while useful for availability incidents, it does not measure SLO compliance or enable proactive response to imminent budget exhaustion.
✗
Log-based alerting — alert when specific error messages appear in logs.
Why it's wrong here
Log-based alerting triggers on predefined error messages or patterns in log entries, which are useful for diagnosing known failure modes but not for measuring SLO performance. It lacks aggregation across all requests and does not correlate error occurrence with the total traffic volume or the error budget defined by the SLO. As a result, it produces noise from isolated errors while failing to signal when the overall error rate is consuming budget at an unsustainable pace.

Go deeper

Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Why each option matters

Option-by-option breakdown

Related to this question