Terraform 1.15: why you should recheck `validate` in CI, especially if you use `-backend-config`

What changed

Terraform 1.15.0 quietly touched one of the most sensitive parts of CI: terraform validate now checks the backend block. It looks at whether the backend type exists, whether required attributes are present, and whether the backend’s own validation logic passes.

That sounds helpful — until you run Terraform with -backend-config. In 1.15.1, HashiCorp removed validation of attributes inside the backend block because it conflicted with workflows that inject part of the configuration from the outside.

In plain language: 1.15.0 made validate stricter, and 1.15.1 made it compatible with real CI setups again.

Why this matters

In many teams, terraform validate is the first cheap gate. It needs to be fast, stable, and predictable. When its behavior changes, two things happen:

• old pipelines start failing without any code change;
• people stop trusting validate because “it keeps acting up”.

This hurts most when:

• state lives in a remote backend;
• backend parameters come from secrets or a separate file;
• terraform init and terraform validate run in different steps;
• module source already uses variables or locals.

In that setup, a tiny mismatch between init and validate can turn into a midnight failure that looks random. Worse, teams may start working around it by hand instead of fixing the pipeline.

The mental model to keep

In a healthy pipeline, terraform init consumes the real backend config you actually use, and terraform validate checks the configuration without breaking that setup. That is why 1.15.1 matters more than plain 1.15.0 if you rely on -backend-config.

How to check your CI

1. Find every place Terraform runs

Start with inventory, not code changes:

• .github/workflows/*.yml
• shell scripts in the repo
• make targets
• any wrapper script around init or validate

Search specifically for terraform init, terraform validate, and -backend-config.

2. Make sure init and validate see the same backend

If init gets backend.hcl from one place and validate runs without it, you already have different conditions. In that case, 1.15.0 may complain even though the real problem is the job layout, not the configuration.

A healthy setup looks like this:

terraform init \
  -backend-config=backend.hcl \
  -input=false

terraform validate

If backend.hcl is generated dynamically, do not hide that from validate. The command needs the same truth, not a simplified version of it.

3. Test the real path on 1.15.1

If you already see or suspect a problem, do not get stuck on 1.15.0. For backend-config workflows, the safer minimum is 1.15.1 or any newer patch release.

For a quick migration check, compare:

• your current version;
• Terraform 1.15.0;
• Terraform 1.15.1.

That tells you whether the failure is a real bug or just the short-lived regression between the two releases.

4. Recheck module source usage

Terraform 1.15 also allows variables and locals in module source and version attributes. That is useful, but it is exactly the kind of change that can expose older CI assumptions.

If your modules are built dynamically, check:

• whether they still resolve from the correct source;
• whether version resolution still behaves as expected;
• whether init now fails instead of validate.

5. Keep the log signal

Terraform 1.15 also improved init logging: timestamps now have millisecond precision. It is not the headline feature, but it is genuinely useful when CI gets flaky.

What not to do

• Do not treat validate as a syntax-only linter.
• Do not stay on 1.15.0 in production CI if you use -backend-config.
• Do not run init with one backend config and validate with another.
• Do not treat support for variables in module source as permission to change everything without retesting.
• Do not disable validate just because it started failing. First understand what it now sees.

Practical takeaway

Short version: Terraform 1.15.0 usefully exposed that backend is part of validation, but if you rely on -backend-config, 1.15.1 is the safer landing point.

What to do today:

• find every CI step that runs Terraform;
• verify that init and validate consume the same backend config;
• test the workflow on 1.15.1;
• separately rerun modules whose module source depends on variables or locals;
• keep one clear path in the pipeline instead of two almost identical ones.

Fewer surprises in validate means fewer nights spent negotiating with a red CI job.