Terraform Cert Guide Chapter 11: Terraform Glossary in Plain English

Chapter 11 is the glossary chapter. In most books, glossaries sit at the back collecting dust. But honestly, if you’re studying for the Terraform certification, this is the chapter you’ll keep coming back to. Ravi Mishra collects every term that showed up throughout the book and defines them in one place.

I’m going to retell these definitions in plain language. Think of this as the cheat sheet version. Bookmark it, come back to it when you blank on what a “backend” is during your study session at 11 PM.

The Core Terraform Terms

API (Application Programming Interface)

An API is how software talks to other software. When Terraform creates an EC2 instance on AWS, it doesn’t log into the AWS console and click buttons. It sends API calls to AWS saying “hey, make this thing.” Every cloud provider exposes APIs, and Terraform uses them to create, update, and delete your infrastructure.

Terraform Cloud has its own APIs too, for managing workspaces and policies programmatically.

HCL (HashiCorp Configuration Language)

This is the language you write Terraform code in. It uses a structured syntax with specific block types like resource, variable, provider, and built-in functions. Everything is written as name-value pairs. If you’ve seen a .tf file, you’ve seen HCL.

IaC (Infrastructure as Code)

Writing your infrastructure in code files instead of clicking around in cloud consoles. You describe what you want (servers, networks, databases), store it in version control, and deploy it automatically. Terraform configuration files are a perfect example of IaC.

CLI (Command-Line Interface)

The Terraform CLI is what you actually run on your machine. It’s an open source binary. You download terraform.exe (or the Linux/Mac equivalent), add it to your PATH, and start running commands like terraform init, terraform plan, and terraform apply. Works on any terminal.

The Building Blocks

Block

A block is the basic container in HCL syntax. It holds your defined objects. A block has a type, one or more labels, and a body with name-value pairs inside curly braces:

resource "aws_instance" "example" {
  ami           = "ami-12345"
  instance_type = "t2.micro"
}

That whole thing is a block. resource is the block type. "aws_instance" and "example" are labels. Everything inside the braces is the body.

Arguments

Inside a block, arguments are the lines that follow the pattern identifier = expression. In the example above, ami = "ami-12345" is an argument. Arguments hold the properties of whatever you’re configuring. They’re how you tell Terraform what you want.

Attributes

An attribute is a property of an object that you can reference elsewhere. After Terraform creates an AWS instance, you can grab its ID with aws_instance.example.id. That .id part is the attribute. You use attributes to wire resources together.

Resource

A resource block describes one or more infrastructure objects you want Terraform to manage. It’s the most important block type. When you write a resource block, you’re telling Terraform “create this thing and keep it in the state you described.” Terraform uses cloud provider APIs behind the scenes to create, edit, and destroy resources.

Data Source

A data source is like a read-only resource. Instead of creating something new, it fetches information about infrastructure that already exists. Maybe someone created a VPC manually, or another Terraform config set it up. You use a data block to look up that existing thing and reference its attributes in your own config. You might also hear it called a “data resource.”

Provider

A provider is a plugin that tells Terraform how to talk to a specific service. AWS, Azure, GCP, each has its own provider. The provider holds the collection of available resources for that platform. Terraform maintains a registry of providers at terraform.io. Without a provider, Terraform doesn’t know what API to call.

Module

Think of a module like a function in programming. It has inputs, does internal processing, and can produce outputs. A module is a self-contained package of Terraform configuration that you can reuse. Instead of copying the same resource blocks everywhere, you write a module once and call it from different configurations. Clean, reusable, maintainable.

Variables and Outputs

Input Variables

A way to parameterize your Terraform code. Instead of hardcoding values, you declare variables and let users pass in values at runtime. This is what makes the same Terraform code work across different environments. You define them in variable blocks and reference them as var.name.

Output Values

After Terraform runs, you might want to see specific results. What’s the IP address of the server it just created? What’s the database endpoint? Output values let you define what information Terraform should display after it finishes. You define them in output blocks, and they show up in the terminal after apply completes.

State and Storage

State

This is a big one. Terraform generates a state file (JSON format) that maps your configuration to the real infrastructure. It records what got created, what the current properties are, and what Terraform is managing. Without state, Terraform has no memory of previous runs. It wouldn’t know if a resource already exists or needs to be created from scratch. If you’re working on a team, state is especially critical because it prevents people from stepping on each other’s work.

Backend

A backend determines where the state file lives and where Terraform runs its operations. It can be local (a file on your machine) or remote (stored on a server somewhere). The backend is what you configure in the terraform block of your configuration.

