Variables and Outputs: Making Infrastructure Reusable

My journey from copy-paste chaos to parameterized infrastructure elegance

---

Table of Contents

1. Introduction: The Copy-Paste Nightmare

2. What Are Variables?

3. Variable Types and Declarations

4. Input Variables Deep Dive

5. Variable Files (.tfvars)

6. Variable Validation

7. Sensitive Variables

8. Variable Precedence

9. Understanding Outputs

10. Output Values Deep Dive

11. Sensitive Outputs

12. Real-World Example: Multi-Environment Blog Platform

13. Common Mistakes and How to Avoid Them

14. Best Practices for Variables and Outputs

15. What I Learned About Parameterization

16. Next Steps

---

Introduction: The Copy-Paste Nightmare

It was month two of using Terraform, and I had a problem. I needed to create identical infrastructure for three environments: development, staging, and production. My solution? Copy-paste the entire configuration three times.

dev/
  main.tf       # 500 lines
staging/
  main.tf       # 500 lines (copy-pasted, changed a few values)
production/
  main.tf       # 500 lines (copy-pasted, changed a few values)

Then disaster struck. I found a bug in the database configuration. Now I had to fix it three times. I missed one. Production broke. Post-mortem meeting. Awkward conversations.

That's when I learned about variables. Instead of copy-paste, I could write the configuration once and parameterize the differences:

# One configuration, three environments
variable "environment" {
  default = "dev"
}

resource "local_file" "config" {
  filename = "${var.environment}-config.txt"
  content  = "Environment: ${var.environment}"
}

Variables transformed my Terraform code from brittle copy-paste hell to elegant, reusable infrastructure as code. This article is about making your infrastructure parameterized, flexible, and maintainable.

---

What Are Variables?

Variables in Terraform are named values that allow you to parameterize your configurations. They make your code:

• Reusable - Same code, different values

• Maintainable - Change once, apply everywhere

• Flexible - Easy to customize per environment

• Testable - Override values for testing

• Documented - Self-documenting configuration options

Variables vs Hardcoding

Without Variables (Bad):

resource "local_file" "dev_config" {
  filename = "dev-app.conf"
  content  = "port=3000\nenv=development\nworkers=2"
}

resource "local_file" "staging_config" {
  filename = "staging-app.conf"
  content  = "port=3000\nenv=staging\nworkers=4"
}

resource "local_file" "prod_config" {
  filename = "production-app.conf"
  content  = "port=8080\nenv=production\nworkers=8"
}

With Variables (Good):

variable "environment" {
  type = string
}

variable "port" {
  type = number
}

variable "workers" {
  type = number
}

resource "local_file" "config" {
  filename = "${var.environment}-app.conf"
  content  = "port=${var.port}\nenv=${var.environment}\nworkers=${var.workers}"
}

Variable Flow

---

Variable Types and Declarations

Terraform supports several variable types, each with specific use cases.

Basic Variable Types

1. String

variable "environment" {
  type        = string
  description = "Deployment environment (dev, staging, prod)"
  default     = "dev"
}

# Usage
resource "local_file" "config" {
  content = "Environment: ${var.environment}"
}

2. Number

variable "port" {
  type        = number
  description = "Application port number"
  default     = 3000
}

# Usage
resource "local_file" "config" {
  content = "Port: ${var.port}"
}

3. Boolean

variable "enable_monitoring" {
  type        = bool
  description = "Enable monitoring features"
  default     = false
}

# Usage
resource "local_file" "config" {
  content = "Monitoring: ${var.enable_monitoring ? "enabled" : "disabled"}"
}

Collection Types

4. List

variable "availability_zones" {
  type        = list(string)
  description = "List of availability zones"
  default     = ["us-east-1a", "us-east-1b", "us-east-1c"]
}

# Usage
resource "local_file" "zones" {
  filename = "zones.txt"
  content  = join("\n", var.availability_zones)
}

5. Set (like list but no duplicates, no order)

