Warning: Deprecated Parameter: "dynamodb_table" is deprecated, use "use_lockfile" instead

Not specified by the original author.

TL;DR

dynamodb_table in the S3 backend is deprecated (AWS provider 5.100+). The replacement is S3-native locking: use_lockfile = true in the backend block, which needs Terraform 1.10+. Make the switch, run terraform init -reconfigure, and you can drop the DynamoDB table.

The warning

Warning: Deprecated Parameter
The parameter "dynamodb_table" is deprecated. Use parameter "use_lockfile" instead.

Steps to fix

1. Confirm your Terraform version is 1.10+ (terraform version); use_lockfile does not exist earlier.

   • Expected: version requirement met, or upgrade first.

2. Update the backend block:

   backend "s3" {
     bucket       = "llmops-bedrock-tfstate"
     key [your value]
     region       = "us-east-1"
     use_lockfile = true
     encrypt      = true
   }

   • Expected: no dynamodb_table remains.

3. Run terraform init -reconfigure.

   • Expected: init succeeds; locking now uses a .tflock object in S3.

4. After confirming applies lock correctly, decommission the DynamoDB table.

   • Expected: one less resource to manage, warning gone.

When to use this

• terraform init/plan prints the dynamodb_table deprecation warning on AWS provider 5.100+.

When NOT to use this

• Actual lock failures (ConditionalCheckFailedException) are operational, not deprecation, and are fixed by unlocking, not by migrating. Do not migrate mid-incident.

Compatibility

• use_lockfile: Terraform 1.10+, AWS provider 5.100+. Older setups keep dynamodb_table with no warning.

Root cause

S3 now supports conditional writes, so Terraform can implement locking with a lockfile object in the bucket itself. The provider deprecated the DynamoDB path to consolidate on the simpler mechanism.

Edge cases

• Both set: use_lockfile wins; remove dynamodb_table to silence the warning.
• Cross-account state buckets need the caller's S3 permissions to include the lockfile object operations.
• Teams pinned to Terraform < 1.10 must stay on dynamodb_table and accept the warning (or upgrade Terraform).

The llmops-bedrocks-project troubleshooting guide records this exactly: "Warning: Deprecated Parameter. The parameter \"dynamodbtable\" is deprecated. Use parameter \"uselockfile\" instead." Root cause: Terraform AWS provider v5.100 deprecated dynamodbtable for state locking in favor of S3 native locking via uselockfile = true (introduced in Terraform 1.10+). The fix updates the backend block to uselockfile = true and runs terraform init -reconfigure. The lesson notes uselockfile writes a .tflock file directly to S3 instead of a separate DynamoDB table.

Not specified by the original author.

TL;DR

Another process holds the state lock, or a crashed process left a stale one in DynamoDB. If a run is genuinely active, wait. If the lock is stale, terraform force-unlock [ID] with the ID from the error; if even that fails, delete the lock row from DynamoDB directly.

The error

Error: Error locking state: Error acquiring the state lock:
ConditionalCheckFailedException: The conditional request failed
Lock Info:
  ID: terraform-s3-bucket/path/to/terraform.tfstate-md5
  Path: terraform-s3-bucket/path/to/terraform.tfstate
  Operation: OperationTypePlan
  Who: root@runner-123-concurrent-0

Steps to fix

1. Check whether the holder is still alive. The Who and Created fields name the machine and time. If a CI job or teammate is mid-run, wait for it.

   • Expected: the other run finishes and your retry succeeds.

2. If the holder is gone (crashed runner, killed process), force-unlock with the exact ID from the error:

   terraform force-unlock terraform-s3-bucket/path/to/terraform.tfstate-md5

   • Expected: Terraform state has been successfully unlocked!

3. If force-unlock fails (malformed lock row, CLI cannot reach the backend), delete the row directly:

   aws dynamodb delete-item --table-name terraform-state-lock \
     --key '{"LockID": {"S": "your-bucket/path/terraform.tfstate"}}' \
     --region us-east-1

   • Expected: the scan of the table no longer shows the lock.

4. Run terraform plan to confirm the state is healthy before any apply.

   • Expected: plan runs without lock errors.

When to use this

• Any Terraform command fails with Error locking state ... ConditionalCheckFailedException on an S3+DynamoDB backend, especially after a cancelled CI job or crashed laptop.

When NOT to use this

• Error acquiring the state lock on a local backend is a lock file on disk, not DynamoDB. Never force-unlock while another operation is genuinely running: you can corrupt state.

Compatibility

• Terraform 0.9+ through 1.x with the S3 backend dynamodb_table option. Terraform 1.10+ offers S3-native locking via use_lockfile = true as an alternative.

Root cause

DynamoDB implements the lock as a conditional write: acquiring the lock succeeds only if no lock row exists. ConditionalCheckFailedException means the row already exists, i.e. someone (or something crashed mid-run) holds it. Crashed processes never run their unlock, so the row goes stale.

Edge cases

• Two CI jobs racing on the same workspace produce this constantly; serialize them or split state per environment.
• terraform force-unlock refuses without the exact lock ID; copy it from the error, not from memory.
• As a last resort on the machine that held the lock: kill Terraform processes and remove local .terraform.tfstate.lock.info files, then verify with ps.

Scalr's state-lock guide documents the exact DynamoDB failure: "Error: Error locking state: Error acquiring the state lock: ConditionalCheckFailedException: The conditional request failed" with full Lock Info (ID, Path, Operation, Who). It gives the three-level recovery: terraform force-unlock with the ID from the error, manual DynamoDB delete-item of the lock row when the CLI cannot do it, and a break-glass procedure (pkill terraform, remove local lock files) as a last resort. The guide stresses the lock row is just a DynamoDB item keyed by LockID.

Not specified by the original author.

TL;DR

Ignore it. When CDKTF manages the remote backend, cdktf destroy deletes the DynamoDB lock table along with everything else, so the final lock check fails. The destroy itself succeeded.

The error

After cdktf destroy completes, you see an error message saying failed to retrieve lock info.

Fix it

1. Verify the destroy actually worked: check that the resources are gone (AWS console, or re-run cdktf diff and confirm no state).
2. If everything is deleted, no action needed; the error is expected.
3. If resources remain, the destroy genuinely failed; read the earlier output for the real error.

Expected result: all stack resources (and optionally the backend bucket/table) are deleted.

When to use this

• cdktf destroy ends with "failed to retrieve lock info" but resources are gone
• You let CDKTF manage the S3 backend bucket and DynamoDB table

When NOT to use this

• Deploy/plan fails with a lock error while the table still exists (that is real lock contention; use force-unlock)
• Resources were not actually deleted

Root cause

Terraform checks the state lock after operations. When the stack itself provisions the backend (S3 bucket + DynamoDB table) and destroy removes them, the post-destroy lock lookup targets a table that no longer exists, producing the error. It is cosmetic.

Edge cases

• If you want a clean destroy log, manage the backend outside the stack (answer "no" to backend management) so the table survives.

Asked: how to fix cdktf destroy reports "failed to retrieve lock info" after deleting the state backend. Verified answer: Explains the expected failed-to-retrieve-lock-info error when cdktf destroy deletes the S3 bucket and DynamoDB table that held the state lock, and why it is safe to ignore. The fix steps above were cross-checked against the accepted community answer at https://dev.to/aws-builders/cdk-for-terraform-cdktf-on-aws-how-to-configure-an-s3-remote-backend-and-deploy-a-lambda-function-url-using-python-3okk, which confirms the same resolution.