Cloud SQL has two distinct mechanisms for controlling who can connect to a database instance, and the Professional Cloud Architect exam expects you to know when each one applies. The Cloud SQL Auth Proxy uses IAM-based authentication and encrypted tunnels. Authorized Networks restricts access by IP range. They solve the same problem from completely different angles, and choosing the wrong one (or worse, combining them carelessly) can either lock your application out or expose your database to the entire internet.
I want to walk through both, explain why I default to the Auth Proxy in almost every architecture I design, and call out the one configuration mistake that shows up on the Professional Cloud Architect exam more than any other.
The Cloud SQL Auth Proxy is a secure connection method between your application and a Cloud SQL instance. It does four things at once.
First, it authenticates connections using IAM rather than database passwords or network ACLs. A service account needs the cloudsql.instances.connect permission to establish a connection through the proxy. If the service account does not have that permission, the connection fails before any database credentials are ever checked.
Second, it encrypts the connection. Traffic between your application and the Cloud SQL instance is wrapped in TLS automatically. You do not configure certificates yourself.
Third, it hides the IP address of the Cloud SQL instance. Your application connects to the proxy, and the proxy connects to Cloud SQL. Anyone scanning the internet for exposed databases will not find yours through this path.
Fourth, it works from anywhere. The application can run on Google Kubernetes Engine, Compute Engine, Cloud Run, App Engine, or even on-premises infrastructure. As long as the workload has a service account with the right permission, the proxy handles the rest.
Picture an application running on GKE that needs to talk to a Cloud SQL for PostgreSQL instance. The application sends its database queries to the Cloud SQL Auth Proxy, which is running as a sidecar or as a connector inside the same pod. The proxy checks with Cloud IAM to confirm the service account has cloudsql.instances.connect. Once authenticated, the proxy establishes an encrypted connection to the Cloud SQL instance and forwards traffic back and forth.
The application never needs to know the Cloud SQL instance's IP address. It connects to 127.0.0.1 or to a Unix socket, and the proxy takes care of routing. That is what makes this pattern portable across environments.
Authorized Networks is the older, IP-based access control on Cloud SQL. You specify a CIDR range, and only traffic originating from that range can reach the instance over its public IP. If you have a fixed set of trusted IPs, like a corporate office or a specific VM, you can list them here and the instance will accept connections from those addresses.
This is purely a network-layer filter. It does not authenticate the application. It does not encrypt traffic on its own. It just decides which source IPs are allowed to attempt a connection.
If you are using the Cloud SQL Auth Proxy, you do not need Authorized Networks at all. Leave that section empty. The proxy already handles connectivity, authentication, and encryption. Adding IP ranges on top of the proxy gives you nothing useful and creates two configurations that need to stay in sync as your network changes.
This is one of the cleanest answers on the Professional Cloud Architect exam. If a question shows an architecture using the Cloud SQL Auth Proxy and asks how to configure Authorized Networks, the answer is "leave it blank."
Never add 0.0.0.0/0 to Authorized Networks. That CIDR represents every IP address on the internet. Adding it tells Cloud SQL to accept connection attempts from anywhere, which exposes your database to brute-force attacks, credential stuffing, and any zero-day in the database engine itself.
You will see this configuration appear as a tempting wrong answer on the Professional Cloud Architect exam. Sometimes the question frames it as a quick fix to get an application connected. The correct response is always to use the Auth Proxy or a private IP with VPC connectivity, never to open the instance to the world.
The only situation where a broad public range is acceptable is when there is a separate authentication and authorization layer in front of the database, like an API gateway with its own auth, and even then it is rare and risky.
For Professional Cloud Architect exam scenarios, the decision tree is straightforward. If the workload is on Google Cloud and needs to reach Cloud SQL, prefer private IP with VPC peering or the Cloud SQL Auth Proxy. The Auth Proxy is the right answer when the workload runs in a managed service like Cloud Run or App Engine, when you want IAM-based access control, or when the application also runs in environments outside Google Cloud.
Authorized Networks is the answer only when there is a hard requirement for direct public IP connectivity from a known, fixed, narrow set of source addresses, and even then I would push back on the design.
One detail the exam likes to test is the specific permission name. Service accounts using the Cloud SQL Auth Proxy need cloudsql.instances.connect. This is granted by the Cloud SQL Client role (roles/cloudsql.client). Without this role or an equivalent custom role containing that permission, the proxy will reject the connection regardless of database credentials.
Database authentication is a separate layer. The proxy gets you to the database. The database itself still requires a username and password, or IAM database authentication if you have configured that. Both layers need to be set up correctly for the application to actually run queries.
My Professional Cloud Architect course covers Cloud SQL connectivity alongside the rest of the databases material.
