How HashiCorp Terraform uses declarative configuration, plans, and state to manage infrastructure as code.
Terraform is an infrastructure-as-code (IaC) tool: it lets a team describe cloud, on-premises, and SaaS resources in human-readable configuration, then plan and apply the changes needed to reach that declared state. The configuration can be versioned, reviewed, reused, and shared; Terraform uses providers to communicate with each managed system. HashiCorp’s introduction to Terraform describes the same write, plan, and apply workflow.
IaC makes the intended infrastructure explicit. It does not make every infrastructure change safe by itself: teams still need code review, access controls, testing appropriate to the change, and a safe state-storage strategy.
| Manual change pattern | IaC improvement |
|---|---|
| An operator changes a console setting with no durable record of intent. | Configuration records the intended setting and can be reviewed before it is applied. |
| Environments are rebuilt from memory or runbooks. | The same configuration can be reused, with variables for legitimate differences. |
| A change is hard to preview. | terraform plan proposes create, update, and destroy actions before terraform apply performs them. |
Terraform is declarative: a configuration describes the desired result rather than a sequence of shell commands. Terraform then builds a dependency graph and works out a valid order for the operations. Declarative does not mean “never replace”: when an API cannot update a property in place, a plan can legitimately show replacement of a resource.
This example declares an AWS provider requirement and a tagged S3 bucket. It is illustrative; a real configuration also needs credentials and must choose a globally unique bucket name.
1terraform {
2 required_providers {
3 aws = {
4 source = "hashicorp/aws"
5 version = "~> 5.0"
6 }
7 }
8}
9
10provider "aws" {
11 region = "ca-central-1"
12}
13
14resource "aws_s3_bucket" "reports" {
15 bucket = "example-company-reports-2026"
16
17 tags = {
18 Environment = "production"
19 ManagedBy = "terraform"
20 }
21}
After terraform init prepares the working directory, terraform plan compares this configuration with Terraform’s current knowledge of the managed infrastructure and displays the proposed actions. terraform apply carries out an approved plan. A plan is a review artifact, not a guarantee that an external system will remain unchanged between planning and applying.
Terraform stores state to bind a resource instance in configuration to the corresponding remote object and to retain operational metadata. For example, the address aws_s3_bucket.reports must be associated with the particular bucket Terraform manages; a name alone is not enough for every API or resource type. Terraform’s state documentation explains why that mapping is necessary.
State can contain sensitive values, even when configuration does not show them. Do not commit state files to a source repository. For collaborative work, use a backend with appropriate access control and locking rather than passing a local state file between people.
Terraform is well suited to declaring and managing infrastructure through provider APIs. It is not a replacement for application build pipelines, operating-system configuration management, or every imperative operational task. A useful boundary is: use Terraform to declare the infrastructure and its stable relationships; use a purpose-built tool where the work is primarily application delivery or in-guest configuration.