Scenario practice questions

A company has a prototype ML model that predicts equipment failure. They want to deploy it to production using Vertex AI. The model must be retrained weekly with new data. They also need to monitor for data drift and model performance. Which THREE components should they include in their MLOps pipeline? (Choose 3)

Trap 1: A manual QA step where data scientists approve each deployment.

Manual approval gates deployments on human availability, so weekly retraining cannot run unattended; drift and performance monitoring need automated triggers instead. It is tempting because human sign-off suits regulated, low-frequency releases where auditability outweighs cadence, not scheduled weekly pipelines.

Trap 2: A manual review of new data before it is used for training.

Manual review adds human latency and does not scale to weekly retraining, and it provides no drift or performance monitoring. It is tempting where regulatory approval of training data is mandatory, but automated pipelines with Vertex AI Pipelines and Model Monitoring satisfy this scenario.

A
A scheduled training pipeline that retrains the model weekly.
Weekly retraining satisfies the stem's explicit cadence requirement. A scheduled Vertex AI pipeline automates ingestion of new data, retrains the model, and registers an updated version, removing manual intervention. This directly fulfils the stated need to retrain weekly with fresh data.
B
A manual QA step where data scientists approve each deployment.
Why it fails: Manual approval gates deployments on human availability, so weekly retraining cannot run unattended; drift and performance monitoring need automated triggers instead. It is tempting because human sign-off suits regulated, low-frequency releases where auditability outweighs cadence, not scheduled weekly pipelines.
C
A manual review of new data before it is used for training.
Why it fails: Manual review adds human latency and does not scale to weekly retraining, and it provides no drift or performance monitoring. It is tempting where regulatory approval of training data is mandatory, but automated pipelines with Vertex AI Pipelines and Model Monitoring satisfy this scenario.
D
An automated trigger that redeploys the model when performance drops below a threshold.
The stem requires monitoring for model performance, not just observing it. An automated trigger comparing live metrics against a threshold and redeploying a retrained model closes the loop, ensuring degraded predictions are corrected without manual intervention, satisfying the production reliability requirement.
E
A monitoring system that checks for data drift and triggers alerts.
Data drift and performance monitoring are named requirements in the stem. A monitoring system comparing live inference distributions against training baselines detects drift and degradation, raising alerts so the team can act. This directly satisfies the stated monitoring constraint.

Question 2hardmulti select

An ML engineer is building a monitoring dashboard for a Vertex AI pipeline that includes training, evaluation, and batch prediction. Which THREE components should be included to provide comprehensive observability? (Select THREE.)

Trap 1: Compute engine CPU and memory logs for each pipeline step.

Pipeline-step CPU and memory metrics describe the underlying Compute Engine VMs, not the ML workflow itself. Vertex AI Pipelines exposes task-level execution metadata, artefacts, and lineage; the dashboard needs those pipeline-run signals. Host metrics would be the right choice when diagnosing infrastructure saturation on self-managed training VMs.

Trap 2: Online prediction latency and request count from the deployed model…

The pipeline covers training, evaluation, and batch prediction, so endpoint request metrics sit outside its scope — no deployed online endpoint is involved. Online latency and request counts belong on a dashboard for a real-time prediction service, where traffic volume and tail latency drive autoscaling and SLO alerting.

A
Pipeline execution status, duration, and failure rates for each component.
Pipeline execution status, duration, and failure rates expose orchestration-level telemetry for each training, evaluation, and batch prediction step, satisfying the requirement for comprehensive observability across the whole Vertex AI pipeline. These metrics reveal where runs stall or fail, which resource-level metrics alone cannot attribute to a specific component.
B
Compute engine CPU and memory logs for each pipeline step.
Why it fails: Pipeline-step CPU and memory metrics describe the underlying Compute Engine VMs, not the ML workflow itself. Vertex AI Pipelines exposes task-level execution metadata, artefacts, and lineage; the dashboard needs those pipeline-run signals. Host metrics would be the right choice when diagnosing infrastructure saturation on self-managed training VMs.
C
Model evaluation metrics (e.g., accuracy, AUC) after training and validation.
Model evaluation metrics capture predictive quality after training and validation, satisfying the pipeline's evaluation stage. Vertex AI writes these to Vertex ML Metadata, letting the dashboard track accuracy and AUC drift across runs. Without them, observability covers infrastructure and data but not model behaviour, leaving a monitoring gap the stem explicitly requires.
D
Data validation reports showing anomaly counts and feature statistics.
Data validation reports expose input drift and schema violations before they corrupt downstream training or predictions, satisfying the pipeline-wide observability requirement. Vertex AI's built-in validation surfaces anomaly counts and feature statistics per split, letting the dashboard flag skew between training and serving data — a gap that resource metrics alone cannot detect.
E
Online prediction latency and request count from the deployed model endpoint.
Why it fails: The pipeline covers training, evaluation, and batch prediction, so endpoint request metrics sit outside its scope — no deployed online endpoint is involved. Online latency and request counts belong on a dashboard for a real-time prediction service, where traffic volume and tail latency drive autoscaling and SLO alerting.

