Error: Unsupported block type: "Blocks of type X are not expected here" in Terraform

TL;DR

You used a nested block the resource schema does not accept, usually because a provider upgrade moved it to a standalone resource. The classic case: versioning { } inside aws_s3_bucket was removed in AWS provider 4.x and became aws_s3_bucket_versioning. Move the block to the replacement resource.

The error

Error: Unsupported block type

  on main.tf line 10, in resource "aws_s3_bucket" "this":
  10:   versioning {

Blocks of type "versioning" are not expected here.

Steps to fix

1. Note the block type the error names (versioning) and the resource it sits in (aws_s3_bucket).

• Expected: you know exactly which block to move.

1. Check the provider's changelog or registry docs for that resource: look for the block name under "removed" or as a separate resource page.

• Expected: docs show a standalone resource (e.g. aws_s3_bucket_versioning).

1. Delete the nested block and create the standalone resource instead, referencing the bucket:

   resource "aws_s3_bucket_versioning" "this" {
     bucket = aws_s3_bucket.this.id
     versioning_configuration { status = "Enabled" }
   }

• Expected: no nested block remains in the original resource.

1. Run terraform validate, then plan and check for replacement surprises before applying.

• Expected: validate passes; plan shows the versioning managed by the new resource.

When to use this

• validate/plan fails with Unsupported block type after a provider major-version upgrade, most famously AWS provider 4.x splitting S3 bucket sub-resources out.

When NOT to use this

• Unsupported argument is for arguments (single values), not blocks. If you wrote the block type yourself from scratch, check the spelling against the docs first.

Compatibility

• Terraform 0.12+. The S3 split happened in hashicorp/aws 4.0; similar splits exist in other providers' major versions.

Root cause

Providers evolve their schemas. When a nested block becomes a top-level resource, the old block type disappears from the schema, and any configuration still using it fails schema validation. The error is Terraform telling you the schema no longer contains that block type.

Edge cases

• Some blocks were renamed rather than extracted; the fix is then just the new block name.
• dynamic blocks generating the old block type fail the same way; update the for_each content labels.
• Importing existing infrastructure after the split requires importing each new standalone resource separately.