GCP VPC Design and Networking Fundamentals for Exams

Mastering Virtual Private Cloud (VPC) design is non-negotiable for any Google Cloud certification, as it forms the bedrock of secure, performant, and scalable cloud architectures. Exam questions will test your ability to translate abstract requirements—like connecting services securely or enabling private internet access—into concrete GCP networking configurations. This guide moves beyond memorization to build the conceptual framework and decision-making skills you need to succeed.

Core Concept 1: VPC, Subnets, and Foundational Controls

Every Google Cloud resource that requires networking, like a Compute Engine VM or a GKE cluster, lives within a global Virtual Private Cloud (VPC) network. A VPC is a logically isolated virtual network partition with its own IP range, firewall rules, and routing tables. Your first critical design choice is between auto-mode and custom-mode VPCs.

An auto-mode VPC network is the default and is excellent for quick prototyping. Google Cloud automatically creates one subnet in each region with a predetermined IP range from the 10.128.0.0/9 CIDR block. This is convenient but inflexible; you cannot control the exact IP ranges of these subnets, which can lead to overlapping IP space if you later need to peer with other networks. In contrast, a custom-mode VPC network starts with no subnets, giving you complete control. You manually define each subnet's region and IP range (CIDR block), allowing for precise, non-overlapping designs that are essential for production environments and complex topologies involving VPC peering or hybrid connectivity via Cloud VPN or Cloud Interconnect. For any exam scenario implying long-term architecture, scalability, or interconnection, custom-mode is almost always the correct choice.

Within a VPC, you create regional subnets to contain your resources. A key advantage in GCP is that resources in different subnets within the same VPC can communicate directly using the VPC's internal routing; no gateway or additional configuration is required. Traffic control is then managed by firewall rules, which are stateful. Every rule consists of a priority (from 0, the highest, to 65535, the lowest), a direction (ingress or egress), an action (allow or deny), a target (which instances the rule applies to), and a protocol/port specification. The exam will test your understanding of rule evaluation: the highest priority rule that matches the traffic packet is applied, and an implicit "deny all" ingress rule and a default "allow all" egress rule exist at priority 65535. To apply rules selectively, you use network tags, which are metadata key-value pairs attached to VM instances. A firewall rule with a target tag will only apply to instances bearing that tag, enabling micro-segmentation (e.g., applying a "web-server" tag to allow HTTP traffic only to specific VMs).

Core Concept 2: Controlling Access to and from the Internet

Not all resources should have public IP addresses. GCP provides robust mechanisms for controlled external access. For outbound internet connectivity from instances without public IPs, you configure Cloud NAT (Network Address Translation). Cloud NAT allows instances in a subnet to reach the internet to download patches or access APIs, but prevents unsolicited inbound connections from the internet, significantly improving security. You manage Cloud NAT through a Cloud Router, which advertises the NAT gateway's IP for the subnet.

For private, Google-scale connectivity, you must understand Private Google Access. When enabled on a subnet, this feature allows instances with only private IP addresses (and no public IPs) to reach the external IP addresses of Google APIs and services—like Cloud Storage or BigQuery—through Google's internal network, not the public internet. This is crucial for secure, high-performance data processing pipelines. A related and commonly tested concept is Private Google Access for on-premises hosts, which extends this private access to your own data center when connected via Cloud Interconnect or VPN, allowing on-premise systems to use private IPs to call Google APIs.

Inbound access is managed through a combination of firewall rules and, if required, external load balancers. For exam purposes, remember that an instance needs a public IP (ephemeral or static) to be directly reachable from the internet, and corresponding ingress firewall rules must allow the traffic. Best practice is to avoid direct public IP assignment to most VMs and instead use managed services like Load Balancers as the public entry point.

Core Concept 3: Connecting Networks and Projects

Real-world deployments span multiple VPCs and Google Cloud projects. GCP offers two primary models for this: Shared VPC and VPC Network Peering.

Shared VPC is the hierarchical model for multi-project connectivity within an organization. You designate a host project containing the Shared VPC network and attach one or more service projects. Network administrators centrally control the shared network, subnets, and firewall policies in the host project. Teams in service projects can then deploy their resources (VMs, GKE clusters) into these shared subnets. This model enforces consistent network security and governance, making it the recommended choice for enterprise environments where a central IT team manages the network.

