5.2.2. Service Account Security and Impersonation
💡 First Principle: The safest way to "act as" a service account is to never possess its credentials at all — impersonation and Workload Identity Federation both achieve exactly that, letting an already-authenticated caller borrow another identity's permissions temporarily without ever downloading or distributing that identity's keys.
Service account impersonation lets an authorized caller generate a short-lived token that lets them act as a target service account, without that caller ever holding the target's long-lived key. Creating and managing short-lived service account credentials generally is the broader best practice this reflects — minimizing the lifetime of any credential in circulation shrinks the window in which a leaked credential remains useful to an attacker. Using a Google Cloud service account with a GKE application typically means binding a Kubernetes service account to a Google Cloud service account so Pods can authenticate to Google Cloud APIs without embedding a key inside the container image. Provisioning Workload Identity Federation extends this same "no downloaded key" principle to workloads running entirely outside Google Cloud (on-premises, another cloud) — letting them authenticate using their existing identity provider's credentials, federated into Google Cloud trust, rather than requiring a Google service account key to be exported and stored externally.
⚠️ Exam Trap: Impersonating a service account requires distributing its private key to whoever needs to act as it — that's the misconception the whole feature exists to eliminate. Impersonation via short-lived, generated credentials lets an authorized caller act as another service account without ever handling its keys, which is precisely the least-privilege pattern the exam expects you to recognize over any solution involving exported, long-lived key files.
Reflection Question: An on-premises application (outside Google Cloud entirely) needs to authenticate to a Google Cloud API using its existing corporate identity, without a Google service account key ever being exported to that on-premises environment. Which feature is purpose-built for exactly this?
