Memory hook: VPC is global; subnet is regional; permission is separate.
Must remember
A Google Cloud VPC network is global; its subnets are regional and can serve zones in that region. Custom-mode networks give deliberate address allocation. Plan nonoverlapping primary/secondary ranges for VMs, Pods and services. Supported subnet expansion increases address space; do not assume arbitrary shrinking is available.
Routes decide where packets go; firewall rules/policies decide whether eligible traffic is allowed. Stateful firewall behavior permits matching return traffic, but the route must still exist. Priority, direction, source/destination and target selection matter. Network tags and service-account targets select workloads under their respective rule models; labels used for inventory are not automatically firewall selectors.
Shared VPC centrally manages a network in a host project while service projects deploy authorized resources into it. VPC Network Peering connects networks privately under its route-exchange rules and is not transitive by default. It does not merge IAM policy or all DNS behavior.
Private Google Access lets eligible private-address workloads reach supported Google APIs under correct routing/DNS. Private Service Connect exposes supported services through private endpoints or related service-connectivity patterns. Private services access allocates peering-based connectivity for supported managed services; these similarly named mechanisms are not interchangeable.
Cloud NAT provides configured outbound address translation for eligible private resources without accepting arbitrary unsolicited inbound connections. It needs the relevant routing and regional configuration; it is not an HTTP proxy or a packet-forwarding VM you administer. Reserve static addresses only where stable identity/allowlisting requires them.
Diagnose source identity/address, subnet/range, route, firewall, DNS and destination listener separately. Private networking reduces exposure but does not grant API IAM permissions or database access.
Review details
A new VPC has implied deny ingress and allow egress rules at the lowest effective priority; explicit rules/policies can change the outcome. Lower numeric priority means higher priority within the applicable rule model, but hierarchical/network/VPC policy evaluation must be considered as a whole. The pre-created default network's explicit rules are not the behavior of every custom VPC.
Cloud NAT is regional and uses Cloud Router configuration without routing packets through a Cloud Router VM. NAT port exhaustion can break outbound connections even when the default route exists. Private Google Access also needs appropriate DNS/routes; merely removing a public IP is not a complete private-access design.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Central network across several projects | Shared VPC with controlled service-project attachment. |
| Private workloads need outbound Internet | Appropriate Cloud NAT and routes. |
| Consume supported service at a private endpoint | Private Service Connect. |
Traps
- VPC peering is not automatically transitive.
- A network label is not the same as a firewall network tag.
Active recall
1. VPC versus subnet scope?
VPC is global; a subnet is regional.
2. Does Cloud NAT permit unsolicited inbound connections?
No, not as a general inbound exposure mechanism.
3. Does peering merge IAM?
No. Resource and identity permissions remain separately controlled.
4. Why plan secondary ranges?
Services such as VPC-native GKE allocate Pod/service addresses from defined ranges.
5. Does a private API path grant permission?
No. IAM authorization must still allow the request.