PMLE Practice Question: Collaborating Within and Across Teams to Manage Data and Models

A data science team wants to share a set of engineered features across multiple projects and teams to reduce training-serving skew and ensure consistency. They need low-latency serving (single-digit milliseconds) for online predictions and also need to retrieve historical feature values for training. Which approach should they take?

⚠ Common exam trap

PMLE often tests the misconception that a data warehouse like BigQuery can serve online predictions with low latency, or that a simple key-value store like Redis suffices for both online and offline needs, ignoring the need for point-in-time correct historical retrieval and centralized feature definitions.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use Vertex AI Feature Store to define features once, serve online predictions from the online store, and retrieve historical features from the offline store for training.

Vertex AI Feature Store is a fully managed, purpose-built feature store that centralizes feature definitions and provides both an online store for low-latency serving and an offline store for historical retrieval. The online store is optimized for single-digit millisecond reads, while the offline store (backed by BigQuery) allows point-in-time correct feature retrieval for training, which directly addresses training-serving skew. By defining features once and reusing them across projects, it ensures consistency between training and serving.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Use Vertex AI Feature Store to define features once, serve online predictions from the online store, and retrieve historical features from the offline store for training.
Why this is correct
Feature Store decouples feature engineering from consumption: one definition feeds both the low-latency online store for serving and the offline store for point-in-time historical retrieval, eliminating training-serving skew. Reusing a Cloud Storage copy cannot meet single-digit millisecond online latency.
✗
Create a shared BigQuery dataset where each team writes features; serve predictions by querying BigQuery synchronously.
Why it's wrong here
Synchronous BigQuery queries cannot meet single-digit-millisecond online serving, and each team writing its own features reintroduces the inconsistency the team wants to eliminate. BigQuery suits analytical and batch retrieval, not a shared low-latency feature store.
✗
Store features in Cloud Storage Parquet files and load them into BigQuery for training; serve predictions from a custom microservice that reads from Cloud Storage.
Why it's wrong here
Cloud Storage plus a custom microservice provides no feature store, so online reads incur object-storage latency and training/serving skew persists because the same transformations are not reused. It is tempting because Parquet on Cloud Storage with BigQuery is a valid batch analytics pattern, but it cannot meet single-digit-millisecond serving.
✗
Use Cloud Memorystore (Redis) to store the latest feature values for low-latency serving; each team independently computes features and pushes to Redis.
Why it's wrong here
Redis holds only the latest values, so historical feature retrieval for training is impossible, and independent computation by each team preserves training-serving skew. Redis is correct as the online serving layer of a feature store, paired with a managed store for point-in-time history.

Go deeper

PMLE Practice Question: Collaborating Within and Across Teams to Manage Data and Models

Why each option matters

Option-by-option breakdown

Related to this question