Google Professional Cloud Network Engineer

Get started today

Ultimate access to all questions.

Explanation:

Correct answer: C

Your organization's policy has two clear needs:

All general internet-bound traffic (0.0.0.0/0) must hairpin through the on-premises HA VPN tunnels before egressing to the internet (centralized inspection/egress control).
Private Google API access via the restricted.googleapis.com VIP (199.36.153.4/30) must remain private inside Google's network — not sent over the VPN (to avoid blackholing or unnecessary back-and-forth).

How option C achieves this:

Announce 0.0.0.0/0 from the on-premises router with MED 1000 (via BGP over HA VPN using Cloud Router).
This BGP-learned default route replaces the system-generated default route (0.0.0.0/0 → default internet gateway). As a result, all non-specific internet traffic from VMs is directed through the HA VPN tunnel to on-premises.
MED 1000 is the standard/default value and is sufficient here (no competing equal-cost paths mentioned).
Configure a custom static route for 199.36.153.4/30 with priority 1000 whose next hop is the default internet gateway.
This is the essential carve-out. Because it is a more-specific prefix (/30 vs. /0), it takes precedence over the BGP default route regardless of priority.
Traffic to the restricted VIP stays inside Google's private backbone (Private Google Access behavior) and is not hairpinned to on-premises.

This matches Google's official documentation exactly:https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-routing-custom

"If you've replaced or changed your default route, ensure that you have custom static routes configured for the destination IP ranges used by private.googleapis.com or restricted.googleapis.com" — with the next hop as the default internet gateway.
(Even though the next hop is "internet gateway," packets to these VIP ranges remain within Google's network.)

Why the other options fail

A and B (custom static default routes inside the VPC):
These are not the recommended approach when you already have HA VPN + BGP running. The VMware Engine / hybrid guidance prefers controlling the default route via BGP advertisement from on-premises. Static defaults can create conflicts with dynamic routing. The link you provided eliminates A/B for this reason.
D:
Announces 0.0.0.0/0 with MED 500 (lower MED = more preferred in BGP). This would also force default traffic via VPN (good).
However, it points the 199.36.153.4/30 route to the VPN tunnel — this sends API traffic to on-premises, breaking the private Google API requirement and likely causing blackholing or failed access.

Note on MED: Lower MED is preferred, but MED 1000 works fine here. The key is the combination with the correct custom /30 route pointing to the default internet gateway.

Route selection reminder (for the exam)

Most specific prefix wins first.
For equal prefixes: lowest priority number (or best BGP attributes like MED) wins.
When you replace the default route (via BGP or static), you must add explicit more-specific static routes for the Google API VIP ranges pointing to default-internet-gateway.

This is a classic Professional Cloud Network Engineer scenario testing deep knowledge of:

HA VPN + Cloud Router BGP
Private Google Access in hybrid setups
Custom routing to prevent blackholing of Google services
Priority vs. prefix length in route selection

Explanation:

Correct answer: C

Your organization's policy has two clear needs:

All general internet-bound traffic (0.0.0.0/0) must hairpin through the on-premises HA VPN tunnels before egressing to the internet (centralized inspection/egress control).
Private Google API access via the restricted.googleapis.com VIP (199.36.153.4/30) must remain private inside Google's network — not sent over the VPN (to avoid blackholing or unnecessary back-and-forth).

How option C achieves this:

Announce 0.0.0.0/0 from the on-premises router with MED 1000 (via BGP over HA VPN using Cloud Router).
This BGP-learned default route replaces the system-generated default route (0.0.0.0/0 → default internet gateway). As a result, all non-specific internet traffic from VMs is directed through the HA VPN tunnel to on-premises.
MED 1000 is the standard/default value and is sufficient here (no competing equal-cost paths mentioned).
Configure a custom static route for 199.36.153.4/30 with priority 1000 whose next hop is the default internet gateway.
This is the essential carve-out. Because it is a more-specific prefix (/30 vs. /0), it takes precedence over the BGP default route regardless of priority.
Traffic to the restricted VIP stays inside Google's private backbone (Private Google Access behavior) and is not hairpinned to on-premises.

This matches Google's official documentation exactly:https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-routing-custom

"If you've replaced or changed your default route, ensure that you have custom static routes configured for the destination IP ranges used by private.googleapis.com or restricted.googleapis.com" — with the next hop as the default internet gateway.
(Even though the next hop is "internet gateway," packets to these VIP ranges remain within Google's network.)

Why the other options fail

A and B (custom static default routes inside the VPC):
These are not the recommended approach when you already have HA VPN + BGP running. The VMware Engine / hybrid guidance prefers controlling the default route via BGP advertisement from on-premises. Static defaults can create conflicts with dynamic routing. The link you provided eliminates A/B for this reason.
D:
Announces 0.0.0.0/0 with MED 500 (lower MED = more preferred in BGP). This would also force default traffic via VPN (good).
However, it points the 199.36.153.4/30 route to the VPN tunnel — this sends API traffic to on-premises, breaking the private Google API requirement and likely causing blackholing or failed access.

Note on MED: Lower MED is preferred, but MED 1000 works fine here. The key is the combination with the correct custom /30 route pointing to the default internet gateway.

Route selection reminder (for the exam)

Most specific prefix wins first.
For equal prefixes: lowest priority number (or best BGP attributes like MED) wins.
When you replace the default route (via BGP or static), you must add explicit more-specific static routes for the Google API VIP ranges pointing to default-internet-gateway.

This is a classic Professional Cloud Network Engineer scenario testing deep knowledge of:

HA VPN + Cloud Router BGP
Private Google Access in hybrid setups
Custom routing to prevent blackholing of Google services
Priority vs. prefix length in route selection

Comments (0)

No comments yet.

To comply with your organization's security policy requiring all internet-bound traffic to route through on-premises HA VPN tunnels before egressing, while allowing VMs to access private Google APIs via the private VIP range 199.36.153.4/30, how should you configure the routes to enable these traffic flows?

Exam-Like

Last updated: April 3, 2026 at 02:45

Configure a custom route 0.0.0.0/0 with a priority of 500 whose next hop is the default internet gateway. Configure another custom route 199.36.153.4/30 with priority of 1000 whose next hop is the VPN tunnel back to the on-premises data center.

44.4%

Configure a custom route 0.0.0.0/0 with a priority of 1000 whose next hop is the internet gateway. Configure another custom route 199.36.153.4/30 with a priority of 500 whose next hop is the VPN tunnel back to the on-premises data center.

27.8%

Announce a 0.0.0.0/0 route from your on-premises router with a MED of 1000. Configure a custom route 199.36.153.4/30 with a priority of 1000 whose next hop is the default internet gateway.