Examkin

Question

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

A global media streaming platform operates a rights-management API running on Google Kubernetes Engine (GKE) behind an External HTTP(S) Load Balancer. The service has a defined Service Level Objective (SLO) of 99.99%99.99\% availability over a rolling 30-day window. SRE teams are currently suffering from alert fatigue caused by transient error spikes triggering immediate paging alerts, while simultaneously failing to catch slow, sustained error budget consumption that exhausts their 30-day budget prior to monthly reviews. Which alerting approach should a Cloud Architect recommend to ensure actionable notifications based on actual risk to the error budget?

  1. Implement multi-window, multi-burn-rate alerting policies in Cloud Monitoring that consume short (e.g., 5-minute/1-hour) and long (e.g., 6-hour/3-day) lookback windows to alert based on the rate of error budget depletion.Answer
  2. B
    Configure static threshold alerts in Cloud Monitoring that trigger an urgent paging notification whenever the 5-minute aggregate HTTP 5xx error rate exceeds 0.01%0.01\%.
  3. C
    Set up GKE Horizontal Pod Autoscaler (HPA) policies based exclusively on CPU utilization and memory consumption to automatically mitigate 5xx errors.
  4. D
    Redefine the Service Level Indicator (SLI) metric target to 99.99%99.99\% container CPU health and issue pings when container CPU consumption surpasses 85%85\%.

Answer

Implement multi-window, multi-burn-rate alerting policies in Cloud Monitoring that evaluate both short and long lookback windows to alert based on the rate of error budget consumption.
Implementing multi-window, multi-burn-rate alerts in Cloud Monitoring is the SRE best practice for managing SLOs. By pairing a short lookback window (ensuring quick response to severe outages) with a long lookback window (ensuring errors are still ongoing and not transient noise), teams can trigger pages for rapid budget consumption and open support tickets for slow budget burn without experiencing alert fatigue.

Step-by-Step Solution

1
Analyze the operational problem and SLO requirements
The API has a target SLO of 99.99%99.99\% over 30 days, leaving an error budget of 0.01%0.01\%. Transient spikes cause alert fatigue, while slow errors burn budget unnoticed.
Static threshold alerting fails to balance reset speed (alerting quickly on critical outages) with precision (avoiding alerts on minor brief spikes).
2
Evaluate SRE best practices for Google Cloud Monitoring SLO alerting
Multi-window multi-burn-rate alerts monitor both recent activity (short window) and sustained trend (long window) across multiple burn rate multiples (e.g., 14.4x for fast burn, 2x for slow burn).
This guarantees that an alert is triggered only when the error budget is genuinely at risk of depletion, avoiding unnecessary pages while catching persistent issues early.
3
Compare against distractor strategies
Static 5xx threshold alerts cause alert fatigue; CPU-based HPA does not remedy software error codes; infrastructure resource metrics are invalid SLIs for availability.
Only multi-window multi-burn-rate alerting correctly measures error budget consumption rate.

Key Concept

Multi-Window Multi-Burn-Rate Alerting on Error Budgets
Estimated Time:2m 30s
Rate this question

Topics

Defining and Managing SLOs, SLIs, and Error Budgets

More questions from this topic