Task 2.1: Exploring and preprocessing data for ML.

• AGoogleSQL transformations in BigQuery over an external table

  Incorrect

  BigQuery is the recommended tool for structured and semi-structured data; resizing image bytes into TFRecord shards is not a SQL task.

• BA one-off pandas script in an Agent Platform Workbench instance

  Incorrect

  One-off Python scripts are for smaller datasets that fit into memory, not 6 TB of photos every week.

• CA Dataflow pipeline built with the Apache Beam SDK

  Correct

  Dataflow suits large volumes and can convert unstructured data into binary formats such as TFRecord, and it uses the Beam model the team knows.

• DA batch workload on Managed Service for Apache Spark serverless

  Incorrect

  Serverless Spark fits an organization invested in Spark code and skills, which this team does not have.

Google Cloud's ML best practices recommend BigQuery for structured and semi-structured data, Dataflow for large volumes (including converting unstructured data to TFRecord for faster ingestion), Managed Service for Apache Spark when the organization has a Spark codebase and skills, and one-off Python scripts for small datasets that fit in memory.

• AAn online store for Optimized online serving, with a feature view synced on a five-minute schedule

  Incorrect

  Optimized online serving is deprecated, and it supports only scheduled sync, not continuous sync.

• BAn online store for Bigtable online serving, with a feature view that uses continuous data sync

  Correct

  Bigtable online serving handles terabytes and supports continuous sync, which syncs new feature records from BigQuery as they are written.

• CAn online store for Bigtable online serving, with a feature view synced once a day by a cron schedule

  Incorrect

  A daily sync leaves features up to a day old, which misses the within-minutes requirement.

• DA feature group on the table, with the model querying BigQuery directly for each prediction

  Incorrect

  A feature group only registers the source; without an online store and feature view nothing serves the features online.

Agent Platform Feature Store keeps feature data in BigQuery and serves it through online store instances and feature views. Bigtable online serving is suited to terabytes of data and supports scheduled and continuous data sync; continuous sync refreshes the feature view as new feature records land in the BigQuery source (it does not sync rows that are updated or deleted in place). Optimized online serving is deprecated and supports only scheduled sync.

• AML.FEATURES_AT_TIME, with the time argument set to the latest decision date in the label table

  Incorrect

  This applies one cutoff to every customer, so earlier decisions get feature values recorded after their own date.

• BML.ENTITY_FEATURES_AT_TIME, with the customer IDs and decision dates from the label table as its entity time table

  Correct

  It looks up features at a separate point-in-time cutoff for each entity and time, so no example sees values from after its decision.

• CA join of each label to the most recent feature snapshot of the same customer

  Incorrect

  The most recent snapshot usually comes after the decision date, so the model learns from information it would not have had at the time.

• DThe decision date added as an extra column to the most recent feature snapshot of each customer

  Incorrect

  An extra date column does not remove the later feature values, so the leak remains.

Features can have time dependencies, and BigQuery ML recommends point-in-time features for training and inference to avoid data leakage. ML.FEATURES_AT_TIME uses the same point-in-time cutoff for all entities. ML.ENTITY_FEATURES_AT_TIME takes an entity time table that maps entity IDs to lookup times and returns, for each of its rows, the features created at or before that time, so each customer gets the values known at its own decision date.

• AA view over the table that keeps only each entity ID's newest feature rows

  Incorrect

  A daily view is what you build when you skip the registry; with a feature group the timestamp column handles it.

• BThe entity ID column and the feature timestamp column

  Correct

  For time-series data the feature group needs a timestamp column, and Feature Store serves the latest value for each entity ID.

• CAn online store with Optimized online serving and embeddings

  Incorrect

  The online store type is chosen later, for serving, and does not decide which row is the latest.

• DA separate feature table for each day, named by its timestamp

  Incorrect

  Splitting by day breaks the single source the feature group points at and is not needed.

A feature group points at a BigQuery table or view and contains one or more entity ID columns. If the feature data is in time-series format, the feature group must also contain a timestamp column (feature_timestamp by default), and Feature Store serves only the latest feature values for each entity ID.

• ACreate a Data Labeling Service job with the team as labelers

  Incorrect

  The Data Labeling Service has been shut down, so new jobs cannot be created.

• BTrain an AutoML model on the unlabeled images to label them

  Incorrect

  AutoML classification needs labeled examples to train on.

• CAdd the labels to the dataset in the Google Cloud console

  Correct

  The console lets you import labeled or unlabeled image data and add labels to the dataset yourself.

• DUse Gemini on Google Cloud to write the labels straight into the dataset's training split

  Incorrect

  Unreviewed model labels can be wrong and are not the team's own labeling.

The legacy AI Platform Data Labeling Service and the Data Labeling Service were deprecated and shut down. For new labeling tasks, add labels in the Google Cloud console or use data labeling solutions from partners in the Google Cloud Marketplace.

• ALog scaling of the review count

  Correct

  Log scaling helps when data follows a power law, where a few values are huge and most are small.

• BLinear scaling of the count to the range 0 to 1

  Incorrect

  Linear scaling keeps the shape of the distribution, so the few huge values still squash all the others together.

• COne-hot encoding of every distinct count

  Incorrect

  Treating counts as categories throws away their order and creates a huge, sparse vocabulary.

• DZ-score scaling of the count

  Incorrect

  Z-score scaling suits roughly normal distributions, not a long-tailed power law.

Common normalization methods are linear scaling, Z-score scaling and log scaling, with clipping for outliers. Log scaling is helpful when the data conforms to a power law distribution, such as ratings or sales per item, and changes the distribution so the model learns better.

• ARemove the rare failure rows as outliers before training

  Incorrect

  The failures are the class the model must learn; removing them makes the problem impossible.

• BDuplicate the failure rows until they match the normal readings in number

  Incorrect

  Heavy duplication without reweighting shifts the predicted probabilities toward the rare class.

• CTrain on the full data with a larger batch size and no other change to the data

  Incorrect

  Bigger batches help a little but keep the same imbalance and waste most of each batch on one class.

• DDownsample the normal readings and upweight them by the same factor

  Correct

  This puts failures in more batches while the weight keeps the predictions calibrated to the real class balance.

For class-imbalanced data, Google's Machine Learning Crash Course recommends downsampling the majority class and upweighting the downsampled class by the same factor. Batches then contain enough minority examples, while upweighting reduces the prediction bias that downsampling alone would add.