Answer-first summary for fast verification
Answer: 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.
**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
Ultimate access to all questions.
No comments yet.
Author: LeetQuiz Editorial Team
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?
A
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.
B
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.
C
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.
D
Announce a 0.0.0.0/0 route from your on-premises router with a MED of 500. Configure another custom route 199.36.153.4/30 with a priority of 1000 whose next hop is the VPN tunnel back to the on-premises data center.