Question 3hardmultiple choice

A machine learning engineer is building a Vertex AI pipeline that uses a pre-built AutoML Tables component to train a classification model. The pipeline also includes a conditional step that deploys the model to an endpoint only if the evaluation metrics exceed a threshold. Which KFP feature should be used to implement the conditional deployment?

Trap 1: dsl.ParallelFor

dsl.ParallelFor iterates a task over a list concurrently, producing fan-out execution rather than branching. It cannot test whether metrics exceed a threshold. dsl.Condition evaluates a boolean expression and runs the deploy component only when that predicate is true, matching the conditional deployment requirement.

Trap 2: dsl.ExitHandler

dsl.ExitHandler registers a cleanup task that runs after a pipeline or block finishes, regardless of success or failure. It does not branch on metric values. dsl.Condition supplies the if-then gating needed to deploy only when evaluation metrics exceed the threshold.

Trap 3: dsl.Collected

dsl.Collected is a type annotation for grouping a loop's output artefacts after a ParallelFor, not a branching construct. It cannot evaluate metrics or gate deployment. dsl.Condition wraps the deploy task with a boolean predicate comparing evaluation output against the threshold, which is the required behaviour.

A
dsl.ParallelFor
Why it fails: dsl.ParallelFor iterates a task over a list concurrently, producing fan-out execution rather than branching. It cannot test whether metrics exceed a threshold. dsl.Condition evaluates a boolean expression and runs the deploy component only when that predicate is true, matching the conditional deployment requirement.
B
dsl.ExitHandler
Why it fails: dsl.ExitHandler registers a cleanup task that runs after a pipeline or block finishes, regardless of success or failure. It does not branch on metric values. dsl.Condition supplies the if-then gating needed to deploy only when evaluation metrics exceed the threshold.
C
dsl.Condition
dsl.Condition wraps pipeline steps in a conditional branch whose predicate is evaluated at runtime, so the deployment step executes only when the evaluation metrics exceed the threshold. This directly implements the stem's conditional deployment requirement within the KFP pipeline definition.
D
dsl.Collected
Why it fails: dsl.Collected is a type annotation for grouping a loop's output artefacts after a ParallelFor, not a branching construct. It cannot evaluate metrics or gate deployment. dsl.Condition wraps the deploy task with a boolean predicate comparing evaluation output against the threshold, which is the required behaviour.

Question 4mediummultiple choice

A company needs to forecast product demand for the next 12 months using historical sales data. They want to use BigQuery ML with minimal coding. Which model type is most suitable?

Trap 1: K_MEANS

K_MEANS partitions rows into unsupervised clusters and outputs no future numeric value, so it cannot produce a 12-month demand figure. Clustering suits segmentation or anomaly grouping; forecasting requires a supervised model trained on a timestamp column and a target label.

Trap 2: MATRIX_FACTORIZATION

MATRIX_FACTORIZATION predicts interactions between users and items for recommendation, not ordered time-series values. It suits sparse rating matrices such as product suggestions; demand forecasting needs a model that consumes timestamped sales and outputs future numeric values, which this cannot do.

Trap 3: LINEAR_REG

LINEAR_REG fits a straight-line relationship between features and a target, so it cannot capture the seasonality and trend in monthly sales. It suits simple continuous prediction from independent features; BigQuery ML's ARIMA_PLUS is designed for time-series forecasting with a timestamp column.

A
K_MEANS
Why it fails: K_MEANS partitions rows into unsupervised clusters and outputs no future numeric value, so it cannot produce a 12-month demand figure. Clustering suits segmentation or anomaly grouping; forecasting requires a supervised model trained on a timestamp column and a target label.
B
MATRIX_FACTORIZATION
Why it fails: MATRIX_FACTORIZATION predicts interactions between users and items for recommendation, not ordered time-series values. It suits sparse rating matrices such as product suggestions; demand forecasting needs a model that consumes timestamped sales and outputs future numeric values, which this cannot do.
C
ARIMA_PLUS
ARIMA_PLUS handles time-series forecasting natively in BigQuery ML, requiring only a single CREATE MODEL statement on the historical sales column. It automatically detects seasonality, trends and holidays, satisfying the 12-month horizon and minimal-coding constraint without exporting data or writing Python.
D
LINEAR_REG
Why it fails: LINEAR_REG fits a straight-line relationship between features and a target, so it cannot capture the seasonality and trend in monthly sales. It suits simple continuous prediction from independent features; BigQuery ML's ARIMA_PLUS is designed for time-series forecasting with a timestamp column.

