Collaborating within and across teams Study Guide — Professional Machine Learning Engineer

Collaborating Within and Across Teams

This domain accounts for 14% of the GCP Professional Machine Learning Engineer exam and tests your ability to manage the full ML collaboration lifecycle: setting up reproducible notebook environments, engineering and serving features at scale, preprocessing data with pipeline-compatible tools, tracking experiments, enforcing source control discipline, and applying Responsible AI principles. Expect 8–12 questions that probe which service to use, why, and how its configuration affects team workflows and model quality.

Vertex AI Workbench and Colab Enterprise Notebooks

Core Concepts

Vertex AI Workbench provides managed, JupyterLab-based notebook environments on GCP. There are two instance types the exam distinguishes sharply:

Colab Enterprise is the exam's preferred answer for team collaboration scenarios. It integrates natively with Google Drive, supports shared runtimes (multiple users connect to one compute backend), and is billed only when the runtime is active.

Key configuration facts:

• Runtimes in Colab Enterprise can be on-demand (spun up per session) or long-running (persistent for a team).
• You assign runtimes to runtime templates that define machine type, accelerators, and network settings.
• IAM roles: roles/aiplatform.colabEnterpriseUser grants notebook execution; roles/aiplatform.colabEnterpriseAdmin manages runtimes.
• Colab Enterprise notebooks are stored in Google Drive or Cloud Storage, not on-VM disk — critical for reproducibility.
• VPC Service Controls and Private Google Access apply to both Workbench and Colab Enterprise for network isolation.

Common Traps

• The exam offers "Colab (free tier)" as a distractor — it has no enterprise IAM or VPC integration. Always choose Colab Enterprise for organizational or compliance scenarios.
• "User-Managed Notebooks give more control" is true but wrong when the scenario emphasizes team collaboration or cost optimization — choose Colab Enterprise.
• Workbench instances are zonal resources; if the scenario mentions HA or regional failover for notebooks, the answer is likely an architectural workaround, not a built-in feature.
• Idle shutdown policies in Workbench are set at the instance level via --no-remove-runtime-after-idle or via Organization Policy — not globally by default.

Worked Scenario

Requirement: A team of five data scientists needs to share GPU notebooks, keep costs low, and enforce corporate VPC boundaries.
Reasoning: "Share" → Colab Enterprise shared runtimes. "VPC boundaries" → Colab Enterprise supports VPC peering + runtime templates with custom networks. User-Managed Workbench is per-user and persistent (higher cost). Answer: Colab Enterprise with a shared runtime template on a custom VPC network.

Feature Engineering and Vertex AI Feature Store

Core Concepts

Vertex AI Feature Store is a managed repository for storing, serving, and sharing ML features. It solves the training-serving skew problem by ensuring the same feature computation logic is used in both pipelines.

Feature Store 2.0 (Bigtable-backed) is the current architecture the exam tests:

Two store types:

• Bigtable Online Store: lowest latency (~ms), best for high-QPS production serving.
• Optimized Online Store: managed, no Bigtable provisioning needed; good for moderate QPS; simpler ops.

Batch serving reads directly from BigQuery (Feature Group source). Online serving reads from the Feature Online Store after a sync (manual or scheduled).

Sync is the process of materializing features from BigQuery into the Online Store. Syncs can be triggered manually or on a schedule. Point-in-time correct lookups are supported for batch serving — critical for avoiding data leakage.

Feature Store 1.0 (legacy) used EntityTypes and FeatureValues; the exam may present both. Know that 2.0 replaces EntityType with Feature Group and adds BigQuery as the source of truth.

Diagram 1: Vertex AI Feature Store 2.0 data flow from source to serving.

Common Traps

• Training-serving skew is the primary reason to use Feature Store — if the scenario describes inconsistent features between training and inference, Feature Store is the answer.
• Feature Store does not run your feature computation — it stores and serves pre-computed features. The computation happens in BigQuery, Dataflow, or custom pipelines.
• Choosing between Bigtable and Optimized store: exam favors Bigtable when the scenario says "sub-10ms latency at high QPS" and Optimized when it says "simplicity" or "no infrastructure management."
• Point-in-time correctness is only guaranteed in batch serving (historical snapshots). Online serving always returns the latest value.
• Feature Store versioning is at the Feature Group level via BigQuery table versioning, not natively within the store itself.