• Introduction
• Step-by-Step Guide
• Code Example
• Additional Notes
• Summary
• Conclusion
• References

In Terraform, resources marked as "deposed" can sometimes cause confusion. This typically happens when you use the create_before_destroy lifecycle setting during resource updates. This setting instructs Terraform to create a new resource before destroying the existing one, leading to a temporary state where the old resource is marked as "deposed".

"Deposed" resources in Terraform arise when using create_before_destroy during updates. This means Terraform creates a new resource before destroying the old one.

resource "aws_lb_target_group" "main" {
 lifecycle {
   create_before_destroy = true
 }
 # ... other configurations
}

During the next update, Terraform creates a new resource and marks the old one as "deposed".

# aws_lb_target_group.main (deposed object f48a8468) will be destroyed

Terraform automatically destroys deposed resources in the next apply cycle. However, issues can occur if the deposed resource is still in use.

To address this, ensure no dependencies rely on the deposed resource before applying changes. You can manually remove a deposed resource from the state file using terraform state rm.

terraform state rm <resource_type>.<resource_name>

For example, to remove a deposed aws_lb_target_group named main:

terraform state rm aws_lb_target_group.main

Remember that manually editing the state file can lead to inconsistencies. Always back up your state file before making any changes.

This code example demonstrates the concept of "deposed" resources in Terraform using an AWS Load Balancer Target Group. It shows how changing a resource's attributes with create_before_destroy can lead to a deposed resource and how to handle it. The example explains that while Terraform manages the creation and replacement of resources, it's crucial to manually remove the deposed resource from the state file after ensuring no dependencies rely on it. It emphasizes the importance of state backups and exploring alternative deployment strategies to mitigate potential issues associated with deposed resources.

This example demonstrates how a "deposed" resource can occur and how to handle it.

Scenario: We have an AWS Load Balancer Target Group that needs its port changed. We'll use create_before_destroy to avoid downtime.

1. Initial Setup:

