Your organization has a hybrid network with an on-premises data center connected to Google Cloud via a Dedicated Interconnect. The on-premises network uses RFC 1918 addresses (10.0.0.0/8) and Google Cloud VPC has a subnet in 10.1.0.0/16. You've configured a Cloud Router with BGP to exchange routes. Recently, you set up a new VPC with a subnet in 10.2.0.0/16 and peered it with the first VPC using VPC Network Peering. You notice that on-premises traffic destined to 10.2.0.0/16 is being dropped. You verify that the firewall rules allow the traffic and that BGP routes for 10.2.0.0/16 are not advertised on-premises. What should you do to enable connectivity from on-premises to the new VPC?
Custom route advertisements on Cloud Router propagate the peering range to on-premises.
Why this answer
Option B is correct because the Cloud Router uses BGP to advertise routes to the on-premises network via the Dedicated Interconnect. By default, only VPC subnet routes are advertised; custom route advertisements must be explicitly configured to propagate the peered VPC's subnet (10.2.0.0/16) to on-premises. This ensures the on-premises routers learn the route and can forward traffic to the new VPC.
Exam trap
The trap here is that candidates assume VPC Network Peering automatically shares routes with on-premises networks via Interconnect, but in reality, peered VPC routes are not propagated to on-premises unless explicitly advertised through Cloud Router custom route advertisements.
How to eliminate wrong answers
Option A is wrong because a Cloud VPN tunnel is unnecessary when a Dedicated Interconnect already exists; the issue is route advertisement, not connectivity method. Option C is wrong because firewall rules are not the problem (they already allow traffic); the root cause is missing route propagation, not a missing allow rule. Option D is wrong because Shared VPC is used for centralized administration of multiple projects, not for enabling route exchange between a peered VPC and an on-premises network via Interconnect.