This chapter covers Google Cloud's Virtual Private Cloud (VPC) networking — the foundational layer for connecting and isolating cloud resources. You'll learn how VPCs, subnets, and firewalls work together to create secure, scalable network architectures. For the Google Cloud Digital Leader (GCDL) exam, roughly 15-20% of questions touch on networking topics, with VPC and firewall rules being among the most frequently tested. Understanding these concepts is critical because they underpin nearly every GCP service deployment.
Jump to a section
Imagine a global company that rents a private office building (a VPC) in a city (the Google Cloud region). The building has its own address range, say 10.0.0.0/8, and no one outside can see inside. Inside, the building is divided into floors (subnets), each with a dedicated purpose: floor 1 for web servers (subnet 10.0.1.0/24), floor 2 for application servers (10.0.2.0/24), and floor 3 for databases (10.0.3.0/24). Each floor has its own hallway with numbered rooms (private IP addresses like 10.0.1.5). The building has a security desk at the main entrance (the firewall). The security guard enforces strict rules: only visitors from the internet (outside) can enter the lobby (ingress firewall rules), and only if they are on a pre-approved list (target tags and source IP ranges). Employees inside can move freely between floors (egress rules allow all traffic by default), but the guard can restrict movement if needed. The building also has a special phone line (Cloud NAT) so that employees can call out to the outside world, but outsiders cannot call in directly. If the company expands, it can add more floors (subnets) or even rent an adjacent building (VPC Network Peering) to connect to another VPC. This analogy shows how VPCs provide isolation, subnets organize resources, and firewalls control traffic with granular rules.
What is a VPC?
A Virtual Private Cloud (VPC) is a logically isolated section of Google Cloud where you can launch resources in a virtual network that you define. It is global in scope — a VPC spans all regions worldwide. Within a VPC, you create subnets, which are regional resources. This global nature means a single VPC can have subnets in multiple regions, and resources in different regions can communicate privately using internal IP addresses without traversing the public internet. Each VPC has a name and a set of firewall rules, routes, and VPN connections.
Subnets
Subnets are regional subdivisions of a VPC's IP address space. Each subnet is defined by a CIDR block (e.g., 10.0.1.0/24) and exists in a single region. You can have up to 10 subnets per VPC, but you can increase this quota. Subnets cannot span multiple regions; they are tied to the region where they are created. Resources like Compute Engine VMs, GKE clusters, and Cloud SQL instances are placed into subnets. Each VM gets a primary internal IP address from the subnet's range. You can also assign alias IP ranges (secondary CIDR blocks) to a subnet for containers or services like GKE pods.
Firewall Rules
Firewall rules control traffic to and from VM instances. They are stateful: if a connection is allowed in one direction, the return traffic is automatically allowed. Firewall rules are applied at the network level, not per instance, but you can target them using tags or service accounts. Each rule has:
Direction: ingress (inbound) or egress (outbound)
Priority: integer from 0 (highest) to 65535 (lowest). Default rules have priority 65535.
Action: allow or deny
Protocol and port: e.g., tcp:80, udp:53, or icmp
Source (for ingress) or destination (for egress): can be IP ranges (CIDR), tags, or service accounts
Target: applies to VMs with matching tags or service accounts
Default Rules
Every VPC comes with four default firewall rules that cannot be deleted: - default-allow-internal: Allows all traffic from within the same VPC (all protocols, all ports) for sources in the 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ranges (plus the subnet's primary range). - default-allow-ssh: Allows TCP 22 from 0.0.0.0/0 (all sources). - default-allow-rdp: Allows TCP 3389 from 0.0.0.0/0. - default-allow-icmp: Allows ICMP from 0.0.0.0/0.
You can modify these rules but not delete them. You can also create custom firewall rules with higher priority to override defaults.
Routes
Routes define the paths that packets take within a VPC. Each VPC has automatically generated system routes for the default internet gateway (0.0.0.0/0) and for each subnet's IP range. You can create custom static routes to direct traffic to specific destinations, such as a VPN gateway or a peered VPC. The longest prefix match (LPM) algorithm is used to determine which route applies.
VPC Peering
VPC Network Peering allows you to connect two VPCs so that resources in each can communicate using internal IP addresses. Peering is not transitive — if VPC A peers with VPC B and VPC B peers with VPC C, A cannot directly communicate with C unless they also peer. Peering is a one-to-one relationship; you must set it up from both sides. Traffic stays within Google's network and does not traverse the public internet.
Cloud NAT
Cloud NAT (Network Address Translation) allows VM instances without external IP addresses to access the internet for outbound connections. It translates the private IP of the VM to a public IP (or a range of public IPs) that you define. Inbound connections from the internet are not allowed through Cloud NAT. You configure Cloud NAT on a Cloud Router, which is associated with a region and a subnet. Cloud NAT is highly available within a region.
Private Google Access
Private Google Access allows VMs without external IPs to reach Google APIs and services (like Cloud Storage, BigQuery, etc.) using private IP addresses. When enabled on a subnet, traffic to Google APIs is routed through Google's internal network rather than the internet. This is configured per subnet and does not require a NAT gateway.
Shared VPC
Shared VPC allows you to share a VPC network across multiple projects in an organization. The host project contains the VPC and subnets, while service projects can use those subnets to create resources. This centralizes network management and security policies. Shared VPC requires organization-level IAM permissions.
VPC Flow Logs
VPC Flow Logs capture information about IP traffic going to and from network interfaces. They are useful for network monitoring, forensics, and security analysis. Flow logs are sampled (default is 1 per 10 packets) and can be exported to BigQuery, Cloud Storage, or Pub/Sub. Enabling flow logs incurs additional costs.
Hands-On: Creating a VPC with Subnets and Firewall Rules
Using gcloud:
# Create a custom VPC
gcloud compute networks create my-vpc --subnet-mode=custom
# Create a subnet in us-central1
gcloud compute networks subnets create my-subnet --network=my-vpc --region=us-central1 --range=10.0.1.0/24
# Create a firewall rule to allow HTTP traffic
gcloud compute firewall-rules create allow-http --network=my-vpc --allow=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=http-server
# Create a VM with the http-server tag
gcloud compute instances create my-vm --zone=us-central1-a --subnet=my-subnet --tags=http-serverInteraction with Other Services
VPCs interact with Cloud Load Balancing (which uses forwarding rules), Cloud VPN (which creates tunnels to on-premises), and Cloud Interconnect (dedicated connections). Firewall rules also apply to load balancer health checks and proxy-only subnets. Understanding these interactions is key for the GCDL exam.
Design IP Address Plan
First, determine the IP address range for your VPC. Choose a private IP range like 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. Avoid overlapping with on-premises networks if you plan to connect via VPN or Interconnect. Divide the range into subnets for each region where you will deploy resources. Each subnet must have a unique CIDR block within the VPC. For example, 10.0.1.0/24 for us-central1, 10.0.2.0/24 for europe-west1. Consider future growth: leave room for more subnets or larger ranges.
Create VPC and Subnets
Using the Google Cloud Console, gcloud CLI, or Terraform, create a VPC with custom subnet mode (recommended for production). Then create subnets in desired regions with appropriate CIDR blocks. Each subnet is regional and cannot be changed after creation. You can optionally enable Private Google Access on the subnet to allow VMs without external IPs to reach Google APIs. Also, you can set the flow logs sampling rate (default 0.5).
Define Firewall Rules
Create firewall rules to control traffic. For each rule, specify direction (ingress/egress), priority (0-65535), action (allow/deny), protocol and port, source/destination, and target. Use tags or service accounts to apply rules to specific VMs. Remember that default rules allow internal traffic and SSH/RDP/ICMP from anywhere. Override with higher priority rules. For example, to block SSH from a specific IP, create a deny rule with priority 1000.
Configure Routes and Gateways
By default, VPCs have routes for each subnet and a default route for internet access (0.0.0.0/0 via the default internet gateway). For hybrid connectivity, create custom routes to direct traffic to a VPN tunnel or Interconnect attachment. Use Cloud Router to dynamically exchange routes with on-premises networks via BGP. For outbound internet access without external IPs, configure Cloud NAT on a Cloud Router.
Deploy and Test Connectivity
Launch VM instances in the subnets. Verify that VMs can communicate internally by pinging private IPs. Test firewall rules by attempting to connect to allowed/denied ports. For internet access, check that VMs with external IPs can reach the internet, while those without can use Cloud NAT. Use VPC Flow Logs to monitor traffic and troubleshoot connectivity issues. Ensure that VPC Peering or Shared VPC is configured correctly if needed.
Enterprise Scenario 1: Multi-Region Web Application
A global e-commerce company deploys a web application across three regions (us-central1, europe-west1, asia-east1) for low latency. They create a single VPC with one subnet per region (10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24). They use a global HTTP(S) Load Balancer with backend services in each region. Firewall rules allow ingress HTTP/HTTPS from the load balancer's health check ranges (130.211.0.0/22 and 35.191.0.0/16) and from the internet. Internal traffic between application tiers uses the default-allow-internal rule. They enable VPC Flow Logs on subnets for security auditing. A common misconfiguration is forgetting to allow health check traffic, causing the load balancer to mark backends as unhealthy.
Scenario 2: Hybrid Connectivity with Shared VPC
A financial services firm connects its on-premises data center to GCP via Cloud VPN and Cloud Interconnect. They use Shared VPC to centralize network management: the host project contains the VPC, subnets, and firewall rules, while multiple service projects deploy VMs and GKE clusters. They configure Cloud Router with BGP to exchange routes. Firewall rules are carefully crafted to allow only necessary traffic between on-premises and cloud resources. They use IAM to restrict who can create firewall rules. A common issue is overlapping IP ranges between on-premises and cloud subnets, which breaks connectivity. They mitigate this by using a non-overlapping range like 10.200.0.0/16 for GCP.
Scenario 3: Serverless with Private Google Access
A startup uses Cloud Functions and Cloud Run with no VMs. They still need a VPC to enable Private Google Access for their serverless services to reach Cloud Storage and BigQuery privately. They create a VPC with a subnet and enable Private Google Access on that subnet. They then configure Serverless VPC Access to allow Cloud Functions to connect to the VPC. Firewall rules are minimal because no VMs exist. A common pitfall is forgetting that Private Google Access must be enabled per subnet, and that serverless services need a connector to use VPC resources.
What GCDL Tests
Objective 2.4 covers VPC, subnets, and firewalls. The exam focuses on:
Understanding that VPCs are global, subnets are regional.
Knowing the four default firewall rules and their purpose.
Recognizing that firewall rules are stateful and can be applied via tags or service accounts.
Understanding VPC Peering (non-transitive) and Shared VPC.
Knowing the difference between Cloud NAT and Private Google Access.
Common Wrong Answers
'Subnets are global' — The exam often presents a scenario where a subnet is created in one region, and a VM is launched in another region within the same subnet. The correct answer is that subnets are regional, so you must create a subnet in each region. Wrong answer: 'VMs in different regions can share the same subnet' (false).
'Firewall rules are applied to instances directly' — Candidates think rules are attached to VMs. Reality: rules are applied to the VPC network, targeting tags or service accounts.
'VPC Peering is transitive' — A question might describe VPC A peered with B, B peered with C, and ask if A can reach C. The correct answer is no, unless A and C also peer.
'Cloud NAT allows inbound connections' — The exam tests that Cloud NAT is outbound-only. Inbound connections require an external IP or Cloud Load Balancing.
Key Numbers and Terms
Priority range: 0 (highest) to 65535 (lowest). Default rules have priority 65535.
Default firewall rules: allow-internal, allow-ssh, allow-rdp, allow-icmp.
VPC Peering is not transitive.
Shared VPC requires organization-level IAM.
Private Google Access is enabled per subnet.
Cloud NAT requires Cloud Router.
Edge Cases
If you delete the default network, you lose the default firewall rules. You must recreate them manually.
Firewall rules with deny actions override allow rules with higher priority.
VPC Flow Logs sample packets; they are not a full packet capture.
Alias IP ranges allow multiple IPs per VM for containers.
Eliminating Wrong Answers
Read the question carefully: if it mentions 'global' for subnets, eliminate that answer. If it says 'transitive' for peering, eliminate. For firewall questions, check if the rule specifies a tag or service account — if the VM doesn't have it, the rule doesn't apply. Always remember that default rules allow internal traffic and SSH/RDP/ICMP from anywhere.
VPCs are global; subnets are regional.
Firewall rules are stateful and applied at the network level, targeting tags or service accounts.
Default firewall rules allow internal traffic and SSH/RDP/ICMP from anywhere.
VPC Peering is one-to-one and non-transitive.
Cloud NAT provides outbound internet access for VMs without external IPs.
Private Google Access enables access to Google APIs from VMs without external IPs.
Shared VPC centralizes network management across projects in an organization.
These come up on the exam all the time. Here's how to tell them apart.
Custom VPC
You define subnets manually with custom CIDR ranges.
Subnets are created only in regions you specify.
Provides full control over IP address planning.
Recommended for production environments.
Can create subnets with any private IP range (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
Auto Mode VPC
Google automatically creates subnets in each region using a predefined /20 range.
Subnets are created in every region automatically.
Less control; IP ranges are fixed (10.128.0.0/9).
Suitable for quick testing or small projects.
You can convert an auto mode VPC to custom, but not vice versa.
Mistake
Subnets are global resources like VPCs.
Correct
Subnets are regional. Each subnet exists in one region and cannot span regions. You must create a separate subnet for each region where you need resources.
Mistake
Firewall rules are applied to VM instances directly.
Correct
Firewall rules are applied to the VPC network and affect all instances in that network. They target instances using tags or service accounts, not by instance name.
Mistake
VPC Peering allows transitive routing between multiple VPCs.
Correct
VPC Peering is not transitive. If VPC A peers with B and B peers with C, A cannot communicate with C unless they also peer directly.
Mistake
Cloud NAT allows inbound connections from the internet.
Correct
Cloud NAT only supports outbound connections. Inbound connections from the internet are not possible through Cloud NAT; they require an external IP or load balancer.
Mistake
Default firewall rules can be deleted.
Correct
The four default firewall rules (allow-internal, allow-ssh, allow-rdp, allow-icmp) cannot be deleted. You can modify them but not remove them.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you cannot modify the IP CIDR range of an existing subnet. You must delete the subnet and recreate it with the desired range. This is why careful IP planning is essential before deploying resources.
You can configure Cloud NAT on a Cloud Router for the region and subnet. Cloud NAT will translate the VM's private IP to a public IP for outbound connections. Inbound connections from the internet are not possible without an external IP or load balancer.
No, each subnet is regional and must have a unique CIDR within the VPC. If you need the same IP range in multiple regions, you must create separate subnets with the same CIDR in each region, but they will be independent.
VPC Peering connects two VPCs (possibly in different projects) so they can communicate via internal IPs. Shared VPC allows you to share a single VPC's subnets with multiple service projects within the same organization. Shared VPC centralizes network management, while peering is more decentralized.
You assign a tag (e.g., 'web-server') to a VM instance when you create it. Then you create a firewall rule that targets that tag. The rule applies to all VMs with that tag. Tags are case-sensitive and up to 64 characters. You can also use service accounts as targets.
Priority is an integer from 0 (highest) to 65535 (lowest). Default rules have priority 65535. Custom rules with lower numbers take precedence. If two rules have the same priority, the deny rule takes precedence over allow.
VPC Flow Logs are sampled. The default sampling rate is 1 per 10 packets (0.5). You can adjust the sampling rate, but it will increase costs. Flow logs are not a full packet capture; they provide metadata about connections.
You've just covered GCP Network: VPC, Subnets, and Firewalls — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.
Done with this chapter?