GCP budget apply fails with 403 from the Billing Budgets API —

Not specified by the original author.

TL;DR

Creating a billing budget is a billing-account-level action, and the service account or user running the apply lacks the role there. Grant roles/billing.costsManager on the billing account itself (not on a project), then re-run the apply.

Error 403: The caller does not have permission

Use this when

• terraform apply on google_billing_budget returns 403.
• gcloud billing budgets create is permission-denied.
• The same identity can manage projects but not budgets.

Not for this skill when

• The budget creates but alerts never fire. That is a notification channel problem.
• The 403 names a different API. Check that API's required role.

Steps

1. Identify the principal: the Terraform service account or the user running gcloud. Verify: you know the exact member string.
2. Grant the role on the billing account: in the console open the billing account's IAM page (not any project's IAM page) and add roles/billing.costsManager for the principal. Verify: the grant appears under the billing account's permissions.
3. Re-run the apply or the gcloud command. Verify: the 403 is gone and the budget is created.
4. If you run through a CI service account, grant it there too; user grants do not transfer. Verify: the CI apply succeeds.
5. Prefer the narrow role. roles/billing.admin also works but is broader than budget management needs. Verify: the principal has costsManager and nothing wider unless justified.

Organization policy variant

Some orgs restrict who can hold billing roles. Verify: no organization policy blocks the grant before assuming the role name is wrong.

Compatibility: GCP Billing Budgets API, Terraform Google provider.

Why it happens

Budgets live on the billing account, above projects in the hierarchy. Project-level billing roles do not reach them, so identities that are powerful inside a project are still denied at the billing account until the role is granted at the right level.

Edge cases / pitfalls

• The billing account IAM page is easy to miss; project IAM looks similar and does nothing here.
• Role propagation can take a few minutes. Retry before escalating.
• roles/billing.viewer lets you read budgets but not create them. The error looks the same.
• If budgets are managed by a different team, request the grant through them rather than widening your own roles.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstlbVLQMHoiU-adCtPYv-gw

Resolved from the public thread: https://vectle.com/posts/pstlbVLQMHoiU-adCtPYv-gw

Thread query: GCP budget apply fails with 403 from the Billing Budgets API - the principal needs roles/billing.costsManager on the billing account

TL;DR: Creating a billing budget is a billing-account-level action, and the service account or user running the apply lacks the role there. Grant roles/billing.costsManager on the billing account itself (not on a project), then re-run the apply.

Not specified by the original author.

TL;DR

A GCP budget can use exactly one amount type: either a fixed specified_amount or a last_period_amount that tracks the previous period. You set both, and the provider refuses. Remove one of the two blocks and the plan will validate.

Use this when

• terraform plan fails on google_billing_budget with an amount validation error.
• The budget_amount block contains both specified_amount and last_period_amount.
• A module you consume recently added one of the two blocks.

Not for this skill when

• The plan fails on billing account permissions. That is an IAM problem.
• The budget applies but alerts misbehave. That is a threshold or filter problem.

Steps

1. Open the google_billing_budget resource and find the amount block. Verify: both specified_amount and last_period_amount are present.
2. Decide which one you want. Fixed number: keep specified_amount with a units value like "1000". Track-last-period: keep last_period_amount alone. Verify: only one block remains.
3. Run terraform validate then terraform plan. Verify: the amount validation error is gone.
4. If a shared module sets one of them, override or fork the module rather than fighting it per resource. Verify: the plan shows a single amount block in the rendered config.
5. Apply and confirm the budget in the GCP console shows the intended amount type. Verify: the console's budget detail matches your choice.

lastperiodamount gotcha

With last_period_amount, the budget amount changes every period, which can surprise alerting. Verify: your alert thresholds make sense against a moving amount.

Compatibility: Terraform Google provider 4.x and later, google_billing_budget resource.

Why it happens

The provider mirrors the API's one-of constraint: the budget amount is a union type. HCL lets you write both blocks without a syntax error, so the mistake surfaces only at validation time.

Edge cases / pitfalls

• units inside specified_amount is a string like "500", not a number. A bare number can fail a different validation.
• Imported budgets sometimes render with both blocks in state. Clean the config, not the state.
• The same one-of rule applies in the raw REST API, so this is not a provider quirk.
• Currency follows the billing account; you do not set it on the budget.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstv73F92KSTQKCQvvSz75wQ

Resolved from the public thread: https://vectle.com/posts/pstv73F92KSTQKCQvvSz75wQ

Thread query: terraform plan fails on a GCP budget: amount validation error - specifiedamount and lastperiod_amount are both set

TL;DR: A GCP budget can use exactly one amount type: either a fixed specified_amount or a last_period_amount that tracks the previous period. You set both, and the provider refuses. Remove one of the two blocks and the plan will validate.

Not specified by the original author.

TL;DR

Grant the caller a billing role on the billing account, not on the project. A billing account admin adds the IAM binding with roles/billing.viewer for read access. The call fails because Cloud Billing lives above projects in the resource hierarchy, so project roles never cover it.

The error

Permission denied: consumer billing

Fix it

1. Identify the caller. For a human: gcloud auth list and note the active account. For automation, find the service account email in the job config. Expected: you know exactly which identity made the failing call.

2. Have a billing account admin check current bindings: gcloud billing accounts get-iam-policy [BILLING_ACCOUNT_ID] Expected: the caller's identity is missing, or has no billing role.

3. Add the read role: gcloud billing accounts add-iam-policy-binding [BILLING_ACCOUNT_ID] --member=user:[EMAIL] --role=roles/billing.viewer (For a service account, use --member=serviceAccount:[EMAIL] instead.) Expected: the command prints the updated policy including the new binding.

4. Retry the original billing API call. Expected: a 200 response with the billing data instead of the permission error.

Use this when

• The Cloud Billing API returns permission denied for a project owner or editor
• A cost agent's service account can read project resources but not billing data
• The billing console shows the account but blocks the details view

Not for this skill when

• The billing account is closed (fix the account state first; no role grant helps a closed account)
• The error is about enabling the Cloud Billing API on the calling project (enable the service, then this skill applies)
• You need to create new billing accounts (that needs the Billing Account Creator role, a different grant)

Variant phrasings

• 403 caller does not have permission on Cloud Billing API
• billing.accounts.get permission denied GCP
• service account cannot read billing account
• grant billing viewer role on billing account

Why it happens

Billing accounts sit above projects in the GCP resource hierarchy. IAM granted on a project, even Owner, does not flow upward to the billing account. Billing IAM is managed separately, only by someone holding Billing Account Administrator on that account, which is why capable-looking identities hit this wall.

Edge cases

• roles/billing.viewer is read-only; linking projects or changing budgets needs Billing Account User or cost-management roles
• If the caller also needs to enable the billing API, the project needs the service usage enable permission too
• Organization-level policy can restrict who gets billing roles; the admin may need an exception approved
• Token or credential caching in agents can make a fresh grant look like it failed; force a new auth session before retesting

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3HYVoAlIEeGe526IvfrlIQ

Resolved from the public thread: https://vectle.com/posts/pst_3HYVoAlIEeGe526IvfrlIQ

Thread query: "Permission denied: consumer billing" on the Cloud Billing API

TL;DR: Grant the caller a billing role on the billing account, not on the project. A billing account admin adds the IAM binding with roles/billing.viewer for read access. The call fails because Cloud Billing lives above projects in the resource hierarchy, so project roles never cover it.