PDE - Preparing and Using Data for Analysis (15% of the exam) - Section 4.2

Prepare data for AI and ML, including feature engineering, training and serving with BigQueryML, and preparing unstructured data for embeddings and retrieval-augmented generation (RAG).

Engineer features from structured data and train models using BigQuery ML, then generate embeddings for unstructured data to support retrieval-augmented generation (RAG) workflows in Vertex AI. Distinguish which preparation tasks belong in BigQuery versus Vertex AI pipelines.

BigQuery MLFeature engineeringEmbeddingsRAGVertex AI

Practice question for this objective

Free samplePreparing and Using Data for Analysishard

A retail analytics team has a BigQuery ML logistic regression model that runs in production every hour. Over the last two weeks, log loss on incoming data has crept up and the team suspects that one categorical feature, product subcategory, has shifted its distribution because new subcategory codes are being assigned by a recent merchandising change. They want a repeatable way to detect this kind of feature drift between the training data and recent serving data using BigQuery ML built-in tooling. Which approach is most appropriate?

ACall ML.TFDV_DESCRIBE on the training table and on the recent serving table, and use ML.VALIDATE_DATA_SKEW to compute Jensen-Shannon divergence and other skew statistics between the two datasets. Correct
BRecreate the model every hour with the latest seven days of data and rely on the new evaluation metrics returned by ML.EVALUATE to surface drift indirectly.
CUse ML.DESCRIBE_DATA on the training table and on the recent serving table separately, then write a SQL query that compares the standard deviation of every numeric column and flags differences above ten percent.
DSchedule ML.GLOBAL_EXPLAIN nightly and trigger an alert whenever the global feature importance of product subcategory shifts by more than one decile compared with the prior week.

Use ML.TFDV_DESCRIBE and ML.VALIDATE_DATA_SKEW in BigQuery ML to detect feature drift between training data and recent serving data. BigQuery ML exposes TensorFlow Data Validation through ML.TFDV_DESCRIBE, which captures statistics for a dataset, and ML.VALIDATE_DATA_SKEW, which compares two TFDV outputs to compute per-feature distribution skew including Jensen-Shannon divergence. This identifies categorical or numerical features whose distribution has changed between training and serving without relying on accuracy regressions to surface the problem.

Why A is correct: ML.TFDV_DESCRIBE produces TensorFlow Data Validation statistics for a dataset, and ML.VALIDATE_DATA_SKEW compares two such snapshots feature by feature, surfacing per-feature divergence so the team can pinpoint that product subcategory has drifted between training and serving.

Why B is wrong: Continuous retraining masks drift rather than detecting it, and a falling ML.EVALUATE score gives no signal about which feature distribution shifted, so the team still has to diagnose the root cause manually after the model accuracy has already degraded.

Why C is wrong: ML.DESCRIBE_DATA gives column-level summary statistics but offers no built-in distributional comparison and cannot detect a shift in a categorical feature whose values are codes rather than numbers, which is exactly the team's situation.

Why D is wrong: ML.GLOBAL_EXPLAIN reports model-level feature importance, not data distribution. Importance can stay flat while the underlying feature distribution shifts, so this would miss many real drift events and is the wrong tool for the question.

See more PDE practice questions, answers explained.

Exam traps in Preparing and Using Data for Analysis

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

Pre-compute all transformations in scheduled queries that write a flat features table, train the model on that table, and reproduce the same scheduled queries on the serving side before each prediction.
Why it is wrong: Maintaining a parallel set of scheduled queries at serving time is exactly the manual duplication the team wants to avoid and is the classic source of training and serving skew.
Use a Dataflow streaming pipeline that reads each article as it changes, calls the embedding API per row, and writes vectors directly into Vector Search without persisting anything in BigQuery.
Why it is wrong: Streaming is appropriate for near-real-time use, but it adds operational surface, sidesteps the SQL-auditability requirement, and there is no clear trigger source for nightly batch refresh of an article corpus.
Publish the rolling aggregates from BigQuery to a Memorystore for Redis instance keyed on customer id, and have the online model read from Redis while the batch model reads from BigQuery directly.
Why it is wrong: A bespoke Redis cache duplicates BigQuery state, lacks built-in point-in-time semantics, and forces the team to write and maintain their own sync code, which contradicts the requirement to minimise glue code and guarantee consistent values across both serving paths.

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