Examkin

Question

Difficulty: HardIncident Management and Automated Alerting

A financial services organization operates a payment processing microservice on Google Kubernetes Engine (GKE) behind an internal HTTP(S) Load Balancer. During unexpected upstream partner outages, the service experiences severe error spikes that deplete its monthly availability Service Level Objective (SLO) error budget in less than an hour. However, the existing SRE alerting policy relies on a single-window 5-minute mean error rate threshold, which either fails to notify on-call engineers before significant budget consumption occurs or generates excessive false positives during brief traffic bursts. What alerting policy design in Cloud Monitoring should a Cloud Architect recommend to alert on critical error budget depletion while minimizing noise?

  1. Configure a multi-window, multi-burn-rate alerting policy based on the Service Level Indicator (SLI) that requires both a short lookback window (14 minutes) and a long lookback window (1 hour) to exceed a specific burn-rate threshold before triggering an incident.Answer
  2. B
    Configure a multi-window, multi-burn-rate alerting policy based on the Service Level Indicator (SLI) that requires both a short lookback window (14 minutes) and a long lookback window (1 hour) to exceed a specific burn-rate threshold before triggering an incident.
  3. C
    Create a static Cloud Monitoring threshold alert that monitors absolute HTTP 500 error count logs in Cloud Logging over a 1-minute alignment window to immediately page engineers when log counts rise.
  4. D
    Modify the Google Cloud Load Balancer health check configuration to perform deep health checks against the upstream third-party payment partner endpoints.
  5. E
    Assign the primitive Owner IAM role to the Cloud Monitoring service account and automate cluster node pool deletion using Cloud Functions when HTTP error rates increase.

Answer

Configure a multi-window, multi-burn-rate alerting policy based on the Service Level Indicator (SLI) that requires both a short lookback window and a long lookback window to exceed a specific burn-rate threshold before triggering an incident.
The correct approach implements multi-window, multi-burn-rate alerting on the service's SLO in Cloud Monitoring. By evaluating both a short lookback window (to verify the incident is ongoing) and a long lookback window (to verify substantial budget consumption), the SRE team ensures fast notification during severe outages while avoiding false alarms caused by brief metric spikes.

Step-by-Step Solution

1
Analyze the operational issue
Identified that single-window static threshold alerts cause false positives during transient traffic bursts and fail to protect against rapid SLO error budget consumption during severe incidents.
SRE best practices require alerts based on error budget burn rate rather than raw metric thresholds.
2
Evaluate SRE multi-window burn rate alert principles in Google Cloud Monitoring
Determined that multi-window multi-burn-rate alerting validates both recent severe consumption (short window) and sustained consumption (long window).
Using dual lookback windows ensures that alerts trigger quickly for high-severity budget-depleting events while suppressing alerts if the error rate immediately drops.
3
Select the optimal architecture solution
Selected the option recommending multi-window, multi-burn-rate policy configuration in Cloud Monitoring.
This aligns directly with Google SRE best practices for incident management and automated alerting.

Key Concept

Multi-window, multi-burn-rate SLO alerting in Cloud Monitoring
Rate this question

Topics

Incident Management and Automated Alerting

More questions from this topic