PDE Practice Test 36 — 15 Questions

Question 1

Your company runs batch predictions using Vertex AI Batch Prediction on a monthly basis. The predictions are used to generate customer segments for marketing campaigns. This month, the batch prediction job failed with an error: 'The number of rows in the input table does not match the number of rows in the output table.' The input table in BigQuery has 5 million rows, but the output table has only 4.5 million rows. You need to identify and handle the missing predictions. What is the most efficient course of action?

Accepted Answer

Enable the 'write_prediction_errors' flag in the batch prediction configuration to capture failed predictions in a separate table.

Answer

Manually inspect the input table to find which rows are missing and rerun the batch prediction for those rows.

Answer

Run the batch prediction job with the 'generate_explanation' parameter enabled to get additional output for debugging.

Answer

Use a Cloud Dataflow pipeline to process the input data and call the model for each row, handling errors programmatically.

Question 2

Your team is responsible for operationalizing a series of machine learning models that are trained and deployed using Vertex AI Pipelines. The pipeline consists of several steps including data preprocessing, training with hyperparameter tuning, model evaluation, and deployment to an endpoint. Recently, the pipeline has been failing intermittently at the model evaluation step with an error indicating insufficient memory. The evaluation step uses a custom container with a memory limit of 4 GB. The training step uses 8 GB and completes successfully. You need to resolve the failure without drastically increasing costs. What should you do?

Accepted Answer

Optimize the evaluation code to use streaming or incremental processing to reduce peak memory usage.

Answer

Increase the memory limit for the evaluation custom container to 8 GB to match the training step.

Answer

Reduce the batch size used in the evaluation step to lower memory consumption.

Answer

Use a smaller machine type for the evaluation step to force lower memory usage.

Question 3

Your company deploys a classification model on Vertex AI for online predictions. The model is an XGBoost model trained on tabular data with 500 features. The endpoint uses a single n1-standard-4 node. After deployment, users report that predictions take 8-10 seconds on average, while the required SLA is under 2 seconds. You have already verified that the model is not large (under 100 MB) and the input data size is small. The endpoint does not scale automatically. Which action should you take to reduce latency to meet the SLA? A) Change the machine type to n1-highcpu-4 to prioritize compute over memory. B) Enable autoscaling by setting min replicas to 2 and max replicas to 5. C) Switch to a custom container that preloads the model into memory. D) Reduce the number of features by half.

Accepted Answer

Enable autoscaling by setting min replicas to 2 and max replicas to 5.. Option B is correct because the current single node is overloaded; autoscaling distributes traffic across multiple nodes, reducing latency for each request. Option A (CPU-optimized machine) may not help if the bottleneck is not CPU. Option C (preloading) is already default for Vertex AI. Option D (feature reduction) could degrade model accuracy and is not necessary.

Answer

Change the machine type to n1-highcpu-4 to prioritize compute over memory.

Answer

Reduce the number of features by half.

Answer

Switch to a custom container that preloads the model into memory.

Question 4

A retail company uses Vertex AI Pipelines to automate monthly retraining of a recommendation model. The pipeline consists of three steps: (1) extract data from BigQuery, (2) train a TensorFlow model on Vertex AI Training, (3) upload the model to Vertex AI Model Registry and deploy to an endpoint if performance metrics improve. Recently, the pipeline has been failing at step 2 with the error: 'The job was cancelled by the system because it exceeded the maximum training time of 3600 seconds.' You have confirmed that the training code is correct and the data size has not changed significantly. What should you do to fix this pipeline failure? A) Reconfigure the pipeline to use a larger machine type for training. B) Set the training timeout to 7200 seconds in the pipeline configuration. C) Reduce the training dataset size by sampling fewer rows. D) Switch from TensorFlow to a simpler model framework.

Accepted Answer

Set the training timeout to 7200 seconds in the pipeline configuration.. Option B is correct because the default timeout for a training job in Vertex AI Pipelines is 3600 seconds; increasing the timeout allows the job to complete. Option A (larger machine) may help but is not a direct fix for timeout. Option C (reducing data) degrades model quality. Option D (changing framework) is drastic and unnecessary.