Question 5easymultiple choice

An organization wants to use Cloud Composer (Airflow) to orchestrate a machine learning workflow that includes running a Vertex AI Pipeline, followed by a BigQuery job, and then a Dataflow pipeline. What is the primary advantage of using Cloud Composer for this orchestration?

Trap 1: It automatically caches the outputs of each step to avoid…

Airflow does not automatically cache task outputs; caching is something you implement yourself via XComs or external storage. Composer's actual advantage is orchestrating the Vertex AI Pipeline, BigQuery job and Dataflow pipeline as one dependency-managed DAG across services.

Trap 2: It integrates natively with the Vertex AI Model Registry for model…

The Model Registry stores and versions models; it does not orchestrate a Vertex AI Pipeline, BigQuery job and Dataflow pipeline in sequence. Cloud Composer's advantage is cross-service DAG orchestration with dependencies, retries and scheduling, which is what this workflow needs.

Trap 3: It provides a serverless execution environment for ML pipelines.

Cloud Composer runs on GKE clusters you size and pay for, so it is not serverless; Vertex AI Pipelines provides the serverless ML pipeline execution. Composer's advantage here is orchestrating the Vertex AI Pipeline, BigQuery job and Dataflow pipeline together with dependencies and retries.

A
It allows orchestrating heterogeneous workflows across multiple GCP services with dependencies and retries.
Cloud Composer runs Apache Airflow DAGs, whose operators and sensors coordinate tasks across disparate GCP services with explicit dependencies and retry policies. This satisfies the stem's need to sequence a Vertex AI Pipeline, BigQuery job and Dataflow pipeline in one workflow.
B
It automatically caches the outputs of each step to avoid recomputation.
Why it fails: Airflow does not automatically cache task outputs; caching is something you implement yourself via XComs or external storage. Composer's actual advantage is orchestrating the Vertex AI Pipeline, BigQuery job and Dataflow pipeline as one dependency-managed DAG across services.
C
It integrates natively with the Vertex AI Model Registry for model versioning.
Why it fails: The Model Registry stores and versions models; it does not orchestrate a Vertex AI Pipeline, BigQuery job and Dataflow pipeline in sequence. Cloud Composer's advantage is cross-service DAG orchestration with dependencies, retries and scheduling, which is what this workflow needs.
D
It provides a serverless execution environment for ML pipelines.
Why it fails: Cloud Composer runs on GKE clusters you size and pay for, so it is not serverless; Vertex AI Pipelines provides the serverless ML pipeline execution. Composer's advantage here is orchestrating the Vertex AI Pipeline, BigQuery job and Dataflow pipeline together with dependencies and retries.

Question 6hardmulti select

A company wants to implement a CI/CD pipeline for their ML models using Vertex AI. They need to automatically retrain the model when new data arrives, but only if the model performance on a validation set has degraded by more than 5% compared to the current production model. Which three services or components should they incorporate into the automated pipeline? (Choose three.)

Trap 1: Dataflow pipeline to clean the new data before training

Dataflow cleans data, but the stem's trigger is validation-set degradation exceeding 5%, requiring a model-evaluation component comparing candidate against production. Dataflow is correct when preprocessing is the bottleneck, not when conditional retraining gates on measured performance regression.

Trap 2: Cloud Scheduler to run the pipeline on a fixed schedule

Cloud Scheduler fires jobs at fixed times, whereas the stem requires retraining triggered by new data arrival and gated on a 5% validation-performance drop. Scheduler suits periodic batch pipelines, not event-driven conditional retraining governed by model evaluation.