VPC Network Peering creates a direct, non-hierarchical connection between two VPC networks, allowing them to communicate using private RFC 1918 addresses. It's simpler than Shared VPC but comes with critical VPC peering limitations you must memorize:

• Transitivity is NOT supported. If VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot communicate with VPC C through VPC B. You must create a direct peering between A and C.
• Overlapping IP ranges prevent peering. Peered VPCs cannot have matching or overlapping CIDR blocks.
• Peered connections cannot be created between Shared VPC host projects. A Shared VPC can peer with a standard VPC or another Shared VPC, but only from the host project.

Choosing between Shared VPC and Peering is a classic exam question. Use Shared VPC for a centralized, hierarchical model within an organization. Use VPC Peering for connecting networks in a more decentralized, mesh-like fashion, often across different organizations or when networks are in projects that cannot be restructured as service projects.

Core Concept 4: Routing and Hybrid Connectivity Design

For advanced topologies, especially those involving on-premises data centers, you need to manage dynamic routing. Cloud Router is a fully managed service that runs the Border Gateway Protocol (BGP) for you. It is a critical component for Cloud VPN and Cloud Interconnect, exchanging routes between your VPC network and your on-premises network. When you create a HA VPN tunnel or a VLAN attachment for Interconnect, you configure a Cloud Router to learn your on-premises subnet routes dynamically and advertise your VPC subnet routes back.

Designing for hybrid connectivity requires synthesizing multiple concepts. A typical exam scenario might ask you to design a network where a web tier in one subnet can be reached from the internet via a load balancer, an application tier in another subnet has no public IP but can access Google Cloud APIs privately, and both can query a database in an on-premises data center. The solution involves: a custom-mode VPC with specific subnet ranges; firewall rules with tags to segment tiers; Cloud NAT for the app tier's outbound patches; Private Google Access enabled on its subnet; and a Cloud VPN/Interconnect connection with Cloud Router to manage dynamic routing between the VPC and the on-premises network.

Common Pitfalls

1. Misapplying Firewall Rule Priorities: A common mistake is creating a high-priority "deny all" rule that inadvertently blocks all traffic, or assuming a lower-priority "allow" rule will be evaluated after an implicit deny. Remember: the first matching rule (with the lowest priority number) wins. Always structure your rules from most specific (low priority number) to most general (high priority number).

1. Overlooking Peering Non-Transitivity: This is a frequent exam trap in multi-VPC scenarios. If a question presents a hub-and-spoke topology where the hub VPC is peered with multiple spokes, you cannot assume the spokes can talk to each other. Without direct peering, traffic between spokes must route through the internet or use a different architecture like a Shared VPC.

1. Confusing Private Google Access with Private API Access: Private Google Access only enables connectivity from your private instances to Google's public APIs and services. It does not make your Google Cloud services (like a Cloud SQL database) private. To make a service like Cloud SQL accessible only via private IP within your VPC, you must configure private services access, which is a separate mechanism involving VPC peering with Google's service producer network.

1. Choosing Auto-Mode for Interconnected Designs: Selecting an auto-mode VPC in a scenario that later requires VPC peering or hybrid connectivity will cause IP range conflicts, as you cannot change the auto-allocated subnets. This is a fundamental design flaw the exams will test. For any design hinting at future growth or interconnection, start with a custom-mode VPC.

Summary

• Choose Custom-Mode VPCs for production and any design requiring precise IP management, peering, or hybrid connectivity. Auto-mode is for simple, isolated prototyping.
• Control traffic flow with stateful firewall rules evaluated by priority, and use network tags to apply rules to specific groups of instances for micro-segmentation.
• Enable Private Google Access on subnets to allow instances without public IPs to reach Google APIs and services privately. Use Cloud NAT to provide outbound internet access for such instances.
• Use Shared VPC for centralized, hierarchical network management across multiple projects within an organization. Use VPC Peering for direct, non-transitive connections between VPCs, ensuring their IP ranges do not overlap.
• Integrate hybrid networks using Cloud VPN or Interconnect, managed by Cloud Router for dynamic BGP routing, to seamlessly connect your VPC to on-premises data centers.