How to Reconfigure Architecture for Real-Time ML Recommendations?

Your company manages an ecommerce website. You developed an ML model that recommends additional products to users in near real time based on items currently in the user’s cart. The workflow will include the following processes: 1. The website will send a Pub/Sub message with the relevant data and then receive a message with the prediction from Pub/Sub 2. Predictions will be stored in BigQuery 3. The model will be stored in a Cloud Storage bucket and will be updated frequently You want to minimize prediction latency and the effort required to update the model. How should you reconfigure the architecture?

  1. Write a Cloud Function that loads the model into memory for prediction. Configure the function to be triggered when messages are sent to Pub/Sub.
  2. Create a pipeline in Vertex AI Pipelines that performs preprocessing, prediction, and postprocessing. Configure the pipeline to be triggered by a Cloud Function when messages are sent to Pub/Sub.
  3. Expose the model as a Vertex AI endpoint. Write a custom DoFn in a Dataflow job that calls the endpoint for prediction.
  4. Use the RunInference API with WatchFilePattern in a Dataflow job that wraps around the model and serves predictions. Source Reference Answer

Community Votes

D
65%
A
35%

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

Community Insight

The exam tests your ability to choose a low-latency serving architecture that avoids a separate endpoint, with the trap being that a Cloud Function appears simple but suffers from cold starts and Pub/Sub synchronous-response limitations.

The recommended answer is to use the RunInference API with WatchFilePattern in a Dataflow job, which minimizes prediction latency and simplifies model updates by loading the model directly into the pipeline and automatically reloading it when the Cloud Storage model changes. Community consensus strongly favors this approach (61 votes) over a Cloud Function alternative (33 votes).

Option A (Cloud Function loading the model into memory) is the most common wrong answer. It ignores Cloud Function cold start latency, memory/timeout limits, the inability to easily return a prediction synchronously via Pub/Sub, and the operational overhead of reloading the model on every function invocation when the model is updated frequently.

Community Discussion (8 comments)

guilhermebutzke 👍 6 Selected: D
My answer: D This Google Documentation explains “Instead of deploying the model to an endpoint, you can use the RunInference API to serve machine learning models in your Apache Beam pipeline. This approach has several advantages, including flexibility and portability.” https://cloud.google.com/blog/products/ai-machine-learning/streaming-prediction-with-dataflow-and-vertex This documentation uses RunInference and WatchFilePattern to “to automatically update the ML model without stopping the Apache Beam”. https://cloud.google.com/dataflow/docs/notebooks/automatic_model_refresh So, thinking in “minimize prediction latency”, its suggested use RunInfenrece, while “effort required to update the model” the WatchFilePattern is the best approach. I think D is the best option
phani49 👍 1 Selected: D
Exposing the model as a Vertex AI endpoint and using Dataflow with a custom DoFn provides the optimal solution for real-time predictions with minimal latency. https://cloud.google.com/blog/products/ai-machine-learning/streaming-prediction-with-dataflow-and-vertex
lunalongo 👍 3 Selected: A
A is the best option because: - Minimizes Latency: Loading the model into the Cloud Function's memory eliminates the overhead of loading the model from storage for each prediction request. This significantly reduces latency, crucial for near real-time recommendations. The function is triggered directly by Pub/Sub messages, further streamlining the process. - Simplified Model Updates: Updating the model involves simply deploying a new version of the Cloud Function with the updated model. This is a much simpler process than managing pipelines or endpoints. D is the most voted so far, but... The complexity of managing the Dataflow pipeline and the potential latency introduced by the pipeline outweigh the benefits of automatic model updates using WatchFilePattern in this context. Therefore, option A (Cloud Function) remains the most efficient solution.
PhilipKoku 👍 1 Selected: C
C) Expose the model as Vertex AI End Point
pinimichele01 👍 1 Selected: D
agree with guilhermebutzke
Yan_X 👍 1 Selected: A
A for me.
ddogg 👍 3 Selected: D
Automatic Model Updates: WatchFilePattern automatically detects model changes in Cloud Storage, leading to seamless updates without managing endpoint deployments.
pikachu007 👍 2 Selected: A
Low Latency: Serverless Execution: Cloud Functions start up almost instantly, reducing prediction latency compared to alternatives that require longer setup or deployment times. In-Memory Model: Loading the model into memory eliminates disk I/O overhead, further contributing to rapid predictions.

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 D uses the RunInference API in an Apache Beam/Dataflow pipeline, which embeds the model directly in the stream processing job. This avoids the extra network call to a separate Vertex AI endpoint, reducing latency. The WatchFilePattern feature automatically detects changes to the model in Cloud Storage and reloads it without manual redeployment, meeting the requirement to minimize model update effort. Comments highlight Google's documentation stating that RunInference provides flexibility and portability, and that automatic model updates are a key advantage.

Why the Other Options Are Wrong

Option A has severe limitations for near real-time synchronous predictions: Cloud Functions are event-driven and asynchronous, making it hard to return a prediction directly to the publisher; cold starts add latency, and memory limits restrict model size. Model updates would require reloading from GCS on each invocation or redeploying the function. Option B relies on Vertex AI Pipelines, which are designed for batch orchestration, not low-latency streaming. Option C introduces a custom DoFn that calls a Vertex AI endpoint, adding network overhead and requiring endpoint versioning and management; it also increases latency compared to in-pipeline inference.

Community Comment Notes

Comments with 6 likes and 3 likes support D, citing Google's blog that RunInference is a better approach for streaming predictions. The 33 votes for A reflect the intuitive appeal of a serverless function, but commenters [2] and [4] overlook cold starts and Pub/Sub request-response limitations. One comment [5] appears to confuse D and C, but the official documentation and suggested answer confirm D as the best choice.

Official Reference

Exam Strategy

When asked to minimize prediction latency and model-update effort, look for an option that performs inference inside the stream processing job and automatically watches for model changes in Cloud Storage. Avoid options that require a separate serving endpoint or manual redeployment, even if they appear simpler at first glance.

Related Analysis

You work for a semiconductor manufacturing company. You need

S-Grade

You need to deploy a scikit-leam classification model to pro

S-Grade

You work for a large retailer, and you need to build a model

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