An enterprise is deploying a secure machine learning environment on Google Cloud using Vertex AI Workbench notebooks, Vertex AI Pipelines, and custom training jobs. The workloads process confidential corporate data and proprietary algorithms. Security and compliance requirements dictate: All training data buckets, pipeline metadata, managed datasets, and registered model artifacts must be encrypted using Customer-Managed Encryption Keys (CMEK). All communication from the VPC to Vertex AI APIs and Cloud Storage must use private routing without traversing the public internet. Accidental data leakage and exfiltration through stolen credentials or modified IAM policies must be prevented by establishing strict network-layer perimeter boundaries around the ML resources. Which architectural approach satisfies all of these security requirements?

Configure a VPC Service Controls perimeter enclosing the projects, restrict the Vertex AI, Cloud Storage, and Cloud KMS APIs, deploy Private Service Connect endpoints for Google APIs, and specify CMEK keys across storage buckets, pipeline jobs, datasets, and model registries.: What this architectural solution is This architecture establishes a comprehensive defense-in-depth model for PaaS machine learning on Google Cloud. It combines VPC Service Controls (VPC SC) perimeters to enforce strict data boundary controls, Private Service Connect (PSC) endpoints for private API transport, and Customer-Managed Encryption Keys (CMEK) for centralized cryptographic ownership over all machine learning data assets. How it meets the requirements Mitigating exfiltration risks: Placing the projects within an enforced VPC Service Controls perimeter and restricting aiplatform.googleapis.com, storage.googleapis.com, and cloudkms.googleapis.com prevents unauthorized access or data exfiltration from unauthorized networks, even if credentials are compromised or IAM permissions are misconfigured. Private API routing: Deploying Private Service Connect endpoints inside the VPC assigns internal IP addresses to Google APIs, ensuring all Vertex AI and Cloud Storage API calls from Workbench notebooks and training workloads route over private Google network paths without touching the public internet. Centralized data protection: Enforcing CMEK across Cloud Storage training buckets, Vertex AI managed datasets, Vertex AI Pipelines metadata stores, and Model Registry ensures that organizations retain exclusive lifecycle and revocation control over the encryption keys managed in Cloud KMS. Key advantages and capabilities Zero-trust boundary: Perimeter boundaries block unauthorized API ingress and unauthorized cross-project egress attempts at the network layer. Granular access control: Access Context Manager and VPC SC ingress/egress rules allow controlled inter-perimeter collaboration when using Shared VPC topologies. Cryptographic kill switch: Revoking or disabling the CMEK key in Cloud KMS immediately prevents Vertex AI services from accessing models, training pipelines, and underlying datasets. No public IP dependency: Eliminates the requirement for public IP addresses or NAT gateways when interacting with Google APIs. Why this is optimal This approach directly aligns with Google Cloud enterprise security best practices for generative AI and machine learning platforms. It provides automated boundary enforcement, complete data-at-rest encryption control, and fully private network connectivity.

Lock Down Vertex AI With Private Perimeters and CMEK

Private Vertex AI Perimeter With Customer Managed Keys

An enterprise is deploying a secure machine learning environment on Google Cloud using Vertex AI Workbench notebooks, Vertex AI Pipelines, and custom training jobs. The workloads process confidential corporate data and proprietary algorithms.

Security and compliance requirements dictate:

All training data buckets, pipeline metadata, managed datasets, and registered model artifacts must be encrypted using Customer-Managed Encryption Keys (CMEK).
All communication from the VPC to Vertex AI APIs and Cloud Storage must use private routing without traversing the public internet.
Accidental data leakage and exfiltration through stolen credentials or modified IAM policies must be prevented by establishing strict network-layer perimeter boundaries around the ML resources.

Which architectural approach satisfies all of these security requirements?

Enable Access Transparency at the organization level, deploy Cloud NAT gateways for outbound internet access from Workbench instances, and attach client-side encryption certificates to Vertex AI custom training containers.