variable "allowed_ips" {
  type        = set(string)
  description = "Set of allowed IP addresses"
  default     = ["10.0.0.1", "10.0.0.2"]
}

6. Map

variable "tags" {
  type        = map(string)
  description = "Resource tags"
  default = {
    Environment = "dev"
    Project     = "blog"
    ManagedBy   = "terraform"
  }
}

# Usage
resource "local_file" "tags" {
  filename = "tags.json"
  content  = jsonencode(var.tags)
}

7. Object (structured type)

variable "database_config" {
  type = object({
    host     = string
    port     = number
    name     = string
    username = string
    ssl      = bool
  })
  
  description = "Database configuration object"
  
  default = {
    host     = "localhost"
    port     = 5432
    name     = "blog_db"
    username = "blog_user"
    ssl      = true
  }
}

# Usage
resource "local_file" "db_config" {
  filename = "database.conf"
  content = <<-EOT
    host=${var.database_config.host}
    port=${var.database_config.port}
    database=${var.database_config.name}
    user=${var.database_config.username}
    ssl=${var.database_config.ssl}
  EOT
}

8. Tuple (list with specific types)

variable "server_config" {
  type        = tuple([string, number, bool])
  description = "Server config: [hostname, port, ssl_enabled]"
  default     = ["app.example.com", 443, true]
}

Complex Nested Types

variable "application" {
  type = object({
    name    = string
    version = string
    servers = list(object({
      hostname = string
      port     = number
      region   = string
    }))
    features = map(bool)
  })
  
  default = {
    name    = "blog-platform"
    version = "1.0.0"
    servers = [
      {
        hostname = "app1.example.com"
        port     = 8080
        region   = "us-east-1"
      },
      {
        hostname = "app2.example.com"
        port     = 8080
        region   = "us-west-2"
      }
    ]
    features = {
      caching    = true
      monitoring = true
      logging    = false
    }
  }
}

---

Input Variables Deep Dive

Let's explore all aspects of input variable declarations.

Complete Variable Declaration

variable "example" {
  # Type constraint
  type = string
  
  # Human-readable description
  description = "Example variable for demonstration"
  
  # Default value (optional)
  default = "default-value"
  
  # Validation rules
  validation {
    condition     = length(var.example) > 3
    error_message = "Example must be more than 3 characters."
  }
  
  # Mark as sensitive (hides in logs)
  sensitive = false
  
  # Deprecated: use validation instead
  # nullable = true
}

Variable Without Default (Required)

variable "api_key" {
  type        = string
  description = "API key for external service"
  sensitive   = true
  # No default = user must provide value
}

# When you run terraform apply:
# var.api_key
#   API key for external service
#   Enter a value:

Using Variables

# Reference with var prefix
resource "local_file" "config" {
  content = "API Key: ${var.api_key}"
}

# In expressions
locals {
  uppercase_env = upper(var.environment)
  port_range    = "${var.port_min}-${var.port_max}"
}

# In conditionals
resource "local_file" "optional" {
  count    = var.enable_feature ? 1 : 0
  filename = "optional.txt"
  content  = "Feature enabled"
}

---

Variable Files (.tfvars)

Variable files let you organize variable values separately from configuration.

File Structure

variables.tf - Declarations

variable "environment" {
  type        = string
  description = "Deployment environment"
}

variable "app_port" {
  type        = number
  description = "Application port"
}

variable "enable_ssl" {
  type        = bool
  description = "Enable SSL"
}

variable "tags" {
  type        = map(string)
  description = "Resource tags"
}

terraform.tfvars - Default values (auto-loaded)

environment = "development"
app_port    = 3000
enable_ssl  = false

tags = {
  Environment = "dev"
  Team        = "platform"
}

production.tfvars - Production values

environment = "production"
app_port    = 8080
enable_ssl  = true

tags = {
  Environment = "prod"
  Team        = "platform"
  CostCenter  = "engineering"
}

Using Variable Files

# Auto-loaded files (no flag needed):
# - terraform.tfvars
# - terraform.tfvars.json
# - *.auto.tfvars
# - *.auto.tfvars.json

