Terraform "provider produced inconsistent result" fix

TL;DR

Terraform's "provider produced inconsistent result after apply" means the provider returned a different value for an attribute after creating the resource than it planned. This is usually a provider bug around computed attributes, but it is often triggered by your config: a value that changes between plan and apply (like a timestamp or random id used in two places), or a resource the provider normalizes. Pin the provider version, find the offending attribute in the error, and work around it with lifecycle or a data source.

Error / query

Terraform "provider produced inconsistent result" fix

Use this skill when

• terraform apply fails with Provider produced inconsistent result after apply
• The error names a specific resource and attribute path like .tags["Name"]
• It started after a provider upgrade
• It happens intermittently on the same config

Not for this skill when

• Plan and apply disagree because someone changed the config between them (re-run plan)
• The error is about a data source read during apply (different timing issue)
• State is locked or corrupted (state management, not provider consistency)
• You are writing a provider (this is consumer-side troubleshooting)

Steps

Step 1: Read which attribute was inconsistent

terraform apply 2>&1 | grep -B 5 -A 15 "inconsistent result"

Expected: the error names the resource address and the attribute path (e.g. aws_instance.web: ... .user_data). That attribute is the entire investigation.

Step 2: Check whether a provider upgrade introduced it

grep -A 3 "required_providers" versions.tf 2>/dev/null; terraform version
git log --oneline -5 -- .terraform.lock.hcl

Expected: if the lockfile changed recently, try pinning the previous provider version and re-applying in a test workspace. Provider regressions on computed attributes are common enough to check first.

Step 3: Look for values that legitimately change between plan and apply

grep -rn "timestamp()\|uuid()\|random_" --include="*.tf" . | grep -v ".terraform"

Expected: any use of timestamp(), uuid(), or random values feeding the inconsistent attribute. These produce a new value on every plan, so plan-time and apply-time never match; replace with a stable input variable.

Step 4: Work around provider normalization with lifecycle

grep -B 5 -A 10 "lifecycle" [resource-file].tf

Expected: if the provider normalizes the value (case, ordering, defaults), add a lifecycle { ignore_changes = [problem_attribute] } block so Terraform stops fighting the provider over it. Confirm the ignored attribute is safe to ignore (tags and descriptions usually are; security settings are not).

Step 5: Verify with a clean plan/apply cycle

terraform plan -out=tfplan && terraform apply tfplan

Expected: apply succeeds and a follow-up terraform plan shows no changes. If the inconsistency persists on the same attribute with a pinned provider, file it as a provider bug with the exact attribute path and a minimal config.

Variant phrasings

"terraform apply inconsistent result after apply"

Same error. The attribute path in the message is the starting point, step 1.

"provider produced inconsistent final plan"

The plan-phase cousin: something changed between the plan and the final plan walk. Usually a data source read or a timestamp(); same step 3 hunt.

"happens only sometimes on same terraform code"

Intermittent inconsistency points at ordering/normalization races in the provider or at eventually consistent APIs. Pin the provider version and retry; if it persists, it is a provider bug.

Why it happens

Terraform's contract with providers: the value planned for an attribute must equal the value returned after apply. Providers break this when they compute or normalize attributes server-side (defaults filled in, ordering changed, case folded) and report the normalized value, or when the config feeds a value that is regenerated between plan and apply. Terraform cannot tell a benign normalization from real drift, so it errors.

Edge cases and pitfalls

• ignore_changes on a security-relevant attribute (SG rules, IAM policies) hides real drift; scope it to the exact attribute path.
• Some providers need the attribute set explicitly to the normalized form (e.g. lowercase) instead of ignored; try setting the canonical value first.
• terraform refresh-only workflows can mask the inconsistency until the next apply; always verify with plan-after-apply.
• Provider bug reports need the minimal config and the exact inconsistent attribute; "it fails sometimes" without the attribute path gets closed.
• Do not "fix" it by tainting and recreating in a loop; if the provider normalizes on every create, recreation fails the same way.

Provenance

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

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

Thread query: Terraform "provider produced inconsistent result" fix

TL;DR: Terraform's "provider produced inconsistent result after apply" means the provider returned a different value for an attribute after creating the resource than it planned. This is usually a provider bug around computed attributes, but it is often triggered by your config: a value that changes between plan and apply (like a timestamp or random id used in two places), or a resource the provider normalizes. Pin the provider version, find the offending attribute in the error, and work around it with lifecycle or a data source.