Once you have more than one VPC in play, or you need to bring traffic in from outside Google Cloud, you have to pick a connection method. The Professional Cloud Architect exam tests four of them: Shared VPC, VPC Peering, Cloud VPN, and Cloud Interconnect. Each one solves a different problem, and the exam expects you to match the right tool to the scenario.
Shared VPC lets you extend a network from one project (the host project) to other projects (service projects) within the same organization. Resources across those service projects can then communicate over a single, centrally managed VPC.
The pattern is straightforward. The host project owns the VPC and its subnets. Service projects A, B, C, and so on contain the actual workloads, things like Compute Engine VMs, GKE clusters, Cloud Run services, Dataflow pipelines. Instead of each project building its own isolated network, every service project plugs into the network managed by the host project.
An important architectural rule: the host project should be dedicated to network resource control only. You should not run pipelines, VMs, or other workloads inside the host project. Keep it as a clean network-administration project, and put everything that consumes the network in service projects.
The benefits show up most clearly in larger organizations:
There is one specific permissions detail the Professional Cloud Architect exam likes to test on Shared VPC. Service accounts living in service projects do not automatically get to use the shared network. They must be granted the compute.networkUser role on the shared VPC subnets in the host project.
A concrete example: you have a Dataflow pipeline running in a service project, and it needs to deploy onto a subnet in the shared VPC. The service account that the pipeline runs as needs compute.networkUser on that subnet, granted from the host project. Without that role, the pipeline cannot consume the network, even if the project itself is attached as a service project.
The same rule applies to any workload in a service project that needs network access: GKE node pools, Compute Engine instances, Cloud Functions on a VPC connector. Grant the running service account compute.networkUser on the relevant subnetworks in the host project.
VPC Peering connects two VPC networks so they can communicate using internal, private IP addresses, over a low-latency, high-bandwidth path inside Google's network. No public internet, no VPN tunnel.
The shape of the connection is symmetric. VPC Network A and VPC Network B each have their own subnets. A peering connection between them creates a private bridge, and resources on either side can reach each other over internal IPs.
The most useful property of peering, especially for the Professional Cloud Architect exam, is that the two VPCs can belong to the same organization or to completely different organizations. That makes peering the right choice when two independently managed networks need a private connection without merging into a Shared VPC. Each side keeps its own network administration. They just agree to talk.
Cloud VPN is what you reach for when you need to connect something outside of Google Cloud to a VPC inside Google Cloud. Traffic is encrypted, but it travels over the public internet.
The three canonical use cases are:
The single most important attribute to remember for the exam: Cloud VPN is encrypted, but it goes over the public internet. That is the trade-off. It is fast to set up and inexpensive, but the underlying transport is the open internet.
Cloud Interconnect is a separate Google Cloud service that provides a secure, private, high-bandwidth connection between networks, usually from on-premises to Google Cloud. Unlike Cloud VPN, Interconnect bypasses the public internet entirely.
That gives you two things VPN cannot match: consistent low-latency performance, and a private path that never touches the public internet. Those properties matter for a specific class of workloads:
The Professional Cloud Architect exam expects you to know that Cloud Interconnect comes in three flavors, and to be able to pick the right one for a given scenario.
Dedicated Interconnect is a direct physical connection between your on-premises data center and Google's network. This is the option for the highest bandwidth, lowest latency, and the strongest private connectivity guarantees. Pick it when you need consistent performance for continuous large-scale data transfers or critical operations like disaster recovery.
Partner Interconnect connects you to Google's network through a supported third-party service provider instead of directly. This is the right answer when lower bandwidth is acceptable, or when your data center is not physically near a Google Cloud edge location and you need geographic flexibility. You give up some of the control and performance of Dedicated Interconnect in exchange for easier reach.
Cross-Cloud Interconnect is a direct connection between Google Cloud and another cloud provider's network. This is the multi-cloud answer when you need a secure, high-performance link between clouds without crossing the public internet.
Most Professional Cloud Architect exam questions in this area come down to recognizing which of these four tools fits the scenario. The decision logic:
If you can run that decision tree fluently, the connectivity questions on the exam become very fast.
My Professional Cloud Architect course covers connecting VPCs alongside the rest of the networking material.
