Day 10 of #30DaysOfTerraform: Writing Smarter Terraform with Expressions
Diving into Cloud and DevOps like a kid who learned cycling yesterday and signed up for a race today. I break things, read error logs like bedtime stories, and slowly figure out how not to repeat the same mistakes. If you enjoy honest tech journeys with a bit of humor, you’ll fit right in.
#30daysofawsterraform
By the time I reached Day 10, Terraform had already stopped feeling like a tool for “just creating resources.”
Days 8 and 9 changed that mindset completely. Meta-arguments taught me how Terraform scales resource creation, and lifecycle rules taught me to respect change.
Day 10 took things one step further.
This day wasn’t about adding more resources at all — it was about writing better Terraform.
Cleaner. Smarter. More intentional.
From Static Configs to Decision-Making Infrastructure
Up to now, most of my Terraform configurations were static. Variables helped, but the structure was still fairly rigid. Day 10 introduced the idea that Terraform configs can make decisions.
Conditional expressions were the first thing that clicked.
The syntax itself is simple:
condition ? true_value : false_value
But the impact is big. Suddenly, the same Terraform code can behave differently based on environment, region, or intent — without copying files or branching logic everywhere.
I started thinking less in terms of “dev code” and “prod code” and more in terms of one codebase that adapts.
Conditional Expressions — Small Logic, Big Clarity
What stood out to me wasn’t just that conditionals exist, but where they make sense.
Using them for things like instance sizes, monitoring flags, or resource counts felt natural. Instead of maintaining multiple versions of the same resource, Terraform now expresses intent clearly: if this condition is true, do this — otherwise, do that.
At the same time, Day 10 made something else clear:
Not everything should be conditional.
When logic starts getting complex, it stops being readable. That’s when locals or higher-level structure is a better choice. This was an important balance to learn — just because Terraform allows logic doesn’t mean you should overuse it.
Dynamic Blocks — The First Time Duplication Really Disappeared
Dynamic blocks were probably the most satisfying part of Day 10.
Before this, repeating nested blocks felt unavoidable. Security group rules, IAM policies, route definitions — they all required copy-paste with minor changes. It worked, but it felt clumsy.
Dynamic blocks changed that.
Instead of repeating blocks, Terraform now generates them from data. A list or map defines the structure, and Terraform handles the repetition. Adding or removing rules becomes a data change, not a structural rewrite.
What I liked most here was how naturally this fits with variables. Infrastructure starts to look data-driven instead of hardcoded.
At the same time, I learned to be careful. Dynamic blocks are powerful, but they can hurt readability if overused. Day 10 reinforced an idea that keeps coming up: clarity matters more than cleverness.
Splat Expressions — Seeing Terraform Think in Lists
Splat expressions were quieter, but they completed the picture.
resource_list[*].attribute
This single line replaces loops, indexing, and manual extraction. Once I understood it, I started noticing how often Terraform deals with lists of things — instances, subnets, IDs, ARNs.
Splat expressions feel like Terraform saying:
“I already know this is a collection — let me handle it.”
This made outputs cleaner, resource linking simpler, and overall configurations easier to read. It’s one of those features that doesn’t look impressive at first, but once you use it, you don’t want to go back.
Where I Got Stuck (and What I Learned)
The main friction on Day 10 wasn’t syntax — it was judgment.
When should I use a conditional vs a variable file?
When does a dynamic block improve clarity, and when does it hide intent?
Is this expression making the code better, or just more complex?
I found myself rewriting sections just to make them more readable. That process taught me that Terraform isn’t just about making things work — it’s about making them understandable to future you.
How Day 10 Connects to the Bigger Picture
Looking back, Day 10 ties together everything learned so far:
Variables (Day 5) made configs flexible
Modules (Day 6) made them structured
Workspaces (Day 7) made them environment-aware
Meta-arguments (Day 8) made them scalable
Lifecycle rules (Day 9) made them safe
Expressions (Day 10) made them intelligent
This was the day Terraform started to feel less like configuration and more like design.
What I Really Took Away from Day 10
Day 10 wasn’t about memorizing syntax. It was about learning how to express intent clearly in Terraform.
Conditional expressions taught me how to handle differences without duplication.
Dynamic blocks showed me how to let data drive structure.
Splat expressions helped me think in collections instead of individual resources.
Most importantly, I learned that good Terraform isn’t just correct — it’s readable, intentional, and maintainable.
Takeaway
Day 10 reinforced a simple idea:
Terraform is powerful, but power needs discipline.
Expressions make Terraform flexible and expressive, but only when used thoughtfully. The goal isn’t to write clever configurations — it’s to write infrastructure that makes sense six months later.
This day felt less like learning a new feature and more like learning how to write Terraform properly.
