PMLE Practice Test 44 — 15 Questions

Question 1

A team is building a batch prediction pipeline that processes raw data from Cloud Storage, performs complex preprocessing, and then runs predictions using a large model. The preprocessing step is compute-intensive and the prediction step is I/O-bound. Which TWO Google Cloud services should they combine to optimize cost and performance? (Choose 2)

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Dataflow for preprocessing and writing results to Cloud Storage. Option A (Dataflow for preprocessing and writing results to Cloud Storage) is correct because Dataflow is a fully managed, autoscaling service built on Apache Beam that handles compute-intensive, parallel batch preprocessing over data in Cloud Storage, and it can write the transformed output back to Cloud Storage for the next stage. Option D (Vertex AI Batch Prediction with Cloud Storage source) is correct because it is the managed, I/O-bound batch inference service designed to read preprocessed files directly from Cloud Storage and run predictions on a large model without provisioning persistent serving infrastructure, which optimizes cost for batch workloads. Option B is wrong because Cloud Functions is event-driven and limited in execution time and memory, making it unsuitable for compute-intensive row-by-row preprocessing of large batch datasets. Option C is wrong because Cloud Run serving preprocessed data as an API adds unnecessary request/response overhead and is designed for online serving, not batch pipeline handoff. Option E is wrong because the pipeline explicitly reads raw data from Cloud Storage and writes preprocessed results there, so a BigQuery source for batch prediction does not match the described data flow.

Answer

Cloud Functions to preprocess data row by row

Answer

Cloud Run to serve the preprocessed data as an API

Answer

Vertex AI Batch Prediction with BigQuery source

Question 2

Your company uses a custom container for model serving on Vertex AI. After a recent update, the model returns predictions but they are clearly wrong (e.g., negative probabilities for a classification model). The logs show no errors. What is the most likely cause?

Accepted Answer

The preprocessing code in the container was updated but the model was not retrained on the new preprocessing. The most likely cause of a model returning predictions without errors, but with clearly wrong outputs like negative probabilities, is a mismatch between the preprocessing logic used during training and inference. If the preprocessing code in the container was updated (e.g., scaling, normalization, or feature engineering steps changed) but the model was not retrained on data processed with that new logic, the model receives inputs that are out of distribution, leading to nonsensical outputs. Vertex AI containers run inference with the deployed code, so any change in preprocessing directly affects the input tensor values without raising runtime errors.

Answer

The model file is corrupted

Answer

The model file was accidentally replaced with a different model

Answer

The container is using an incompatible version of the serving framework

Question 3

You are monitoring a machine learning pipeline that runs on Vertex AI Pipelines. The pipeline occasionally fails with a 'ResourceExhausted' error when attempting to read data from BigQuery. Which action should you take to resolve this issue?

Accepted Answer

Reduce the complexity of the BigQuery query or increase the reservation size. The 'ResourceExhausted' error when reading from BigQuery indicates that the query is consuming more resources than the BigQuery reservation allows. Option C is correct because reducing query complexity (e.g., using fewer JOINs, aggregations, or partitions) or increasing the reservation size directly addresses the root cause by either lowering resource demand or allocating more capacity. Other options like switching to Cloud Storage or adjusting pipeline memory do not fix the BigQuery-specific quota or slot exhaustion.

Answer

Switch from BigQuery to Cloud Storage for data source

Answer

Increase the memory allocated to the pipeline step

Answer

Reduce the batch size of the data being read

Question 4

A company deploys a custom ML model on Vertex AI to predict customer churn. The model retrains weekly, and predictions are served via a Vertex AI endpoint. After a recent retraining, the monitoring dashboard shows a sudden increase in prediction requests but a decrease in predicted churn probabilities. The model's accuracy on the validation set remains stable. What is the most likely cause of the observed behavior?

Accepted Answer

The incoming data distribution has changed, e.g., due to a new marketing campaign attracting different customers.. A sudden increase in prediction requests alongside a decrease in predicted churn probabilities, while validation accuracy remains stable, indicates a shift in the incoming data distribution (covariate shift). This is typical when a new marketing campaign attracts a different customer segment that inherently has lower churn risk. The model itself hasn't degraded; it's simply seeing a different population than it was trained on, which changes the base rate of churn in the live traffic.

Answer

A training-serving skew exists between the training pipeline and the serving endpoint.

Answer

Concept drift has occurred, changing the relationship between features and churn.

Answer

