PMLE Practice Question: Refer to the exhibit

Exhibit

modelMonitoringConfig:
  objectiveConfig:
    detectionConfig:
      driftThresholds:
        age: 0.3
        income: 0.1
      skewThresholds:
        age: 0.2
        income: 0.05
  featureAttributionConfig:
    enabled: True

Refer to the exhibit. An engineer notices no drift alerts but the model performance has degraded. What is the likely cause?

⚠ Common exam trap

Google Cloud often tests the distinction between data drift (input feature changes) and concept drift (target relationship changes), trapping candidates who assume that no drift alerts mean the model is healthy, when in fact performance degradation can occur without any feature distribution shift.

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

✓

Concept drift is occurring, which is not captured by drift or skew detection

Concept drift occurs when the statistical properties of the target variable change over time, causing model performance to degrade even when the input data distribution remains stable. Drift detection (e.g., data drift or skew) monitors changes in feature distributions, not the relationship between features and the target. Since no drift alerts were triggered, the input data appears unchanged, but the model's predictive relationship has shifted — this is classic concept drift, which requires performance monitoring (e.g., accuracy, F1-score) rather than drift or skew detection.

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 attribution monitoring is causing too many false positives
Why it's wrong here
Feature attribution monitoring explains which features drive predictions; it neither detects drift nor causes false positives that hide degradation. It is tempting because attribution outputs can look like alerts, and it is the right tool when investigating why a model's behaviour changed after a known data shift, not for diagnosing silent performance loss.
✗
Drift threshold for income is too high
Why it's wrong here
Raising the income drift threshold suppresses alerts rather than restoring accuracy; if the degradation stems from a changed feature-target relationship, distribution monitoring never fires regardless of threshold. Threshold tuning is genuinely useful when legitimate seasonal income shifts trigger nuisance alerts, but here it would mask the real signal instead of explaining the performance drop.
✗
Skew thresholds are not configured for categorical features
Why it's wrong here
Skew monitoring compares training and serving feature distributions; it does not detect concept drift, where the input-output relationship itself changes, so performance falls silently. It is tempting because skew thresholds genuinely catch categorical encoding mismatches between training and inference pipelines, which would be the correct diagnosis if the exhibit showed serving values diverging from training data.
✓
Concept drift is occurring, which is not captured by drift or skew detection
Why this is correct
Concept drift changes the input-to-output mapping itself, so incoming feature distributions still match the training baseline and drift or skew detection stays silent. The model's learned relationship is stale, which explains degraded performance without alerts.

Go deeper

PMLE Practice Question: Refer to the exhibit

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question