Terraform Architecture Explained: How It Works Under the Hood

Terraform architecture explained simply means peeling back the layers to see how a Go binary, JSON state, and external APIs coordinate to provision cloud infrastructure. Every DevOps engineer eventually runs into a situation where a terraform apply hangs, or a state file gets locked, leaving them wondering what is actually happening behind the terminal screen.

At Squarebrackets, in our Advanced DevOps and Infrastructure Engineering Course, we teach our students that Terraform is not a cloud service; it is a client-side tool. It does not run on a background daemon. It executes, completes its job, and exits. If you are building multi-cloud automation on AWS or deploying container fleets via our Kubernetes: Beginner to Advanced training, pairing Terraform with our AWS Cloud courses makes these mechanics second nature.

What is the High-Level Architecture of Terraform?

When you run a command like `terraform init`, Terraform Core reads your configuration files, identifies which providers you are using, and downloads those specific provider binaries from the HashiCorp Registry into your local `.terraform` directory.

Understanding Terraform Core: The Brain of the Operation

Terraform Core is the engine that drives the entire workflow. It is compiled as a single command-line tool (`terraform`) and is responsible for processing your HashiCorp Configuration Language (HCL) files.

Core performs three critical jobs during any execution run:

• Configuration Parsing: It reads your `.tf` files, validates the syntax, interpolates variables, and evaluates expressions.
• Graph Generation: It builds a Directed Acyclic Graph (DAG) representing all your resources. If Resource B needs an IP address from Resource A, Core knows it must build Resource A first.
• State Management: It compares your desired configuration against the current state file to determine what actions (Create, Read, Update, Destroy) are required.

# Example of implicit dependency that Terraform Core resolves using a DAG
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id # Core detects this dependency first
  cidr_block = "10.0.1.0/24"
}

In the code block above, Terraform Core parses the configuration and notes that the subnet cannot be created without the VPC ID. It places the VPC ahead of the subnet in the dependency graph automatically.

What is the Role of Terraform Providers?

Terraform Providers are executable plugins that act as translators. While Terraform Core knows *how* to manage the lifecycle of a generic resource, it does not know how to talk to the AWS EC2 API, create a Google Cloud Storage bucket, or spin up a Kubernetes pod.

That is where providers come in. When Core decides that an AWS VPC needs to be created, it sends a gRPC request to the AWS Provider plugin: *'Please create a VPC with CIDR 10.0.0.0/16.'* The AWS Provider takes that request, authentication credentials, and converts it into an actual HTTPS API call to `ec2.amazonaws.com`.

The Terraform State File: The Source of Truth

You cannot understand terraform architecture explained without grasping the state file (`terraform.tfstate`). Terraform is a declarative tool. You write what you want the end-state to look like, and Terraform makes it happen.

To do this efficiently without querying your cloud provider for thousands of resources on every single command, Terraform keeps a local or remote JSON file containing metadata about the resources it manages. This file maps your logical HCL resource names to real-world cloud IDs.

When you run `terraform plan`, Terraform performs a refresh operation. It reads the state file, queries the actual cloud APIs to see if anything has changed (detecting 'drift'), and compares this with your local HCL code. It then outputs the difference.

How the Terraform Workflow Executes Under the Hood

Let's trace exactly what happens under the hood during the classic write-plan-apply workflow:

1. terraform init: Core reads configuration files, identifies the required providers, downloads them from registry.terraform.io, and initializes the backend settings.
2. terraform plan: Core builds the dependency graph. It asks the state file for the last known state, asks the providers to query the cloud APIs for updates, and calculates the delta. It outputs a plan of action.
3. terraform apply: Core coordinates the execution. It walks the dependency graph. For each resource, it sends a gRPC request to the respective provider to execute the API change. Once the provider confirms success, Core writes the new metadata to the state file.

Remote Backends and State Locking

By default, the state file is stored on your local disk as `terraform.tfstate`. This works fine for solo projects, but in a production team environment, it is a disaster waiting to happen. If two engineers run `terraform apply` at the same time, they will overwrite each other's changes and corrupt the state.

To solve this, Terraform architecture supports Remote Backends like Amazon S3, Azure Blob Storage, or HashiCorp Consul. When using a remote backend, Terraform stores the state file in a centralized cloud bucket and uses a locking mechanism (such as an AWS DynamoDB table) to ensure only one person or CI/CD pipeline can modify the infrastructure at any given time.

Where to go from here

Mastering the internal mechanics of infrastructure code is just the start. If you want to build resilient cloud platforms and master production-grade pipelines, take a look at the Advanced DevOps and Infrastructure Engineering Course where we build and deploy enterprise architectures from scratch.