Free Professional-Machine-Learning-Engineer Practice Test Questions and Answers (2026)

Q: 1

You work as an analyst at a large banking firm. You are developing a robust, scalable ML pipeline to train several regression and classification models. Your primary focus for the pipeline is model interpretability. You want to productionize the pipeline as quickly as possible What should you do?

Options

42 comments in the community discussion

Maya T. 5

Option D

Zoe Z. 3

Option D

Q: 2

You work for a bank You have been asked to develop an ML model that will support loan application decisions. You need to determine which Vertex Al services to include in the workflow You want to track the model's training parameters and the metrics per training epoch. You plan to compare the performance of each version of the model to determine the best model based on your chosen metrics. Which Vertex Al services should you use?

Options

45 comments in the community discussion

Sam 4

Option C. had something like this in a mock and C covered the tracking and comparison parts.

Leo O. 4

Option C is right here. ML Metadata logs the artifacts, Experiments helps with model version comparisons, and TensorBoard shows metrics per epoch. Pretty sure this trio covers exactly what's needed for tracking and evaluation.

Q: 3

You developed a custom model by using Vertex Al to forecast the sales of your company s products based on historical transactional data You anticipate changes in the feature distributions and the correlations between the features in the near future You also expect to receive a large volume of prediction requests You plan to use Vertex Al Model Monitoring for drift detection and you want to minimize the cost. What should you do?

Options

25 comments in the community discussion

Piya O. 1

Option D, but wow Google sure makes you jump through hoops for config tuning. Sampling rate near 0 keeps the bills reasonable even if you have a ton of data, and attributions still give proper drift signals. If budget is the main concern, pretty sure this is it.

Quinn 1

Makes sense to me, D. Lower sampling rate is the biggest saver for cost with lots of requests.

Correct Answer:

Explanation

The best option for using Vertex AI Model Monitoring for drift detection and minimizing the cost is to

use the features and the feature attributions for monitoring, and set a prediction-sampling-rate value

that is closer to 0 than 1. This option allows you to leverage the power and flexibility of Google Cloud

to detect feature drift in the input predict requests for custom models, and reduce the storage and

computation costs of the model monitoring job. Vertex AI Model Monitoring is a service that can

track and compare the results of multiple machine learning runs. Vertex AI Model Monitoring can

monitor the model’s prediction input data for feature skew and drift. Feature drift occurs when the

feature data distribution in production changes over time. If the original training data is not available,

you can enable drift detection to monitor your models for feature drift. Vertex AI Model Monitoring

uses TensorFlow Data Validation (TFDV) to calculate the distributions and distance scores for each

feature, and compares them with a baseline distribution. The baseline distribution is the statistical

distribution of the feature’s values in the training data. If the training data is not available, the

baseline distribution is calculated from the first 1000 prediction requests that the model receives. If

the distance score for a feature exceeds an alerting threshold that you set, Vertex AI Model

Monitoring sends you an email alert. However, if you use a custom model, you can also enable

feature attribution monitoring, which can provide more insights into the feature drift. Feature

attribution monitoring analyzes the feature attributions, which are the contributions of each feature

to the prediction output. Feature attribution monitoring can help you identify the features that have

the most impact on the model performance, and the features that have the most significant drift

over time. Feature attribution monitoring can also help you understand the relationship between the

features and the prediction output, and the correlation between the features1. The prediction-

sampling-rate is a parameter that determines the percentage of prediction requests that are logged

and analyzed by the model monitoring job. Using a lower prediction-sampling-rate can reduce the

storage and computation costs of the model monitoring job, but also the quality and validity of the

data. Using a lower prediction-sampling-rate can introduce sampling bias and noise into the data,

and make the model monitoring job miss some important features or patterns of the data. However,

using a higher prediction-sampling-rate can increase the storage and computation costs of the model

monitoring job, and also the amount of data that needs to be processed and analyzed. Therefore,

there is a trade-off between the prediction-sampling-rate and the cost and accuracy of the model

monitoring job, and the optimal prediction-sampling-rate depends on the business objective and the

data characteristics2. By using the features and the feature attributions for monitoring, and setting a

prediction-sampling-rate value that is closer to 0 than 1, you can use Vertex AI Model Monitoring for

drift detection and minimize the cost.

The other options are not as good as option D, for the following reasons:

Option A: Using the features for monitoring and setting a monitoring-frequency value that is higher

than the default would not enable feature attribution monitoring, and could increase the cost of the

model monitoring job. The monitoring-frequency is a parameter that determines how often the

model monitoring job analyzes the logged prediction requests and calculates the distributions and

distance scores for each feature. Using a higher monitoring-frequency can increase the frequency

and timeliness of the model monitoring job, but also the computation costs of the model monitoring

job. Moreover, using the features for monitoring would not enable feature attribution monitoring,

which can provide more insights into the feature drift and the model performance1.

Option B: Using the features for monitoring and setting a prediction-sampling-rate value that is

closer to 1 than 0 would not enable feature attribution monitoring, and could increase the cost of the

model monitoring job. The prediction-sampling-rate is a parameter that determines the percentage

of prediction requests that are logged and analyzed by the model monitoring job. Using a higher

prediction-sampling-rate can increase the quality and validity of the data, but also the storage and

computation costs of the model monitoring job. Moreover, using the features for monitoring would

not enable feature attribution monitoring, which can provide more insights into the feature drift and

the model performance12.

Option C: Using the features and the feature attributions for monitoring and setting a monitoring-

frequency value that is lower than the default would enable feature attribution monitoring, but

could reduce the frequency and timeliness of the model monitoring job. The monitoring-frequency is

a parameter that determines how often the model monitoring job analyzes the logged prediction

requests and calculates the distributions and distance scores for each feature. Using a lower

monitoring-frequency can reduce the computation costs of the model monitoring job, but also the

frequency and timeliness of the model monitoring job. This can make the model monitoring job less

responsive and effective in detecting and alerting the feature drift1.

Reference:

Preparing for Google Cloud Certification: Machine Learning Engineer, Course 3: Production ML

Systems, Week 4: Evaluation

Google Cloud Professional Machine Learning Engineer Exam Guide, Section 3: Scaling ML models in

production, 3.3 Monitoring ML models in production

Official Google Cloud Certified Professional Machine Learning Engineer Study Guide, Chapter 6:

Production ML Systems, Section 6.3: Monitoring ML Models

Using Model Monitoring

Understanding the score threshold slider

Q: 4

You work for a pet food company that manages an online forum Customers upload photos of their pets on the forum to share with others About 20 photos are uploaded daily You want to automatically and in near real time detect whether each uploaded photo has an animal You want to prioritize time and minimize cost of your application development and deployment What should you do?

Options

29 comments in the community discussion

Grace M. 1

I keep going back and forth but leaning mostly A. Cloud Vision API does the job with almost zero setup, which is what they're asking for. If it was about custom accuracy or animal breeds, I'd reconsider. Not positive but seems safest for time/cost. Anyone see a case where D would truly be faster?