Remote Backend

A remote backend stores your state file in cloud storage like AWS S3 or Google Cloud Storage. This is the recommended approach for teams. It keeps the state file secure, versioned, and accessible to everyone who needs it. If the state only lives on your laptop, nobody else can run Terraform against that infrastructure without creating a mess.

Locking

When Terraform runs an operation like apply, it locks the state file. This prevents another person (or another process) from running Terraform at the same time and creating conflicts. Think of it like a mutex in programming. One operation at a time, please. When the operation finishes, the lock releases.

Workflow Terms

Plan

terraform plan is where Terraform compares the desired state (your config files) to the actual state (what exists in the real world via the state file). It produces a human-readable output showing what it will create, change, or destroy. Always run plan before apply. Always.

Apply

terraform apply is when Terraform actually does the work. It takes the planned changes and executes them against the cloud provider APIs. This is where resources get created, updated, or deleted for real.

Log

Text output that Terraform prints to stderr during operations like plan and apply. Useful for debugging when things go wrong. You can increase the verbosity with the TF_LOG environment variable.

Configuration Language

Mishra calls this out separately, but it’s really just HCL. Terraform files use a declarative format where you describe the desired state of your infrastructure. You say “I want this to exist” and Terraform figures out the steps to make it happen. This is different from imperative approaches where you spell out every step yourself.

Version Control Terms

Git

A distributed version control system. It tracks every change to every file, which is exactly what you want when your infrastructure is defined in code. Multiple developers can work on the same Terraform configs, and Git handles merging, history, and rollbacks.

VCS (Version Control System)

The broader category that Git falls into. Any software that tracks changes to files over time. GitHub, GitLab, Bitbucket are all platforms built on top of Git. Terraform Cloud can integrate directly with VCS providers to trigger runs when code changes.

Repository

Where your code lives. For Terraform, this means a Git repo containing your .tf files, your module definitions, and everything else needed to manage your infrastructure. Store everything in version control except secrets. Never commit secrets.

Clone

Copying a remote repository to your local machine so you can make changes. git clone <url> gives you a local copy of the entire repo, including its full history.

Fork

Like a clone, but on the server side. You copy an entire repository (with all its branches and history) into your own VCS account. Useful when you want to work on someone else’s project independently. Common in open source workflows.

Cloud Providers

AWS (Amazon Web Services)

Amazon’s public cloud platform. One of the most commonly used Terraform providers.

Azure

Microsoft’s public cloud platform.

AzureRM

The specific Terraform provider for Azure. When you write provider "azurerm" in your config, this is what you’re referencing.

Enterprise and Governance

Policy

A rule that validates whether your Terraform plan complies with organizational requirements. For example, “all S3 buckets must have encryption enabled” or “no instances larger than t3.large in development.”

Policy Set

A collection of policies. You can enforce policy sets globally across all workspaces or target specific ones. Useful for organizations that need different rules for different teams or environments.

Sentinel

HashiCorp’s policy-as-code framework. Available in paid products like Terraform Cloud, Terraform Enterprise, HashiCorp Vault Enterprise, and Consul Enterprise. Sentinel lets you write policies that automatically check Terraform plans before they get applied. It’s the guardrail system.

Workspace

In the Terraform CLI, a workspace is an isolated environment that uses its own state file. You can use workspaces to manage multiple environments (dev, staging, production) from a single set of configuration files. Each workspace gets its own state, so changes in one don’t affect the others.

CI/CD (Continuous Integration / Continuous Delivery)

The practice of automatically building, testing, and deploying changes. For Terraform, this means setting up pipelines that run terraform plan on pull requests and terraform apply when changes merge. The book used Azure DevOps Pipeline as an example of CI/CD with Infrastructure as Code.

Why This Glossary Matters

If you’re preparing for the HashiCorp Terraform certification, these terms will show up everywhere. On the exam, in job interviews, in real Terraform projects. Some of them sound similar (arguments vs. attributes, backend vs. remote backend) and the distinctions matter.

My advice: don’t just memorize definitions. Understand how each concept connects to the others. A provider gives you resources. Resources have arguments and attributes. Resources get tracked in state. State lives in a backend. Backends can be remote. Remote state supports locking. It’s all one chain.

Keep this page open while you study. When a term trips you up in another chapter, come back here.

Previous: Chapter 10: Cloud and Enterprise

Next: Closing Thoughts

This is part of a series retelling “HashiCorp Infrastructure Automation Certification Guide” by Ravi Mishra (Packt, 2021). For the full text, grab the book - ISBN: 978-1-80056-597-5.