Google ACE Deploying and Implementing a Cloud Solution Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use Cloud SQL Proxy by adding the Cloud SQL instance connection name to the Cloud Run service

  Why this is correct

  When you bind a Cloud Run service to a Cloud SQL instance by its connection name, the platform automatically injects and runs the Cloud SQL Auth Proxy as a sidecar container. The proxy connects to the database over an encrypted channel using either a private IP or a Unix socket, and it leverages IAM permissions to authorize the connection. This pattern avoids static IP management, network whitelisting, and manual secret handling, making it the officially recommended integration.

• ✗

  Use a public IP for the Cloud SQL instance and whitelist the Cloud Run service's IP

  Why it's wrong here

  This approach is unworkable because Cloud Run does not provide a dedicated, stable outbound IP address for each revision. Egress traffic originates from a dynamic, shared Google-owned pool, so whitelisting a specific IP would either fail to match the actual source or open the database to a broad range of addresses. Moreover, exposing Cloud SQL on a public IP contradicts security best practices; a Serverless VPC Access connector with Cloud NAT could provide a static IP if one is absolutely required, but that is not the simple whitelist described here.

• ✗

  Store database credentials in environment variables

  Why it's wrong here

  Storing credentials in environment variables is a configuration practice, not a connectivity solution—it never establishes a network path from Cloud Run to Cloud SQL. Environment variables can easily leak through logging, and they are not encrypted at rest in the service configuration. The correct place for secrets is Secret Manager, and credentials alone still require a secure transport mechanism such as the Cloud SQL Auth Proxy or Private Service Connect to reach the instance.

• ✗

  Use VPC peering to connect Cloud Run to Cloud SQL

  Why it's wrong here

  Cloud Run is a serverless compute service that cannot directly participate in VPC peering; peering is a network-level relationship between two VPCs, and Cloud Run has no customer-managed VPC or router to peer. To access resources in a VPC, Cloud Run uses a Serverless VPC Access connector, and Cloud SQL can be reached via Private Service Connect or the Auth Proxy. Trying to configure VPC peering between Cloud Run and Cloud SQL would fail because the required network entities do not exist on the Cloud Run side.

Go deeper

Related to this question