Connecting GKE to AlloyDB Across Isolated VPCs

PCDBE By islever Editorial Last updated

Determine how applications will connect to the database. Apply concepts to implement scalable and highly available databases in Google Cloud.

Short answer

D Install a SOCKS proxy in a VM in the db-dev VPC and connect the AlloyDB Auth Proxy in the GKE cluster through that server to bridge the isolated VPCs.

Question

You have a non-critical business application running on Google Kubernetes Engine (GKE) in the app-dev VPC. You have created an AlloyDB cluster with Private Service Access (PSA) and no public IP address in the db-dev VPC. You want your application to securely connect to AlloyDB in a cost-effective way. What should you do?
  1. Set up a high availability VPN between the app-dev and db-dev VPCs. Connect the application directly to AlloyDB.
  2. Connect by using the private IP address of the AlloyDB cluster directly from the application.
  3. Connect by using AlloyDB Auth Proxy installed in the GKE cluster.
  4. Install a SOCKS proxy in a VM in the db-dev VPC. Install AlloyDB Auth Proxy in your GKE cluster, and connect to the AlloyDB cluster through the SOCKS server and port. Correct Answer

Key Takeaways

Private Service Access alone does not connect separate VPCs; network bridging via a proxy VM is required for cross-VPC communication.

Learn how to securely connect GKE applications to AlloyDB across different VPCs using a SOCKS proxy and Auth Proxy when direct private IP access is unavailable.

Common mistake: Choosing Option C (Auth Proxy only) assumes PSA bridges VPCs, ignoring that the proxy still needs network reachability which doesn't exist between isolated networks.

Expert Analysis

The question presents a scenario with two distinct VPCs: app-dev hosting GKE and db-dev hosting AlloyDB. Crucially, there is no mention of VPC peering or shared VPC between these networks, meaning they are isolated at the network layer. Private Service Access (PSA) creates a connection only between the specific VPC where it is configured (db-dev) and Google's managed service network; it does not automatically bridge unconnected VPCs.

Option C is the most attractive but wrong answer because it suggests using the AlloyDB Auth Proxy directly from GKE. While the proxy handles authentication securely, it still requires underlying network connectivity to reach the database endpoint. Since the GKE pods in app-dev have no route to the db-dev VPC, direct connection fails.

Option D is correct because it provides the necessary network bridging. Installing a SOCKS proxy in a VM within db-dev allows the GKE cluster to tunnel traffic through that VM. This effectively bypasses the lack of direct VPC-to-VPC routing, allowing the Auth Proxy in GKE to communicate with the database via the intermediary VM. Without this bridge, secure access is impossible.

Exam Strategy

Always verify network topology before selecting connectivity solutions. If VPCs are not explicitly peered or part of a Shared VPC, assume they are isolated. For cloud-native proxies like Auth Proxy, remember they handle auth but still rely on underlying TCP/IP routes; if routes don't exist, you must provide a tunneling mechanism first.

Frequently Asked Questions

Does Private Service Access connect my VPC to another VPC?

No. PSA connects your VPC to Google's managed services. It does not create routes between two customer-owned VPCs unless they are already peered.

Can I use AlloyDB Auth Proxy without a public IP?

Yes, the proxy uses Google Cloud APIs to authenticate and create a secure tunnel, but it still requires network connectivity to the database instance.

More PCDBE FAQ →

Community Votes

C
50%
D
25%
B
25%

50% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 7 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 7

  1. syffuf 👍 2 Answered C
    https://cloud.google.com/alloydb/docs/quickstart/integrate-kubernetes
  2. syffuf 👍 2
    But are different VPCs: PSA as created on db-dev
  3. AwesomeGCP 👍 1 Answered D
    The correct answer is D. Install a SOCKS proxy in a VM in the db-dev VPC. Install AlloyDB Auth Proxy in your GKE cluster, and connect to the AlloyDB cluster through the SOCKS server and port. Why Option D is Correct Non-Transitive VPC Peering: Private Service Access (PSA) connects the db-dev VPC to the underlying Google-managed service project via VPC Network Peering. Because VPC Network Peering is non-transitive, resources in another VPC (app-dev) cannot natively route traffic to the private IP address of an AlloyDB instance in db-dev. Documented Architecture Pattern: Google Cloud documentation explicitly recommends using an intermediary proxy (such as a SOCKS5 server running on a Compute Engine VM in the database VPC) combined with the AlloyDB Auth Proxy to bridge cross-VPC or external connections to PSA-enabled instances. Cost-Effectiveness: For a non-critical application, deploying a lightweight proxy VM costs significantly less than provisioning and maintaining high-availability Cloud VPN gateways and tunnels. Why the Other Options are Incorrect A. HA VPN between the VPCs: While an HA VPN can route traffic to an on-premises network or cross-VPC custom routes, HA VPN incurs continuous gateway and tunnel provisioning costs, making it unnecessarily expensive and over-engineered for a non-critical workload. B. Connect using the private IP directly: Fails due to lack of direct network reachability. The GKE pods in app-dev have no route to the private IP of an AlloyDB cluster provisioned in db-dev's peered service network. C. AlloyDB Auth Proxy alone in the GKE cluster: The AlloyDB Auth Proxy manages IAM authorization and mTLS encryption, but it still requires an underlying TCP network path to reach the instance's private IP. Without a network intermediary (like the SOCKS proxy) to traverse the separate VPCs, the Auth Proxy cannot establish a connection.
  4. Skywatch 👍 1 Answered C
    Connect by using AlloyDB Auth Proxy installed in the GKE cluster. Feasibility: This is the ideal solution. The AlloyDB Auth Proxy is a client-side tool that provides secure access to AlloyDB instances without needing a public IP or direct network connectivity via VPN/Peering. How it works: You run the proxy as a sidecar container in your GKE pods. The proxy uses Google Cloud APIs to create a secure, encrypted tunnel directly to your AlloyDB instance. Your application simply connects to the proxy on localhost, and the proxy handles the secure forwarding of traffic. Security: This is the most secure method. It uses IAM permissions for authentication and authorization and automatically encrypts all traffic with TLS 1.3. Cost-Effectiveness: The proxy itself is free. It completely eliminates the need for expensive VPN gateways or complex VPC Peering configurations, making it the most cost-effective solution.
  5. krop 👍 1
    To be fair, i think this question is incorrectly described here - You have 1st VPC with GKE and you have Managed Database visible in 2nd VPC with its private IP because of PSA. As you mentioned these two VPCs are not connected at all and communication won't be possible between them. I think i have to admit, option C might be the answer here.
Show 2 more comments
  1. krop 👍 1 Answered B
    Private Service Access (PSA) establishes a private connection between your VPC and the Google-managed service network where AlloyDB resides. This allows resources in your VPC (such as GKE pods) to communicate with AlloyDB using its private IP, without needing public IPs or VPNs
  2. nubpirogrammer 👍 1
    Can you check questions from 133 to 147 questions as well

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Scheduling Cloud SQL Exports with Cloud Scheduler and Pub/Sub

S-grade

Migrating Cloud SQL PostgreSQL PITR Logs to Cloud Storage

S-grade

Using Service Accounts for Cloud SQL Auth Proxy on Compute Engine

S-grade

Google Cloud SQL Enterprise Plus Advanced DR Setup

A-grade

← Back to PCDBE Study Guide