Terraform Core Concepts: Providers, Resources, State, and Modules

Terraform lets you describe infrastructure as code and then makes the real world match that description. You write HCL declaring what you want — an EC2 instance, an RDS database, a security group — run terraform plan to see what would change, and terraform apply to make it happen. Four concepts underpin how all of that works: providers, resources, state, and modules.

Providers — the plugin layer

• Providers are plugins that translate Terraform resource declarations into cloud API calls — aws, google, kubernetes, github are all providers; each one knows the API for its platform
• Pin provider versions in the required_providers block to prevent silent breaking changes when Terraform releases updates — the same reason you pin library versions in application code; unpinned providers can change behavior overnight
• Multiple providers in one configuration enable cross-cloud resources: an aws provider managing EKS plus a kubernetes provider managing the namespaces inside that cluster, all in one terraform apply

Resources — the individual infrastructure units

• A resource is one cloud object: an EC2 instance, an S3 bucket, a DNS record, a Kubernetes namespace; each resource belongs to a provider and has a type and a name that together form a unique address (aws_instance.app_server)
• Resources reference each other by address — aws_security_group.web.id inside an EC2 resource declaration creates a dependency; Terraform builds a dependency graph from these references and determines the creation order automatically
• Destroying a resource that other resources depend on fails safely — Terraform detects the dependency and refuses to destroy until dependents are removed first

State — the source of truth

• State is what makes Terraform declarative rather than scripted; Terraform writes a record of every resource it manages, including the real cloud IDs that APIs assign (i-0abc123 for an EC2 instance)
• On every plan, Terraform reads your HCL (desired state) and the state file (current state) and computes the minimum set of API calls to close the gap — without state, Terraform would have to re-inspect every cloud resource on every run and could not tell what it manages from what existed before
• State stores sensitive values (database passwords, private keys) in plaintext — encrypt state at rest and restrict access to the state backend; never commit terraform.tfstate to version control

Modules — reusable configuration packages

• A module is a directory of .tf files with explicit variable inputs and output values; you call it with a module block, pass inputs, and get outputs back — the same ECS service pattern used by eight microservices is defined once and called eight times with different parameters
• The Terraform Registry hosts community modules for common infrastructure patterns — VPCs, RDS clusters, EKS clusters — that are worth using rather than rebuilding from scratch