Deploy Serverless VPC Access connectors across all subnets, apply IAM conditions on Cloud Storage buckets requiring MFA, configure VPC Network Peering with default Google APIs, and enable Google-managed default encryption.

Configure standard VPC Network Peering to the Vertex AI producer network, create a NAT VM reverse proxy for API egress, and enforce the compute.vmCanIpForward organization policy constraint on all training instances.

Configure a VPC Service Controls perimeter enclosing the projects, restrict the Vertex AI, Cloud Storage, and Cloud KMS APIs, deploy Private Service Connect endpoints for Google APIs, and specify CMEK keys across storage buckets, pipeline jobs, datasets, and model registries.

Explanations

Enable Access Transparency at the organization level, deploy Cloud NAT gateways for outbound internet access from Workbench instances, and attach client-side encryption certificates to Vertex AI custom training containers.

What this option does

This option enables Access Transparency logging across the organization, provisions Cloud NAT gateways to allow private Compute Engine or Workbench instances to initiate outbound connections to the internet, and suggests using client-side certificates inside training containers.

Why it doesn't meet the requirements

Allows public egress paths: Deploying Cloud NAT gateways provides workloads with outbound access to the public internet, which directly contradicts the requirement to prevent exfiltration and avoid public routing.
Missing perimeter controls: Access Transparency generates audit logs when Google personnel interact with customer data, but it is a detective control, not a preventative perimeter control like VPC Service Controls.
Unsupported encryption model: Vertex AI PaaS pipelines and managed datasets natively integrate with Cloud KMS CMEK, not container-level client-side certificate encryption mechanisms.

Key limitations

Cloud NAT exposes outbound paths to external internet endpoints, increasing data exfiltration risk.
Does not restrict the Vertex AI or Cloud Storage APIs within a secure service boundary.
Fails to configure internal Private Service Connect endpoints for private API ingress.

This answer would be correct if

The requirement was to provide managed VM instances with internet outbound access for external package downloads while auditing administrative actions taken by Google support personnel.

View source documentation

Deploy Serverless VPC Access connectors across all subnets, apply IAM conditions on Cloud Storage buckets requiring MFA, configure VPC Network Peering with default Google APIs, and enable Google-managed default encryption.

What this option does

This configuration uses Serverless VPC Access connectors to route serverless traffic into a VPC, applies IAM Conditions on Cloud Storage buckets, relies on VPC Network Peering, and uses Google's standard default platform encryption keys.

Why it doesn't meet the requirements

No perimeter boundary: IAM policies and multi-factor authentication (MFA) conditions do not prevent data exfiltration if credentials are valid within an authorized session; they lack the perimeter-level boundary enforcement provided by VPC Service Controls.
Fails CMEK mandate: Google-managed default encryption uses Google-owned keys rather than Customer-Managed Encryption Keys (CMEK) in Cloud KMS, preventing the customer from controlling key lifecycle or revoking access.
Incorrect transport mechanism: Serverless VPC Access connectors are designed to route outbound traffic from serverless runtimes (like Cloud Run or Cloud Functions) into a VPC, rather than securing Vertex AI custom training jobs, Workbench instances, and API communication.

Key limitations

Lacks VPC Service Controls to prevent unauthorized data movement across organizational boundaries.
Fails to supply CMEK configuration parameters to Vertex AI Pipelines and Model Registry.
Does not establish Private Service Connect endpoints for dedicated internal Google API routing.

This answer would be correct if

The scenario focused exclusively on connecting standard Cloud Run functions to internal VPC databases using default encryption and identity-only policy checks.

View source documentation

Configure standard VPC Network Peering to the Vertex AI producer network, create a NAT VM reverse proxy for API egress, and enforce the compute.vmCanIpForward organization policy constraint on all training instances.

What this option does

This configuration sets up VPC Network Peering to a producer network, deploys a Compute Engine NAT VM to reverse-proxy traffic, and enables the constraints/compute.vmCanIpForward organization policy constraint to govern VM packet routing.

Why it doesn't meet the requirements

