Glossary — Speak the Language

The builder may think in blueprints and site registers, but in interviews people use Terraform's real vocabulary. This page has everything you need to talk about Terraform confidently: a quick-reference table, interview-ready answers, and a Classic Interview Q&A section.

Quick Reference

Term	Builder meaning	Plain meaning
Terraform	The builder who reads blueprints and directs contractors	HashiCorp's tool for provisioning infrastructure as code
HCL	The blueprint notation	The HashiCorp Configuration Language that .tf files are written in
Configuration	The full blueprint set	All your .tf files describing the desired state
Block	One section of the blueprint	A labeled { ... } group, e.g. resource, provider, module
Argument	One line of instruction	A key = value setting inside a block
Provider	A contractor company (AWS, Azure, GCP)	A plugin that talks to a specific cloud or service
Resource	A room Terraform builds and manages	An infrastructure object Terraform creates and tracks (e.g. aws_s3_bucket)
Data source	Reading an existing site's measurements	A read-only lookup of existing infrastructure
Variable	An adjustable blueprint dimension	A configurable input to a configuration or module
Local	The builder's shorthand phrase	A named computed value reused within a config
Output	The delivered keys and addresses	A value exposed after apply, e.g. an ARN or IP
Module	A reusable master blueprint	A self-contained folder of .tf files you can call and reuse
Registry	The public blueprint library	The shared repository of published modules/providers
init	The first contractor meeting	Downloads providers and sets up the working directory
fmt	Neatening the blueprint	Reformats files to standard style
validate	Proofreading the blueprint	Checks syntax and consistency without touching the cloud
plan	Showing the blueprint before building	Displays exactly what would change; changes nothing
apply	Building the villa	Creates/updates/deletes resources to match the config
destroy	Demolishing the villa	Removes all resources the configuration created
refresh	Re-measuring the site	Updates state to match reality without changing infrastructure
show	Inspecting a built villa	Displays state and outputs
output	Reading the delivered keys	Prints the declared outputs
console	Trying a measurement interactively	Interactive shell for evaluating expressions
tfvars	A sheet of preset dimensions	A .tfvars file of variable values for an environment
Lock file	The pinned contractor versions	terraform.lock.hcl — exact provider versions for reproducibility
State	The site register	The JSON file mapping config → real infrastructure
tfstate	The register itself	The terraform.tfstate file storing state
Backend	The central archive office	Where state is stored (local, S3, Terraform Cloud)
State lock	One contractor on site at a time	Prevents concurrent runs from writing the same state
Drift	Reality drifting from the register	Live infra differing from state
Import	Recording an already-built villa	Brings existing infrastructure into state/managed by Terraform
Workspace	A different city for the same blueprint	Separate state for the same configuration (dev/staging/prod)
Sensitive	Sealed instructions	A value kept out of logs and output (still stored in state)
count	"Three rooms"	Meta-argument repeating a resource N times
for_each	"One room per name in this list"	Meta-argument repeating once per item in a map/set

Interview-Ready Answers

These are written the way you'd actually say them in an interview — a definition, when to use it, and the gotcha interviewers listen for.

The Blueprint & Language

Terraform Terraform is HashiCorp's infrastructure-as-code tool. Instead of clicking through a cloud console, you describe the desired infrastructure in HCL, and Terraform figures out the difference between your blueprint and reality, then makes reality match. Its two superpowers are that everything is code (reviewable, versionable) and that it can plan changes with zero side effects before applying them.

HCL HCL — HashiCorp Configuration Language — is the language Terraform configuration is written in. It's designed to be human-readable while still being exact: a series of blocks and key = value arguments. It's not a general programming language, but it has expressions, functions, and conditionals for enough logic to build infrastructure.

Provider A provider is a plugin that connects Terraform to a specific platform — AWS, Azure, GCP, GitHub, Kubernetes. Each resource you declare belongs to a provider, and the provider knows how to create, read, update, and delete that resource on the real platform. You declare which providers and versions your config needs in required_providers.