A
Dataflow pipeline to clean the new data before training
Why it fails: Dataflow cleans data, but the stem's trigger is validation-set degradation exceeding 5%, requiring a model-evaluation component comparing candidate against production. Dataflow is correct when preprocessing is the bottleneck, not when conditional retraining gates on measured performance regression.
B
Vertex AI Evaluation component to compute model performance metrics on the validation set
The Vertex AI Evaluation component computes metrics on the validation set, producing the performance figures needed to compare against the production model. This satisfies the stem's 5% degradation gate by supplying the quantitative basis for the retrain decision.
C
Cloud Functions to trigger the pipeline when new data arrives in Cloud Storage
Cloud Functions provides the event-driven trigger that satisfies the requirement to retrain automatically when new data arrives in Cloud Storage. Its native Cloud Storage object-finalise events initiate the pipeline without polling, ensuring retraining starts only on genuine data arrival, while the 5% degradation check is handled downstream by Vertex AI model evaluation.
D
Vertex AI Model Registry alias update to promote the model if performance passes the threshold
Updating a Vertex AI Model Registry alias points the production alias at the newly validated model, satisfying the stem's promotion step. This only happens once evaluation confirms performance passes the 5% degradation threshold, gating deployment on measured metrics.
E
Cloud Scheduler to run the pipeline on a fixed schedule
Why it fails: Cloud Scheduler fires jobs at fixed times, whereas the stem requires retraining triggered by new data arrival and gated on a 5% validation-performance drop. Scheduler suits periodic batch pipelines, not event-driven conditional retraining governed by model evaluation.

Question 7mediummultiple choice

A retail company wants to build a product recommendation system using BigQuery ML for their e-commerce platform. The data includes customer purchase history, product metadata, and clickstream logs. The ML engineer needs to minimize manual feature engineering and leverage pre-built solutions. Which approach should the engineer take?

Trap 1: Use a pre-built recommendation model from Vertex AI Model Garden…

Vertex AI Model Garden models run outside BigQuery, so purchase history and clickstream data must be exported and features engineered manually, defeating the minimise-feature-engineering requirement. Model Garden suits deploying pretrained models when data already resides in Vertex AI pipelines.

Trap 2: Write a custom TensorFlow model using the Vertex AI Training…

A custom TensorFlow model demands manual feature engineering and training code, contradicting the requirement to minimise that work. BigQuery ML's matrix factorisation handles this inside SQL. Vertex AI Training is chosen when bespoke architectures or frameworks are genuinely needed.

Trap 3: Export the data to CSV and use AutoML Tables to train a…

Exporting to CSV and using AutoML Tables breaks the BigQuery ML requirement and forces data movement plus schema preparation. AutoML Tables is chosen for tabular classification or regression on exported datasets, not in-database recommendation modelling.

A
Use a pre-built recommendation model from Vertex AI Model Garden and deploy it to an endpoint.
Why it fails: Vertex AI Model Garden models run outside BigQuery, so purchase history and clickstream data must be exported and features engineered manually, defeating the minimise-feature-engineering requirement. Model Garden suits deploying pretrained models when data already resides in Vertex AI pipelines.
B
Write a custom TensorFlow model using the Vertex AI Training service and deploy it via Vertex AI Prediction.
Why it fails: A custom TensorFlow model demands manual feature engineering and training code, contradicting the requirement to minimise that work. BigQuery ML's matrix factorisation handles this inside SQL. Vertex AI Training is chosen when bespoke architectures or frameworks are genuinely needed.
C
Export the data to CSV and use AutoML Tables to train a recommendation model.
Why it fails: Exporting to CSV and using AutoML Tables breaks the BigQuery ML requirement and forces data movement plus schema preparation. AutoML Tables is chosen for tabular classification or regression on exported datasets, not in-database recommendation modelling.
D
Use BigQuery ML's matrix factorization model (CREATE MODEL with model_type='matrix_factorization') to train directly on historical interaction data.
BigQuery ML's matrix_factorization model learns latent user and item embeddings directly from historical interaction data, so purchase history and clickstream logs feed training without hand-crafted features. This satisfies the stem's constraint of minimising manual feature engineering while using a pre-built solution, unlike approaches requiring custom pipelines or external frameworks.

Question 8hardmulti select

A retail company wants to implement a recommendation system using Recommendations AI. They need to generate personalized recommendations for users based on their browsing history and purchase behavior. Which THREE recommendation types are available in Recommendations AI?

Trap 1: trending-now

Recommendations AI offers recommended-for-you, others-you-may-like, frequently-bought-together, and similar-item types; trending-now is a Retail Search or Vertex AI Search feature, not a Recommendations AI type. It is tempting because trending content suits retail merchandising, but it does not personalise from a user's browsing and purchase history.

Trap 2: most-popular

Most-popular returns the same items to every user, ignoring the browsing history and purchase behaviour the scenario requires for personalisation. It is genuinely a Recommendations AI type, useful as a fallback when a user or item has insufficient interaction data for personalised models.

