Study guide
5.3 Creating & Consolidating Features in Agent Platform Feature Store
Google Cloud Professional Machine Learning Engineer PMLE
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & the Agent Platform Map
1.1 PMLE Exam Facts, Policies & the June 2026 Blueprint 1.2 From Vertex AI to Gemini Enterprise Agent Platform: The Product Name Map
2 Chapter 2: Low-Code ML with BigQuery ML
2.1 Choosing, Training & Predicting with BigQuery ML Models 2.2 Feature Engineering & Feature Selection in BigQuery ML 2.3 Fine-Tuning & Evaluating Gemini Models from BigQuery
3 Chapter 3: AutoML & Google Cloud AI APIs
3.1 Training Models with Agent Platform AutoML 3.2 Building with Document AI, Vision, Translation & Other AI APIs
4 Chapter 4: Foundation Models in Model Garden
4.1 Evaluating & Selecting Models in Model Garden 4.2 Building & Tuning Solutions with Gemini, Imagen, Veo & MaaS 4.3 Optimizing Gemini Applications for Cost, Latency & Availability
5 Chapter 5: Exploring, Preprocessing & Protecting Data
5.1 Organizing & Exploring Tabular, Text & Image Data 5.2 Choosing a Preprocessing Tool: BigQuery, Dataflow, Spark or Python 5.3 Creating & Consolidating Features in Agent Platform Feature Store 5.4 Protecting PII & Sensitive Data in ML Workflows
6 Chapter 6: Notebooks, Prototyping & Experiment Tracking
6.1 Workbench vs. Colab Enterprise: Secure, Collaborative Notebooks 6.2 Prototyping with PyTorch, scikit-learn, JAX & Model Garden in Notebooks 6.3 Experiment Environments, Tracking & Lineage with Experiments and ML Metadata
7 Chapter 7: Evaluating Predictive & Generative AI Solutions
7.1 Evaluation Metrics for Predictive Models 7.2 Evaluating Gen AI: Computation Metrics, Rubrics & LLM-as-a-Judge
8 Chapter 8: Choosing the Modeling Approach
8.1 Choosing the Model Type: ARIMA, Trees, DNNs & LLMs 8.2 Choosing the Product & Deployment Strategy 8.3 Modeling Techniques for Interpretability Requirements
9 Chapter 9: Training Data & Training SDKs
9.1 Organizing & Ingesting Training Data from Cloud Storage & BigQuery 9.2 Custom Training on Agent Platform: Containers, Jobs & Worker Pools 9.3 Kubeflow on GKE, AutoML & Tabular Workflows as Training Choices
10 Chapter 10: Troubleshooting, Hyperparameter Tuning & Fine-Tuning
10.1 Troubleshooting ML Training Failures 10.2 Hyperparameter Tuning on Agent Platform 10.3 Fine-Tuning Foundation Models & When to Tune
11 Chapter 11: Training Hardware & Distributed Training
11.1 Choosing CPUs, GPUs & TPUs for Training 11.2 Distributed Training: Data & Model Parallelism
12 Chapter 12: Deploying Models for Inference
12.1 Batch vs. Online Inference on Agent Platform 12.2 Serving Beyond Agent Platform Endpoints: Model Garden, Cloud Run & GKE 12.3 Prebuilt & Custom Serving Containers
13 Chapter 13: Model Versions, Rollouts & Inference Logic
13.1 Organizing & Versioning Models in Model Registry 13.2 Rollout Strategies: A/B Tests, Canaries & Traffic Splits 13.3 Inference Preprocessing & Postprocessing
14 Chapter 14: Scaling Online Serving
14.1 Serving Features Online with Feature Store 14.2 Public, Dedicated & Private Endpoints 14.3 Serving Hardware & Autoscaling for Throughput 14.4 Tuning Models for Production Training & Serving
15 Chapter 15: End-to-End ML Pipelines
15.1 Validating Data & Models in Pipelines 15.2 Agent Platform Pipelines with KFP: Components, Templates & Caching 15.3 Ensuring Consistent Preprocessing Between Training & Serving
16 Chapter 16: Orchestration with Managed Airflow & Ray
16.1 Orchestrating ML Workflows with Managed Service for Apache Airflow 16.2 Ray on Agent Platform for Distributed ML Workloads
17 Chapter 17: Automating Retraining & CI/CD/CT
17.1 Choosing a Retraining Policy 17.2 CI/CD/CT for ML with Cloud Build
18 Chapter 18: Securing AI Systems, Responsible AI & Explainability
18.1 Protecting AI Systems from Data & Model Exfiltration 18.2 Defending Gen AI Apps: Safety Filters, Model Armor & Regex Guardrails 18.3 Responsible AI: Detecting & Monitoring Bias 18.4 Model Explainability on Agent Platform
19 Chapter 19: Monitoring AI Solutions
19.1 Configuring Model Monitoring on Agent Platform 19.2 Training-Serving Skew, Data Drift, Concept Drift & Attribution Drift 19.3 Monitoring, Testing & Evaluating Gen AI Solutions in Production
5.3 Creating & Consolidating Features in Agent Platform Feature Store
Key Takeaways Explain This Topic AI
Agent Platform Feature Store uses BigQuery tables or views as its offline store, so no separate offline store is provisioned.
The Feature Registry organizes features into feature groups, each linked to a BigQuery source with entity ID columns and an optional feature timestamp column.
Feature Store (Legacy) and Optimized online serving were deprecated on February 17, 2026, with shutdown on February 17, 2027; Bigtable online serving is the recommended path.
Feature monitors detect drift with L-infinity distance for categorical features and Jensen-Shannon divergence for numerical features, with a default threshold of 0.3.
Offline serving fetches historical feature values for given entity IDs and timestamps from BigQuery to build point-in-time training data.
Last updated: September 2026
The exam guide asks you to create and consolidate features in Agent Platform Feature Store . The goal is organizational: many teams recompute "customer lifetime value" slightly differently, which leads to duplicated effort, inconsistent models, and training-serving skew. A feature store gives the organization one governed definition used for training and serving.
The Current Architecture: BigQuery Is the Offline Store
The current Feature Store (called Feature Store V2 in older material) works differently from the legacy product:
Feature data lives in BigQuery tables or views , which together form the offline store . Nothing is imported or copied into a separate offline store.
Feature Store acts as a metadata and serving layer : a registry of features plus online stores that serve the latest values at low latency.
Training and batch jobs read features with BigQuery's own tools, including point-in-time historical lookups.
Deprecations to know
Capability Status
Feature Store (Legacy), with entity types and its own offline store Deprecated February 17, 2026 . Shutdown February 17, 2027 . Migrate to the current Feature Store
Optimized online serving Deprecated February 17, 2026. Shutdown February 17, 2027. Migrate to Bigtable online serving , and use Vector Search for embeddings
Bigtable online serving Current recommended online serving for large data volumes
If an older practice question mentions entity types, ingestion jobs into a Feature Store offline store, or Optimized online serving for a new design, translate it to BigQuery sources, feature groups, and Bigtable online serving.
- Data Model
- Prepare the BigQuery source
At least one entity ID column (string or int, each value under 4 KB). The default name is entity_id , and you can combine several ID columns into a composite key.
Optional feature timestamp column (default feature_timestamp ) when the data is a time series with several rows per entity.
One column per feature . Supported types include bool, int, float, string, timestamp, bytes, and arrays of these.
The source must be in the same region as the online store, or in a multi-region that includes it.
Register in the Feature Registry (optional but recommended)
Resource What it represents
FeatureGroup A logical group of features from one BigQuery table or view, with entity ID columns and (for time series) a timestamp column
- Feature A specific column in that source
- FeatureMonitor A schedule for computing statistics and detecting drift on selected features
- FeatureMonitorJob The statistics and anomalies produced by one monitoring run
Register features when the source has multiple rows per entity (so the store serves only the latest value by timestamp), when you want to pick specific columns , when you want to combine features from several sources into one feature view, or when you need feature monitoring . Without registration, each row must hold the single latest record for a unique ID.
Consolidating Features Across Teams
A practical consolidation program:
Inventory duplicate feature logic across teams (for example, five versions of "30-day purchase count").
Agree on one definition and implement it once as a scheduled BigQuery transformation or Dataflow pipeline that writes a feature table.
Register the table as a feature group, with descriptions and labels so others can find it.
Retire the duplicates, and point models at the registered features.
Monitor the shared features for drift so every consuming model benefits.
Naming conventions that encode entity, window, and aggregation (such as customer_purchases_30d_count ) make features searchable and self-documenting.
Offline Serving: Point-in-Time Training Data
To train a model, you need each feature's value as it was when the label event happened , not today's value. Offline serving (preview at the time of writing) fetches historical values for a set of entity IDs and timestamps. In Python this is fetch_historical_feature_values with an entity DataFrame of IDs and timestamps. It requires registered feature groups, and every row for the same entity must have a different timestamp. In SQL, BigQuery ML's ML.FEATURES_AT_TIME does the same kind of cutoff-aware lookup.
Example: For a loan default model with applications dated across 2025, join each application to the applicant's credit_utilization_90d as of the application date. Using the value from today would leak information from after the loan was issued.
Online Stores and Feature Views (Preview of Chapter 14)
An online store ( FeatureOnlineStore ) is the serving cluster. A feature view ( FeatureView ) inside it selects features from feature groups, or directly from a BigQuery source, and syncs them for low-latency reads. Sync can be scheduled (cron) or, for Bigtable online serving with registered feature groups in supported locations, continuous . Serving details are covered in Section 14.1.
Why Not Just Share BigQuery Tables?
Plain shared tables solve part of the problem, and the current Feature Store builds on them. The Feature Store adds:
Need Plain BigQuery table Feature Store on top of BigQuery
Latest value per entity at low latency for online inference Not designed for millisecond key lookups Online store and feature views
Discoverable, documented feature definitions Naming conventions only Feature Registry with feature groups and features
- Point-in-time historical retrieval Hand-written joins Offline serving by entity and timestamp
- Drift detection on shared features Custom jobs Feature monitors
If a use case is batch only and a well-governed BigQuery feature table meets it, that can be enough. Choose Feature Store when features must also be served online or governed and monitored across teams.
Monitoring Features for Drift
A feature monitor runs on a cron schedule and compares snapshots from consecutive runs using BigQuery's ML.TFDV_VALIDATE :
Categorical features: L-infinity distance .
Numerical features: Jensen-Shannon divergence .
Drift threshold per feature in the range [0, 1). The default is 0.3 .
Feature-level drift monitoring complements model-level monitoring (Chapter 19). If a shared feature shifts, every model that uses it is at risk.