Search for a command to run...
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.
No comments yet. Be the first to comment.
This series contains my journey where I learn Terraform from scratch and share my progress every single day. My goal is to stay consistent, learn at a steady and honest pace, and hopefully complete all 30 days.
#30daysofawsterraform Introduction I’ve clicked buttons in the AWS console before. A lot of them. Sometimes things worked, sometimes they didn’t, and most of the time I couldn’t confidently explain why something was set up the way it was. That’s one ...
Docker Isn’t the Problem. The Assumption Is.
Deployed a Stateless Django Docker App on AWS with Terraform for Fault Tolerance and Autoscaling
Debugging Isn’t the Problem. The Assumption Is.
I Didn’t Understand Cloud Costs Until Resources Kept Running A few months ago, I signed up for an AWS account. The promise of the cloud felt almost magical — servers I could spin up in minutes, no har
Aditya Raj Singh
17 posts
#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.
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.
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 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 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.
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.
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.
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.
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.