PCNE Configuring Network Services Practice Question

Which TWO considerations are important when designing a VPC peering strategy between multiple projects in Google Cloud?

⚠ Common exam trap

Google Cloud often tests the misconception that VPC peering is transitive by default, leading candidates to incorrectly select Option A, when in fact transitivity must be explicitly engineered.

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

✓

Subnet IP ranges in peered VPCs must not overlap

VPC peering requires that subnet IP ranges in peered VPCs do not overlap. This is a fundamental constraint of VPC peering in Google Cloud: if two VPCs have overlapping CIDR blocks, routes cannot be exchanged unambiguously, and the peering connection will fail to establish or will cause routing conflicts. Overlapping ranges would break the ability to route traffic correctly between the VPCs, as there would be no way to determine which subnet a packet should be delivered to.

Answer analysis

Option-by-option breakdown

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

✗
Peering is transitive by default
Why it's wrong here
Peering is not transitive unless route exchange is enabled.
✓
Subnet IP ranges in peered VPCs must not overlap
Why this is correct
Overlapping ranges cause routing issues.
✗
Firewall rules in one VPC automatically apply to peered VPCs
Why it's wrong here
Firewall rules are not shared via peering.
✗
VPC peering can only be used within the same project
Why it's wrong here
Cross-project peering is supported.
✓
Custom routes can be exchanged between peered VPCs if configured
Why this is correct
You can export custom routes.

Visual reference

Go deeper

PCNE Configuring Network Services Practice Question

Why each option matters

Option-by-option breakdown

Related to this question