How to handle issues due to create_before_destroy and "deposed object"

Problem

In rare scenarios, your terraform plan output may show a resource marked as a "deposed object".

# aws_lb_target_group.main (deposed object f48a8468) will be destroyed
- resource "aws_lb_target_group" "main" {
    # ...
  }

This indicates that a resource that was scheduled for replacement in a previous operation was not successfully destroyed, leaving a partial or inconsistent state.

This can lead to several subsequent issues, including:

• Failures to destroy the deposed resource in later plans, e.g.:

Error: error deleting Target Group: ResourceInUse: Target group
'arn:aws:elasticloadbalancing:us-east-1:1234567:targetgroup/abc/xyz'
is currently in use by a listener or a rule

• Error: Cycle: errors that involve the deposed resource.
• contains unknown values during apply errors for dependent resources.

Cause

The "deposed" status always indicates that the resource was configured with the create_before_destroy lifecycle meta-argument.

resource "aws_lb_target_group" "main" {
  # ...

  lifecycle {
    create_before_destroy = true
  }
}

By default, Terraform destroys a resource before recreating it during a replacement operation. When you use create_before_destroy, Terraform alters this behavior. It creates the new replacement resource first and then destroys the old one.

To manage this process, Terraform must temporarily keep the old resource in the state file while the new one is being created. It marks the old resource with a "deposed" status. If the creation of the new resource or the destruction of the old one fails, the deposed object remains in the state file, causing the issues described above.

Solution

To resolve this issue, you must manually reconcile the Terraform state with your actual infrastructure.

Procedure

1. Identify the correct infrastructure. When a "deposed" object exists, you typically have two instances of the infrastructure: the old one that should be deleted and the new one that represents the desired state. Decide which one you want to keep.

2. Remove the resource from state. Use the terraform state rm command to remove all instances (both deposed and active) of the resource from Terraform's state tracking. This command does not destroy the actual infrastructure.
   Note: This command will remove both deposed and non-deposed instances of the resource from the state.

   $ terraform state rm aws_lb_target_group.main

3. Import the desired resource. Use the terraform import command to bring the existing, desired infrastructure resource back under Terraform's management.

   $ terraform import aws_lb_target_group.main <TARGET_GROUP_ARN>

4. Clean up unwanted infrastructure. Manually delete the unwanted infrastructure resource (the one that corresponds to the old deposed object) through your cloud provider's console or CLI. Alternatively, you can import it into a temporary Terraform resource configuration and then destroy it using Terraform.

Additional Information

• For a detailed guide on importing resources into a remote state, refer to How to Import Resources into a Remote State Managed by HCP Terraform.