Luke 1

A , Cloud Vision API does the heavy lifting with almost no setup. No model training or data labeling needed, so you save loads of time and money. Pretty sure that's what they're looking for here.

Correct Answer:

Explanation

Cloud Vision API is a service that allows you to analyze images using pre-trained machine learning

models1. You can use Cloud Vision API to perform various tasks, such as face detection, text

extraction, logo recognition, and object localization1. Object localization is a feature that allows you

to detect multiple objects in an image and draw bounding boxes around them2. You can also get the

labels and confidence scores for each detected object2.

By sending user-submitted images to the Cloud Vision API, you can use object localization to identify

all objects in the image and compare the results against a list of animals. You can use

the OBJECT_LOCALIZATION feature type in the AnnotateImageRequest to request object

localization3. You can then use the localizedObjectAnnotations field in

the AnnotateImageResponse to get the list of detected objects, their labels, and their confidence

scores. You can compare the labels with a predefined list of animals, such as dogs, cats, birds, etc.,

and determine whether the image has an animal or not.

This option is the best for your scenario, because it allows you to automatically and in near real time

detect whether each uploaded photo has an animal, without requiring any manual labeling, model

training, or model deployment. You can also prioritize time and minimize cost of your application

development and deployment, as you can use the Cloud Vision API as a ready-to-use service, without

needing any machine learning expertise or infrastructure.

The other options are not suitable for your scenario, because they either require manual labeling,

model training, or model deployment, which would increase the time and cost of your application

development and deployment, or they use object detection models, which are more complex and

computationally expensive than object localization models, and are not necessary for your simple

task of detecting whether an image has an animal or not.

Reference:

Cloud Vision API | Google Cloud

Object localization | Cloud Vision API | Google Cloud

AnnotateImageRequest | Cloud Vision API | Google Cloud

[AnnotateImageResponse | Cloud Vision API | Google Cloud]

Q: 5

You recently developed a deep learning model using Keras, and now you are experimenting with different training strategies. First, you trained the model using a single GPU, but the training process was too slow. Next, you distributed the training across 4 GPUs using tf.distribute.MirroredStrategy (with no other changes), but you did not observe a decrease in training time. What should you do?

Options

37 comments in the community discussion

Parker K. 4

Option D is what I'd pick. With multiple GPUs and MirroredStrategy, you usually need to up the batch size so each GPU can get enough data to process in parallel, otherwise training time won't drop. Happened to me before in practice, but open if anyone disagrees.

Jack Q. 2

Probably D. If you just switch to MirroredStrategy but keep the same (small) batch size, each GPU isn't used efficiently so no real speed gain. Increasing the batch size lets GPUs process more data in parallel. Not 100% sure if dataset sharding is a trap here, but D is what I see in similar questions.

Correct Answer:

Explanation

Option A is incorrect because distributing the dataset with

tf.distribute.Strategy.experimental_distribute_dataset is not the most effective way to decrease the

training time. This method allows you to distribute your dataset across multiple devices or machines,

by creating a tf.data.Dataset instance that can be iterated over in parallel1. However, this option may

not improve the training time significantly, as it does not change the amount of data or computation

that each device or machine has to process. Moreover, this option may introduce additional

overhead or complexity, as it requires you to handle the data sharding, replication, and

synchronization across the devices or machines1.

Option B is incorrect because creating a custom training loop is not the easiest way to decrease the

training time. A custom training loop is a way to implement your own logic for training your model,

by using low-level TensorFlow APIs, such as tf.GradientTape, tf.Variable, or tf.function2. A custom

training loop may give you more flexibility and control over the training process, but it also requires

more effort and expertise, as you have to write and debug the code for each step of the training loop,

such as computing the gradients, applying the optimizer, or updating the metrics2. Moreover, a

custom training loop may not improve the training time significantly, as it does not change the

amount of data or computation that each device or machine has to process.

Option C is incorrect because using a TPU with tf.distribute.TPUStrategy is not a valid way to decrease

the training time. A TPU (Tensor Processing Unit) is a custom hardware accelerator designed for high-

performance ML workloads3. A tf.distribute.TPUStrategy is a distribution strategy that allows you to

distribute your training across multiple TPUs, by creating a tf.distribute.TPUStrategy instance that can

be used with high-level TensorFlow APIs, such as Keras4. However, this option is not feasible, as

Vertex AI Training does not support TPUs as accelerators for custom training jobs5. Moreover, this

option may require significant code changes, as TPUs have different requirements and limitations

than GPUs.

Option D is correct because increasing the batch size is the best way to decrease the training time.

The batch size is a hyperparameter that determines how many samples of data are processed in each

iteration of the training loop. Increasing the batch size may reduce the training time, as it reduces the

number of iterations needed to train the model, and it allows each device or machine to process

more data in parallel. Increasing the batch size is also easy to implement, as it only requires changing

a single hyperparameter. However, increasing the batch size may also affect the convergence and the

accuracy of the model, so it is important to find the optimal batch size that balances the trade-off

between the training time and the model performance.

Reference:

tf.distribute.Strategy.experimental_distribute_dataset

Custom training loop

TPU overview

tf.distribute.TPUStrategy

Vertex AI Training accelerators

[TPU programming model]

[Batch size and learning rate]

[Keras overview]

[tf.distribute.MirroredStrategy]

[Vertex AI Training overview]

[TensorFlow overview]

Q: 6

You need to train a computer vision model that predicts the type of government ID present in a given image using a GPU-powered virtual machine on Compute Engine. You use the following parameters: • Optimizer: SGD • Image shape 224x224 • Batch size 64 • Epochs 10 • Verbose 2 During training you encounter the following error: ResourceExhaustedError: out of Memory (oom) when allocating tensor. What should you do?

Options

37 comments in the community discussion

Robin 1

You’re right, batch size is the main thing affecting GPU memory during training. B

Neha J. 1

B tbh, since batch size eats up a lot of GPU memory fast. D might be tempting but you'd lose image detail for IDs, so not ideal here. Saw a similar question in practice and B was correct. Trap is thinking optimizer or learning rate helps!

Correct Answer:

Explanation

A ResourceExhaustedError: out of memory (OOM) when allocating tensor is an error that occurs

when the GPU runs out of memory while trying to allocate memory for a tensor. A tensor is a multi-

dimensional array of numbers that represents the data or the parameters of a machine learning

model. The size and shape of a tensor depend on various factors, such as the input data, the model

architecture, the batch size, and the optimization algorithm1.

For the use case of training a computer vision model that predicts the type of government ID present

in a given image using a GPU-powered virtual machine on Compute Engine, the best option to

resolve the error is to reduce the batch size. The batch size is a parameter that determines how many

input examples are processed at a time by the model. A larger batch size can improve the model’s

accuracy and stability, but it also requires more memory and computation. A smaller batch size can