Data leakage during training caused the model to overfit to historical patterns.

Question 5

A company wants to monitor features in Vertex AI Feature Store for drift over time. Which two services should they use? (Choose two.)

Accepted Answer

Vertex AI Feature Store monitoring. Option A, Vertex AI Feature Store monitoring, is correct because it is the native capability that computes feature-level drift and skew statistics for features served from a Vertex AI Feature Store, generating metrics and alerts when distributions shift over time. Option E, Cloud Monitoring, is correct because the drift metrics produced by Feature Store monitoring are exported to Cloud Monitoring, where they can be visualized on dashboards and used to create alerting policies. Option B, Cloud Logging, is not the right choice because it captures log entries rather than computing or charting feature drift metrics. Option C, Vertex AI Model Monitoring, targets model prediction drift/skew on deployed endpoints, not feature drift within a Feature Store. Option D, Vertex AI Experiments, is for tracking training runs, parameters, and metrics, not for ongoing drift monitoring of stored features.

Answer

Cloud Logging

Answer

Vertex AI Model Monitoring

Answer

Vertex AI Experiments

Question 6

A data science team is configuring Vertex AI Model Monitoring for a deployed model. They want to detect both feature skew and feature drift. Which TWO configurations must they set?

Accepted Answer

Configure the monitoring frequency (e.g., hourly).. Option C is correct because Vertex AI Model Monitoring requires a monitoring schedule/frequency (for example hourly or daily) so the job knows how often to evaluate incoming prediction data against the baseline; without a configured frequency, no monitoring analysis runs. Option E is correct because detecting feature skew and drift requires a baseline: for skew you supply the training dataset (or its generated statistics), and for drift you compare recent production data against the baseline statistics, so specifying a training dataset or statistics is mandatory. Option A is not required because request/response logging is a separate feature for capturing payloads and is not the configuration that enables skew/drift detection. Option B is not required because Jensen-Shannon divergence is only one selectable distance metric for drift/skew detection, not a mandatory setting. Option D is not required because a 1.0 sampling rate (100%) is optional; monitoring can run on a lower sample of requests.

Answer

Enable request/response logging.

Answer

Select the Jensen-Shannon divergence algorithm.

Answer

Set the sampling rate to 1.0 (100%).

Question 7

Which TWO are best practices for deploying models to Vertex AI Prediction? (Choose 2.)

Accepted Answer

Monitor prediction latency and error rates with Cloud Monitoring alerts.. Option A is correct because Vertex AI Prediction exposes built-in metrics such as prediction latency, request count, and error rates to Cloud Monitoring, and configuring alerting policies on these metrics is a recommended operational best practice to detect model degradation or endpoint failures early. Option C is correct because the endpoint and model deployment should run under a dedicated service account scoped with least-privilege IAM roles (e.g., only the permissions needed to read model artifacts from Cloud Storage and write logs), which limits blast radius if the endpoint is compromised. Option B is not a best practice because logging every raw prediction input and output can expose sensitive data (PII), incur high logging costs, and is not required for auditing; sampling or redaction is preferred. Option D is incorrect because training and serving environments are typically decoupled, and Vertex AI supports deploying models across environments as long as the serving container and dependencies are compatible; forcing identical environments is not a deployment best practice. Option E is incorrect because relying solely on the 'default' alias for all deployments removes version control and makes rollback or A/B testing harder; explicit, immutable model versions or dedicated aliases should be used.

Answer

Log all raw prediction inputs and outputs for every request for auditing.

Answer

Always deploy the model in the same environment as training to avoid incompatibility.

Answer

Use the default model version alias 'default' for all deployments to simplify updates.

Question 8

A data science team uses Vertex AI Experiments to compare multiple model training runs. They want to capture and compare hyperparameters, metrics, and code versions for each run. Which TWO steps should they take?

Accepted Answer

Log hyperparameters and metrics using the Vertex AI SDK's experiment logging functions. Option C is correct because the Vertex AI SDK provides dedicated experiment logging functions (e.g., aiplatform.log_params() and aiplatform.log_metrics()) that record hyperparameters and metrics directly into a Vertex AI Experiment run, which is exactly what the team needs to capture and compare across runs. Option E is correct because integrating training code with Git and passing the commit hash as a run parameter ties each experiment run to a specific, reproducible code version, satisfying the requirement to capture code versions alongside hyperparameters and metrics. Option A is not appropriate because Cloud Logging captures log output, not structured experiment parameters or metrics for comparison in Vertex AI Experiments. Option B is unnecessary and less precise than using Git commit hashes, since manually linking Cloud Storage artifacts does not automatically associate code versions with runs. Option D is not required because Vertex AI Experiments already provides comparison capabilities natively, so exporting to BigQuery is an extra step not needed for the stated goal.