Answer

Reduce the training dataset size by sampling fewer rows.

Answer

Switch from TensorFlow to a simpler model framework.

Answer

Reconfigure the pipeline to use a larger machine type for training.

Question 5

A financial services company uses a custom container on Vertex AI Prediction to serve a fraud detection model. The container runs a Flask app that loads a large feature engineering library (~2 GB) at startup. The model is updated weekly. For the past two weeks, the new model version has been failing health checks and showing 'Container failed to start' errors in the logs. The previous versions worked fine. You inspect the container image and confirm it is built correctly using Cloud Build. The only change in the latest build is an updated version of the feature engineering library. What is the most likely cause and how should you fix it?

Accepted Answer

The new library version increased memory consumption during startup, exceeding the health check timeout. Increase the startup probe initial delay.

Answer

The Cloud Build step that pushes the image is misconfigured. Rebuild using a different approach.

Answer

The Vertex AI endpoint machine type is too small for the new container. Upgrade to a larger machine type.

Answer

The new library has a dependency conflict that causes the Flask app to crash. Roll back to the previous library version.

Question 6

You manage a large-scale machine learning system that recommends products to users. The model is a deep neural network trained on TensorFlow and deployed on Vertex AI Endpoint with global load balancing. The model receives over 10,000 requests per second. Recently, the team added a new feature: the user's current geographic location (latitude/longitude). After deploying the updated model, you notice that the average prediction latency has doubled, and the error rate has increased, particularly for requests from regions far from the model's primary training data (North America). You suspect the location feature is causing issues. What should you do to diagnose and mitigate the problem?

Accepted Answer

Examine the latency breakdown using Cloud Monitoring to see if the location feature is causing computationally expensive operations, then consider feature engineering like bucketing coordinates.

Answer

Remove the location feature from the model and retrain without it to restore performance.

Answer

Increase the number of replicas for the endpoint to handle the increased latency.

Answer

Switch to a regional endpoint in North America to reduce latency for the majority of users.

Question 7

A financial services company operates a real-time fraud detection pipeline using Apache Beam running on Google Cloud Dataflow. The pipeline reads transactions from Pub/Sub, enriches them with customer data from Bigtable, runs a machine learning model with side inputs from a Redis cluster, and writes results to BigQuery for downstream reporting. The data must be processed with exactly-once semantics to avoid duplicate fraud alerts or missing transactions. The pipeline currently uses a global window with 5-minute accumulation, but the team is experiencing high latency and occasional duplicates when the model side input is updated (triggered every 15 minutes via a WatchTransform). Additionally, the pipeline has a dead letter queue that outputs failed records to a separate Pub/Sub topic, but these records are never reprocessed. The team needs to ensure high reliability and data quality. Which course of action should the team take to improve solution quality?

Accepted Answer

Implement sliding windows of 5 minutes with a 2-minute allowed lateness, use side inputs with periodic refreshes using the .withUpdateFrequency transformation, and set up a Cloud Function to automatically replay dead letter records back to the main Pub/Sub topic after fixing the issue.. Option B is correct because switching to a sliding window with allowed lateness ensures that late-arriving transactions are captured without blocking the window, and using side inputs with periodic refreshes (e.g., .withUpdateFrequency) reduces latency from model updates. Adding a system to reprocess dead letter records (e.g., via a Cloud Function that replays to the main topic) ensures data completeness. Option A is incorrect because fixed windows with session gaps do not help with side input latency and may cause data loss. Option C is incorrect because GlobalWindow with triggers can cause duplicates if not configured carefully; defaults may not achieve exactly-once. Option D is incorrect because it focuses on batching, which is not suitable for real-time detection and introduces latency.

Answer

Use fixed windows with a 10-minute duration and session gap of 2 minutes, disable side input caching, and log all dead letter records to Cloud Storage for manual inspection.

Answer

Switch to a batch processing approach that runs every minute using Cloud Composer, with data loaded from Pub/Sub into BigQuery and then processed with Dataproc to run the model.

