An enterprise is deploying a mission-critical workload on a VPC-native Google Kubernetes Engine (GKE) cluster that must interact with a Cloud SQL for PostgreSQL instance configured exclusively with private IP. The organization's security policy mandates the following: No long-lived service account keys, passwords, or static database credentials may be stored inside the cluster. Database network traffic must stay strictly on internal RFC 1918 routes and enforce mutual TLS encryption. Database authentication and instance access must be dynamically governed using Cloud IAM. Which configuration should the security engineer implement to meet these requirements?

Configure GKE Workload Identity by binding the application's Kubernetes Service Account (KSA) to a Google Service Account (GSA) granted roles/cloudsql.client and roles/cloudsql.instanceUser. Deploy Cloud SQL Auth Proxy v2 as a sidecar container using the --private-ip and --auto-iam-authn flags, and configure the application to connect to 127.0.0.1 on the specified local database port.: ### What the Cloud SQL Auth Proxy with Workload Identity and IAM Authentication is The **Cloud SQL Auth Proxy** is a companion connector that provides secure access to Cloud SQL instances by establishing an encrypted TLS/SSL tunnel and authenticating through the **Cloud SQL Admin API**. When combined with **GKE Workload Identity** and **IAM database authentication**, applications running on Google Kubernetes Engine authenticate seamlessly without managing static database user passwords or long-lived private key files. ### How it meets the requirements - **Zero static credentials:** **Workload Identity** binds the pod's **Kubernetes Service Account (KSA)** to a **Google Service Account (GSA)**, allowing the proxy to fetch short-lived OAuth 2.0 access tokens and ephemeral client certificates automatically. - **Enforced private IP and TLS:** Running the proxy with the `--private-ip` flag forces network traffic to route through internal RFC 1918 addresses via **Private Service Access** or **Private Service Connect**. Outgoing connections from the proxy to the database on port `3307` are automatically wrapped in 256-bit TLS/SSL with ephemeral certificates refreshed every hour. - **IAM-governed authentication:** Passing the `--auto-iam-authn` flag instructs the proxy to supply IAM credentials directly during the database handshake, eliminating static database passwords entirely. - **Least privilege access control:** Granting the GSA **`roles/cloudsql.client`** permits connection authorization via the Cloud SQL Admin API, while **`roles/cloudsql.instanceUser`** grants permission to log in using IAM database authentication. ### Key advantages and capabilities - **Sidecar architecture isolation:** Deploying the proxy in the same pod allows the application to connect via `127.0.0.1` (localhost), ensuring unencrypted local traffic never leaves the pod boundary. - **Automatic certificate rotation:** Ephemeral SSL certificates are generated on demand and refreshed before their one-hour expiration. - **Per-pod IAM scoping:** Prevents cluster-wide privilege escalation by tying database privileges directly to specific application identities. ### Why this is optimal This approach adheres strictly to Google Cloud security best practices by eliminating credential persistence, enforcing internal encrypted routing, and automating identity federation across GKE and Cloud SQL.

Cloud Sql Private Ip Iam Auth Gke | Professional Cloud Security Engineer

Cloud Sql Private Ip Iam Auth Gke

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise is deploying a mission-critical workload on a VPC-native Google Kubernetes Engine (GKE) cluster that must interact with a Cloud SQL for PostgreSQL instance configured exclusively with private IP. The organization's security policy mandates the following:

No long-lived service account keys, passwords, or static database credentials may be stored inside the cluster.
Database network traffic must stay strictly on internal RFC 1918 routes and enforce mutual TLS encryption.
Database authentication and instance access must be dynamically governed using Cloud IAM.

Which configuration should the security engineer implement to meet these requirements?

Establish direct TCP connections to the Cloud SQL private IP on port 5432 using manually generated self-signed client certificates, and retrieve static database passwords dynamically from Cloud Secret Manager.

Deploy the Cloud SQL Auth Proxy as a centralized Kubernetes Deployment exposed via a ClusterIP service on 0.0.0.0, grant the GKE node pool default Compute Engine service account the roles/cloudsql.admin role, and connect using static database passwords.

Generate a long-lived service account key JSON file, store it in a Kubernetes Secret, and mount it into a standalone Cloud SQL Auth Proxy pod running with the legacy --enable_iam_login flag and public IP routing.

Configure GKE Workload Identity by binding the application's Kubernetes Service Account (KSA) to a Google Service Account (GSA) granted roles/cloudsql.client and roles/cloudsql.instanceUser. Deploy Cloud SQL Auth Proxy v2 as a sidecar container using the --private-ip and --auto-iam-authn flags, and configure the application to connect to 127.0.0.1 on the specified local database port.

Professional Cloud Security Engineer

Cloud Sql Private Ip Iam Auth Gke

Related questions