Day 9 of #30DaysOfTerraform — Understanding Terraform Lifecycle and Safe Changes
#30daysofawsterraform
By the time I reached Day 9, Terraform had already started changing the way I think about infrastructure. Day 8 was a big moment — meta-arguments like count and for_each showed me how Terraform can generate infrastructure dynamically instead of forcing me to copy and paste blocks over and over again. It felt powerful, almost like programming infrastructure instead of just describing it.
But Day 9 slowed everything down.
It wasn’t about creating more resources or scaling faster. It was about understanding what really happens when infrastructure changes — and why Terraform sometimes behaves in ways that feel surprising if you’re not paying attention.
When a Small Change Is Not a Small Change
Up until this point, I had been making changes fairly casually. Modify a variable, tweak a resource, run terraform plan, apply, and move on. Most changes felt safe because Terraform handled them smoothly.
Then I hit a moment where a minor-looking update caused Terraform to plan a destroy and recreate action. Nothing was technically wrong, but it forced me to stop and think. If this were a production environment, that single change could have meant downtime or data loss.
That’s when it really clicked for me: Terraform doesn’t think in terms of “small” or “big” changes. It thinks in terms of state transitions. If a resource cannot be updated in place, Terraform replaces it. And it will do that confidently, unless you tell it otherwise.
How Terraform lifecycle rules protect resources, control replacement order, and manage change safely over time.
Discovering the lifecycle Block
Day 9 introduced the lifecycle block, and at first it looked deceptively simple. A few extra lines inside a resource definition didn’t seem like a big deal. But the more I experimented, the more I realized how much control this block gives you over Terraform’s behavior.
The first rule I explored was prevent_destroy. Adding it felt almost like putting a lock on a resource. Terraform didn’t stop managing it, but it refused to delete it without explicit intervention. The moment Terraform failed a plan because destruction was blocked, I understood its value.
A basic example:
resource "aws_s3_bucket" "example" {
bucket = "my-app-bucket"
lifecycle {
prevent_destroy = true
}
}
Adding this immediately changed Terraform’s behavior. When I tried an operation that would delete the bucket, Terraform failed the plan instead of proceeding.
That failure wasn’t an error. It was Terraform protecting me from myself.
Thinking About What Should Never Be Deleted
Once I saw prevent_destroy in action, my mindset shifted. I started thinking less about how to build resources and more about which ones should never disappear automatically.
S3 buckets with data. Core networking components. Anything that holds state or traffic. These aren’t resources you want disappearing because of a refactor or an accidental variable change.
Terraform gives you power, but Day 9 made it clear that responsibility comes with it. Guardrails aren’t optional — they’re part of good infrastructure design.
Learning How Terraform Replaces Resources
Another important realization came from create_before_destroy. Before this, I hadn’t paid much attention to the order in which Terraform replaced resources. I assumed updates were mostly in-place.
Seeing Terraform destroy first and then create made me uncomfortable — and that discomfort was useful. It forced me to think about availability and continuity.
The create_before_destroy rule flips that order:
lifecycle {
create_before_destroy = true
}
Terraform now ensured the new resource existed before removing the old one.
Creates the new resource
Switches dependencies
Destroys the old one
This pattern is essential for high-availability setups and rolling replacements.
Using create_before_destroy changed the sequence completely. This wasn’t just a configuration tweak; it was a way of designing for reliability instead of hoping for it.
Accepting That Not All Drift Is a Problem
One of the quieter lessons of Day 9 came from ignore_changes. I noticed Terraform repeatedly trying to “fix” things that weren’t actually broken — tags modified manually, attributes adjusted by AWS itself.
At first, I thought Terraform was being strict. Later, I realized it was being honest. Terraform doesn’t know which changes matter unless you tell it.
That’s where ignore_changes helps:
lifecycle {
ignore_changes = [tags]
}
Using ignore_changes felt like acknowledging reality: not all infrastructure is perfectly controlled, and not all differences require correction. This was an important step toward using Terraform pragmatically instead of dogmatically.
How Day 9 Connected Everything Before It
Looking back, Day 9 made sense only because of the days before it.
Day 6 taught me to structure infrastructure using modules. Day 7 showed how environments should be isolated using workspaces. Day 8 explained how Terraform creates and orders resources dynamically. Day 9 tied all of that together by answering a harder question: what happens when those resources change over time?
Terraform wasn’t just building infrastructure anymore. It was managing its lifecycle.
What I Actually Learned
Day 9 didn’t teach me new commands as much as it taught me caution. It taught me to slow down and read terraform plan carefully. It taught me that Terraform will do exactly what you ask — even if that means deleting something important.
Lifecycle rules aren’t shortcuts or hacks. They are deliberate tools to make change safer, clearer, and more intentional.
This was the day Terraform stopped feeling like a convenience tool and started feeling like something that deserves respect.
Takeaway
Day 9 was about learning to control change instead of reacting to it. Terraform gives you the power to create, destroy, and replace infrastructure, but lifecycle rules help you decide when and how those actions should happen.
At this point in the journey, Terraform feels less like a script that builds infrastructure and more like a system that helps manage it responsibly over time.
