GCP Professional Cloud Security Engineer Practice Question

An online retailer is migrating its card-holder data environment (CDE) to Google Cloud and must prepare for a PCI DSS audit. Architects need to keep the CDE out of scope for non-PCI workloads yet still allow internal HTTP API calls from services running in other projects. Which design best achieves PCI scope reduction while keeping administration effort low?

Deploy CDE instances with public IP addresses in a separate VPC and rely on Cloud Armor policies to limit access to the IP ranges of non-PCI services.
Keep CDE and non-PCI workloads in distinct projects but interconnect the two VPCs with VPC Network Peering, using IAM Conditions to restrict which service accounts can initiate traffic.
Create a dedicated project that hosts its own standalone VPC for the CDE, place the project in a "PCI" folder, and expose required APIs through an Internal HTTP(S) Load Balancer or Private Service Connect; do not establish any VPC peering to other projects.
Attach every project, including the CDE, to a single organization-wide Shared VPC and use firewall rules to block all traffic except TCP 443 between CDE and non-PCI subnets.

Report Issue

Answer Description

Keeping the CDE in a completely separate VPC that is owned by a dedicated project under a PCI-only folder prevents any implicit Layer-3 reachability from non-PCI workloads. Exposing the necessary services through an Internal HTTP(S) Load Balancer (or Private Service Connect endpoint) lets other projects consume the API without creating network peering, so the non-PCI networks are not brought into PCI scope. Relying on a single Shared VPC, subnet separation, public IPs, or VPC Network Peering would mean that the larger network-or even the public internet-becomes in scope, greatly increasing audit surface and contradicting PCI segmentation guidance.

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.