2.5 Notebook Environments: Collaboration and Security Best Practices
Key Takeaways
Notebooks should run as a dedicated least-privilege service account, never as a broadly-privileged user identity or the default Compute Engine service account.
Instances belong on private IP inside a VPC with Private Google Access, reached through IAP TCP forwarding rather than an external address.
Idle shutdown, scheduled shutdown, and right-sized machine types prevent GPU-attached instances from billing overnight for nobody.
Notebooks are not source control — code belongs in Git, and nbstripout or a similar hook prevents outputs and embedded secrets from being committed.
Credentials belong in Secret Manager and data access should flow through the service account, never through downloaded key files pasted into a cell.
2.5 Notebook Environments: Collaboration and Security Best Practices
Blueprint reference: Section 2.2, "Applying collaboration and security best practices when setting up and running notebook environments."
Notebooks are where most data science begins, and they are also where most of an organization's worst security habits live: long-lived credentials pasted into cells, instances running as project-wide admins, and GPU machines idling all weekend. The exam tests whether you know the managed alternatives.
Identity: Least Privilege Is the Whole Answer
A managed notebook instance runs as a service account, and every data access it performs uses that identity.
- Create a dedicated service account per team or project. Grant it only what the work requires — for example, BigQuery Data Viewer on two datasets and Storage Object Viewer on one bucket.
- Never use the default Compute Engine service account. It is broadly scoped by default and shared by every instance in the project, which makes least privilege impossible and audit attribution meaningless.
- Single-user instances for regulated work. A single-user managed instance binds access to one principal, so notebook actions are attributable. Shared instances mean any user of the instance inherits the instance's identity.
- Grant users the ability to use the instance, not to impersonate the service account broadly. Notebook access roles are separate from Service Account User on high-privilege identities.
The recurring exam pattern: a scenario where a notebook can read production data it should not. The wrong fixes are "ask the team not to" or "audit afterwards." The right fix is a narrower service account.
Network Isolation
Default-configured instances with an external IP address are a standing exposure. The hardened pattern:
| Control | Effect |
|---|---|
| Private IP only (no external address) | Instance is unreachable from the internet |
| Private Google Access on the subnet | Instance still reaches BigQuery, Cloud Storage, and the Agent Platform |
| IAP TCP forwarding | Users connect through Identity-Aware Proxy with IAM-checked identity, no VPN and no public IP |
| VPC Service Controls | Data cannot be copied out of the perimeter even by an authorized principal |
| Disabled root access / terminal | Prevents users from bypassing instance controls |
| CMEK on instance disks | Organization-controlled encryption keys |
If a scenario says "data scientists must reach notebooks without exposing them to the internet and without deploying a VPN," IAP TCP forwarding is the intended answer.
Cost Discipline
Notebook cost is dominated by instances that are running and not being used.
- Idle shutdown. Configure an idle timeout — commonly 30 to 180 minutes — so an instance with no kernel activity stops automatically. This single setting is usually the largest saving available, because attached accelerators bill for every hour the instance is up.
- Right-size, then attach. Develop on a small CPU instance; attach a GPU only when actually training. Better still, submit real training to a custom training job so the accelerator lives only for the duration of the job.
- Stop, do not delete. Stopping preserves the persistent disk and the environment while halting compute charges.
- Budget alerts and labels. Label instances by team so chargeback is possible, and set budget alerts on the project.
The most-tested habit: heavy training does not belong in a notebook. A notebook is for exploration and prototyping; when the job is long, it should be submitted as a training job so the notebook can be shut down while it runs.
Collaboration and Reproducibility
Notebooks collaborate badly by default — they are JSON documents containing outputs, so they merge poorly and leak data into version control.
- Git is the source of truth. Notebook instances integrate with repositories; commit code, not state.
- Strip outputs before committing. A pre-commit hook such as
nbstripoutremoves cell outputs. Without it, a singledf.head()on a customer table publishes real PII into the repository history. - Pin the environment. A custom container image, or at minimum a checked-in
requirements.txtwith pinned versions, makes "it works on my instance" reproducible. Managed notebook images are versioned; record which one was used. - Promote to a component. Once a notebook cell block is worth keeping, move it into a pipeline component rather than re-running the notebook by hand. Notebooks are not a scheduler.
- Executor / scheduled runs. Notebook execution can be submitted as a parameterized job rather than run interactively, which keeps a reproducible record and frees the instance.
Secrets
- Never paste a service account key file into a cell. The instance already has an identity; use it.
- Never hard-code API keys. Store them in Secret Manager and fetch at runtime with the instance's service account.
- Never commit
.envfiles or credential JSON. Add them to.gitignoreand rely on the output-stripping hook for anything printed. - Rotate anything that leaks. A key committed to a repository is compromised the moment it is pushed, even if the commit is later removed.
Exam Traps
- Default Compute Engine service account on a notebook touching production data.
- External IP plus firewall rule instead of private IP plus IAP.
- Running multi-hour training interactively instead of submitting a training job.
- Committing notebooks with outputs containing customer rows.
- Deleting instead of stopping, losing the environment to save the same compute cost.
A regulated organization requires that data scientists reach managed notebook instances without exposing them to the internet and without provisioning a VPN, while every connection is authorized against corporate identity. Which configuration meets this?
Assign external IP addresses and restrict access with a firewall rule limited to the corporate office IP range.
Deploy instances with private IP only, enable Private Google Access on the subnet, and have users connect through IAP TCP forwarding.
Place the instances in a shared VPC and require users to connect over Cloud VPN from the corporate network.
Keep external IPs but enable OS Login so that SSH access is governed by IAM roles.
A finance team discovers that notebook instances run as the default Compute Engine service account and can therefore read every BigQuery dataset in the project, including production payroll. What is the correct remediation?
Ask data scientists to use a separate project for payroll analysis and rely on project boundaries for isolation.
Apply column-level policy tags to the payroll table so the columns are hidden from notebook queries.
Create a dedicated service account per team with only the dataset-level roles each team requires, and configure the notebook instances to run as it.
Enable Cloud Audit Logs on the payroll dataset and review notebook access weekly.
A data scientist commits an exploratory notebook to the team repository. A security scan later finds real customer email addresses and account balances in the repository history. The notebook code itself contains no data. How did this happen, and what prevents recurrence?
The notebook instance had an external IP, allowing the repository scanner to read its disk; move the instance to private IP.
The repository was cloned onto the instance rather than the reverse, so the working directory was committed; use the managed Git integration instead.
The notebook embedded a service account key that was used to re-fetch the data; store credentials in Secret Manager instead.
Executed cell outputs are stored inside the notebook file, so a displayed dataframe was committed; add an output-stripping pre-commit hook such as nbstripout.
A team's notebook spend is dominated by GPU-attached instances that remain running overnight and across weekends while long training runs and idle periods alternate. Which combination best addresses the cost?
Enable idle shutdown on the instances, develop on smaller CPU instances, and submit long training runs as custom training jobs so accelerators exist only for the job duration.
Switch the instances to preemptible GPUs so that overnight running costs less per hour.
Increase the instance machine type so that training finishes faster and the instances spend less total time running.
Delete instances at the end of each day and recreate them each morning from a startup script.
Sections you finish are checked off in the contents.