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.

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.check_circle 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.check_circle Correct

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.