Write Once, Deploy Everywhere: Mastering Terraform’s Expression Toolkit

Avatar photoByAdil

It’s Day 10 of the AWS Challenge, and today I’m exploring the features that transform Terraform from a simple declarative tool into a flexible, intelligent configuration powerhouse. If yesterday’s lifecycle meta-arguments were about surgical control, today’s expressions are about surgical precision with maximum reusability.

I’m talking about Conditional Expressions, Dynamic Blocks, and Splat (Funny thing is…. I called that word seplat and spelled it seplat in my previous blogs…) Expressions, the trio that eliminates code duplication and makes your infrastructure truly adaptable across environments.

Hey, I’m learning terraform within 30 days. Or at least I’m trying to. You too can join the challenge.

Here’s how these three expression types became game-changers in my infrastructure code.

1. Conditional Expressions: Decision-Making in Your Config

Think of conditional expressions as the if-else statements of Terraform. They let you make intelligent decisions right in your configuration without duplicating entire files.

The Syntax: 

condition ? true_value : false_value

How it works: Terraform evaluates the condition. If true, it uses the first value; if false, it uses the second. Simple, but incredibly powerful.

Real-World Example: 

resource "aws_instance" "app_server" {
  ami           = var.ami
  instance_type = var.environment == "production" ? "t3.large" : "t3.micro"

  monitoring = var.environment == "production" ? true : false

  tags = {
    Name        = "${var.environment}-app-server"
    Environment = var.environment
    CostCenter  = var.environment == "production" ? "prod-ops" : "dev-team"
  }
}

In this example, production gets beefier instances with monitoring enabled, while dev environments stay lean. One configuration, multiple environments, no code duplication.

Use Cases:

  • Selecting instance sizes based on environment
  • Enabling expensive features (like enhanced monitoring) only in production
  • Choosing different AMIs per region
  • Setting resource counts (scale production higher than dev)
  • Applying environment-specific security policies

Pro Tip: Don’t nest these too deeply. If you find yourself chaining multiple ternary operators, use locals blocks to break down the logic into readable chunks.

2. Dynamic Blocks: The Code Duplication Killer

This is where Terraform goes from good to great. Dynamic blocks let you generate multiple nested blocks from a single definition. If you’ve ever copied and pasted the same ingress rule 10 times in a security group, this is your salvation.

The Syntax: 

dynamic "block_name" {
  for_each = var.collection
  content {
    # Configuration using block_name.value
  }
}

You might be asking why not just using for_each tf meta argument? The reason is for_each works only at a resources level but dynamic blocks helps to make the arguments for resouces flexible.
How it works: The for_each argument takes a list or map and iterates over it. For each item, Terraform generates a complete block using the template in the content section.

Real-World Example: Security Group Rules

Instead of this nightmare: 

resource "aws_security_group" "app_sg" {
  name = "app-security-group"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }
  # ... and 7 more repeated blocks
}

You write this beauty: 

variable "ingress_rules" {
  type = list(object({
    port        = number
    protocol    = string
    cidr_blocks = list(string)
    description = string
  }))
  default = [
    {
      port        = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
      description = "HTTP access"
    }...
  ]
}

resource "aws_security_group" "app_sg" {
  name = "app-security-group"

  dynamic "ingress" {
    for_each = var.ingress_rules
    content {
      from_port   = ingress.value.port
      to_port     = ingress.value.port
      protocol    = ingress.value.protocol
      cidr_blocks = ingress.value.cidr_blocks
      description = ingress.value.description
    }
  }
}

Why This is Brilliant:

  • Adding a new rule? Just add it to the variable, no code changes needed.
  • Environment-specific rules? Pass different lists per environment.
  • Want to disable all external access? Pass an empty list.
  • Need to audit all open ports? Check one variable instead of scattered code.

Other Powerful Use Cases:

  • Multiple EBS volumes attached to EC2 instances
  • IAM policy statements
  • Route table routes
  • CloudWatch alarm actions
  • Any nested block that repeats with variation

