PDE Practice Test 18 — 15 Questions

Question 1

Your team wants to continuously monitor a deployed model's performance in production. They need to detect when the model's predictions become unreliable due to changes in the real world (e.g., new customer behavior). Which Vertex AI service should they use?

Accepted Answer

Vertex AI Model Monitoring. Vertex AI Model Monitoring is the correct choice because it is specifically designed to continuously track a deployed model's prediction quality over time, detecting issues like data drift, feature drift, and prediction skew that indicate the model's reliability is degrading due to changes in the real world. It automatically compares incoming prediction data against a baseline training dataset and alerts when statistical distributions shift beyond configurable thresholds, enabling proactive retraining or intervention.

Answer

Vertex AI Explainable AI

Answer

Vertex AI Experiments

Answer

Vertex AI Prediction

Question 2

A data science team needs to ensure that a deployed Vertex AI model can handle varying traffic patterns with minimal latency and cost. What should they do?

Accepted Answer

Use Vertex AI Prediction with autoscaling. Vertex AI Prediction with autoscaling dynamically adjusts the number of serving instances based on incoming traffic, ensuring minimal latency during spikes and cost efficiency during lulls. This is the recommended approach for handling variable traffic patterns in production, as it leverages Google Cloud's managed infrastructure to scale from zero to thousands of nodes automatically.

Answer

Use batch prediction instead of online

Answer

Pre-warm all instances

Answer

Deploy to a single large machine type

Question 3

A machine learning pipeline uses Vertex AI Pipelines. One component fails intermittently due to resource constraints. What is the best way to handle this?

Accepted Answer

Use retry policies in the component specification. Option A is correct because Vertex AI Pipelines supports retry policies at the component level via the `retry` field in the component specification (YAML or Python). This allows the pipeline to automatically re-execute a failed component when the failure is transient (e.g., resource exhaustion), without manual intervention. Retry policies are the standard mechanism for handling intermittent failures in a serverless orchestration environment like Vertex AI Pipelines.

Answer

Deploy the pipeline on a larger cluster

Answer

Increase the pipeline timeout

Answer

Use a different orchestrator

Question 4

A company serves multiple models using Vertex AI endpoints. Each model has different latency and memory requirements. To minimize cost, the company wants to share underlying compute resources among models. Which approach should they use?

Accepted Answer

Deploy all models to a single Vertex AI endpoint and configure traffic splitting.. Vertex AI endpoints support traffic splitting, allowing you to deploy multiple models behind a single endpoint and route a percentage of traffic to each model. This enables resource sharing and cost optimization because the underlying compute infrastructure is shared among the models, unlike separate endpoints which would each require dedicated resources.

Answer

Deploy each model as a separate Cloud Run service and use a load balancer.

Answer

Use a single GKE cluster with multiple deployments and use Istio for routing.

Answer

Create separate endpoints for each model and use a load balancer to route traffic.

Question 5

Your company has a machine learning model that predicts customer churn. The model is deployed on Vertex AI Endpoints with autoscaling. After a marketing campaign, traffic to the endpoint increases by 10x. Some predictions start failing with 'HTTP 503 Service Unavailable' errors. What is the most likely cause?

Accepted Answer

The autoscaling configuration has insufficient maximum nodes to handle the traffic.. A 503 Service Unavailable error from Vertex AI Endpoints indicates that the endpoint is overwhelmed and cannot handle the incoming request volume. With a 10x traffic spike and autoscaling configured, the most likely cause is that the autoscaling configuration has insufficient maximum nodes, so the endpoint cannot scale out enough to handle the load, causing requests to be rejected.

Answer

The model container has a memory leak.

Answer

The model's accuracy has degraded due to data drift.

Answer

The model is using an older version that is not supported.

Question 6

A model deployed on Vertex AI Endpoint is making predictions with high accuracy but the business team suspects bias against a certain demographic group. You need to analyze the model's predictions for fairness. What is the most effective approach?

Accepted Answer

Use Vertex AI Explainable AI to generate feature attributions for each prediction and analyze whether the demographic feature has disproportionate impact.. Vertex AI Explainable AI provides per-instance feature attributions, which allow you to examine how the model uses each feature—including sensitive demographic attributes—to arrive at a prediction. By analyzing these attributions across demographic groups, you can detect whether the model disproportionately relies on the demographic feature, indicating potential bias. This approach is more granular than aggregate metrics and directly addresses the business team's concern about bias in individual predictions.

Answer

Compute overall fairness metrics by comparing prediction rates across demographic groups.

