Using Service Accounts for Cloud SQL Auth Proxy on Compute Engine

PCDBE By islever Editorial Last updated

Determine database connectivity and access management considerations. Apply concepts to implement scalable and highly available databases in Google Cloud.

Short answer

C Set up a service account for the application server to securely authenticate the Cloud SQL Auth Proxy following Google-recommended practices.

Question

You are deploying a new Cloud SQL instance on Google Cloud using the Cloud SQL Auth proxy. You have identified snippets of application code that need to access the new Cloud SQL instance. The snippets reside and execute on an application server running on a Compute Engine machine. You want to follow Google-recommended practices to set up Identity and Access Management (IAM) as quickly and securely as possible. What should you do?
  1. For each application code, set up a common shared user account.
  2. For each application code, set up a dedicated user account.
  3. For the application server, set up a service account. Correct Answer
  4. For the application server, set up a common shared user account.

Key Takeaways

The main trap is confusing human 'user accounts' with machine 'service accounts'; workloads must use service accounts for IAM integration.

Learn why Google recommends using service accounts instead of user accounts for authenticating Cloud SQL Auth Proxy connections from Compute Engine instances.

Common mistake: Choosing B (dedicated user account) because it sounds more granular, but user accounts are for humans, not automated application code.

Expert Analysis

The core concept tested here is the boundary between human identity and workload identity in Google Cloud. The question specifies that code resides on a Compute Engine instance and requires secure, recommended access to Cloud SQL via the Auth Proxy.

Why Service Accounts are Correct (C): Google Cloud IAM distinguishes between users (people) and service accounts (workloads). For applications running on infrastructure like Compute Engine, the recommended practice is to use service accounts. A service account represents an application or a virtual machine, not a person. By assigning the Cloud SQL Client role to a dedicated service account attached to the Compute Engine instance, you grant the necessary permissions for the Cloud SQL Auth Proxy to authenticate and connect. This follows the principle of least privilege and allows for granular control over which workloads can access specific databases.

Why User Accounts are Incorrect (A, B, D): Options A and B suggest using "user accounts." In Google Cloud, user accounts represent individual humans and are managed via Identity Platform or Google Workspace. They are intended for interactive logins (e.g., Console access), not for programmatic API calls from backend services. Using user accounts for automated tasks is insecure, difficult to manage at scale, and violates best practices. Even if interpreted as "local OS users," this does not integrate with GCP IAM for Cloud SQL authentication.

Why Shared Accounts are Incorrect (D): Option D suggests a "common shared user account" for the server. Sharing credentials (whether user or service account) across multiple applications or instances violates security best practices because it makes auditing difficult and increases the blast radius if credentials are compromised. Dedicated service accounts per workload are preferred.

The comments correctly identify that while some argue for granularity (B), the fundamental mechanism must be a service account, not a user account. Option C is the only choice that uses the correct IAM entity type for a workload.

Official Reference

https://cloud.google.com/sql/docs/mysql/sql-proxy#using-a-service-account

This link opens the official vendor documentation in a new tab.

Exam Strategy

When configuring IAM for any Google Cloud workload (Compute Engine, GKE, Cloud Run), always select 'Service Account' as the identity provider. Never choose 'User Account' for programmatic access. If the question asks about securing app-to-service communication, look for options involving dedicated service accounts with minimal required roles.

Frequently Asked Questions

Can I use a user account for Cloud SQL Auth Proxy?

No. User accounts are for humans. Workloads must use service accounts to authenticate via OAuth2 tokens generated by the metadata server.

Should I use one service account for all apps on the VM?

No. Best practice is to create dedicated service accounts for each distinct workload or application to enforce least privilege.

More PCDBE FAQ →

Community Votes

C
67%
B
33%

67% 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. chelbsik 👍 3 Answered C
    https://cloud.google.com/sql/docs/mysql/sql-proxy#using-a-service-account
  2. GCP72 👍 3 Answered C
    Correct answer is C, service account is the GCP recommended option
  3. dynamic_dba 👍 2
    C. The Google recommendation would be for an application to use a service account. None of the other options make sense in light of this.
  4. Lucker 👍 1
    the best answer would be B . Need granular control for each of the code snippets . The advantage of using a service account for this purpose is that you can create a credential file specifically for the Cloud SQL Auth Proxy, and it is explicitly and permanently linked to the Cloud SQL Auth Proxy as long as it is running. For this reason, using a service account is the recommended method for production instances not running on a Compute Engine instance.
  5. ebd62a2 👍 1 Answered B
    Google best practices, use Dedicated Service Accounts per Workload: Create a specific service account (SA) dedicated to running each code snippet/workload rather than using default Compute Engine or App Engine service accounts.
Show 2 more comments
  1. felipeschossler 👍 1
    C. The docs proving this are here: Create and configure a Google Cloud service account that has the Cloud SQL Client role with permissions to connect to Cloud SQL.
  2. pk349 👍 1
    B: For each application code, set up a dedicated * user account.

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

Google Cloud SQL Enterprise Plus Advanced DR Setup

A-grade

← Back to PCDBE Study Guide