Resource and data blocks

Two block types carry almost all of a Terraform configuration, and on the page they look nearly alike:

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

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

The difference is ownership. A resource block declares a managed resource, a real object Terraform creates, updates, and destroys^[1] so infrastructure matches your configuration. A data block declares a data source, a read-only lookup that fetches data from the provider without creating or modifying anything^[2]. In the example Terraform builds and owns the aws_instance, but only reads the aws_ami that someone else published.

Two labels form the address

Both blocks open with a keyword and two labels, a type and a local name. In resource "aws_instance" "web", the type aws_instance comes from the provider and fixes what the object is, while the local name web is yours to choose. Together they form the block's address, aws_instance.web, which Terraform uses to track the object in state^[1] and which must be unique within the module. The local name is only an internal handle: it does not need to be globally unique, and it never has to match an id the provider assigns on create.

The data. prefix is the read-only tell

You wire blocks together by referencing their exported attributes. A managed resource's attribute reads as aws_instance.web.id; a data source's has the same shape with a leading data. marker, data.aws_ami.ubuntu.id. That data. prefix is the single syntactic signal that a reference points at a read-only lookup rather than a managed object. Drop it and Terraform looks for a managed resource of that name instead, so the prefix, not the block's position in the file, is what tells configuration and reader alike which kind of block owns a value.

Every resource and data block accepts a fixed set of meta-arguments that Terraform interprets itself, independent of the provider. Learn them once and they behave the same on any resource type.

Meta-argument	What it does
depends_on	Forces an explicit ordering when Terraform cannot infer it from references
count	Creates a fixed number of instances, indexed from 0
for_each	Creates one instance per map entry or set member, keyed by that element
provider	Selects a non-default (aliased) provider configuration
lifecycle	Tunes create, replace, and destroy behavior (create_before_destroy, prevent_destroy, ignore_changes)

The reference lists exactly these five for a resource block^[1]; a data block accepts the same set, plus precondition and postcondition checks inside its lifecycle.

count indexes; for_each keys

count and for_each both stamp out multiple instances from one block, but they identify those instances differently, and you cannot use both in the same block^[3].

• count takes a whole number^[3] and creates that many instances. Inside the block count.index is the position starting at 0, and you address an instance by number: aws_instance.web[0].
• for_each takes a map or a set of strings^[4] and creates one instance per element. Inside the block each.key and each.value describe the current element, and you address an instance by its key: aws_instance.web["blue"].

count.index is available only under count, and each.key / each.value only under for_each; reaching for the wrong one is a common configuration error.

Why for_each survives edits that count churns

Prefer for_each when instances have their own identity. Because for_each tracks instances by key, deleting the middle entry of a three-item map removes exactly that one instance. Under count, deleting the middle of a three-item list shifts every later instance down one index, and since state is keyed by that index, Terraform plans to destroy and recreate each shifted instance^[3]. Switching an existing resource from count to for_each re-addresses every instance the same way, so pair the switch with a moved block to keep the objects instead of replacing them.

A data source's value is only as fresh as its last read, so knowing when Terraform reads it explains most data-source surprises. The rule has two branches.

Terraform reads a data source during the refresh phase^[2], the read-back step at the start of plan and apply where Terraform checks real objects against its records, when all of the data source's arguments are already known, for example a hard-coded owner id or a plain variable. The result is available during plan, so the plan can show what the lookup returned.

Terraform defers the read to the apply phase^[2] when at least one argument refers to a value it cannot predict during planning, such as an attribute of a resource being created in the same run. Until apply produces that value, the data source and everything downstream of it read as (known after apply).

Reads repeat on every run

A data source is not read once and cached forever. Terraform re-reads each data source on the refresh of every plan and apply, so it always reflects the current real-world value. A managed resource behaves differently: Terraform changes it only when your configuration or detected drift calls for a change. That is the practical run-time split between the two block types. The data source re-observes reality each run, while the resource is reconciled toward your configuration.

Reach for a provisioner only after every declarative option is exhausted. HashiCorp designs Terraform for immutable infrastructure and recommends purpose-built solutions for post-apply steps^[5], because a provisioner runs an opaque imperative command that Terraform cannot model, plan, or reconcile. When you do need one, the type you choose decides where the command runs.

Three provisioner types, two locations

• local-exec invokes an executable on the machine running Terraform^[8] after the resource is created; it needs no network connection to the resource.
• remote-exec runs commands on the remote resource itself^[6] and therefore requires a connection block giving Terraform SSH or WinRM access.
• file copies files or directories from the Terraform machine to the new resource^[9]; like remote-exec it reaches the target through a connection block. It rounds out the built-in triad, and despite the plain name it acts on the remote host, not on local disk.

Creation-time by default, destroy-time on request

Provisioners run at creation by default. Set when = destroy to run one during terraform destroy instead. Failure handling differs by phase, and the default catches people out:

• A creation-time provisioner that fails marks the resource as tainted^[5], so the next terraform apply destroys and recreates it rather than leaving a half-configured object. The default on_failure is fail, which aborts the apply; on_failure = continue instead tells Terraform to ignore the error and proceed.
• A destroy-time provisioner that fails does not taint anything: Terraform returns an error and reruns the provisioner on the next terraform apply^[5].

terraform_data: a resource to hang provisioners on

A provisioner must live inside a resource, so what do you do when no real resource fits? Use terraform_data, a built-in managed resource that follows the standard lifecycle without managing any real object^[7]. It is always available through the built-in provider terraform.io/builtin/terraform, with no required_providers entry or provider block^[7], and it is the modern replacement for the null provider's null_resource. Its optional input argument stores a value that Terraform echoes to the computed output attribute (unknown during plan, equal to input after apply), and setting triggers_replace forces the instance to be replaced when that value changes, which you can chain into another resource's lifecycle { replace_triggered_by = [...] }.

The exam rarely asks for a definition outright. It shows a snippet or a scenario and asks which block, which meta-argument, or which command fits. The recurring patterns:

• A stem shows configuration that reads an object that already exists (an AMI, a VPC, the current account) and asks how to reference it. The answer is a data block; distractors propose a resource block, which would try to create or take over the object. A data source cannot create or destroy anything.
• A stem references aws_instance.web.id on a resource that sets count and asks why the plan errors. With count the name is a list, so you must index it: aws_instance.web[0].id. The for_each counterpart uses a string key, aws_instance.web["blue"].id, never a numeric index.
• A stem sets both count and for_each on one block. That is always invalid: the two are mutually exclusive.
• A stem omits the data. prefix when referencing a data source, or asks which prefix distinguishes a data source from a managed resource. The data. prefix is the answer.
• A stem needs to run a shell command or copy a file onto a new server. The answer is a provisioner, but the correct framing is that it is a last resort: local-exec for the Terraform host, remote-exec or file for the server through a connection block. An option offering a provider resource or instance user data is often the better real-world choice the question is steering you toward.
• A stem wants to run provisioners but has no natural resource to attach them to, or mentions replacing null_resource. The answer is terraform_data, which needs no provider configured.
• A stem describes a provisioner that failed during creation and asks about the resource's state. It is tainted, so the next terraform apply destroys and recreates it; on_failure = continue is the only setting that would have let the apply proceed.