Answer

Collect more data for the under-represented group and retrain the model.

Answer

Use Vertex AI Model Monitoring to check for training-serving skew on the demographic feature.

Question 7

A company uses a custom container image for model serving. The image is large (10 GB). During deployment, they get timeouts. What should they do?

Accepted Answer

Use a smaller base image. Option D is correct because using a smaller base image directly addresses the root cause of the timeout: the 10 GB image takes too long to download from the container registry during pod startup. By reducing the image size (e.g., using a slim or distroless base image), the pull time decreases, avoiding the default kubelet image pull timeout (typically 5 minutes) without requiring infrastructure changes.

Answer

Pre-pull the image on all nodes

Answer

Increase the timeout in the deployment config

Answer

Switch to a larger machine type

Question 8

After deploying a model to Vertex AI Endpoints, the prediction responses include unexpected data. The model returns logits instead of probabilities. What is the most likely cause?

Accepted Answer

The model output is not post-processed. The most likely cause is that the model output is not post-processed. In Vertex AI Endpoints, models often output raw logits (unnormalized scores) from the final layer, and a softmax or sigmoid activation must be applied as a post-processing step to convert these logits into probabilities. Without this post-processing, the endpoint returns the raw logits, which is why the prediction responses contain unexpected data.

Answer

The model was trained with different loss

Answer

The input data is scaled incorrectly

Answer

The endpoint is not properly configured

Question 9

A data engineer deploys a TensorFlow model on Vertex AI using a custom container. After deployment, online prediction requests sometimes fail with a 500 error and the message 'Out of memory'. The model requires significant memory during inference. Which action should the engineer take to resolve this issue?

Accepted Answer

Increase the memory limit in the Vertex AI endpoint configuration.. Option B is correct because Vertex AI endpoints allow you to configure a machine type with a specific memory limit. When a custom container runs out of memory during inference, increasing the memory allocation (e.g., by selecting a machine type with more RAM, such as n1-highmem-8) directly addresses the 'Out of memory' error. This ensures the container has sufficient resources to handle the model's inference workload without crashing.

Answer

Reduce the batch size of prediction requests sent to the endpoint.

Answer

Optimize the model by quantizing weights to reduce model size.

Answer

Use a machine type with higher CPU performance.

Question 10

A company deploys a scikit-learn model on Vertex AI for online predictions. The model is packaged in a custom container with all dependencies. Users report high latency (over 5 seconds) for predictions. The model size is 2 GB. What is the most likely cause of the high latency?

Accepted Answer

Using a custom container with a large unoptimized model. Option C is correct because a 2 GB model loaded into a custom container without optimization (e.g., quantization, pruning, or ONNX conversion) will cause significant cold-start latency and per-request loading overhead. Vertex AI online predictions require the model to be loaded into memory for each request or container instance; a large, unoptimized model increases both loading time and inference time, easily exceeding 5 seconds.

Answer

Using online predictions instead of batch prediction

Answer

Not enabling GPU acceleration

Answer

Using a small machine type (e.g., n1-standard-2)

Question 11

Refer to the exhibit. The feature store 'my_fs' responds to offline queries but online serving requests fail. What is the most likely cause?

Accepted Answer

Update the existing feature store to enable online serving. The feature store 'my_fs' responds to offline queries but not online serving requests, which indicates that online serving is not enabled for the feature store. In Vertex AI Feature Store, online serving requires a dedicated endpoint and underlying infrastructure (e.g., Bigtable) to serve low-latency requests. Updating the existing feature store to enable online serving (option C) is the correct fix, as it activates the necessary serving resources without recreating the store.

Answer

Create a new feature store with online serving enabled

Answer

Use Cloud Bigtable directly

Answer

Re-import features into a new store

Question 12

You are a data engineer at a financial services company. You have deployed a credit risk model on Vertex AI Endpoints using a custom container with a TensorFlow SavedModel. The model expects input features as a JSON object. Recently, the model has been returning high prediction latency and occasional 503 errors. You have enabled autoscaling with minNodes=2 and maxNodes=10. The model is CPU-only and uses n1-standard-4 machines. Monitoring shows that during peak hours, CPU utilization reaches 90% and memory is at 80%. The number of prediction requests per second peaks at 100. You suspect that the model is not scaling fast enough. Which action will most effectively reduce latency and eliminate 503 errors?

Accepted Answer