No data exfiltration perimeter: Standard VPC Network Peering establishes network connectivity between VPCs but does not provide VPC Service Controls protection against unauthorized API calls or credential abuse.
Unnecessary proxy bottleneck: Implementing a custom NAT VM reverse proxy introduces operational overhead, latency, and maintenance burdens when Google native Private Service Connect endpoints natively provide scalable, private IP access to Google APIs.
Lacks CMEK integration: Configuring IP forwarding constraints does not enforce Customer-Managed Encryption Keys across Cloud Storage, Vertex AI datasets, pipeline metadata, or models.

Key limitations

VPC peering alone does not restrict API access across perimeters or enforce data boundary protections.
The compute.vmCanIpForward constraint manages whether VMs can act as network routers, which is irrelevant to encrypting pipeline assets or securing PaaS Vertex AI services.
Fails to address the encryption requirements for pipeline metadata and model artifacts.

This answer would be correct if

The scenario required bridging non-transitive traffic between a legacy on-premises database and a peered database network using a proxy VM.

View source documentation

Configure a VPC Service Controls perimeter enclosing the projects, restrict the Vertex AI, Cloud Storage, and Cloud KMS APIs, deploy Private Service Connect endpoints for Google APIs, and specify CMEK keys across storage buckets, pipeline jobs, datasets, and model registries.

What this architectural solution is

This architecture establishes a comprehensive defense-in-depth model for PaaS machine learning on Google Cloud. It combines VPC Service Controls (VPC SC) perimeters to enforce strict data boundary controls, Private Service Connect (PSC) endpoints for private API transport, and Customer-Managed Encryption Keys (CMEK) for centralized cryptographic ownership over all machine learning data assets.

How it meets the requirements

Mitigating exfiltration risks: Placing the projects within an enforced VPC Service Controls perimeter and restricting aiplatform.googleapis.com, storage.googleapis.com, and cloudkms.googleapis.com prevents unauthorized access or data exfiltration from unauthorized networks, even if credentials are compromised or IAM permissions are misconfigured.
Private API routing: Deploying Private Service Connect endpoints inside the VPC assigns internal IP addresses to Google APIs, ensuring all Vertex AI and Cloud Storage API calls from Workbench notebooks and training workloads route over private Google network paths without touching the public internet.
Centralized data protection: Enforcing CMEK across Cloud Storage training buckets, Vertex AI managed datasets, Vertex AI Pipelines metadata stores, and Model Registry ensures that organizations retain exclusive lifecycle and revocation control over the encryption keys managed in Cloud KMS.

Key advantages and capabilities

Zero-trust boundary: Perimeter boundaries block unauthorized API ingress and unauthorized cross-project egress attempts at the network layer.
Granular access control: Access Context Manager and VPC SC ingress/egress rules allow controlled inter-perimeter collaboration when using Shared VPC topologies.
Cryptographic kill switch: Revoking or disabling the CMEK key in Cloud KMS immediately prevents Vertex AI services from accessing models, training pipelines, and underlying datasets.
No public IP dependency: Eliminates the requirement for public IP addresses or NAT gateways when interacting with Google APIs.

Why this is optimal

This approach directly aligns with Google Cloud enterprise security best practices for generative AI and machine learning platforms. It provides automated boundary enforcement, complete data-at-rest encryption control, and fully private network connectivity.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Private Vertex AI Perimeter With Customer Managed Keys

Security and compliance requirements dictate:

All training data buckets, pipeline metadata, managed datasets, and registered model artifacts must be encrypted using Customer-Managed Encryption Keys (CMEK).
All communication from the VPC to Vertex AI APIs and Cloud Storage must use private routing without traversing the public internet.
Accidental data leakage and exfiltration through stolen credentials or modified IAM policies must be prevented by establishing strict network-layer perimeter boundaries around the ML resources.

Which architectural approach satisfies all of these security requirements?

Explanations

Enable Access Transparency at the organization level, deploy Cloud NAT gateways for outbound internet access from Workbench instances, and attach client-side encryption certificates to Vertex AI custom training containers.

What this option does

Why it doesn't meet the requirements

