Exam Objective 5.5: Use configuration management mechanisms such as Ansible to execute commands.
Objective 5.3 introduced automation-based management and infrastructure as code at a conceptual level. This objective goes one level deeper into the specific tool the CCNA blueprint names directly — Ansible — covering how it's actually structured and used to execute commands and push configuration across network devices. You're not expected to become an Ansible developer, but you are expected to recognize Ansible's core components, understand why it's well-suited to network device management specifically, and be able to read a basic playbook and identify what it does.
Ansible is an open-source, agentless configuration management and automation tool that uses simple, human-readable YAML files to define a desired sequence of tasks, then executes those tasks against one or many target devices.
Why "agentless" matters specifically for network devices: Unlike some automation/configuration management tools that require installing dedicated agent software on every managed system, Ansible does not require any special software to be installed on the network devices it manages. For traditional Linux/Windows server automation, Ansible typically connects via SSH and uses Python already present on the target system; for network devices specifically (which generally don't run a general-purpose OS capable of hosting Python the way a server does), Ansible instead uses specialized network modules that communicate with the device over SSH (or, for some platforms, an API) and issue standard CLI commands or API calls on Ansible's behalf, without needing any Ansible-specific software running on the device itself.
Why this fits network devices particularly well: Since most routers and switches cannot run arbitrary third-party agent software the way a general-purpose server can, an agentless tool that simply connects over SSH (a protocol every managed device already supports, as covered back in objective 4.2) and issues standard commands is a natural fit for network infrastructure, without requiring any change to the device's own capabilities.
Exam Alert: Ansible being agentless — requiring no special software installed on the managed network device itself, communicating instead via existing protocols like SSH — is one of the most frequently tested foundational facts about the tool.
Control node: The machine where Ansible itself is installed and run from — the system an administrator actually interacts with to launch automation tasks against the managed devices.
Managed nodes: The target devices being configured/managed by Ansible — in a network automation context, these are the routers, switches, firewalls, and other network devices being automated.
Inventory: A file (commonly named hosts or inventory, in INI or YAML format) listing the managed nodes Ansible should be able to target, often organized into logical groups.
Example inventory (INI-style format):
[branch_routers]
router1 ansible_host=10.1.1.1
router2 ansible_host=10.1.2.1
[core_switches]
switch1 ansible_host=10.1.1.2
Modules: Individual, reusable units of Ansible functionality that actually perform a specific task against a managed node — for example, a module for configuring an interface, a module for gathering device facts, or a module for pushing a full configuration file. Cisco maintains platform-specific Ansible modules (for example, modules targeting Cisco IOS devices specifically) that understand how to correctly interact with that platform's particular CLI syntax and behavior.
Tasks: An individual action within a playbook, typically invoking one specific module with a defined set of parameters.
Playbook: A YAML file defining an ordered list of tasks (also referred to as plays) to be executed against one or more groups of managed nodes defined in the inventory — the playbook is the actual "script" describing what Ansible should do.
Facts: Information Ansible automatically gathers about a managed node before executing tasks against it (such as the device's current hostname, software version, or interface list), which can then be used elsewhere within the playbook's logic.
Exam Alert: Know the core vocabulary — control node, managed node, inventory, module, task, playbook — and specifically that a playbook is the YAML file containing the ordered sequence of tasks Ansible will execute; expect to be shown a description of one of these components and asked to identify it by name.
A representative, simplified example playbook targeting Cisco IOS devices:
name: Configure hostname and save config
hosts: branch_routers
gather_facts: no
tasks:
name: Set the device hostname
ios_config:
lines:
hostname Router1
name: Save the running configuration
ios_config:
save_when: always
Reading this playbook structurally:
name (at the top level) — a human-readable description of what this play accomplishes, purely for clarity/documentation purposes
hosts — specifies which inventory group this play should be executed against (branch_routers, matching a group defined in the inventory file)
tasks — the ordered list of individual actions to perform; here, two tasks are defined, each invoking the ios_config module (a Cisco-specific Ansible module) with different parameters
Each task's own name — a human-readable label for that specific task, shown in Ansible's output as it executes, again purely for clarity
Exam Alert: Expect to be shown a simplified sample playbook (similar to the example above) and asked to identify what specific action it performs, which devices it targets (based on the hosts field), or to identify a specific playbook component (task, module, hosts group) by name.
Idempotency means that running the same Ansible playbook multiple times against the same target produces the same end result every time, without generating unintended, repeated, or duplicate changes on subsequent runs.
Why idempotency matters: If a task's desired configuration is already present on the device, Ansible recognizes this and simply does nothing further for that specific task on that run (reporting it as "ok" rather than "changed") — rather than blindly re-applying the same command over and over regardless of the device's actual current state. This allows the exact same playbook to be safely re-run at any time (to enforce a known-good configuration state, to check for drift, or as part of a regularly scheduled compliance run) without worrying about it causing unintended side effects from repeated execution.
How this differs from a simple, naive script: A basic script that just blindly re-issues the same CLI commands every single time it runs, regardless of current state, is not idempotent — running it twice could produce duplicate configuration lines, errors, or otherwise unintended results. Ansible's network modules are specifically designed to check the current state first and only make the changes actually needed to reach the desired state, which is exactly the idempotent behavior described.
Exam Alert: Idempotency — the same playbook run repeatedly produces the same consistent end-state without unintended repeated changes — is one of the most conceptually important and frequently tested Ansible-specific facts, and it directly reinforces the declarative mindset introduced with Infrastructure as Code in objective 5.3.
The actual command used to run a playbook from the control node:
ansible-playbook -i inventory configure_hostname.yml
Key elements:
ansible-playbook — the command used to execute a playbook (as opposed to ansible, a related command used to run a single, one-off ad hoc task rather than a full multi-task playbook)
-i inventory — specifies which inventory file to use, defining the actual target managed nodes/groups
configure_hostname.yml — the specific playbook file being executed
Ad hoc commands (a simpler, single-task alternative to a full playbook):
ansible branch_routers -i inventory -m ios_facts
This example runs a single module (ios_facts, which gathers device information) directly against the branch_routers inventory group, without needing a full playbook file — useful for quick, one-off tasks (like a simple fact-gathering check) rather than a repeatable, multi-step configuration process.
Exam Alert: Know the distinction between the ansible-playbook command (executing a full, multi-task playbook file) and the simpler ansible command (running a single ad hoc task/module directly against target hosts without needing a playbook file at all).
Recall from objective 5.3 that automation-based management (the category Ansible most directly represents) is generally described as more imperative in nature — a playbook's tasks describe a defined sequence of actions to carry out — though Ansible's idempotent behavior does give it some declarative-like characteristics (checking current state before deciding whether to act), distinguishing it somewhat from a purely naive imperative script while still remaining conceptually distinct from a fully declarative Infrastructure as Code tool like Terraform, which is built around continuously reconciling actual infrastructure state against a declared target state as its central operating model.
Where Ansible fits among the five management approaches from objective 5.3:
Can be used to directly automate device-based CLI configuration (connecting via SSH to individual routers/switches, as shown in the examples above)
Can also be used to interact with a controller-based platform's API instead of individual device CLIs directly, combining automation-based management with controller-based management
Frequently used alongside Terraform in real-world deployments — Terraform might provision/define the overall desired infrastructure state, while Ansible handles more granular, ongoing configuration management tasks on top of that provisioned infrastructure
Exam Alert: Recognize that Ansible and Terraform, while both falling under the broader automation/IaC umbrella from objective 5.3, are not identical in their underlying model — Ansible executes ordered tasks (with idempotent behavior layered on top) while Terraform is built specifically around declarative, continuous state reconciliation. Both tools are commonly named together on the current blueprint, and the exam expects you to know Ansible specifically as the tool referenced under this particular objective (5.5), focused on executing commands/tasks against managed network devices.
Consistency — the exact same playbook produces the exact same result across many devices, eliminating the human variability inherent in manually typing commands into each device individually (directly addressing device-based management's consistency problem from objective 5.3)
Speed at scale — a single playbook execution can configure hundreds of devices in the time it would take to manually log into just a handful of them
Version control and auditability — since playbooks are simply text (YAML) files, they can be stored in a system like Git, providing a full history of exactly what changes were made, when, and by whom
Safe repeatability — thanks to idempotency, playbooks can be re-run routinely (for compliance checking or drift correction) without fear of causing unintended duplicate changes
Agentless simplicity — no need to install or maintain any special software on the managed network devices themselves, working instead through protocols (SSH) those devices already support
Q1. Why is Ansible particularly well-suited to managing network devices such as routers and switches, compared to configuration management tools that require an installed agent?
A. Ansible requires every network device to run a full Linux operating system
B. Ansible is agentless, communicating with managed devices over protocols like SSH that they already support, without requiring any special software installed on the device itself
C. Ansible only works with cloud-hosted network devices
D. Ansible requires a dedicated hardware appliance on every managed device
Answer: B. Ansible's agentless architecture means it does not require any special software to be installed on the managed network device itself. Instead, it communicates using protocols the device already supports (most commonly SSH), issuing standard CLI commands or API calls on Ansible's behalf — a natural fit for network devices, which generally cannot host arbitrary third-party agent software the way a general-purpose server can.
Q2. In Ansible terminology, what is a playbook?
A. The machine where Ansible itself is installed and executed from
B. A YAML file defining an ordered list of tasks to be executed against one or more groups of managed devices
C. A file listing the target devices Ansible can manage
D. A single, reusable unit of functionality that performs one specific action
Answer: B. A playbook is the YAML file containing the ordered sequence of tasks (plays) that Ansible will execute against the managed nodes specified in its hosts field, effectively serving as the "script" describing exactly what Ansible should do. The control node is the machine running Ansible, the inventory lists target devices, and a module is a single reusable unit of functionality invoked by a task.
Q3. What does it mean for an Ansible playbook to be idempotent?
A. The playbook can only be run once, ever, against any given device
B. Running the same playbook multiple times against the same target produces the same consistent end result, without generating unintended repeated changes if the desired state is already in place
C. The playbook automatically encrypts all data it transmits
D. The playbook requires a dedicated agent to be installed on the target device
Answer: B. Idempotency means Ansible checks the current state of a managed device before applying a task, and if the desired configuration is already present, it simply reports no change needed rather than blindly re-applying the same command again. This allows the same playbook to be safely re-run repeatedly (for drift correction or compliance checking) without unintended side effects from repeated execution.
Q4. Which command is used to execute a full, multi-task Ansible playbook file, as opposed to running a single ad hoc task directly?
A. ansible
B. ansible-playbook
C. ios_config
D. ansible-inventory
Answer: B. The ansible-playbook command is used to execute a full playbook file, running its complete ordered sequence of tasks against the specified target hosts. The simpler ansible command, by contrast, is used to run a single, one-off ad hoc task/module directly against target hosts, without requiring a full playbook file.
Q5. In an Ansible inventory file, what is the purpose of organizing managed devices into named groups, such as branch_routers or core_switches?
A. Groups are purely cosmetic and have no functional effect
B. Groups allow a playbook's hosts field to target a specific, defined set of devices, rather than requiring every individual device to be listed out separately in every playbook
C. Groups automatically encrypt communication with devices in that group
D. Groups are required only for cloud-based devices, not on-premises devices
Answer: B. Organizing managed devices into named inventory groups allows a playbook to specify a single group name in its hosts field (such as branch_routers), targeting every device within that group at once, rather than requiring an administrator to individually list out every single target device by name in every playbook that needs to run against that set of devices.
Q6. A network engineer runs the same Ansible playbook twice in a row against a router that already has the desired hostname configured from the first run. What is the expected result of the second run, assuming the playbook's tasks are properly idempotent?
A. The hostname will be configured a second time, creating a duplicate configuration entry
B. Ansible will report that no change was needed for that task, since the desired state is already in place
C. The second run will fail with an error
D. The router will revert to its previous hostname
Answer: B. Because Ansible's network modules are designed to be idempotent, the second run checks the router's current configuration first, recognizes the desired hostname is already correctly set, and reports that task as requiring no change ("ok" rather than "changed") — rather than blindly re-issuing the same configuration command regardless of the device's actual current state.