A
trending-now
Why it fails: Recommendations AI offers recommended-for-you, others-you-may-like, frequently-bought-together, and similar-item types; trending-now is a Retail Search or Vertex AI Search feature, not a Recommendations AI type. It is tempting because trending content suits retail merchandising, but it does not personalise from a user's browsing and purchase history.
B
recommended-for-you
Recommended-for-you is a genuine Recommendations AI type that personalises suggestions per user from their browsing history and past behaviour. This directly matches the stem's requirement to generate personalised recommendations based on browsing and purchase activity.
C
others-you-may-like
Others-you-may-like is a genuine Recommendations AI type, generating related-item suggestions from co-occurrence patterns in browsing and purchase data. It satisfies the stem's requirement for personalised recommendations derived from user behaviour, alongside the other two valid types.
D
frequently-bought-together
Frequently-bought-together is a valid Recommendations AI type, generating item associations from co-purchase patterns across all users rather than per-user history. It satisfies the stem's requirement to name available recommendation types, alongside "recommended-for-you" and "others-you-may-like", which cover the personalised browsing and purchase behaviour signals described.
E
most-popular
Why it fails: Most-popular returns the same items to every user, ignoring the browsing history and purchase behaviour the scenario requires for personalisation. It is genuinely a Recommendations AI type, useful as a fallback when a user or item has insufficient interaction data for personalised models.

Question 9mediummulti select

Your organization wants to automate the retraining of a model when new data is available and also on a weekly schedule. Which TWO services would you use together to achieve this? (Choose two.)

Trap 1: Cloud Composer

Cloud Composer orchestrates pipelines but is not the event-driven trigger for new data arriving in Cloud Storage; that is Eventarc. Composer would be the right choice for authoring and scheduling complex multi-step DAG workflows, not for reacting to individual object-creation events.

Trap 2: Cloud Tasks

Cloud Tasks queues asynchronous HTTP callbacks to a worker; it has no scheduler for recurring weekly runs and no event trigger on new data. It would suit decoupling or rate-limiting task execution, not orchestrating retraining pipelines.

Trap 3: Dataflow

Dataflow is a managed Apache Beam runner for stream and batch data processing, not a scheduler or event trigger. It would be correct for transforming or enriching the training data itself, but it neither fires on new data nor runs the weekly retraining job.

A
Cloud Functions
Cloud Functions provides the event-driven compute: a trigger fires when new data lands, invoking code that submits the retraining pipeline. This satisfies the stem's requirement to automate retraining on data arrival, complementing a scheduler for the weekly cadence.
B
Cloud Composer
Why it fails: Cloud Composer orchestrates pipelines but is not the event-driven trigger for new data arriving in Cloud Storage; that is Eventarc. Composer would be the right choice for authoring and scheduling complex multi-step DAG workflows, not for reacting to individual object-creation events.
C
Cloud Tasks
Why it fails: Cloud Tasks queues asynchronous HTTP callbacks to a worker; it has no scheduler for recurring weekly runs and no event trigger on new data. It would suit decoupling or rate-limiting task execution, not orchestrating retraining pipelines.
D
Dataflow
Why it fails: Dataflow is a managed Apache Beam runner for stream and batch data processing, not a scheduler or event trigger. It would be correct for transforming or enriching the training data itself, but it neither fires on new data nor runs the weekly retraining job.
E
Cloud Scheduler
Cloud Scheduler supplies the time-based trigger, firing weekly against a defined cron schedule, which satisfies the recurring cadence the stem demands. It handles only scheduling, so it must be paired with a pipeline service that reacts to new data; the retraining logic itself is not provided here.

Question 10mediummultiple choice

You have deployed a regression model that predicts house prices. Over the past month, the model's predictions have been consistently too high. You suspect data drift in the input features. Which monitoring metric should you prioritize to confirm this?

Trap 1: Monitor prediction drift (prediction distribution)

Prediction drift tracks the model's output distribution, but the stem already establishes that outputs are skewed high; it cannot confirm whether inputs shifted. It is tempting because prediction drift suits unlabelled production data where ground truth is unavailable, yet here you need feature-level distribution comparison against the training baseline.

Trap 2: Monitor feature attribution drift using SHAP values

SHAP attribution drift measures how much each feature contributes to predictions, not whether the input feature distributions themselves shifted. It tempts because attribution changes often accompany drift, but to confirm input data drift you compare live feature distributions against training baselines, not explanation values.

Trap 3: Monitor residual distribution drift

Residual drift reflects prediction error against delayed ground truth, not the input feature distributions the stem suspects. It is tempting because residuals directly capture the consistently high predictions, and residual monitoring would be the right choice once labels arrive to confirm degraded accuracy rather than input drift.

