## TL;DR

During apply, the provider returned a value that contradicts what it planned. Terraform treats this as a provider bug, and the error message says so. Your move: upgrade the provider (the bug is often already fixed), and if it persists, file it on the provider's issue tracker with the exact `was ... but now ...` lines.

## The error

```text
Error: Provider produced inconsistent final plan

When expanding the plan for aws_ecs_task_definition.api to include new
values learned so far during apply, provider
"registry.terraform.io/hashicorp/aws" produced an invalid new value for
.container_definitions: inconsistent values for sensitive attribute.

This is a bug in the provider, which should be reported in the provider's
own issue tracker.
```

## Steps to fix

1. Read the `was ... but now ...` (or equivalent) detail: it names the attribute whose planned and apply-time values disagree.
   - Expected: you know which attribute the provider mishandled.
2. Upgrade the provider to the latest version: loosen or bump the version constraint, run `terraform init -upgrade`.
   - Expected: a newer provider contains the consistency fix; re-run apply.
3. If the latest provider still fails, work around by making the planned value match reality: e.g. for sensitive-attribute mismatches, ensure the configuration value is exactly what the API returns (no extra whitespace or reordering in JSON documents).
   - Expected: plan and apply agree on the value.
4. File the issue on the provider's tracker with the full error text, provider version, and a minimal config.
   - Expected: maintainer can reproduce from your report.

## When to use this

- `terraform apply` fails with `Provider produced inconsistent final plan` while `plan` succeeded. The state is usually still written, so a second apply may look clean.

## When NOT to use this

- `Provider produced inconsistent result after apply` is the sibling error for the post-apply read-back check; the triage is the same but the trigger differs. If *your* config changed between plan and apply, that is on you, not the provider.

## Compatibility

- Terraform 0.15+ (the final-plan consistency check). Provider-side; seen across AWS, Vault, Equinix, vSphere providers.

## Root cause

Providers must return values during apply that are consistent with the plan they produced. When a provider normalizes, drops, or reorders a value between plan and apply (sensitive attribute handling, API defaults, JSON canonicalization), Terraform's consistency check fails the apply rather than recording a value it never planned.

## Edge cases

- `ignore_changes` on the flapping attribute can silence it, but it also blinds you to real drift; prefer the provider upgrade.
- JSON policy documents are the classic trigger: semantically identical but textually different documents trip the check. Normalize with `jsonencode` of a decoded value.
- The error aborts the apply but state is usually saved; inspect `terraform plan` after before re-running.