Terraform Duplicate Resource ID Auditor

The Incident (What Does the Error Mean?)

Raw error output from terraform plan:

Error: error creating <RESOURCE_TYPE> (<RESOURCE_ID>): EntityAlreadyExists: resource with ID "arn:aws:iam::123456789012:role/my-app-role" already exists.

  on main.tf line 14, in resource "aws_iam_role" "my_app_role":
  14: resource "aws_iam_role" "my_app_role" {

Or the state-side variant:

Error: Resource already managed by Terraform

Terraform is already managing a remote object for
aws_s3_bucket.data_lake. To import it, first remove the existing object
from the state using `terraform state rm`.

Immediate consequence: terraform apply is fully blocked. No changes in the plan will be applied — not just the conflicting resource, but the entire run. In a pipeline, this means a dead deployment. If this is a terraform apply -auto-approve in CI/CD, the job fails and any downstream modules depending on this resource's outputs will also fail, cascading across your stack.

The Attack Vector / Blast Radius

This error surfaces from three distinct root causes, each with a different blast radius:

1. Out-of-band resource creation (most common in production outages) Someone created the resource manually via the AWS Console, aws cli, or a one-off script. Terraform has no state entry for it. When you write the HCL to codify it, Terraform tries to CREATE it — but the provider rejects the call because the ID already exists at the API level. The risk: If you force-apply, you either get a hard error or, worse, Terraform creates a second resource with a slightly different name, leaving a zombie resource you'll pay for and never track.

2. Duplicate HCL resource blocks (copy-paste incident) A developer copies a resource block and changes the logical Terraform name but forgets to change the provider-side name/ID argument (e.g., name = "my-app-role" is identical in both blocks). Terraform generates two API calls for the same provider-side ID. The risk: Non-deterministic apply behavior — whichever resource block wins the race gets created; the second call fails. Your state is now partially applied.

3. State file desync after terraform state rm or workspace switch A resource was removed from state (intentionally or by accident) but the real infrastructure still exists. Re-running apply re-triggers a create call. The risk: In multi-workspace or Terraform Cloud setups, this can cause the same physical resource to be "owned" by two workspaces simultaneously, making future destroys unpredictable and dangerous.

Prevention in CI/CD

1. Checkov — Detect duplicate resource names pre-plan:

checkov -d . --check CKV_TF_1
# Also run: checkov -d . --framework terraform
# Checkov will flag resource blocks with identical name arguments

2. terraform validate + tflint as a pre-commit gate:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    hooks:
      - id: terraform_validate
      - id: terraform_tflint
        args:
          - --args=--enable-rule=terraform_required_providers

3. OPA/Conftest policy — Block plans with create actions on already-tracked IDs:

# policy/no_duplicate_ids.rego
package terraform

deny[msg] {
  rc := input.resource_changes[_]
  rc.change.actions[_] == "create"
  rc.change.before != null  # Resource already has prior state — should be update, not create
  msg := sprintf("Resource '%v' has prior state but action is CREATE — possible duplicate ID conflict", [rc.address])
}

4. Terraform Cloud / Atlantis — Always require plan approval before apply: Never run apply -auto-approve on resources that manage unique provider-side identifiers (IAM role names, S3 bucket names, RDS identifiers). Gate every apply on a human-reviewed plan artifact. Use remote state locking (DynamoDB for S3 backend) to prevent concurrent applies that can generate race-condition duplicate ID errors.

5. Tag and track manually created resources: Enforce an IaC tag policy (e.g., ManagedBy = terraform) on all resources. Any resource without this tag in your account is a candidate for the duplicate ID error the next time someone tries to codify it. Use AWS Config rules or GCP Asset Inventory to audit untagged resources before they collide with your HCL.