A
Monitor prediction drift (prediction distribution)
Why it fails: Prediction drift tracks the model's output distribution, but the stem already establishes that outputs are skewed high; it cannot confirm whether inputs shifted. It is tempting because prediction drift suits unlabelled production data where ground truth is unavailable, yet here you need feature-level distribution comparison against the training baseline.
B
Monitor feature distribution drift using a divergence metric like Jensen-Shannon divergence
Jensen-Shannon divergence quantifies how far each input feature's live distribution has drifted from its training baseline, directly confirming whether covariate shift explains the biased predictions. Aggregate prediction metrics alone cannot isolate which features moved, so distribution-level comparison is the appropriate diagnostic.
C
Monitor feature attribution drift using SHAP values
Why it fails: SHAP attribution drift measures how much each feature contributes to predictions, not whether the input feature distributions themselves shifted. It tempts because attribution changes often accompany drift, but to confirm input data drift you compare live feature distributions against training baselines, not explanation values.
D
Monitor residual distribution drift
Why it fails: Residual drift reflects prediction error against delayed ground truth, not the input feature distributions the stem suspects. It is tempting because residuals directly capture the consistently high predictions, and residual monitoring would be the right choice once labels arrive to confirm degraded accuracy rather than input drift.

Question 11easymultiple choice

A healthcare analytics team needs to serve a model on Vertex AI to internal applications, but compliance requires that no prediction request or response payload ever be written to logs. They still want basic operational metrics such as request count and latency. What should they configure on the endpoint?

Trap 1: Delete the endpoint's service account permissions on Cloud Logging…

Revoking logging permissions breaks operational logging broadly and does not selectively suppress payload capture. It can also cause deployment or health-check failures, and Cloud Monitoring metrics are delivered through a separate pipeline, so this approach harms observability without cleanly meeting the requirement.

Trap 2: Set the endpoint's traffic split to route all requests to a canary…

Traffic splitting governs which model version serves requests; it does not disable logging on the version that receives traffic. If the canary has logging off but the primary still logs, any request routed to the primary is captured, so the compliance guarantee is not met and the split adds needless complexity.

Trap 3: Enable request-response logging but set the sampling rate to a very…

Any nonzero sampling still writes some prediction payloads to Cloud Logging, which violates the requirement that no request or response content ever be logged. Compliance controls must be deterministic, not probabilistic, so a low sampling rate is unacceptable even if it reduces the volume of captured data.

A
Delete the endpoint's service account permissions on Cloud Logging so the platform cannot write any log entries, including metrics.
Why it fails: Revoking logging permissions breaks operational logging broadly and does not selectively suppress payload capture. It can also cause deployment or health-check failures, and Cloud Monitoring metrics are delivered through a separate pipeline, so this approach harms observability without cleanly meeting the requirement.
B
Disable request-response logging on the deployed model while leaving endpoint monitoring and Cloud Monitoring metrics enabled.
Request-response logging is a separate, opt-in setting on the deployed model. Leaving it disabled means payloads are never captured, while the endpoint still emits standard metrics like request count, error rate, and latency percentiles to Cloud Monitoring, satisfying both the compliance constraint and the observability requirement.
C
Set the endpoint's traffic split to route all requests to a canary deployment that has logging disabled, while the primary deployment keeps logging enabled.
Why it fails: Traffic splitting governs which model version serves requests; it does not disable logging on the version that receives traffic. If the canary has logging off but the primary still logs, any request routed to the primary is captured, so the compliance guarantee is not met and the split adds needless complexity.
D
Enable request-response logging but set the sampling rate to a very small value so almost no payloads are captured.
Why it fails: Any nonzero sampling still writes some prediction payloads to Cloud Logging, which violates the requirement that no request or response content ever be logged. Compliance controls must be deterministic, not probabilistic, so a low sampling rate is unacceptable even if it reduces the volume of captured data.

Question 12hardmulti select

A team wants to implement CI/CD for their ML pipeline using Cloud Build. They want to automatically compile and deploy the pipeline when code is pushed to the main branch. Which three steps should they include in the Cloud Build configuration? (Choose three.)

Trap 1: Run the pipeline immediately after deployment

Running the pipeline immediately after deployment executes the ML workflow as a build step, not a CI/CD action; Cloud Build should compile, deploy, and register the pipeline instead. It is tempting because pipeline execution validates the artefact, but that belongs to scheduled or triggered runs after release.

Trap 2: Configure Cloud Scheduler to trigger on push

Cloud Scheduler triggers time-based or Pub/Sub jobs, not source-code push events; Cloud Build triggers subscribe to repository changes directly. It is tempting because Scheduler automates invocation, but it would only be correct for cron-style retraining, not main-branch commit-driven builds.

