Examkin

Question

Difficulty: Very hardDefining and Managing SLOs, SLIs, and Error Budgets

An enterprise financial platform hosts a high-throughput transaction processing API on Cloud Run backed by Cloud Spanner. The business alignment requires maintaining a rolling 30-day Service Level Objective (SLO) of 99.9% successful HTTP requests, while enabling feature teams to maintain rapid deployment velocity. The Site Reliability Engineering (SRE) team needs to establish an automated alerting strategy in Google Cloud Monitoring that minimizes alert fatigue from brief transient spikes while ensuring immediate paging for major outages that threaten the monthly error budget. Which alerting implementation should you configure?

  1. Configure multi-window, multi-threshold burn-rate alerts that page on-call engineers when consuming a significant percentage of the error budget over short lookback windows (such as 2% over 1 hour) and create ticket alerts for sustained lower burn rates over longer windows (such as 5% over 6 hours).Answer
  2. B
    Configure static threshold alerts in Cloud Monitoring to page on-call engineers whenever HTTP 5xx server error rate exceeds 0.1% for a continuous 5-minute window across all Cloud Run instances.
  3. C
    Set up an alert policy monitored against instance-level performance by setting the target SLI to 99.9% availability and paging engineers whenever average CPU utilization across the container instances exceeds 80% for more than 10 minutes.
  4. D
    Configure the Cloud Load Balancer health check probe to trigger continuous synthetic payment write operations against Cloud Spanner every 5 seconds, sending a critical page if probe failures exceed 0.1%.

Answer

The SRE team should implement multi-window, multi-threshold burn-rate alerts based on error budget consumption rates.
Multi-window, multi-threshold burn rate alerting consumes metrics from Cloud Monitoring to calculate the exact speed at which the 30-day error budget is being depleted. By configuring a high burn rate threshold over a short window (e.g., 2% budget consumed in 1 hour, representing a 14.4x burn rate) for paging alerts, and a lower burn rate threshold over a longer window for ticket creation, the system balances rapid emergency incident response with protection against alert fatigue.

Step-by-Step Solution

1
Define the Service Level Indicator (SLI) and Service Level Objective (SLO)
The SLI is the ratio of successful HTTP requests to total requests, and the SLO is set to 99.9% over a 30-day rolling window, yielding an allowable error budget of 0.1%.
Establishing explicit measurement metrics and error budgets provides the foundation for alerting logic.
2
Evaluate alerting methods against alert fatigue and responsiveness trade-offs
Static threshold alerts fire on minor transient events, whereas error budget burn-rate alerts quantify the urgency based on how fast the error budget is being consumed relative to time.
Burn rate monitoring protects deployment velocity and engineer focus by filtering non-critical incidents.
3
Configure multi-window multi-threshold alert policies in Cloud Monitoring
Short lookback windows with high burn rate thresholds catch severe outages immediately, while long lookback windows with lower burn rate thresholds capture persistent, slow budget leaks.
Combining short and long lookback windows eliminates alert reset delays and prevents missed incidents.

Key Concept

Error Budget Burn Rate Alerting in Google Cloud SRE Practices
Estimated Time:3m 0s
Rate this question

Topics

Defining and Managing SLOs, SLIs, and Error Budgets

More questions from this topic