Answer

Keep the global window but use a custom trigger with early firings every 30 seconds and a late-firing threshold of 1 minute, and configure the side input to be broadcast every 5 minutes using a Read transform.

Question 8

A media company runs a batch data pipeline on Cloud Dataflow that ingests log files from Cloud Storage, transforms them, and writes results to BigQuery for analytics. The pipeline runs daily and has been stable for months. Recently, the source log format changed: a new optional field was added to some records. The pipeline started failing with ParseErrors for rows that contain the new field. The error logs show that the Dataflow job uses a hardcoded JSON schema that does not include the new field. The Dataflow pipeline logs are written to Stackdriver Logging, but no alerts are configured. The team wants to ensure that future schema changes do not break the pipeline and that failures are detected promptly. The team has limited experience with streaming and wants to keep the batch approach. Which course of action should the team take to improve solution quality?

Accepted Answer

Implement schema validation and evolution using a schema registry (e.g., AVRO) in the Dataflow pipeline, and configure Stackdriver alerts on pipeline failure or error logs.. Option D is correct because using a schema registry (e.g., AVRO schema registry) and updating the pipeline to use a flexible schema (e.g., infer schema from data or use a schema registry) allows the pipeline to handle new fields without failing. Additionally, configuring Stackdriver alerts on pipeline failure logs ensures prompt detection of issues. Option A is incorrect because it only addresses detection after the fact, not prevention. Option B is incorrect because BigQuery dry run does not prevent pipeline failures. Option C is incorrect because scheduling a job to check every hour is reactive and inefficient.

Answer

Create a Cloud Monitoring alert on any PipelineError log entries from the Dataflow job, and set up a runbook to manually fix schema mismatches within one hour.

Answer

Schedule a Cloud Function to run every hour that checks the latest log file headers and compares them to the pipeline schema, sending an alert if differences are found.

Answer

Use BigQuery dry run queries to validate the schema before loading data, and if a mismatch is detected, block the pipeline run and notify the team via email.

Question 9

A company runs a data pipeline that ingests clickstream events from multiple websites into Cloud Pub/Sub, then processed by Dataflow to generate user sessions, and written to BigQuery for analytics. The pipeline runs 24/7. Recently, the team noticed that some sessions are incomplete due to missing events, and data quality checks reveal that about 2% of sessions have gaps of more than 30 minutes. The pipeline uses fixed 30-minute windows for sessionization, with allowed lateness set to 10 minutes. They have Cloud Monitoring dashboards tracking system throughput and pipeline lag but do not have custom metrics tracking per-element delays or watermark progress. The team suspects two possible causes: (a) the Pub/Sub subscription accumulates backlog and some messages are delivered after the window end; (b) the Dataflow job has insufficient workers causing checkpoint failures. The team needs to determine the root cause and improve data quality. What is the best first course of action?

Accepted Answer

Set up a Dataflow monitoring dashboard that tracks the watermark delay and create an alert when it exceeds the allowed lateness.. To determine whether late-arriving messages are the issue, the team should monitor the Dataflow watermark delay, which indicates how far behind the pipeline is compared to the event time. Setting up a metric and alert on watermark delay > allowed lateness will confirm if late data is being dropped.

Answer

Change the Pub/Sub subscription to pull mode with more aggressive flow control settings.

Answer

Increase the number of Dataflow workers and set autoscaling to the maximum allowed.

Answer

Modify the Dataflow pipeline to use session windows instead of fixed windows, and increase allowed lateness to 60 minutes.

Question 10

A company runs a large Dataflow pipeline that aggregates user activity data from Pub/Sub into BigQuery every 10 minutes using fixed windows. Recently, the daily summary reports have shown 5-10% lower user engagement for certain segments compared to historical trends. The pipeline is completing successfully with no errors in Cloud Monitoring, and the Dataflow job dashboard shows all steps in green. There are no alarms. The team suspects data is being dropped or missed. They have verified that the Pub/Sub topic is receiving data correctly. After reviewing the pipeline code, they find that the pipeline uses a global window with a default 10-minute trigger, and writes results to a single BigQuery table partitioned by date. They also use exactly-once processing mode. Which of the following is the most likely cause and the best course of action to diagnose and fix the data quality issue?

