What's changed: Initial version
6.4Configuration management tools (Ansible, Terraform, Puppet/Chef)
Covers the idea of Infrastructure as Code (IaC) managing configuration as code; the meaning of idempotency; Ansible, which is agentless, works over SSH, is push-based, and is written in YAML; Terraform, which builds infrastructure declaratively; and the positioning of the agent-resident, pull-based Puppet/Chef—all as tool-selection judgment.
Beyond replacing manual CLI with scripts lies the world of configuration management: "declare the desired configuration state as code and have a tool realize it." Turning configuration into code enables version control, review, and reproducibility—this is called Infrastructure as Code (IaC). This section organizes how the representative tools tested on CCNA—Ansible, Terraform, Puppet, and Chef—differ in "agent needed or not," "push or pull," and "description language," building tool-selection judgment according to requirements.
6.4.1IaC and idempotency
- Infrastructure as Code (IaC) is the idea of writing and managing server and network configuration as code (text files) rather than by hand. It can be version-controlled with Git, making change review, restoration to a past state, and environment reproduction easy.
- Idempotency is the property that applying the same configuration code any number of times yields the same result. If the desired state already holds, nothing is changed and only the differing parts are fixed, so repeated runs are safe. It is a key property a configuration management tool should have.
- Declarative vs. procedural: describing "what the end state should be" is declarative, while describing "what steps to take, in order" is procedural. Declarative descriptions pair well with idempotency.
6.4.2Ansible (agentless, push, YAML)
- Ansible is an agentless tool (it installs no dedicated resident software on managed targets; it connects over SSH to apply configuration). Configuration is written in a YAML file called a playbook and applied idempotently.
- Push model: the management side (control node) pushes configuration out to the target devices. Nothing needs to reside on the target side, and it can be applied immediately to devices where SSH is already enabled, so the barrier to entry is low.
6.4.3Terraform (declarative IaC) and Puppet/Chef
- Terraform is an IaC tool that builds and manages infrastructure (especially cloud resources) declaratively. You define the "desired state," and it computes the diff against the current state and applies only the necessary changes. It is agentless and operates the target APIs through providers.
- Puppet/Chef are tools that mainly keep resident agents on managed targets and maintain configuration in a pull model (each agent periodically fetches configuration from a central server). Puppet uses its own DSL and Chef uses a Ruby-based description. Their scope is trending down in CCNA v1.1, but grasp the contrasting traits of resident agents and the pull model.
Most-tested: the contrast of Ansible = agentless, push, YAML, SSH; Puppet/Chef = resident agent, pull; and Terraform = declarative IaC. Together with the definition idempotency = the same result no matter how many times you apply, be able to distinguish each tool by "agent needed or not / push or pull / description language" in a table.
Suppose your network team wants to start, as fast as possible, an automation to "uniformly configure the SNMP community and Syslog destination" across dozens of existing Cisco switches, under the constraint that you do not want to install new software on the target devices (change management is a high hurdle). Thus whether an agent is needed becomes the deciding fork. Puppet/Chef are fundamentally pull-based, keeping a resident agent on each device that fetches configuration from a central server, which sits poorly with the "install nothing on the devices" constraint. Ansible, by contrast, is agentless: you can start by simply pushing configuration from a control node to switches where SSH is already enabled, and you write the configuration declaratively in a YAML playbook. Moreover, because the playbook is idempotent, re-running it after a mid-way failure behaves as "leave already-correct devices as-is and fix only the un-applied ones," avoiding double-application accidents. If instead the requirement were "build a virtual network and VMs from scratch on a new cloud," the focus shifts from device configuration to infrastructure provisioning, making the declarative IaC tool Terraform a strong candidate. Choosing the tool by the nature of the requirement—"push config to existing devices without installing an agent (Ansible)," "build cloud infrastructure declaratively (Terraform)," or "run in an agent-resident pull model (Puppet/Chef)"—is practical judgment, not rote memorization.
| Tool | Agent | Model | Main description/trait |
|---|---|---|---|
| Ansible | Agentless (SSH) | Push | YAML playbooks, idempotent |
| Terraform | Agentless | Push | Declarative IaC, applies state diff |
| Puppet | Resident agent | Pull | Puppet-specific DSL, declarative |
| Chef | Resident agent | Pull | Ruby-based recipes |
Trap: "Ansible requires a dedicated resident agent on managed targets" is wrong—Ansible is agentless and push-based over SSH. It is Puppet and Chef that keep resident agents and operate in a pull model. Also wrong: "with an idempotent tool, applying the same code twice inserts the configuration twice"—idempotency means the result is the same no matter how many times you apply, preventing side effects from double application.
6.4.4Section summary
- IaC manages configuration as code, enabling version control and reproduction; idempotency is the property that the result is the same no matter how many times you apply
- Ansible is agentless, push, YAML, SSH; Terraform is declarative IaC (especially cloud building)
- Puppet/Chef are characterized by resident agents and a pull model. Choose the tool by requirements (agent needed or not / push or pull / target)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. For dozens of existing Cisco switches, you want to bulk-push configuration over SSH without installing new resident software on the targets, describing it declaratively in YAML. Which configuration management tool best fits this requirement?
Q2. Which best explains a configuration management tool's "idempotency" from an operational standpoint?
Q3. You want to provision a virtual network and VMs from scratch on the cloud using declarative IaC. Among the representative tools tested on CCNA, which is most commonly used for this purpose?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.