What if you could update your cloud resources without ever causing downtime or losing data?
Why Create_before_destroy lifecycle rule in Terraform? - Purpose & Use Cases
Imagine you are updating a critical cloud resource like a database or a server manually. You delete the old one first, then create the new one. During this gap, your application has no resource to use, causing downtime and unhappy users.
Manually deleting before creating is risky and slow. It causes service interruptions and potential data loss. You must carefully time each step, and any mistake can break your system. This manual juggling wastes time and causes stress.
The create_before_destroy lifecycle rule in Terraform solves this by automatically creating the new resource before deleting the old one. This ensures continuous availability and smooth updates without downtime or data loss.
terraform apply: destroy old_resource; terraform apply: create new_resource
lifecycle {
create_before_destroy = true
}This rule enables seamless resource updates with zero downtime, keeping your services reliable and users happy.
When updating a load balancer or a virtual machine, using create_before_destroy ensures the new instance is ready before the old one is removed, so your website stays online without interruption.
Manual resource replacement causes downtime and risk.
create_before_destroy automates safe updates by creating first, then deleting.
This keeps services running smoothly during changes.
Practice
create_before_destroy lifecycle rule in Terraform?Solution
Step 1: Understand lifecycle behavior
Thecreate_before_destroyrule tells Terraform to create the replacement resource first.Step 2: Avoid downtime during updates
This ensures the old resource is only destroyed after the new one is ready, preventing service interruption.Final Answer:
To create a new resource before deleting the old one to avoid downtime -> Option AQuick Check:
create_before_destroy = avoid downtime [OK]
- Thinking it deletes old resource before creating new
- Confusing with prevent_destroy lifecycle rule
- Assuming it backs up resources automatically
create_before_destroy in a Terraform resource?Solution
Step 1: Review Terraform lifecycle block syntax
The lifecycle block uses curly braces with key-value pairs using = and booleans without quotes.Step 2: Identify correct boolean assignment
Boolean values are unquoted, sotrueis correct, not "true" as string.Final Answer:
lifecycle { create_before_destroy = true } -> Option AQuick Check:
Correct syntax uses = and unquoted booleans [OK]
- Using colon : instead of equals =
- Putting boolean true in quotes
- Assigning lifecycle block with = instead of braces
resource "aws_instance" "example" {
ami = "ami-123456"
instance_type = "t2.micro"
lifecycle {
create_before_destroy = true
}
}Solution
Step 1: Check lifecycle rule effect
Thecreate_before_destroy = truemeans Terraform creates the new resource first.Step 2: Understand resource replacement
Since the instance requires replacement, Terraform creates new instance before destroying old one.Final Answer:
Terraform will create the new instance before destroying the old one -> Option DQuick Check:
create_before_destroy = new before old [OK]
- Assuming old resource is destroyed first
- Thinking update happens in place always
- Believing create_before_destroy is unsupported
create_before_destroy = true to a resource but Terraform still destroys the old resource before creating the new one. What is the likely cause?Solution
Step 1: Understand resource support
Not all Terraform resources supportcreate_before_destroy. If unsupported, Terraform ignores it.Step 2: Check lifecycle behavior fallback
If unsupported, Terraform defaults to destroying old resource before creating new one.Final Answer:
The resource does not support create_before_destroy lifecycle rule -> Option BQuick Check:
Unsupported resource ignores create_before_destroy [OK]
- Assuming terraform init fixes lifecycle issues
- Using quotes around boolean true
- Believing lifecycle rules always override resource behavior
create_before_destroy?Solution
Step 1: Use create_before_destroy for zero downtime
Settingcreate_before_destroy = trueensures new resource is ready before old is removed.Step 2: Confirm resource supports lifecycle rule
Check documentation to ensure the database resource supports this lifecycle feature to avoid unexpected downtime.Final Answer:
Addlifecycle { create_before_destroy = true }and verify the resource supports it -> Option CQuick Check:
Use create_before_destroy with support check [OK]
- Using prevent_destroy which blocks updates
- Relying on default lifecycle risking downtime
- Manually deleting resources causing downtime
Ready to prove it?
Pass the test and this pattern moves unknown
