Private connectivity is the technology that lets your cloud resources talk to each other and to Google's own services without ever sending data across the public internet. It matters for the PCSE exam because security engineers must design networks that are both fast and safe, and the exam tests your ability to choose the right private connection for each business need.
Jump to a section
A simple way to picture Private Connectivity: VPC Peering, VPN, and Private Google Access
A city apartment building has a central mailroom in the lobby. Each flat has its own locked mailbox inside this room. Residents can access their mailbox from the building's internal hallway without ever going outside. This is VPC Peering: a private, direct hallway between two trusted networks (the flats) inside the same building (Google Cloud), offering fast, internal mail delivery with no public street traffic.
Now consider a different scenario. Your friend lives in a separate building across the street. Their building has its own locked mailroom, but the two buildings are not connected by an internal tunnel. To exchange a letter, you must walk outside onto the public pavement, cross the street, and enter your friend's lobby. Your letter is inside an envelope (encrypted), but it travels on the open street where anyone could see the envelope's address. This is a Cloud VPN: an encrypted tunnel over the public internet that connects two separate networks (different buildings) securely, but the traffic still travels across the public road.
Finally, imagine a delivery driver bringing a package directly to your apartment door from an online store. The driver never enters the building's mailroom; they use a special internal service corridor granted by the building management. Your apartment gets the package without the driver ever touching the public street or the shared mailroom. This is Private Google Access: allowing resources in your building (VPC) to reach Google's own services (the store) without sending traffic over the public internet. The building management (Google Cloud) gives your resource a private pass.
When you build applications in Google Cloud, your virtual machines and databases live inside a Virtual Private Cloud (VPC). A VPC is your own private, isolated network within Google's data centres. Think of it as your own gated community in the cloud. By default, resources inside the same VPC can communicate with each other freely, but they cannot talk to resources in other VPCs or to Google's public APIs (like BigQuery or Cloud Storage) without a configuration change.
This chapter covers three ways to establish private connectivity: VPC Peering, Cloud VPN, and Private Google Access. Each one solves a different problem.
VPC Peering connects two VPCs directly so they behave as if they were one network. Imagine you and your neighbour decide to knock a door through the shared wall between your two houses. Now you can walk into each other's living rooms without stepping outside. VPC Peering does not require a VPN or a physical cable. It uses Google's own high-speed backbone inside its data centres. All traffic stays within Google's network, never touching the public internet. Google charges no bandwidth cost for peered traffic that stays within the same region. For the exam, remember that VPC Peering is transitive only if explicitly configured — meaning if VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot automatically reach VPC C through VPC B unless you set up a separate peering between A and C. This is called non-transitive peering.
Cloud VPN creates an encrypted tunnel between your on-premises network (your office or data centre) and your Google Cloud VPC over the public internet. Think of this as a secure, underground passage built under a busy public road. Your data packets are wrapped in a layer of encryption (using IPsec protocol) so that even if someone intercepts them on the internet, they cannot read the contents. There are two types of Cloud VPN:
Classic VPN: an older style that uses a single tunnel and supports static routing. It is simpler but less flexible.
HA VPN (High Availability VPN): a modern, redundant setup that uses two tunnels (one active, one standby) to ensure your connection stays up even if one tunnel fails. The exam loves to test that HA VPN provides 99.99% availability and uses dynamic routing via BGP (Border Gateway Protocol).
Cloud VPN is a good choice when you need to connect a physical location to the cloud with strong encryption, but you accept that traffic travels over the public internet, which can be slower and less reliable than a dedicated link.
Private Google Access (PGA) is the simplest of the three. It allows resources in your VPC (like a virtual machine or a container) to reach Google's own public APIs and services (such as Cloud Storage, BigQuery, or Cloud Logging) using only internal IP addresses. Normally, if your VM wants to talk to BigQuery, it must have a public IP address and send traffic out to the internet. With PGA, the VM keeps only a private IP address, and Google Cloud routes the traffic internally across its own backbone. The traffic never leaves Google's network. This is not just about security — it also saves you money because egress (outbound) traffic over the internet usually costs more than internal traffic.
The exam frequently tests the distinction between Private Google Access and Private Services Access. Private Google Access is for VMs reaching Google APIs. Private Services Access is for VMs reaching Google-managed services like Memorystore or Cloud SQL, and it requires a separate VPC peering connection called Service Networking. Do not confuse these two.
Finally, there is Cloud Interconnect. This is a premium option that provides a direct, physical cable from your on-premises network into Google's network. It bypasses the public internet entirely. There are two flavours:
Dedicated Interconnect: You get one or more dedicated fibre connections. It offers 10 Gbps or 100 Gbps per connection.
Partner Interconnect: You connect through a third-party service provider who already has a connection to Google.
The exam tests that Cloud Interconnect is the fastest and most reliable option, and that it requires a Service Level Agreement (SLA) of 99.99% or higher. However, it is also the most expensive and takes weeks to provision.
In summary, the hierarchy of private connectivity from least to most reliable (and least to most expensive) is: Cloud VPN, then VPC Peering, then Cloud Interconnect. Private Google Access is a feature, not a direct connection between networks, but it complements all of these.
Identify the source and target networks
Determine what you are connecting: is it two VPCs (use VPC Peering), a VPC to an on-premises network (use Cloud VPN or Cloud Interconnect), or a VPC to Google APIs (use Private Google Access)? This step dictates all subsequent choices.
Ensure IP address ranges do not overlap
For VPC Peering, the two VPCs must have non-overlapping CIDR blocks. If they overlap, the peering request will fail. This is a common exam scenario — if a question mentions overlapping ranges, peering is not possible without re-addressing one VPC.
Set up the connection
For VPC Peering, create a peering request in one VPC and accept it in the other. For Cloud VPN, configure the VPN gateway, tunnel, and router (with BGP for HA VPN). For Private Google Access, enable the subnet-level setting in the VPC's subnet where the VMs reside.
Configure firewall rules and routes
Even after the connection is established, traffic will not flow until you allow it. For VPC Peering, create firewall rules in each VPC to permit the desired ingress and egress traffic. For Cloud VPN, ensure on-premises firewall allows IPsec traffic (UDP ports 500 and 4500). For Private Google Access, no additional firewall rules are needed; the routing handles the rest.
Test and monitor the connection
Use tools like ping (for ICMP) or telnet (for TCP ports) to verify connectivity from a test VM. For VPN, monitor tunnel status using Cloud Monitoring and set up alerts for tunnel disconnections. For Private Google Access, test by querying a Google API from a VM without a public IP — it should succeed.
An IT professional at a mid-sized e-commerce company called ShopStream needs to connect three environments securely using Google Cloud. The company has a physical office in Chicago running its own internal servers for inventory management. It also runs its main customer-facing website on Google Cloud in a VPC called 'prod-west' in the us-west1 region. Additionally, the development team maintains a separate VPC called 'dev-east' in us-east1 for testing new features.
Step 1: The IT engineer enables HA VPN between the Chicago office router and the 'prod-west' VPC. She configures two tunnels and sets up BGP routing so that the on-premises network automatically learns about the cloud network's subnets and vice versa. She tests the connection by pinging a Google Cloud VM from a server in Chicago. The ping succeeds, meaning the office can securely reach the cloud over the internet without exposing services to the public.
Step 2: The engineer must allow the development VPC ('dev-east') to communicate with the production VPC ('prod-west') so that developers can deploy new code to staging environments that mimic production. She sets up VPC Peering between the two VPCs. Now a VM in 'dev-east' can directly access a database in 'prod-west' using its private IP address. The traffic stays within Google's network. She also tests that the connection is not transitive: the Chicago office cannot reach 'dev-east' just because it is peered with 'prod-west' — she must set up a separate VPN tunnel or a new peering if the office needs to reach dev resources.
Step 3: The engineers in 'dev-east' need to run analytics queries against Google BigQuery. They do not want to give their VMs public IP addresses because that would increase the attack surface. The engineer enables Private Google Access on the subnet where the dev VMs live. Now those VMs can query BigQuery using only their private IPs. The traffic goes from the VM directly to Google's internal network, bypassing the internet entirely.
Step 4: Later, the company decides to migrate its entire inventory database to Google Cloud SQL. To allow the production VMs to connect to Cloud SQL privately, the engineer enables Private Services Access. This creates a VPC peering between the 'prod-west' VPC and a Google-managed VPC that hosts Cloud SQL. Now the production VMs can talk to Cloud SQL via internal IPs without ever sending data over the internet.
Throughout these steps, the IT professional documents each connection, configures firewall rules to allow only necessary traffic, and monitors the VPN tunnel's health using Cloud Monitoring alerts. She also tests failover by manually disabling the primary VPN tunnel — the secondary tunnel takes over within seconds, maintaining the connection to Chicago.
The PCSE exam tests your ability to choose the correct private connectivity option for a given scenario. Here is exactly what you need to know.
First, memorise the core characteristics of each option:
VPC Peering: connects two Google Cloud VPCs; non-transitive; no encryption needed (because traffic stays on Google's backbone); free data transfer within the same region; requires non-overlapping IP ranges.
Cloud VPN: connects an on-premises network or a non-GCP network to a VPC; encrypted via IPsec; operates over the public internet; HA VPN provides 99.99% SLA; uses BGP for dynamic routing.
Private Google Access: allows VMs to reach Google APIs without public IPs; enabled per subnet; does not require a direct connection like a VPN or Interconnect; works only for Google APIs and services, not third-party endpoints.
Cloud Interconnect: dedicated physical connection; highest throughput and reliability; requires weeks to provision; most expensive; supports both Dedicated and Partner options.
The exam loves scenario-based questions that describe a business requirement and ask you to pick the solution. Trap patterns include:
A question says 'connect two VPCs in different regions' — the correct answer is VPC Peering, not VPN. Beginners often pick VPN because they think all cross-network connections need encryption. Peering is simpler and cheaper.
A question says 'connect an on-premises data centre to a VPC with low latency and high reliability' — the correct answer is Cloud Interconnect, not VPN. The trap is that VPN can technically do it, but the requirement for low latency and high reliability points to a physical connection.
A question says 'allow a VM with only a private IP to access Cloud Storage' — the correct answer is Private Google Access. Beginners sometimes pick VPC Peering, but peering connects two VPCs, not a VPC to a Google API.
A question asks about 'transitive peering' — the correct answer is that VPC Peering is not transitive by default. The trap is that some beginners assume all peering is transitive like in other cloud providers (AWS). Google Cloud requires explicit peering for each pair of VPCs.
A question about Cloud VPN asks which protocol is used — the answer is IPsec. The exam also tests that HA VPN uses two tunnels and supports dynamic routing with BGP.
Key definitions to memorise:
Non-transitive peering: Traffic from VPC A to VPC C cannot flow through VPC B, even if A-B and B-C are peered.
BGP (Border Gateway Protocol): The routing protocol used by HA VPN to exchange routes dynamically between the cloud and on-premises.
IPsec: The encryption standard used by Cloud VPN to secure data over the internet.
Service Networking: The Google Cloud feature that enables Private Services Access for managed services like Cloud SQL and Memorystore.
Egress: Traffic leaving the VPC. Private Google Access avoids egress charges for Google APIs.
Finally, be prepared for drag-and-drop or multiple-select questions where you must identify the correct sequence of steps to set up a connection. For example, setting up VPC Peering requires: 1) creating the peering request in the source VPC, 2) accepting the request in the target VPC, and 3) configuring firewall rules to allow traffic between the ranges.
VPC Peering connects two Google Cloud VPCs directly using Google's internal network, with no encryption required and no transit charges within the same region.
Cloud VPN creates an encrypted tunnel over the public internet to connect an on-premises network to a VPC, with HA VPN offering 99.99% availability via two tunnels and BGP routing.
Private Google Access allows VMs with only private IPs to access Google APIs and services without sending traffic over the internet.
VPC Peering is non-transitive: if VPC A is peered to B, and B is peered to C, A cannot reach C through B without a direct peering.
Cloud Interconnect provides a dedicated physical cable from your on-premises network to Google Cloud, offering the highest throughput and lowest latency but at a higher cost and longer provisioning time.
Private Services Access (using Service Networking) is separate from Private Google Access; it lets VMs connect to managed services like Cloud SQL using VPC peering with a Google-managed VPC.
These come up on the exam all the time. Here's how to tell them apart.
VPC Peering
Connects two Google Cloud VPCs only
No encryption (traffic stays on Google's network)
Free data transfer within same region
Cloud VPN
Connects on-premises network to a VPC
Encrypted with IPsec over the public internet
Charges for data egress based on volume
Private Google Access
Allows VMs to reach Google APIs (e.g., Cloud Storage)
Enabled per subnet in the VPC
No VPC peering required
Private Services Access
Allows VMs to reach managed services (e.g., Cloud SQL)
Requires VPC peering with a Google-managed VPC
Uses Service Networking feature
Cloud Interconnect
Dedicated physical cable (no internet involved)
10 Gbps or 100 Gbps per connection
99.99% SLA, but takes weeks to provision
Cloud VPN
Encrypted tunnel over the public internet
Up to 3 Gbps per tunnel (can aggregate several)
99.99% SLA with HA VPN, can be set up in minutes
Classic VPN
Single tunnel, static routing only
No SLA guarantee
Simple but no automatic failover
HA VPN
Two tunnels with automatic failover
99.99% SLA
Dynamic routing via BGP required
Mistake
VPC Peering creates an encrypted tunnel between two VPCs.
Correct
VPC Peering does not add encryption because the traffic stays entirely on Google's internal network. Encryption is only needed for traffic that travels over the public internet, like Cloud VPN.
Beginners often think all traffic between separate networks must be encrypted, but Google's physical infrastructure is already isolated from the public internet.
Mistake
Private Google Access requires a VPN or Cloud Interconnect connection.
Correct
Private Google Access is a per-subnet setting that works without any external connection. It routes traffic to Google APIs internally using Google's backbone.
The term 'private' makes people assume it requires a dedicated connection, but it is simply a routing configuration change within the VPC.
Mistake
HA VPN provides 99.99% uptime because it uses encryption.
Correct
HA VPN achieves 99.99% uptime through redundancy — two tunnels with automatic failover — not because of encryption. Encryption provides security, not availability.
Learners conflate security features (encryption) with reliability features (redundancy) when both are present in the same product.
Mistake
Cloud Interconnect and VPC Peering are the same thing.
Correct
Cloud Interconnect connects your on-premises network directly to Google Cloud with a physical cable. VPC Peering connects two VPCs inside Google Cloud. They serve completely different use cases.
Both terms involve 'connection' and are private, so beginners lump them together. The key difference is what networks are being connected (on-premises vs. cloud-to-cloud).
Mistake
VPC Peering automatically allows all traffic between the two VPCs.
Correct
VPC Peering only enables routing. You still need firewall rules in each VPC to permit the specific traffic you want.
People assume 'connected' means 'everything is open'. In cloud networking, routing and firewall are separate concepts.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, VPC Peering only works between two Google Cloud VPCs. To connect an on-premises network, you need Cloud VPN or Cloud Interconnect.
Private Google Access works for Google APIs and services like Cloud Storage, BigQuery, and Cloud Logging. It does not work for third-party services or for Google-managed services like Cloud SQL (those require Private Services Access).
Yes, Cloud VPN uses IPsec encryption which is the industry standard for securing data over the internet. It is considered highly secure and is used by many production systems.
Dedicated Interconnect gives you a direct, private fibre connection to Google's network. Partner Interconnect connects you through a supported third-party service provider, which is useful if you cannot get a direct connection to a Google colocation facility.
Yes, Private Google Access can be enabled or disabled on an existing subnet at any time. Existing VMs will immediately start using it — no reboot required.
Because VPC Peering traffic travels entirely within Google's own physical network, which is isolated from the public internet. Google controls the infrastructure, so the data never passes through unsecured wires or routers.
You've finished Private Connectivity: VPC Peering, VPN, and Private Google Access. Continue through the PCSE study guide to build a complete picture of the exam.
Done with this chapter?