Networking is one of those topics that a lot of people skip or skim when studying for a Google Cloud certification. But VPC concepts come up on the Professional Data Engineer (PDE) exam, and understanding how your data moves between services, projects, and external networks is a big part of building real systems on GCP.
Cloud VPC is how you define and control the network your GCP resources live on. I think that one sentence captures the purpose of Cloud VPC well, and every concept in this post maps back to it: how the network is structured, how resources communicate within it, and how it connects to the outside world.
This post covers VPC fundamentals, IP addressing, Private Google Access, Private Service Connect, the different ways to connect VPCs to other networks, and project isolation techniques. You could see questions about any of these on the exam.
A Virtual Private Cloud is a virtualized version of a traditional physical network. A physical network relies on tangible hardware like routers, switches, servers, and cables to enable communication between devices. A virtual network abstracts all of that into software-defined elements. You are dealing with virtual firewalls, network policies, and segmentation, all managed through software rather than hardware.
Cloud VPC is a logically isolated virtual network within GCP. You can think of it as having your own private network carved out within GCP's infrastructure. It functions much like a physical network, but everything is virtualized, which gives you greater flexibility and control.
Here is how a VPC fits into the overall structure of GCP. At the highest level, you have GCP itself. Within GCP, you organize your resources into projects. Inside a project, you can create one or more VPCs. Within a VPC, you define subnets, which are further subdivisions that let you segment your network and control traffic flow more granularly.
VPC subnets can span multiple regions. You could have two subnets in the US-Central1 region and one subnet in the US-East1 region, all within the same VPC. This gives you flexibility to deploy resources across different geographical locations while maintaining network isolation and control.
You need to understand IP addresses for certain parts of the exam and for VPC concepts in general, so let's talk about them.
IP addresses are like unique phone numbers for devices connected to a network. They allow devices to send and receive data. There are two main versions: IPv4 and IPv6. IPv4 is the older, more common format. IPv6 is the newer version with a much larger address space. For the exam, you will mostly focus on IPv4 since it is still the most widely used.
Within a VPC, you use private IP addresses. These are specific ranges reserved for use within private networks, whether that is a home network, an office network, or your VPC. The establishment of these private IP addresses through your VPC and its subnets is what enables communication between your resources. It is like having a dedicated phone system within your organization where everyone has an internal extension.
There are three common private IP address ranges you will encounter.
10.0.0.0/8 offers over 16 million IP addresses. It is often used in large private networks or corporate environments where you need to accommodate a large number of devices.
172.16.0.0/12 provides around a million IP addresses. It is a good fit for medium-sized private networks typically found in small to medium enterprises.
192.168.0.0/16 is the most familiar range for many people because it is commonly used in home networks and small office routers. You might recognize the 192.168 prefix from your own home network. It offers about 65,000 IP addresses, which is still sufficient for smaller environments.
CIDR notation is a concise way to represent IP address ranges, and you will see it frequently when working with VPCs and subnets. You may be asked to adjust the IP range of a subnet on the exam, so this is useful knowledge to have.
In CIDR notation, an IP address is followed by a slash and a number, like x.x.x.x/y. The numbers before the slash represent the starting IP address of the network range. The number after the slash is the prefix length, which tells you how many bits are used for the network part of the address and determines the number of possible IP addresses within that range.
Here is how to calculate the number of possible IP addresses in a subnet. Identify the number after the slash. Subtract it from 32, since IPv4 addresses have 32 bits. Calculate 2 to the power of that result. That gives you the total number of possible IP addresses.
For example, take 192.168.0.0/12. The prefix length is 12. 32 minus 12 is 20, and 2 to the power of 20 is a little over a million. So this range can accommodate over 1 million IP addresses.
Subnets are defined at the region level, and you specify the IP range using CIDR notation. There are a couple of key rules to keep in mind.
First, the subnet's IP range needs to stay within the boundaries of your VPC's overall range. If your VPC has a CIDR block of 10.0.0.0/16, your subnets need to have IP ranges that fit within that, like 10.0.1.0/24 or 10.0.2.0/24.
Second, subnet IP ranges cannot overlap with each other within the same VPC. This prevents IP address conflicts and ensures that traffic is routed correctly.
Another thing worth knowing is that if you run out of IP addresses in your subnet, you can expand its IP range without having to delete it and recreate it.
And as a general rule, do not use 0.0.0.0/0. It represents the default route for all IP addresses. It is an invalid IP address range for a subnet.
This is another topic that could show up on the exam. Enabling Private Google Access allows your virtual machines to securely interact with Google services without the need for public IP addresses. This enhances security by keeping your internal resources isolated from the public internet.
Consider a VPC with a subnet that has Private Google Access enabled. Any VM in that subnet, even if it does not have an external IP address, can connect with Google APIs. It is like having a dedicated private pathway from your VM directly to Google's services.
In contrast, if a subnet does not have Private Google Access enabled, any VM that needs Google APIs must have a public IP address and traverse the public internet to reach them.
Private Google Access lets you use Google Cloud services while ensuring that your internal VMs remain shielded from the public internet, because they can operate with only internal private IPs within your VPC network.
Private Service Connect, or PSC, is similar to Private Google Access but serves a different purpose. PSC is designed to create private internal connections between services within your VPC, and it is also flexible enough to connect to services outside of your VPC.
Consider a Cloud Run instance within a private subnet that is configured with an internal IP. It does not have a direct route to external services. A PSC endpoint in your VPC enables that Cloud Run instance to securely connect to other Google Cloud services like Composer or Cloud SQL without needing public IPs or going over the public internet. And since PSC can also be extended to connect with services outside of Google Cloud, Cloud Run could use PSC to securely reach certain third-party APIs while staying within the private network environment.
Let's look at a more concrete use case. A new file is uploaded to Cloud Storage, which triggers a Cloud Function. That Cloud Function needs to communicate with a Cloud Composer environment, but the Composer environment is hosted in a private subnet within a VPC and has no internet access. The Cloud Function cannot connect directly.
This is where Private Service Connect comes in. With PSC, the Cloud Function establishes a secure private connection to Cloud Composer through a PSC endpoint in the VPC. This allows the Cloud Function to use the Airflow REST API over the private connection to trigger a specific DAG that processes the uploaded file. All communication remains internal with no need for public IPs or internet access. The PSC endpoint is what makes this architecture work. It allows the Cloud Function to access Composer securely and privately while keeping the environment isolated from the public internet.
These two features have something in common. They both enable you to connect with Google services without public IPs, and they both enhance network security. But they have distinct purposes, and the distinction matters.
Private Google Access is designed for outbound access from a private subnet to Google APIs. If you have a VM or service with only internal IP addresses in a private subnet, Private Google Access allows it to reach Google APIs securely without needing a public IP. However, Private Google Access is one-directional. It does not provide a way to handle inbound connectivity between services.
Private Service Connect focuses on private internal communication between services. It creates a private connection that allows one service to reach another securely without traversing the public internet. Unlike Private Google Access, PSC is not limited to outbound access to Google APIs. It allows for private connectivity between services both within the same VPC and across VPCs.
The short version: Private Google Access enables secure outbound connections to Google APIs from private subnets. Private Service Connect ensures private internal communication between services, providing the inbound connectivity that Private Google Access does not have.
If you see a PDE exam question about connecting a service in a private subnet to other GCP services or third-party APIs without public IPs, and the scenario involves two-way or service-to-service communication, the answer will almost certainly involve Private Service Connect.
This section covers the different ways to connect your VPC to other networks in GCP or outside of GCP. Understanding your specific requirements, or the requirements presented in an exam question, is important for selecting the right option. Each method has its own strengths, and they could all show up on the exam.
Shared VPC is a tool for simplifying network management across multiple projects. It allows you to extend the network from one project (the host project) to other projects (the service projects) within the same organization, enabling seamless communication between GCP services in those projects.
The host project should be dedicated to network resource control only. Other services that need to use the shared VPC should live in the service projects, not the host project.
The host project acts as the central hub, housing the shared VPC network and its subnets. Service projects represent different teams or departments within your organization. Instead of each project building and maintaining its own isolated network, they connect to the central network managed by the host project. It is like multiple departments sharing a common infrastructure.
The big benefits here are centralized network management (one place to define your network configuration, IP ranges, and firewall rules instead of juggling multiple VPCs), unified security policies across all your service projects, and cost efficiency through shared resources like firewalls and load balancers. Shared VPC is a good way to streamline your network architecture, especially in larger organizations with multiple projects.
Something to note for the exam: Service accounts in a service project must be granted the compute.networkUser role on the shared VPC subnets within the host project in order to access network resources. For example, if you have a Dataflow pipeline in a service project, you have to grant its service account the compute.networkUser role specifically on the subnets within the host project. Without this, the Dataflow pipeline cannot run or interact with network resources in the shared VPC. This is the kind of detail the exam likes to test.
VPC Peering enables communication between two separate VPC networks using internal private IP addresses. This is a different situation from Shared VPC. Rather than creating a shared network, you are connecting two independently created VPC networks.
A peering connection creates a direct communication pathway between the two networks. You can think of it as building a secure private bridge between two separate VPCs. Resources within each VPC can communicate with each other using their internal private IP addresses without traversing the public internet.
One nice thing about VPC Peering is that it works for VPCs within the same organization or across different organizations.
Cloud VPN connects an on-premises network, another cloud provider's network, or a remote office network to a Cloud VPC in GCP. There are three main use cases to keep in mind.
Hybrid. You have an on-premises data center, the traditional infrastructure that many businesses still rely on. Cloud VPN can securely connect this on-prem network to your VPC in GCP, creating a hybrid environment.
Multi-cloud. Cloud VPN can connect your GCP VPC to a VPC in another cloud provider's environment, allowing you to build a multi-cloud architecture where you leverage the strengths of different clouds.
Remote office. Similar to the hybrid approach, this provides remote workers on an office network with secure access to resources and applications in GCP.
The key distinction here is that Cloud VPN securely extends the reach of your network outside of GCP. You are not talking about connecting VPCs within GCP. You are talking about VPCs in other clouds or non-VPC networks entirely.
Cloud Interconnect is actually a separate GCP service. It is not part of Cloud VPC, but I am including it here because it relates to connecting your VPC to on-prem or other external networks, and if it shows up on the exam, it would likely show up in that context.
Cloud Interconnect provides a secure, private, high-bandwidth connection from your on-prem environment to GCP. It bypasses the public internet, which enhances both security and reliability, especially for sensitive or critical data transfers. It also provides consistent low-latency performance, which matters for tasks like large-scale data replication, disaster recovery, and real-time processing.
Common use cases include low-latency and high-throughput scenarios, disaster recovery where you need to mirror data across locations, data replication tasks (such as with Datastream), and any scenario where public internet exposure is unacceptable due to strict compliance or security requirements.
There are three types of Cloud Interconnect, and each provides a different balance of performance, control, and flexibility.
Dedicated Interconnect provides a direct physical connection between your on-prem data center and Google's network. It is the right choice when you need high bandwidth, low latency, and a private connection for things like large data transfers or critical operations.
Partner Interconnect lets you connect through a supported third-party service provider instead of connecting directly to Google. This is a good fit if lower bandwidth is acceptable or if your data center is not close to a GCP edge location and you need geographic flexibility. You get private connectivity without the same level of control or performance as Dedicated Interconnect.
Cross-Cloud Interconnect provides a direct connection between GCP and another cloud provider's network. It is useful if your organization uses multiple clouds and needs a secure way to move data between them while avoiding the public internet.
Here is a quick recap so you have a high-level view of when to use each option.
If you need centralized network management and consistent security across multiple projects, go with Shared VPC. When you need direct private connections between independent VPC networks, either within the same organization or across organizations, go with VPC Peering. To securely bridge on-prem networks or other cloud providers with your Cloud VPCs (anything outside of GCP), go with Cloud VPN. For secure, high-bandwidth, low-latency connections from on-prem to GCP, especially for data replication or critical applications where consistent performance matters, go with Cloud Interconnect.
Understanding which option fits which scenario is exactly the kind of question you could see on the PDE exam, so it is worth internalizing these distinctions.
One way to achieve secure isolation between projects is to create separate VPCs in each project and make sure there is no peering or routing configured between them. This works at the network layer.
Consider Project A with VPC Network A and Project B with VPC Network B. Each VPC has its own subnets, but they have no peering or routing connections crossing between them. Traffic cannot flow directly between the VPCs because there is no network relationship linking them. No peering, no shared routes. This creates a network boundary that prevents accidental or unauthorized access across projects.
This method is commonly used to separate different environments or departments and can help meet security and compliance requirements.
VPC Service Controls provide isolation at the service layer rather than the network layer. With VPC Service Controls, you can create a security perimeter around each project. This perimeter acts as a protective boundary to prevent data exfiltration and to ensure that resources in one project cannot access resources in another project.
Consider Project A running Cloud Functions, Dataflow, and Cloud Run within VPC Network A, and Project B running Compute Engine, App Engine, and Dataproc within VPC Network B. By setting up service control perimeters around each project, resources inside Project A are restricted from accessing resources in Project B and vice versa. Each project operates securely within its own boundaries with no cross-project data leakage.
VPC Service Controls work at the service layer, adding an extra layer of isolation that you can use on top of network-level isolation. You could use both approaches together to secure sensitive resources across projects.
For the exam, VPC Service Controls is probably a bit more likely to show up as a question since it is a distinct GCP feature, but network-layer isolation through separate VPCs is worth understanding as well. Either could appear.
Cloud VPC is how you define, control, and secure the network layer of your GCP environment. The exam-relevant concepts to focus on are how VPCs and subnets are structured (including IP ranges and CIDR notation), Private Google Access versus Private Service Connect and when to use each, the four main options for connecting to other networks (Shared VPC, VPC Peering, Cloud VPN, and Cloud Interconnect), and project isolation techniques at both the network and service layers.
This was a longer topic, but it covers a lot of ground that is worth knowing for the PDE exam and for working with GCP in general. Hope it was helpful. Thanks for reading.
