GCP Professional Cloud Architect Practice Question

Your company operates a global web application behind a Cloud HTTP(S) Load Balancer. Site-reliability engineers want a single alert that pages on-call staff only when end-user availability is clearly impacted, not for transient problems in one region. The alert must fire when the percentage of HTTP 200 responses from at least two different probe locations drops below 97 % for 5 consecutive minutes. Which configuration in Cloud Monitoring best meets these requirements while minimizing alert noise?

Create an uptime check that requests the load-balancer URL and add an alerting policy whose condition aggregates the probe-location time series; trigger the alert when fewer than 97 % of responses are HTTP 200 in at least two locations for five minutes.
Export access logs to Cloud Logging, create a logs-based metric counting HTTP 500 responses, and alert when that metric exceeds 3 % of total requests in any single region.
Use the GKE metric kubernetes.io/container/restart_count with an alert that pages when pod restarts in any zone exceed 5 per minute for five minutes.
Attach a backend health check to each instance group and configure an alerting policy that fires when any backend status turns unhealthy for three consecutive samples.

Report Issue

Answer Description

The requirement is to measure end-user availability, not internal component health. A Cloud Monitoring uptime check issues synthetic HTTP requests from several Google probe locations and records one time-series per location. Creating an alerting policy on the uptime-check metric with an MQL or GUI-based condition that:

Aggregates the multiple probe-location series with the count_true("status" == 200)/count function to calculate the global success percentage.
Adds a secondary group-by on the label location and sets alert trigger = 2+ time-series failing, so at least two probe locations must show availability below 97 %.
Applies a 5-minute / 1-minute alignment period.

This fires only when real user-perceived availability drops across regions, avoiding pages for a single probe or regional-only issue.

Backend health-check metrics (options contrasting) observe instance health, not end-user availability, and fire on any single backend. Pod-restart or log-based metrics do not measure HTTP success rates. Therefore the uptime-check policy with multi-time-series aggregation is the correct solution.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.