Change the machine type to n1-standard-4 with a GPU (e.g., NVIDIA T4) and update the custom container to use GPU. Option B is correct because the high CPU utilization (90%) indicates that the model's inference is compute-bound. Offloading the computation to a GPU (NVIDIA T4) significantly accelerates TensorFlow model inference, reducing per-request latency and allowing each replica to handle more requests per second. This directly addresses the root cause of the 503 errors (requests timing out due to slow inference) and reduces the need for rapid scaling.

Answer

Increase maxNodes to 20 to allow more replicas during peak

Answer

Set minNodes to 5 to keep more replicas warm

Answer

Switch to n1-highmem-4 machines to provide more memory per node

Question 13

A gaming company uses Cloud Pub/Sub to ingest player activity events. A Dataflow streaming pipeline consumes these events, performs stateful processing to compute session metrics, and writes results to Cloud Bigtable for low-latency queries. Recently, the pipeline's processing latency increased, and the Bigtable write throughput dropped. Monitoring shows that the pipeline is experiencing a high rate of 'out-of-order' messages and 'duplicate' events. The Pub/Sub subscription is configured with exactly-once delivery. The Dataflow job uses a GlobalWindow with a trigger that fires every 10 seconds. What is the most likely cause and solution?

Accepted Answer

The pipeline's trigger is too frequent; increase the trigger interval to 30 seconds and set allowed lateness to 1 minute to handle out-of-order events.. Option C is correct because the high rate of out-of-order and duplicate events indicates that the pipeline's trigger is firing too frequently, causing the stateful processing to attempt to commit partial windows before all events arrive. Increasing the trigger interval to 30 seconds and setting allowed lateness to 1 minute allows the pipeline to buffer more events, reduce the number of speculative triggers, and handle late-arriving data within the lateness bound, which directly reduces processing latency and Bigtable write contention.

Answer

The Bigtable instance is under-provisioned; add more nodes to increase write throughput.

Answer

Change the Pub/Sub subscription from exactly-once to at-least-once delivery to avoid redelivery overhead.

Answer

The streaming engine is disabled; enable Streaming Engine to reduce worker memory pressure.

Question 14

Your team is using Cloud Data Fusion to build batch ETL pipelines that load data from Cloud Storage into BigQuery. You have several pipelines that run daily. Recently, one pipeline started failing with a 'Permission denied' error when trying to read a new CSV file uploaded to a specific Cloud Storage bucket. Other pipelines using the same bucket succeed. The failing pipeline has a Cloud Storage source plugin that uses a service account with the roles/storage.objectViewer role. The bucket has uniform bucket-level access enabled. What is likely causing the issue?

Accepted Answer

Check that the service account used by the failing pipeline's Data Fusion instance has the correct permissions, and ensure that the service account is the same as the one used by working pipelines.. The correct answer is B because the error is likely due to the Data Fusion instance's service account, not the source plugin's service account. In Cloud Data Fusion, the pipeline execution uses the service account attached to the Data Fusion instance itself to access Cloud Storage, even if the source plugin specifies a different service account. Since other pipelines using the same bucket succeed, the issue is that the failing pipeline's Data Fusion instance uses a service account that lacks the roles/storage.objectViewer role on the bucket, while working pipelines use an instance with the correct permissions.

Answer

Create a custom IAM role with storage.buckets.get and storage.objects.get permissions and assign it to the service account.

Answer

Disable uniform bucket-level access and add bucket ACLs for the service account.

Answer

Add the service account as a member of the Cloud Storage bucket with the roles/storage.objectViewer role.

Question 15

A media company uses Cloud Dataflow to process video metadata from a Pub/Sub stream. The pipeline enriches metadata using a lookup table stored in Cloud Bigtable. Recently, they noticed increased latency and occasional 'Bigtable operation timeout' errors. The Bigtable instance has 3 nodes and the data is highly distributed. The Dataflow pipeline uses default settings. What is the most likely cause of the timeouts?

Accepted Answer

The Bigtable table uses a single column family with over 100 columns, leading to high read overhead. A single column family with over 100 columns in Bigtable forces the system to read all column qualifiers for each row, even if only a few are needed. This increases read overhead and latency, and can trigger 'operation timeout' errors when the Dataflow pipeline's default settings (which do not limit column qualifiers) request the entire row. The highly distributed data and 3-node cluster exacerbate the issue, but the root cause is the excessive column count within one family.

Answer

The Dataflow pipeline uses a large batch size for Bigtable reads, overwhelming the instance

Answer

The Bigtable cluster has too few nodes for the read throughput

Answer

The Dataflow pipeline does not cache Bigtable results, causing repeated lookups