2.5 Notebook Environments: Collaboration and Security Best Practices

Google Cloud Professional Machine Learning Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

0.1 Exam Overview, Blueprint & Certification Logistics 0.2 Study Strategy, Scenario Mechanics & 8-Week Roadmap

2 Section 1: Architecting Low-Code AI Solutions (~13%)

1.1 BigQuery ML: Model Types, SQL Syntax and In-Database Evaluation 1.2 Feature Engineering and Feature Selection in BigQuery ML 1.3 Generating Predictions with BigQuery ML 1.4 AutoML on Agent Platform: Tabular, Image, Text and Video Training 1.5 Fine-Tuning Gemini Models from BigQuery 1.6 Model Garden: Evaluating and Selecting the Right Model 1.7 Industry-Specific AI APIs: Document AI, Vision, Translate and Speech 1.8 Generative Media and Models as a Service: Gemini, Imagen and Veo 1.9 Optimizing Gemini Applications for Cost, Latency and Availability

3 Section 2: Collaborating Within and Across Teams to Manage Data and Models (~16%)

2.1 Organizing and Exploring Tabular, Text, Image and Video Data 2.2 Choosing the Preprocessing Tool: BigQuery, Dataflow, Spark and In-Memory Python 2.3 Creating and Consolidating Features in Agent Platform Feature Store 2.4 Data Privacy, PII Handling and Sensitive Information 2.5 Notebook Environments: Collaboration and Security Best Practices 2.6 Prototyping in Workbench and Colab Enterprise with PyTorch, scikit-learn and JAX 2.7 Prototyping with Model Garden Foundational and Open Models in Notebooks 2.8 Choosing the Development and Experimentation Environment 2.9 Evaluating Generative Solutions: LLM-as-a-Judge and RAG Evaluation 2.10 Experiment Tracking, Artifact Lineage and Model Registry Governance

4 Section 3: Scaling Prototypes into ML Models (~21%)

3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines 3.2 Choosing the Product: AutoML, BigQuery ML, Custom Training and Pipelines 3.3 Choosing the Deployment Strategy at Design Time 3.4 Modeling Techniques for Interpretability Requirements 3.5 Organizing Training Data on Cloud Storage and BigQuery 3.6 Ingesting Structured and Unstructured Data into Training Pipelines 3.7 Training SDKs and Services: Custom Training, Kubeflow on GKE, AutoML and Tabular Workflows 3.8 Troubleshooting ML Model Training Failures 3.9 Hyperparameter Tuning, Bayesian Optimization and Vizier 3.10 Model Evaluation Metrics, Transfer Learning and Fine-Tuning 3.11 Evaluating Compute and Accelerator Options: CPU, GPU and TPU 3.12 Distributed Training Strategies, Hardware Acceleration and Performance Optimization

5 Section 4: Serving and Scaling Models (~20%)

4.1 Batch and Online Inference: Agent Platform, Model Garden, Cloud Run and GKE 4.2 Rollout Strategies: Canary, Traffic Splitting, Shadow and Blue-Green 4.3 Tuning Models for Production: Vector Search and Model Compression 4.4 Deploying Models to Public and Private Endpoints 4.5 Choosing Serving Hardware: CPU, GPU, TPU and Edge 4.6 Scaling the Serving Backend for Throughput

6 Section 5: Automating and Orchestrating ML Pipelines (~18%)

5.1 Validating Data and Models Inside Pipelines 5.2 Agent Platform Pipelines: Kubeflow Pipelines (KFP) and TFX Architecture 5.3 Reusable Pipeline Components, Artifacts and ML Metadata Lineage 5.4 Ray on Agent Platform for Distributed Python Workloads 5.5 MLOps CI/CD Automation, Retraining Triggers and Skew Prevention

7 Section 6: Monitoring AI Solutions (~13%)

6.1 Securing AI Systems: Exfiltration, Malicious Prompting and Model Armor 6.2 Responsible AI, Explainable AI, Fairness Metrics and Model Governance 6.3 Model Monitoring: Feature Skew and Drift Detection 6.4 Operational Troubleshooting, Performance Profiling and Cost Optimization 6.5 Monitoring, Testing and Evaluating Generative AI in Production

2.5 Notebook Environments: Collaboration and Security Best Practices

Key Takeaways Explain This Topic AI

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.

Last updated: September 2026

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 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.