How to Automate Vertex AI Model Retraining Efficiently?

You have developed a BigQuery ML model that predicts customer chum, and deployed the model to Vertex AI Endpoints. You want to automate the retraining of your model by using minimal additional code when model feature values change. You also want to minimize the number of times that your model is retrained to reduce training costs. What should you do?

1 Enable request-response logging on Vertex AI Endpoints
1. Enable request-response logging on Vertex AI Endpoints
1. Create a Vertex AI Model Monitoring job configured to monitor prediction drift Source Reference Answer
1. Create a Vertex AI Model Monitoring job configured to monitor training/serving skew

Community Votes

50%

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

Community Insight

This question evaluates your ability to differentiate between static data validation checks and continuous production monitoring, with test-takers often misapplying skew detection to long-term operational scenarios.

Automating BigQuery ML retraining on Vertex AI relies on configuring Model Monitoring jobs to detect production data shifts. Community analysis consistently points to prediction drift monitoring as the optimal approach for triggering cost-effective, scheduled retraining pipelines.

Option D is the most frequent distractor; candidates select it assuming any feature distribution mismatch requires skew monitoring, overlooking that skew is strictly an initial deployment validation tool rather than a continuous retraining trigger.

Community Discussion (17 comments)

guilhermebutzke 👍 7 Selected: D

My answer: D Given the emphasis on "model feature values change" in the question, the most suitable option would be D. Although option C involves monitoring prediction drift, which may indirectly capture changes in feature values, option D directly addresses the need to monitor training/serving skew. By detecting discrepancies between the training and serving data distributions, option D is more aligned with the requirement to automate retraining when model feature values change. Therefore, option D is the most suitable choice in this context.

bc3f222 👍 1 Selected: C

Training/serving skew monitoring is best used to detect mismatches between training and serving data schemas—not feature drift over time. Prediction drift is more relevant for this use case.

f084277 👍 2 Selected: C

Skew is static, drift happens over time. Answer is C.

bobjr 👍 4 Selected: C

Skew should be detected at the beginning of the productionalisation of the model -> skew test the training data Vs the real data -> a skew indicates you trained in a dataset that is not alined with your data that you have in input Drift is used when the model works well at the beginning, but the world change and the data input changes -> drift is more long term here it is a drift issue

Shno 👍 1

if the model training is done through bigquery ML, we don't have access to the training data after export, so I don't understand how training/serving skew can be applied. Can someone who is voting in favour of D clarify?

gscharly 👍 1 Selected: D

I go with D

pinimichele01 👍 1 Selected: D

It's D

CHARLIE2108 👍 3 Selected: D

changed my mind it's D

CHARLIE2108 👍 3 Selected: C

I go with C but D is pretty similar. C -> Prediction drift (When the overall distribution of predictions changes significantly between training and serving data). D -> Training/serving skew (When the distribution of specific features between training and serving data differs significantly).

ddogg 👍 3 Selected: C

Option C: This option directly addresses your requirements: Vertex AI Model Monitoring: It allows efficient monitoring of prediction drift through metrics like Mean Squared Error or AUC-ROC. Pub/Sub alerts: Alert triggers notification upon significant drift, minimizing unnecessary retraining. Cloud Function: It reacts to Pub/Sub messages and triggers retraining in BigQuery using minimal additional code.

b1a8fae 👍 3 Selected: C

After reconsidering, I think it is C: - No need to use TF to enable model monitoring as stated here: https://cloud.google.com/vertex-ai/docs/model-monitoring/using-model-monitoring (even if it uses it under the hood: https://cloud.google.com/vertex-ai/docs/model-monitoring/overview#calculating-skew-and-drift) - The problem speaks about alerting of model feature changes, which happens over time, and uses a baseline of the historical production data -> prediction skew. (if the problem specified that it changes compared to training data, then it would be training-skew) (https://cloud.google.com/vertex-ai/docs/model-monitoring/monitor-explainable-ai#feature_attribution_training-serving_skew_and_prediction_drift)

