Google Cloud gives you three distinct ways to reach services over a private path, and the Professional Cloud Database Engineer exam expects you to tell them apart. The three are Private Service Access, Private Service Connect, and Private Google Access. All of them keep traffic inside the Google network and let resources communicate without external IP addresses or a route to the public internet, but they do that through different mechanisms and they fit different situations. Most of the difficulty in these questions comes from the fact that two or three of the answer choices are valid private connectivity methods, so the work is matching the right one to the scenario rather than picking the only private option.
Private Service Access, often shortened to PSA, enables private access to VPC-hosted services from Google and third-party service producers using internal connectivity. Under the hood it uses VPC Network Peering to establish a connection between your consumer VPC and the producer VPC where the managed service lives, although it is set up and managed as a single connection for the whole service rather than as individual peerings you wire up yourself.
Because PSA joins two separate networks, it requires an allocated internal IP range. You reserve that range specifically for the service producer so there is no address overlap between your network and theirs. Once the connection is in place, traffic routes internally over private IPv4 addresses, and your VM instances talk to the managed service as if both sat on the same local network. This is the model behind giving a Cloud SQL or AlloyDB instance a private IP, and it is the traditional way to reach those managed databases without exposing them on a public address.
The detail the exam likes to test is route propagation. PSA depends on the underlying peering configuration, and by default that peering only advertises the allocated range. Custom routes require explicit import and export to be shared between the networks. The case where this matters most is a cross-region read replica. When you add a Cloud SQL replica in another region and connectivity fails over the private path, the fix is usually to modify the peering so it exports and imports custom routes, which lets the primary and the replica in different regions see each other's networks. Plain VPC peering or NAT changes do not solve that.
Private Service Connect, or PSC, takes a different approach. Instead of peering two networks together, it creates a service-oriented connection using an endpoint, or a backend, inside your own VPC. That endpoint gives you a private, internal connection to services within your VPC, and it can also reach services outside of it. A workload with only an internal IP, such as a service on a private subnet, can use a PSC endpoint to connect to Google Cloud services like managed Airflow and Cloud SQL, and PSC can extend to third-party APIs as well, all without public IPs and without leaving the private network.
The practical advantage over PSA is that PSC avoids direct VPC peering. That keeps network complexity down and sidesteps IP address exhaustion and overlapping ranges, since you are not reserving a producer range and you are not merging route tables across networks. Security is also handled locally, because traffic to the endpoint is controlled with your own VPC firewall rules. PSC is the more modern option for highly scalable services, and there is one case where it is not optional. Memorystore for Redis Cluster requires Private Service Connect when it is accessed across multiple VPC networks. If a single centralized Redis cluster has to serve several VPCs at once, PSC is the connectivity method you configure and register, and PSA does not apply.
Private Google Access is the third method, and the exam weights it less heavily than the other two. It allows VM instances that have only internal IP addresses to connect to Google APIs and services without external IP addresses. You enable it at the subnet level, and any VM in that subnet can then reach Google APIs and services such as Cloud Storage or BigQuery over an internal path. It routes traffic internally without requiring external IPs, and it relies on the subnet having the feature turned on along with a default route to the internet gateway. A subnet without Private Google Access enabled forces its VMs to carry a public IP and traverse the public internet to reach those same Google APIs.
The line to hold here is that Private Google Access is about reaching Google's own APIs and services from internal-only VMs. It is not the mechanism for giving a managed database a private IP or for connecting across VPCs to a managed service, which is where PSA and PSC come in.
For reaching a managed database privately, the choice usually narrows to PSA versus PSC. PSA connects your VPC by peering to a Google-managed service producer network, needs a dedicated internal range reserved for the connection, and supports traditional database deployments like Cloud SQL or AlloyDB on internal IPs. Its main operational catch is the manual route export and import for complex topologies such as cross-region replicas. PSC creates a service-oriented connection using endpoints or backends inside your own VPC, eliminates the peering and the overlapping-address problem, controls traffic through local firewall rules, and is the route for highly scalable services. We would generally lean toward PSC when the architecture spans multiple VPCs or when peering and address overlap are a concern, and toward PSA for a straightforward private Cloud SQL or AlloyDB deployment, while remembering that some services in Google's infrastructure can be reached through PSC, Private Google Access, or both.
A few scenario patterns are worth carrying into the exam. A Redis session store larger than 300 GB that needs sub-millisecond lookups and a private path points to Memorystore for Redis Cluster over PSC, since cluster mode is required above the single-instance ceiling and the cluster only supports PSC. A Postgres workload that demands a strict private path with identity-based access points to a PSC endpoint for the database combined with an internal IP and IAM database authentication. A Cloud Run service reaching a private Cloud SQL instance with no internet exposure points to a private IP backed by PSA, with a Serverless VPC Access connector so the serverless workload can enter the VPC, and no Auth Proxy is needed over private IP. A failing cross-region Cloud SQL replica on a peered PSA connection points back to exporting and importing custom routes on the peering.
Our Professional Cloud Database Engineer course covers private connectivity alongside Cloud SQL private IP configuration and cross-region replication, with practice questions that drill these distinctions.
