Day 114: Terraform fundamentals: providers, remote state, locking
Declaring infrastructure the way Kubernetes declares workloads
Terraform lets you describe cloud infrastructure (VPCs, servers, databases, DNS records) declaratively — the same "desired state, reconciled" philosophy as Kubernetes (Phase 8, Day 47), just for infrastructure that lives outside a cluster.
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "web" {
ami = "ami-0abcdef1234567890"
instance_type = "t3.micro"
}Providers
A provider is a plugin translating Terraform's generic resource model into a specific API — AWS, GCP, even non-cloud systems (GitHub, Datadog). This is conceptually the same plugin-interface pattern as CNI/CSI (Phase 9/10): Terraform core doesn't know about AWS specifically, the AWS provider does.
Remote state and locking
Terraform tracks what it created in a state file — mapping your config to real resource IDs. Storing this locally is dangerous for a team (two people applying simultaneously can corrupt state or create duplicate resources). Remote state (an S3 bucket, Terraform Cloud) centralizes it; state locking (via DynamoDB, or Terraform Cloud's built-in locking) prevents two applies from running concurrently — directly analogous to the leader-election/mutual-exclusion concepts from Phase 7.
Never edit the state file by hand
The state file is Terraform's single source of truth about what it manages. Manual edits (or losing it) can cause Terraform to believe resources exist when they don't, or vice versa — leading to destructive "fixes" on the next apply.
Key terms
- Provider
- A plugin translating Terraform resources into a specific API (AWS, GCP...).
- State file
- Terraform's record mapping configuration to real, created resource IDs.
- State locking
- Prevents concurrent Terraform applies from corrupting shared state.
Two engineers run terraform apply on the same infrastructure at nearly the same time, without state locking. What can go wrong?
