How does Terraform differ from configuration management tools like Ansible, Chef, or Puppet?
Quick Answer
Terraform is primarily a **provisioning** tool: it creates, updates, and destroys infrastructure resources (VMs, networks, managed services) via cloud provider APIs and tracks their state. Ansible/Chef/Puppet are **configuration management** tools: they install packages, edit files, and manage the software running *inside* already-existing machines, typically without tracking state the way Terraform does. In practice teams use both together — Terraform provisions the VM/cluster, then hands off to Ansible (or cloud-init/user-data) for in-instance configuration.
Detailed Answer
It's easy to lump Terraform in with Ansible, Chef, and Puppet as "DevOps automation tools," but they solve different layers of the problem, and understanding the boundary is a common interview probe.
Provisioning vs. configuration management
- Terraform (provisioning) talks to cloud/platform APIs to create the resources themselves: a VPC, an EC2 instance, an RDS database, a Kubernetes cluster, a DNS record. It answers "what infrastructure exists?"
- Ansible/Chef/Puppet (configuration management) operate inside a machine that already exists: installing packages, writing config files, starting services, managing users. They answer "what software is running on this box, and how is it configured?"
Other structural differences
| Terraform | Ansible | |
|---|---|---|
| Model | Declarative, state-tracked | Primarily imperative task lists (though idempotent by convention) |
| Target | Cloud/platform APIs | Machines (via SSH/WinRM) or APIs |
| State | Maintains a state file mapping config → real resources | Stateless — re-runs tasks and relies on each task being idempotent |
| Typical unit | A resource (VM, subnet, bucket) | A task (install package, template a file) |
How they're used together
A common pattern: Terraform provisions the VM/cluster and passes it a minimal bootstrap (cloud-init or a startup script), then Ansible (or Chef/Puppet) takes over to configure the software stack running inside it. In containerized/Kubernetes-first shops, this split often disappears entirely — Terraform provisions the cluster and Kubernetes manifests (or Helm) replace the configuration-management layer.
resource "aws_instance" "app" {
ami = var.ami_id
instance_type = "t3.medium"
user_data = file("bootstrap.sh") # hands off to a config tool or just starts the app
}
The interview-ready summary: Terraform creates the machine; Ansible configures what's on it. They're complementary, not competing.