Day 1 of 30 Days of AWS Terraform: Understanding the Basics Before Writing Code
#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 of the reasons I decided to start the #30DaysOfAWSTerraform challenge.
Day 1 wasn’t about deploying servers or writing complex code. It was about slowing down and understanding what Infrastructure as Code really means, and why tools like Terraform exist in the first place. This post is a reflection of what clicked for me on Day 1, and what still feels a little unclear.
What Is Terraform?
Terraform is a tool that helps create and manage cloud infrastructure using code instead of manual steps in the cloud console.
Instead of repeatedly clicking through AWS to create servers, networks, or databases, we write configuration files that describe the infrastructure we want. Terraform then reads this code and takes care of creating or updating resources for us.
This approach reduces manual effort and makes infrastructure easier to manage, especially as systems grow.
Infrastructure as Code (IaC)
This way of managing infrastructure is known as Infrastructure as Code (IaC).
IaC means treating infrastructure the same way we treat application code:
It can be stored in version control
It can be reused
It can be recreated whenever needed
If something breaks or needs to be rebuilt, the same code can be used again instead of setting everything up manually from scratch. This makes infrastructure more consistent and reliable.
Cloud-Agnostic Nature of Terraform
One interesting thing about Terraform is that it is cloud-agnostic.
This means Terraform itself is not limited to AWS. It can also work with Azure, GCP, and many other platforms. Terraform does this using providers.
A provider tells Terraform which cloud platform it should communicate with. For example, the AWS provider allows Terraform to interact with AWS services. Providers act as a bridge between Terraform and the cloud.
How Terraform Thinks and Works
Terraform follows a declarative approach. Instead of telling Terraform how to build infrastructure step by step, we describe the final state we want.
We define what resources should exist, and Terraform figures out how to reach that state.
Terraform also maintains a state file, which keeps track of the resources it manages. This state helps Terraform understand what already exists and what needs to change. The internal working of the state file is still a bit confusing to me, but I expect it will become clearer as I move forward in this challenge.
Terraform Workflow (The Core Commands)
Every Terraform project follows a basic workflow:
terraform init
This command initializes the project. It downloads required provider plugins and prepares the directory for Terraform to work.
terraform plan
This command shows what Terraform will do before making any real changes. Think of it as a dry run or preview.
terraform apply
This command actually creates or updates infrastructure based on the configuration files.
Even though Day 1 does not involve creating real infrastructure, understanding this workflow is essential because it is used in every Terraform project.
provider "aws"
{region = "us-east-1"}
This small piece of code tells Terraform:
Use AWS as the cloud provider
Deploy resources in the specified region
At this stage, the goal is not to write complex code but to understand how Terraform configurations are structured.
Understanding the Terraform State File
Terraform maintains a state file, which keeps track of the resources it manages. This file helps Terraform understand:
What already exists
What needs to change
What needs to be created or destroyed
One thing that is still slightly confusing is how Terraform internally compares the state file with real infrastructure. This is something I expect to understand better as the challenge progresses.
At this stage, I don’t fully understand how Terraform compares the state file with real infrastructure, and that’s okay. I’m treating this as something that will make sense once I start breaking and fixing things in later days.
How Terraform Fits Together
How Terraform works with AWS
This diagram shows how Terraform uses providers to communicate with AWS and manage infrastructure using code.
Key Learnings from Day 1
Terraform allows infrastructure to be managed using code
Infrastructure as Code improves consistency and repeatability
Providers connect Terraform with cloud platforms
The
*init → plan → apply*workflow is fundamentalDay 1 is about understanding concepts, not deploying resources
Conclusion
Day 1 was less about doing and more about thinking. No infrastructure was created, but the foundation was set.
If you’re also starting with Terraform or thinking about Infrastructure as Code, I’d genuinely recommend spending time on these basics before rushing ahead. I’m sharing this journey publicly to stay consistent, learn from others, and hopefully connect with people who are on a similar path.
Thanks to Piyush Sachdeva for creating this challenge and pushing the community toward hands-on, structured learning.
If you’re following the challenge too, I’d love to hear how Day 1 felt for you.