Answer

Use Cloud Logging to capture all training outputs

Answer

Store code versions in Cloud Storage and link them to experiments manually

Answer

Export experiment data to BigQuery for comparison

Question 9

An ML engineer is troubleshooting why a Vertex AI Endpoint is returning high prediction latency. They have enabled request/response logging and see that some requests take >1 second while most are fast. Which THREE actions should they take to diagnose the issue?

Accepted Answer

Check CPU and GPU utilisation metrics on the endpoint.. Option A is correct because high prediction latency on a Vertex AI Endpoint is frequently caused by resource saturation, so inspecting CPU and GPU utilisation metrics in Cloud Monitoring reveals whether the underlying nodes are maxed out and throttling inference. Option B is correct because request/response logging for Vertex AI Endpoints can be routed to BigQuery, where the engineer can correlate payload size with latency and confirm whether large inputs (e.g., big images or long text) are the outliers exceeding 1 second. Option D is correct because p99 latency in Cloud Monitoring exposes the tail behaviour of the distribution, showing whether the slow requests are a persistent tail problem or isolated spikes, which is exactly the symptom described. Option C is not appropriate because Model Monitoring runs asynchronously on sampled data and does not add per-request prediction latency, so disabling it would not diagnose the issue. Option E is not appropriate because blindly scaling replicas is a remediation step, not a diagnostic one, and it would not identify the root cause of the >1 second requests.

Answer

Disable Vertex AI Model Monitoring to reduce overhead.

Answer

Increase the number of replicas to resolve the issue immediately.

Question 10

A company wants to use DVC for data versioning alongside their ML code in Git. Which TWO statements about DVC are correct? (Select 2)

Accepted Answer

DVC uses a separate .dvc file to track data versions.. Option A is correct because DVC creates small .dvc metafiles (e.g., data.dvc) that record the MD5 hash and path of the tracked data, allowing Git to version the pointer while the actual data lives in the DVC cache. Option B is correct because DVC supports many remote storage backends, including Google Cloud Storage, via `dvc remote add` and `dvc push`, so data can be stored outside the Git repository. Option C is wrong because DVC deliberately keeps large data files out of Git, storing them in its cache and remotes instead. Option D is wrong because DVC supports S3, GCS, Azure Blob Storage, SSH, HDFS, and local remotes, not only S3. Option E is wrong because DVC complements Git for data versioning; it does not replace Git for source code version control.

Answer

DVC stores the actual data files in Git.

Answer

DVC only works with AWS S3 as remote storage.

Answer

DVC replaces Git for code versioning.

Question 11

A team uses Vertex AI Pipelines for continuous training triggered by model drift. They want to monitor the pipeline execution cost and optimize resource usage. Which THREE metrics should they track? (Choose 3)

Accepted Answer

Pipeline execution duration. Option A (Pipeline execution duration) is correct because the wall-clock time a Vertex AI Pipeline run takes directly drives the compute resources billed by the underlying services (Vertex AI Training, Dataflow, etc.), so tracking duration is essential for spotting inefficiencies and optimizing resource usage. Option D (Total GPU hours consumed per pipeline run) is correct because GPUs are the most expensive accelerator resource in Vertex AI; measuring GPU hours per run quantifies accelerator consumption and reveals over-provisioning or idle GPU time that can be right-sized. Option E (Cost per pipeline run in Cloud Billing) is correct because Cloud Billing cost data (exported to BigQuery and labeled per pipeline run) gives the actual monetary cost, which is the ground truth for monitoring execution cost and validating optimization efforts. Option B (Number of failed pipeline runs) is not a cost or resource-usage metric; it measures reliability, so it does not directly address cost monitoring or resource optimization. Option C (Model accuracy on validation set) is a model-quality metric, not an execution-cost or resource-utilization metric, so it is out of scope for this question.

Answer

Number of failed pipeline runs

Answer

Model accuracy on validation set

Question 12

A pipeline uses the Google Cloud Pipeline Components to perform AutoML training and batch prediction. Which two components from the GCPC library should they use? (Choose two.)

Accepted Answer

