When a Google Cloud client library needs credentials and you did not pass any explicitly, it uses Application Default Credentials (ADC). ADC checks three places, in this order:
1. The GOOGLE_APPLICATION_CREDENTIALS environment variable, pointing at a service account key file.
2. The user credential file created by `gcloud auth application-default login` (lives in your config dir, not your shell).
3. The attached service account, reached through the metadata server (GCE, GKE, Cloud Run, Cloud Functions, etc).
Why this matters: if ADC picks the wrong identity you get confusing 403s. Common mixup: you ran `gcloud auth login` as yourself, then wonder why the Python client still fails. `gcloud auth login` only authorizes the gcloud CLI. Client libraries need step 1 or 2.
Check which identity ADC will use:
- `echo $GOOGLE_APPLICATION_CREDENTIALS` - if set, that key file wins. Everything else is ignored.
- `gcloud auth application-default print-access-token` - shows the ADC identity for local dev.
- On a VM or Cloud Run, query the metadata server for the default service account email (the computeMetadata v1 instance service-accounts endpoint, with the Metadata-Flavor Google header). That is the attached identity.
Rules of thumb:
- Local dev: use `gcloud auth application-default login`. Never commit a key file.
- CI or production outside Google Cloud: prefer Workload Identity Federation over a key file. If you must use a key, scope it tight and rotate it.
- On Google Cloud: attach a service account to the resource and grant it only the roles it needs. No key files at all.
Quota gotcha: ADC also needs a quota project for APIs that bill per caller. If the credential has no quota project set you can see odd billing errors; `gcloud auth application-default set-quota-project` fixes it.