Examkin

Question

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

An enterprise logistics company runs a critical real-time inventory reservation service deployed on Google Kubernetes Engine (GKE) backed by Cloud Spanner. The service processes high-throughput synchronous HTTP requests from mobile applications. To balance feature velocity with operational stability, the Site Reliability Engineering (SRE) team needs to define metrics and alerting mechanisms. Which TWO of the following practices should the team implement? (Select TWO)

  1. Define the Service Level Indicator (SLI) as the ratio of successful HTTP requests (non-5xx5xx status codes) to total valid requests, evaluated over a rolling 30-day window.Answer
  2. Implement multi-window, multi-burn-rate alerts based on error budget consumption rates rather than static metric thresholds.Answer
  3. C
    Configure high-priority pager alerts triggered immediately whenever backend GKE cluster CPU utilization exceeds 85%85\% for more than 5 minutes.
  4. D
    Set the Service Level Indicator (SLI) to a fixed target of 99.9%99.9\% and define the measured real-time request success rate as the Service Level Objective (SLO).

Answer

The team should define the SLI as the ratio of successful HTTP requests to total valid requests over a rolling 30-day window, and implement multi-window, multi-burn-rate alerts based on error budget consumption rates.
Defining the SLI as the ratio of successful requests to total valid requests accurately measures customer-facing reliability. Pairwise, implementing multi-window, multi-burn-rate alerting monitors how quickly the service consumes its error budget, allowing teams to catch both fast outages and slow burn rate trends without generating false-positive alert fatigue.

Step-by-Step Solution

1
Identify the proper Service Level Indicator (SLI) definition for a synchronous web service.
SLI is defined as the ratio of good events (successful HTTP requests) to total events over a defined window.
SLIs must quantify user experience directly rather than internal server resource metrics.
2
Select the appropriate alerting strategy based on Site Reliability Engineering (SRE) best practices.
Multi-window, multi-burn-rate alerts are chosen to monitor error budget consumption.
Burn-rate alerting triggers based on how fast the error budget is being consumed, preventing unnecessary alerts for transient spikes while ensuring significant outages are paged immediately.
3
Evaluate and eliminate distractors based on common SRE antipatterns.
Reject static CPU utilization alerting and inverted SLI/SLO definitions.
Resource utilization alerts do not directly correlate with user impact, and swapping SLI/SLO concepts causes misconfigured monitoring pipelines.

Key Concept

Defining SLIs as ratio metrics of user-impacting events and configuring error budget burn-rate alerts.
Estimated Time:2m 0s
Rate this question

Topics

Defining and Managing SLOs, SLIs, and Error Budgets

More questions from this topic