PMLE Practice Question: Your company uses a custom container for model…

Your company uses a custom container for model serving on Vertex AI. After a recent update, the model returns predictions but they are clearly wrong (e.g., negative probabilities for a classification model). The logs show no errors. What is the most likely cause?

⚠ Common exam trap

Google Cloud often tests the concept that silent prediction errors (no logs, no crashes) are almost always due to data or preprocessing mismatches, not infrastructure or model file issues, which would generate explicit errors.

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

✓

The preprocessing code in the container was updated but the model was not retrained on the new preprocessing

The most likely cause of a model returning predictions without errors, but with clearly wrong outputs like negative probabilities, is a mismatch between the preprocessing logic used during training and inference. If the preprocessing code in the container was updated (e.g., scaling, normalization, or feature engineering steps changed) but the model was not retrained on data processed with that new logic, the model receives inputs that are out of distribution, leading to nonsensical outputs. Vertex AI containers run inference with the deployed code, so any change in preprocessing directly affects the input tensor values without raising runtime errors.

Answer analysis

Option-by-option breakdown

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

✓
The preprocessing code in the container was updated but the model was not retrained on the new preprocessing
Why this is correct
A preprocessing change alters the feature transformation applied before inference, so the model receives inputs on a different scale or encoding than it was trained on. Predictions remain numerically valid but semantically wrong, and no runtime error is raised because the container executes successfully.
✗
The model file is corrupted
Why it's wrong here
A corrupted model file typically throws deserialisation or load errors at startup, which the clean logs contradict; wrong-but-successful predictions imply the container loaded something valid. It is tempting because file corruption is a common post-update failure, and it would be correct if the container crashed or failed health checks instead of serving output.
✗
The model file was accidentally replaced with a different model
Why it's wrong here
Swapping in a different model still yields valid outputs for that model's schema, yet the stem's negative probabilities indicate the serving layer is bypassing the model's output activation, not that the weights changed. It is tempting because accidental artefact replacement is a real deployment risk, and it would fit if predictions were merely inaccurate rather than structurally invalid.
✗
The container is using an incompatible version of the serving framework
Why it's wrong here
An incompatible serving framework version usually raises import or signature errors, which the error-free logs rule out; the container is running and returning values. It is tempting because framework mismatches commonly break custom containers, and it would be correct if the container failed to start or threw runtime exceptions during inference.

Go deeper

PMLE Practice Question: Your company uses a custom container for model…

Why each option matters

Option-by-option breakdown

Related to this question