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 By Day 6, Terraform starts to demand a different mindset.Up until now, writing everything in a single directory worked fine. Variables improved flexibility, remote state improved reliability, but the structure was still flat. Th...
Docker Isn’t the Problem. The Assumption Is.
#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
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 Day 5 of this journey, you’ve already stood up infrastructure, handled remote state, and built a foundation of reusable Terraform configurations. But real Infrastructure-as-Code isn’t just about what you build — it’s about how flexibly you build it.
Day 5 was all about variables — input, output, and locals — and how they give your configurations real muscle. Instead of hardcoding values everywhere, you learn to write Terraform that adapts, scales, and responds to different environments or use cases without changing the code itself. This shift — from static definitions to dynamic infrastructure — changes how you think about IaC forever.
In your early days with Terraform, you probably hardcoded simple values like CIDR blocks, bucket names, or instance sizes. That’s fine for a lab. But once you start building real environments — dev, staging, prod — hardcoding becomes a liability: it requires copy-paste, invites errors, and makes maintenance painful.
Variables let you write one configuration that can behave differently depending on context. They turn Terraform from a single-purpose script into a reusable definition of intent.
The official curriculum for Day 5 lists the key areas covered: input variables, output variables, locals, variable precedence, and variable files (*.tfvars). All of these pieces come together to make your code reusable and safe at scale.
The simplest form of variability in Terraform comes from input variables. These let you parameterize your configuration without rewriting code. A basic variable definition looks like this:
variable "region" {
description = "The AWS region to deploy into"
type = stringdefault = "us-east-1"
}
This declares a named variable with a type and a default. When you run Terraform, you can override the default using a .tfvars file or command-line flags.
For instance, a terraform.tfvars file might contain:
region = "us-west-2"
This pattern decouples values from logic, making your configs far more flexible. It also lets teammates or automation pipelines inject values without touching code.
Once resources are created, you often want to expose information from them — maybe an IP, a DNS name, or a resource ARN. Terraform’s output variables are designed precisely for that.
Here’s a typical output:
output "vpc_id" {
description = "The ID of the created VPC"
value = aws_vpc.example.id
}
By exposing outputs, you turn Terraform into not just a builder of infrastructure, but a data provider. Outputs can feed other automation, be shown to users, or be passed into remote systems in CI/CD pipelines.
When you find yourself repeating expressions or values derived from multiple variables, Terraform’s locals help you collapse that repetition into a single source of truth.
For example:
locals {
common_tags = {
Environment = var.environment
}
}
You can reference local.common_tags anywhere. This isn’t just a convenience — it reduces duplication, minimizes risk of drift, and makes refactoring safer.
Terraform evaluates variables in a well-defined order: defaults, environment variables, .tfvars files (like terraform.tfvars), and command-line flags. Understanding this precedence lets you design configurations that behave predictably in different contexts — local development, automated tests, or production pipelines.
Variable files (*.tfvars) let you maintain separate configurations for dev vs prod without changing any HCL. They’re especially useful in automation, where different environments need different inputs but share the same underlying module logic.
What made Day 5 a real shift wasn’t just learning syntax, but the intent behind variables:
They detach environment-specific settings from code
They encourage reuse and modular design
They make automation robust, predictable, and safe
With variables, your Terraform configurations stop being brittle scripts and start looking like declarative interfaces to infrastructure.
Day 5 was where Terraform truly began to feel like real Infrastructure-as-Code:
Input variables let configurations adapt without rewriting code.
Outputs and locals make data reusable and configurations reusable.
Understanding variable precedence and tfvars makes environments manageable and pipelines reliable.
Once you think in terms of inputs and outputs instead of hardcoded values, Terraform stops being a set of commands and becomes a framework for predictable, reusable, and automated infrastructure.
#Terraform #DevOps #AWS #IaC #30DaysOfTerraform #InfrastructureAsCode