Study Google Cloud ACE Service Accounts: key concepts, common traps, and exam decision cues.
This lesson covers workload identity in Google Cloud. ACE expects you to know how service accounts are created, assigned to resources, impersonated, and used with minimum permissions rather than with unmanaged long-lived key sprawl.
Service account impersonation: Pattern where one identity temporarily acts as a service account without exposing a long-lived key directly.
Short-lived credential: Temporary credential with limited lifetime, reducing the blast radius of theft or misuse.
ACE wants you to separate:
The exam usually rewards the path that keeps credentials short-lived and centrally governed.
| If the question is mainly about… | Strongest first lane |
|---|---|
| a VM, Cloud Run service, or other workload needs Google Cloud API access | attach a least-privilege service account to the workload |
| an operator or automation needs to act briefly as another identity | service account impersonation |
| reducing the risk of stolen credentials | short-lived credentials instead of long-lived keys |
| exporting or sharing a JSON key file broadly | usually the wrong answer unless the stem gives no safer option |
flowchart LR
A["User or workload"] --> B["Approved service account"]
B --> C["Short-lived token"]
C --> D["Google Cloud API call"]
A -. "avoid by default" .-> E["Long-lived key file"]
The safe pattern is to bind the right service account to the workload, or let an approved principal impersonate it briefly. The weak pattern is distributing long-lived keys that are hard to rotate and easy to leak.
| Pattern | Strongest use |
|---|---|
| attach a service account to the resource | the workload itself needs ongoing access |
| impersonate a service account | a person or automation needs temporary delegated access |
| use a long-lived key | only when the stem removes safer managed identity options |
Impersonation is especially strong when the question cares about auditability, short-lived access, or reducing secrets distribution.
| Trap | Better reading |
|---|---|
| “A service account key is fine because it works everywhere.” | ACE usually prefers attached identities or impersonation because they reduce persistent secret sprawl. |
| “Impersonation replaces IAM design.” | The target service account still needs the right least-privilege permissions. |
| “One service account per project is simplest.” | Simplicity is not the same as least privilege. |
| “If the workload runs in Google Cloud, any credential source is equivalent.” | Managed identity attachment is usually stronger than distributing key files. |
A CI job running under one identity needs to deploy to Google Cloud using a controlled production service account, but the security team does not want to hand out a reusable key file. Which lane is strongest first?
Correct answer: B. ACE wants you to recognize impersonation as the safer path when temporary delegated access is enough and key sprawl is a risk.