Terraform 0.12.6 changes S3 backend credential selection

A Terraform upgrade can change the identity used to access state without changing the bucket name or any infrastructure resource. Terraform 0.12.6, released on July 31, includes an AWS SDK update that changes credential selection when a named profile and static environment credentials are both present.

The release note specifies the competing inputs. When AWS_PROFILE is set alongside AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, the updated SDK prefers credentials found through the profile. Previously the static environment credentials caused it to ignore AWS_PROFILE. The distinction matters for the S3 backend because its requests determine which state Terraform can read and update.

I consider backend identity part of a Terraform configuration's operating context. The DSL can make resource declarations reusable, but it cannot make an ambiguous credential environment obvious to a reader. This patch deserves attention even when the configuration itself produces no source diff.

A dependency update changes behavior

Pull request 22253 updates the AWS Go SDK to v1.21.7 and records the credential precedence change. It also adds web identity support and recognition of the new me-south-1 region. The precedence behavior is described as a bug fix in the SDK, while Terraform's release notes call it out separately as an upgrade consideration.

Both descriptions can be correct. A dependency can correct its intended behavior while a caller observes a change to a long-standing result. An environment that supplied both credential sources previously had one effective precedence rule. After the update, the same environment can select another source.

The relevant scenario does not require a malformed key or a missing profile. Both sources may be usable, but they need not represent the same identity. A successful credential lookup therefore does not prove that Terraform selected the source an operator intended. The release note is about resolving that choice, not merely about making more credentials discoverable.

This claim has a defined scope. It concerns the named environment variables and S3 backend behavior in this release. It should not be generalized into a universal precedence table for every AWS client, every explicit backend credential argument, or every separately installed provider version.

The backend creates its own session

The S3 backend implementation at the release tag builds an AWS base configuration from backend settings and obtains a session. It constructs its S3 and DynamoDB clients from that session. This is code in the Terraform CLI's backend implementation.

An AWS provider configuration elsewhere in the module is a different configuration boundary. Editing a provider alias does not rewrite the backend's session construction. The SDK update in the Terraform binary can therefore affect state access independently of the provider binaries that perform resource operations.

The versioned backend documentation gives the basic state location this way. The names below are illustrative and assume the bucket already exists.

terraform {
  backend "s3" {
    bucket = "example-terraform-state"
    key    = "network/terraform.tfstate"
    region = "us-east-1"
  }
}

The location stays constant when credential selection changes. Whichever identity the SDK selects still needs permission to operate on that location. The documentation identifies bucket listing and object read and write permissions. When the backend uses DynamoDB locking, the identity also needs the documented table permissions.

This explains two possible observations after an upgrade. A newly selected profile might lack access and cause initialization to fail. It might also have access, allowing the command to proceed under a different identity. These are consequences of the documented selection change, not reports of incidents or guarantees about how a particular IAM policy behaves.

Web identity becomes another supported source

The SDK update also lets the S3 backend assume a role using AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN. The release notes identify those environment variables explicitly. This supplies a supported path for an environment that already has a web identity token and a role to assume.

That addition should be read separately from the profile precedence fix. Supporting a new source does not establish that an existing environment will choose it ahead of every other configured source. The credentials available to the process and the SDK's selection rules remain part of the result.

The region change has another specific qualification. Automatic validation now accepts me-south-1, but the release notes say the region must be enabled for AWS operations to work. The pull request shows that an account without the necessary enablement can receive an invalid-token error during credential validation. Recognizing a region name is distinct from authorizing its use.

The same release adds resource iteration

Version 0.12.6 also introduces resource for_each. The resource documentation at this tag describes map or string-set inputs and instances identified by their keys. That is a substantial language feature in the same patch release, although it is separate from the backend credential change.

I welcome language improvements that make reusable infrastructure easier to express, but state access remains a prerequisite for interpreting the resulting plan. This release changes both configuration capabilities and part of the execution environment. The S3 upgrade note gives a precise condition to resolve, so a process that supplies a named profile and static key variables should have an intentional credential choice before it reads or writes shared state.