gcloud end user credentials not supported quota project

Not specified by the original author.

Error 403: Your application has authenticated using end user credentials which are not supported

TL;DR: some Google APIs refuse user credentials from ADC — they need a billing project attached to the call. Run gcloud auth application-default set-quota-project [project] once, or pass --billing-project=[project] on the command. Re-running gcloud auth login alone changes nothing.

Error 403: Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the API.
We recommend configuring the billing/quota_project setting in gcloud or using a service account through the auth/impersonate_service_account setting.

Steps

1. Confirm the shape of the problem: the call 403s with the message above even though gcloud auth application-default print-access-token returns a token fine. The credential works — the API just wont bill it.
2. Attach a quota project to ADC:

gcloud auth application-default set-quota-project [project-id]

Expected: Quota project [project-id] was added to ADC which can be used by Google client libraries for billing and quota.

3. Or set it per command instead:

gcloud scc notifications describe [name] --organization [org-id] --billing-project=[project-id]

4. Or impersonate a service account (needs iam.serviceAccounts.getAccessToken on it):

gcloud ... --impersonate-service-account=[service account email]

5. Retry the original command. Expected: the 403 is gone.

When this applies

• the exact 403 about end user credentials not being supported
• Cloud Shell or ADC user credentials calling APIs like securitycenter or accesscontextmanager
• terraform plan failing with this text when the provider uses your user-creds ADC

When it doesnt

• invalid_grant: Token has been expired or revoked — dead refresh token, re-run gcloud auth login
• API not enabled without the end-user-credentials text — enable the API on the project
• plain permission denied — the credential is fine, the IAM role is missing

Compatibility

Google Cloud SDK, all recent versions. ADC file: ~/.config/gcloud/applicationdefaultcredentials.json.

Why it happens

ADC user credentials carry no quota project, so APIs that bill per call reject them outright. The gcloud CLI usually supplies the project from its own config, but ADC consumers — client libraries, terraform, and some gcloud paths in Cloud Shell — dont, so the call arrives unbilled and gets 403d.

Edge cases

• you need the serviceusage.services.use permission on the quota project or the set-quota-project call fails
• the terraform Google provider has its own quotaproject and impersonateservice_account settings for the same problem
• pick a project you own: the quota project gets billed for the API usage

Find this skill again

curl -s 'https://vectle.com/api/v1/search?q=gcloud+end+user+credentials+not+supported+quota+project'

Users calling Google APIs with application-default user credentials hit Error 403: Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the API. The verified fixes: gcloud auth application-default set-quota-project to attach a billing project to ADC, pass --billing-project on the command, or impersonate a service account — re-running gcloud auth login does not help. Source: https://github.com/googlecloudplatform/terraform-google-enterprise-genai/blob/HEAD/docs/TROUBLESHOOTING.md

Not specified by the original author.

TL;DR

Check for a runaway: did usage spike 100x at some timestamp? Fix by cause: - Legitimate need: request a quota increase from the quotas page. This is the only fix for real growth. - Runaway loop: fix the code first (backoff, batching, idempotency), then the quota error clears on its own as usage drops. - Wrong project/region: quotas are per project per region.

When to use

You are seeing this: Symptom: "Quota exceeded for quota metric '[METRIC]' and limit '[LIMIT]' of service '[SERVICE]'". Use this skill when you run into "Diagnose: Quota exceeded for quota metric".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Steps

1. Symptom: "Quota exceeded for quota metric '[METRIC]' and limit '[LIMIT]' of service '[SERVICE]'".
2. Cause: the project hit a quota: API rate, concurrent operations, or resource count. Either legitimate growth or a bug generating load.
3. Confirm:
4. Copy the exact metric name from the error.
5. Console: IAM and Quotas, filter by that metric. See current usage vs limit and which region/service.
6. Check for a runaway: did usage spike 100x at some timestamp? Look at your deploy/retry logs around that time. Agents' retry loops are a classic cause.
7. Fix by cause:

• Legitimate need: request a quota increase from the quotas page. Some increases are automatic, some need review. This is the only fix for real growth.
• Runaway loop: fix the code first (backoff, batching, idempotency), then the quota error clears on its own as usage drops.
• Wrong project/region: quotas are per project per region. You may just be deploying to a region with a low default limit; switch regions or raise that region's limit.

5. Do not hammer retries against a quota error. It extends the block and can look abusive. Back off, fix, then retry once.
6. Prevention: for batch workloads, add client-side rate limiting and concurrency caps before you need quota increases. Quotas protect the platform; your code should protect your quota.
7. Verify: the quotas dashboard shows usage under limit after the fix, then rerun the original operation.

Verified 2026-09-26: quota error format with named metric is documented across services (BigQuery quotaExceeded docs describe the pattern). The increase-request flow is the documented quotas-page process.

Not specified by the original author.

TL;DR

When a Google Cloud client library needs credentials and you did not pass any explicitly, it uses Application Default Credentials (ADC). Check which identity ADC will use: - echo $GOOGLE\APPLICATION\CREDENTIALS - if set, that key file wins. Rules of thumb: - Local dev: use gcloud auth application-default login.

When to use

You are seeing this: ADC checks three places, in this order: 1. Use this skill when you run into "GCP ADC search order: where your client library actually looks for credentials".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

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 GOOGLEAPPLICATIONCREDENTIALS 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.

Verified 2026-09-26 on the official ADC docs: search order is GOOGLEAPPLICATIONCREDENTIALS, then the gcloud auth application-default login file, then the attached service account from the metadata server. The docs stress the order is fixed and not about merit. This skill exists because agents routinely confuse gcloud auth login (CLI only) with ADC (client libraries), and misdiagnose the resulting auth failures.