PMLE Practice Question: Which TWO practices are important when scaling a…

Which TWO practices are important when scaling a prototype ML model to production on Google Cloud? (Choose two.)

⚠ Common exam trap

Google Cloud often tests the misconception that production ML can rely on manual processes or single-instance deployments, whereas the correct approach emphasizes automation, monitoring, and scalability through managed services.

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

✓

Set up model monitoring for data drift and concept drift

Option A is correct because production ML models degrade as input data distributions shift (data drift) and as the relationship between features and labels changes (concept drift), so Vertex AI Model Monitoring must track these and trigger retraining or alerts. Option E is correct because scaling to production requires reproducible, automated MLOps: CI/CD pipelines (e.g., Cloud Build, Vertex AI Pipelines) automate training, evaluation, and deployment, ensuring consistency and fast iteration. Option B is wrong because manual feature engineering per iteration does not scale and should be replaced by automated feature pipelines (e.g., Vertex AI Feature Store). Option C is wrong because a single high-memory Compute Engine VM is a non-scalable, non-resilient deployment; production serving should use managed, horizontally scalable endpoints like Vertex AI Prediction. Option D is wrong because proprietary, lock-in-heavy libraries hinder portability, maintainability, and integration with Google Cloud's managed ML services.

Answer analysis

Option-by-option breakdown

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

✓
Set up model monitoring for data drift and concept drift
Why this is correct
Production traffic inevitably diverges from training data, so monitoring for data drift and concept drift detects degradation before it harms users. This satisfies the scaling requirement by catching silent model decay that static offline evaluation cannot reveal once the prototype serves live requests.
✗
Manually engineer features for each training iteration
Why it's wrong here
Manual feature engineering per iteration does not scale and blocks reproducible retraining pipelines as data volumes grow. It is tempting because hand-crafted features often lift prototype accuracy, and would be correct during early experimentation rather than production scaling.
✗
Run the model on a single high-memory Compute Engine VM
Why it's wrong here
A single high-memory VM caps throughput and offers no horizontal scaling or redundancy, so it cannot absorb production load. It is tempting because large VMs suit memory-bound prototyping, and would be correct for a one-off batch job rather than a scaled service.
✗
Use proprietary libraries to maximize performance regardless of lock-in
Why it's wrong here
Proprietary libraries create lock-in and hinder portability across Google Cloud services and future runtimes. It is tempting because vendor-tuned libraries can squeeze out performance, and would be correct only where measured gains outweigh migration and maintenance constraints.
✓
Implement CI/CD pipelines for model training and deployment
Why this is correct
CI/CD pipelines automate retraining, testing and deployment, giving repeatable, auditable releases instead of manual notebook runs. This satisfies the production-scaling requirement by letting the team ship model updates reliably and roll back quickly when quality checks fail.

Go deeper

PMLE Practice Question: Which TWO practices are important when scaling a…

Why each option matters

Option-by-option breakdown

Related to this question