PMLE - Serving and Scaling Models (20% of the exam) - Section 4.2

Scale online model serving by managing and serving features with the Feature Store, deploying to public and private endpoints, choosing CPU, GPU, TPU, and edge hardware, scaling the serving backend for throughput, and tuning models for production training and serving.

Serve and manage features at prediction time using the Agent Platform Feature Store, deploy models to public or private endpoints based on network and security requirements, and select CPU, GPU, TPU, or edge hardware to match latency and throughput targets. Configure serving backend scaling to handle variable traffic without over-provisioning.

Agent Platform Feature StorePrivate endpointsServing backend scalingEdge serving

Practice question for this objective

Free sampleServing and Scaling Modelsmedium

A team has registered feature groups in Vertex AI Feature Store and now needs the online prediction service to read the freshest feature values with single-digit millisecond latency at request time. Historical values for training already sit in BigQuery. Which TWO actions together are required to make these features available for low-latency online reads? (Select TWO.)

AQuery the same BigQuery source table directly from inside the prediction handler at request time, relying on BigQuery to return the latest feature row per entity.
BMaterialise the features into a Cloud Storage prefix as Parquet and have the handler scan that prefix for the relevant entity on each prediction call.
CCreate an online store instance for the feature data so that values are held in a low-latency serving store optimised for per-entity point lookups. Correct
DLower the prediction endpoint's autoscaling target utilisation so that extra replicas absorb the latency added by reading features from the offline store.
EConfigure feature serving so that the registered features are synced into the online store, keeping the served values current for each entity. Correct

Low-latency online feature serving requires materialising registered features into a Feature Store online store and keeping it synced, not querying the offline BigQuery source at request time. The Feature Store online path serves per-entity point lookups from a dedicated online store engineered for millisecond reads, and those values stay current only when registered features are synced into it. Querying BigQuery or scanning Cloud Storage delivers analytical latency, and autoscaling the endpoint changes throughput, not the read latency of the offline store.

Why A is wrong: It tempts because the freshest values do live in BigQuery, but interactive BigQuery queries deliver analytical-scale latency, not the single-digit millisecond reads an online endpoint needs.

Why B is wrong: Parquet on Cloud Storage suits bulk offline reads, so it looks like a cheap store, but scanning object storage per request cannot meet online point-lookup latency.

Why C is correct: An online store provides the low-latency, key-based serving layer that returns a single entity's current feature values within milliseconds at request time.

Why D is wrong: Adding replicas scales request throughput, but it does not change the offline store's read latency, so feature reads stay slow regardless of replica count.

Why E is correct: Syncing the registered features into the online store is what keeps each entity's served values fresh, which is required before low-latency online reads return current data.

See more PMLE practice questions, answers explained.

Exam traps in Serving and Scaling Models

Answers that look right on this material and are not. Each one is a distractor from a different question in the PMLE bank for this domain.

The online path scans the full historical table at request time and returns the average of all recorded values for each entity.
Why it is wrong: It is tempting because the same ingested data backs both paths, but scanning the historical table per request would add seconds of latency and averaging values is not how point lookups work, so this misdescribes the mechanism.
The online path runs each read as a scan over the full historical feature table, then returns only the most recent row to the caller.
Why it is wrong: This is tempting because the offline store does hold full history, but scanning history per request would be slow; the online path avoids history scans precisely to hit single-digit millisecond reads.
Assigning the deployed model an external IP and an HTTPS load balancer is sufficient, because TLS encryption already prevents the traffic from being treated as public internet traffic.
Why it is wrong: Encryption protects data in transit, so this feels secure, but a public IP still routes over the internet, which violates the requirement that traffic stay off the public network.

Examworthy is not affiliated with or endorsed by Google Cloud. Original, blueprint-aligned practice material only.