Cisco IOS XE Command Collection with Ansible: A CCNA v2.0 Lab
What CCNA v2.0 changes in the Ansible objective
Cisco’s upcoming CCNA 200-301 v2.0 includes a hands-on-oriented objective, 5.5, to use configuration management mechanisms such as Ansible to execute commands. This differs from v1.1, which asks candidates to recognize capabilities of tools such as Ansible and Terraform. The aim is network operations literacy: use a permitted connection to run an appropriate observation command, understand what comes back, and distinguish that from a configuration write. It is not a requirement to build an enterprise orchestration system.
As of October 2026, v1.1 remains active through February 2, 2027; v2.0 begins February 3 under the same exam code. Read the official v2.0 objectives when booking the later exam and do not mislabel the new command-execution task as already required by the active v1.1 outline.
Identify the control node, inventory and network session
Ansible runs from a control node holding playbooks, inventory and required collections. The managed IOS or IOS XE device offers a management address and access mechanism, usually an authorized SSH CLI for a supported network connection. A lab inventory can group devices under cisco_lab, while variables specify the appropriate platform and connection. Neither naming a device in the inventory nor running an Ansible task overrides the device’s normal authentication and privilege policy.
The cisco.ios.ios_command documentation says this module can send operational commands to a remote Cisco IOS node over a compatible connection such as network_cli. It is part of the cisco.ios collection, which may need to be installed separately. Confirm supported versions, management VRF and permissions. Never include reusable production credentials in a public article, version-control repository or AI prompt.
A read-only command is different from a device change
The ios_command module can run observations such as show version and show ip interface brief. Its output describes what the device reported. It is not intended to enter configuration mode and apply a changed interface policy. Modules such as ios_config have distinct configuration semantics and require explicit authorization, backups and verification. The CCNA task can be learned with read-only commands and without making unauthorized network changes.
Choose an observation that matches a real troubleshooting question. A successful show version result does not prove a client can reach DNS. A physically up interface does not prove that the correct VLAN is carried across a trunk. Ansible automates reading a chosen device state; the networking knowledge decides whether the result is meaningful.
A safe sample playbook for a fictional lab
This example contains no credentials or real device output. It assumes an authorized inventory group named cisco_lab with a compatible connection and privilege setup. Before running any command, verify that its target and read-only nature are appropriate for the lab.
---
- name: Collect IOS operational evidence
hosts: cisco_lab
gather_facts: false
tasks:
- name: Read device state
cisco.ios.ios_command:
commands:
- show version
- show ip interface brief
register: ios_state
- name: Inspect captured lines
ansible.builtin.debug:
var: ios_state.stdout_lines
The commands sequence requests two operations. register stores the returned result, and stdout_lines provides line-oriented output for inspection. An engineer must still verify that the result came from the intended device and that its observation answers the original question. The playbook has not been run by Exam-Labs to generate any claimed successful IOS output.
Read connection errors and command results precisely
Management-DNS failure, SSH connection refusal, invalid credentials, insufficient command privileges and an unsupported IOS command are separate failure cases. Check which stage failed before changing anything. A failed management login is not proof that the user data path is down; a stale inventory hostname can cause an automation failure even while the network forwards ordinary client traffic. Do not bypass access controls to make a tutorial run.
The command module can include a wait_for condition to examine returned output across retries. Such a condition verifies only what its expression tests. Seeing the word IOS in show version does not establish that OSPF neighbors are healthy. A good condition should be narrow and follow a documented operational expectation, not a made-up pass/fail rule attached to every command. Be careful not to log secrets or unneeded full configuration data while investigating an error.
Turn a returned interface summary into network reasoning
Imagine a lab client on VLAN 20 failing to reach a remote service. A permitted Ansible task can collect relevant interface and route data, but the operator must establish the intended client subnet, switch trunk, gateway, next hop and return path. A device reporting an interface as administratively up is only one observation. It cannot rule out a missing VLAN, incorrect ACL or a service that has stopped responding.
The CCNA network fault-isolation guide shows how to connect observations across layers. Reproduce a known-good topology and introduce one controlled failure. Compare the real output before and after, label device identity and timestamp, and record which observation changed. A copied or invented transcript is not equivalent to actual lab verification.
Contrast command orchestration and declared resource state
Ansible can orchestrate device-status collection or configuration tasks. Terraform typically models infrastructure resources using providers and managed state, with a plan indicating proposed changes. They solve different workflow problems and have different failure and rollback considerations. The Terraform concepts for CCNA article explains why provider state and plan review matter.
For v1.1, recognizing these capabilities follows the published blueprint. For v2.0, a candidate should also understand how an Ansible task executes a command and where its output is returned. This comparison is about which task requires a read versus a planned change, not about inventing a universal hierarchy of automation tools.
Inventory connection settings matter. For an IOS lab, a compatible ansible_connection such as ansible.netcommon.network_cli and ansible_network_os such as cisco.ios.ios tell Ansible which network transport and platform behavior to use. The inventory format and supported settings vary by collection release. An SSH failure, incorrect device-family setting or management-interface ACL can prevent command execution even though the playbook’s YAML syntax is valid. Diagnose these failures separately before changing host or switch configuration.
Tie returned data to the operational question. An interface overview may show an address and administrative or line status, but does not prove a VLAN is allowed on a trunk. A routing display may contain an expected prefix but not prove a remote service works. After task execution, compare the result with the intended topology, then choose a further read-only check when evidence remains incomplete. Avoid interpreting “task successful” as a declaration that all clients have network service. Remember that two identical commands executed at different times or against different interfaces can show different valid states.
An Ansible task can check expected output text or other conditions, but a wait_for expression is only as useful as its condition. Matching “up” in an unrelated line can produce false confidence. Inspect the actual returned structure, tie the condition to a specific interface or route, handle absent data, and document that the example is instructional rather than a tested Cisco exam simulation. Scope inventory groups narrowly so an incorrect playbook target does not run across unrelated devices.
Finish with evidence tied to the correct Cisco objective
A completed lab has an inventory of permitted devices, selected commands, actual results, an explanation of what each result proves and a record of missing evidence. If the test cannot connect, document the error instead of fabricating output. If it connects but reveals no fault, choose another justified observation rather than assume everything is healthy. These are the same habits needed when troubleshooting without Ansible.
Use third-party Cisco 200-301 practice questions only to identify weaknesses, then verify the relevant command behavior in a supported lab. For the upcoming v2.0 objective 5.5, the goal is controlled network command execution with interpretation and scope awareness. For the still-active v1.1 exam, the objective stays recognition of capabilities. Keeping those versions separate avoids misleading study plans.
