Pass the Google Cloud Professional Machine Learning Engineer exam with an AI tutor

A Vertex AI online prediction endpoint serves synchronous, low-latency predictions, which is what a sub-100 ms per-transaction requirement needs. Autoscaling on replica count adds capacity during the business-hours spike and removes it afterwards, so you match cost to demand without missing the latency target.

• B is asynchronous and high-latency by design; a five-minute batch cannot answer a single transaction in under 100 ms.
• C is not a serving mechanism. Loading a model artifact from storage per request adds cold-load latency and pushes inference onto the client.
• D routes each prediction through the data warehouse, which is built for analytical throughput, not per-request low-latency serving.

Vertex AI Pipelines give you reproducible, versioned, containerized steps with tracked inputs, outputs, and artifacts. Triggering the pipeline from the bucket's object-finalize event through a Cloud Function turns "new data arrived" into an automatic retraining run, which is continuous training (CT) done properly.

• B leaves you managing VM lifecycle and gives no built-in artifact lineage or reproducibility, and cron is time-based rather than data-driven.
• C is manual, so it is neither automatic nor reliably reproducible.
• D refreshes a table but does not orchestrate training, evaluation, and model registration.

Vertex AI Model Monitoring compares the live serving inputs against the training baseline and raises alerts when feature distributions skew or drift over time. That is exactly the "silent accuracy decay from a shifting input distribution" failure mode described, and it lets you trigger retraining before users feel it.

• B catches request failures, not a healthy endpoint returning increasingly wrong answers on shifted data.
• C changes throughput and latency, not model quality; a bigger machine predicts the same wrong values faster.
• D changes how often you score, not whether you can detect that the inputs have moved.

BigQuery ML lets a SQL-fluent team create, evaluate, and serve models with familiar SQL, directly on data that is already in BigQuery. There is no data movement and no separate training infrastructure to operate, which is precisely the low-code, minimal-infrastructure constraint in the scenario.

• B assumes ML-engineering skills the team says it lacks, and it adds a training-job workflow they do not need for a tabular churn model.
• C is heavy infrastructure to provision and operate, the opposite of the requirement.
• D is an image model applied to a tabular problem, which does not fit the data at all.

For a standard TensorFlow model, a single GPU is the natural, cost-controlled first accelerator: it gives a large speedup over CPU without the price and complexity of distributed training. You scale out to multiple GPUs only after confirming one is insufficient, which keeps spend proportional to need.

• B jumps straight to expensive, large-scale hardware that a single job rarely needs, and TPUs also require the model and ops to be TPU-compatible.
• C abandons the deep-learning model rather than accelerating it, and scikit-learn does not train DNNs on accelerators.
• D is a stateless serving runtime, not a platform for long-running, accelerated training.

A feature store centralizes feature definitions and serves the same computed values to both training and online inference. Because everyone reads features from one governed source rather than recomputing them, you remove the most common cause of training-serving skew and make features reusable across teams.

• B produces divergent, unversioned copies of features, which is precisely how skew and duplicated effort creep in.
• C lets each service compute features slightly differently from the training path, reintroducing the skew you are trying to remove.
• D is ephemeral and private to one notebook, so nothing is shared, reproducible, or servable.