Terraform "import" Block Errors - Configuration Mismatch in CI
A declarative import {} block adopts an existing cloud resource into state during apply. It errors when the to resource is not declared, the id is wrong for the provider, or the target is already in state.
What this error means
plan/apply fails on an import block - the to address has no matching resource, the import id format is wrong, or the resource is already managed so the import is redundant. The adoption does not happen.
Error: Configuration for import target does not exist
on import.tf line 1:
1: import {
The configuration for the given import target aws_s3_bucket.logs does not exist.
All target instances must have an associated resource configuration.Common causes
Target resource not declared
The to address in the import block must correspond to a resource block in the config. Importing to an address that has no resource definition fails.
Wrong import ID for the resource type
Each resource type expects a specific ID format. A bucket name vs ARN, or a composite ID in the wrong shape, makes the provider reject the import.
Resource already in state
If the target address is already managed, the import is redundant and Terraform reports the object is already managed.
How to fix it
Declare the resource and use the correct ID
Add the matching resource block, then import with the provider’s expected ID format.
resource "aws_s3_bucket" "logs" {
bucket = "my-app-logs"
}
import {
to = aws_s3_bucket.logs
id = "my-app-logs" # bucket name is the import ID for aws_s3_bucket
}Remove redundant imports
- If Terraform says the resource is already managed, drop the
importblock - it is already in state. - Confirm the
toaddress matches a realresourceblock. - Verify the
idmatches the provider’s documented import format.
How to prevent it
- Pair every
importblock with a declaredresourceblock. - Use the provider docs’ exact import ID format.
- Remove
importblocks after the adoption has applied everywhere.