Examkin

Question

Difficulty: MediumDefining and Managing SLOs, SLIs, and Error Budgets

An e-commerce company operates a critical catalog search service deployed on Google Cloud Run backed by Cloud Bigtable. The Site Reliability Engineering (SRE) team established a Service Level Objective (SLO) of 99.9% success rate over a rolling 30-day window. To balance fast detection of catastrophic failures with low false-alarm noise during minor events, which alerting policy should the team implement in Cloud Monitoring?

  1. Implement multi-window, multi-burn-rate alerts that trigger based on consuming specific percentages of the 30-day error budget over short and long lookback windows.Answer
  2. B
    Configure a static threshold alert that fires immediately whenever the 5-minute request error percentage exceeds 0.1%.
  3. C
    Set up alert thresholds directly on Cloud Run instance CPU and memory utilization metrics exceeding 85% over a 10-minute average.
  4. D
    Configure load balancer health check probes to run synchronous database queries against Cloud Bigtable on every health check request.

Answer

The team should implement multi-window, multi-burn-rate alerts that evaluate error budget consumption rates over short and long lookback windows.
According to Google SRE principles, multi-window, multi-burn-rate alerts evaluate both the magnitude and duration of error budget consumption. Using multiple lookback windows (such as a 1-hour window for high burn-rate critical pages and a 6-hour or 3-day window for low burn-rate non-urgent notifications) ensures quick response to major outages without alerting on short, non-threatening spikes.

Step-by-Step Solution

1
Identify the reliability requirement
The target is to protect a 99.9% rolling 30-day SLO while preventing alert fatigue and detecting budget exhaustion early.
SRE best practices recommend alerting on error budget burn rate rather than raw metric thresholds.
2
Evaluate alerting mechanisms for SLOs
Multi-window, multi-burn-rate alerting evaluates consumption of the error budget over multiple time windows (e.g., 1-hour short window for critical paging, 6-hour/3-day windows for ticket creation).
This strategy captures fast budget depletion quickly while avoiding false alarms from self-correcting micro-spikes.
3
Differentiate from sub-optimal alternatives
Static metric thresholds and infrastructure metric monitoring fail to accurately reflect user experience or budget consumption speed.
Resource metrics (CPU/RAM) and static short-window error spikes do not directly map to SLO compliance.

Key Concept

Multi-window multi-burn-rate alerting
Rate this question

Topics

Defining and Managing SLOs, SLIs, and Error Budgets

More questions from this topic