Allows public egress paths: Deploying Cloud NAT gateways provides workloads with outbound access to the public internet, which directly contradicts the requirement to prevent exfiltration and avoid public routing.
Missing perimeter controls: Access Transparency generates audit logs when Google personnel interact with customer data, but it is a detective control, not a preventative perimeter control like VPC Service Controls.
Unsupported encryption model: Vertex AI PaaS pipelines and managed datasets natively integrate with Cloud KMS CMEK, not container-level client-side certificate encryption mechanisms.

Key limitations

Cloud NAT exposes outbound paths to external internet endpoints, increasing data exfiltration risk.
Does not restrict the Vertex AI or Cloud Storage APIs within a secure service boundary.
Fails to configure internal Private Service Connect endpoints for private API ingress.

This answer would be correct if

The requirement was to provide managed VM instances with internet outbound access for external package downloads while auditing administrative actions taken by Google support personnel.

View source documentation

Deploy Serverless VPC Access connectors across all subnets, apply IAM conditions on Cloud Storage buckets requiring MFA, configure VPC Network Peering with default Google APIs, and enable Google-managed default encryption.

What this option does

Why it doesn't meet the requirements

No perimeter boundary: IAM policies and multi-factor authentication (MFA) conditions do not prevent data exfiltration if credentials are valid within an authorized session; they lack the perimeter-level boundary enforcement provided by VPC Service Controls.
Fails CMEK mandate: Google-managed default encryption uses Google-owned keys rather than Customer-Managed Encryption Keys (CMEK) in Cloud KMS, preventing the customer from controlling key lifecycle or revoking access.
Incorrect transport mechanism: Serverless VPC Access connectors are designed to route outbound traffic from serverless runtimes (like Cloud Run or Cloud Functions) into a VPC, rather than securing Vertex AI custom training jobs, Workbench instances, and API communication.

Key limitations

Lacks VPC Service Controls to prevent unauthorized data movement across organizational boundaries.
Fails to supply CMEK configuration parameters to Vertex AI Pipelines and Model Registry.
Does not establish Private Service Connect endpoints for dedicated internal Google API routing.

This answer would be correct if

The scenario focused exclusively on connecting standard Cloud Run functions to internal VPC databases using default encryption and identity-only policy checks.

View source documentation

Configure standard VPC Network Peering to the Vertex AI producer network, create a NAT VM reverse proxy for API egress, and enforce the compute.vmCanIpForward organization policy constraint on all training instances.

What this option does

Why it doesn't meet the requirements

No data exfiltration perimeter: Standard VPC Network Peering establishes network connectivity between VPCs but does not provide VPC Service Controls protection against unauthorized API calls or credential abuse.
Unnecessary proxy bottleneck: Implementing a custom NAT VM reverse proxy introduces operational overhead, latency, and maintenance burdens when Google native Private Service Connect endpoints natively provide scalable, private IP access to Google APIs.
Lacks CMEK integration: Configuring IP forwarding constraints does not enforce Customer-Managed Encryption Keys across Cloud Storage, Vertex AI datasets, pipeline metadata, or models.

Key limitations

VPC peering alone does not restrict API access across perimeters or enforce data boundary protections.
The compute.vmCanIpForward constraint manages whether VMs can act as network routers, which is irrelevant to encrypting pipeline assets or securing PaaS Vertex AI services.
Fails to address the encryption requirements for pipeline metadata and model artifacts.

This answer would be correct if

The scenario required bridging non-transitive traffic between a legacy on-premises database and a peered database network using a proxy VM.

View source documentation

Configure a VPC Service Controls perimeter enclosing the projects, restrict the Vertex AI, Cloud Storage, and Cloud KMS APIs, deploy Private Service Connect endpoints for Google APIs, and specify CMEK keys across storage buckets, pipeline jobs, datasets, and model registries.

What this architectural solution is

How it meets the requirements