# Specify custom file
terraform apply -var-file="production.tfvars"

# Multiple files (merged in order)
terraform apply \
  -var-file="base.tfvars" \
  -var-file="production.tfvars"

Variable File Formats

HCL format (.tfvars):

environment = "staging"
replicas    = 3

database = {
  host = "db.staging.internal"
  port = 5432
}

allowed_ips = [
  "10.0.1.0/24",
  "10.0.2.0/24"
]

JSON format (.tfvars.json):

{
  "environment": "staging",
  "replicas": 3,
  "database": {
    "host": "db.staging.internal",
    "port": 5432
  },
  "allowed_ips": [
    "10.0.1.0/24",
    "10.0.2.0/24"
  ]
}

---

Variable Validation

Validation rules ensure variables meet requirements before Terraform runs.

Basic Validation

variable "environment" {
  type        = string
  description = "Deployment environment"
  
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

Invalid value:

terraform apply -var="environment=test"

Error:

Error: Invalid value for variable

  on variables.tf line 1:
   1: variable "environment" {

Environment must be dev, staging, or prod.

Complex Validation Examples

String Length:

variable "username" {
  type = string
  
  validation {
    condition     = length(var.username) >= 3 && length(var.username) <= 20
    error_message = "Username must be between 3 and 20 characters."
  }
}

Regex Pattern:

variable "email" {
  type = string
  
  validation {
    condition     = can(regex("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$", var.email))
    error_message = "Must be a valid email address."
  }
}

Number Range:

variable "port" {
  type = number
  
  validation {
    condition     = var.port >= 1024 && var.port <= 65535
    error_message = "Port must be between 1024 and 65535."
  }
}

List Validation:

variable "availability_zones" {
  type = list(string)
  
  validation {
    condition     = length(var.availability_zones) >= 2
    error_message = "Must specify at least 2 availability zones for high availability."
  }
}

Object Validation:

variable "database" {
  type = object({
    host     = string
    port     = number
    username = string
  })
  
  validation {
    condition     = var.database.port >= 1024 && var.database.port <= 65535
    error_message = "Database port must be between 1024 and 65535."
  }
  
  validation {
    condition     = length(var.database.username) >= 3
    error_message = "Database username must be at least 3 characters."
  }
}

Multiple Conditions:

variable "instance_type" {
  type = string
  
  validation {
    condition = (
      can(regex("^[a-z][0-9]\\.[a-z]+$", var.instance_type)) &&
      !can(regex("\\.micro$", var.instance_type)) &&
      var.instance_type != "t2.nano"
    )
    error_message = "Instance type must be valid format and not micro/nano tiers."
  }
}

---

Sensitive Variables

Sensitive variables hide their values in logs and output.

Marking Variables as Sensitive

variable "database_password" {
  type        = string
  description = "Database password"
  sensitive   = true
  # No default for sensitive values
}

variable "api_token" {
  type      = string
  sensitive = true
}

Sensitive Variable Behavior

Without sensitive = true:

terraform apply -var="password=secret123"

Output:

  # local_file.config will be created
  + resource "local_file" "config" {
      + content = "password=secret123"  # EXPOSED!
    }

With sensitive = true:

variable "password" {
  type      = string
  sensitive = true
}

Output:

  # local_file.config will be created
  + resource "local_file" "config" {
      + content = (sensitive value)  # HIDDEN!
    }

Working with Sensitive Values

# Generate random password
resource "random_password" "db" {
  length  = 16
  special = true
}

# Use in configuration (automatically sensitive)
resource "local_file" "db_config" {
  filename        = "database.conf"
  content         = "password=${random_password.db.result}"
  file_permission = "0600"
}

# Mark output as sensitive
output "db_password" {
  value     = random_password.db.result
  sensitive = true
}

Providing Sensitive Variables

Environment variables (recommended):

export TF_VAR_database_password="secret123"
terraform apply

Variable file (encrypted):

# Use encrypted file with tools like sops or Vault
terraform apply -var-file="secrets.tfvars.encrypted"

Never do this:

# DON'T: Passwords visible in shell history
terraform apply -var="password=secret123"

# DON'T: Passwords in unencrypted files committed to Git
echo 'password = "secret123"' > terraform.tfvars
git add terraform.tfvars  # BAD!

---

Variable Precedence

When multiple sources provide values for the same variable, Terraform uses a precedence order.

Precedence Order (Lowest to Highest)

Precedence Example

variables.tf:

variable "environment" {
  type    = string
  default = "dev"  # Precedence: 1 (lowest)
}

terraform.tfvars:

environment = "staging"  # Precedence: 2

production.auto.tfvars:

environment = "production"  # Precedence: 3

Command line:

# Precedence: 4
terraform apply -var-file="custom.tfvars"  # environment = "custom"

# Precedence: 5
export TF_VAR_environment="from-env"
terraform apply

# Precedence: 6 (highest)
terraform apply -var="environment=from-cli"
# Result: environment = "from-cli"

---

Understanding Outputs

Outputs expose values from your Terraform configuration. They're useful for:

• Displaying important information after deployment

• Passing values between Terraform modules

• Integrating with other tools and systems

• Documenting infrastructure attributes

Output Syntax

output "name" {
  value       = expression
  description = "Human-readable description"
  sensitive   = false
  depends_on  = []
}

Basic Output Examples

# Simple value
output "environment" {
  value       = var.environment
  description = "Deployment environment"
}

# Resource attribute
output "config_file_path" {
  value       = local_file.config.filename
  description = "Path to configuration file"
}

# Computed value
output "full_url" {
  value       = "https://${var.domain}:${var.port}"
  description = "Complete application URL"
}

# List output
output "all_files" {
  value       = local_file.configs[*].filename
  description = "All generated configuration files"
}

# Map output
output "tags" {
  value       = var.tags
  description = "Resource tags"
}

---

Output Values Deep Dive

Viewing Outputs

During apply:

terraform apply

Output:

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

config_file_path = "./config/app.yaml"
environment = "production"
full_url = "https://blog.example.com:8080"

After apply:

# Show all outputs
terraform output

# Show specific output
terraform output environment

# JSON format
terraform output -json

# For scripting
CONFIG_PATH=$(terraform output -raw config_file_path)

Complex Output Examples

Object output:

output "database_connection" {
  value = {
    host     = var.database_config.host
    port     = var.database_config.port
    database = var.database_config.name
    ssl      = var.database_config.ssl
  }
  description = "Database connection details"
}

Conditional output:

output "monitoring_url" {
  value       = var.enable_monitoring ? "https://monitoring.example.com" : "Monitoring disabled"
  description = "Monitoring dashboard URL"
}

Computed from multiple resources:

output "deployment_summary" {
  value = {
    environment   = var.environment
    deployed_at   = timestamp()
    config_files  = local_file.configs[*].filename
    total_servers = length(var.servers)
  }
  description = "Deployment summary"
}

---

Sensitive Outputs

Hide sensitive values in Terraform output.

Marking Outputs as Sensitive

resource "random_password" "db" {
  length = 16
}

output "database_password" {
  value     = random_password.db.result
  sensitive = true
  description = "Database password (sensitive)"
}

Viewing outputs:

terraform output

Output:

database_password = <sensitive>

To view sensitive output:

terraform output database_password
# Shows actual value

# Or in JSON
terraform output -json database_password

Why Use Sensitive Outputs?

Without sensitive = true:

Outputs:

admin_password = "super-secret-123"  # Visible in logs!
api_key = "abc-def-ghi-jkl"          # Visible in CI logs!

With sensitive = true:

Outputs:

admin_password = <sensitive>
api_key = <sensitive>

---

Real-World Example: Multi-Environment Blog Platform

Let's build a complete multi-environment infrastructure using variables and outputs.

Project Structure

blog-platform/
├── main.tf
├── variables.tf
├── outputs.tf
├── terraform.tfvars
├── environments/
│   ├── dev.tfvars
│   ├── staging.tfvars
│   └── production.tfvars
└── .gitignore

variables.tf

# Environment configuration
variable "environment" {
  type        = string
  description = "Deployment environment (dev, staging, production)"
  
  validation {
    condition     = contains(["dev", "staging", "production"], var.environment)
    error_message = "Environment must be dev, staging, or production."
  }
}

variable "project_name" {
  type        = string
  description = "Project name for resource naming"
  default     = "blog-platform"
  
  validation {
    condition     = can(regex("^[a-z][a-z0-9-]*$", var.project_name))
    error_message = "Project name must start with letter, contain only lowercase letters, numbers, and hyphens."
  }
}

# Application configuration
variable "app_config" {
  type = object({
    port            = number
    workers         = number
    enable_caching  = bool
    cache_ttl       = number
    log_level       = string
  })
  
  description = "Application configuration settings"
  
  validation {
    condition     = var.app_config.port >= 1024 && var.app_config.port <= 65535
    error_message = "Port must be between 1024 and 65535."
  }
  
  validation {
    condition     = contains(["debug", "info", "warn", "error"], var.app_config.log_level)
    error_message = "Log level must be debug, info, warn, or error."
  }
}

# Database configuration
variable "database" {
  type = object({
    engine          = string
    version         = string
    port            = number
    max_connections = number
    enable_ssl      = bool
  })
  
  description = "Database configuration"
  
  validation {
    condition     = contains(["postgresql", "mysql"], var.database.engine)
    error_message = "Database engine must be postgresql or mysql."
  }
}

# Feature flags
variable "features" {
  type = map(bool)
  description = "Feature flags for enabling/disabling features"
  default = {
    comments   = true
    analytics  = false
    newsletter = false
    cdn        = false
  }
}

# Tags
variable "tags" {
  type        = map(string)
  description = "Resource tags"
}

# Secrets (sensitive)
variable "secrets" {
  type = object({
    jwt_secret     = string
    admin_password = string
  })
  
  description = "Sensitive secrets"
  sensitive   = true
}

terraform.tfvars (default/shared values)

project_name = "blog-platform"

tags = {
  Project   = "BlogPlatform"
  ManagedBy = "Terraform"
  Team      = "Platform"
}

environments/dev.tfvars

environment = "dev"

app_config = {
  port           = 3000
  workers        = 2
  enable_caching = false
  cache_ttl      = 300
  log_level      = "debug"
}

database = {
  engine          = "postgresql"
  version         = "14"
  port            = 5432
  max_connections = 20
  enable_ssl      = false
}

features = {
  comments   = true
  analytics  = false
  newsletter = false
  cdn        = false
}

tags = {
  Environment = "development"
  CostCenter  = "engineering"
}

environments/staging.tfvars

environment = "staging"

app_config = {
  port           = 8080
  workers        = 4
  enable_caching = true
  cache_ttl      = 600
  log_level      = "info"
}

database = {
  engine          = "postgresql"
  version         = "14"
  port            = 5432
  max_connections = 50
  enable_ssl      = true
}

features = {
  comments   = true
  analytics  = true
  newsletter = true
  cdn        = false
}

tags = {
  Environment = "staging"
  CostCenter  = "engineering"
}

environments/production.tfvars

environment = "production"

app_config = {
  port           = 8080
  workers        = 8
  enable_caching = true
  cache_ttl      = 3600
  log_level      = "warn"
}

database = {
  engine          = "postgresql"
  version         = "14"
  port            = 5432
  max_connections = 100
  enable_ssl      = true
}

features = {
  comments   = true
  analytics  = true
  newsletter = true
  cdn        = true
}

tags = {
  Environment = "production"
  CostCenter  = "engineering"
  Compliance  = "required"
}

main.tf

terraform {
  required_version = ">= 1.0"
  
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.5"
    }
    local = {
      source  = "hashicorp/local"
      version = "~> 2.4"
    }
  }
}

