Connecting Dataflow to Private Cloud SQL Across Projects

PDE By islever Editorial Last updated

Optimizing resources. Planning for using a data warehouse.

Short answer

D Set up VPC Network Peering between Project A and Project B and use a Compute Engine instance as a proxy server to connect to the Cloud SQL database without exposing data to the public internet.

Question

You are developing an Apache Beam pipeline to extract data from a Cloud SQL instance by using JdbcIO. You have two projects running in Google Cloud. The pipeline will be deployed and executed on Dataflow in Project A. The Cloud SQL. instance is running in Project B and does not have a public IP address. After deploying the pipeline, you noticed that the pipeline failed to extract data from the Cloud SQL instance due to connection failure. You verified that VPC Service Controls and shared VPC are not in use in these projects. You want to resolve this error while ensuring that the data does not go through the public internet. What should you do?
  1. Set up VPC Network Peering between Project A and Project B. Add a firewall rule to allow the peered subnet range to access all instances on the network.
  2. Turn off the external IP addresses on the Dataflow worker. Enable Cloud NAT in Project A.
  3. Add the external IP addresses of the Dataflow worker as authorized networks in the Cloud SQL instance.
  4. Set up VPC Network Peering between Project A and Project B. Create a Compute Engine instance without external IP address in Project B on the peered subnet to serve as a proxy server to the Cloud SQL database. Correct Answer

Key Takeaways

VPC peering is non-transitive; you cannot route traffic from one VPC through another to reach a Google-managed service like Cloud SQL unless you use an intermediary resource like a proxy VM.

Learn how to securely connect Apache Beam pipelines to Cloud SQL instances with private IPs across different GCP projects using VPC peering and a proxy VM.

Common mistake: Candidates often choose Option A, assuming that peering the two projects directly will allow access to the Cloud SQL instance. This ignores the fact that Cloud SQL uses a separate Google-managed network for PSA, which is not reachable via simple inter-VPC peering.

Expert Analysis

The core challenge is connecting a Dataflow pipeline in Project A to a Cloud SQL instance with a private IP in Project B, without using the public internet. While VPC Network Peering between Project A and Project B (Option A) establishes connectivity between the two user-defined networks, it does not automatically grant access to the Cloud SQL instance. This is because Cloud SQL Private IP relies on Private Services Access (PSA), which creates a peering connection between your VPC and a Google-managed service network, not directly within your own project's VPC.

Since VPC peering is non-transitive, routing traffic from Project A through Project B to reach the Google-managed Cloud SQL network is not supported natively. Option A fails because simply peering Project A and B does not extend the PSA peering link to Project A. Option C is invalid because authorized networks require external IPs or specific ranges that often traverse public boundaries, violating the 'no public internet' constraint.

Option D is the correct architectural pattern for this cross-project, private-IP scenario. By creating a Compute Engine instance in Project B (on the subnet peered with Project A) without an external IP, you create a secure bridge. The Dataflow workers in Project A can route traffic via the VPC peering to this proxy VM in Project B, which then connects to the Cloud SQL instance over its internal PSA link. This ensures all data remains within Google's internal network infrastructure.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When dealing with Google-managed services (Cloud SQL, AlloyDB, BigQuery) behind private IPs, always verify if the service uses Private Services Access (PSA). If you need to access it from a different VPC/project, remember that standard VPC peering does not transitively route to these Google-managed service networks. You typically need a compute resource (like a VM or Cloud Run job) in the target project to act as a gateway.

Frequently Asked Questions

Why can't I just use VPC Peering to access Cloud SQL Private IP?

Cloud SQL Private IP uses Private Services Access (PSA), which peers your VPC with a Google-managed service network. Standard VPC peering between two customer projects (Project A and B) does not provide transitive routing to that Google-managed network.

Is there a way to avoid using a proxy VM for this setup?

Yes, you can use Serverless VPC Access (Connector) to attach your VPC directly to the Google-managed service network, but this requires the connector to be in the same region and project context as needed. In cross-project scenarios with strict security constraints, a proxy VM is often the prescribed exam answer.

More PDE FAQ →

Community Votes

A
52%
D
48%

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

Discussion 30 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 30

  1. aoifneofi_ef 👍 8 Answered D
    It is a tie between A and D. Option A will definitely provide necessary connectivity but is less secure as access is enabled to "all instances". Which i feel is unnecessary considering industry best practices. Option D provides the necessary connectivity but brings in the unnecessary overhead of managing an extra VM and introduces a bit of extra complexity. Since the question emphasises on data not going through public internet(which is satisfied in both options), i would prioritise security over simplicity and choose option D in this case.
  2. clouditis 👍 5 Answered A
    A looks to be the best out of the 4, D is complicated involving Compute Engine which is unnecessary making it cumbersome to address the problem
  3. MaxNRG 👍 4 Answered D
    D is the correct solution. To allow the Dataflow workers in Project A to connect to the private Cloud SQL instance in Project B, you need to set up VPC Network Peering between the two projects. Then create a Compute Engine instance without external IP in Project B on the peered subnet. This instance can serve as a proxy server to connect to the private Cloud SQL instance. The Dataflow workers can connect through the peered network to the proxy instance, which then connects to Cloud SQL. This allows accessing the private Cloud SQL instance without going over the public internet. Option A would allow access but still goes over the public internet. Option B and C would not work since the Cloud SQL instance does not have a public IP address. So D is the right approach to resolve the connection issue while keeping the data private.
  4. chrissamharris 👍 4 Answered A
    A - The requirement for a proxy is un-necessary: https://cloud.google.com/sql/docs/mysql/private-ip#multiple_vpc_connectivity
  5. BIGQUERY_ALT_ALT 👍 3 Answered D
    Option D is the correct answer. The reason is you cannot access cloud sql or alloydb instances from a peered vpc connection as they will be hosted in service project not in Project B. The VPC Peering doesn't give transitive routing so accessing cloud sql directly is not possible without a proxy vm. https://cloud.google.com/vpc/docs/vpc-peering#spec-general
