Google Cloud gives you four main ways to connect a VPC to other networks, and the Professional Cloud Database Engineer exam expects you to know which one fits a given scenario. Two of them connect networks inside Google Cloud, Shared VPC and VPC Peering, and two of them reach outside Google Cloud to on-premises data centers, other cloud providers, or remote offices, Cloud VPN and Cloud Interconnect. The exam questions tend to come down to telling these apart, because more than one option will technically establish connectivity but only one matches the stated requirements around management, performance, or whether traffic can touch the public internet. The sections below walk through each option and then summarize when to reach for which.
Shared VPC lets you extend the network from one project, called the host project, to other projects, called service projects, within the same organization. The host project owns the Shared VPC network and its subnets, and it should be dedicated to network resource control only. The pipelines, virtual machines, and other workloads that need the network live in the service projects. Instead of each project building and maintaining its own isolated network, the service projects connect to the single network managed by the host project and use its subnets.
The benefits are centralized network management, unified security policies, and cost efficiency. You define IP ranges, firewall rules, and the rest of the network configuration in one place rather than across many separate VPCs, you apply consistent security policies across all the service projects, and you avoid duplicating shared resources like firewalls and load balancers. This makes Shared VPC the natural fit for larger organizations with many projects that want one team to govern the network while other teams deploy into it.
There is a specific permissions detail worth knowing for the Professional Cloud Database Engineer exam. Service accounts in the service projects must be granted the compute.networkUser role on the Shared VPC subnets in the host project before they can use the network. For example, if you have a Dataflow pipeline running in a service project, you grant that pipeline's service account the compute.networkUser role on the relevant subnets in the host project so it can deploy and communicate privately over the Shared VPC. Without that role on the subnets, the service account cannot use the network infrastructure the host project provides.
VPC Peering connects two VPC networks so they can communicate with each other using internal, private IP addresses, without sending traffic over the public internet. Each network keeps its own subnets, and the peering connection creates a direct private path between them. A useful property for scenario questions is that the two peered VPCs can belong to the same organization or to different organizations.
The distinction from Shared VPC matters here. Shared VPC is about one centrally managed network shared across projects under a single host project. VPC Peering connects two networks that are independently managed and stay that way, each side keeps control of its own configuration. So when a question describes two separately owned or separately administered VPC networks that need private connectivity, especially across organizations, VPC Peering is the match rather than Shared VPC.
Cloud VPN connects a network outside Google Cloud to a Cloud VPC. That outside network can be an on-premises data center, another cloud provider's network, or a remote office network. The connection is encrypted, but it travels over the public internet. The common use cases are hybrid setups, where you securely connect an on-premises data center to your VPC so you can move workloads and data between the two, multi-cloud setups, where you connect your Google Cloud VPC to a VPC in another cloud provider to avoid vendor lock-in, and remote office access, where workers on an office network reach resources in Google Cloud securely. The point of Cloud VPN is to securely extend the reach of your network beyond Google Cloud when running the traffic over the public internet, with encryption, is acceptable.
Cloud Interconnect is a separate Google Cloud service, but it belongs in this comparison because it also connects your VPC to on-premises or other networks. It provides a secure, private, high-bandwidth connection from on-premises to Google Cloud, and it bypasses the public internet entirely. That gives it consistent, low-latency performance along with stronger security and reliability than a connection that traverses the internet.
Those properties make it the right choice for a specific set of demands. It suits low-latency, high-throughput, reliable connections for critical workloads, disaster recovery where data or systems are mirrored across locations, and large-scale data replication tasks such as feeding Datastream continuously and securely from on-premises into Google Cloud. It is also the answer when public internet exposure is simply unacceptable, which often comes up in industries with strict compliance or security requirements that mandate a private path.
Cloud Interconnect comes in three types. Dedicated Interconnect is a direct physical connection between your on-premises network and Google's network, best when you need high bandwidth, low latency, and direct private connectivity, for cases like continuous large-scale data transfers or disaster recovery. Partner Interconnect runs through a supported third-party service provider instead of connecting to Google directly, which suits situations where lower bandwidth is acceptable or your data center is not near a Google Cloud edge location and you need geographic flexibility. Cross-Cloud Interconnect provides a direct connection between Google Cloud and another cloud provider's network, valuable when you use multiple clouds and want a secure, high-performance way to move data between them without the public internet.
For the exam, it helps to map each option to its trigger. Use Shared VPC for centralized network management and consistent security policies across multiple projects in one organization. Use VPC Peering for direct, private connections between independently managed VPC networks, whether in the same organization or different ones. Use Cloud VPN to securely connect on-premises networks or networks in other cloud providers to your Cloud VPCs, accepting encrypted traffic over the public internet. Use Cloud Interconnect for secure, high-bandwidth, low-latency connections from on-premises to Google Cloud, which is the option for data replication and critical applications where consistent performance matters and the public internet is not an option. The two internal options differ on whether the network is centrally shared or independently managed, and the two external options differ on whether traffic may cross the public internet or must stay on a private path.
Our Professional Cloud Database Engineer course covers connecting a VPC to other networks alongside VPC fundamentals and the Shared VPC permissions model, with practice questions that drill these distinctions.
