Your organization operates a mission-critical, multi-region checkout API hosted on Google Cloud. You need to establish synthetic monitoring to proactively detect customer-impacting issues before real traffic is disrupted. Your monitoring strategy must fulfill the following operational requirements: Probe the checkout endpoint from multiple global geographic regions at a 1-minute frequency. Validate that the endpoint responds with an HTTP 200 OK, contains a specific JSON confirmation key in the response body, and passes TLS certificate validity verification. Generate an incident and notify on-call engineers via Slack and PagerDuty if the 99th percentile (p99) latency exceeds 250 ms across probes for a 5-minute rolling window. Which combination of actions should you configure in Google Cloud Monitoring to meet these requirements?

Configure an HTTPS Uptime Check with multi-region global checkers, response content matching, and SSL certificate validation enabled; then attach a Cloud Monitoring Alerting Policy evaluating a threshold condition on latency with a 5-minute rolling window connected to third-party notification channels.: ### What the Solution Is This solution implements **Cloud Monitoring Uptime Checks** (synthetic monitors) paired with a metric-based **Alerting Policy** that evaluates aggregated latency and failure conditions over a designated rolling duration. ### How It Meets the Requirements - **Geographic Probing & Frequency**: Cloud Monitoring HTTPS Uptime Checks allow probing endpoints across multiple global geographic regions (e.g., North America, Europe, Asia Pacific) at configurable check intervals down to 1 minute. - **Assertions & TLS Validity**: The Uptime Check natively supports response status code assertions (expecting HTTP `200`), **content matching** strings (validating specific JSON payload tokens), and automated **TLS/SSL certificate validation** to detect expired or invalid certificates. - **Latency Threshold & Window**: You can create an alerting policy with a **Threshold condition** set against the check latency metric (or `serviceruntime` request latencies bucket), configuring the threshold to trigger when latency exceeds 250 ms over a continuous 5-minute rolling alignment window. - **Incident Management Integration**: The alerting policy links directly to **notification channels** such as Slack, PagerDuty, or Webhooks to alert on-call teams instantly. ### Key Advantages - **Proactive detection**: Validates end-to-end network, certificate, and application payload health before end users experience failures. - **False-positive reduction**: The 5-minute rolling alignment window prevents intermittent network blips from triggering false alarms. - **Seamless integration**: Native Cloud Monitoring notification channels deliver alerts directly into modern incident management workflows. ### Why This Is Optimal This approach uses fully managed Google Cloud observability primitives without requiring custom infrastructure, scripts, or cron daemons.

Synthetic Probes Assertions Latency Alerting Logic | Professional Cloud DevOps Engineer

Synthetic Probes Assertions Latency Alerting Logic

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your organization operates a mission-critical, multi-region checkout API hosted on Google Cloud. You need to establish synthetic monitoring to proactively detect customer-impacting issues before real traffic is disrupted. Your monitoring strategy must fulfill the following operational requirements:

Probe the checkout endpoint from multiple global geographic regions at a 1-minute frequency.
Validate that the endpoint responds with an HTTP 200 OK, contains a specific JSON confirmation key in the response body, and passes TLS certificate validity verification.
Generate an incident and notify on-call engineers via Slack and PagerDuty if the 99th percentile (p99) latency exceeds 250 ms across probes for a 5-minute rolling window.

Which combination of actions should you configure in Google Cloud Monitoring to meet these requirements?

Configure an internal Cloud Monitoring metric threshold alert on firestore.googleapis.com API latency with PromQL, and route log entries directly via Pub/Sub to an on-call email distribution list.

Create a Cloud Function triggered every minute by Cloud Scheduler to issue curl requests, parse output using custom regex, and push raw JSON logs to BigQuery for hourly alert evaluation.

Deploy a Compute Engine VM in each region to run continuous ping commands, log response times to Cloud Logging, and create a log-based metric with an instantaneous threshold alert.

Configure an HTTPS Uptime Check with multi-region global checkers, response content matching, and SSL certificate validation enabled; then attach a Cloud Monitoring Alerting Policy evaluating a threshold condition on latency with a 5-minute rolling window connected to third-party notification channels.

Professional Cloud DevOps Engineer

Synthetic Probes Assertions Latency Alerting Logic

Related questions