PMLE practice questions 91–100

1. Question 91 · 364 in bank

   You work for a bank with strict data governance requirements. You recently implemented a custom model to detect fraudulent transactions. You want your training code to download internal data by using an API endpoint hosted in your project’s network. You need the data to be accessed in the most secure way, while mitigating the risk of data exfiltration. What should you do?

   • AEnable VPC Service Controls for peerings, and add Vertex AI to a service perimeter.
   • BCreate a Cloud Run endpoint as a proxy to the data. Use Identity and Access Management (IAM) authentication to secure access to the endpoint from the training job.
   • CConfigure VPC Peering with Vertex AI, and specify the network of the training job.
   • DDownload the data to a Cloud Storage bucket before calling the training job.

   Show answer

   Answer: A

   Explanation

   My Answer B: Creating a Cloud Run endpoint as a proxy to the data allows you to control access to the internal data through an API endpoint. By using Identity and Access Management (IAM) authentication, you can enforce strict access controls, ensuring that only authorized entities (such as your training job) can access the data. This approach helps mitigate the risk of data exfiltration by providing a secure and controlled access point to the internal data. - Option A: may help control access within Google Cloud Platform services, but it does not directly address securing access to the internal data through an API endpoint. - Option C: is more about network configurations and does not provide a solution for securely accessing the internal data through an API endpoint. - Option D: involves transferring the data to a Cloud Storage bucket, which might introduce additional security risks during the data transfer process.

   Source: Adapted from community discussion — guilhermebutzke

   References

   • Google Cloud documentation
   • Google Cloud documentation

   Next question

2. Question 92 · 364 in bank

   You are deploying a new version of a model to a production Vertex Al endpoint that is serving traffic. You plan to direct all user traffic to the new model. You need to deploy the model with minimal disruption to your application. What should you do?

   • A1. Create a new endpoint 2. Create a new model. Set it as the default version. Upload the model to Vertex AI Model Registry 3. Deploy the new model to the new endpoint 4. Update Cloud DNS to point to the new endpoint
   • B1. Create a new endpoint 2. Create a new model. Set the parentModel parameter to the model ID of the currently deployed model and set it as the default version. Upload the model to Vertex AI Model Registry 3. Deploy the new model to the new endpoint, and set the new model to 100% of the traffic.
   • C1. Create a new model. Set the parentModel parameter to the model ID of the currently deployed model. Upload the model to Vertex AI Model Registry. 2. Deploy the new model to the existing endpoint, and set the new model to 100% of the traffic
   • D1. Create a new model. Set it as the default version. Upload the model to Vertex AI Model Registry 2. Deploy the new model to the existing endpoint

   Show answer

   Answer: C

   Explanation

   Minimal Downtime: By deploying the new model to the existing endpoint, you avoid any service interruptions caused by creating and switching to a completely new endpoint. Versioning: Setting the parentModel parameter allows you to track the lineage of your models and easily revert to the previous version if needed. Traffic Control: Vertex AI lets you control traffic allocation between different versions of a model deployed on the same endpoint. Setting the new model to 100% traffic directs all user requests to the new version.

   Source: Adapted from community discussion — fitri001

   Next question

3. Question 93 · 364 in bank

   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?

   • AIncrease the learning rate
   • BIncrease the number of epochs
   • CDecrease the learning rate
   • DIncrease the batch size

   Show answer

   Answer: D

   Explanation

   A common reason for underutilized TPUs is a small batch size. TPUs are designed for high throughput, and feeding them small batches doesn't leverage their full potential. Try increasing the batch size while monitoring model performance. A larger batch size can lead to faster training but might also affect accuracy. Experiment to find the optimal balance.

   Source: Adapted from community discussion — fitri001

   References

   • Google Cloud documentation

   Next question

4. Question 94 · 364 in bank

   You work for a retail company. You have a managed tabular dataset in Vertex AI that contains sales data from three different stores. The dataset includes several features, such as store name and sale timestamp. You want to use the data to train a model that makes sales predictions for a new store that will open soon. You need to split the data between the training, validation, and test sets. What approach should you use to split the data?

   • AUse Vertex AI manual split, using the store name feature to assign one store for each set
   • BUse Vertex AI default data split
   • CUse Vertex AI chronological split, and specify the sales timestamp feature as the time variable
   • DUse Vertex AI random split, assigning 70% of the rows to the training set, 10% to the validation set, and 20% to the test set

   Show answer

   Answer: C

   Explanation

   Time-Series Data: Your sales data has timestamps, indicating it's time-series data. A chronological split considers the order of the timestamps, ensuring the model is trained on historical trends. Predicting for New Store: Since you want to predict sales for a new store, a chronological split is better than a random split (option D) which wouldn't prioritize recent trends. Vertex AI Functionality: Vertex AI's chronological split functionality is specifically designed for time-series data and leverages the timestamp feature you provide to separate data for training, validation, and testing.

   Source: Adapted from community discussion — fitri001

   References

   • Google Cloud documentation

   Next question

5. Question 95 · 364 in bank

   You have developed a BigQuery ML model that predicts customer chum, and deployed the model to Vertex AI Endpoints. You want to automate the retraining of your model by using minimal additional code when model feature values change. You also want to minimize the number of times that your model is retrained to reduce training costs. What should you do?

   • A1 Enable request-response logging on Vertex AI Endpoints 2. Schedule a TensorFlow Data Validation job to monitor prediction drift 3. Execute model retraining if there is significant distance between the distributions
   • B1. Enable request-response logging on Vertex AI Endpoints 2. Schedule a TensorFlow Data Validation job to monitor training/serving skew 3. Execute model retraining if there is significant distance between the distributions
   • C1. Create a Vertex AI Model Monitoring job configured to monitor prediction drift 2. Configure alert monitoring to publish a message to a Pub/Sub queue when a monitoring alert is detected 3. Use a Cloud Function to monitor the Pub/Sub queue, and trigger retraining in BigQuery
   • D1. Create a Vertex AI Model Monitoring job configured to monitor training/serving skew 2. Configure alert monitoring to publish a message to a Pub/Sub queue when a monitoring alert is detected 3. Use a Cloud Function to monitor the Pub/Sub queue, and trigger retraining in BigQuery

   Show answer

   Answer: C

   Explanation

   After reconsidering, I think it is C: - No need to use TF to enable model monitoring as stated here: https://cloud.google.com/vertex-ai/docs/model-monitoring/using-model-monitoring (even if it uses it under the hood: https://cloud.google.com/vertex-ai/docs/model-monitoring/overview#calculating-skew-and-drift) - The problem speaks about alerting of model feature changes, which happens over time, and uses a baseline of the historical production data -> prediction skew. (if the problem specified that it changes compared to training data, then it would be training-skew) (https://cloud.google.com/vertex-ai/docs/model-monitoring/monitor-explainable-ai#feature_attribution_training-serving_skew_and_prediction_drift)

   Source: Adapted from community discussion — b1a8fae

   References

   • Google Cloud documentation
   • Google Cloud documentation
   • Google Cloud documentation

   Next question

6. Question 96 · 364 in bank

   You have been tasked with deploying prototype code to production. The feature engineering code is in PySpark and runs on Dataproc Serverless. The model training is executed by using a Vertex AI custom training job. The two steps are not connected, and the model training must currently be run manually after the feature engineering step finishes. You need to create a scalable and maintainable production process that runs end-to-end and tracks the connections between steps. What should you do?

   • ACreate a Vertex AI Workbench notebook. Use the notebook to submit the Dataproc Serverless feature engineering job. Use the same notebook to submit the custom model training job. Run the notebook cells sequentially to tie the steps together end-to-end.
   • BCreate a Vertex AI Workbench notebook. Initiate an Apache Spark context in the notebook and run the PySpark feature engineering code. Use the same notebook to run the custom model training job in TensorFlow. Run the notebook cells sequentially to tie the steps together end-to-end.
   • CUse the Kubeflow pipelines SDK to write code that specifies two components: - The first is a Dataproc Serverless component that launches the feature engineering job - The second is a custom component wrapped in the create_custom_training_job_from_component utility that launches the custom model training job Create a Vertex AI Pipelines job to link and run both components
   • DUse the Kubeflow pipelines SDK to write code that specifies two components - The first component initiates an Apache Spark context that runs the PySpark feature engineering code - The second component runs the TensorFlow custom model training code Create a Vertex AI Pipelines job to link and run both components.

   Show answer

   Answer: C

   Explanation

   A. Vertex AI Workbench notebook: While notebooks are a good way to prototype workflows, they are not ideal for production due to limitations in scalability and version control. Running everything sequentially also doesn't allow for potential parallelization of tasks. B. Apache Spark context in notebook: Similar to A, notebooks are not ideal for production. Additionally, running the model training with TensorFlow within the notebook ties the process to a specific framework, making it less flexible. D. Kubeflow pipelines with Spark context: This option gets close, but it's unnecessary to initiate a Spark context within the first component. Dataproc Serverless already handles the Spark environment for running PySpark code.

   Source: Adapted from community discussion — fitri001

   Next question

