Fixing Cloud SQL "Network association failed" in a Shared VPC

PCDBE By islever Editorial Last updated

Determine database connectivity and access management considerations. Determine how applications will connect to the database.

Short answer

B Enable the Service Networking API in both the host and service projects before assigning private IPs to the Cloud SQL instances.

Question

You are creating new Cloud SQL for PostgreSQL instances in us-east1 and us-east4. You are assigning private IP addresses to the Cloud SQL instances starting with us-east1 so you can reach the instance without going through the internet or using external IP addresses. However, you keep getting a “Network association failed” error message. You are using a shared VPC network. What should you do to resolve the issue?
  1. Use the Google Cloud console to assign private IP.
  2. Enable the Service Networking API for the host and service projects. Correct Answer
  3. Configure Private Services Access prior to assigning a private IP to Cloud SQL.
  4. Assign the private IP by using the gcloud sql instances patch command.

Key Takeaways

The question tests recognition of a documented Cloud SQL error message; the trap is choosing Private Services Access setup instead of the API enablement the error actually names.

When Cloud SQL for PostgreSQL reports "Network association failed" while assigning a private IP over a shared VPC, the fix is enabling the Service Networking API in both the host and service projects (B).

Common mistake: Option C is the most tempting wrong answer: Private Services Access is a genuine prerequisite for private IP, but it is not what the "Network association failed" message indicates, and the question already implies an existing shared VPC setup.

Expert Analysis

The error name is the clue

The exact string "Network association failed" is a documented Cloud SQL error, and its official troubleshooting entry names one cause: the Service Networking API is not enabled. Because this deployment uses a shared VPC, the API must be enabled in both the host project (which owns the shared network) and the service project (which owns the Cloud SQL instance). That is precisely what option B says, so B is the correct answer.

Why option C is the attractive trap

Option C sounds authoritative because Private Services Access really is a prerequisite for private IP: you must allocate an address range and create a PSA connection before Cloud SQL can hand out an internal address. A candidate who has configured many private-IP instances will recognise that sequence and pick C. But the question does not report a missing-range or "no private services access connection" failure — it reports a network association failure, and the documented remedy for that message is enabling the Service Networking API. C describes normal setup order, not the fix for this specific error. Once the API is enabled in both projects, the association to the allocated range can complete; if PSA itself were absent, the failure would surface as a different error at connection-selection time.

Why A and D fail

Options A and D only change the tool used to issue the same request. The console and gcloud sql instances patch both call the same backend, so switching interfaces cannot repair a disabled API — the assignment fails identically either way.

Shared VPC nuance

Enabling the API only in the service project is a common half-fix; the host project must have it too, since the network association is created against the host's shared network.

Exam Strategy

On Google Cloud database exams, treat an exact error string as a lookup key: recall or reason to the official troubleshooting entry rather than general best practice. Eliminate options that only change the tool (console vs gcloud), since interface choice never fixes a backend or API-visibility problem. Then split prerequisite answers: ask whether the option addresses this specific error message or merely describes normal setup order, and prefer the one that names both the host and service projects when a shared VPC is mentioned.

Frequently Asked Questions

Why does "Network association failed" appear only with a shared VPC?

The private IP association is created against the shared VPC's host project network, so the Service Networking API must be enabled in the host project as well as the service project. Enabling it in only one project leaves the association blocked.

Is Private Services Access still required for Cloud SQL private IP?

Yes. You must allocate a range and create a PSA connection before assigning a private IP. However, that prerequisite produces different errors; "Network association failed" specifically points to the Service Networking API being disabled.

Does switching between the console and gcloud fix the private IP error?

No. Both the console and gcloud sql instances patch invoke the same backend operation, so a disabled Service Networking API fails identically regardless of which tool you use.

More PCDBE FAQ →

Community Votes

B
100%

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

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

  1. taskeen87 👍 1 Answered B
    Exact Error Root Cause: As documented in the Cloud SQL Error Messages reference: Error Message: Network association failed. Troubleshooting: "The Service Networking API isn't enabled in the project. Enable the Service Networking API in your project. If you see this error when you're trying to assign a private IP address to a Cloud SQL instance, and you're using a Shared VPC, you also need to enable the Service Networking API for the host project."

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

Connecting GKE to AlloyDB Across Isolated VPCs

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

← Back to PCDBE Study Guide