AutoMLTabularTrainingJobRunOp. Option C, AutoMLTabularTrainingJobRunOp, is correct because it is the Google Cloud Pipeline Components (GCPC) operator that wraps the Vertex AI AutoML tabular training job, allowing the pipeline to launch an AutoMLTabularTrainingJob and produce a model artifact. Option D, BatchPredictOp, is correct because it is the GCPC component that submits a Vertex AI batch prediction job against a trained model and a specified input data source, which is exactly the batch prediction step described in the scenario. Option A, CustomJobRunOp, is not appropriate here because it runs a custom training container rather than an AutoML training job. Option B, DataflowPythonOp, is a Dataflow-based Python execution component and does not perform AutoML training or batch prediction. Option E, EndpointPredictOp, performs online prediction against a deployed Vertex AI endpoint, not batch prediction, so it does not fit the scenario.

Answer

CustomJobRunOp

Answer

DataflowPythonOp

Answer

EndpointPredictOp

Question 13

A company is experiencing high prediction costs on Vertex AI Endpoints. They want to monitor and optimize costs. Which THREE actions should they take? (Choose 3)

Accepted Answer

Use Cloud Billing reports to track Vertex AI endpoint costs per hour and per request. Option A is correct because Cloud Billing reports let you break down Vertex AI endpoint charges by labels, SKU, and time granularity, giving visibility into per-hour and per-request prediction costs so optimization decisions are data-driven. Option C is correct because prediction cost on Vertex AI Endpoints is driven largely by the number of deployed replicas and machine hours; reducing replicas or configuring autoscaling (e.g., minReplicaCount/maxReplicaCount with a target utilization metric) eliminates idle capacity and directly lowers spend. Option D is correct because budget alerts in Cloud Billing proactively notify stakeholders when actual or forecasted costs exceed a defined threshold, enabling timely corrective action before prediction costs escalate. Option B does not belong because Vertex AI Explainability adds feature attribution to predictions, which increases compute and cost rather than optimizing it. Option E does not belong because Model Monitoring tracks data drift, skew, and prediction quality metrics, not cost, and it does not reduce prediction expenses.

Answer

Use Vertex AI Explainability on every prediction

Answer

Enable Vertex AI Model Monitoring to track prediction latency

Question 14

Which TWO metrics should you monitor to detect data drift in a batch prediction pipeline?

Accepted Answer

Feature distribution drift (e.g., KS test). Feature distribution drift (C) is correct because data drift is detected by statistically comparing the distribution of each input feature in recent batches against the training/reference distribution, typically using tests like the Kolmogorov-Smirnov (KS) test or Population Stability Index (PSI). Prediction distribution drift (D) is correct because shifts in the distribution of model outputs (e.g., changing class proportions or score histograms) are a direct, label-free signal that the input data relationship has changed in a batch pipeline. Model accuracy on recent labeled data (A) measures performance degradation, not drift itself, and labels are usually unavailable or delayed in batch prediction. Model prediction latency (B) is an operational performance metric unrelated to distributional change, and training data size (E) is a static dataset property, not a monitoring signal for drift.

Answer

Model accuracy on recent labeled data

Answer

Model prediction latency

Answer

Training data size

Question 15

Which TWO actions are best practices when scaling a prototype ML model to production in Google Cloud?

Accepted Answer

Store and manage features in a feature store like Vertex AI Feature Store.. Option A is correct because storing and managing features in Vertex AI Feature Store provides a centralized, consistent source of feature values for both training and serving, which prevents training/serving skew and enables feature reuse and low-latency online serving at production scale. Option C is correct because production ML requires continuous monitoring and logging of model performance metrics and data drift (for example via Vertex AI Model Monitoring), so degradation, skew, and drift can be detected and the model retrained or rolled back. Option B is not a best practice because validating only on a small sample of production data risks missing edge cases and distribution shifts; production readiness requires representative validation and testing. Option D is not a best practice because manual scaling is error-prone and slow; production inference should use autoscaling based on real-time metrics such as CPU/GPU utilization or request load. Option E is not a best practice because applying one-hot encoding to all categorical features regardless of cardinality can create extremely high-dimensional sparse vectors, causing memory and training problems; high-cardinality features should use embeddings or hashing instead.

Answer

Test the model only on a small sample of the production data to save costs.

Answer

Manually scale inference instances based on historical traffic patterns.

Answer

Use one-hot encoding for all categorical features without considering cardinality.