Resource A resource is a block that says "create and manage this object." For example, aws_s3_bucket is a resource Terraform will create, track in state, and update or delete on later applies. Each resource has a type (aws_s3_bucket) and a name (archive), giving an address like aws_s3_bucket.archive.

Data source A data source is a read-only lookup. Instead of managing something, it fetches information about infrastructure that already exists — like the latest AMI ID or the current account ID. You reference it with data. (data.aws_ami.ubuntu.id). The rule: if Terraform created it, it's a resource; if Terraform merely reads it, it's a data source.

Variable A variable is a configurable input to a configuration or module. Declaring variable "env" {} lets you change behavior without editing files — via default, terraform.tfvars, the -var flag, or a TF_VAR_ environment variable. If a value differs between environments, it belongs in a variable.

Local A local is a named value computed once inside a configuration and reused — like locals { common_tags = { ... } }. Locals reduce repetition and make configs readable. Unlike variables, they're never set from outside; they're always derived from what's already in the configuration.

Module A module is a reusable package of Terraform configuration — a folder with its own main.tf, variables.tf, and outputs.tf. You call it with module "name" { source = "..." }, passing inputs and reading outputs. Modules are how teams share blueprints instead of copy-pasting resources, and they're versionable from the Terraform Registry.

Output An output exposes a value from a configuration after apply — an ARN, an IP address, a bucket name. Declared with output "name" { value = ... }, printed at the end of apply, and read anytime with terraform output. Outputs are also how a child module hands results back to its caller.

The Commands & Lifecycle

init terraform init is the first command you run in any configuration. It downloads the declared providers, sets up the backend, and creates terraform.lock.hcl. Run it once at the start, and again whenever you change providers or the backend.

fmt terraform fmt reformats your .tf files to Terraform's standard style — indentation, spacing, alignment. It never changes logic. Running it before every commit keeps diffs clean and reviews pleasant.

validate terraform validate checks the configuration for syntax and internal consistency without contacting the cloud. It's the cheap, fast proofread you run before plan — and it runs in CI on every commit.

plan terraform plan compares your configuration against state and prints exactly what would be created, changed, or destroyed — without changing anything. It's the most important command because it turns "let's hope this works" into a reviewable diff. In teams, the plan is the artifact people approve before anyone runs apply.

apply terraform apply executes the plan and makes reality match the configuration — creating, updating, or deleting resources. By default it re-plans and asks for confirmation. With -auto-approve it skips the prompt, which is how CI applies on merge.

destroy terraform destroy removes every resource the configuration created — the inverse of apply. It's used to clean up temporary environments so nothing is left running (or costing money). One gotcha: it removes resources in the right dependency order, but it only removes what's in the configuration — orphaned resources (removed from state) are left behind.

refresh terraform apply -refresh-only updates state to match reality without changing any infrastructure. You use it after drift — someone changed something outside Terraform — so the register is accurate again before you plan.

tfvars A .tfvars file holds variable values for a specific environment: terraform apply -var-file="prod.tfvars". It's the "settings sheet" you hand with a blueprint — same config, different dimensions per environment.

Lock file terraform.lock.hcl is generated by init and pins the exact provider versions and checksums your configuration uses. Committing it guarantees everyone — and every CI run — uses identical providers, so builds are reproducible.

The Register (State)

State State is the JSON file (terraform.tfstate) that maps every resource in your configuration to its real-world object. Terraform needs it to know whether a resource already exists, what its current settings are, and what to change. It also holds sensitive values. The golden rules: never hand-edit it, never commit it to Git, and share it via a remote backend on teams.

Backend A backend is where state is stored. The default is a local terraform.tfstate file. For teams, you use a remote backend — typically S3 with a DynamoDB lock table — so everyone shares one register and concurrent runs are locked. Terraform Cloud is a hosted backend with more features built in.

State lock State locking prevents two Terraform runs from writing the same state at the same time — the "one contractor on site" rule. Before planning or applying against a remote backend, Terraform acquires a lock; while locked, other runs wait or error. A stuck lock (crashed process) is released with terraform force-unlock.

