What's changed: Created Professional Cloud Network Engineer Chapter 2 (Domain 2 "Implement": VPC/subnets/firewall rules-policies, VPC peering (non-transitive), Shared VPC and compute.networkUser, Private Google Access, VPC Service Controls perimeter, subnet expansion, static/Cloud Router dynamic routing, route priority/network tags, internal LB next hop, policy-based routing, Network Connectivity Center spokes/topologies/Private NAT/PSC propagation/CIDR filters, GKE = VPC-native/private clusters/authorized networks/DNS-based endpoint/Dataplane V2/IP masquerade/network policies/Pod-Service ranges).
2.1Configuring VPCs and routing
Understand creating VPC resources (networks/subnets/firewall rules or policies), VPC Network Peering, Shared VPC creation and sharing subnets with service projects with IAM permissions, Private Google Access, VPC Service Controls perimeters, expanding subnet ranges, static/dynamic routing (Cloud Router), route priority and network tags, internal LB as a next hop, and policy-based routing.
This is where the design becomes real: create VPCs, subnets, firewalls, and routes, and configure reachability and control correctly. Translate requirements into "which configuration realizes it."
2.1.1VPC, subnets, firewall, and sharing
Create a VPC and its subnets (regional), and define allow/deny with firewall rules or firewall policies. To let multiple projects use one VPC, enable Shared VPC and grant service projects the subnet-user permission (IAM compute.networkUser). Connect separate VPCs with VPC Network Peering (note: it is not transitive). Let VMs without external IPs reach Google APIs by enabling Private Google Access, and prevent data exfiltration from sensitive services with VPC Service Controls service perimeters. If IPs run short after launch, grow ranges with subnet range expansion.
2.1.2Routing and next hops
Configure routes with static routes and dynamic routing (BGP) via Cloud Router. Set scope with the global or regional dynamic routing mode. When multiple routes share a destination, narrow application with route priority (lower wins) and network tags. To steer traffic through inspection appliances, set an internal load balancer as a next hop or use policy-based routing that diverts by source/protocol. Exchange routes across VPC peering or NCC with custom route import/export. Map "choosing among same-destination routes = priority" and "bending traffic for inspection = ILB next hop/policy-based route."
Common: requirement → means. E.g., "let a service project use a Shared VPC subnet" = grant compute.networkUser; "Google APIs from no-external-IP VMs" = Private Google Access; "prevent data exfiltration from sensitive services" = VPC Service Controls perimeter; "choose among same-destination routes" = route priority; "steer specific VMs to an inspection LB" = internal LB as next hop/policy-based route.
Watch the mix-ups: (1) VPC peering is non-transitive—A-B and B-C do not give A-C (consider NCC/hub-and-spoke). (2) Private Google Access (private reach to Google APIs) vs Cloud NAT (general internet egress) differ in purpose. (3) Lower route-priority value wins.
2.1.3Section summary
- Shared VPC subnet use = compute.networkUser; connect separate VPCs = (non-transitive) peering
- Google APIs without external IP = Private Google Access; prevent exfiltration = VPC Service Controls perimeter
- Routes = static/Cloud Router dynamic; same destination = priority; inspection = ILB next hop/policy-based route
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To let a service-project team create resources in a Shared VPC subnet, which IAM role should you grant?
Q2. To let VMs without external IPs reach Google APIs (e.g., Cloud Storage) privately, which setting?
Q3. To prevent data exfiltration from BigQuery or Cloud Storage with a perimeter, which is best?
Q4. To steer east-west traffic through an inspection firewall appliance, which next-hop construct is recommended?
Q5. A-VPC peers with B-VPC and B-VPC peers with C-VPC, but A cannot reach C. Why?