An enterprise IoT platform ingests telemetry from 500,000 connected vehicles through an AP… — Google Cloud Professional Cloud Architect

An enterprise IoT platform ingests telemetry from 500,000 connected vehicles through an API gateway hosted on Google Kubernetes Engine (GKE) Autopilot. The SRE team defines a Service Level Objective (SLO) requiring 99.9% of valid telemetry ingestion requests to complete successfully with a latency of under $200\text{ ms}$ over a rolling 30-day window. Following a series of rapid feature releases, 80% of the monthly error budget was consumed within 4 days due to brief, high-intensity error spikes that went undetected by standard threshold alerts until budget exhaustion occurred. The product team requires a policy and monitoring design that halts non-critical feature deployments when budget consumption accelerates dangerously while minimizing false-positive alerts during short transient spikes. Which architecture and operational policy should the Site Reliability Engineer recommend?

Implement multi-window, multi-burn-rate alerting in Cloud Monitoring based on short (1-hour/6-hour) and long (3-day) budget consumption windows, and establish an automated deployment gate that halts feature rollouts when the 1-hour burn rate exceeds $14.4\times$ or 3-day burn rate exceeds $1\times$ .Answer
B
Configure static threshold alert policies in Cloud Monitoring to notify the on-call team whenever HTTP 5xx error rates exceed 0.1% or node CPU utilization exceeds 85% for a continuous 5-minute window.
C
Redefine the Service Level Indicator (SLI) from successful request ratio to target 99.99% overall availability, and reconfigure Cloud Load Balancing health checks to execute deep write queries against the database tier.
D
Treat the 99.9% target as a Service Level Agreement (SLA) contract, and measure the measured SLI metric values directly as the target SLO threshold to trigger manual rollbacks whenever any single HTTP 500 error occurs.

Answer

Implement multi-window, multi-burn-rate alerting based on short and long budget consumption windows, and enforce automated feature deployment gates tied to burn-rate thresholds.

The correct strategy uses Google SRE multi-window, multi-burn-rate alerts in Cloud Monitoring. A 2% error budget consumption over 1 hour corresponds to a burn rate of

14.4\times

(since

100\% / (30 \times 24 \text{ hours}) \approx 0.1388\%

per hour, and

2\% / 0.1388\% \approx 14.4

). Enforcing multi-window lookbacks prevents false alarms from short transient spikes while instantly catching significant burns, and linking deployment gates to burn rates balances release velocity with SLO targets.

Step-by-Step Solution

Analyze error budget consumption behavior and identify why static alerts failed

Discovered that short, high-intensity error spikes rapidly burn monthly error budgets without triggering brief static threshold alarms.

Static metric thresholds do not measure the rate of error budget depletion relative to time.

Apply Google SRE best practices for burn-rate alerting

Selected multi-window multi-burn-rate alerting (e.g., 1-hour lookback at

14.4\times

burn rate consuming 2% of monthly budget, and 3-day lookback at

1\times

burn rate).

Multi-window alerting ensures fast alerts during catastrophic outages while avoiding noise for transient minor glitches.

Integrate error budget policy with CI/CD deployment pipelines

Automated deployment freezes occur when burn rate thresholds are exceeded, reserving remaining budget for operational stability.

Aligns development velocity directly with reliability metrics as mandated by SRE error budget policies.

Key Concept

Multi-window multi-burn-rate alerting and error budget governance

Estimated Time:3m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic