Study guide
6.1 Workbench vs. Colab Enterprise: Secure, Collaborative Notebooks
Google Cloud Professional Machine Learning Engineer PMLE
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & the Agent Platform Map
1.1 PMLE Exam Facts, Policies & the June 2026 Blueprint 1.2 From Vertex AI to Gemini Enterprise Agent Platform: The Product Name Map
2 Chapter 2: Low-Code ML with BigQuery ML
2.1 Choosing, Training & Predicting with BigQuery ML Models 2.2 Feature Engineering & Feature Selection in BigQuery ML 2.3 Fine-Tuning & Evaluating Gemini Models from BigQuery
3 Chapter 3: AutoML & Google Cloud AI APIs
3.1 Training Models with Agent Platform AutoML 3.2 Building with Document AI, Vision, Translation & Other AI APIs
4 Chapter 4: Foundation Models in Model Garden
4.1 Evaluating & Selecting Models in Model Garden 4.2 Building & Tuning Solutions with Gemini, Imagen, Veo & MaaS 4.3 Optimizing Gemini Applications for Cost, Latency & Availability
5 Chapter 5: Exploring, Preprocessing & Protecting Data
5.1 Organizing & Exploring Tabular, Text & Image Data 5.2 Choosing a Preprocessing Tool: BigQuery, Dataflow, Spark or Python 5.3 Creating & Consolidating Features in Agent Platform Feature Store 5.4 Protecting PII & Sensitive Data in ML Workflows
6 Chapter 6: Notebooks, Prototyping & Experiment Tracking
6.1 Workbench vs. Colab Enterprise: Secure, Collaborative Notebooks 6.2 Prototyping with PyTorch, scikit-learn, JAX & Model Garden in Notebooks 6.3 Experiment Environments, Tracking & Lineage with Experiments and ML Metadata
7 Chapter 7: Evaluating Predictive & Generative AI Solutions
7.1 Evaluation Metrics for Predictive Models 7.2 Evaluating Gen AI: Computation Metrics, Rubrics & LLM-as-a-Judge
8 Chapter 8: Choosing the Modeling Approach
8.1 Choosing the Model Type: ARIMA, Trees, DNNs & LLMs 8.2 Choosing the Product & Deployment Strategy 8.3 Modeling Techniques for Interpretability Requirements
9 Chapter 9: Training Data & Training SDKs
9.1 Organizing & Ingesting Training Data from Cloud Storage & BigQuery 9.2 Custom Training on Agent Platform: Containers, Jobs & Worker Pools 9.3 Kubeflow on GKE, AutoML & Tabular Workflows as Training Choices
10 Chapter 10: Troubleshooting, Hyperparameter Tuning & Fine-Tuning
10.1 Troubleshooting ML Training Failures 10.2 Hyperparameter Tuning on Agent Platform 10.3 Fine-Tuning Foundation Models & When to Tune
11 Chapter 11: Training Hardware & Distributed Training
11.1 Choosing CPUs, GPUs & TPUs for Training 11.2 Distributed Training: Data & Model Parallelism
12 Chapter 12: Deploying Models for Inference
12.1 Batch vs. Online Inference on Agent Platform 12.2 Serving Beyond Agent Platform Endpoints: Model Garden, Cloud Run & GKE 12.3 Prebuilt & Custom Serving Containers
13 Chapter 13: Model Versions, Rollouts & Inference Logic
13.1 Organizing & Versioning Models in Model Registry 13.2 Rollout Strategies: A/B Tests, Canaries & Traffic Splits 13.3 Inference Preprocessing & Postprocessing
14 Chapter 14: Scaling Online Serving
14.1 Serving Features Online with Feature Store 14.2 Public, Dedicated & Private Endpoints 14.3 Serving Hardware & Autoscaling for Throughput 14.4 Tuning Models for Production Training & Serving
15 Chapter 15: End-to-End ML Pipelines
15.1 Validating Data & Models in Pipelines 15.2 Agent Platform Pipelines with KFP: Components, Templates & Caching 15.3 Ensuring Consistent Preprocessing Between Training & Serving
16 Chapter 16: Orchestration with Managed Airflow & Ray
16.1 Orchestrating ML Workflows with Managed Service for Apache Airflow 16.2 Ray on Agent Platform for Distributed ML Workloads
17 Chapter 17: Automating Retraining & CI/CD/CT
17.1 Choosing a Retraining Policy 17.2 CI/CD/CT for ML with Cloud Build
18 Chapter 18: Securing AI Systems, Responsible AI & Explainability
18.1 Protecting AI Systems from Data & Model Exfiltration 18.2 Defending Gen AI Apps: Safety Filters, Model Armor & Regex Guardrails 18.3 Responsible AI: Detecting & Monitoring Bias 18.4 Model Explainability on Agent Platform
19 Chapter 19: Monitoring AI Solutions
19.1 Configuring Model Monitoring on Agent Platform 19.2 Training-Serving Skew, Data Drift, Concept Drift & Attribution Drift 19.3 Monitoring, Testing & Evaluating Gen AI Solutions in Production
6.1 Workbench vs. Colab Enterprise: Secure, Collaborative Notebooks
Key Takeaways Explain This Topic AI
Google positions Colab Enterprise for collaboration without managing infrastructure, and Agent Platform Workbench for control and customization on VM instances.
Colab Enterprise notebooks can be shared through IAM with a single user, a Google group, or a Google Workspace domain.
Colab Enterprise and Workbench instances both shut down after 180 idle minutes by default, and the timeout can be set from 10 to 1,440 minutes.
Workbench instances use a Single user only or Service account access mode, which is set at creation and can't be changed afterward.
Colab Enterprise runtime templates can disable public internet access, choose a VPC network, and use end-user credentials or other authentication for Google Cloud APIs.
Last updated: September 2026
Section 2.2 of the exam guide starts with applying collaboration and security best practices when setting up and running notebook environments . Notebooks are where sensitive data, credentials, and expensive GPUs meet informal, fast-moving work, so the exam expects secure defaults, not just convenience.
Two Managed Notebook Options
Workbench managed notebooks and user-managed notebooks reached end of life on March 30, 2026. The supported choices are:
- Dimension Colab Enterprise Agent Platform Workbench instances
- Google's positioning Collaborate and avoid managing infrastructure Control and customizability
Interface Colab notebook UI in the Google Cloud console, also embedded in BigQuery JupyterLab on a VM you configure
Compute Runtimes created from runtime templates (machine type, accelerators, disk, network) that Colab Enterprise starts and stops for you A VM instance with CPU or GPU that you create and manage
Sharing Share the notebook file through IAM with a user, Google group, or Workspace domain Access mode set per instance. Share code through GitHub sync
Customization Runtime templates and post-startup scripts Conda environments as kernels (for example, R or Apache Beam), custom containers , framework versions
Scheduling Scheduled notebook runs with results stored in Cloud Storage Executor runs notebooks once or on a schedule on Agent Platform custom training, even while the instance is stopped
Data access Embedded in BigQuery and Agent Platform console pages. Data Science Agent and Gemini code assistance Browse Cloud Storage and query BigQuery from the JupyterLab navigation menu
Rule of thumb: a team that wants to share notebooks and not manage VMs picks Colab Enterprise . A researcher who needs a specific conda environment, custom container, or long-lived customized VM picks Workbench .
- Identity and Access
- Colab Enterprise
Colab Enterprise User ( roles/aiplatform.colabEnterpriseUser ) lets people create and run notebooks. Colab Enterprise Admin ( roles/aiplatform.colabEnterpriseAdmin ) can see and manage all notebooks in the project. Notebook Runtime User covers runtime usage.
Notebooks are stored through Dataform , which is why Dataform APIs and permissions appear in setup and VPC Service Controls configuration.
Share individual notebooks through IAM instead of downloading .ipynb files and emailing them around.
By default, runtime templates use end-user credentials , so notebook code calls Google Cloud APIs with the user's own permissions . That keeps a notebook from quietly gaining broader access than the person running it.
Workbench instances
Single user only access mode: only the named user can open JupyterLab. The instance's service account still needs access to any resources the code uses.
Service account access mode: users with iam.serviceAccounts.actAs on the specified service account can open JupyterLab. Use a custom, least-privilege service account , not the broad Compute Engine default.
The access mode is fixed at creation .
Granting access to JupyterLab doesn't grant permission to start, stop, or reset the instance. That needs separate IAM on the instance.
After access is revoked, an existing browser session may keep working for up to five days . Stop or reset the instance to cut access immediately.
Network and Data Protection
Control Colab Enterprise Workbench
Private networking Runtime template picks the VPC and subnet, and can disable public internet access Deploy into your VPC instead of the default network
VPC Service Controls Runtimes are subject to the perimeter. Add every service the code calls (and Dataform) to the perimeter Supported for instances inside a service perimeter
CMEK Runtimes, notebooks, and the Data Science Agent Instances
Other Access Transparency, Compute Engine reservations for runtimes Confidential Computing (Confidential VM) for data in use
Cost Controls
Idle shutdown: both Colab Enterprise runtimes and Workbench instances default to 180 minutes of inactivity. You can set 10 to 1,440 minutes or turn it off, but leaving GPU notebooks running overnight is a classic cost leak.
Default Colab Enterprise runtime: e2-standard-4 , 100 GiB SSD boot disk, idle shutdown at 180 minutes, and automatic deletion 18 hours after creation. Files uploaded to a runtime disappear when it's deleted, so keep data in Cloud Storage or BigQuery.
Right-size with templates: a small template for exploration, and a GPU template only when needed.
Move long jobs out of notebooks: use scheduled runs or submit custom training jobs, so an interactive VM isn't held open for hours.
Collaboration Best Practices
Version control: sync Workbench notebooks to GitHub, and review notebook changes like code.
Clear outputs before sharing or committing. Output cells can contain raw customer rows, tokens, or API responses.
Never hard-code credentials. Use end-user credentials or service accounts, and put API keys in Secret Manager.
Work on de-identified or sampled data during exploration (Chapter 5).
Parameterize notebooks (dataset, date range, hyperparameters) so scheduled runs are reproducible.
Log experiments to Experiments on Agent Platform rather than tracking results in notebook cells (Section 6.3).
Promote stable code from notebooks into pipeline components and containers for production (Chapter 15).
Worked Scenario
A bank's fraud analytics team of eight needs shared notebooks over BigQuery data that includes account numbers. Requirements: no public internet from compute, data must not leave the security perimeter, and people should get only the access their own identity allows.
Choose Colab Enterprise for IAM-based sharing and managed runtimes.
Create a runtime template in the bank's VPC subnet with public internet access disabled and end-user credentials enabled.
Put Agent Platform, BigQuery, Cloud Storage, and Dataform inside a VPC Service Controls perimeter.
Grant analysts Colab Enterprise User , and share the team notebooks with a Google group.
Enable CMEK if policy requires customer-managed keys, and keep idle shutdown on.