ExamFinch.com My Study

Study guide

6.5 Configuration Management Tools

Practice this exam

Cisco Certified Network Associate CCNA

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the CCNA 200-301 Exam Domains and Weights Study Strategies and Tips

2 Chapter 1: Network Fundamentals (20%)

1.1 Network Components 1.2 Network Topology Architectures 1.3 Physical Interfaces and Cabling 1.4 TCP vs. UDP 1.5 IPv4 Addressing and Subnetting 1.6 IPv6 Addressing and Prefix 1.7 Wireless Principles 1.8 Virtualization Fundamentals 1.9 Switching Concepts 1.10 OSI and TCP/IP Reference Models 1.11 Verifying IP Parameters on Client Operating Systems

3 Chapter 2: Network Access (20%)

2.1 VLANs — Configuration and Verification 2.2 Trunking and 802.1Q 2.3 Layer 2 Discovery Protocols (CDP and LLDP) 2.4 EtherChannel (Link Aggregation) 2.5 Spanning Tree Protocol (STP) and RSTP 2.6 Wireless Architectures and AP Modes 2.7 Network Access Troubleshooting 2.8 Inter-VLAN Routing — Deep Dive

4 Chapter 3: IP Connectivity (25%)

3.1 Routing Table Components 3.2 Router Forwarding Decisions 3.3 IPv4 and IPv6 Static Routing 3.4 Single-Area OSPFv2 — Concepts 3.5 Single-Area OSPFv2 — Configuration 3.6 First Hop Redundancy Protocols (FHRP) 3.7 Troubleshooting IP Connectivity 3.8 OSPF Troubleshooting Scenarios

5 Chapter 4: IP Services (10%)

4.1 NAT (Network Address Translation) 4.2 DHCP and DNS 4.3 NTP, SNMP, and Syslog 4.4 QoS Fundamentals 4.5 TFTP/FTP and Remote Access 4.6 IP Services — Comprehensive Review

6 Chapter 5: Security Fundamentals (15%)

5.1 Key Security Concepts 5.2 Device Access Control and Password Policies 5.3 VPN Fundamentals 5.4 Access Control Lists (ACLs) 5.5 Layer 2 Security Features 5.6 Network Security Best Practices and Hardening 5.7 Threat Mitigation and Incident Response

7 Chapter 6: Automation and Programmability (10%)

6.1 Impact of Automation on Network Management 6.2 Controller-Based and Software-Defined Architectures 6.3 AI and Machine Learning in Network Operations 6.4 REST-Based APIs 6.5 Configuration Management Tools 6.6 JSON-Encoded Data 6.7 Automation and Programmability — Comprehensive Review

6.5 Configuration Management Tools

Key Takeaways Explain This Topic AI

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.

Last updated: June 2026

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 .tf files in HCL.

Plan — terraform plan shows exactly what will change.

Apply — terraform apply makes the changes.

  • Destroy — terraform destroy tears 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).