reduce the memory and computation requirements, but it may also affect the model’s performance

and convergence2.

By reducing the batch size, the GPU can allocate less memory for each tensor, and avoid running out

of memory. Reducing the batch size can also speed up the training process, as the GPU can process

more batches in parallel. However, reducing the batch size too much may also have some drawbacks,

such as increasing the noise and variance of the gradient updates, and slowing down the

convergence of the model. Therefore, the optimal batch size should be chosen based on the trade-off

between memory, computation, and performance3.

The other options are not as effective as option B, because they are not directly related to the

memory allocation of the GPU. Option A, changing the optimizer, may affect the speed and quality of

the optimization process, but it may not reduce the memory usage of the model. Option C, changing

the learning rate, may affect the convergence and stability of the model, but it may not reduce the

memory usage of the model. Option D, reducing the image shape, may reduce the size of the input

tensor, but it may also reduce the quality and resolution of the image, and affect the model’s

accuracy. Therefore, option B, reducing the batch size, is the best answer for this question.

Reference:

ResourceExhaustedError: OOM when allocating tensor with shape - Stack Overflow

How does batch size affect model performance and training time? - Stack Overflow

How to choose an optimal batch size for training a neural network? - Stack Overflow

Q: 7

Your data science team has requested a system that supports scheduled model retraining, Docker containers, and a service that supports autoscaling and monitoring for online prediction requests. Which platform components should you choose for this system?

Options

44 comments in the community discussion

Logan M. 5

B. not A. App Engine doesn't fully support containers or ML monitoring, pretty sure B is the right stack here.

LiamM 3

Makes sense to go with B since only Vertex AI Prediction supports autoscale and Docker containers together.

Correct Answer:

Explanation

Option A is incorrect because Vertex AI Pipelines and App Engine do not meet all the requirements of

the system. Vertex AI Pipelines is a service that allows you to create, run, and manage ML workflows

using TensorFlow Extended (TFX) components or custom components1. App Engine is a service that

allows you to build and deploy scalable web applications using standard or flexible

environments2. However, App Engine does not support Docker containers in the standard

environment, and does not provide a dedicated service for online prediction and monitoring of ML

models3.

Option B is correct because Vertex AI Pipelines, Vertex AI Prediction, and Vertex AI Model Monitoring

meet all the requirements of the system. Vertex AI Prediction is a service that allows you to deploy

and serve ML models for online or batch prediction, with support for autoscaling and custom

containers4. Vertex AI Model Monitoring is a service that allows you to monitor the performance and

fairness of your deployed models, and get alerts for any issues or anomalies5.

Option C is incorrect because Cloud Composer, BigQuery ML, and Vertex AI Prediction do not meet

all the requirements of the system. Cloud Composer is a service that allows you to create, schedule,

and manage workflows using Apache Airflow. BigQuery ML is a service that allows you to create and

use ML models within BigQuery using SQL queries. However, BigQuery ML does not support custom

containers, and Vertex AI Prediction does not support scheduled model retraining or model

monitoring.

Option D is incorrect because Cloud Composer, Vertex AI Training with custom containers, and App

Engine do not meet all the requirements of the system. Vertex AI Training is a service that allows you

to train ML models using built-in algorithms or custom containers. However, Vertex AI Training does

not support online prediction or model monitoring, and App Engine does not support Docker

containers in the standard environment or online prediction and monitoring of ML models3.

Reference:

Vertex AI Pipelines overview

App Engine overview

Choosing an App Engine environment

Vertex AI Prediction overview

Vertex AI Model Monitoring overview

[Cloud Composer overview]

[BigQuery ML overview]

[BigQuery ML limitations]

[Vertex AI Training overview]

Q: 8

Your team has a model deployed to a Vertex Al endpoint You have created a Vertex Al pipeline that automates the model training process and is triggered by a Cloud Function. You need to prioritize keeping the model up-to-date, but also minimize retraining costs. How should you configure retraining'?

Options

44 comments in the community discussion

Drew I. 5

D . Feature drift is directly tied to data changes that impact model accuracy, so retraining only triggers when it's actually needed. Costs stay low since you're not retraining just on a set schedule or for random anomalies. Agree?

Jamie I. 3

Option D not B. Only D triggers on real feature drift so you don't retrain for no reason.

Q: 9

You are developing a Kubeflow pipeline on Google Kubernetes Engine. The first step in the pipeline is to issue a query against BigQuery. You plan to use the results of that query as the input to the next step in your pipeline. You want to achieve this in the easiest way possible. What should you do?

Options

35 comments in the community discussion

Quinn B. 2

D here, but honestly C looks ok too if you prefer custom stuff. Pretty sure D is quicker for most cases though.

Robin F. 1

Correct Answer:

Explanation

Kubeflow is an open source platform for developing, orchestrating, deploying, and running scalable

and portable machine learning workflows on Kubernetes. Kubeflow Pipelines is a component of

Kubeflow that allows you to build and manage end-to-end machine learning pipelines using a

graphical user interface or a Python-based domain-specific language (DSL). Kubeflow Pipelines can

help you automate and orchestrate your machine learning workflows, and integrate with various

Google Cloud services and tools1

One of the Google Cloud services that you can use with Kubeflow Pipelines is BigQuery, which is a

serverless, scalable, and cost-effective data warehouse that allows you to run fast and complex

queries on large-scale data. BigQuery can help you analyze and prepare your data for machine

learning, and store and manage your machine learning models2

To execute a query against BigQuery as the first step in your Kubeflow pipeline, and use the results of

that query as the input to the next step in your pipeline, the easiest way to do that is to use the

BigQuery Query Component, which is a pre-built component that you can find in the Kubeflow

Pipelines repository on GitHub. The BigQuery Query Component allows you to run a SQL query on

BigQuery, and output the results as a table or a file. You can use the component’s URL to load the

component into your pipeline, and specify the query and the output parameters. You can then use

the output of the component as the input to the next step in your pipeline, such as a data processing

or a model training step3

The other options are not as easy or feasible. Using the BigQuery console to execute your query and

then save the query results into a new BigQuery table is not a good idea, as it does not integrate with

your Kubeflow pipeline, and requires manual intervention and duplication of data. Writing a Python

script that uses the BigQuery API to execute queries against BigQuery is not ideal, as it requires

writing custom code and handling authentication and error handling. Using the Kubeflow Pipelines

DSL to create a custom component that uses the Python BigQuery client library to execute queries is

not optimal, as it requires creating and packaging a Docker container image for the component, and

testing and debugging the component.

Reference: 1: Kubeflow Pipelines overview 2: BigQuery overview 3: BigQuery Query Component

Q: 10

