6.5 Configuration Management Tools
Key Takeaways
- Ansible is agentless (uses SSH), uses YAML playbooks, and is ideal for configuring network devices.
- Terraform is declarative infrastructure-as-code: it provisions and tracks resources via a state file.
- Ansible is procedural (do these steps); Terraform is declarative (make the state match this).
- Both Ansible and Terraform are idempotent — re-running them converges to the same end state.
- Puppet and Chef are agent-based, pull-model tools more common for server than network management.
Why These Tools Are Tested
The CCNA v1.1 names three configuration management tools you must compare: Ansible, Terraform, and (to a lesser degree) Puppet/Chef. You will not write playbooks on the exam, but you must know each tool's agent model, language, and ideal use case.
Ansible
Ansible (developed by Red Hat / IBM) is the most popular tool for network device configuration.
| Feature | Detail |
|---|---|
| Agent model | Agentless — nothing installed on devices; connects over SSH (or API) |
| Language | YAML for playbooks; Python under the hood |
| Operation | Push-based — the control node pushes config out |
| Idempotency | Re-running a playbook converges to the same state, no duplicate changes |
| Best for | Day-2 operations: configuring devices that already exist |
Ansible Components
| Component | Purpose |
|---|---|
| Inventory | List of managed hosts/groups and their addresses |
| Playbook | YAML file defining the ordered tasks |
| Module | Pre-built action, e.g. cisco.ios.ios_config |
| Task | A single action inside a playbook |
| Role | Reusable bundle of tasks, templates, and variables |
Example Playbook (Network)
---
- name: Configure VLANs on access switches
hosts: access_switches
gather_facts: no
tasks:
- name: Create VLAN 10
cisco.ios.ios_vlans:
config:
- vlan_id: 10
name: SALES
state: merged
- name: Set access port
cisco.ios.ios_config:
parents: interface GigabitEthernet0/1
lines:
- switchport mode access
- switchport access vlan 10
Because Ansible is agentless and YAML-driven, it suits routers/switches that cannot run a custom agent — a frequent exam fact.
Terraform
Terraform (by HashiCorp) is an infrastructure-as-code tool for provisioning resources — creating the infrastructure rather than tweaking an existing box.
| Feature | Detail |
|---|---|
| Model | Declarative — you describe the desired end state; Terraform plans the steps |
| Language | HCL (HashiCorp Configuration Language) |
| Providers | Plugins for AWS, Azure, GCP, plus Cisco, Juniper, etc. |
| State file | terraform.tfstate records what currently exists |
| Safety | terraform plan previews changes before apply runs them |
| Best for | Day-0 provisioning: standing up new infrastructure |
Terraform Workflow
- Write the
.tffiles in HCL. - Plan —
terraform planshows exactly what will change. - Apply —
terraform applymakes the changes. - Destroy —
terraform destroytears the resources down.
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
tags = { Name = "Production-VPC" }
}
resource "aws_subnet" "web" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
}
Run terraform apply twice with no config change and it reports "No changes" — that is idempotency plus the state file at work.
Ansible vs. Terraform
| Feature | Ansible | Terraform |
|---|---|---|
| Approach | Procedural (step-by-step) | Declarative (desired state) |
| Primary use | Configuration management | Infrastructure provisioning |
| Agent | Agentless (SSH) | Agentless (API) |
| Language | YAML | HCL |
| State file | No | Yes (terraform.tfstate) |
| Network strength | Excellent (many Cisco modules) | Growing (cloud-network providers) |
| Best phase | Day-2 (configure existing) | Day-0 (create new) |
When to Use Each
| Scenario | Tool |
|---|---|
| Push VLANs/ACLs/OSPF to 100 existing switches | Ansible |
| Provision a new AWS VPC with subnets and security groups | Terraform |
| Build an entire cloud network from scratch | Terraform |
| Update ACLs on all firewalls nightly | Ansible |
Puppet, Chef, and SaltStack
| Tool | Agent | Language | Model |
|---|---|---|---|
| Puppet | Agent-based | Ruby / Puppet DSL | Declarative, pull |
| Chef | Agent-based | Ruby | Procedural, pull |
| SaltStack | Agent or agentless | YAML/Python | Declarative or procedural |
Trap: Puppet and Chef need an agent installed on each managed node, so they are awkward for switches/routers that cannot run one — that is exactly why Ansible dominates networking.
On the Exam: Ansible = agentless, SSH, YAML, push, Day-2 config. Terraform = declarative, HCL, state file, Day-0 provisioning. Both are idempotent and agentless; Puppet/Chef are agent-based.
Idempotency: The Concept That Ties Them Together
The single most important property shared by all these tools is idempotency — running the same definition any number of times leaves the system in the same final state. If a playbook says VLAN 10 should exist and it already does, Ansible reports "ok" and changes nothing; only if VLAN 10 is missing does it report "changed" and create it. Terraform behaves the same way through its state file, applying only the delta between desired and actual.
This is why automation is safe to re-run on a schedule to enforce the baseline and crush configuration drift — you never have to worry that re-running will duplicate VLANs, stack ACL lines, or otherwise compound. Contrast that with a naive script that blindly types vlan 10 every run; that script is not idempotent and is exactly what automation tooling is designed to replace.
Day-0 vs. Day-2: A Decision Framework
The exam often frames tool selection around lifecycle phases. Day-0 is the moment infrastructure is born — provisioning a brand-new VPC, spinning up virtual machines, carving out subnets and security groups that did not exist a minute ago. That creation-from-nothing job belongs to Terraform, whose declarative model and state file are built to track resources it created. Day-1 is initial configuration, and Day-2 is ongoing operations — pushing VLANs, updating ACLs, deploying routing changes to devices that already exist.
That recurring configuration job belongs to Ansible, whose agentless SSH model and rich library of Cisco modules make it the network engineer's daily driver.
In the real world the two are complementary, not competitors: a team commonly uses Terraform to stand up the cloud network and then hands off to Ansible to configure the operating systems and network functions running inside it. When a CCNA question asks which tool fits a scenario, decode whether the task creates infrastructure (Terraform) or configures existing devices (Ansible), and whether an agent is required (only Puppet and Chef need one).
Which configuration management tool is agentless and uses SSH with YAML playbooks to configure network devices?
What is the primary difference between Ansible and Terraform?