GCP Professional Cloud Architect Practice Question

Your team operates a highly trafficked e-commerce platform on Google Cloud. During last year's holiday sale, a spike in traffic caused the checkout service's 95th-percentile latency to exceed its 200-ms SLO before the on-call engineer was paged. The current alerting policy pages the team when the latency metric actually breaches 200 ms for five consecutive minutes. You have been asked to replace this reactive approach with a proactive one that warns operators early enough to add capacity or shift traffic before users are affected, while still avoiding notification fatigue.

Which alerting design best satisfies the requirement for proactive alerting?

Create a logs-based metric that counts "quota exceeded" errors from the checkout service and alert when more than 10 such errors occur within 5 minutes.
Lower the current latency alert's threshold to 180 ms and reduce the evaluation window from 5 minutes to 1 minute so the alert fires sooner after a spike.
Create a Cloud Monitoring alerting policy that uses a predictive condition to forecast the 95th-percentile checkout latency 30 minutes ahead and pages the on-call if the forecasted value is expected to exceed the 200-ms SLO for two consecutive forecast points.
Add regional uptime checks for the checkout endpoint and alert when any check fails or returns an HTTP 5xx response for more than 30 seconds.

Report Issue

Answer Description

Proactive alerting relies on forecasts or trend analysis that raise an alert before a metric violates the SLO, giving operators time to intervene. Cloud Monitoring supports predictive conditions that forecast a metric's value into the future (using built-in time-series forecasting) and compare the predicted value with a threshold. An alert that triggers when the forecast for 95th-percentile checkout latency is expected to cross 200 ms in the next 30 minutes provides early warning yet fires only when the SLO is genuinely at risk.

Lowering the CPU threshold (or shortening the evaluation window) is still reactive because it waits for an actual threshold breach; it may also increase noise from transient spikes. Uptime checks detect outright unavailability, not performance degradation, and therefore react after user impact. A logs-based metric on "quota exceeded" errors is also reactive and unrelated to latency. Therefore, forecasting the latency metric is the only option that delivers proactive alerting without excessive false positives.

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.