You are experimenting with a built-in distributed XGBoost model in Vertex AI Workbench user- managed notebooks. You use BigQuery to split your data into training and validation sets using the following queries: CREATE OR REPLACE TABLE ‘myproject.mydataset.training‘ AS (SELECT * FROM ‘myproject.mydataset.mytable‘ WHERE RAND() < 0.8); CREATE OR REPLACE TABLE ‘myproject.mydataset.validation‘ AS (SELECT * FROM ‘myproject.mydataset.mytable‘ WHERE RAND() < 0.2); After training the model, you achieve an area under the receiver operating characteristic curve (AUC ROC) value of 0.8, but after deploying the model to production, you notice that your model performance has dropped to an AUC ROC value of 0.65. What problem is most likely occurring?

Options

31 comments in the community discussion

CaseyU 6

Wait, but doesn’t the RAND() approach here mean some records show up in both training and validation tables, not necessarily every record? Feels like partial overlap (option C) is the bigger issue, especially since D would only ever happen if you got super unlucky with a tiny dataset. Am I missing something?

Riley J. 5

C . D is a trap, it's not every record that's duplicated, it's just some overlap because RAND() is used twice per row. I've seen this come up on similar questions.

Q: 11

You work at a subscription-based company. You have trained an ensemble of trees and neural networks to predict customer churn, which is the likelihood that customers will not renew their yearly subscription. The average prediction is a 15% churn rate, but for a particular customer the model predicts that they are 70% likely to churn. The customer has a product usage history of 30%, is located in New York City, and became a customer in 1997. You need to explain the difference between the actual prediction, a 70% churn rate, and the average prediction. You want to use Vertex Explainable AI. What should you do?

Options

14 comments in the community discussion

Zoe 3

B . Some folks go for C but integrated gradients is mostly for images and text, not tabular data like churn. Easy trap there.

Sofia O. 1

Sampled Shapley values (B) is what Vertex Explainable AI uses for feature attribution on tabular data. Integrated gradients aren't supported in this case, that's more for images or text. Pretty sure B is the right move here.

Correct Answer:

Explanation

Option A is incorrect because training local surrogate models to explain individual predictions is not a

feature of Vertex Explainable AI, but rather a general technique for interpreting black-box

models. Local surrogate models are simpler models that approximate the behavior of the original

model around a specific input1.

Option B is correct because configuring sampled Shapley explanations on Vertex Explainable AI is a

way to explain the difference between the actual prediction and the average prediction for a given

input. Sampled Shapley explanations are based on the Shapley value, which is a game-theoretic

concept that measures how much each feature contributes to the prediction2. Vertex Explainable AI

supports sampled Shapley explanations for tabular data, such as customer churn3.

Option C is incorrect because configuring integrated gradients explanations on Vertex Explainable AI

is not suitable for explaining the difference between the actual prediction and the average prediction

for a given input. Integrated gradients explanations are based on the idea of computing the gradients

of the prediction with respect to the input features along a path from a baseline input to the actual

input4. Vertex Explainable AI supports integrated gradients explanations for image and text data, but

not for tabular data3.

Option D is incorrect because measuring the effect of each feature as the weight of the feature

multiplied by the feature value is not a valid way to explain the difference between the actual

prediction and the average prediction for a given input. This method assumes that the model is linear

and additive, which is not the case for an ensemble of trees and neural networks. Moreover, this

method does not account for the interactions between features or the non-linearity of the model5.

Reference:

Local surrogate models

Shapley value

Vertex Explainable AI overview

Integrated gradients

Feature importance

Q: 12

You are developing ML models with Al Platform for image segmentation on CT scans. You frequently update your model architectures based on the newest available research papers, and have to rerun training on the same dataset to benchmark their performance. You want to minimize computation costs and manual intervention while having version control for your code. What should you do?

Options

9 comments in the community discussion

Sanjay 3

C . Cloud Build triggers off code pushes so you get auto retraining and solid version control, fits the use case way better than Composer polling or doing stuff manually. Anyone disagree? Maybe I'm missing a Composer trick but don't think so.

Sam M. 1

Gotta be C here. Cloud Build with Source Repos gives you real version control and automates the retrain as soon as code's updated, saves time and cuts costs. Composer (D) doesn't track code changes directly. Pretty sure C matches what's needed but open if someone sees a use case for D.

Correct Answer:

Explanation

Developing ML models with AI Platform for image segmentation on CT scans requires a lot of

computation and experimentation, as image segmentation is a complex and challenging task that

involves assigning a label to each pixel in an image. Image segmentation can be used for various

medical applications, such as tumor detection, organ segmentation, or lesion localization1

To minimize the computation costs and manual intervention while having version control for the

code, one should use Cloud Build linked with Cloud Source Repositories to trigger retraining when

new code is pushed to the repository. Cloud Build is a service that executes your builds on Google

Cloud Platform infrastructure. Cloud Build can import source code from Cloud Source Repositories,

Cloud Storage, GitHub, or Bitbucket, execute a build to your specifications, and produce artifacts

such as Docker containers or Java archives2

Cloud Build allows you to set up automated triggers that start a build when changes are pushed to a

source code repository. You can configure triggers to filter the changes based on the branch, tag, or

file path3

Cloud Source Repositories is a service that provides fully managed private Git repositories on Google

Cloud Platform. Cloud Source Repositories allows you to store, manage, and track your code using

the Git version control system. You can also use Cloud Source Repositories to connect to other

Google Cloud services, such as Cloud Build, Cloud Functions, or Cloud Run4

To use Cloud Build linked with Cloud Source Repositories to trigger retraining when new code is

pushed to the repository, you need to do the following steps:

Create a Cloud Source Repository for your code, and push your code to the repository. You can use

the Cloud SDK, Cloud Console, or Cloud Source Repositories API to create and manage your

repository5

Create a Cloud Build trigger for your repository, and specify the build configuration and the trigger

settings. You can use the Cloud SDK, Cloud Console, or Cloud Build API to create and manage your

trigger.

Specify the steps of the build in a YAML or JSON file, such as installing the dependencies, running the

tests, building the container image, and submitting the training job to AI Platform. You can also use

the Cloud Build predefined or custom build steps to simplify your build configuration.

Push your new code to the repository, and the trigger will start the build automatically. You can

monitor the status and logs of the build using the Cloud SDK, Cloud Console, or Cloud Build API.

The other options are not as easy or feasible. Using Cloud Functions to identify changes to your code

in Cloud Storage and trigger a retraining job is not ideal, as Cloud Functions has limitations on the

memory, CPU, and execution time, and does not provide a user interface for managing and tracking

your builds. Using the gcloud command-line tool to submit training jobs on AI Platform when you

update your code is not optimal, as it requires manual intervention and does not leverage the

benefits of Cloud Build and its integration with Cloud Source Repositories. Creating an automated

workflow in Cloud Composer that runs daily and looks for changes in code in Cloud Storage using a

sensor is not relevant, as Cloud Composer is mainly designed for orchestrating complex workflows

across multiple systems, and does not provide a version control system for your code.

Reference: 1: Image segmentation 2: Cloud Build overview 3: Creating and managing build