7. Question 97 · 364 in bank

   You recently deployed a scikit-learn model to a Vertex AI 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?

   • ADeploy two models to the same endpoint, and distribute requests among them evenly
   • BConfigure an appropriate minReplicaCount value based on expected baseline traffic
   • CSet the target utilization percentage in the autoscailngMetricSpecs configuration to a higher value
   • DChange the model’s machine type to one that utilizes GPUs

   Show answer

   Answer: B

   Explanation

   Autoscaling based on baseline: Vertex AI endpoints have built-in autoscaling capabilities. Setting a minReplicaCount ensures there are always at least that many replicas running, handling the baseline traffic efficiently. When demand increases above the baseline, autoscaling will automatically provision additional replicas to maintain performance. Efficient scaling: This approach allows the endpoint to scale up smoothly as traffic increases, preventing sudden spikes in latency for users. Targeted resource allocation: Unlike option A (deploying multiple models), this method avoids redundant resources when traffic is low. Additionally, option D (switching to GPUs) might be unnecessary if the bottleneck isn't processing power.

   Source: Adapted from community discussion — fitri001

   Next question

8. Question 98 · 364 in bank

   You work at a bank. You have a custom tabular ML model that was provided by the bank’s vendor. The training data is not available due to its sensitivity. The model is packaged as a Vertex AI Model serving container, which accepts a string as input for each prediction instance. In each string, the feature values are separated by commas. You want to deploy this model to production for online predictions and monitor the feature distribution over time with minimal effort. What should you do?

   • A1. Upload the model to Vertex AI Model Registry, and deploy the model to a Vertex AI endpoint 2. Create a Vertex AI Model Monitoring job with feature drift detection as the monitoring objective, and provide an instance schema
   • B1. Upload the model to Vertex AI Model Registry, and deploy the model to a Vertex AI endpoint 2. Create a Vertex AI Model Monitoring job with feature skew detection as the monitoring objective, and provide an instance schema
   • C1. Refactor the serving container to accept key-value pairs as input format 2. Upload the model to Vertex AI Model Registry, and deploy the model to a Vertex AI endpoint 3. Create a Vertex AI Model Monitoring job with feature drift detection as the monitoring objective.
   • D1. Refactor the serving container to accept key-value pairs as input format 2. Upload the model to Vertex AI Model Registry, and deploy the model to a Vertex AI endpoint 3. Create a Vertex AI Model Monitoring job with feature skew detection as the monitoring objective

   Show answer

   Answer: A

   Explanation

   A. Minimum effort -> ditch refactoring (hopefully not needed) Training data not available -> can't be skew, so it must be drift

   Source: Adapted from community discussion — b1a8fae

   Next question

9. Question 99 · 364 in bank

   You are implementing a batch inference ML pipeline in Google Cloud. The model was developed using TensorFlow and is stored in SavedModel format in Cloud Storage. You need to apply the model to a historical dataset containing 10 TB of data that is stored in a BigQuery table. How should you perform the inference?

   • AExport the historical data to Cloud Storage in Avro format. Configure a Vertex AI batch prediction job to generate predictions for the exported data
   • BImport the TensorFlow model by using the CREATE MODEL statement in BigQuery ML. Apply the historical data to the TensorFlow model
   • CExport the historical data to Cloud Storage in CSV format. Configure a Vertex AI batch prediction job to generate predictions for the exported data
   • DConfigure a Vertex AI batch prediction job to apply the model to the historical data in BigQuery

   Show answer

   Answer: B

   Explanation

   The choice is between B and D, both good BUT: Importing and making batch predictions is quite straightforward in BQ ML https://cloud.google.com/bigquery/docs/making-predictions-with-imported-tensorflow-models if not pre-processing needed on the data. If we need a more complete pipeline I'd chose D, but the tables need partitioning (100GB is the limit in Vertex AI): https://cloud.google.com/vertex-ai/docs/tabular-data/classification-regression/get-batch-predictions#input_data_requirements

   Source: Adapted from community discussion — edoo

   References

   • Google Cloud documentation
   • Google Cloud documentation
   • Google Cloud documentation

   Next question

10. Question 100 · 364 in bank

    You have written unit tests for a Kubeflow Pipeline that require custom libraries. You want to automate the execution of unit tests with each new push to your development branch in Cloud Source Repositories. What should you do?

    • AWrite a script that sequentially performs the push to your development branch and executes the unit tests on Cloud Run.
    • BUsing Cloud Build, set an automated trigger to execute the unit tests when changes are pushed to your development branch.
    • CSet up a Cloud Logging sink to a Pub/Sub topic that captures interactions with Cloud Source Repositories. Configure a Pub/Sub trigger for Cloud Run, and execute the unit tests on Cloud Run.
    • DSet up a Cloud Logging sink to a Pub/Sub topic that captures interactions with Cloud Source Repositories. Execute the unit tests using a Cloud Function that is triggered when messages are sent to the Pub/Sub topic.

    Show answer

    Answer: B

    Explanation

    B. GCP recommends to use Cloud Build when building KubeFlow Pipelines. It's possible to run unit tests in Cloud Build. And, the others seems overly complex/unnecessary

    Source: Adapted from community discussion — maartenalexander

    References

    • Google Cloud documentation

    Next question

Keyboard:J Kmove between questionsA–Dselect an answerRshow or hide the answer← →change page

PMLE practice, question 91. 364 questions available.