6.1 Workbench vs. Colab Enterprise: Secure, Collaborative Notebooks
Key Takeaways
- 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
.ipynbfiles 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.actAson 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.
Test Your Knowledge
A data science team wants to share notebooks with a Google group, avoid managing VMs, and have compute start and stop automatically. Which environment fits best?
A
B
C
D
Test Your Knowledge
An administrator revokes a contractor's IAM access to a Workbench instance, but the contractor can still use JupyterLab in an open browser tab. What should the administrator do to cut off access immediately?
A
B
C
D
Test Your Knowledge
A security review requires that Colab Enterprise notebook compute have no public internet access and that notebook code call Google Cloud APIs only with each person's own permissions. How should the team configure this?
A
B
C
D