PMLE Practice Question: Refer to the exhibit

Exhibit

{
  "name": "projects/123/alertPolicies/456",
  "displayName": "High Latency",
  "conditions": [
    {
      "displayName": "Latency > 500ms",
      "conditionThreshold": {
        "filter": "metric.type=\"vertexai.googleapis.com/prediction/latency\"",
        "comparison": "COMPARISON_GT",
        "thresholdValue": 500,
        "duration": "300s"
      }
    }
  ],
  "combiner": "OR"
}

Refer to the exhibit. An alert policy is configured to trigger when prediction latency exceeds 500 ms for 5 consecutive minutes. The team is experiencing many false positive alerts during brief latency spikes. Which adjustment would most effectively reduce false positives while still detecting prolonged latency issues?

⚠ Common exam trap

Google Cloud often tests the distinction between threshold and duration adjustments, trapping candidates who think raising the threshold (Option D) is the only way to reduce false positives, when in fact increasing the evaluation window is more precise for filtering out transient spikes without compromising detection of sustained issues.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Increase the duration to 30 minutes

Increasing the duration from 5 to 30 minutes (Option C) directly addresses the problem of false positives from brief latency spikes by requiring the latency to exceed 500 ms for a longer continuous period before triggering an alert. This ensures that only sustained, prolonged latency issues—not transient spikes—activate the policy, aligning with the goal of detecting genuine degradation while ignoring noise.

Answer analysis

Option-by-option breakdown

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

✗
Change the comparison to less than
Why it's wrong here
Reversing the comparison to less than would fire alerts when latency drops below 500 ms, inverting the intended condition entirely and missing genuine latency breaches. It is tempting because comparison operators are the visible trigger logic, but the stem's problem is spike duration, which only the sustained evaluation window setting addresses.
✗
Add a condition that CPU utilization is also high
Why it's wrong here
Adding a CPU condition might reduce false positives if latency spikes are not CPU-related, but it may also cause missed detections if high latency occurs without high CPU.
✓
Increase the duration to 30 minutes
Why this is correct
Extending the condition duration to 30 minutes requires latency to remain above 500 ms continuously for longer, filtering out brief spikes while still firing on sustained degradation. This directly reduces false positives without masking prolonged latency issues.
✗
Increase the threshold to 1000 ms
Why it's wrong here
Raising the threshold to 1000 ms suppresses brief spikes but also delays detection of genuine sustained latency between 500 and 1000 ms, weakening the prolonged-issue requirement. Threshold tuning is tempting because it directly reduces firing frequency. Widening the evaluation window instead preserves sensitivity to sustained breaches.

Go deeper

PMLE Practice Question: Refer to the exhibit

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question