Examkin

Question

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

A fintech enterprise operates an online payment processing API deployed on Google Cloud Run and backed by Cloud Spanner. The team has established a Service Level Objective (SLO) requiring 99.9%99.9\% of successful HTTP responses to serve within 200 ms over a rolling 30-day window. Recently, short transient spikes in latency triggered paging alerts that resolved themselves in under two minutes, causing alert fatigue for the SRE team. Meanwhile, a slow memory leak consumed 35%35\% of the monthly error budget over a 12-hour period without waking the on-call engineer. Which alerting strategy should the team implement in Cloud Monitoring to ensure timely notifications for critical incidents while eliminating false alarms?

  1. Implement a multi-window, multi-burn-rate alert policy in Cloud Monitoring that triggers high-priority pages based on short and long window error budget consumption rates.Answer
  2. B
    Set up a static threshold metric alert in Cloud Monitoring that triggers a page whenever the request latency exceeds 200 ms for a continuous 5-minute evaluation window.
  3. C
    Reconfigure Cloud Monitoring to measure container CPU and memory utilization thresholds instead of tracking latency-based HTTP metrics.
  4. D
    Redefine the Service Level Indicator (SLI) metric to track the target availability goal of 99.9% directly as a time-series metric input rather than calculating the latency ratio.

Answer

Implement a multi-window, multi-burn-rate alert policy in Cloud Monitoring that triggers high-priority pages based on short and long window error budget consumption rates.
According to Google SRE principles and GCP Cloud Monitoring recommended practices, multi-window multi-burn-rate alert policies evaluate error budget consumption across both short and long lookback windows. This prevents transient momentary spikes from triggering unnecessary pages while ensuring that sustained degradation rapidly alerting on-call engineers before significant budget depletion occurs.

Step-by-Step Solution

1
Analyze the problem requirements and current alerting flaws.
Identified that transient spikes trigger false alarms (alert fatigue) while long sustained degradation fails to alert despite consuming a significant portion of the error budget.
Static time windows and fixed thresholds are either too sensitive to short spikes or too slow to catch sustained slow budget consumption.
2
Apply Google SRE best practices for SLO-based alerting.
Selected multi-window, multi-burn-rate alerting.
Burn-rate alerting measures how fast an application is consuming its error budget relative to the SLO target over multiple short (e.g., 1-hour) and long (e.g., 6-hour) lookback windows.

Key Concept

Multi-window, multi-burn-rate alerting for error budget management in SRE practices.
Rate this question

Topics

Defining and Managing SLOs, SLIs, and Error Budgets

More questions from this topic