Google ACE Practice Question: A team is designing a system where two GCP…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  VPC Peering between the two projects' VPCs

  Why it's wrong here

  VPC Peering connects two separate VPCs directly over Google's private backbone, allowing RFC1918 communication without external IPs or VPN tunnels. However, it is a peer relationship, not a shared infrastructure: each project retains its own network admin, firewall rules, routes, and subnets, so there is no centralized control point for enforcing organization-wide security policy. As the number of service projects grows, you also face transitive peering limitations (peered VPCs can reach the direct peer but not vice versa through the peering chain) and must manage a one-to-one peering session for each pair, making governance and auditing harder than with a single shared VPC.

• ✓

  Shared VPC (XPN) with the shared services project as the host

  Why this is correct

  With Shared VPC (XPN), the shared services project acts as the host, owning the VPC networks and subnets that service projects' VMs consume. The host project's network admin has centralized visibility and control over routing, firewall policies (including hierarchical firewall rules), and subnet allocation, while service project owners can deploy VMs without managing network infrastructure. This is the recommended pattern when multiple projects need to consume common services over private IPs because it enforces consistent governance, simplifies auditing, and scales without adding peering or VPN links per project.

• ✗

  Cloud VPN between the two projects' default VPCs

  Why it's wrong here

  Cloud VPN establishes an IPsec tunnel between the two projects' default VPCs, which adds encryption overhead, extra latency, and the operational burden of managing tunnel endpoints and health checks. Both VPCs already live inside Google's private network, so forcing traffic through an IPsec tunnel is unnecessary and does not provide centralized network management — the projects remain independent, and you still have to duplicate firewall rules and routing. This approach is better suited for connecting an on-premises network to Google Cloud or two clouds, not for internal multi-project communication within the same organization.

• ✗

  Using external IPs with TLS — private IP communication isn't necessary between GCP projects

  Why it's wrong here

  Assigning external IPs to VMs in both projects and using TLS means traffic traverses the public internet, incurring egress fees, higher latency, and exposure to DDoS attacks even though payloads are encrypted. TLS protects confidentiality in transit but does not provide network-level authorization or private IP reachability, so you'd also need IP whitelists or client certificates to restrict access, and every service must manage its own certificate lifecycle. This also prevents centralized, org-wide network policy and makes it impossible to enforce consistent firewall rules across projects; Google's private backbone via Shared VPC or peering is faster, cheaper, and requires no public exposure.

Go deeper

Related to this question