Terraform Expressions, Functions, Dependencies, and Sensitive Data

Expressions are how values are computed anywhere an argument accepts one. The simplest expressions are literals and references — var.environment, aws_subnet.app.id, data.aws_ami.ubuntu.id, local.common_tags, module.network.vpc_id, each.value, count.index. On top of those, Terraform supports arithmetic, comparison, and logical operators, plus a ternary conditional expression:

instance_type = var.environment == "prod" ? "m5.large" : "t3.micro"

The syntax is exactly condition ? true_val : false_val, and both result values must be convertible to a common type. Conditionals are the standard way to vary sizing, counts, or feature flags per environment without duplicating blocks.

String templates interpolate expressions into strings with ${...} and support directives with %{...}:

name    = "web-${var.environment}-${count.index}"
message = "%{ if var.environment == "prod" }Handle with care%{ else }Sandbox%{ endif }"

Interpolation-only strings like "${var.name}" are legal but redundant — write var.name directly. The exam expects you to read all of these forms fluently and predict what they evaluate to.

A for expression builds a new collection by transforming another. Square brackets produce a list, curly braces with => produce a map, and an optional if clause filters:

locals {
  upper_zones  = [for z in var.zones : upper(z)]
  public_ids   = [for s in aws_subnet.all : s.id if s.map_public_ip_on_launch]
  name_by_env  = {for e in var.environments : e => "app-${e}"}
}

When iterating a map, bind both sides: {for k, v in var.tags : k => lower(v)}.

A splat expression is shorthand for the most common for expression — extracting one attribute from every element of a list:

output "instance_ids" {
  value = aws_instance.web[*].id
}

aws_instance.web[*].id is equivalent to [for o in aws_instance.web : o.id]. Splat works on lists and sets — including resources created with count, which form a list. Resources created with for_each form a map, so splat does not apply directly; use values(aws_instance.web)[*].id or a for expression instead. That count-list versus for_each-map distinction is a favorite exam discriminator.

Terraform ships a large library of built-in functions, and — a fact tested directly — you cannot define your own functions in Terraform configuration. (Providers may publish extra functions with a provider:: prefix, but the language itself has no user-defined functions.) The exam expects you to recognize what the common built-ins return:

• lookup(map, key, default) — a map value, or the default when the key is absent: lookup(var.amis, var.region, "ami-default")
• element(list, index) — the element at that index, wrapping around when the index exceeds the list length: element(["a", "b", "c"], 4) returns "b"
• length(value) — the number of elements in a list, map, or set, or characters in a string
• join(separator, list) — one string from a list: join(",", var.zones)
• cidrsubnet(prefix, newbits, netnum) — a subnet CIDR carved from a larger block: cidrsubnet("10.0.0.0/16", 8, 2) returns "10.0.2.0/24"
• file(path) — the raw contents of a file as a string
• templatefile(path, vars) — a file rendered as a string template with the given variables, the standard way to build cloud-init user data

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  user_data     = templatefile("${path.module}/init.tftpl", {
    app_port = var.app_port
  })
}

You can experiment with any function interactively in terraform console, which is also how the tutorials suggest you study them.

The count and for_each meta-arguments turn one resource block into several instances — and a resource can use one or the other, never both.

resource "aws_instance" "worker" {
  count         = var.environment == "prod" ? 3 : 1
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  tags          = { Name = "worker-${count.index}" }
}

resource "aws_instance" "service" {
  for_each      = {
    api   = "t3.small"
    batch = "t3.large"
  }
  ami           = data.aws_ami.ubuntu.id
  instance_type = each.value
  tags          = { Name = each.key }
}

The reindexing row is the practical reason to prefer for_each for collections of distinct objects: deleting element 0 of a three-instance count shifts instances 1 and 2 to new addresses, and Terraform plans to destroy and recreate them. With for_each, keys are stable. Also remember that for_each keys must be known at plan time — you cannot key instances on an attribute that is only known after apply.

Meta-arguments repeat whole resources; a dynamic block repeats a nested block inside one resource, driven by a collection. The classic case is security group rules:

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

