Symptom: impersonation fails: "[IDENTITY] does not have iam.serviceAccounts.getAccessToken access to service account [SA]" or the gcloud flag errors similarly.
Cause: the source identity (your user, or a CI SA) was not granted Service Account Token Creator on the target SA. Impersonation is an IAM grant, not just a flag.
Confirm:
1. `gcloud iam service-accounts get-iam-policy [SA-EMAIL]` - look for your identity with roles/iam.serviceAccountTokenCreator.
2. Check you are granting on the right SA: the error names the target. Agents often grant Token Creator on SA-A while impersonating SA-B.
3. Chained impersonation (A impersonates B impersonates C): EVERY link needs the grant. Check each hop.
Fix:
```
gcloud iam service-accounts add-iam-policy-binding [SA-EMAIL] --member user:[YOU] --role roles/iam.serviceAccountTokenCreator
```
(Or --member serviceAccount:[CI-SA] for CI.)
After the grant works, remember impersonation only changes WHO you act as. If the next error is a 403 on the actual API, the target SA itself lacks that API's role. Two grants, two problems, in that order.
Client-library path: the same grant covers google.auth.impersonated_credentials. If gcloud impersonation works but Python fails, the difference is scopes (set target_scopes to cover your APIs) or an expired source credential, not the grant.
Verify: `gcloud auth print-access-token --impersonate-service-account [SA-EMAIL]` returns a token, and a read-only call with the flag succeeds.