Drift Drift is when live infrastructure no longer matches state — someone changed or deleted a resource outside Terraform. Symptoms: a plan showing changes you didn't intend. The fix is terraform apply -refresh-only to sync state with reality, then plan to see the true diff against the blueprint.

Import terraform import <address> <id> brings infrastructure that was created outside Terraform into state, so Terraform can start managing it. After importing, the next plan shows the difference between your configuration and the real resource. It's the safe alternative to state rm — which untracks a resource but leaves it orphaned in the cloud.

Environments & Teams

Workspace A workspace is a separate instance of state for the same configuration — the same blueprint built in a different city. You switch with terraform workspace select dev. It's a lightweight way to get dev/staging/prod from one config. The caveat to mention: workspaces isolate state, not code, so some teams prefer one backend per environment for stronger isolation.

Sensitive The sensitive = true flag on a variable or output keeps its value out of logs, plan output, and terraform output. It's how you mark secrets like database passwords. The gotcha interviewers like: sensitive values are still stored in plaintext in state, which is why state must never go into Git.

count / for_each count and for_each are meta-arguments that create multiple instances of a resource or module. count repeats N times and addresses instances by index ([0], [1]). for_each repeats once per item in a map or set, addressing by key (["dev"]). Prefer for_each when items have meaningful names — it makes state readable and instances easy to reference.

Classic Interview Q&A

1 · What's the difference between terraform plan and terraform apply? plan shows exactly what will be created, changed, or destroyed, based on the difference between my configuration and the current state — and it changes nothing. apply then executes that plan, making reality match the configuration. My habit is: always plan first, review the output — especially anything listed as "will destroy" — and only then apply.

2 · What is the state file, and why does it matter? State (terraform.tfstate) is Terraform's map of configuration to real infrastructure. It's how Terraform knows a resource already exists and what its real attributes are — without it, every apply would try to re-create everything and fail. It also stores sensitive values. That's exactly why state should never be committed to Git and should live in a remote backend with locking on a team.

3 · Backend vs workspace — what's the difference? A backend is where state is stored and locked (local file, S3, Terraform Cloud). A workspace is which state instance you're using within that storage — separate registers for the same configuration. Roughly: backends are about storage and team sharing; workspaces are about environment isolation (dev/staging/prod).

4 · How do you handle secrets in Terraform? I mark variables and outputs sensitive so values don't leak into logs or plan output, and I never hard-code secrets in .tf files or commit them. Values come from environment variables, a secret store, or references to existing resources. The critical caveat: secrets are still stored in plaintext in state, so state must go to a protected remote backend and never into version control.

5 · What is drift, and how do you deal with it? Drift is when live infrastructure changes outside Terraform — someone edits a resource in the console, so reality no longer matches state. I first run terraform apply -refresh-only to sync state with reality, then terraform plan to see the true difference between the blueprint and reality. Then I decide: re-apply to restore the blueprint, or update the configuration to reflect the intended change.

6 · Resource, data source, and module — what's the difference? A resource is an object Terraform creates and manages. A data source is a read-only lookup of existing infrastructure. A module is a packaged, reusable group of resources, variables, and outputs — a building block I can call from many configurations. Resources are the atoms, data sources are the readers, and modules are the reusable assemblies.

7 · How do you bring existing infrastructure under Terraform's control? With terraform import <address> <id>. I write a resource block that matches what exists, then import the real object's ID into state. After that, terraform plan shows the difference between my configuration and reality, and from then on Terraform manages it. Importing is the safe path — using state rm would just orphan the resource.

8 · When do you use count versus for_each? count when I want a fixed number of identical instances, addressed by index. for_each when I'm iterating over a named set — a map of environments or regions — because instances are addressed by meaningful keys, which keeps state readable and lets me reference specific instances cleanly. For anything with names, for_each is my default.

Remember

Understand the why — why state exists, why plan comes before apply, why modules are reused — and the words will follow. Then practice everything in the Exercises and the Capstone, and keep the Problem Desk nearby.