terraform plan fails on a GCP budget: amount validation error — sp

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

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

Set the Terraform working directory if the config is not at the repo root. Enable speculative plans on pull requests in the workspace VCS settings.

Steps

1. A PR that changes Terraform without a plan is a PR nobody actually reviewed. VCS-connected workspaces run speculative plans automatically: full plans against the PR branch that never touch state and never apply. With cost estimation enabled, the PR also shows the projected cost delta.
2. Connect the workspace to the VCS repo. Set the Terraform working directory if the config is not at the repo root.
3. Enable speculative plans on pull requests in the workspace VCS settings. Every PR gets a plan run linked as a status check.
4. Enable cost estimation if the plan includes supported resources. The run shows added/changed cost per resource.
5. Require the plan status check to pass before merge, the same way you require CI.
6. Speculative plans cannot apply and cannot write state. If a PR plan shows "would create" for resources that already exist, the config drifted from reality; fix the config or import, do not force-apply.
7. A speculative plan that fails to even plan is a broken PR. Do not merge around it.
8. Cost estimates cover supported resource types only. "No cost change shown" is not "free"; it can mean "unsupported resource".
9. Keep the working directory setting accurate. A workspace pointed at the wrong directory plans the wrong config and the PR check is meaningless.

When to use

You are seeing this: Connect the workspace to the VCS repo. Use this skill when you run into "HCP Terraform: speculative plans and cost estimation on every PR".

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.

Why this happens

A PR that changes Terraform without a plan is a PR nobody actually reviewed.

HCP Terraform VCS workspaces support speculative plans on pull requests and cost estimation on runs; runs page shows plan output and cost deltas. Verified against live cloud docs 2026-09-26. Verified against live docs 2026-09-26.