Google Cloud ACE VPC Networking Guide
Study Google Cloud ACE VPC Networking: key concepts, common traps, and exam decision cues.
This lesson covers the core Google Cloud networking changes ACE expects operators to make. Many questions are really about whether the issue is a VPC design choice, a firewall rule, or a peering or VPN path.
Custom mode VPC: VPC where you create and manage subnets explicitly instead of relying on automatically created defaults.
Network peering: Connection between networks that allows traffic flow without exposing everything through the public internet.
Firewall policy: Centralized traffic-control policy that can govern multiple firewall rules or network scopes.
What Google Cloud is really testing here
Google Cloud wants you to separate:
- network layout from traffic filtering
- subnet boundaries from route reachability
- peering or VPN connectivity from firewall permission
- default convenience from intentional network design
Fast network chooser
| If the question is mainly about… | Strongest first lane |
|---|---|
| explicit subnet planning and intentional IP layout | custom mode VPC |
| allowing or denying specific traffic | firewall rules or firewall policies |
| private traffic between networks without public internet routing | VPC peering or VPN, depending on the boundary |
| making one service reachable internally after deployment | route plus firewall plus target-network placement together |
Control-boundary mental model
The visual below is the fastest way to remember the order of decisions:
The key thing to notice is that firewall rules do not create the network path. First the networks must be connected in the right way. Only then do the firewall decisions control which traffic is allowed across that path.
Do not blur these controls together
| Control | What it really answers |
|---|---|
| VPC and subnet design | where resources live and how address space is organized |
| Firewall rules | which traffic is allowed or denied |
| Peering | whether two networks can exchange private traffic |
| VPN | how traffic reaches another network boundary securely across a broader path |
Candidates often pick a firewall answer when the real problem is that the networks are not connected at all, or they pick peering when the problem is really just blocked traffic inside an already connected path.
Peering versus VPN
| Question | VPC peering | VPN |
|---|---|---|
| Main purpose | private traffic between Google Cloud networks | secure private path across a broader network boundary |
| Strongest first when | both networks are already in the cloud and need direct private reach | the requirement crosses into another boundary such as on-premises or another environment |
| Common trap | assuming peering alone fixes all firewall issues | treating VPN as the first answer when the problem is really just cloud-to-cloud network design |
Troubleshooting order
When a network question gets noisy, use this order:
- Prove the networks are connected in the intended way.
- Check whether the subnets and address ranges make sense.
- Check firewall rules or policies.
- Only then decide whether the failure is in the workload, route, or service itself.
That sequence prevents a common ACE mistake: debugging packet filtering before proving the private path exists at all.
Common traps
| Trap | Better reading |
|---|---|
| “The firewall is open, so the networks must be connected.” | Allowed traffic still fails if peering or VPN was never established correctly. |
| “Peering means every possible path now works.” | Peering answers connectivity between networks, not every workload-specific policy decision. |
| “Custom mode VPC is only about naming.” | It is about deliberate subnet layout and address planning. |
| “VPN and peering are interchangeable.” | They solve different boundary problems even though both can provide private traffic paths. |
Harder scenario question
A team can reach resources within each VPC separately, but two VPCs still cannot communicate privately even though the firewall rules are already open for the right ports. Which lane is strongest first?
- A. Increase the machine type
- B. Check the network-connection path such as peering or VPN
- C. Rename the subnet
- D. Add Cloud Logging sinks
Correct answer: B. If the traffic policy is already open, the next question is whether the networks themselves are connected privately at all.
Decision order that usually wins
- First classify the problem as intentional subnet layout, traffic filtering, or private network connectivity.
- If the team wants deliberate subnet design, think custom mode VPC.
- If the question is about allowing or blocking traffic, think firewall rules and policies.
- If traffic still fails even though firewall rules look right, verify the private network path such as peering or VPN.
- ACE usually rewards fixing the network boundary first instead of changing compute or IAM settings.