# Generate deployment ID
resource "random_uuid" "deployment_id" {}

# Generate database password if not provided
resource "random_password" "db_password" {
  length  = 20
  special = true
}

# Create application configuration
resource "local_file" "app_config" {
  filename = "${path.module}/generated/${var.environment}/app.yaml"
  
  content = yamlencode({
    application = {
      name        = var.project_name
      environment = var.environment
      deployment_id = random_uuid.deployment_id.result
    }
    
    server = {
      port           = var.app_config.port
      workers        = var.app_config.workers
      log_level      = var.app_config.log_level
    }
    
    cache = {
      enabled = var.app_config.enable_caching
      ttl     = var.app_config.cache_ttl
    }
    
    database = {
      engine          = var.database.engine
      version         = var.database.version
      host            = "db.${var.environment}.internal"
      port            = var.database.port
      database        = "${var.project_name}_${var.environment}"
      max_connections = var.database.max_connections
      ssl             = var.database.enable_ssl
      password_file   = "./secrets/db_password.txt"
    }
    
    features = var.features
  })
  
  file_permission = "0644"
}

# Create database configuration
resource "local_file" "db_config" {
  filename = "${path.module}/generated/${var.environment}/database.conf"
  
  content = <<-EOT
    # Database Configuration - ${var.environment}
    # Generated by Terraform on ${timestamp()}
    
    [database]
    engine=${var.database.engine}
    version=${var.database.version}
    port=${var.database.port}
    max_connections=${var.database.max_connections}
    ssl=${var.database.enable_ssl}
    
    [connection]
    host=db.${var.environment}.internal
    database=${var.project_name}_${var.environment}
    user=${var.project_name}_user
  EOT
  
  file_permission = "0644"
}