Mitigating exfiltration risks: Placing the projects within an enforced VPC Service Controls perimeter and restricting aiplatform.googleapis.com, storage.googleapis.com, and cloudkms.googleapis.com prevents unauthorized access or data exfiltration from unauthorized networks, even if credentials are compromised or IAM permissions are misconfigured.
Private API routing: Deploying Private Service Connect endpoints inside the VPC assigns internal IP addresses to Google APIs, ensuring all Vertex AI and Cloud Storage API calls from Workbench notebooks and training workloads route over private Google network paths without touching the public internet.
Centralized data protection: Enforcing CMEK across Cloud Storage training buckets, Vertex AI managed datasets, Vertex AI Pipelines metadata stores, and Model Registry ensures that organizations retain exclusive lifecycle and revocation control over the encryption keys managed in Cloud KMS.

Key advantages and capabilities

Zero-trust boundary: Perimeter boundaries block unauthorized API ingress and unauthorized cross-project egress attempts at the network layer.
Granular access control: Access Context Manager and VPC SC ingress/egress rules allow controlled inter-perimeter collaboration when using Shared VPC topologies.
Cryptographic kill switch: Revoking or disabling the CMEK key in Cloud KMS immediately prevents Vertex AI services from accessing models, training pipelines, and underlying datasets.
No public IP dependency: Eliminates the requirement for public IP addresses or NAT gateways when interacting with Google APIs.

Why this is optimal

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Private Vertex AI Perimeter With Customer Managed Keys

Explanations

Enable Access Transparency at the organization level, deploy Cloud NAT gateways for outbound internet access from Workbench instances, and attach client-side encryption certificates to Vertex AI custom training containers.

What this option does

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Deploy Serverless VPC Access connectors across all subnets, apply IAM conditions on Cloud Storage buckets requiring MFA, configure VPC Network Peering with default Google APIs, and enable Google-managed default encryption.

What this option does

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Configure standard VPC Network Peering to the Vertex AI producer network, create a NAT VM reverse proxy for API egress, and enforce the compute.vmCanIpForward organization policy constraint on all training instances.

What this option does

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Configure a VPC Service Controls perimeter enclosing the projects, restrict the Vertex AI, Cloud Storage, and Cloud KMS APIs, deploy Private Service Connect endpoints for Google APIs, and specify CMEK keys across storage buckets, pipeline jobs, datasets, and model registries.

What this architectural solution is

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

Confidential GKE Nodes vs Shielded GKE Nodes

Vertex AI Custom Training Service Account IAM

Environment-First Folder Hierarchy with Shared VPC

OWNER_NOT_MONITORED Finding Remediation

SCC Data Residency Regional Endpoints

Least Privilege IAM and GitOps with Break-Glass OU

Private Vertex AI Perimeter With Customer Managed Keys

Explanations

Enable Access Transparency at the organization level, deploy Cloud NAT gateways for outbound internet access from Workbench instances, and attach client-side encryption certificates to Vertex AI custom training containers.

What this option does

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Deploy Serverless VPC Access connectors across all subnets, apply IAM conditions on Cloud Storage buckets requiring MFA, configure VPC Network Peering with default Google APIs, and enable Google-managed default encryption.

What this option does

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Configure standard VPC Network Peering to the Vertex AI producer network, create a NAT VM reverse proxy for API egress, and enforce the compute.vmCanIpForward organization policy constraint on all training instances.

What this option does

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Configure a VPC Service Controls perimeter enclosing the projects, restrict the Vertex AI, Cloud Storage, and Cloud KMS APIs, deploy Private Service Connect endpoints for Google APIs, and specify CMEK keys across storage buckets, pipeline jobs, datasets, and model registries.

What this architectural solution is

How it meets the requirements

Key advantages and capabilities

Why this is optimal

Try 10 interactive questions like this one, free

Related questions

Confidential GKE Nodes vs Shielded GKE Nodes

Vertex AI Custom Training Service Account IAM

Environment-First Folder Hierarchy with Shared VPC

OWNER_NOT_MONITORED Finding Remediation

SCC Data Residency Regional Endpoints

Least Privilege IAM and GitOps with Break-Glass OU