990 questions total · 14pages · All types, answers revealed
Drag and drop the steps to perform a hyperparameter tuning job on Vertex AI in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Define the search space, then create and run the tuning job, monitor, and select the best parameters.
A team is monitoring a model on Vertex AI Endpoints and wants to track the p99 latency of online predictions. Which approach should they use to set up latency monitoring and alerting?
Prediction logs contain latency information; log-based metrics can capture p99 and other percentiles.
Why this answer
Vertex AI Endpoints automatically export request/response logs to Cloud Logging, which can be used to create log-based metrics for latency percentiles. These metrics can then be visualized in Cloud Monitoring dashboards and used for alerting.
A company is deploying a deep learning model on edge devices with limited storage and computational resources. They need to reduce the model size by 80% while maintaining acceptable accuracy. Which two techniques should they combine?
Quantization and pruning: Correct. Quantization (e.g., INT8) and pruning (e.g., 50% sparsity) together can achieve 80%+ model size reduction while maintaining acceptable accuracy on edge devices.
Why this answer
Quantization reduces model size by converting weights from FP32 to INT8, achieving up to 75% size reduction. Pruning removes redundant weights (e.g., 50% pruning) to further shrink the model. Together, these two techniques can reduce model size by over 80% (e.g., 50% pruning + INT8 quantization yields ~87.5% reduction) while preserving acceptable accuracy on edge devices.
Knowledge distillation also reduces size but typically requires a pre-trained teacher and may not achieve the extreme compression needed when combined with quantization alone.
Which TWO factors should you consider when choosing between BigQuery and Cloud Storage for storing training data? (Choose 2)
Correct: Cloud Storage is better for unstructured data.
Why this answer
BigQuery is optimized for structured, tabular data (e.g., CSV, Avro, Parquet) and supports SQL queries, while Cloud Storage is a better fit for unstructured data (e.g., images, videos, raw text files) that does not require schema enforcement. Choosing the right storage depends on whether the training data has a fixed schema and requires relational querying or is blob-based and needs high-throughput access.
Exam trap
Google Cloud often tests the misconception that BigQuery has a hard 1 TB storage limit, when in reality the limit is much higher (default 10 TB for free, and no hard cap for paid tiers), leading candidates to incorrectly choose option E.
An ML engineer trained a model and registered it in Vertex AI Model Registry. They want to assign the alias 'champion' to the best-performing version for production deployment. Which gcloud command should they use?
This updates the version's aliases.
Why this answer
The correct command is 'gcloud ai models versions update' with the --update-aliases flag. This command updates a specific model version's aliases, allowing you to assign or remove aliases like 'champion' to denote the best-performing version for production. Option A only describes a version, option B uploads a new model, and option C deploys a model to an endpoint, none of which assign aliases to a version.
A company wants to use Vertex AI for hyperparameter tuning. Which three components are required to configure a hyperparameter tuning job? (Choose THREE.)
Required to specify how to search.
Why this answer
Vertex AI hyperparameter tuning requires specifying the search algorithm (Bayesian, grid, or random) to determine how the hyperparameter space is explored. Bayesian optimization is the default and most efficient for continuous spaces, while grid search is exhaustive and random search is simple. Without an algorithm, Vertex AI cannot decide how to sample trials.
Exam trap
Candidates often mistakenly include machine type or container image as mandatory tuning parameters, but these are optional training job settings.
You have a TensorFlow model that you want to deploy on edge devices for real-time inference. The model was trained in Vertex AI. You need to convert it to a format suitable for on-device inference. Which approach should you use?
TensorFlow Lite is optimized for on-device inference with low latency.
Why this answer
TensorFlow Lite is specifically designed for on-device inference on edge devices, offering optimized performance and reduced model size. The TensorFlow Lite converter transforms a TensorFlow model (e.g., from a SavedModel) into the FlatBuffer format (.tflite), which is lightweight and compatible with mobile and embedded platforms. This directly addresses the requirement for real-time inference on edge devices.
Exam trap
A common misconception is that Vertex AI services like Edge Manager or Model Optimization directly produce a deployable edge format, when in fact TensorFlow Lite conversion is the required final step for on-device inference.
How to eliminate wrong answers
Option A is wrong because a TFX pipeline is a production ML workflow framework for orchestrating training, validation, and deployment, not a model format for on-device inference; serializing it does not produce a deployable edge model. Option B is wrong because Vertex AI Edge Manager is a service for managing and deploying models to edge devices, but it expects models in a compatible format like TensorFlow Lite; exporting to SavedModel alone is insufficient without conversion, and Edge Manager itself does not perform the conversion. Option D is wrong because Vertex AI Model Optimization focuses on techniques like pruning and quantization to improve model efficiency, but it does not compile the model into a format suitable for on-device inference; the output still requires conversion to TensorFlow Lite for edge deployment.
A company is building a document processing pipeline for invoices. They need to extract key fields (invoice number, date, total amount) and allow human review for invoices over $10,000. Which TWO Google Cloud services/features should they combine?
Why this answer
Document AI with a specialized invoice parser can extract fields. Human-in-the-Loop (HITL) is a feature of Document AI that enables human review. Cloud Vision API is not specialized for invoices.
AutoML Tables is for tabular models. Cloud Translation is not needed.
You need to serve multiple models on a single Vertex AI endpoint to reduce costs. How can you achieve this?
Multiple models can be deployed to a single endpoint, each receiving a portion of the traffic.
Why this answer
Vertex AI Prediction supports multi-model serving, allowing you to deploy multiple models to a single endpoint and use traffic splits to route a percentage of requests to each model. This reduces costs by sharing underlying infrastructure (e.g., compute resources) across models, rather than provisioning separate endpoints or containers for each model.
Exam trap
The trap here is that candidates often confuse multi-model serving with containerization, assuming that bundling models into a single container (Option C) is equivalent to Vertex AI's native multi-model support, but this ignores the need for traffic splitting and independent model lifecycle management.
How to eliminate wrong answers
Option A is wrong because Cloud Run serves each model as a separate service, which does not consolidate models onto a single endpoint and incurs additional costs for individual scaling and networking. Option C is wrong because packaging all models into a single container violates the principle of model isolation, complicates updates, and does not leverage Vertex AI's native traffic-splitting mechanism for granular control. Option D is wrong because deploying each model to its own endpoint and using a load balancer increases operational overhead and cost, as each endpoint requires separate compute resources, defeating the purpose of cost reduction.
A machine learning team has a prototype using a custom TensorFlow model trained on a small dataset stored in Cloud Storage. They want to scale the prototype to production with minimal code changes while ensuring the model can handle increased traffic and new data. The model currently loads data using tf.data.Dataset from CSV files. Which approach best meets these requirements?
Vertex AI provides seamless scaling with minimal code changes and supports tf.data.Dataset.
Why this answer
Vertex AI Prediction with autoscaling directly addresses the need to handle increased traffic without code changes, while Vertex AI Training with hyperparameter tuning and distributed training enables scaling to larger datasets with minimal modifications to the existing tf.data pipeline. This approach keeps the custom TensorFlow model intact and leverages managed infrastructure for both training and serving.
Exam trap
The trap here is that candidates may overcomplicate by choosing containerization (B) or a completely different platform (C), missing that Vertex AI Prediction natively supports TensorFlow models with autoscaling and minimal code changes.
How to eliminate wrong answers
Option B is wrong because it suggests using AI Platform (Unified) Prediction with a custom container, which is unnecessary and adds complexity; the existing model can be deployed directly without containerization, and the requirement is minimal code changes. Option C is wrong because migrating to BigQuery ML would require rewriting the model logic from TensorFlow to SQL, which is a significant code change and not suitable for a custom TensorFlow model. Option D is wrong because Cloud Run Functions are stateless and not designed for serving ML models with autoscaling for prediction traffic; Cloud Scheduler for retraining does not address the need for handling increased traffic or new data in a production serving path.
A data scientist wants to deploy a trained TensorFlow model to Vertex AI for online predictions. They need to serve predictions with low latency and want to leverage GPU acceleration. Which machine type should they select when creating the Vertex AI endpoint?
Attaching a GPU to an n1-standard machine enables GPU acceleration.
Why this answer
The n1-standard-4 machine type supports attaching GPUs such as the NVIDIA Tesla T4, which provides GPU acceleration for low-latency online predictions. Vertex AI endpoints require a machine type that allows GPU attachment, and the n1-series is one of the few families that supports GPUs, while the T4 offers a good balance of cost and performance for inference workloads.
Exam trap
The trap here is that candidates may assume any machine type can be paired with a GPU, but only specific series (like n1, n2, g2) support GPU attachment, and the e2 series explicitly does not, leading to a wrong selection if the GPU requirement is overlooked.
How to eliminate wrong answers
Option B is wrong because n1-standard-4 without a GPU does not provide GPU acceleration, so it cannot meet the requirement for low-latency predictions with GPU. Option C is wrong because e2-standard-4 does not support attaching GPUs at all; the e2 series is designed for cost-optimized CPU-only workloads. Option D is wrong because n1-highmem-8, while it can support GPUs, is over-provisioned in memory for typical inference tasks and does not include a GPU by default, so it would not satisfy the explicit need for GPU acceleration unless a GPU is attached, but the option as stated lacks the GPU specification.
A company is serving a model for their e-commerce website. They expect traffic to be low at night and very high during flash sales. They want to minimize costs while ensuring availability during spikes. Which autoscaling configuration should they use?
Scales from 1 to 20 based on load, cost-efficient.
Why this answer
Setting a high max_replica_count allows scaling to handle spikes, while a low min_replica_count saves cost during low traffic. CPU utilization target of 60% is reasonable.
A company has a prototype ML model that works well on historical data, but when deployed to production, the model performance degrades over time. The data distribution shifts gradually. Which strategy should they implement to maintain model accuracy?
Periodic retraining with fresh data helps the model adapt to gradual distribution shifts.
Why this answer
Gradual data distribution shifts (concept drift) require the model to adapt to new patterns over time. A retraining pipeline that periodically retrains on recent data ensures the model remains aligned with the current production distribution, directly addressing the degradation caused by drift without relying on static historical data.
Exam trap
Google Cloud often tests the misconception that overfitting or model complexity is the primary cause of production degradation, leading candidates to choose regularization or more complex architectures instead of recognizing that distribution shift requires data freshness.
How to eliminate wrong answers
Option A is wrong because increasing regularization strength reduces overfitting to historical noise but does not address the root cause—distribution shift—and may actually harm performance on new data by forcing the model to ignore legitimate new patterns. Option B is wrong because adding more historical records only reinforces the old distribution, making the model less responsive to recent shifts and potentially worsening drift. Option D is wrong because switching to a more complex model architecture increases capacity to fit data but does not solve the problem of stale training distribution; it may even overfit to outdated patterns and degrade faster under drift.
A data analyst wants to train a linear regression model to predict house prices using only SQL queries on BigQuery. Which BigQuery ML model type should they use?
Why this answer
The question specifies a linear regression model for predicting house prices, which is a regression task with a continuous target variable. BigQuery ML's LINEAR_REG model type is explicitly designed for linear regression, making it the correct choice for this use case.
Exam trap
Google often tests the distinction between regression and classification model types, and the trap here is that candidates might confuse LOGISTIC_REG (classification) with linear regression due to the word 'logistic' sounding similar to 'linear', or they might overcomplicate the solution by choosing a tree or neural network model when a simple linear model suffices.
How to eliminate wrong answers
Option A is wrong because BOOSTED_TREE_REGRESSOR is a tree-based ensemble method, not a linear model, and is overkill for a simple linear regression task. Option B is wrong because LOGISTIC_REG is used for binary classification, not regression (predicting continuous values like house prices). Option D is wrong because DNN_REGRESSOR is a deep neural network regressor, which is unnecessarily complex and not a linear model.
A developer needs to transcribe phone calls with high accuracy for a call center analytics application. The audio is in English and has background noise. Which Speech-to-Text model should they choose?
Why this answer
The telephony model is optimized for phone call audio with background noise. latest_long is for longer audio (without phone-specific optimization), and latest_short is for short utterances.
A company has deployed a fraud detection model on Vertex AI Prediction. After three months, the model's accuracy has degraded, and the business is losing money due to undetected fraud. What should the team implement to proactively detect such issues?
Model Monitoring automatically analyzes input distributions and prediction quality over time.
Why this answer
Vertex AI Model Monitoring tracks prediction drift and alerts when metrics exceed thresholds, enabling proactive detection of model degradation. Option B is wrong because Cloud Logging captures requests and responses but does not automatically detect drift, requiring manual review. Option C is wrong because shuffling training data does not help detect drift.
Option D is wrong because scheduling retraining without monitoring cannot proactively detect issues before they cause loss.
Exam trap
A common trap is to confuse monitoring with logging or retraining. Logging provides data but not automated drift detection; retraining fixes drift but doesn't detect it proactively.
A data science team wants to monitor model quality by comparing predictions against ground truth labels. They have deployed a model on Vertex AI Endpoints and enable request/response logging to BigQuery. Which THREE actions should they take to set up model quality monitoring? (Choose 3)
Correct: Scheduled queries automate metric computation.
Why this answer
To monitor model quality, the team needs to upload ground truth labels to BigQuery, join with prediction logs, compute metrics (e.g., accuracy, confusion matrix) over time, and optionally create dashboards.
A company uses Vertex AI Pipelines to orchestrate ML workflows. After a pipeline run, they want to query the lineage of a particular model artifact to find out which dataset and hyperparameters were used to produce it. Which API method should they use?
Correct method to get lineage subgraph.
Why this answer
Vertex AI Metadata allows querying lineage via the lineagesubgraph method to retrieve upstream and downstream artifacts.
You have a Vertex AI endpoint with autoscaling enabled. You notice that during traffic spikes, the endpoint takes a long time to scale up, causing prediction errors. What is the most effective solution?
Higher min replicas reduce the time to scale up during spikes.
Why this answer
Setting higher min replicas ensures a baseline of compute always available to absorb traffic spikes, reducing cold start latency. Increasing max replicas allows scaling higher but does not address the initial delay.
You need to run a custom training job on Vertex AI using a pre-built container for scikit-learn. Which container image should you specify?
Correct pre-built container for scikit-learn.
Why this answer
Vertex AI provides pre-built containers for scikit-learn with the prefix 'us-docker.pkg.dev/vertex-ai/training/scikit-learn-cpu.0.23-0'. The others are for different frameworks.
A team notices that a Vertex AI Pipeline step re-executes every time the pipeline runs, even though its inputs and code have not changed. They want to enable caching for this component to avoid redundant computation. However, caching is currently disabled globally. Which configuration change will enable caching for that specific component?
Setting caching=True in the component decorator enables caching for that component.
Why this answer
Caching can be enabled per component by setting the 'caching' parameter to True in the component decorator or by setting the environment variable. Setting it in the pipeline decorator affects all components. In KFP SDK v2, you can use @dsl.component(caching=True) or set the task-level caching.
The correct answer is to set caching=True in the component definition.
An organization wants to deploy a pre-trained BERT model for sentiment analysis on Vertex AI. They want to fine-tune it on their domain-specific data. Which feature in Vertex AI allows them to find and fine-tune a suitable foundation model with minimal effort?
JumpStart offers pre-built models and fine-tuning options with minimal code.
Why this answer
Vertex AI JumpStart provides one-click deployment and fine-tuning of foundation models, including BERT and other NLP models. Model Garden is for model discovery, but fine-tuning is typically done via JumpStart. AutoML is for training custom models, not fine-tuning existing ones.
Custom training requires more manual effort.
Match each ML acronym to its definition.
Drag a concept onto its matching description — or click a concept then click the description.
Area Under the ROC Curve
Mean Squared Error
Tensor Processing Unit
Support Vector Machine
Principal Component Analysis
Why these pairings
The correct matches are A (ML), B (AI), C (NLP), and D (CNN). Options E and F are incorrect because they swap definitions: E assigns the definition of AI to ML, and F assigns the definition of CNN to NLP.
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.)
dsl.Else defines the branch executed when the condition is false.
Why this answer
In Kubeflow Pipelines SDK v2, `dsl.If` and `dsl.Else` are the constructs used to create conditional execution branches within a pipeline. `dsl.If` evaluates a condition (e.g., model accuracy > 0.9) and runs the enclosed steps only if true; `dsl.Else` defines the alternative branch that runs when the condition is false. This directly implements the required logic for running additional evaluation on high accuracy or data augmentation otherwise.
Exam trap
The trap here is that candidates may confuse `dsl.ParallelFor` or `dsl.ExitHandler` with conditional constructs, but `dsl.If` and `dsl.Else` are the only SDK v2 constructs specifically designed for branching based on runtime conditions.
You are running a Vertex AI custom training job with pre-built TensorFlow container. You want to use TPU v3 pods for faster training. Which configuration is required?
TPU machine type must be specified, and code must use TPUStrategy.
Why this answer
TPU training requires specifying the TPU type in the worker pool spec and using tf.distribute.TPUStrategy in code. The pre-built container supports TPUs. Runtime version must include TPU support.
A global retail company uses Vertex AI Recommendations to provide product recommendations on their website. They have a large catalog and millions of users. The initial deployment works well for active users, but they notice that new users (with no purchase history) receive generic recommendations that are not personalized. The company wants to improve the cold-start experience. They have user demographic data (age, location) available at sign-up. Current recommendation model is a collaborative filtering model using the built-in Vertex AI Recommendations. What should the company do to improve personalization for new users?
Exploration helps serve diverse items to new users to learn preferences.
Why this answer
Increasing the user exploration parameter in Vertex AI Recommendations instructs the model to allocate a higher percentage of recommendations to items with less historical data, effectively enabling personalized suggestions for cold-start users based on available demographic signals. This parameter directly controls the balance between exploiting known user-item interactions and exploring new or less-seen items, which is the standard mechanism within Vertex AI's built-in collaborative filtering to address the cold-start problem without requiring a custom model.
Exam trap
Google Cloud often tests the misconception that cold-start problems always require custom models or additional data collection, when in fact built-in platform features like exploration parameters are designed specifically to handle this scenario without custom development.
How to eliminate wrong answers
Option A is wrong because collecting more historical interaction data before showing recommendations does not solve the immediate cold-start problem for new users; it merely delays personalization and contradicts the goal of improving the experience from sign-up. Option B is wrong because disabling recommendations for new users until they have at least 10 interactions is a poor user experience and ignores the fact that Vertex AI Recommendations can leverage user demographic data (age, location) to provide personalized suggestions even without purchase history. Option D is wrong because building a custom two-tower recommendation model using Vertex AI Training is unnecessary and over-engineered; Vertex AI's built-in service already supports exploration parameters and can utilize demographic features for cold-start personalization without requiring custom model development.
You are deploying a PyTorch model on Vertex AI and want to use NVIDIA Triton Inference Server for optimal performance. You have built a custom container with Triton. Which serving configuration should you use?
Vertex AI allows custom containers for prediction; Triton can be included in the container.
Why this answer
Vertex AI supports custom containers for prediction. You can bring your own container with Triton installed, and Vertex AI will deploy it to the endpoint.
A team is operationalizing a machine learning pipeline using Vertex AI. They want to automatically track experiment runs, log model parameters and metrics, and store model artifacts for reproducibility. They also need to capture lineage between pipeline components (e.g., which dataset and hyperparameter tuning job produced a model). Which TWO services should they use together to achieve this? (Choose two.)
Captures lineage between pipeline components, artifacts, and executions.
Why this answer
Vertex AI Experiments provides experiment tracking (parameters, metrics, artifacts). Vertex AI Metadata captures lineage between pipeline components, artifacts, and executions. Together, they enable full reproducibility and traceability.
Match each ML model interpretability method to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Game-theoretic approach to explain feature contributions
Local surrogate model to explain individual predictions
Ranking features by their impact on model output
Shows marginal effect of a feature on predictions
Measures decrease in performance when feature is shuffled
Why these pairings
LIME (Local Interpretable Model-agnostic Explanations) provides local explanations by approximating the model's behavior near a specific prediction using a simpler interpretable model. SHAP (SHapley Additive exPlanations) uses Shapley values from game theory to fairly distribute feature contributions for individual predictions. Partial Dependence Plots (PDP) show the average marginal effect of one or two features on the predicted outcome across the dataset, making it a global method.
Permutation Feature Importance measures the increase in prediction error when a feature's values are randomly shuffled, indicating feature importance globally. Common mistakes: confusing LIME with a global method (B) and misattributing SHAP to visualizing decision trees (D).
Exam trap
The most common trap is confusing local vs global interpretability methods. LIME and SHAP are local, while PDP and Permutation Importance are global.
Refer to the exhibit. A user receives the error shown when trying to upload a model to Vertex AI. What is the most likely cause?
Permission denied errors typically indicate missing IAM roles.
Why this answer
The error message indicates a permission issue during model upload. The user lacks the 'aiplatform.models.upload' permission or the broader 'roles/aiplatform.admin' role on the project. Vertex AI requires these IAM permissions to authorize the upload action, regardless of other resource accessibility.
Exam trap
Google Cloud often tests the distinction between permission errors and resource availability errors, trapping candidates who assume the error is due to a missing bucket or container image rather than IAM misconfiguration.
How to eliminate wrong answers
Option A is wrong because if the container image were inaccessible, the error would typically occur during deployment or prediction, not during the upload step, and the error message would reference image pull failures (e.g., 'ImagePullBackOff'). Option C is wrong because us-central1 is a fully supported region for Vertex AI; the error does not mention region unavailability. Option D is wrong because if the Cloud Storage bucket did not exist, the error would be a 404 or 'bucket not found' message, not a permission-denied error.
An ML engineer has a model trained in Vertex AI and wants to deploy it to an endpoint with autoscaling and traffic splitting for canary testing. They have the model artifact stored in Vertex AI Model Registry with alias 'champion'. What is the correct sequence of steps?
Correct order: model first, then endpoint, then deploy.
Why this answer
The standard sequence: upload model to registry, create endpoint, deploy model to endpoint with traffic split.
Refer to the exhibit. A user attempts to upload a model to Vertex AI Model Registry using the gcloud CLI. The command fails with the error shown. What is the most likely cause?
Error indicates URI must point to a single file.
Why this answer
The error indicates that the `--artifact-uri` flag points to a directory (e.g., `gs://bucket/model/`) rather than a specific model file (e.g., `gs://bucket/model/saved_model.pb`). Vertex AI Model Registry requires a direct path to the model artifact file, not a container directory, because the service needs to locate and register the exact model binary for deployment.
Exam trap
Google Cloud often tests the distinction between a directory path and a file path in cloud CLI commands, exploiting the common mistake of assuming a folder URI is acceptable when the service expects a specific artifact file.
How to eliminate wrong answers
Option A is wrong because us-central1 is a fully supported region for Vertex AI, including Model Registry, and the error message does not indicate a regional restriction. Option B is wrong because the `--container-command` flag is correctly spelled in the command; the error is unrelated to flag spelling. Option D is wrong because the `--container-ports` flag does accept a comma-separated list, but the error message points to the `--artifact-uri` value, not to the ports flag.
A team wants to perform hyperparameter tuning on a Vertex AI custom training job with 100 trials. They require an algorithm that efficiently explores the search space by learning from previous trials. Which algorithm should they select in the study configuration?
Bayesian optimization is the default and most efficient algorithm for hyperparameter tuning.
Why this answer
Vertex AI Vizier provides Bayesian optimization as a default algorithm that builds a probabilistic model of the objective function and selects hyperparameters based on expected improvement. This is more efficient than grid or random search for most scenarios. The ALGORITHM_UNSPECIFIED defaults to Bayesian optimization.
A data scientist wants to use AutoML to classify images of retail products into categories. There are 50 categories and the dataset has 100,000 labelled images. Which Vertex AI AutoML service is most appropriate?
Why this answer
AutoML Vision is designed for image classification, object detection, and segmentation. AutoML Tables is for tabular data, AutoML NLP for text, and AutoML Video for video.
A team is building ML pipelines with Vertex AI. They want to reuse standard pipeline components across teams and enforce governance. What approach should they take?
Vertex AI component registry enables sharing and governance of reusable components.
Why this answer
Standardized pipeline templates (components) in Vertex AI Pipelines allow reuse and governance across teams.
A team deploys a real-time model using a custom container on Vertex AI Prediction. The container is large (5 GB) and cold starts are causing latency spikes. The endpoint is configured with `min_replica_count=0` to reduce cost. The team wants to keep the cost low while reducing cold starts. What is the best approach?
A single warm replica handles traffic immediately while autoscaling adds more.
Why this answer
Setting min_replica_count=1 ensures that at least one replica is always running, eliminating cold starts for most requests. The container is large, but keeping a replica warm avoids the cold start latency. Option B is incorrect because using a prebuilt container may reduce image size but does not directly address cold starts; it might help with download time but not eliminate cold starts.
Option C is incorrect because container memory optimization does not significantly reduce startup time for a large container. Option D is incorrect because provisioning a Persistent Disk (SSD) speeds up image download but does not fully eliminate cold start latency; the replica still needs to initialize.
A company uses Cloud Composer to orchestrate their ML workflows. They have an Airflow DAG that runs a Vertex AI pipeline, then a BigQuery query, then a Dataflow job. The DAG is failing because the Vertex AI pipeline takes longer than the Airflow task timeout. What is the best way to handle this?
The operator can poll the pipeline status, freeing the worker while waiting.
Why this answer
Vertex AI pipelines are asynchronous; the Airflow operator should wait for completion using a sensor or by setting the wait_for_completion parameter. Increasing the task timeout is a workaround but not best practice. Using a separate DAG for the pipeline defeats the purpose of orchestration.
An ML engineer needs to trigger a Vertex AI Pipeline on a recurring schedule, every 24 hours, to retrain a model with the latest data. Which approach should they use to set up this schedule?
Cloud Scheduler can invoke Vertex AI API via HTTP or Pub/Sub to trigger a pipeline on a schedule.
Why this answer
Cloud Scheduler is the native Google Cloud service for cron-based job scheduling. By configuring a Cloud Scheduler job to call the Vertex AI API (e.g., via a HTTP POST to the projects.locations.pipelineJobs.create endpoint), the engineer can trigger a pipeline run every 24 hours. This approach is reliable, supports authentication via OAuth, and integrates directly with Vertex AI Pipelines without requiring additional orchestration code.
Exam trap
The PMLE exam often tests the misconception that Vertex AI Pipelines has a built-in scheduling feature (like a cron parameter in the pipeline definition or a UI schedule button), when in fact scheduling must be implemented using Cloud Scheduler or similar external services.
How to eliminate wrong answers
Option A is wrong because Cloud Tasks is a distributed task queue designed for asynchronous message delivery and retries, not for recurring cron-based scheduling; it would require an additional scheduler to enqueue tasks daily. Option C is wrong because Vertex AI Pipeline definitions do not support a 'schedule' parameter; scheduling is handled externally, not within the pipeline YAML or JSON definition. Option D is wrong because the Vertex AI Pipelines UI does not provide a built-in recurring schedule feature; schedules must be created using Cloud Scheduler or other external tools.
A company trains a model using features from Vertex AI Feature Store. They notice training-serving skew because the feature values used at training time differ from those served online. How should they address this?
This ensures training uses the exact feature values as of the label time, eliminating skew.
Why this answer
Point-in-time correct retrieval ensures that the feature values used in training correspond to the exact same point in time as the label, preventing data leakage and skew.
A data analyst wants to use low-code ML to analyze text data. Which TWO Google Cloud services are appropriate?
Correct: Pre-trained sentiment and entity analysis via API.
Why this answer
Cloud Natural Language API is a low-code ML service that provides pre-trained models for analyzing text, including sentiment analysis, entity recognition, and syntax analysis, without requiring custom model training. It is appropriate for a data analyst who wants to quickly extract insights from text data using simple API calls.
Exam trap
The trap here is that candidates may confuse BigQuery ML's sentiment analysis feature (which is SQL-based and not a dedicated low-code service) with a standalone low-code ML service, or mistakenly think Vertex AI Workbench is low-code when it actually requires coding in Python or other languages.
A company is implementing MLOps with Vertex AI. They need to ensure that only approved models can be deployed to production. Which TWO practices should they adopt?
Aliases provide a clear designation of production models.
Why this answer
Using aliases to designate champion and enabling manual approval in Continuous Evaluation ensures governance.
A machine learning engineer wants to manage multiple model versions and facilitate collaboration across teams. The goal is to track model lineage, versioning, and approvals. Which Vertex AI service should they use?
Model Registry is designed for model versioning, lifecycle management, and collaboration.
Why this answer
Vertex AI Model Registry provides model versioning, approval tracking, and lineage tracking, enabling easy collaboration across teams. Option B is wrong because ML Metadata is a lower-level tool for tracking metadata, not a user-friendly service for model versioning and approvals. Option C is wrong because Feature Store is designed for managing feature data, not models.
Option D is wrong because Vizier is used for hyperparameter tuning, not model management.
A team is implementing CI/CD for ML using Cloud Build. They want to trigger a training pipeline in Vertex AI whenever a new model code is pushed to the main branch of the repository. Which Cloud Build configuration should they use to achieve this?
This correctly limits the trigger to the main branch and uses gcloud to launch the pipeline.
Why this answer
Cloud Build triggers can be configured to fire specifically on pushes to the main branch. The build step then uses the gcloud command to submit a Vertex AI Pipeline job, which directly integrates the CI/CD pipeline with Vertex AI's orchestration. This approach is event-driven, immediate, and requires no additional services or polling.
Exam trap
Google often tests the candidate's understanding that Cloud Build triggers can be scoped to specific branches and that using gcloud directly in a build step is the simplest and most efficient way to invoke Vertex AI Pipelines, rather than introducing unnecessary intermediate services like Cloud Functions or Scheduler.
How to eliminate wrong answers
Option A is wrong because triggering on push to any branch would cause the pipeline to run on feature branches, pull requests, and other non-main branches, leading to unnecessary executions and potential conflicts. Option B is wrong because Cloud Scheduler polling is inefficient, introduces latency, and is not the intended event-driven mechanism; Cloud Build triggers are designed to react to repository events directly. Option C is wrong because using Cloud Functions as an intermediary adds unnecessary complexity and cost; Cloud Build natively supports repository event triggers without requiring a separate compute service.
You run the above command to deploy a new model version to an existing endpoint. After deployment, you observe that the endpoint's previous model version is still receiving 100% of traffic. What is the most likely reason for this?
Correct syntax requires model IDs with percentages.
Why this answer
The traffic-split flag syntax is incorrect. The correct syntax for Vertex AI is --traffic-split=<model-id>=<percentage> for each model. Without correct model IDs, the flag is ignored, and no traffic split is applied, so the existing version continues to receive all traffic.
A developer sees this error when calling the endpoint. What is the most likely cause?
Correct: Model deployment is still initializing.
Why this answer
The question stem does not provide the exact error, but in Vertex AI, when an endpoint returns an error indicating that the model is not ready, the most common cause is that the model is deployed but still in a transient state (e.g., deploying, scaling, updating). Option B captures this scenario. Option C (no model deployed) would typically result in a different error, and other options are less likely.
Thus, without the specific error text, this understanding points to the model being 'deployed but not yet serving' as the most probable cause.
Exam trap
Google Cloud often tests the distinction between 'no model deployed' and 'model deployed but not serving', where candidates confuse a deployment that exists but is not yet ready with a missing deployment.
How to eliminate wrong answers
Option A is wrong because if the model were still in training, the endpoint would not exist or would return a 'ModelNotFound' error, not a 'not serving' error. Option C is wrong because if the endpoint had no deployed model, the error would be 'NoSuchModel' or 'EndpointNotFound', not a serving state error. Option D is wrong because payload size limits (typically 5 MB for SageMaker real-time endpoints) cause a '413 Request Entity Too Large' or 'PayloadTooLarge' error, not a 'not serving' error.
You are building a CI/CD pipeline for an ML model using Cloud Build. When code is pushed to the main branch, you want to automatically build a training image, run a Vertex AI pipeline, and if the model evaluation passes, deploy it to a staging endpoint. Which two components are essential for this CI/CD pipeline?
Pipelines are used to run the ML workflow.
Why this answer
Vertex AI Pipelines is the service that orchestrates the entire ML workflow, including training, evaluation, and conditional deployment logic. In a CI/CD pipeline, you need a managed orchestrator to chain steps like model training, evaluation, and deployment, and Vertex AI Pipelines provides that with its Kubeflow Pipelines-based DAG execution.
Exam trap
Google often tests the distinction between event-driven triggers (Cloud Build trigger on push) and schedule-based triggers (Cloud Scheduler), so candidates mistakenly pick Cloud Scheduler when the requirement is for a code-push event.
You deployed a model to a Vertex AI endpoint with minReplicas=0 and maxReplicas=5. After sending prediction requests, you notice the endpoint takes about 30 seconds to respond initially, but subsequent requests are fast. What is the most likely cause?
Correct. With minReplicas=0, the endpoint scales down to zero, leading to cold start latency.
Why this answer
Vertex AI endpoints with minReplicas=0 scale down to zero when idle. The first request after a period of inactivity triggers a cold start, where the endpoint must provision a new VM instance and load the model, causing a ~30-second delay. Subsequent requests are fast because the instance remains warm and handles them without provisioning overhead.
Exam trap
Google often tests the distinction between cold start latency and persistent performance issues, so candidates may mistakenly attribute the initial delay to model size or network misconfiguration instead of recognizing the intentional scaling-to-zero behavior.
How to eliminate wrong answers
Option A is wrong because a model too large for the machine type would cause persistent latency or errors on every request, not just the first one after idle time. Option C is wrong because VPC Service Controls enforce network boundaries and would block all requests consistently, not just the initial one with a 30-second delay. Option D is wrong because the autoscaling configuration (minReplicas=0, maxReplicas=5) is correct for scaling to zero; the observed behavior is the expected cold start, not a misconfiguration.
An ML engineer is monitoring a Vertex AI Endpoint and notices a spike in 5xx error rates. Which TWO metrics should they examine to diagnose the issue? (Choose 2)
GPU exhaustion can lead to prediction failures.
Why this answer
CPU/GPU utilization can indicate resource exhaustion causing errors. Prediction job failures metric directly shows failed predictions.
A company deploys a training pipeline on Vertex AI using custom containers. The pipeline includes a hyperparameter tuning job that uses Bayesian optimization. After several runs, they observe that the tuning job is not converging and the search space is large. They want to reduce the number of trials while still finding good hyperparameters. Which strategy should they use?
A smaller search space requires fewer trials to find good hyperparameters.
Why this answer
Reducing the search space using prior knowledge directly decreases the number of trials needed. Option A is wrong because increasing parallel trials does not reduce the total number of trials. Option B is wrong because grid search generally requires more trials than Bayesian optimization.
Option C is wrong because early stopping reduces time per trial but does not reduce the number of trials.
Which THREE of the following are recommended practices for model governance and lineage in Vertex AI?
ML Metadata provides automated lineage tracking.
Why this answer
Vertex AI ML Metadata is a fully managed service that automatically tracks artifacts, executions, and contexts across the ML workflow. By enabling it, you create a lineage graph that records every step from data preparation to model deployment, which is essential for auditability and reproducibility. This is a core recommended practice for model governance because it provides an immutable, queryable history of all model-related activities.
Exam trap
Google Cloud often tests the distinction between using native Vertex AI services (like ML Metadata, Experiments, and Model Registry) versus ad-hoc or manual methods (like spreadsheets or custom databases) that lack automated governance and audit trails.
An ML engineer is building a pipeline on Vertex AI Pipelines and wants to pass a dataset artifact from one component to another without incurring additional cost for intermediate storage. How should they define the input and output types?
Artifact types like Dataset are designed for passing data via GCS URIs.
Why this answer
Using the KFP SDK's Dataset artifact type allows Vertex AI Pipelines to manage the data as a lineage-tracked artifact, automatically handling the underlying GCS storage reference without incurring additional intermediate storage costs. The artifact type enables the pipeline to pass the metadata (URI, type, etc.) between components efficiently, leveraging the native artifact management of the KFP SDK.
Exam trap
The trap is that candidates often think 'avoiding additional cost' means 'avoiding any storage,' leading them to choose in-memory passing (Option D) or manual string paths (Option B). In reality, Vertex AI Pipelines uses the same underlying GCS storage that is already part of the pipeline's infrastructure, so the KFP Dataset artifact type incurs no extra cost while enabling lineage tracking.
How to eliminate wrong answers
Option A is wrong because storing data in BigQuery and passing a table reference incurs BigQuery storage and query costs, and it introduces an external dependency that is not necessary for intermediate data passing within a pipeline. Option B is wrong because passing a GCS path as a string manually bypasses the artifact tracking and lineage capabilities of KFP, leading to potential issues with reproducibility and cost management, though it does not directly incur additional storage cost. Option D is wrong because in-memory Python objects cannot be passed between pipeline components that run in separate containers or environments; they would require serialization and storage, defeating the purpose of avoiding intermediate storage costs.
Which TWO options are best practices for building ML pipelines on Vertex AI?
Reusable components allow sharing across pipelines and reduce duplication.
Why this answer
Custom container components allow you to encapsulate reusable logic with specific dependencies, libraries, and environments, enabling consistent execution across pipeline steps. This is a best practice for building modular, maintainable ML pipelines on Vertex AI, as it decouples step logic from the pipeline orchestration and supports versioning and testing.
Exam trap
Google Cloud often tests the misconception that serverless functions like Cloud Functions are suitable for ML pipeline steps, but the trap is that ML steps require persistent state, longer timeouts, and specialized hardware, which Cloud Functions cannot provide.
A startup wants to deploy a small machine learning model for real-time predictions but has a very limited budget. Traffic is minimal and predictable. They want to avoid paying for idle resources. Which serving option is most cost-effective?
Cloud Run scales to zero and charges only when serving requests.
Why this answer
Cloud Run with a custom container is the most cost-effective option because it automatically scales to zero when idle, meaning you pay only when requests come in. For a small model with minimal, predictable traffic, this avoids idle costs entirely. Option A (single Compute Engine VM with GPU) incurs 24/7 cost and is overkill for a small model.
Option B (Vertex AI Batch Prediction) is designed for asynchronous batch jobs, not real-time predictions. Option D (Vertex AI Endpoint with min_replica_count=0) can also scale to zero, but requires additional setup and may involve higher per-request costs compared to Cloud Run; moreover, Cloud Run is simpler and more cost-effective for lightweight models.
A model serving team notices that during a flash sale, a real-time recommendation model experiences sudden spikes in traffic, causing some requests to time out. The endpoint is configured with `min_replica_count=3`, `max_replica_count=10`, and autoscaling metric set to `target_utilization=0.6` on CPU. Despite this, autoscaling is too slow. What change will most improve the autoscaling responsiveness?
Request count directly reflects load and scales more quickly than CPU.
Why this answer
Using 'average request count per replica' directly measures the load on the endpoint, enabling faster autoscaling response to traffic spikes compared to CPU utilization. Option A is wrong because GPU utilization is not relevant unless the model uses GPU, which is not specified. Option B is wrong because increasing target CPU utilization makes scaling slower, not faster.
Option C is wrong because reducing min_replica_count could lead to underprovisioning and does not improve autoscaling responsiveness.
A data scientist needs to train a time-series forecasting model on historical sales data stored in BigQuery to predict future demand. The data has strong seasonal patterns. Which BigQuery ML model type should they use?
ARIMA_PLUS is the correct model for time-series forecasting in BigQuery ML.
Why this answer
ARIMA_PLUS is the correct choice because it is specifically designed for time-series forecasting in BigQuery ML, handling seasonal patterns, trend decomposition, and automatic hyperparameter tuning. It models autoregressive (AR) and moving average (MA) components with seasonal differencing, making it ideal for historical sales data with strong seasonal cycles.
Exam trap
Google often tests the misconception that any regression model (like BOOSTED_TREE_REGRESSOR) can be naively applied to time-series data, ignoring the need for specialized models that handle temporal dependencies and seasonality natively.
How to eliminate wrong answers
Option A is wrong because MATRIX_FACTORIZATION is used for recommendation systems (e.g., collaborative filtering) and cannot model temporal dependencies or seasonality in time-series data. Option B is wrong because BOOSTED_TREE_REGRESSOR is a tree-based ensemble method for regression tasks but does not inherently capture time-series structures like seasonality, trend, or autocorrelation without extensive feature engineering. Option D is wrong because K_MEANS is an unsupervised clustering algorithm that groups data points by similarity and has no mechanism for forecasting future values or modeling sequential patterns.
You are using Vertex AI Vector Search to find nearest neighbors for a recommendation system. Your index is built on 10M embeddings and you need low-latency queries. You want to ensure that adding new embeddings does not require a full index rebuild. Which index type should you use?
Streaming mode allows incremental updates without full index rebuild.
Why this answer
The ANN index with 'streaming' update mode is correct because it supports real-time insertion of new embeddings without requiring a full index rebuild, which is essential for low-latency recommendation systems. This mode uses a separate unsearched buffer for new vectors and periodically merges them into the main index, enabling continuous updates while maintaining query performance.
Exam trap
Google often tests the misconception that all ANN indexes support incremental updates, but only the 'streaming' mode in Vertex AI Vector Search avoids full rebuilds, while 'batch' mode and Tree-AH require periodic full reindexing.
How to eliminate wrong answers
Option A is wrong because a brute-force index computes exact distances against all 10M embeddings, which is computationally prohibitive for low-latency queries and does not support efficient incremental updates. Option C is wrong because the 'batch' update mode requires rebuilding the entire index from scratch when new embeddings are added, violating the requirement to avoid full rebuilds. Option D is wrong because Tree-AH (Asymmetric Hashing) is a specific ANN algorithm that typically requires batch rebuilding and does not natively support streaming updates like the 'streaming' mode in Vertex AI Vector Search.
You are fine-tuning a large language model using Vertex AI Training with spot VMs to reduce cost. Your training job keeps getting preempted, causing delays. Which THREE strategies can help mitigate the impact of preemption?
Allows resuming from last saved state.
Why this answer
Checkpointing saves progress; using a smaller model reduces training time; increasing number of workers allows faster training and recovery. Using dedicated VMs increases cost. Reducing batch size doesn't help with preemption frequency.
An ML engineer has set up Vertex AI Model Monitoring on an endpoint with a sampling rate of 0.1 (10%). They notice that the monitoring job runs hourly but the reported drift metrics seem inconsistent. What is the most likely cause?
10% sampling may result in small sample sizes, causing high variance in drift estimates.
Why this answer
A low sampling rate means only a small fraction of requests are logged for monitoring, which can lead to statistical noise and inconsistent drift metrics. Increasing the sampling rate would improve accuracy.
Which TWO are best practices for implementing a low-code ML solution using Vertex AI AutoML? (Choose 2)
Why A is correct: AutoML optimizes split for best performance.
Why this answer
AutoML's recommended data split (train/validation/test) is designed to prevent overfitting by ensuring the model is evaluated on unseen data. AutoML automatically handles the split ratio (e.g., 80/10/10) and stratification, which is a best practice for low-code ML solutions where manual split logic is error-prone.
Exam trap
Google Cloud often tests the misconception that manual preprocessing (like imputation or normalization) is required for AutoML, when in fact AutoML is designed to handle these steps automatically, and manual intervention can degrade performance or cause errors.
An e-commerce company uses a recommendation model that suggests products based on user browsing history. The model was trained on data from the past year and has high accuracy on the test set. However, after deployment, the click-through rate (CTR) on recommendations is much lower than expected. Which three steps should the data scientist take to diagnose and improve the model? (Choose THREE)
A/B testing validates the model's real-world performance and identifies issues.
Why this answer
An A/B experiment directly measures the model's real-world impact by comparing its CTR against a baseline (e.g., random or popularity-based recommendations). This isolates the model's performance from confounding factors like seasonality or user behavior changes, providing a causal estimate of its effectiveness.
Exam trap
Google Cloud often tests the misconception that high offline accuracy guarantees online success, ignoring that offline metrics can be misleading due to distribution shift, feedback loops, or mismatched optimization objectives (e.g., accuracy vs. CTR).
Refer to the exhibit. A data scientist runs the above BigQuery ML query to create a logistic regression model. After training, the model is evaluated using ML.EVALUATE. The evaluation shows poor performance with high bias. Which action would most likely improve the model's performance?
Polynomial expansions increase model complexity, allowing it to learn non-linear patterns from the data, which addresses high bias.
Why this answer
High bias indicates the model is underfitting the data, meaning it is too simple to capture underlying patterns. Adding polynomial expansions (feature crosses) in the TRANSFORM clause increases model complexity, allowing the logistic regression to learn non-linear decision boundaries, which directly addresses underfitting.
Exam trap
Google Cloud often tests the distinction between bias and variance; the trap here is that candidates might confuse high bias (underfitting) with high variance (overfitting) and incorrectly choose to simplify the model or increase iterations, rather than adding complexity.
How to eliminate wrong answers
Option A is wrong because removing the TRANSFORM clause would discard any feature preprocessing, likely making the model even simpler and worsening high bias. Option B is wrong because changing model_type to 'linear_reg' would switch to a regression task, which is inappropriate for classification and does not address bias in a logistic regression model. Option D is wrong because increasing MAX_ITERATIONS only affects convergence of the optimization algorithm; if the model is too simple (high bias), more iterations will not help it learn more complex patterns.
A data scientist is using Vertex AI Experiments to track training runs. They want to automatically log all hyperparameters, metrics, and model artifacts without modifying their training code. Which approach should they use?
Autologging automatically captures parameters, metrics, and artifacts without modifying training code.
Why this answer
Vertex AI Experiments supports autologging with MLflow integration. By using the MLflow tracking API or Vertex AI's autologging, parameters and metrics are captured without code changes.
A company uses Vertex AI Matching Engine for a product recommendation system. They need to update the index with new product embeddings every hour, but the index is used for online queries with low latency. Which index update strategy should they use?
Streaming updates allow incremental, real-time changes while the index serves queries.
Why this answer
Streaming updates in Vertex AI Matching Engine allow incremental insertion of new embeddings into an existing index without rebuilding it. This satisfies the requirement for hourly updates while maintaining low-latency online queries, as the index remains available and consistent during the update process.
Exam trap
Google often tests the misconception that batch updates are required for consistency or that streaming updates cannot handle frequent changes, leading candidates to choose hybrid or batch approaches when incremental streaming is both sufficient and optimal for low-latency online serving.
How to eliminate wrong answers
Option B is wrong because a hybrid approach with batch for daily full rebuild and streaming for hourly adds unnecessary complexity and cost; streaming updates alone suffice for hourly increments without needing a daily rebuild. Option C is wrong because batch updates replace the entire index, causing downtime or increased latency during the rebuild, which violates the low-latency online query requirement. Option D is wrong because recreating the index from scratch each hour is inefficient, time-consuming, and disrupts query availability, making it unsuitable for real-time serving.
You are using Vertex AI Matching Engine (Vector Search) to serve similarity search for an e-commerce product recommendation system. The index is updated daily with new product embeddings via a batch job. However, you notice that some new products are not appearing in the search results for up to 24 hours. You need to ensure that new products are discoverable within 1 hour of ingestion. What should you do?
Streaming updates allow near real-time index updates, making new products searchable within minutes.
Why this answer
Vertex AI Matching Engine supports streaming updates to the index, which allows new embeddings to be added in near real-time (typically within minutes) without requiring a full batch rebuild. By switching to a streaming update configuration, new product embeddings become searchable within the 1-hour requirement, as the index is updated incrementally as data arrives.
Exam trap
The trap here is that candidates may assume increasing batch frequency (Option C) is sufficient, but they overlook that batch updates in Vertex AI Matching Engine are designed for daily or less frequent rebuilds and cannot guarantee sub-hour freshness due to build and deployment overhead, whereas streaming updates are the intended solution for low-latency index updates.
How to eliminate wrong answers
Option B is wrong because deploying multiple index endpoints with traffic splitting does not address the latency of index updates; it only distributes query load across existing index versions, which still rely on the same batch update schedule. Option C is wrong because increasing the batch job frequency to every 30 minutes still introduces a delay of up to 30 minutes plus processing time, and batch updates are not designed for sub-hour freshness; they also require rebuilding the entire index, which is resource-intensive and may not meet the 1-hour SLA consistently. Option D is wrong because using a brute-force index (exact nearest neighbor) instead of an ANN index does not change the update mechanism; it only affects search accuracy and performance, not the freshness of data ingestion.
An organization wants to trigger a Vertex AI pipeline whenever a new commit is pushed to the main branch of their Cloud Source Repository. The pipeline should retrain and evaluate the model. Which service should they use to detect the push event and start the pipeline?
Cloud Build triggers directly respond to push events and can invoke pipelines.
Why this answer
Cloud Build triggers are designed to automatically invoke a build pipeline in response to events from Cloud Source Repository, such as a push to a specific branch. This allows the organization to directly start a Vertex AI pipeline for retraining and evaluation without additional infrastructure. Cloud Build triggers natively integrate with Cloud Source Repository, making them the simplest and most reliable choice for this event-driven workflow.
Exam trap
This question tests the distinction between event-driven triggers (Cloud Build) and time-based schedulers (Cloud Scheduler, Vertex AI Pipeline schedule), leading candidates to mistakenly choose a polling or cron-based option for an event-driven requirement.
How to eliminate wrong answers
Option A is wrong because Vertex AI Pipeline schedules are time-based (cron) triggers, not event-driven; they cannot detect a Git push event. Option C is wrong because Cloud Scheduler on a short interval would poll for changes, introducing latency and inefficiency, and it does not natively detect push events from Cloud Source Repository. Option D is wrong because while Pub/Sub with a push subscription to a Cloud Function could technically work, it adds unnecessary complexity and an extra compute layer; Cloud Build triggers provide a direct, managed integration without the need for custom code or additional services.
A fintech company needs to deploy a TensorFlow model for real-time fraud detection with strict latency SLO (p99 < 100ms). They expect variable traffic with spikes. They also want to minimize cold-start latency. Which two configurations should they use? (Choose 2)
GPUs can reduce inference latency for deep learning models.
Why this answer
GPU-enabled machine types (e.g., N1 with T4) significantly accelerate TensorFlow model inference, which is critical for meeting the p99 < 100ms latency SLO. GPUs parallelize matrix operations common in deep learning models, reducing per-request latency even under variable traffic spikes.
Exam trap
A common misconception is that scale-to-zero (min_replicas = 0) is always cost-effective, but in latency-sensitive real-time inference, it introduces unacceptable cold-start delays, making baseline warm instances (min_replicas > 0) essential.
A team is fine-tuning a large language model (LLaMA 2) using Vertex AI with a custom container on a multi-node GPU cluster. They need to implement model parallelism to fit the model across multiple GPUs because it does not fit into a single GPU memory. Which distributed training strategy should they use?
Pipeline parallelism is the appropriate model parallelism technique for large models; it must be manually configured.
Why this answer
Model parallelism, specifically pipeline parallelism, splits the model layers across devices. For large models that don't fit on one GPU, this is necessary. Data parallelism (even with ZeRO) still requires the full model on each device.
Vertex AI does not natively support model parallelism; users must configure it manually using frameworks like Megatron-LM or DeepSpeed.
You have deployed a text classification model using Vertex AI Endpoints. The model is performing well, but the operations team wants to be alerted if the endpoint returns an excessive number of HTTP 503 errors. What is the simplest way to achieve this?
Built-in metric directly reflects HTTP errors.
Why this answer
Vertex AI Endpoints automatically export the 'prediction/failed_request_count' metric to Cloud Monitoring, which includes a label for HTTP status codes. By creating an alert on this metric with a filter for 5xx errors, you can directly monitor excessive 503 responses without additional infrastructure or custom code.
Exam trap
The trap here is that candidates often confuse uptime checks (which measure availability from external probes) with metric-based alerts (which track internal error counts), leading them to choose Option A despite its inability to specifically detect 503 errors.
How to eliminate wrong answers
Option A is wrong because Cloud Monitoring uptime checks test endpoint availability from external locations, but they cannot distinguish between 503 errors and other HTTP statuses; they only report overall uptime/downtime, not specific error counts. Option C is wrong because adding a logging statement in a custom prediction routine requires modifying the deployment code and does not leverage the built-in metrics already available in Vertex AI, making it unnecessarily complex and not the simplest approach. Option D is wrong because exporting logs to BigQuery and running scheduled queries introduces significant latency, cost, and operational overhead compared to using the native Cloud Monitoring alert, which provides real-time detection with minimal configuration.
A team deploys a model on Vertex AI that uses a custom prediction routine (CPR) with a dependency on a native library. The container crashes with 'ImportError: libcudart.so.11.0: cannot open shared object file'. How should they resolve this?
Ensures the library is available.
Why this answer
The error 'ImportError: libcudart.so.11.0: cannot open shared object file' indicates that the CUDA runtime library (version 11.0) is missing from the container environment. Since the custom prediction routine (CPR) depends on a native library that requires this CUDA runtime, the correct solution is to build a custom container image that includes the CUDA runtime library. This ensures the shared object is available at runtime, resolving the import error.
Exam trap
Google Cloud often tests the misconception that requesting a GPU machine type automatically provides the necessary CUDA libraries, but in reality, the CUDA runtime must be explicitly included in the container image, as the GPU machine type only provides the hardware and driver, not the user-space libraries.
How to eliminate wrong answers
Option B is wrong because submitting the model for batch prediction does not change the container environment; the same missing CUDA runtime library will cause the same ImportError during batch prediction. Option C is wrong because requesting a GPU machine type for the endpoint provides GPU hardware but does not install the CUDA runtime library into the container; the library must be present in the container image regardless of the underlying hardware. Option D is wrong because using a Vertex AI pre-built container for PyTorch does not guarantee inclusion of the specific CUDA runtime version 11.0 required by the native library; the pre-built container may have a different CUDA version or omit the library entirely.
A data scientist runs a BigQuery ML prediction query and gets a region mismatch error. The model is in the US region, but the new_data table is in the EU region. What is the simplest way to resolve this?
Copying the table to the same region resolves the mismatch with minimal effort.
Why this answer
The simplest fix is to move the new_data table to the same region as the model (US). BigQuery ML requires that the model and the data used for predictions reside in the same multi-region or regional location. Copying the table via the BigQuery UI or CLI (e.g., `bq cp`) is a straightforward, no-code operation that avoids retraining or exporting the model.
Exam trap
The trap here is that candidates may overthink the solution and choose to recreate the model or export/import it, not realizing that the simplest and most efficient fix is to copy the data table to the model's region.
How to eliminate wrong answers
Option A is wrong because recreating the model in the EU region would require retraining the model from scratch, which is unnecessary and time-consuming when a simple data copy resolves the mismatch. Option C is wrong because BigQuery does not support a 'cross-region query' setting; queries are always restricted to a single region or multi-region, and enabling such a feature is not possible. Option D is wrong because exporting and importing a model between regions is more complex and involves additional steps (e.g., using Cloud Storage as an intermediary), whereas copying the table is simpler and directly addresses the region mismatch.
You are using Vertex AI Training to train a model and then automatically deploy the best candidate to a Vertex AI Prediction endpoint via the Vertex AI Model Registry. However, after deployment, you notice that the endpoint returns predictions for the new model, but they are significantly different from the evaluation metrics computed during training. The training scripts used TensorFlow with a serving input function. What is the most likely issue and how would you fix it?
Preprocessing mismatch is a common cause for prediction discrepancies.
Why this answer
The serving input function's preprocessing must match training preprocessing exactly; any mismatch causes prediction errors. Option A is wrong because the model saved includes evaluation metrics. Option C is possible but less likely given the consistency of difference.
Option D is unlikely as numerical precision differences are minimal.
Refer to the exhibit. A data analyst creates a BigQuery ML logistic regression model for churn prediction. The model evaluation shows high precision but low recall. Which change to the model creation would most likely improve recall?
Why C is correct: Lowering the classification threshold using ML.ADJUST_THRESHOLD will classify more instances as positive, increasing true positives and thus recall, at the cost of precision.
Why this answer
Lowering the classification threshold (e.g., from 0.5 to 0.3) will classify more customers as positive (churn), increasing recall (true positives / (true positives + false negatives)). In BigQuery ML, ML.ADJUST_THRESHOLD directly modifies the decision boundary, trading off precision for recall. This is the most direct way to address low recall without altering the model architecture or training data.
Exam trap
Google Cloud often tests the misconception that changing the model type (e.g., to boosted trees) is the default solution for any performance metric issue, when in fact the threshold adjustment is the simplest and most direct way to trade off precision and recall in a logistic regression model.
How to eliminate wrong answers
Option A is wrong because dropping more columns to reduce overfitting would likely harm recall further by removing potentially informative features, and overfitting typically causes high variance, not low recall. Option B is wrong because including customers without churn dates (non-churners) would increase the class imbalance, making the model even more biased toward the majority class and likely reducing recall further. Option D is wrong because changing model_type to 'BOOSTED_TREE_CLASSIFIER' might improve overall performance but does not specifically target the recall issue; it is a model architecture change that could also reduce recall if the class imbalance is not addressed, and it is not the most direct fix for a threshold-related precision-recall trade-off.
Which machine type is most suitable for a Vertex AI endpoint serving a GPU-accelerated model?
You need GPU machine type or attach GPU to N1.
Why this answer
Vertex AI endpoints require a machine type that supports GPU acceleration, and the n1-standard-4 with an attached GPU provides the necessary CPU-to-GPU balance for inference workloads. The n1 series supports GPU attachments via the `accelerator` configuration, enabling CUDA-based model serving, while the e2 series and n1-highmem-8 without GPU cannot leverage GPU acceleration.
Exam trap
A common misconception is that any n1 machine type inherently supports GPU acceleration, but the trap is that the GPU must be explicitly attached via the `accelerator` configuration. Options like n1-highmem-8 or n1-standard-4 without the `accelerator` are CPU-only, failing to meet the requirement for a GPU-accelerated model on Vertex AI.
How to eliminate wrong answers
Option B is wrong because e2-standard-4 does not support GPU attachments; the e2 machine series lacks the PCIe passthrough capability required for NVIDIA GPUs in Vertex AI. Option C is wrong because n1-highmem-8, while part of the n1 series, is a high-memory configuration that is overkill for most GPU-accelerated models and does not include a GPU by default; without an attached GPU, it cannot accelerate model inference. Option D is wrong because n1-standard-4 without an attached GPU is a CPU-only instance that cannot utilize GPU acceleration, making it unsuitable for a GPU-accelerated model endpoint.
You have a Vertex AI endpoint with two deployed models: model A (champion) and model B (challenger). Traffic split is 90:10. You want to gradually increase model B's traffic to 50% over a week. What is the best way to update the traffic split?
Correct. The gcloud command can update traffic percentages.
Why this answer
The `gcloud ai endpoints update` command allows you to directly modify the traffic split of an existing Vertex AI endpoint without redeploying or recreating the endpoint. This is the intended method for gradually shifting traffic between deployed models, as it supports incremental updates to the `--traffic-split` parameter, enabling a controlled rollout from 90:10 to 50:50 over a week.
Exam trap
Google often tests the misconception that you must recreate or redeploy resources to change configuration, when in fact Vertex AI endpoints support live updates via the `update` command, avoiding unnecessary downtime and complexity.
How to eliminate wrong answers
Option A is wrong because `gcloud ai models upload` is used to upload a new model version, not to update traffic split settings on an existing endpoint; traffic splits are managed at the endpoint level, not the model level. Option B is wrong because creating a new endpoint and using a load balancer adds unnecessary complexity and cost, and Vertex AI endpoints natively support traffic splitting without external load balancers. Option D is wrong because deleting and redeploying model B would cause downtime for the 10% of traffic already served by model B, and the traffic split can be updated without redeployment.
Your team has deployed a text classification model on Vertex AI Endpoints. You notice that the model's latency has increased significantly over the last week, but the request rate has remained stable. Which of the following is the most likely cause?
This increases per-request latency without changing request rate.
Why this answer
A computationally expensive preprocessing step directly increases per-request latency on the inference path, even when request rate is stable. Vertex AI Endpoints execute user-provided preprocessing code before model inference, so adding a heavy operation (e.g., large regex, image resizing, or external API call) will linearly increase response time for every prediction.
Exam trap
The trap here is that candidates confuse 'model latency' with 'request rate' and assume any latency increase must be due to scaling issues, ignoring that preprocessing logic changes can dramatically affect per-request performance without altering throughput.
How to eliminate wrong answers
Option A is wrong because a sudden increase in request rate would cause latency to rise, but the question explicitly states request rate has remained stable. Option B is wrong because replacing the model with a larger version requires deploying a new model to the endpoint or updating the endpoint's deployed model; simply replacing the model binary without updating the endpoint's deployment configuration would not change the model served, so latency would not increase. Option D is wrong because a misconfiguration in autoscaling policy (e.g., too few min replicas) would cause latency to increase only when request rate exceeds the current serving capacity, but request rate is stable and autoscaling would have already scaled to match the stable load.
Practice PMLE by domain
Target a specific domain to shore up weak areas.