# Create secrets file
resource "local_file" "secrets" {
  filename = "${path.module}/generated/${var.environment}/secrets/db_password.txt"
  
  content         = random_password.db_password.result
  file_permission = "0600"
}

resource "local_file" "jwt_secret" {
  filename = "${path.module}/generated/${var.environment}/secrets/jwt_secret.txt"
  
  content         = var.secrets.jwt_secret
  file_permission = "0600"
}

# Create environment documentation
resource "local_file" "readme" {
  filename = "${path.module}/generated/${var.environment}/README.md"
  
  content = <<-EOT
    # ${title(var.environment)} Environment - ${var.project_name}
    
    **Deployment ID**: ${random_uuid.deployment_id.result}  
    **Generated**: ${timestamp()}  
    **Managed By**: Terraform
    
    ## Configuration
    
    - **Application Config**: `app.yaml`
    - **Database Config**: `database.conf`
    - **Secrets Directory**: `secrets/`
    
    ## Application Settings
    
    - **Port**: ${var.app_config.port}
    - **Workers**: ${var.app_config.workers}
    - **Caching**: ${var.app_config.enable_caching ? "Enabled" : "Disabled"}
    - **Log Level**: ${var.app_config.log_level}
    
    ## Database Settings
    
    - **Engine**: ${var.database.engine} ${var.database.version}
    - **Port**: ${var.database.port}
    - **Max Connections**: ${var.database.max_connections}
    - **SSL**: ${var.database.enable_ssl ? "Enabled" : "Disabled"}
    
    ## Features
    
    ${join("\n", [for feature, enabled in var.features : "- **${title(feature)}**: ${enabled ? "✓ Enabled" : "✗ Disabled"}"])}
    
    ## Tags
    
    ${join("\n", [for key, value in var.tags : "- **${key}**: ${value}"])}
    
    ## Security
    
    - Database password: `secrets/db_password.txt`
    - JWT secret: `secrets/jwt_secret.txt`
    - Admin password: Set via `TF_VAR_secrets` environment variable
    
    ⚠️  **Never commit secrets to version control!**
  EOT
  
  file_permission = "0644"
}

