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 reads them 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 mistake.

When a data source is read

Terraform normally reads a data source during plan, so its values are known in the plan and can be used by resources. The read is deferred to apply when it cannot be done safely at plan time: when one of its arguments is a value that is only known after apply (for example the ID of a VPC this same run will create), or when the data source depends on a managed resource that has changes pending in the plan (directly or through depends_on). In that case the plan shows the data source as "will be read during apply" and every attribute that flows from it shows (known after apply). The result of each read is saved in state, but it is only a cached copy — the next plan reads the data source again.

Deleting a resource block from configuration tells Terraform the object should no longer exist, so the next plan destroys it. Deleting a data block only removes its cached result from state; nothing real changes, because Terraform never managed that object.

A lifecycle { prevent_destroy = true } setting does not help here: it lives inside the resource block, so it disappears along with the block you deleted and no longer blocks the destroy. To keep the real object but stop Terraform managing it, use one of these instead:

• A removed block (Terraform 1.7 and later), which replaces the resource block and is reviewed in a normal plan:

removed {
  from = aws_instance.legacy

  lifecycle {
    destroy = false
  }
}

• terraform state rm aws_instance.legacy, the older imperative way, which edits state directly with no plan. Remove the resource block too, or the next plan will try to create the object again.

Either way, the infrastructure keeps running and simply leaves Terraform state. With destroy = true, a removed block instead destroys the object, the same as deleting the resource block.

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
  default  = "dev"
  nullable = false
}

The arguments to know: type constrains what values are accepted (and converts compatible ones, see the complex-types section); default makes the variable optional; description documents it; sensitive = true redacts the value from plan and apply output; nullable controls whether null is an accepted value; and validation blocks reject bad values with your own error message (custom conditions are covered in the expressions and dependencies lesson).

Required variables and missing values

A variable with no default is required. If nothing supplies a value, Terraform prompts for it in an interactive terminal. When prompting is impossible — -input=false is set, or Terraform runs without a terminal, as in most CI pipelines — the run fails with a "No value for required variable" error instead of guessing.

nullable and explicit null

nullable defaults to true, which means a caller (for example a module block) may pass null explicitly, and that null overrides the default — the variable really is null inside the module. With nullable = false, Terraform treats an explicit null as "not set": the variable falls back to its default, or, if it has no default, a value is required. Use nullable = false when module code should never have to handle null.

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

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 command-line options are the strongest.

-var and -var-file share one precedence level. Terraform applies them in the order they appear on the command line, so if both set the same variable, whichever comes last wins:

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

Here, if ci.tfvars also sets instance_type, its value wins because it comes after the -var. Swap the two options and m5.large wins.

Which flag takes what

• -var="name=value" sets one variable directly.
• -var-file="path/to/file.tfvars" takes a file path, not a name=value pair. terraform.tfvars and *.auto.tfvars files load automatically; any other file (like prod.tfvars) is only used when passed with -var-file.
• -backend-config is a terraform init option that supplies settings for the state backend. It cannot set input variables.

An output block exposes a value from a configuration. 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
}

Sensitive outputs

If an output's value is derived from a sensitive value, the plan errors until you declare sensitive = true on the output. Terraform never marks the output sensitive for you, and the fix is not to remove sensitive from the variable — that would expose the secret everywhere else it is used. Sensitivity only controls display, and it depends on how you look:

The real value is always in the state file, so anyone who can read state or run those commands can see it.

Module outputs and dependencies

A reference to module.network.vpc_id depends only on the resources that the vpc_id output itself reads, not on everything in the module. If you need to wait for the whole module (including resources no output exposes), add depends_on = [module.network]. A module called with for_each is a map of instances, so you read its outputs per key: module.vpc["staging"].id. Child-module outputs never appear in terraform output on their own; the root module must re-export them with its own output block.

output "staging_vpc_id" {
  value = module.vpc["staging"].id
}

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)
    owner         = optional(string)
  }))
}

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

optional() attributes and their defaults

optional() lets callers omit an object attribute. optional(number, 20) substitutes 20 when the attribute is omitted or set to null. optional(string) with no default makes the omitted attribute null, so your code must handle null.

any, and why list(any) is not a tuple

any is a placeholder: Terraform infers a concrete type from the value. In list(any) or map(any) it still infers one shared element type, because every element of a collection has the same type. Given ["a", 1, true], Terraform converts all elements to a common type (here, strings: "a", "1", "true"); if no common type exists, the value is rejected. It never keeps a different type per position. When each position genuinely needs its own type, use a tuple.

Automatic type conversion

When a value does not match a type constraint exactly, Terraform converts it if it safely can, and rejects it otherwise:

• A string converts to a number or bool only if it holds a valid representation ("5" to 5, "true" to true); "five" is an error. Numbers and bools always convert to strings.
• A bool never converts to a number, and a number never converts to a bool.
• A list or tuple converts to a set (duplicates are dropped, order is lost) and a set converts to a list.
• A map or object converts to an object type if it has every required attribute; attributes the object type does not declare are discarded.

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.