Show 25 more comments
  1. lipa31 👍 2 Answered D
    the reason : Cloud SQL supports private IP addresses through private service access. When you create a Cloud SQL instance, Cloud SQL creates the instance within its own virtual private cloud (VPC), called the Cloud SQL VPC. Enabling private IP requires setting up a peering connection between the Cloud SQL VPC and your VPC network.
  2. e70ea9e 👍 2 Answered A
    Secure Private Communication: Establishes a direct, private connection between the VPCs, eliminating exposure to the public internet. Ensures data confidentiality and integrity.
  3. raaad 👍 2 Answered A
    VPC Network Peering allows for the connection of two VPC networks so that they can communicate internally as if they were part of the same network.
  4. julydev82 👍 2 Answered A
    vpc create a subnet beetwen sql Cloud and the dataflow. https://cloud.google.com/sql/docs/mysql/private-ip#multiple_vpc_connectivity
  5. fabiogoma 👍 2 Answered A
    Why so many people are voting for D? There's no need for a proxy, the peering is enough to allow network traffic between subnets.
  6. chrissamharris 👍 2
    I think you're incorrect. VPC Peering does not traverse the public internet. https://cloud.google.com/vpc/docs/using-vpc-peering
  7. fabiogoma 👍 2
    Now I see why, I put this on ChatGPT and it thinks the right answer is D. I'm pretty sure that's a hallucination.
  8. ML6 👍 2
    Option D. Source: https://cloud.google.com/sql/docs/mysql/private-ip#multiple_vpc_connectivity
  9. josech 👍 2 Answered D
    https://cloud.google.com/sql/docs/mysql/connect-multiple-vpcs
  10. ccpmad 👍 2
    Proxy? no, it is not necessary.. A
  11. 71083a7 👍 2 Answered D
    "all instances" freaks me out
  12. saschak94 👍 1 Answered D
    Cloud SQL with a private IP utilizes Private Services Access (PSA), which fundamentally works by creating a VPC network peering connection between your VPC (in Project B) and a Google-managed VPC (where the Cloud SQL instance actually lives). Google Cloud VPC peering is non-transitive. This means if Project A is peered with Project B, and Project B is peered with the Google-managed VPC, Project A cannot directly route traffic to the Google-managed VPC. To bridge this gap without the public internet, you must place a proxy server (like a Compute Engine VM) in Project B. Project A's Dataflow workers can reach the proxy via the first peering connection, and the proxy can reach Cloud SQL via the second.
  13. Lestrang 👍 1 Answered A
    People referencing "VPC Network Peering does not provide transitive routing. For example, if VPC networks net-a and net-b are connected using VPC Network Peering, and VPC networks net-a and net-c are also connected using VPC Network Peering, VPC Network Peering does not provide connectivity between net-b and net-c." the question states that cloud sql is running in project B. Which means the instance is already part of the VPC in project B, so with Network Peering workers from A can definitely access data in B. No proxy is needed.
  14. saschak94 👍 1 Answered D
    Using VPC Network Peering, Cloud SQL implements private service access internally, which allows internal IP addresses to connect across two VPC networks regardless of whether they belong to the same project or organization. However, since VPC Network Peering isn't transitive, it only broadcasts routes between the two VPCs that are directly peered. If you have an additional VPC, it won't be able to access your Cloud SQL resources using the connection set up with your original VPC.
  15. Saaaurabh 👍 1 Answered A
    If properly implemented with the right routing and firewall rules, Option A can be the correct and most straightforward solution, as it leverages VPC Peering to maintain internal traffic without going through the public internet.
  16. Positron75 👍 1
    A says to allow access to "all instances in the network", which is excessive and not good practice security-wise. This is yet another question where no answer is fully correct and it's up to you to choose which one is less wrong.
  17. datapassionate 👍 1 Answered D
    D. Set up VPC Network Peering between Project A and Project B. Create a Compute Engine instance without external IP address in Project B on the peered subnet to serve as a proxy server to the Cloud SQL database.
  18. fadlkhafdofpew 👍 1 Answered A
    The answer is A. While D might work, it adds unnecessary complexity. Setting up a proxy is an extra layer of infrastructure that isn’t required
  19. Anudeep58 👍 1
    The Cloud SQL. instance is running in Project B and does not have a public IP address. Correct would be D. Any thoughts ?
  20. Ben_oso 👍 1 Answered A
    VPC Peering allow to two private routes can communicate each other.
  21. Matt_108 👍 1 Answered D
    Option D is the most aligned to best practices for me
  22. kk1211 👍 1
    still confused between A and D
  23. kajitsu 👍 1 Answered A
    no proxy needed
  24. meh_33 👍 1
    A is correct
  25. JyoGCP 👍 1 Answered D
    Option D

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.

How to establish consistent BigQuery spend?

S-grade

Triggering Airflow DAGs Reactively in Private Cloud Composer

S-grade

How to resolve Cloud Composer 2 worker pod evictions and task failures?

S-grade

Ensuring Consistency in BigQuery Streaming Analytics

S-grade

← Back to PDE Study Guide