Google ACE Practice Question: Your application running on GKE is experiencing…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Two separate alerting policies — one for latency and one for error rate — each with their own notification channel.

  Why it's wrong here

  Two separate alerting policies can each detect one signal, but they create two independent incidents and send duplicate notifications when both thresholds are breached around the same time, which increases alert fatigue. Cloud Monitoring supports a single alerting policy with multiple conditions and an OR combiner, so you can evaluate both the p99 latency metric and the 5xx error rate in one policy. Maintaining one policy also reduces duplication: you define the notification channel, duration, and incident grouping once instead of twice. While this option is technically functional, it is less clean and less efficient than a combined policy.

• ✓

  A single alerting policy with two conditions (p99 latency and error rate) joined with OR logic.

  Why this is correct

  A single alerting policy can define two separate conditions — one on p99 latency and one on 5xx error rate — and use an OR combiner so that the policy enters the firing state if either condition is breached. Each condition can be built on the appropriate Cloud Monitoring time series, such as a distribution-valued metric for the 99th percentile latency and a ratio metric for the error rate, with its own threshold and duration window. This approach creates a single incident and sends one notification when any condition fires, reducing noise while still covering both critical signals. It is also easier to maintain and update because the notification channels, documentation, and incident grouping are centralized in one policy.

• ✗

  A log-based alert using Cloud Logging to detect 5xx response codes in access logs.

  Why it's wrong here

  A log-based alert that scans access logs for 5xx response codes can only count log entries matching a textual pattern; it cannot compute a percentile like p99 latency or calculate an error rate as a ratio of failing to total requests. This approach requires you to parse logs, extract structured fields, and create a log-based metric, and even then it will not capture latency distributions unless you explicitly log latency values and build a custom distribution metric. Log-based alerts are better suited for triggering on specific log content (e.g., a stack trace or a security event), not for precision SLO-style thresholding across aggregated metrics. Cloud Monitoring's native metric-based alerting with distribution and ratio metrics is the direct, reliable way to meet this requirement.

• ✗

  An SLO with error budget burn rate alerts configured in Cloud Monitoring.

  Why it's wrong here

  An SLO with error budget burn rate alerts tracks how quickly the remaining error budget is consumed, which requires a pre-defined service level objective (SLO) target and a compliance period. This scenario demands direct threshold-based alerts on 99th percentile latency and 5xx error rate, not a burn-rate calculation. It is tempting because SLOs are a powerful tool for measuring reliability over time, and would be correct if the goal were to monitor gradual degradation against a long-term availability target rather than immediate threshold breaches.

Go deeper

Related to this question