Important: Dynamic blocks work for nested blocks within resources, not for creating multiple resources. For multiple resources, use count or for_each on the resource itself.

3. Splat Expressions: Data Extraction Made Elegant

Splat expressions are Terraform’s way of saying “give me this attribute from every item in this list.” The [*] operator is your friend here.

The Syntax: 

resource_list[*].attribute_name

How it works: Instead of writing a loop to extract values, you use [*] to tell Terraform “get this attribute from all elements.”

Real-World Example: 

resource "aws_instance" "web_servers" {
  count         = 3
  ami           = var.ami_id
  instance_type = "t3.micro"

  tags = {
    Name = "web-server-${count.index}"
  }
}

# Output all instance IDs in one line
output "instance_ids" {
  value = aws_instance.web_servers[*].id
}

# Output all private IPs
output "private_ips" {
  value = aws_instance.web_servers[*].private_ip
}

# Use those IPs in another resource
resource "aws_lb_target_group_attachment" "web" {
  count            = length(aws_instance.web_servers)
  target_group_arn = aws_lb_target_group.web.arn
  target_id        = aws_instance.web_servers[*].id[count.index]
}

Without splat expressions, you’d need a complex for loop or repeated code. With them, it’s one elegant line.

Common Use Cases:

  • Extracting IDs from multiple EC2 instances for use in other resources
  • Collecting all subnet IDs from a VPC data source
  • Getting security group IDs to attach to resources
  • Gathering ARNs for IAM policies
  • Building lists for outputs and dependencies

Pro Tip: Combine splat with other functions like join() for even more power: 

output "all_ips_comma_separated" {
  value = join(",", aws_instance.web_servers[*].private_ip)
}

Bringing It All Together: A Real-World Scenario

Here’s how these three expressions work together in a production-grade configuration: 

variable "environment" {
  type = string
}

variable "ingress_rules" {
  type = map(object({
    port        = number
    cidr_blocks = list(string)
  }))
}

# Conditional: Different instance types per environment
resource "aws_instace" "app" {
  count         = var.environment == "production" ? 3 : 1
  ami           = var.ami_id
  instance_type = var.environment == "production" ? "t3.large" : "t3.micro"

  vpc_security_group_ids = [aws_security_group.app.id]

  tags = {
    Name        = "${var.environment}-app-${count.index}"
    Environment = var.environment
  }
}

# Dynamic: Generate security rules from variable
resource "aws_security_group" "app" {
  name = "${var.environment}-app-sg"

  dynamic "ingress" {
    for_each = var.ingress_rules
    content {
      from_port   = ingress.value.port
      to_port     = ingress.value.port
      protocol    = "tcp"
      cidr_blocks = ingress.value.cidr_blocks
    }
  }
}

# Splat: Extract all instance IDs for output
output "instance_ids" {
  description = "IDs of all app instances"
  value       = aws_instance.app[*].id
}

# Splat: Get all private IPs for configuration
output "private_ips" {
  description = "Private IPs for load balancer config"
  value       = aws_instance.app[*].private_ip
}

My key Takeaways

Conditional Expressions give you environment-aware configurations without file duplication. One codebase, infinite environments (maybe lol).
Dynamic Blocks eliminate the pain of repetitive nested blocks. Your security groups and policies become data-driven and maintainable.
Splat Expressions make data extraction effortless. No more loops or complex logic to grab attributes from multiple resources.
Together, these expressions transform Terraform from a declarative tool into an intelligent, flexible infrastructure-as-code platform. I think they’re the difference between maintaining 5 separate environment configs and maintaining one adaptive configuration that scales with your needs, the industry might say different but let me enjoy the joy of the new knowledge while I can.
Tomorrow’s topic dives into Terraform’s built-in functions where I’ll unlock even more power for data manipulation and transformation giving me that full programming experience. See yaa!

Similar Posts