triggers 4: Cloud Source Repositories overview 5: Quickstart: Create a repository : [Quickstart: Create

a build trigger] : [Configuring builds] : [Viewing build results]

Q: 13

You work for the AI team of an automobile company, and you are developing a visual defect detection model using TensorFlow and Keras. To improve your model performance, you want to incorporate some image augmentation functions such as translation, cropping, and contrast tweaking. You randomly apply these functions to each training batch. You want to optimize your data processing pipeline for run time and compute resources utilization. What should you do?

Options

10 comments in the community discussion

LiamB 5

A. Official TensorFlow docs or practice labs usually push for tf.Data pipeline for this type of augmentation.

Piya I. 5

A . Had something like this in a mock and tf.Data pipelines are way more efficient for augmentation since they use native TensorFlow ops and support optimizations like parallel mapping and prefetching. Keras generators are decent for small stuff but don't scale or integrate as well, especially with distributed training

Correct Answer:

Explanation

The best option for optimizing the data processing pipeline for run time and compute resources

utilization is to embed the augmentation functions dynamically in the tf.Data pipeline. This option

has the following advantages:

It allows the data augmentation to be performed on the fly, without creating or storing additional

copies of the data. This saves storage space and reduces the data transfer time.

It leverages the parallelism and performance of the tf.Data API, which can efficiently apply the

augmentation functions to multiple batches of data in parallel, using multiple CPU cores or GPU

devices. The tf.Data API also supports various optimization techniques, such as caching, prefetching,

and autotuning, to improve the data processing speed and reduce the latency.

It integrates seamlessly with the TensorFlow and Keras models, which can consume the tf.Data

datasets as inputs for training and evaluation. The tf.Data API also supports various data formats,

such as images, text, audio, and video, and various data sources, such as files, databases, and web

services.

The other options are less optimal for the following reasons:

Option B: Embedding the augmentation functions dynamically as part of Keras generators introduces

some limitations and overhead. Keras generators are Python generators that yield batches of data for

training or evaluation. However, Keras generators are not compatible with the tf.distribute API,

which is used to distribute the training across multiple devices or machines. Moreover, Keras

generators are not as efficient or scalable as the tf.Data API, as they run on a single Python thread

and do not support parallelism or optimization techniques.

Option C: Using Dataflow to create all possible augmentations, and store them as TFRecords

introduces additional complexity and cost. Dataflow is a fully managed service that runs Apache

Beam pipelines for data processing and transformation. However, using Dataflow to create all

possible augmentations requires generating and storing a large number of augmented images, which

can consume a lot of storage space and incur storage and network costs. Moreover, using Dataflow to

create the augmentations requires writing and deploying a separate Dataflow pipeline, which can be

tedious and time-consuming.

Option D: Using Dataflow to create the augmentations dynamically per training run, and stage them

as TFRecords introduces additional complexity and latency. Dataflow is a fully managed service that

runs Apache Beam pipelines for data processing and transformation. However, using Dataflow to

create the augmentations dynamically per training run requires running a Dataflow pipeline every

time the model is trained, which can introduce latency and delay the training process. Moreover,

using Dataflow to create the augmentations requires writing and deploying a separate Dataflow

pipeline, which can be tedious and time-consuming.

Reference:

[tf.data: Build TensorFlow input pipelines]

[Image augmentation | TensorFlow Core]

[Dataflow documentation]

Q: 14

You recently deployed a scikit-learn model to a Vertex Al endpoint You are now testing the model on live production traffic While monitoring the endpoint. you discover twice as many requests per hour than expected throughout the day You want the endpoint to efficiently scale when the demand increases in the future to prevent users from experiencing high latency What should you do?

Options

7 comments in the community discussion

Alex X. 1

B . Setting minReplicaCount handles the baseline traffic and lets autoscaling keep up when demand jumps. Seen similar advice for Vertex AI endpoints before, seems like the best fit here.

Sara

Option C could work too. Raising target utilization in autoscalingMetricSpecs can help use resources more efficiently during spikes, and I saw similar advice in some official guides and Vertex AI practice labs. Not 100 percent sure though, maybe B is safer?

Correct Answer:

Explanation

The best option for scaling a Vertex AI endpoint efficiently when the demand increases in the future,

using a scikit-learn model that is deployed to a Vertex AI endpoint and tested on live production

traffic, is to configure an appropriate minReplicaCount value based on expected baseline traffic. This

option allows you to leverage the power and simplicity of Vertex AI to automatically scale your

endpoint resources according to the traffic patterns. Vertex AI is a unified platform for building and

deploying machine learning solutions on Google Cloud. Vertex AI can deploy a trained model to an

online prediction endpoint, which can provide low-latency predictions for individual instances.

Vertex AI can also provide various tools and services for data analysis, model development, model

deployment, model monitoring, and model governance. A minReplicaCount value is a parameter

that specifies the minimum number of replicas that the endpoint must always have, regardless of the

load. A minReplicaCount value can help you ensure that the endpoint has enough resources to

handle the expected baseline traffic, and avoid high latency or errors. By configuring an appropriate

minReplicaCount value based on expected baseline traffic, you can scale your endpoint efficiently

when the demand increases in the future. You can set the minReplicaCount value when you deploy

the model to the endpoint, or update it later. Vertex AI will automatically scale up or down the

number of replicas within the range of the minReplicaCount and maxReplicaCount values, based on

the target utilization percentage and the autoscaling metric1.

The other options are not as good as option B, for the following reasons:

Option A: Deploying two models to the same endpoint and distributing requests among them evenly

would not allow you to scale your endpoint efficiently when the demand increases in the future, and

could increase the complexity and cost of the deployment process. A model is a resource that

represents a machine learning model that you can use for prediction. A model can have one or more

versions, which are different implementations of the same model. A model version can help you

experiment and iterate on your model, and improve the model performance and accuracy. An

endpoint is a resource that provides the service endpoint (URL) you use to request the prediction. An

endpoint can have one or more deployed models, which are instances of model versions that are

associated with physical resources. A deployed model can help you serve online predictions with low

latency, and scale up or down based on the traffic. By deploying two models to the same endpoint

and distributing requests among them evenly, you can create a load balancing mechanism that can

distribute the traffic across the models, and reduce the load on each model. However, deploying two

models to the same endpoint and distributing requests among them evenly would not allow you to

scale your endpoint efficiently when the demand increases in the future, and could increase the

complexity and cost of the deployment process. You would need to write code, create and configure

the two models, deploy the models to the same endpoint, and distribute the requests among them

evenly. Moreover, this option would not use the autoscaling feature of Vertex AI, which can

automatically adjust the number of replicas based on the traffic patterns, and provide various

benefits, such as optimal resource utilization, cost savings, and performance improvement2.

Option C: Setting the target utilization percentage in the autoscalingMetricSpecs configuration to a

higher value would not allow you to scale your endpoint efficiently when the demand increases in

