PDE Practice Question: Which TWO metrics are most important to monitor…

Which TWO metrics are most important to monitor for a real-time online prediction system to ensure service reliability and model performance?

⚠ Common exam trap

Google Cloud often tests the distinction between offline training metrics (like feature skew or training example count) and real-time serving metrics (like latency and error rate), trapping candidates who confuse model performance monitoring with service reliability monitoring.

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

✓

Prediction latency (p50, p99)

Prediction latency (p50, p99) is correct because a real-time online prediction system must respond within strict time budgets, and monitoring percentile latencies (especially p99) reveals tail-latency regressions that directly impact service reliability and user experience. Prediction error rate (e.g., 4xx/5xx responses) is correct because it is the primary signal of serving failures, such as malformed requests, timeouts, or model-server crashes, and is essential for detecting availability and correctness problems in production. Feature distribution skew between training and serving, while important for model quality, is a data-quality/drift metric rather than a core real-time reliability metric, so it is not one of the two most important here. The number of training examples used for the latest model version is a training-time artifact and does not reflect live serving health. Batch prediction job throughput applies to offline/batch inference, not to a real-time online prediction system.

Answer analysis

Option-by-option breakdown

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

✗
Feature distribution skew between training and serving
Why it's wrong here
Training-serving skew is a data-quality concern affecting prediction accuracy, not the service reliability and latency the question targets. It is the correct metric when diagnosing gradual model degradation or drift in production predictions, not endpoint health.
✓
Prediction latency (p50, p99)
Why this is correct
Prediction latency percentiles directly expose whether the real-time serving path meets its responsiveness constraint, since p99 captures tail delays that averages hide. Monitoring p50 and p99 together reveals queueing, cold starts, or overload degrading user-facing predictions, satisfying the stem's service reliability requirement for an online system.
✗
Number of training examples used for the latest model version
Why it's wrong here
Training-example count is a build-time dataset statistic, not a runtime signal, so it cannot reveal live latency, throughput or prediction drift. It is tempting because dataset size indicates model quality during development, and it would be worth tracking when auditing reproducibility of a released model version.
✗
Batch prediction job throughput
Why it's wrong here
Batch throughput measures offline job completion, which is unrelated to a live serving endpoint's latency and availability. It is the right metric for scheduled scoring pipelines where job duration and queue backlog matter, not for real-time prediction reliability.
✓
Prediction error rate (e.g., 4xx/5xx responses)
Why this is correct
Prediction error rate captures 4xx/5xx responses, directly exposing serving failures and reliability degradation in a real-time system. Monitoring it satisfies the service reliability constraint, since rising error rates signal endpoint, authentication, or quota problems before users abandon the service.

Go deeper

PDE Practice Question: Which TWO metrics are most important to monitor…

Why each option matters

Option-by-option breakdown

Related to this question