🔗 Repo: github.com/Push/terraform-aws-labs/day05

🎯 Goal: Replace hardcoded values with reusable, environment-aware configs — no more copy-paste errors!

🧠 Why Variables? The Real Pain Point

Imagine this in a real team:

# ❌ Disaster waiting to happen
tags = { Environment = "dev" }   # S3
tags = { Environment = "stg" }   # VPC ← typo!
tags = { Environment = "dev" }   # EC2

→ Your “dev” environment has a staging VPC → failed deployments, broken pipelines, and 3 AM pages.

✅ Variables fix this by letting you define once, reuse everywhere, change in one place.

📦 The 3 Variable Types (By Purpose)

Type Analogy Scope When to Use
variable (Input) Function parameters Configurable input env, region, instance_type
locals Local variables (let x = …) Computed, internal-only bucket_name = "${var.app}-${var.env}-logs"
output Function return values Exported results vpc_id, bucket_arn, alb_dns

💡 Golden Rule:

✏️ Hands-On: From Hardcoded → Parameterized

Let’s refactor a multi-resource config (S3 + VPC + EC2) using all 3 variable types.

📁 File Structure (Clean & Organized)

day05/
├── main.tf          # Resources
├── variables.tf     # Input variables (env, region)
├── locals.tf        # Computed values (names, tags)
├── outputs.tf       # Results to expose
├── terraform.tfvars # Default values (dev)
└── dev.tfvars       # Dev overrides

1️⃣ variables.tf — Input Variables (User-Provided)

# 🔹 variables.tf
variable "env" {
  description = "Deployment environment"
  type        = string
  default     = "dev"
  validation {
    condition     = contains(["dev", "staging", "prod"], var.env)
    error_message = "env must be 'dev', 'staging', or 'prod'."
  }
}

variable "region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "app" {
  description = "Application name"
  type        = string
  default     = "tech-tutorials-push"
}