You know terraform apply creates resources. But do you know how to import existing infrastructure into state? Or how to target a single resource during a risky deployment? Or how to use the interactive console to test expressions before putting them in code? The Terraform CLI has more power than most people ever use. Let us fix that.
31 posts tagged with "Terraform"
Infrastructure as Code with Terraform
View All TagsNot everything in your cloud account was created by Terraform. Maybe the VPC was built by another team using CloudFormation. Maybe the DNS zone was set up manually in the console two years ago. Maybe you need the latest Amazon Linux AMI and its ID changes every week. Data sources let Terraform read information from your cloud provider without managing the resource itself.
You rename a tag in your Terraform config, expecting a simple metadata update. Instead, Terraform announces it will destroy and recreate your production database. Your heart rate spikes. Understanding how Terraform decides to create, update, or destroy resources — and how to control that behavior — is the difference between a calm deploy and a production incident.
Terraform by itself does not know how to create an EC2 instance, a Kubernetes pod, or a DNS record. It delegates that work to providers — plugins that translate your HCL into API calls. Understanding providers is understanding how Terraform actually talks to the outside world.
Hardcoding an AMI ID, an instance type, and a region directly into your Terraform config works exactly once. The moment you need a second environment — staging, production, a different region — you are copying and pasting entire files. Variables and outputs exist to stop that cycle.
You just ran terraform apply, everything deployed perfectly, and then your teammate ran it too — from their laptop. Suddenly, resources are duplicated, outputs are wrong, and nobody knows what is actually deployed. Welcome to the world of Terraform state mismanagement.