the future, and could cause errors or poor performance. A target utilization percentage is a

parameter that specifies the desired utilization level of each replica. A target utilization percentage

can affect the speed and accuracy of the autoscaling process. A higher target utilization percentage

can help you reduce the number of replicas, but it can also cause high latency, low throughput, or

resource exhaustion. By setting the target utilization percentage in the autoscalingMetricSpecs

configuration to a higher value, you can increase the utilization level of each replica, and save some

resources. However, setting the target utilization percentage in the autoscalingMetricSpecs

configuration to a higher value would not allow you to scale your endpoint efficiently when the

demand increases in the future, and could cause errors or poor performance. You would need to

write code, create and configure the autoscalingMetricSpecs, and set the target utilization

percentage to a higher value. Moreover, this option would not ensure that the endpoint has enough

resources to handle the expected baseline traffic, which could cause high latency or errors1.

Option D: Changing the model’s machine type to one that utilizes GPUs would not allow you to scale

your endpoint efficiently when the demand increases in the future, and could increase the

complexity and cost of the deployment process. A machine type is a parameter that specifies the

type of virtual machine that the prediction service uses for the deployed model. A machine type can

affect the speed and accuracy of the prediction process. A machine type that utilizes GPUs can help

you accelerate the computation and processing of the prediction, and handle more prediction

requests at the same time. By changing the model’s machine type to one that utilizes GPUs, you can

improve the prediction performance and efficiency of your model. However, changing the model’s

machine type to one that utilizes GPUs would not allow you to scale your endpoint efficiently when

the demand increases in the future, and could increase the complexity and cost of the deployment

process. You would need to write code, create and configure the model, deploy the model to the

endpoint, and change the machine type to one that utilizes GPUs. Moreover, this option would not

use the autoscaling feature of Vertex AI, which can automatically adjust the number of replicas based

on the traffic patterns, and provide various benefits, such as optimal resource utilization, cost

savings, and performance improvement2.

Reference:

Configure compute resources for prediction | Vertex AI | Google Cloud

Deploy a model to an endpoint | Vertex AI | Google Cloud

Q: 15

You developed a custom model by using Vertex Al to predict your application's user churn rate You are using Vertex Al Model Monitoring for skew detection The training data stored in BigQuery contains two sets of features - demographic and behavioral You later discover that two separate models trained on each set perform better than the original model You need to configure a new model mentioning pipeline that splits traffic among the two models You want to use the same prediction-sampling-rate and monitoring-frequency for each model You also want to minimize management effort What should you do?

Options

6 comments in the community discussion

Ajay M. 4

Makes sense to go with D since deploying both models to the same endpoint cuts down on management overhead. Using separate training tables fits how the models need to be trained, and the monitoring-config-from param covers model IDs. Pretty sure that's what Google expects here. Agree?

Morgan 1

Its D, since both models can share an endpoint and a single monitoring job if you use the right monitoring-config settings. This fits what I've seen in exam reports and official doc reviews. Splitting up the data into separate tables is key for proper training. Official documentation and Google's own sample pipelines a

Q: 16

You need to develop an image classification model by using a large dataset that contains labeled images in a Cloud Storage Bucket. What should you do?

Options

5 comments in the community discussion

Luna 4

C . AutoML with managed datasets is built for this exact use case and no code needed. B is tempting but only if you need custom pipelines or advanced logic, which the question doesn't mention. Anyone else see this on any practice sets?

Alex A. 1

Its C if "best" means lowest effort, but is there a code requirement that would make A or B more suitable?

Correct Answer:

Explanation

The best option for developing an image classification model by using a large dataset that contains

labeled images in a Cloud Storage bucket is to import the labeled images as a managed dataset in

Vertex AI and use AutoML to train the model. This option allows you to leverage the power and

simplicity of Google Cloud to create and deploy a high-quality image classification model with

minimal code and configuration. Vertex AI is a unified platform for building and deploying machine

learning solutions on Google Cloud. Vertex AI can create a managed dataset from a Cloud Storage

bucket that contains labeled images, which can be used to train an AutoML model. AutoML is a

service that can automatically build and optimize machine learning models for various tasks, such as

image classification, object detection, natural language processing, and tabular data analysis.

AutoML can handle the complex aspects of machine learning, such as feature engineering, model

architecture, hyperparameter tuning, and model evaluation. AutoML can also evaluate, deploy, and

monitor the image classification model, and provide online or batch predictions. By using Vertex AI

and AutoML, users can develop an image classification model by using a large dataset with ease and

efficiency.

The other options are not as good as option C, for the following reasons:

Option A: Using Vertex AI Pipelines with the Kubeflow Pipelines SDK to create a pipeline that reads

the images from Cloud Storage and trains the model would require more skills and steps than using

Vertex AI and AutoML. Vertex AI Pipelines is a service that can orchestrate machine learning

workflows using Vertex AI. Vertex AI Pipelines can run preprocessing and training steps on custom

Docker images, and evaluate, deploy, and monitor the machine learning model. Kubeflow Pipelines

SDK is a Python library that can create and run pipelines on Vertex AI Pipelines or on Kubeflow, an

open-source platform for machine learning on Kubernetes. However, using Vertex AI Pipelines and

Kubeflow Pipelines SDK would require writing code, building Docker images, defining pipeline

components and steps, and managing the pipeline execution and artifacts. Moreover, Vertex AI

Pipelines and Kubeflow Pipelines SDK are not specialized for image classification, and users would

need to use other libraries or frameworks, such as TensorFlow or PyTorch, to build and train the

image classification model.

Option B: Using Vertex AI Pipelines with TensorFlow Extended (TFX) to create a pipeline that reads

the images from Cloud Storage and trains the model would require more skills and steps than using

Vertex AI and AutoML. TensorFlow Extended (TFX) is a framework that can create and run end-to-end

machine learning pipelines on TensorFlow, a popular library for building and training deep learning

models. TFX can preprocess the data, train and evaluate the model, validate and push the model,

and serve the model for online or batch predictions. However, using Vertex AI Pipelines and TFX

would require writing code, building Docker images, defining pipeline components and steps, and

managing the pipeline execution and artifacts. Moreover, TFX is not optimized for image

classification, and users would need to use other libraries or tools, such as TensorFlow Data

Validation, TensorFlow Transform, and TensorFlow Hub, to handle the image data and the model

architecture.

Option D: Converting the image dataset to a tabular format using Dataflow, loading the data into

BigQuery, and using BigQuery ML to train the model would not handle the image data properly and

could result in a poor model performance. Dataflow is a service that can create scalable and reliable

pipelines to process large volumes of data from various sources. Dataflow can preprocess the data by

using Apache Beam, a programming model for defining and executing data processing workflows.

BigQuery is a serverless, scalable, and cost-effective data warehouse that can perform fast and

interactive queries on large datasets. BigQuery ML is a service that can create and train machine