A
Create or update the pipeline in Vertex AI using the compiled file
Creating or updating the pipeline in Vertex AI registers the compiled pipeline definition, making it runnable and schedulable. This satisfies the deployment half of the CI/CD requirement, since compilation alone leaves the pipeline unregistered and unable to execute on Vertex AI.
B
Upload the compiled pipeline to Cloud Storage
Uploading the compiled pipeline to Cloud Storage gives Vertex AI a durable GCS URI to reference when creating or updating the pipeline. This satisfies the stem's deployment requirement, since Vertex AI pipeline jobs read their compiled specification from Cloud Storage rather than local build artefacts.
C
Run the pipeline immediately after deployment
Why it fails: Running the pipeline immediately after deployment executes the ML workflow as a build step, not a CI/CD action; Cloud Build should compile, deploy, and register the pipeline instead. It is tempting because pipeline execution validates the artefact, but that belongs to scheduled or triggered runs after release.
D
Install KFP SDK and compile the pipeline
Installing the KFP SDK and compiling the pipeline converts the Python pipeline definition into a compiled YAML specification. This satisfies the stem's build stage, producing the artefact that subsequent Cloud Build steps upload to Cloud Storage and register with Vertex AI.
E
Configure Cloud Scheduler to trigger on push
Why it fails: Cloud Scheduler triggers time-based or Pub/Sub jobs, not source-code push events; Cloud Build triggers subscribe to repository changes directly. It is tempting because Scheduler automates invocation, but it would only be correct for cron-style retraining, not main-branch commit-driven builds.

Question 13easymultiple choice

You have a TensorFlow training script that runs on a single machine. To speed up training on Vertex AI with 8 GPUs on a single machine, which strategy should you use?

Trap 1: tf.distribute.ParameterServerStrategy

ParameterServerStrategy places variables on parameter servers and workers compute updates, a topology designed for asynchronous, multi-machine clusters. On one machine with eight GPUs it introduces unnecessary server-worker separation. It is tempting as a scaling pattern, but it suits large distributed clusters, not a single host's local devices.

Trap 2: tf.distribute.TPUStrategy

TPUStrategy targets Tensor Processing Unit pods and their specific collective communication topology; it cannot drive NVIDIA GPUs on a Vertex AI single machine. It is tempting because TPUs also accelerate training, but that requires TPU VMs. For eight local GPUs, MirroredStrategy replicates variables across the devices on that host.

Trap 3: tf.distribute.MultiWorkerMirroredStrategy

MultiWorkerMirroredStrategy coordinates gradients across multiple machines, each with its own workers, so it adds cross-host communication overhead without benefit on one host. It is tempting because it mirrors variables across workers, but that is for multi-node clusters; single-machine eight-GPU training needs MirroredStrategy, which mirrors across local devices only.

A
tf.distribute.ParameterServerStrategy
Why it fails: ParameterServerStrategy places variables on parameter servers and workers compute updates, a topology designed for asynchronous, multi-machine clusters. On one machine with eight GPUs it introduces unnecessary server-worker separation. It is tempting as a scaling pattern, but it suits large distributed clusters, not a single host's local devices.
B
tf.distribute.MirroredStrategy
MirroredStrategy performs synchronous, all-reduce data-parallel training across multiple GPUs within one machine, replicating the model on each device and aggregating gradients. This directly satisfies the stem's constraint of 8 GPUs on a single machine, where MultiWorkerMirroredStrategy would add unnecessary cross-machine networking overhead.
C
tf.distribute.TPUStrategy
Why it fails: TPUStrategy targets Tensor Processing Unit pods and their specific collective communication topology; it cannot drive NVIDIA GPUs on a Vertex AI single machine. It is tempting because TPUs also accelerate training, but that requires TPU VMs. For eight local GPUs, MirroredStrategy replicates variables across the devices on that host.
D
tf.distribute.MultiWorkerMirroredStrategy
Why it fails: MultiWorkerMirroredStrategy coordinates gradients across multiple machines, each with its own workers, so it adds cross-host communication overhead without benefit on one host. It is tempting because it mirrors variables across workers, but that is for multi-node clusters; single-machine eight-GPU training needs MirroredStrategy, which mirrors across local devices only.

Question 14mediummulti select

A company uses Vertex AI Matching Engine for real-time recommendations. They need to serve queries with low latency and support frequent updates. Which two configurations are appropriate? (Choose 2)

Trap 1: Store the index in Cloud Storage and query via Python

Cloud Storage holds objects for batch ingestion, not low-latency vector search; querying it via Python adds retrieval latency and cannot serve online recommendations. It is tempting because it is cheap and familiar for storing embeddings; it would be correct as the source location for building or rebuilding an index.

Trap 2: Use a brute-force index for exact results

