Examkin

Question

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

A global enterprise runs a real-time order fulfillment service hosted on Google Kubernetes Engine (GKE) Autopilot backed by Cloud Spanner. The Site Reliability Engineering (SRE) team has set a Service Level Objective (SLO) requiring 99.9% of successful HTTP POST requests to complete with a latency under 200 ms over a 30-day rolling window. Recently, short network blips caused multiple false-positive emergency pages, while a persistent minor database regression consumed 60% of the error budget over two weeks before anyone was alerted. Which TWO operational practices should the SRE team implement to improve alerting precision and protect the service error budget? (Select TWO.)

  1. Configure multi-window, multi-burn-rate alerts in Cloud Monitoring to page on fast error budget consumption over short windows and trigger tickets on slow consumption over longer windows.Answer
  2. Establish an automated policy that freezes non-emergency feature releases and redirects engineering resources to performance fixes whenever the 30-day error budget is fully exhausted.Answer
  3. C
    Replace the latency SLO metric with a static Cloud Monitoring threshold alert that pages the team whenever GKE node CPU utilization exceeds 85% for 5 consecutive minutes.
  4. D
    Define the Service Level Indicator (SLI) by measuring synthetic probe latencies targeted directly against internal Cloud Spanner database read/write queries.

Answer

The SRE team should implement multi-window, multi-burn-rate alerting in Cloud Monitoring and enforce an error budget policy that halts feature deployments when the error budget is exhausted.
Implementing multi-window multi-burn-rate alerts accurately detects both fast and slow error budget consumption while preventing noise from transient network hiccups. Enforcing an explicit error budget policy ensures engineering capacity automatically shifts to reliability fixes when the error budget is depleted.

Step-by-Step Solution

1
Analyze the existing alerting defect
Identified that static alerts and single-window thresholds produce false-positive pages for short spikes and miss low-rate long-duration budget leaks.
SRE principles advocate for measuring budget burn rate rather than static metric limits.
2
Select appropriate alerting strategy
Selected multi-window, multi-burn-rate alerts.
This strategy alerts based on how fast the error budget is being consumed (e.g., 14.4x burn rate over 1 hour for paging, 2x burn rate over 3 days for ticketing), avoiding page fatigue while catching sustained degradation.
3
Determine governance for error budget exhaustion
Adopted an explicit policy halting new feature deployments upon budget exhaustion.
Error budgets exist to balance innovation speed with reliability; when depleted, focus must shift to stabilizing the platform.

Key Concept

Multi-window, multi-burn-rate alerting and error budget governance policies
Rate this question

Topics

Defining and Managing SLOs, SLIs, and Error Budgets

More questions from this topic