Accepted Answer

Use Dataflow’s built-in metrics to compare the number of elements read from Pub/Sub and written to BigQuery for each window.. Option D is correct because the pipeline uses a global window with a default 10-minute trigger, which means data is processed in micro-batches but the global window never closes, so late-arriving data is included. However, the team suspects data is being dropped, and the most direct way to diagnose this is to compare the number of elements read from Pub/Sub (using the Pub/Sub subscription's 'pubsub_subscription' metric) with the number of elements written to BigQuery (using the BigQuery sink's 'bigquery_rows_written' metric) for each window. This comparison will reveal if any data is lost between reading and writing, which is a common issue when using exactly-once processing mode with streaming inserts that may silently fail due to schema mismatches or quota limits.

Answer

Implement a retry mechanism in the Pub/Sub subscription to ensure no messages are lost.

Answer

Enable Cloud Logging for all pipeline steps and analyze the logs for dropped elements.

Answer

Add a global window with a late-data trigger to capture any data arriving after the window ends.

Question 11

A company runs a Dataproc cluster with 10 worker nodes for a Spark streaming job that processes data from Pub/Sub (via Pub/Sub Lite) and writes to Cloud Storage. They observe that the job is producing many small files in Cloud Storage, leading to high costs and performance issues in downstream batch pipelines. The team wants to consolidate output files while maintaining low latency. What is the best solution?

Accepted Answer

Use windowed streaming with a longer window duration and Spark's file size configuration. Option B is correct because using a longer window duration in Spark Streaming allows more data to accumulate before writing, and combining this with Spark's file size configuration (e.g., `spark.sql.files.maxRecordsPerFile` or `spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2`) ensures that output files are consolidated into larger sizes. This reduces the number of small files in Cloud Storage while maintaining low latency by avoiding an extra compaction job or reducing parallelism.

Answer

Run a separate compaction job that periodically merges small files into larger ones

Answer

Reduce the number of workers to force more data per task

Answer

Switch from Dataproc to Dataflow, which has built-in file sharding optimization

Question 12

Your company runs a real-time recommendation system for a popular e-commerce website using a machine learning model deployed on Vertex AI Endpoints. The model takes user features and product catalog data as input and returns top-10 product recommendations. The system uses a feature store to serve user embeddings and product embeddings. Recently, the recommender team retrained the model with a new algorithm and deployed it as a new version. Since the deployment, the latency for recommendation requests has increased from 100ms to 500ms on average, exceeding the 200ms SLO. The model accuracy is acceptable, and there are no errors. The endpoint uses an n1-standard-8 machine with a single GPU. The new model is larger but still fits on the GPU. You investigate and find that the GPU utilization remains low (<20%), but CPU utilization is high (90%). What should you do to reduce latency while maintaining accuracy?

Accepted Answer

Increase the number of replicas (nodes) to parallelize the CPU-bound preprocessing work.. Option C is correct because the high CPU utilization (90%) with low GPU utilization (<20%) indicates that the bottleneck is CPU-bound preprocessing, not GPU inference. Increasing the number of replicas (nodes) distributes the CPU preprocessing load across multiple instances, reducing per-request latency without affecting model accuracy. This directly addresses the root cause while keeping the existing GPU resources.

Answer

Upgrade the machine type to one with more GPU memory (e.g., n1-standard-8 with a larger GPU) to reduce model inference time.

Answer

Change the batch size in the model serving code to process multiple requests together, improving GPU utilization.

Answer

Offload preprocessing to a dedicated Cloud Run service that runs asynchronously and returns precomputed feature vectors.

Question 13