Brute-force search compares the query against every vector, so latency scales with index size and cannot meet the low-latency serving requirement. It is tempting because it returns exact nearest neighbours; it would be correct for small datasets or accuracy benchmarking, not large-scale real-time recommendation.

Trap 3: Use batch updates only

Batch updates leave the index stale between rebuilds, so newly added items are not served, failing the frequent-update requirement. It is tempting because batch rebuilds are operationally simple; they would be correct where the catalogue changes rarely and near-real-time freshness is unnecessary.

A
Store the index in Cloud Storage and query via Python
Why it fails: Cloud Storage holds objects for batch ingestion, not low-latency vector search; querying it via Python adds retrieval latency and cannot serve online recommendations. It is tempting because it is cheap and familiar for storing embeddings; it would be correct as the source location for building or rebuilding an index.
B
Enable streaming updates for the index
Streaming updates allow new embeddings to be inserted or removed incrementally while the index remains queryable, avoiding the full rebuild and redeploy that batch updates force. This satisfies the frequent-update requirement without interrupting the low-latency online serving the stem specifies.
C
Use a brute-force index for exact results
Why it fails: Brute-force search compares the query against every vector, so latency scales with index size and cannot meet the low-latency serving requirement. It is tempting because it returns exact nearest neighbours; it would be correct for small datasets or accuracy benchmarking, not large-scale real-time recommendation.
D
Deploy the index to a Vertex AI Matching Engine endpoint
Deploying the index to a Matching Engine endpoint exposes it for online queries over the network, returning approximate nearest-neighbour results in milliseconds. This satisfies the low-latency serving requirement, since an undeployed index cannot answer real-time recommendation requests.
E
Use batch updates only
Why it fails: Batch updates leave the index stale between rebuilds, so newly added items are not served, failing the frequent-update requirement. It is tempting because batch rebuilds are operationally simple; they would be correct where the catalogue changes rarely and near-real-time freshness is unnecessary.

Question 15mediummulti select

A machine learning team uses Vertex AI Pipelines for model training. They want to implement a conditional step that runs additional evaluation if the model accuracy exceeds 0.9, otherwise it runs a data augmentation component. Which two Kubeflow Pipelines SDK v2 constructs can they use to achieve this? (Choose two.)

Trap 1: dsl.ParallelFor

dsl.ParallelFor iterates over a list, launching concurrent branches for each item; it cannot branch on a boolean accuracy threshold. It is tempting because it handles fan-out workloads such as hyperparameter tuning or per-dataset training, where the same component runs repeatedly across a collection rather than following one conditional path.

Trap 2: dsl.ExitHandler

dsl.ExitHandler runs a cleanup component when the pipeline exits, whether successfully or after failure; it cannot branch on accuracy. It is tempting because it does conditionally execute a component, but that trigger is pipeline termination, not a data-dependent boolean. Conditional branching on a threshold requires dsl.Condition instead.

Trap 3: dsl.Collected

dsl.Collected groups outputs from a loop, not conditional execution. Branching requires dsl.Condition with an if-expression, so Collected cannot select between the evaluation and augmentation components. It is tempting because it appears in pipeline-authoring examples alongside control-flow constructs.

A
dsl.ParallelFor
Why it fails: dsl.ParallelFor iterates over a list, launching concurrent branches for each item; it cannot branch on a boolean accuracy threshold. It is tempting because it handles fan-out workloads such as hyperparameter tuning or per-dataset training, where the same component runs repeatedly across a collection rather than following one conditional path.
B
dsl.Else
dsl.Else provides the alternative branch executed when the dsl.If condition evaluates false, so the data augmentation component runs whenever accuracy does not exceed 0.9. It is the required companion construct to dsl.If for building if/else conditionals in Kubeflow Pipelines SDK v2.
C
dsl.ExitHandler
Why it fails: dsl.ExitHandler runs a cleanup component when the pipeline exits, whether successfully or after failure; it cannot branch on accuracy. It is tempting because it does conditionally execute a component, but that trigger is pipeline termination, not a data-dependent boolean. Conditional branching on a threshold requires dsl.Condition instead.
D
dsl.Collected
Why it fails: dsl.Collected groups outputs from a loop, not conditional execution. Branching requires dsl.Condition with an if-expression, so Collected cannot select between the evaluation and augmentation components. It is tempting because it appears in pipeline-authoring examples alongside control-flow constructs.
E
dsl.If
dsl.If evaluates a boolean condition at runtime and executes its enclosed tasks only when that condition holds, so the additional evaluation step runs when accuracy exceeds 0.9. It is the primary conditional construct in Kubeflow Pipelines SDK v2, paired with dsl.Else.