outputs.tf

output "deployment_id" {
  value       = random_uuid.deployment_id.result
  description = "Unique deployment identifier"
}

output "environment" {
  value       = var.environment
  description = "Deployment environment"
}

output "configuration_files" {
  value = {
    app_config = local_file.app_config.filename
    db_config  = local_file.db_config.filename
    readme     = local_file.readme.filename
  }
  description = "Generated configuration files"
}

output "application_settings" {
  value = {
    port           = var.app_config.port
    workers        = var.app_config.workers
    caching        = var.app_config.enable_caching
    log_level      = var.app_config.log_level
  }
  description = "Application configuration summary"
}

output "database_settings" {
  value = {
    engine          = var.database.engine
    version         = var.database.version
    port            = var.database.port
    max_connections = var.database.max_connections
    ssl_enabled     = var.database.enable_ssl
  }
  description = "Database configuration summary"
}

output "enabled_features" {
  value       = [for feature, enabled in var.features : feature if enabled]
  description = "List of enabled features"
}

output "secrets_location" {
  value       = "${path.module}/generated/${var.environment}/secrets/"
  description = "Location of secrets directory"
  sensitive   = true
}

output "database_password" {
  value       = random_password.db_password.result
  description = "Generated database password"
  sensitive   = true
}

.gitignore