A company runs a daily batch data processing pipeline using Cloud Dataproc. The pipeline reads 10 TB of CSV files from Cloud Storage, performs a heavy aggregation (GroupBy) and joins with a small reference table, then writes the results to BigQuery. The cluster consists of 20 n1-standard-8 nodes, including 10 preemptible workers for cost savings. Recently, the job completion time has doubled from 30 minutes to over an hour. The job logs show many tasks being retried, and the Shuffle spill ratio is high. No significant data volume change was observed. What is the most likely root cause?

Accepted Answer

Preemptible workers are being reclaimed, causing YARN container failures and task retries.. The correct answer is C because preemptible workers are frequently reclaimed by Google Cloud, causing YARN containers to fail and tasks to be retried. This leads to increased job completion time and a high shuffle spill ratio, as partial shuffle data is lost and must be recomputed. The doubling of job time without data volume change strongly points to infrastructure instability rather than data or configuration issues.

Answer

The cluster's HDFS is running out of space due to intermediate shuffle data.

Answer

Data skew has developed, causing a few tasks to process most of the data.

Answer

The reference table has increased in size, causing more data to be broadcast to all workers.

Question 14

A large e-commerce company is migrating its on-premise Hadoop cluster to Google Cloud using Dataproc for batch processing. The cluster processes daily sales data from multiple sources, generates aggregated reports, and performs ad-hoc analysis. The migration is complete, but users report that jobs are running 30% slower than on-premise. The data is stored in Cloud Storage as Parquet files partitioned by date. The Dataproc cluster uses preemptible VMs for worker nodes, and the master node uses a standard VM. The jobs heavily rely on shuffling data between stages. The cluster's autoscaling is enabled with a minimum of 10 and a maximum of 50 workers. During job execution, CPU utilization on workers is low, but disk I/O is high, especially on local SSDs. The network utilization is moderate. The team suspects that the shuffle operation is causing the slowdown. Which action should the team take to improve job performance?

Accepted Answer

Enable Cloud Storage as a shuffle destination by setting the property `dataproc:dataproc.shuffle.direct` to `true` and ensure the cluster has appropriate IAM permissions.. B is correct because the high disk I/O on local SSDs during shuffling indicates that the shuffle data is being written to local disk, which is a bottleneck. By enabling Cloud Storage as a shuffle destination via `dataproc:dataproc.shuffle.direct`, shuffle data is written directly to Cloud Storage, bypassing local disks and leveraging Google Cloud's high-throughput object storage. This reduces disk I/O contention and improves shuffle performance, especially when preemptible VMs are used, as shuffle data is not lost on VM preemption.

Answer

Attach additional local SSDs to each worker to increase local disk capacity and I/O throughput.

Answer

Change all worker VMs from preemptible to standard VMs to avoid preemption and improve reliability.

Answer

Increase the maximum number of preemptible workers to 100 to provide more parallelism.

Question 15

A healthcare company uses Vertex AI to deploy a medical image classification model. The model is deployed on a private endpoint with automatic scaling (minReplicaCount=2, maxReplicaCount=10). The model uses a custom container with a GPU for inference. Recently, during peak business hours (9 AM - 5 PM), users report that prediction requests frequently time out after 60 seconds, and the error rate increases. The team checks Cloud Monitoring and observes that CPU utilization averages 40%, GPU utilization averages 30%, and the number of replicas stays at 2. There are no errors in the container logs. The model serves a few hundred requests per second during peak. The team suspects the issue is not resource saturation but something else. What should they do to resolve the problem?

Accepted Answer

Optimize the prediction container to handle requests faster by reducing image pre-processing and using async I/O.. Option D is correct because the symptoms—low CPU/GPU utilization, replicas stuck at 2, and timeouts—indicate that the container is taking too long to process each request, not that resources are saturated. Optimizing the container (e.g., reducing image pre-processing, using async I/O) reduces per-request latency, allowing the model to handle the same request rate within the 60-second timeout. This directly addresses the root cause without changing scaling or timeout settings.

Answer

Switch from online prediction to batch prediction using Vertex AI Batch Prediction.

Answer

Increase the minReplicaCount to 5 to ensure more replicas are always available.

Answer

Increase the request timeout setting on the load balancer to 120 seconds.