Expressions, Functions and Dependencies

What it is

Expressions compute values instead of hard-coding them. With conditionals, for expressions, dynamic blocks and built-in functions, one configuration can adapt to different inputs.

Dependencies decide the order in which Terraform acts. Most come from references between blocks; depends_on covers the rare case where no reference exists.

How it works

Conditional expressions

A conditional picks one of two values: condition ? true_value : false_value.

resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.env == "prod" ? "m5.large" : "t3.micro"
}

Both results should have the same type. A common pattern is count = var.create ? 1 : 0 to create a resource only when a flag is true.

for expressions

A for expression transforms one collection into another. Square brackets produce a list or tuple, braces produce an object or map.

locals {
  upper_names = [for n in var.names : upper(n)]
  name_to_len = { for n in var.names : n => length(n) }
  prod_only   = [for s in var.servers : s.name if s.env == "prod"]
}

The optional if clause filters elements. A for expression builds a value; it does not create resources by itself.

dynamic blocks

A dynamic block generates repeated nested blocks, such as several ingress rules, from a collection.

resource "aws_security_group" "web" {
  dynamic "ingress" {
    for_each = var.ports
    content {
      from_port   = ingress.value
      to_port     = ingress.value
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  }
}

Inside content, the iterator is named after the block label, here ingress, with .key and .value. The iterator argument renames it. Dynamic blocks generate nested blocks only, never whole resources.

Built-in functions

Terraform has only built-in functions plus functions that providers supply; you cannot write your own. Calls look like name(arg1, arg2).

Run terraform console to try expressions and functions against the current configuration and state without changing anything.

Implicit and explicit dependencies

A reference such as vpc_id = aws_vpc.main.id creates an implicit dependency. Terraform builds a dependency graph from these references and creates independent resources in parallel.

When a dependency is real but not visible in any argument, add depends_on with a list of references.

resource "aws_instance" "app" {
  ami           = var.ami_id
  instance_type = "t3.micro"
  depends_on    = [aws_iam_role_policy.app_s3]
}

Here the application needs an IAM policy at boot, but no argument refers to it. HashiCorp recommends depends_on only as a last resort, because it can make plans more conservative.

Lifecycle settings

The lifecycle block changes how Terraform replaces or protects a resource.

How the exam asks about this

• "Create a bastion host only when var.enable_bastion is true." Use count = var.enable_bastion ? 1 : 0.
• "An instance needs an S3 policy at boot but references nothing from it. How do you enforce order?" Add depends_on to the instance.
• "Generate one ingress rule per port in a list." Use a dynamic "ingress" block with for_each.