# Terraform
.terraform/
*.tfstate
*.tfstate.backup
.terraform.lock.hcl

# Secrets
**/secrets/
*.pem
*.key

# Generated files
generated/

# Variable files with secrets
secrets.tfvars

Deploying Different Environments

Development:

terraform init

# Set secrets via environment variable
export TF_VAR_secrets='{
  jwt_secret = "dev-jwt-secret-123",
  admin_password = "dev-admin-pass"
}'

terraform apply -var-file="environments/dev.tfvars"

Staging:

export TF_VAR_secrets='{
  jwt_secret = "staging-jwt-secret-xyz",
  admin_password = "staging-admin-pass"
}'

terraform apply -var-file="environments/staging.tfvars"

Production:

# Production secrets from secure vault
export TF_VAR_secrets='{
  jwt_secret = "'$(vault read -field=jwt_secret secret/blog/prod)'",
  admin_password = "'$(vault read -field=admin_password secret/blog/prod)'"
}'

terraform apply -var-file="environments/production.tfvars"

---

Common Mistakes and How to Avoid Them

Mistake #1: Hardcoding Values

Bad:

resource "local_file" "config" {
  filename = "app-config.txt"
  content  = "port=3000\nenv=development"
}

Good:

variable "port" { type = number }
variable "environment" { type = string }

resource "local_file" "config" {
  filename = "${var.environment}-config.txt"
  content  = "port=${var.port}\nenv=${var.environment}"
}

Mistake #2: Not Validating Variables

Bad:

variable "environment" {
  type = string
  # User could set to anything: "prod", "produciton", "PROD", etc.
}

Good:

variable "environment" {
  type = string
  
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Must be dev, staging, or prod."
  }
}

Mistake #3: Exposing Sensitive Values

Bad:

output "database_password" {
  value = var.db_password
  # Shows in logs!
}

Good:

output "database_password" {
  value     = var.db_password
  sensitive = true
}

Mistake #4: Committing Secrets to Git

Bad:

# terraform.tfvars
database_password = "super-secret-123"
api_key = "abc-def-ghi"

git add terraform.tfvars  # DANGER!

Good:

# Use environment variables
export TF_VAR_database_password="secret"
export TF_VAR_api_key="key"

# Or encrypted files with .gitignore
echo "*.tfvars" >> .gitignore
echo "secrets/" >> .gitignore

Mistake #5: Wrong Variable Type

Bad:

variable "port" {
  type    = string  # Port is a number!
  default = "3000"
}

# Later causes issues
resource "local_file" "config" {
  content = "port=${var.port + 80}"  # Can't add string + number
}

Good:

variable "port" {
  type    = number
  default = 3000
}

---

Best Practices for Variables and Outputs

1. Always Provide Descriptions