b1a8fae 👍 4 Selected: D

I would avoid using TensorFlow validation to minimize code written. That leaves us with options C and D. Now, since it is the values of the features that we want to flag and not the value of the predictions, this sounds more like training-serving skew situation than prediction drift. Hence, I would go for D.

BlehMaks 👍 1 Selected: D

i've changed my mind) it's D https://www.evidentlyai.com/blog/machine-learning-monitoring-data-and-concept-drift

BlehMaks 👍 1 Selected: D

we might need to retrain if the feature data distribution in the production and training are significantly different(training/serving skew). Prediction drift occurs when feature data distribution in production changes significantly over time. Should we retrain our model every time when we meet prediction drift? I dont think so, better to analyze why this drift happens. https://cloud.google.com/vertex-ai/docs/model-monitoring/overview#considerations

36bdc1e 👍 2

C The best option for automating the retraining of your model by using minimal additional code when model feature values change, and minimizing the number of times that your model is retrained to reduce training costs, is to create a Vertex AI Model Monitoring job configured to monitor prediction drift, configure alert monitoring to publish a message to a Pub/Sub queue when a monitoring alert is detected, and use a Cloud Function to monitor the Pub/Sub queue, and trigger retraining in BigQuery. This option allows you to leverage the power and simplicity of Vertex AI, Pub/Sub, and Cloud Functions to monitor your model performance and retrain your model when needed. Vertex AI is a unified platform for building and deploying machine learning solutions on Google Cloud.

pikachu007 👍 2 Selected: C

A and B: TensorFlow Data Validation jobs require more setup and maintenance, and they might not integrate as seamlessly with Vertex AI Endpoints for automated retraining. D: Monitoring training/serving skew focuses on differences between training and deployment environments, which might not directly address feature value changes.

vale_76_na_xxx 👍 2

I go with : C. 1. Create a Vertex AI Model Monitoring job configured to monitor prediction drift - > if the modle is already in production we have to considet Prediction drift 2. Configure alert monitoring to publish a message to a Pub/Sub queue when a monitoring alert is detected -> set Pub/Sub notification channels. 3. Use a Cloud Function to monitor the Pub/Sub queue, and trigger retraining in BigQuery -> to eimport new data in BQ

Comments & Corrections

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

Expert Analysis

Why the Answer Is Correct

Vertex AI Model Monitoring configured for prediction drift continuously analyzes incoming requests against baseline metrics to identify significant distribution changes over time. When drift exceeds defined thresholds, it triggers Pub/Sub alerts that seamlessly integrate with Cloud Functions or Dataform to initiate automated BigQuery ML retraining. This architecture minimizes manual code overhead while ensuring models only retrain when statistically necessary, directly addressing cost and efficiency requirements.

Why the Other Options Are Wrong

Request-response logging (Options A/B) merely captures raw traffic without analyzing statistical distributions or triggering automated workflows. Training/serving skew (Option D) compares current serving data against historical training data to catch immediate pipeline errors, making it unsuitable for detecting gradual feature changes that occur months after deployment. Skew monitoring lacks the temporal thresholding required to prevent excessive retraining cycles.

Community Comment Notes

Multiple high-voted comments clarify that skew represents a static deployment mismatch while drift captures evolving production patterns [Comment 2, 7]. Several users initially selected D but revised their answers after recognizing that feature value changes in live environments constitute drift rather than skew [Comment 6, 14]. The consensus emphasizes pairing drift alerts with Pub/Sub subscriptions to achieve the stated automation goals with minimal custom code.

Official Reference

Exam Strategy

Always map temporal keywords like 'over time,' 'gradual changes,' or 'live environment' to prediction drift, while reserving skew for initial deployment validation questions. Prioritize managed services like Vertex AI Model Monitoring over custom TensorFlow Data Validation jobs to satisfy 'minimal additional code' constraints in MLOps scenarios.

Related Analysis

Practice All PMLE Questions

Access 65 questions with complete answers and detailed explanations.

View Full PMLE Practice Test →

← Back to PMLE Study Guide