GCP Workload Identity - No More Service Account Keys

GCP interviewers almost always ask how you'd let a pod talk to Cloud Storage, BigQuery, or Pub/Sub without baking a service account key into the container image. It's a quick way to check whether you understand modern GCP identity, or whether you're still shipping JSON key files around in 2026.

The answer interviewers want

Service account keys are a security liability. They're long-lived, easy to leak into a repo or a Docker image, and painful to rotate once they're in the wild. Workload Identity solves this by mapping a Kubernetes service account directly to a Google Cloud service account, so the pod gets a short-lived token automatically. There's nothing to manage and nothing to rotate manually.

The setup is three steps: enable Workload Identity on your GKE cluster, create the binding between the Google service account and the Kubernetes service account with gcloud, then annotate the Kubernetes service account using kubectl annotate serviceaccount. Once that's done, any pod running under that Kubernetes service account can call GCP APIs with the permissions of the bound Google service account, no credentials file in sight.

The part candidates often skip: you can scope this per namespace. Each team's workloads get their own Kubernetes service account bound to their own Google service account, so each team has exactly the permissions it needs and nothing more. Combined with no static keys, that means no more credential leaks showing up in repos or CI logs.

Why interviewers ask this

They're checking if you've actually run a GKE cluster in a real org, not just read the docs once. Anyone can say "use Workload Identity," but explaining the binding flow and the per-namespace scoping shows you understand it as an access control model, not just a magic flag. It also signals whether you think about credential sprawl as a security problem, which matters a lot in an SRE or platform interview.

Follow-ups to expect

What happens to pods that existed before Workload Identity was enabled? They keep using whatever credentials they had before; enabling Workload Identity on the cluster doesn't retroactively change a pod's identity, you still have to annotate the relevant Kubernetes service accounts and roll the pods.

How do you stop a team from binding their Kubernetes service account to an overly broad Google service account? Enforce least privilege at the namespace level: give each team's Kubernetes service account a binding only to the Google service account scoped for its own workload, not a shared or admin-level account.

Why is this better than mounting a key as a Kubernetes secret? A mounted key is still a static, long-lived credential sitting in etcd and in pod specs; Workload Identity issues short-lived tokens automatically, so there's no secret to leak or rotate in the first place.

The common wrong answer

The common mistake is describing Workload Identity as just "a way to avoid key files" without mentioning the actual binding mechanism or the namespace-level scoping. Candidates who stop at "it gives pods a token" miss the access control story interviewers actually want: that permissions are scoped per team, which is the real security win over a shared key floating around in a repo.