### Terraform Version ```shell 1.15.0 ``` ### Terraform Configuration Files ```terraform # providers.tf terraform { backend "s3" {} required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } ``` ### Debug Output ``` $ terraform init -reconfigure \ -backend-config=bucket=my-bucket \ -backend-config=key=my/state/key.tfstate \ -backend-config=region=eu-west-3 Initializing the backend... Successfully configured the backend "s3"! Terraform will automatically use this backend unless the backend configuration changes. Terraform has been successfully initialized! $ terraform validate ╷ │ Error: Missing required argument │ │ on providers.tf line 2, in terraform: │ 2: backend "s3" {} │ │ The argument "bucket" is required, but no definition was found. ╵ ╷ │ Error: Missing required argument │ │ on providers.tf line 2, in terraform: │ 2: backend "s3" {} │ │ The argument "key" is required, but no definition was found. ╵ ``` ### Expected Behavior `terraform validate` should succeed after a successful `terraform init -reconfigure` that provides all required backend attributes via `-backend-config` flags. The pattern of declaring an empty `backend "s3" {}` block and injecting configuration at init time via `-backend-config` is a well-established and widely documented practice for CI/CD pipelines (see: https://developer.hashicorp.com/terraform/language/backend#partial-configuration). Prior to v1.15.0, `terraform validate` worked correctly in this scenario because it did not inspect backend block attributes. ### Actual Behavior After a successful `terraform init -reconfigure` with all required backend attributes provided via `-backend-config`, `terraform validate` fails: ``` $ terraform init -reconfigure \ -backend-config=bucket=my-bucket \ -backend-config=key=my/state/key.tfstate \ -backend-config=region=eu-west-3 Initializing the backend... Successfully configured the backend "s3"! Terraform will automatically use this backend unless the backend configuration changes. Terraform has been successfully initialized! $ terraform validate ╷ │ Error: Missing required argument │ │ on providers.tf line 2, in terraform: │ 2: backend "s3" {} │ │ The argument "bucket" is required, but no definition was found. ╵ ╷ │ Error: Missing required argument │ │ on providers.tf line 2, in terraform: │ 2: backend "s3" {} │ │ The argument "key" is required, but no definition was found. ╵ ``` This is a breaking change introduced by PR #38021 (merged Feb 13, 2026). The `validate` command now performs a static analysis of the HCL source and ignores the resolved backend configuration stored in `.terraform/` by `init`. This means even when `validate` runs after a successful `init`, it fails. There is now an inconsistency: - `terraform init -reconfigure` with `-backend-config` flags ACCEPTS the empty backend block - `terraform plan` and `terraform apply` WORK correctly after init - `terraform validate` REJECTS the same configuration ### Steps to Reproduce 1. Create a `providers.tf` with an empty `backend "s3" {}` block: terraform { backend "s3" {} } 2. Run: terraform init -reconfigure -backend-config=bucket=my-bucket -backend-config=key=my/key.tfstate -backend-config=region=eu-west-3 3. Observe that init succeeds 4. Run: terraform validate 5. Observe that validate fails with "Missing required argument" for `bucket` and `key` This worked correctly with Terraform v1.14.9 and all prior versions. ### Additional Context ## Why this is a widely used pattern The empty backend block with CLI-injected configuration is the standard approach for multi-environment CI/CD pipelines. It is documented in the Terraform partial configuration documentation (https://developer.hashicorp.com/terraform/language/backend#partial-configuration) and allows teams to: - Use the same Terraform code across multiple environments (dev, staging, production) with different state file locations - Inject backend configuration dynamically from CI/CD variables without hardcoding values - Avoid committing sensitive or environment-specific backend details into version control ## Impact This change breaks CI/CD pipelines that follow the officially documented partial backend configuration pattern. Any pipeline that runs `terraform validate` after `terraform init` with `-backend-config` flags is affected. ## Suggested improvements 1. Skip backend required-attribute checks when the backend has already been configured by `init` (i.e., a valid `.terraform/` directory exists) 2. Add a flag to `terraform validate` (e.g., `-skip-backend` or `-backend=false`) to allow users to opt out of backend validation 3. Downgrade backend validation errors to warnings when required attributes are missing but the backend type is valid, acknowledging that partial configuration is a supported pattern ## Current workarounds - Adding placeholder values (`bucket = "placeholder"`, `key = "placeholder"`) that get overridden by `-backend-config` during init — works but is misleading - Wrapping `terraform validate` in a script that filters out backend-related errors — risks masking legitimate validation issues - Pinning to Terraform v1.14.x — not sustainable ## References - PR that introduced this change: https://github.com/hashicorp/terraform/pull/38021 - Partial backend configuration docs: https://developer.hashicorp.com/terraform/language/backend#partial-configuration ### References - PR that introduced this change: https://github.com/hashicorp/terraform/pull/38021 - Partial backend configuration docs: https://developer.hashicorp.com/terraform/language/backend#partial-configuration ### Generative AI / LLM assisted development? _No response_