learning models by using SQL queries on BigQuery. However, converting the image data to a tabular

format would lose the spatial and semantic information of the images, which are essential for image

classification. Moreover, BigQuery ML is not specialized for image classification, and users would

need to use other tools or techniques, such as feature hashing, embedding, or one-hot encoding, to

handle the categorical features.

Q: 17

You have created a Vertex Al pipeline that includes two steps. The first step preprocesses 10 TB data completes in about 1 hour, and saves the result in a Cloud Storage bucket The second step uses the processed data to train a model You need to update the model's code to allow you to test different algorithms You want to reduce pipeline execution time and cost, while also minimizing pipeline changes What should you do?

Options

12 comments in the community discussion

Owen 1

Not sure about that, pretty sure A is better here. If you add a pipeline parameter and step to decide whether to preprocess or not, you can skip preprocessing if data hasn't changed and just go straight to training. That way, you're not redoing heavy ETL work every time, and the change is minimal. But open to other

Casey K.

Caching on Vertex AI lets you reuse the output from the preprocessing step, so you only rerun it if the inputs or code change. That way, when testing different algorithms in training, you skip the big ETL re-do and save both time and compute cost. Pretty sure D makes the most sense here since it keeps pipeline changes

Correct Answer:

Explanation

The best option for reducing pipeline execution time and cost, while also minimizing pipeline

changes, is to enable caching for the pipeline job, and disable caching for the model training step.

This option allows you to leverage the power and simplicity of Vertex AI Pipelines to reuse the output

of the data preprocessing step, and avoid unnecessary recomputation. Vertex AI Pipelines is a service

that can orchestrate machine learning workflows using Vertex AI. Vertex AI Pipelines can run

preprocessing and training steps on custom Docker images, and evaluate, deploy, and monitor the

machine learning model. Caching is a feature of Vertex AI Pipelines that can store and reuse the

output of a pipeline step, and skip the execution of the step if the input parameters and the code

have not changed. Caching can help you reduce the pipeline execution time and cost, as you do not

need to re-run the same step with the same input and code. Caching can also help you minimize the

pipeline changes, as you do not need to add or remove any pipeline steps or parameters. By enabling

caching for the pipeline job, and disabling caching for the model training step, you can create a

Vertex AI pipeline that includes two steps. The first step preprocesses 10 TB data, completes in about

1 hour, and saves the result in a Cloud Storage bucket. The second step uses the processed data to

train a model. You can update the model’s code to allow you to test different algorithms, and run the

pipeline job with caching enabled. The pipeline job will reuse the output of the data preprocessing

step from the cache, and skip the execution of the step. The pipeline job will run the model training

step with the updated code, and disable the caching for the step. This way, you can reduce the

pipeline execution time and cost, while also minimizing pipeline changes1.

The other options are not as good as option D, for the following reasons:

Option A: Adding a pipeline parameter and an additional pipeline step, depending on the parameter

value, the pipeline step conducts or skips data preprocessing and starts model training, would

require more skills and steps than enabling caching for the pipeline job, and disabling caching for the

model training step. A pipeline parameter is a variable that can be used to control the input or

output of a pipeline step. A pipeline parameter can help you customize the pipeline logic and

behavior, and experiment with different values. An additional pipeline step is a new instance of a

pipeline component that can perform a part of the pipeline workflow, such as data preprocessing or

model training. An additional pipeline step can help you extend the pipeline functionality and

complexity, and handle different scenarios. However, adding a pipeline parameter and an additional

pipeline step, depending on the parameter value, the pipeline step conducts or skips data

preprocessing and starts model training, would require more skills and steps than enabling caching

for the pipeline job, and disabling caching for the model training step. You would need to write code,

define the pipeline parameter, create the additional pipeline step, implement the conditional logic,

and compile and run the pipeline. Moreover, this option would not reuse the output of the data

preprocessing step from the cache, but rather from the Cloud Storage bucket, which can increase the

data transfer and access costs1.

Option B: Creating another pipeline without the preprocessing step, and hardcoding the

preprocessed Cloud Storage file location for model training, would require more skills and steps than

enabling caching for the pipeline job, and disabling caching for the model training step. A pipeline

without the preprocessing step is a pipeline that only includes the model training step, and uses the

preprocessed data from the Cloud Storage bucket as the input. A pipeline without the preprocessing

step can help you avoid running the data preprocessing step every time, and reduce the pipeline

execution time and cost. However, creating another pipeline without the preprocessing step, and

hardcoding the preprocessed Cloud Storage file location for model training, would require more skills

and steps than enabling caching for the pipeline job, and disabling caching for the model training

step. You would need to write code, create a new pipeline, remove the preprocessing step, hardcode

the Cloud Storage file location, and compile and run the pipeline. Moreover, this option would not

reuse the output of the data preprocessing step from the cache, but rather from the Cloud Storage

bucket, which can increase the data transfer and access costs. Furthermore, this option would create

another pipeline, which can increase the maintenance and management costs1.

Option C: Configuring a machine with more CPU and RAM from the compute-optimized machine

family for the data preprocessing step, would not reduce the pipeline execution time and cost, while

also minimizing pipeline changes, but rather increase the pipeline execution cost and complexity. A

machine with more CPU and RAM from the compute-optimized machine family is a virtual machine

that has a high ratio of CPU cores to memory, and can provide high performance and scalability for

compute-intensive workloads. A machine with more CPU and RAM from the compute-optimized

machine family can help you optimize the data preprocessing step, and reduce the pipeline execution

time. However, configuring a machine with more CPU and RAM from the compute-optimized

machine family for the data preprocessing step, would not reduce the pipeline execution time and

cost, while also minimizing pipeline changes, but rather increase the pipeline execution cost and

complexity. You would need to write code, configure the machine type parameters for the data

preprocessing step, and compile and run the pipeline. Moreover, this option would increase the

pipeline execution cost, as machines with more CPU and RAM from the compute-optimized machine

family are more expensive than machines with less CPU and RAM from other machine

families. Furthermore, this option would not reuse the output of the data preprocessing step from

the cache, but rather re-run the data preprocessing step every time, which can increase the pipeline

execution time and cost1.

Reference:

Preparing for Google Cloud Certification: Machine Learning Engineer, Course 3: Production ML

Systems, Week 3: MLOps

Google Cloud Professional Machine Learning Engineer Exam Guide, Section 3: Scaling ML models in

production, 3.2 Automating ML workflows

Official Google Cloud Certified Professional Machine Learning Engineer Study Guide, Chapter 6:

Production ML Systems, Section 6.4: Automating ML Workflows

Vertex AI Pipelines

Caching

Pipeline parameters

Machine types

Q: 18

You are training an ML model on a large dataset. You are using a TPU to accelerate the training process You notice that the training process is taking longer than expected. You discover that the TPU is not reaching its full capacity. What should you do?

Options

6 comments in the community discussion

Ryan I. 5

