GCP Professional Cloud Security Engineer Practice Question

Your company runs all existing workloads in a central Shared VPC host project. You need to deploy a new payment-processing service that is subject to PCI-DSS. The security team requires that:

The Cardholder Data Environment (CDE) is isolated from other Google Cloud projects.
Only the on-prem 10.1.0.0/16 network may reach the service on TCP 443 via Cloud VPN.
CDE VMs must have no public IPs and must not reach the public Internet except for access to Google APIs.
The network protections must stay in force even if project owners attempt to add VPC peering or override firewall rules.

Which Google Cloud design best meets these requirements with the least ongoing operational effort?

Deploy the payments service in its own project and VPC, peer it to the Shared VPC for management, use Cloud NAT with a reserved public IP for outbound access, and protect the service with Identity-Aware Proxy instead of organization-level policies.
Run the payments workload in the same VPC as other applications, wrap Cloud Storage and Pub/Sub in a VPC Service Controls perimeter, use Cloud NAT for outbound traffic, and rely on VPC firewall rules to restrict ingress from non-PCI subnets.
Create a payments project inside a dedicated "PCI" folder. Apply compute.vmExternalIpAccess:DENY and compute.restrictVpcPeering:DENY constraints to the folder. Build an isolated VPC (no peering), connect on-prem via Cloud VPN, enable Private Google Access (restricted.googleapis.com), and enforce a folder-level hierarchical firewall that denies all egress except Google APIs and allows HTTPS ingress only from 10.1.0.0/16.
Add the payments project as a service project in the existing Shared VPC, use subnet-level firewall tags to block other subnets, enable Private Service Connect for Google APIs, and instruct developers not to assign external IPs or create VPC peerings.

Report Issue

Answer Description

A dedicated project placed in its own PCI folder allows security administrators to bind organization-policy constraints that project owners cannot remove. The constraint compute.vmExternalIpAccess:DENY guarantees no VM in the folder can obtain a public IP, while compute.restrictVpcPeering:DENY prevents any future peering that could break CDE isolation. A stand-alone VPC (not attached to the existing Shared VPC) removes implicit routing to other workloads. A folder-level hierarchical firewall that first denies all egress and then selectively allows traffic to the on-prem CIDR (ingress TCP 443) and to restricted.googleapis.com (egress) keeps the CDE free of unintended paths-even if lower-level firewall rules are added later. Enabling Private Google Access lets the CDE reach Google APIs without public IPs or general Internet connectivity. The alternative proposals either leave the CDE inside the Shared VPC (permitting lateral movement), rely on project-level controls that owners could change, or introduce Cloud NAT/public IPs that violate the no-Internet requirement.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.