variable "environment" {
  type        = string
  description = "Deployment environment (dev, staging, prod)"  # Clear!
}

output "config_path" {
  value       = local_file.config.filename
  description = "Path to generated configuration file"  # Helpful!
}

2. Use Validation for Critical Variables

variable "environment" {
  type = string
  
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Must be dev, staging, or prod."
  }
}

3. Organize Variables by Purpose

variables.tf
├── # Environment
├── # Application config
├── # Database config
├── # Feature flags
└── # Secrets

4. Use Sensible Defaults

variable "log_level" {
  type    = string
  default = "info"  # Safe default
}

variable "enable_monitoring" {
  type    = bool
  default = true  # Monitoring on by default
}

5. Mark Sensitive Data

variable "api_key" {
  type      = string
  sensitive = true  # Hides in logs
}

output "password" {
  value     = random_password.db.result
  sensitive = true  # Hides in output
}

6. Use Structured Types for Related Data

# Instead of:
variable "db_host" { }
variable "db_port" { }
variable "db_name" { }

# Use:
variable "database" {
  type = object({
    host = string
    port = number
    name = string
  })
}

7. Environment-Specific Variable Files

environments/
├── dev.tfvars
├── staging.tfvars
└── production.tfvars

---

What I Learned About Parameterization

1. Variables Enable Reusability

One configuration, infinite environments. That's the power of variables.

Before variables:

• 3 copies of same code

• Bug fixes required 3 changes

• Easy to miss differences

After variables:

• 1 configuration

• 3 variable files

• Consistent infrastructure

2. Validation Catches Mistakes Early

validation {
  condition     = contains(["dev", "staging", "prod"], var.environment)
  error_message = "Must be dev, staging, or prod."
}

This simple validation has saved me from:

• Typos ("produciton")

• Inconsistencies ("PROD" vs "prod")

• Invalid values ("test", "qa", "uat" when infrastructure doesn't support them)

3. Outputs Are Documentation

Good outputs tell the story of what was created:

output "deployment_summary" {
  value = {
    environment = var.environment
    app_url     = "https://${var.domain}"
    deployed_at = timestamp()
  }
}

4. Sensitive Data Requires Care

• Mark variables as sensitive = true

• Mark outputs as sensitive = true

• Never commit secrets to Git

• Use environment variables or encrypted files

5. Types Matter

Correct types prevent bugs:

• number for ports, counts, sizes

• bool for feature flags

• list for collections

• object for structured data

---

Next Steps

Congratulations! You now understand how to make Terraform configurations flexible and reusable:

✅ Variable types and declarations ✅ Input variables and .tfvars files ✅ Variable validation ✅ Sensitive variables ✅ Outputs and sensitive outputs ✅ Multi-environment blog platform example

Practice Exercises

Exercise 1: Variable Types

# Create variables of each type:
# - string
# - number
# - bool
# - list
# - map
# - object
# Use them in resources and outputs

Exercise 2: Multi-Environment Setup

# Create 3 environment-specific .tfvars files
# Deploy each environment
# Compare the generated configurations

Exercise 3: Validation Rules

# Add validation to all your variables
# Try to break the validation with invalid values
# Observe the error messages

Coming Up Next

In Article 4: Mastering HCL - Terraform's Configuration Language, we'll dive deep into:

• HCL syntax and expressions

• Built-in functions (50+ functions!)

• Conditional expressions

• For expressions and loops

• Dynamic blocks

• Local values

• Complex configuration patterns

Variables are the first step to flexible infrastructure. HCL expressions are how you make those variables work together to create powerful, dynamic configurations.

---

This Week's Challenge: Build a multi-environment infrastructure with at least 5 variables, validation rules for each, and comprehensive outputs. Deploy to 3 different environments using .tfvars files. Document the differences in a README.

See you in Article 4! 🎯

---

"Variables turned my copy-paste nightmare into elegant, reusable infrastructure. If you're still copying code between environments, you're doing it wrong." - Me, after deleting 1,500 lines of duplicate code