## 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

```text
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.
2. 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`).
3. Delete the nested block and create the standalone resource instead, referencing the bucket:
   ```hcl
   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.
4. 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.