2.5 Notebook Environments: Collaboration and Security Best Practices

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:

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 nbstripout removes cell outputs. Without it, a single df.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.txt with 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 .env files or credential JSON. Add them to .gitignore and 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.