Memory hook: Address allocation first; route selection second.
Must remember
- Routes determine next hops; firewall rules determine permitted traffic. Evaluate route applicability, destination specificity and the documented priority rules for the route type rather than comparing all numbers as one flat list.
- Cloud Router learns and advertises routes using BGP; regional/global dynamic routing mode controls where learned routes are available. It is a control-plane service, not the device through which every data packet passes.
- NCC connects VPC, hybrid and supported producer spokes. Mesh and star topologies, route filters, PSC propagation and Private NAT must match the intended reachability; inspect advertised and accepted prefixes.
- VPC-native GKE uses alias IP ranges for Pods and Services. Plan primary/secondary ranges, additional Pod ranges, Shared VPC permissions, IPv6 support and node-pool growth.
- Private nodes and private/control-plane access are separate choices. Authorized networks and DNS-based control-plane endpoints address access differently; verify the chosen endpoint’s identity and network requirements.
- GKE Dataplane V2, NetworkPolicy, IP masquerade/SNAT settings and DNS choices affect Pod traffic. Use kube-dns/Cloud DNS and NodeLocal DNSCache as appropriate; a healthy node does not prove Pod DNS or policy is correct.
Review details
Custom route exchange across peering is explicit, and imported routes do not automatically turn a peer into a transit router. Route selection considers applicability and route category before the relevant prefix/priority rules. Policy-based routes can direct matching traffic to a supported internal load-balancer next hop; appliance health and a correct return path remain essential.
For Shared VPC GKE, check the service project and required service-agent/subnet permissions as well as the network administrator. Pod IP exhaustion can happen even when CPU quota is healthy. Inspect masquerade policy when the observed source address differs from the expected Pod address.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| On-premises routes must be usable across regions | Evaluate global dynamic routing plus resilient connectivity and advertisements. |
| Pods cannot reach a service but nodes can | Inspect Pod ranges, NetworkPolicy, DNS and SNAT rather than only the VM firewall. |
Traps
- Creating a Cloud Router without a BGP peer does not establish hybrid connectivity.
- A private cluster is not automatically inaccessible to every authorized management path.
Active recall
1. What does Cloud Router exchange?
BGP route information for supported hybrid/network services.
2. Why inspect both imported and exported routes?
One-way reachability often comes from a missing return path.
3. What does a Kubernetes NetworkPolicy govern?
Allowed Pod traffic within supported policy semantics and implementation.
4. Why can SNAT affect access rules?
The destination may see a translated source rather than the original Pod address.
5. What does NCC topology control?
Which connected spokes can exchange reachability according to the configured topology and policies.