Google PCA Shared VPC Practice Question

A company is designing a VPC architecture for a multi-tenant SaaS platform. Each tenant has isolated workloads that must not communicate with each other. They also need centralized network security and logging. Which VPC design meets these requirements?

⚠ Common exam trap

Candidates may incorrectly think that VPC peering (Option D) provides the same isolation and centralization as Shared VPC, but peering still requires management of multiple VPCs and does not offer a single point for logging and security policies.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use a Shared VPC with separate subnets for each tenant and firewall rules to enforce isolation

Option B is correct because a Shared VPC in Google Cloud lets a host project centrally own and manage the VPC network, subnets, firewall rules, and logging while each tenant's service project gets its own subnet; firewall rules scoped to those subnets or service accounts enforce isolation so tenant workloads cannot communicate with each other. This design also satisfies the centralized network security and logging requirement, since the host project retains control of firewall policies and VPC Flow Logs across all tenant subnets. Option A does not provide tenant isolation or centralized logging, as Cloud VPN only establishes encrypted tunnels to on-premises or remote networks. Option C is unsuitable because a single VPC with network tags and IAP tunnels does not create hard tenant boundaries and IAP is for identity-based TCP access, not tenant segmentation. Option D is wrong because VPC peering connects networks rather than isolating tenants, and Cloud NAT only provides outbound internet access, not centralized security or logging.

Answer analysis

Option-by-option breakdown

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

✗
Dedicated Cloud VPN connections per tenant
Why it's wrong here
Cloud VPN connections encrypt traffic between on-premises networks and Google Cloud; they do not isolate tenants inside a VPC or provide centralised logging. It is tempting when hybrid connectivity is required, but tenant separation here needs separate projects or VPCs with firewall rules and aggregated logs.
✓
Use a Shared VPC with separate subnets for each tenant and firewall rules to enforce isolation
Why this is correct
A Shared VPC centralises firewall rules and logging in the host project while separate subnets per tenant, combined with firewall rules, prevent cross-tenant traffic. This satisfies both the isolation requirement and the demand for centralised network security and logging across the multi-tenant platform.
✗
Single VPC with network tags and IAP tunnels
Why it's wrong here
Network tags and IAP tunnels govern access to individual instances; they do not provide the hard tenant-to-tenant traffic separation the scenario demands. It is tempting because tags centralise firewall policy in one VPC, but that design still permits east-west traffic between tenants unless explicit deny rules are written.
✗
Peered VPCs for each tenant with Cloud NAT
Why it's wrong here
Peering connects tenant VPCs directly, so isolation depends on firewall rules rather than architectural separation, and Cloud NAT only provides egress. It is tempting because peering plus NAT suits centrally managed shared services across a few trusted VPCs, not strict multi-tenant isolation with centralised logging.

Visual reference

Go deeper

Google PCA Shared VPC Practice Question

Why each option matters

Option-by-option breakdown

Related to this question