PMLE Scaling Prototypes into ML Models Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Support for GPUs during preprocessing

  Why it's wrong here

  tf.Transform runs its Apache Beam pipeline on Dataflow workers, which are CPU-only, so GPU acceleration is unavailable; its value lies in emitting a reusable transform graph. GPU preprocessing suits frameworks such as RAPIDS cuDF or TensorFlow ops on GPU instances, which would be chosen when throughput demands hardware acceleration.

• ✗

  Built-in feature store integration

  Why it's wrong here

  tf.Transform outputs a transform function embedded in the exported SavedModel, guaranteeing identical preprocessing at serving time; that consistency, not feature store linkage, is its benefit. Feature store integration is genuinely provided by Vertex AI Feature Store, which would be the right answer if the stem asked about online feature serving rather than training-serving skew.

• ✗

  Faster data processing

  Why it's wrong here

  tf.Transform executes as an Apache Beam pipeline, typically on Dataflow, so it inherits that runner's throughput rather than exceeding it; the gain is a portable transform graph applied consistently at serving. Raw speed alone would favour tuning Dataflow worker counts, autoscaling or sharding, not adopting tf.Transform.

• ✓

  Training/serving skew prevention through a consistent transformation graph

  Why this is correct

  tf.Transform records the full preprocessing graph and applies it identically at training and prediction, eliminating training/serving skew. Dataflow alone executes transforms but does not preserve that reusable graph, so the same feature engineering cannot be replayed consistently at serving time on Vertex AI.

Go deeper

Related to this question