How to Deploy a New Vertex AI Model Version with Minimal Impact

You work for a retail company that is using a regression model built with BigQuery ML to predict product sales. This model is being used to serve online predictions. Recently you developed a new version of the model that uses a different architecture (custom model). Initial analysis revealed that both models are performing as expected. You want to deploy the new version of the model to production and monitor the performance over the next two months. You need to minimize the impact to the existing and future model users. How should you deploy the model?

  1. Import the new model to the same Vertex AI Model Registry as a different version of the existing model. Deploy the new model to the same Vertex AI endpoint as the existing model, and use traffic splitting to route 95% of production traffic to the BigQuery ML model and 5% of production traffic to the new model. Source Reference Answer
  2. Import the new model to the same Vertex AI Model Registry as the existing model. Deploy the models to one Vertex AI endpoint. Route 95% of production traffic to the BigQuery ML model and 5% of production traffic to the new model.
  3. Import the new model to the same Vertex AI Model Registry as the existing model. Deploy each model to a separate Vertex AI endpoint.
  4. Deploy the new model to a separate Vertex AI endpoint. Create a Cloud Run service that routes the prediction requests to the corresponding endpoints based on the input feature values.

Community Votes

A
100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The question checks your understanding of Vertex AI Model Registry versioning and endpoint traffic splitting; the trap is choosing a separate-model approach or a second endpoint, which disrupts monitoring or requires extra routing.

Learn how to deploy a new custom model version with BigQuery ML in Vertex AI using model versioning and 95/5 traffic splitting. This guide covers the canary deployment pattern recommended by experts to monitor performance with minimal impact to production users.

Option B is a common wrong answer because it also uses one endpoint and traffic splitting, but it fails to explicitly register the new artifact as a version of the existing model, making rollback and version tracking harder.

Community Discussion (6 comments)

bfdf9c8 👍 1 Selected: B
I’m considering two options, A and B. Both deploy to the same endpoint and divide traffic in a similar way. However, option B is more appropriate because it generates a new model rather than just creating a new version of the existing model.
fitri001 👍 4 Selected: A
Minimal Disruption: Deploying the new model to the same endpoint avoids changes for existing users. Traffic splitting ensures a gradual rollout, minimizing any potential impact on production. Performance Monitoring: By routing a small percentage of traffic (5%) to the new model, you can monitor its performance in a controlled environment for the next two months. Metrics like prediction accuracy and latency can be compared with the BigQuery ML model. Versioning in Model Registry: Storing both models in the same Vertex AI Model Registry with clear versioning allows easy tracking and management.
pinimichele01 👍 2 Selected: A
https://cloud.google.com/vertex-ai/docs/general/deployment#models-endpoint
Yan_X 👍 4 Selected: A
A, no need to separate endpoint.
BlehMaks 👍 2 Selected: C
as i understand we need to minimize the impact to the model users, so if we take a part of the traffic from the old model users, we will effect them. As for me we should deploy models to separated endpoints and duplicate the traffic
pikachu007 👍 2 Selected: A
B. Doesn't Specify Traffic Splitting: Deploying models to a single endpoint without explicit traffic splitting might lead to unpredictable model selection behavior, hindering controlled evaluation. C. Separate Endpoints: While isolating models, it introduces complexity in managing multiple endpoints and routing logic, increasing operational overhead. D. Cloud Run Routing: Adds complexity by requiring a separate service to manage routing, potentially increasing latency and maintenance overhead compared to Vertex AI's built-in traffic splitting.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Option A uses the Vertex AI Model Registry versioning feature by importing the new model as a different version of the existing model. This preserves the model lineage and allows you to roll back easily if the new model underperforms. Deploying to the same endpoint keeps the endpoint URL and client interface unchanged, so existing users are not forced to update their code. Traffic splitting with 95% to the BigQuery ML model and 5% to the new custom model is a classic canary deployment pattern: it exposes the new model to a small amount of real production traffic while avoiding broad impact. This lets you monitor metrics like prediction accuracy and latency over the two-month period before increasing traffic. As commenter [1] notes, the approach ensures minimal disruption and a controlled environment for performance monitoring.

Why the Other Options Are Wrong

Option B looks similar but does not explicitly say the new model is registered as a version of the existing model. In Vertex AI, importing a model to the same registry can create a separate model resource, which does not preserve the version relationship and complicates rollback and comparison. Commenter [6] argued for B, but the omission of 'different version' is the key exam trap. Option C creates separate endpoints, which would require changing the endpoint for existing users or introducing custom routing; it also does not provide the built-in traffic splitting mechanism needed for a gradual rollout. Commenter [4] favored this to avoid affecting users, but it adds unnecessary operational overhead. Option D adds a Cloud Run service to route based on feature values, which is over-engineered and not needed when Vertex AI endpoints already support serving multiple models with traffic splitting.

Community Comment Notes

The community overwhelmingly supports Option A, with commenter [2] saying 'A, no need to separate endpoint.' Commenter [3] links to the official Vertex AI deployment documentation, reinforcing that model deployment uses endpoints and model registry versioning. Commenter [5] correctly rejects C and D, though their reasoning about B is slightly off: they say B does not specify traffic splitting, but B actually does specify routing percentages. The real difference between A and B is the explicit 'different version of the existing model' phrase in A, which signals proper Vertex AI model versioning. This is the detail to watch for on the exam.

Official Reference

https://cloud.google.com/vertex-ai/docs/general/deployment#models-endpoint

Exam Strategy

Watch for wording like 'different version' vs 'same Model Registry' — if an option says 'as a different version,' it's the correct managed canary deployment. Traffic splitting (95/5) is the standard technique for A/B testing in Vertex AI, so memorize that pattern rather than creating extra endpoints.

Related Analysis

You received a training-serving skew alert from a Vertex AI

S-Grade

You are using Kubeflow Pipelines to develop an end-to-end Py

A-Grade

You developed a Python module by using Keras to train a regr

S-Grade

Practice All PMLE Questions

Access 65 questions with complete answers and detailed explanations.

View Full PMLE Practice Test →

← Back to PMLE Study Guide