Terraform Resources, Data Sources, Variables, and Outputs

A resource block declares a piece of infrastructure that Terraform creates, updates, and destroys on your behalf. It is the most important block type in the language: everything Terraform manages in state corresponds to a resource. Each block has two labels, the resource type and a local name, and the pair must be unique within a module.

resource "aws_instance" "web" {
  ami           = "ami-0c02fb55956c7d316"
  instance_type = "t3.micro"

  tags = {
    Name = "web-server"
  }
}

The resource type's prefix tells Terraform which provider manages it: aws_instance belongs to the aws provider, google_compute_instance to google, and random_pet to random. Elsewhere in the configuration you refer to this resource by the address aws_instance.web — the word resource never appears in the reference.

Arguments inside the block configure the resource; which arguments exist is defined by the provider's schema, not by Terraform core. After an apply, the resource also exposes attributes that the provider computes, such as aws_instance.web.public_ip, which you can read even though you never set them.

A data block reads information from outside the current configuration — an object managed by another Terraform workspace, created by hand, or published by the provider itself. Data sources never create, modify, or destroy anything; Terraform refreshes them during planning and exposes the result as read-only attributes.

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"]

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

References to data sources are prefixed with data. — here data.aws_ami.ubuntu.id. Forgetting that prefix (or adding it to a managed resource) is a classic exam trap.

Referencing one resource's attribute inside another resource is how you wire infrastructure together, and it does double duty: the reference itself tells Terraform the order in which to create things. This is called an implicit dependency, and it is the preferred way to express ordering.

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "app" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.app.id
}

Because aws_subnet.app references aws_vpc.main.id, Terraform builds the VPC first, then the subnet, then the instance — with no explicit ordering configuration at all. During a destroy, the graph runs in reverse. The general reference form is <resource_type>.<name>.<attribute>, and you can drill into nested values with further dots and index brackets.

Values that a provider only knows after creation (like an instance ID) are shown as (known after apply) in the plan. Terraform still resolves the graph correctly; it simply defers the concrete value until apply time.

An input variable is declared with a variable block and referenced as var.<name>. Variables are how the same configuration serves multiple environments without editing the source.

variable "instance_type" {
  type        = string
  description = "EC2 instance type for the web tier"
  default     = "t3.micro"
}

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

variable "environment" {
  type = string

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

Key arguments to know for the exam: type constrains what values are accepted; default makes the variable optional; description documents it; sensitive = true redacts the value from plan and apply output; and one or more validation blocks reject bad values at plan time with your own error_message. Since Terraform 1.9, a validation condition may also reference other variables in the module, not just the one being validated.

A variable with no default and no supplied value causes Terraform to prompt interactively — or fail in automation — so required inputs are simply variables without defaults.

Terraform loads variable values from several sources, and later sources override earlier ones. From lowest to highest precedence:

1. Environment variables named TF_VAR_<name> (for example TF_VAR_instance_type=t3.small)
2. The terraform.tfvars file, if present
3. The terraform.tfvars.json file, if present
4. Any *.auto.tfvars or *.auto.tfvars.json files, processed in lexical order of their filenames
5. -var and -var-file options on the command line, in the order they are provided (highest precedence)

A default in the variable block sits beneath all of these — it applies only when no source supplies a value. Note the direction: the environment variable is the weakest definition source, and a -var flag on the CLI beats everything. Exam questions frequently set the same variable in two or three places and ask which value wins.

terraform apply -var="instance_type=m5.large" -var-file="prod.tfvars"

One more file-loading rule worth memorizing: terraform.tfvars and *.auto.tfvars files load automatically, but any other .tfvars file (like prod.tfvars above) is only used when passed explicitly with -var-file.

An output block exposes a value from a configuration after apply. In the root module, outputs print at the end of terraform apply and are queryable with terraform output; in a child module, outputs are the only values a parent can read, via module.<name>.<output>.

output "instance_ip" {
  description = "Public IP of the web server"
  value       = aws_instance.web.public_ip
}

output "db_connection_string" {
  value     = "postgres://app:${var.db_password}@${aws_instance.web.private_ip}/app"
  sensitive = true
}

Marking an output sensitive = true redacts it from CLI output — Terraform prints <sensitive> instead of the value. If an output's value derives from a sensitive variable, Terraform forces you to mark the output sensitive too, or the plan errors. Redaction is display-only: the real value still lives in the state file, and terraform output -raw db_connection_string or terraform output -json will reveal it to anyone with state access.

Outputs commonly feed other systems: a parent module composing child modules, a script parsing terraform output -json, or another Terraform configuration reading them through remote state.

Terraform's type system starts with three primitives — string, number, and bool — and builds two families of complex types on top of them.

Collection types hold many values of one element type:

• list(string) — ordered, indexed from zero, duplicates allowed: var.zones[0]
• set(string) — unordered, unique values, no index access (convert with tolist if you need one)
• map(string) — key/value pairs accessed as var.tags["team"]

Structural types hold a fixed shape of possibly different types:

• object({...}) — named attributes, each with its own type
• tuple([...]) — a fixed-length sequence where each position has its own type

variable "servers" {
  type = map(object({
    instance_type = string
    monitoring    = bool
    disk_gb       = optional(number, 20)
  }))
}

variable "endpoint" {
  type = tuple([string, number])
  default = ["api.example.com", 443]
}

The optional() modifier (with an optional default) lets object attributes be omitted by callers. There is also any, a placeholder that tells Terraform to infer the type — convenient, but it gives up the plan-time checking that explicit constraints provide. On the exam, expect to distinguish map from object (uniform element type vs named mixed attributes) and list from tuple (uniform vs per-position types), and to remember that sets are unordered.