PMLE Practice Question: Which THREE components should you include in a…

Which THREE components should you include in a comprehensive model monitoring dashboard for a production ML system?

⚠ Common exam trap

Google Cloud often tests the distinction between operational governance artifacts (like team roles) and actual monitoring metrics; the trap here is confusing project management documentation with the technical components of a live monitoring dashboard.

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

✓

System resource utilization (CPU, memory, latency)

Option B is correct because a production ML monitoring dashboard must track system resource utilization such as CPU, memory, and latency to detect infrastructure bottlenecks, scaling issues, and SLA violations that degrade inference serving. Option C is correct because input data quality metrics like missing values and outliers enable detection of data drift, schema violations, and upstream pipeline failures before they corrupt predictions. Option E is correct because tracking model performance metrics such as accuracy, precision, and recall over time is essential to detect model degradation, concept drift, and performance regressions in production. Option A is not a monitoring dashboard component; team roles and responsibilities belong to governance and RACI documentation, not runtime observability. Option D is not appropriate for a monitoring dashboard either, since training pipeline code version is a lineage/reproducibility artifact tracked in model registries or CI/CD metadata, not a live production monitoring signal.

Answer analysis

Option-by-option breakdown

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

✗
Team member roles and responsibilities
Why it's wrong here
Roles and responsibilities are governance documentation, not telemetry; a monitoring dashboard displays operational signals such as latency, drift and error rates. It is tempting because ownership clarity matters for incident response, and would fit a RACI matrix or runbook rather than a live dashboard.
✓
System resource utilization (CPU, memory, latency)
Why this is correct
System resource utilisation exposes infrastructure saturation that degrades inference before model metrics shift, satisfying the stem's production constraint. CPU, memory and latency reveal capacity exhaustion, memory leaks and queueing under live traffic, which data drift or accuracy checks cannot detect. Including these signals keeps the dashboard comprehensive across serving health and model behaviour.
✓
Input data quality metrics (missing values, outliers)
Why this is correct
Input data quality metrics catch distribution drift and schema violations before they corrupt predictions, satisfying the dashboard's need for upstream detection in a production ML system. Missing values and outliers signal training-serving skew, letting teams retrain or quarantine feeds early rather than diagnosing degraded outputs after downstream failures surface.
✗
Training pipeline code version
Why it's wrong here
Training pipeline code version is build provenance, not runtime behaviour, so it cannot show a production system's health. It is tempting because reproducibility and audit trails matter, and would be correct on a model registry or CI/CD lineage view rather than a monitoring dashboard.
✓
Model performance metrics (accuracy, precision, recall) over time
Why this is correct
Accuracy, precision and recall tracked over time detect concept drift, where the relationship between inputs and labels shifts after deployment. Trending them exposes gradual degradation that point-in-time evaluation on static training data would miss entirely.

Go deeper

PMLE Practice Question: Which THREE components should you include in a…

Why each option matters

Option-by-option breakdown

Related to this question