resource "aws_security_group" "web" {
  name = "web-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.cidrs
    }
  }
}

The label on the dynamic block names the nested block to generate, its for_each supplies the collection, and inside content the iterator carries the block's own name — ingress.value here — unless you override it with an iterator argument.

Use dynamic blocks sparingly: they make configuration harder to read, and HashiCorp's guidance is to prefer literal nested blocks unless the repetition genuinely needs to be data-driven.

Terraform orders operations from a dependency graph, and there are exactly two ways a dependency gets into that graph. An implicit dependency is created automatically whenever one resource's expression references another — subnet_id = aws_subnet.app.id means the subnet is created first. This is the preferred mechanism: it is self-maintaining and impossible to forget.

An explicit dependency uses the depends_on meta-argument for relationships Terraform cannot see in any expression — a hidden, behavioral dependency:

resource "aws_iam_role_policy" "app" {
  role   = aws_iam_role.app.name
  policy = data.aws_iam_policy_document.s3.json
}

resource "aws_instance" "app" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  iam_instance_profile = aws_iam_instance_profile.app.name

  depends_on = [aws_iam_role_policy.app]
}

The instance references the instance profile, but nothing in its arguments mentions the role policy — yet the application on the instance will fail at boot if the policy is not attached first. depends_on accepts a list of resource or module references and forces the ordering.

For the exam: implicit dependencies come from references and are preferred; depends_on is a last resort for dependencies invisible to Terraform, and overusing it creates ordering constraints that slow plans and hide the real relationships.

Custom conditions let a configuration check its own assumptions and fail with a clear message instead of a confusing provider error. There are three placements to know.

Variable validation guards inputs at the earliest possible moment:

variable "instance_type" {
  type = string

  validation {
    condition     = can(regex("^t3\\.", var.instance_type))
    error_message = "Only t3-family instance types are allowed."
  }
}

Preconditions and postconditions live inside a resource, data source, or output lifecycle block. A precondition checks an assumption before Terraform acts; a postcondition checks a guarantee afterwards and may reference the resource's own result via self:

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = var.instance_type

  lifecycle {
    precondition {
      condition     = data.aws_ami.ubuntu.architecture == "x86_64"
      error_message = "The selected AMI must be x86_64."
    }
    postcondition {
      condition     = self.public_dns != ""
      error_message = "The instance must have a public DNS name."
    }
  }
}

Every condition pairs a boolean condition with an error_message. Failed conditions halt the run with your message. Terraform also has standalone check blocks whose failures are only warnings — useful for ongoing health assertions — but the enforcing tools are validation, precondition, and postcondition.

The ground truth of Terraform secrets handling is this: the state file stores all values in plaintext, including variables and outputs marked sensitive. The sensitive = true flag redacts values from plan and apply output so they do not leak into logs, but it encrypts nothing. Consequently the real controls are operational: never hardcode credentials in .tf files, never commit .tfvars files containing secrets (gitignore them), pass secrets via TF_VAR_ environment variables or a secrets manager, and store state in an access-controlled, encrypted remote backend.

HashiCorp's recommended secrets manager is Vault, consumed through the vault provider. Terraform authenticates to Vault and reads secrets with data sources, so credentials live centrally with audit logging and rotation instead of scattered across configurations:

provider "vault" {}

data "vault_kv_secret_v2" "db" {
  mount = "secret"
  name  = "database"
}

resource "aws_db_instance" "app" {
  engine   = "postgres"
  username = "app"
  password = data.vault_kv_secret_v2.db.data["password"]
}

Two caveats the exam rewards you for knowing. First, any secret Terraform reads — even from Vault — is still written to the plan and state in plaintext, so Vault reduces sprawl and enables short-lived dynamic credentials, but state protection remains essential. Second, modern Terraform (1.10+) adds ephemeral values, and 1.11+ adds provider write-only arguments, which let certain secrets be used during a run without ever being persisted to plan or state — the direction of travel for secret-safe configuration in Terraform 1.12.