D . When the TPU isn't maxed out, increasing batch size lets it process more data in parallel and really use all those TPU cores. Pretty sure that's what Google wants here.

Drew K.

Isn't there a catch though? If the model has ops that aren't batch friendly or you're bottlenecked on data input, even cranking up batch size (D) won't help. Anyone else seen real-world TPUs not scale for this reason?

Correct Answer:

Explanation

The best option for training an ML model on a large dataset, using a TPU to accelerate the training

process, and discovering that the TPU is not reaching its full capacity, is to increase the batch size.

This option allows you to leverage the power and simplicity of TPUs to train your model faster and

more efficiently. A TPU is a custom-developed application-specific integrated circuit (ASIC) that can

accelerate machine learning workloads. A TPU can provide high performance and scalability for

various types of models, such as linear regression, logistic regression, k-means clustering, matrix

factorization, and deep neural networks. A TPU can also support various tools and frameworks, such

as TensorFlow, PyTorch, and JAX. A batch size is a parameter that specifies the number of training

examples in one forward/backward pass. A batch size can affect the speed and accuracy of the

training process. A larger batch size can help you utilize the parallel processing power of the TPU, and

reduce the communication overhead between the TPU and the host CPU. A larger batch size can also

help you avoid overfitting, as it can reduce the variance of the gradient updates. By increasing the

batch size, you can train your model on a large dataset faster and more efficiently, and make full use

of the TPU capacity1.

The other options are not as good as option D, for the following reasons:

Option A: Increasing the learning rate would not help you utilize the parallel processing power of the

TPU, and could cause errors or poor performance. A learning rate is a parameter that controls how

much the model is updated in each iteration. A learning rate can affect the speed and accuracy of the

training process. A larger learning rate can help you converge faster, but it can also cause instability,

divergence, or oscillation. By increasing the learning rate, you may not be able to find the optimal

solution, and your model may perform poorly on the validation or test data2.

Option B: Increasing the number of epochs would not help you utilize the parallel processing power

of the TPU, and could increase the complexity and cost of the training process. An epoch is a measure

of the number of times all of the training examples are used once in the training process. An epoch

can affect the speed and accuracy of the training process. A larger number of epochs can help you

learn more from the data, but it can also cause overfitting, underfitting, or diminishing returns. By

increasing the number of epochs, you may not be able to improve the model performance

significantly, and your training process may take longer and consume more resources3.

Option C: Decreasing the learning rate would not help you utilize the parallel processing power of the

TPU, and could slow down the training process. A learning rate is a parameter that controls how

much the model is updated in each iteration. A learning rate can affect the speed and accuracy of the

training process. A smaller learning rate can help you find a more precise solution, but it can also

cause slow convergence or local minima. By decreasing the learning rate, you may not be able to

reach the optimal solution in a reasonable time, and your training process may take longer2.

Reference:

Preparing for Google Cloud Certification: Machine Learning Engineer, Course 2: ML Models and

Architectures, Week 1: Introduction to ML Models and Architectures

Google Cloud Professional Machine Learning Engineer Exam Guide, Section 2: Architecting ML

solutions, 2.1 Designing ML models

Official Google Cloud Certified Professional Machine Learning Engineer Study Guide, Chapter 4: ML

Models and Architectures, Section 4.1: Designing ML Models

Use TPUs

Triose phosphate utilization and beyond: from photosynthesis to end …

Cloud TPU performance guide

Google TPU: Architecture and Performance Best Practices - Run

Q: 19

You are an ML engineer at a bank. You have developed a binary classification model using AutoML Tables to predict whether a customer will make loan payments on time. The output is used to approve or reject loan requests. One customer’s loan request has been rejected by your model, and the bank’s risks department is asking you to provide the reasons that contributed to the model’s decision. What should you do?

Options

7 comments in the community discussion

BenC 1

A , because the question is about explaining a single customer's rejection, not overall model behavior. B and C are about global stats, which isn't what risk wants here. D sounds like a trap, way too manual. Open to other views if I'm missing something.

Reese R.

Makes sense to me, it's A. Local feature importance gives the why for that customer's outcome, not just the model overall.

Correct Answer:

Explanation

Option A is correct because using local feature importance from the predictions is the best way to

provide the reasons that contributed to the model’s decision for a specific customer’s loan

request. Local feature importance is a measure of how much each feature affects the prediction for a

given instance, relative to the average prediction for the dataset1. AutoML Tables provides local

feature importance values for each prediction, which can be accessed using the Vertex AI SDK for

Python or the Cloud Console2. By using local feature importance, you can explain why the model

rejected the loan request based on the customer’s data.

Option B is incorrect because using the correlation with target values in the data summary page is

not a good way to provide the reasons that contributed to the model’s decision for a specific

customer’s loan request. The correlation with target values is a measure of how much each feature is

linearly related to the target variable for the entire dataset, not for a single instance3. The data

summary page in AutoML Tables shows the correlation with target values for each feature, as well as

other statistics such as mean, standard deviation, and histogram4. However, these statistics are not

useful for explaining the model’s decision for a specific customer, as they do not account for the

interactions between features or the non-linearity of the model.

Option C is incorrect because using the feature importance percentages in the model evaluation

page is not a good way to provide the reasons that contributed to the model’s decision for a specific

customer’s loan request. The feature importance percentages are a measure of how much each

feature affects the overall accuracy of the model for the entire dataset, not for a single instance5. The

model evaluation page in AutoML Tables shows the feature importance percentages for each feature,

as well as other metrics such as precision, recall, and confusion matrix. However, these metrics are

not useful for explaining the model’s decision for a specific customer, as they do not reflect the

individual contribution of each feature for a given prediction.

Option D is incorrect because varying features independently to identify the threshold per feature

that changes the classification is not a feasible way to provide the reasons that contributed to the

model’s decision for a specific customer’s loan request. This method involves changing the value of

one feature at a time, while keeping the other features constant, and observing how the prediction

changes. However, this method is not practical, as it requires making multiple prediction requests,

and may not capture the interactions between features or the non-linearity of the model.

Reference:

Local feature importance

Getting local feature importance values

Correlation with target values

Data summary page

Feature importance percentages

[Model evaluation page]

[Varying features independently]

Q: 20

You are working on a Neural Network-based project. The dataset provided to you has columns with different ranges. While preparing the data for model training, you discover that gradient optimization is having difficulty moving weights to a good solution. What should you do?

Options

8 comments in the community discussion

Ethan

Definitely B. Normalizing gets all your inputs on similar scales which makes gradient descent work way better, especially with neural nets. Without normalization, bigger ranged features can totally mess up convergence. Pretty sure this is what Google's looking for here but open to debate if anyone disagrees.

Piya P.

Yeah, normalization is the move here. B is correct since getting all features on a similar scale will help gradient descent optimize smoothly. Seen this in a couple similar practice sets, pretty sure that's the intended fix.

Question 1 of 20

Premium Access Includes