# main.tf
resource "aws_lb_target_group" "main" {
  name     = "my-target-group"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

 lifecycle {
   create_before_destroy = true
 }
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

2. Apply the initial configuration:

terraform apply

This creates the target group with port 80.

3. Update the Target Group Port:

Now, let's change the target group port to 443:

# main.tf
resource "aws_lb_target_group" "main" {
  name     = "my-target-group"
  port     = 443 # Updated port
  protocol = "HTTPS"
  vpc_id   = aws_vpc.main.id

 lifecycle {
   create_before_destroy = true
 }
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

4. Apply the changes:

terraform apply

Terraform will:

• Create a new target group with port 443.
• Mark the old target group (port 80) as "deposed".

You'll see a message like this:

# aws_lb_target_group.main (deposed object f48a8468) will be destroyed

5. Potential Issue:

If any other resource still relies on the deposed target group (port 80), it might break.

6. Manual Removal (if necessary):

Important: Before proceeding, ensure no dependencies rely on the deposed target group.

You can manually remove the deposed target group from the state file:

terraform state rm aws_lb_target_group.main

7. Final Apply:

Run terraform apply again to finalize the changes and remove the deposed resource from the plan.

Important Notes:

• Dependencies: Always ensure no active dependencies rely on the deposed resource before removing it.
• State Backup: Back up your Terraform state file before manually editing it.
• Alternatives: Consider using other methods like blue-green deployments to avoid potential issues with deposed resources.

This example demonstrates how "deposed" resources can occur and how to handle them carefully. Remember to prioritize understanding dependencies and backing up your state file to avoid unexpected issues.

• Understanding the Cause: The create_before_destroy lifecycle setting is essential for scenarios where you need zero downtime or minimal disruption during updates. However, it's this setting that directly leads to the "deposed" state for the old resource version.

• Temporary State: It's crucial to remember that "deposed" is a temporary state. Terraform doesn't leave the old resource hanging indefinitely. By default, it will destroy the deposed resource in the next apply cycle after the new resource is successfully created and (presumably) in use.

• Manual Intervention: While Terraform aims to handle deposed resources automatically, manual intervention is sometimes necessary. This is particularly true if:

  • Dependencies Exist: Other parts of your infrastructure might still rely on the deposed resource, leading to errors if it's destroyed prematurely.
  • State Corruption: In rare cases, state file corruption might prevent Terraform from correctly managing the deposed resource.

• State Manipulation Risks: Directly editing the Terraform state file (terraform.tfstate) is generally discouraged unless absolutely necessary. Incorrect modifications can lead to inconsistencies between your infrastructure and Terraform's understanding of it. Always back up your state file before making any manual changes.

• Alternatives to create_before_destroy: While powerful, create_before_destroy isn't always the only solution. Consider these alternatives:

  • Blue-Green Deployments: Create a parallel environment ("green") with the updated resource. Once verified, switch traffic from the old environment ("blue") to the new one.
  • Rolling Updates: Gradually update instances of a resource (e.g., in an autoscaling group) to minimize disruption.

• Debugging and Troubleshooting: When encountering issues related to deposed resources:

  • Examine Terraform Plan: Carefully review the terraform plan output to understand which resources are marked as deposed and why.
  • Check Dependencies: Identify any resources that might depend on the deposed resource.
  • Inspect State File (with caution): If necessary, inspect the state file to verify the status of the deposed resource.

By understanding the reasons behind "deposed" resources, the potential risks involved, and the available mitigation strategies, you can use Terraform's powerful lifecycle management features more effectively and confidently.

Example:

Using create_before_destroy with an aws_lb_target_group resource can result in a deposed resource during updates. Terraform will mark the old resource as deposed and schedule it for destruction. Ensure no other resources depend on the deposed resource before applying further changes or manually remove it from the state file using terraform state rm aws_lb_target_group.main.

In conclusion, "deposed" resources in Terraform, while potentially confusing, are a consequence of using the create_before_destroy lifecycle setting for zero-downtime updates. Understanding that this is a temporary state and that Terraform typically handles the destruction automatically is crucial. However, it's essential to be aware of potential dependency issues and the need for manual intervention using terraform state rm in specific situations. Always prioritize backing up your state file before any modifications and consider alternative deployment strategies like blue-green deployments to minimize risks associated with deposed resources. By understanding these concepts and best practices, you can leverage Terraform's powerful lifecycle management capabilities effectively and confidently.

• How to handle issues due to create_before_destroy and "deposed ... | Introduction While a rare scenario, something like the following can appear in the Terraform plan output:

• resource "aws_lb...

• How to use state rm on a deposed resource - Terraform - HashiCorp ... | I got into a weird situation where I need to remove a deposed resource from the state file - I don’t want terraform to destroy it. I don’t know how to address it for a terraform state rm command. It seems I have to manually edit the state file? How I got into this situation is the subject of another post I should make…
• Please document "(deposed)" · Issue #10753 · hashicorp/terraform ... | After updating to 0.8.0, I ran terraform plan against some existing infrastructure to see if the new version wanted to make any changes. I saw surprised to see a bunch of "deposed" resources: - mod...
• Dealing with resources stuck in "deposed" state. | I can see the deposed resources in the terraform.tfstate.backup file. Presumably I could edit that and do a "state push" to make terraform forget the ...
• Terraform Glossary | Terraform | HashiCorp Developer | Terraform will destroy the deposed resource on the next apply. This only can ... Terraform's aws provider can manage S3 resources. Terraform Enterprise ...
• How are people managing ECS deployments with Terraform? : r ... | Posted by u/Theguest217 - 11 votes and 16 comments
• aws_db_parameter_group | Resources | hashicorp/aws | Terraform ... | This configuration will prevent destruction of the deposed parameter group while still in use by the database during upgrade. resource "aws_db_parameter_group" ...
• Terraform and Spotify – Part 2 (how I got George Michael to shut up) | This is a follow-up to my first post on how leveraging Terraform with Spotify. I’m sure you have someone in your family or in your group of friends with terrible musical taste. I know I certa…
• Terraform from 0 to Hero — 12. Depends_On and LifeCycle Block ... | Understanding how to use depends_on and the lifecycle block can help you better manage complex infrastructure dependencies and handle…