Infrastructure automation with Ansible solves the problem of manually configuring hundreds or thousands of network devices (routers, switches, firewalls) and servers one at a time. For the 200-901 exam, you need to understand how Ansible replaces error-prone manual commands with repeatable, version-controlled automation that executes the same configuration on every device, every time.
Jump to a section
A simple way to picture Infrastructure Automation with Ansible
A busy restaurant kitchen on a Saturday night. The head chef has a stack of orders coming in — tables requesting steaks, salads, pastas, each with custom modifications like 'no onions' or 'medium rare'.
Without a system, chaos erupts. The chef scribbles notes on napkins, runs to the fridge to check stock, shouts instructions to the line cooks, and constantly checks if the grill is free. Every new order requires manual intervention — reading the slip, walking to the walk-in cooler, remembering which cook is on which station.
Ansible is like that head chef who, instead of running around, uses a master ordering system. The head chef writes a single set of instructions — a 'playbook' — that says: 'For every steak order, season, grill to medium rare, rest for 3 minutes, plate with herb butter.' A 'play' in the playbook is like one step: 'season the steak.' The 'inventory' is the list of all the kitchen stations — the grill, the sauté station, the salad prep — each with its own capabilities. Ansible connects to each station — each 'managed node' — over a secure network connection (SSH) and executes the instructions without needing a human to run to each station. It doesn't install any permanent software on the stations — it's 'agentless,' like a chef who doesn't need to install a new app on every sous chef's phone to give them orders. If a station is down (the grill is broken), Ansible doesn't just crash — it skips that step and reports the failure. The result: consistent, repeatable, hands-free kitchen operations, every Saturday night.
Ansible is an open-source automation tool that IT professionals use to configure systems, deploy software, and orchestrate advanced workflows. The core idea is simple: instead of logging into each device individually and typing commands (which takes hours and invites mistakes), you write a single set of instructions that Ansible carries out for you.
At its heart, Ansible is 'agentless.' That means, unlike some other automation tools, you do not need to install any special software — called an 'agent' — on the devices you want to manage. Ansible communicates with them over standard, secure network protocols. For Linux servers, it typically uses SSH (Secure Shell). For network devices like Cisco routers or switches, it uses SSH as well, or sometimes API calls over HTTPS. This makes Ansible very easy to adopt because you don't need to change the devices themselves — they just need to be reachable over the network.
The three foundational concepts in Ansible are:
Control node: This is the machine where Ansible is installed. It can be your laptop, a dedicated server, or a virtual machine. From here, you write your automation instructions and push them out.
Managed nodes: These are the devices Ansible configures — the routers, switches, firewalls, servers, cloud instances. They receive and execute the instructions.
Inventory: A file (usually in INI or YAML format) that lists all your managed nodes. It can group them by function — for example, all 'core-routers,' all 'branch-switches,' all 'web-servers.' You define the inventory once, and Ansible uses it to know which devices to target.
The instructions themselves are written in 'playbooks.' A playbook is a file written in YAML (a human-readable data serialisation language — think of it like a simpler, cleaner version of JSON). A playbook contains one or more 'plays.' Each play targets a specific group of managed nodes (from your inventory) and defines a series of 'tasks' to run on them. Each task calls a single 'module.'
Modules are the actual tools Ansible uses to do work. They are small programs that perform specific actions — for example, the 'ios_config' module applies configuration to a Cisco IOS device; the 'copy' module copies a file; the 'service' module starts or stops a service. Modules are idempotent — this fancy word means running the same module multiple times produces the same result. If a configuration is already in place, the module does nothing new. This prevents accidental duplicates or errors.
Let us walk through a simple real example. Imagine you have ten Cisco switches that all need a new VLAN (Virtual Local Area Network) configured. Without automation, you would SSH into each switch, enter configuration mode, type 'vlan 100', name it, and exit — repeating the exact same process ten times. With Ansible, you write a playbook that looks something like this (in plain language):
Play: 'Configure VLAN 100 on all switches'
Target: group 'access-switches' from the inventory
Tasks:
- Use the 'ios_vlan' module - Provide the vlan_id: 100 - Provide the name: 'Engineering'
You run the playbook from the control node. Ansible reads the inventory, connects by SSH to each switch in 'access-switches,' executes the module idempotently (only creating the VLAN if it does not already exist), and reports back whether the change was successful on each device. The entire operation takes seconds, and the results are consistent across all ten switches.
What does Ansible replace? It replaces the manual, error-prone process of 'crafting commands' on each device. It also replaces the need to remember the exact syntax for every vendor's operating system — because Ansible modules abstract that away. You tell Ansible 'I want this VLAN' and Ansible knows how to translate that into Cisco, Juniper, or Arista commands.
Why was Ansible created? The creator, Michael DeHaan, wanted a tool that was simpler than existing configuration management tools like Puppet or Chef. Those tools require learning a custom language (like Ruby DSL) and usually need an agent installed. Ansible uses YAML — which is easy to read even for non-programmers — and requires no agents. The philosophy is 'batteries included but swappable' — it ships with hundreds of built-in modules for common tasks.
For the 200-901 exam, you should know that Ansible is declarative in nature — you declare the desired end state (e.g., 'VLAN 100 should exist'), and Ansible makes it so. You should also understand that playbooks are executed in order, top to bottom, and that you can use variables and conditionals to make automation smarter.
In summary, Ansible makes infrastructure automation accessible by using:
YAML playbooks that are easy to write and read
An inventory to organise your devices
Agentless push-based model (control node pushes configs to managed nodes)
Idempotent modules that do not cause side effects on repetition
This replaces the old 'snowflake' pattern where every device had unique manual configuration, leading to drift and hard-to-debug issues. Instead, you get consistent, repeatable, auditable infrastructure.
Install Ansible on the Control Node
You first set up a control node — typically a Linux server or a VM. Ansible is installed via package managers like 'apt' or 'yum', or using Python's pip. This machine will be the brain of the operation, sending commands to all managed devices.
Create an Inventory File
You define an inventory file that lists all your managed nodes — the routers, switches, servers you want to automate. You can group them logically, e.g., [routers] or [branch-switches]. This tells Ansible which devices exist and how to connect to them (IP addresses, SSH credentials).
Write a Playbook in YAML
You create a text file with a .yml extension. Inside, you define one or more plays. Each play specifies the target group (e.g., routers), and a list of tasks. Each task calls a module (like ios_config) with parameters. This YAML file is your automation blueprint.
Run the Playbook
You execute the playbook using the 'ansible-playbook' command followed by the filename. Ansible reads the inventory, connects to each managed node in the targeted group via SSH, and executes each task in order. It reports the results: success, failure, or unreachable.
Verify and Iterate
After the run, you check the output for errors. If a device was unreachable, you troubleshoot connectivity. If a module failed, you adjust the playbook. Ansible supports a '--check' flag for dry runs to preview changes before applying them, allowing safe iteration.
Consider a medium-sized company called 'FinTech Connect' that runs 50 Cisco Catalyst switches across three office floors, plus 20 routers connecting branch offices. The network team receives a security directive: 'Disable Telnet access on all network devices and enable SSH version 2 only.' Doing this manually would require logging into 70 devices, entering enable mode, finding the right configuration lines, typing 'transport input ssh,' and verifying.
A junior network engineer named Maria is assigned the task. She has never used Ansible before but has read the basics. Here is how she would approach it in a real business context:
Maria’s first step is to set up the control node. She installs Ansible on a lightweight Linux virtual machine (VM) in the data centre. She ensures this VM has network access to all 70 devices. She creates an inventory file that groups devices:
[core-switches] — the 10 main distribution switches
[access-switches] — the 40 floor switches
[branch-routers] — the 20 remote routers
She writes a playbook called 'remove-telnet-ssh.yml'. The playbook has two plays. The first play targets all devices in 'core-switches' and 'access-switches' (combined group) and uses the 'ios_config' module with lines to disable telnet and enforce SSH. The second play targets 'branch-routers' and uses the 'ios_config' module with slightly different syntax because those run a different IOS version.
Before running it live, Maria uses the '--check' flag (dry run). This tells Ansible to simulate the changes without actually applying them. The output shows which lines would be changed on each device. She reviews it and catches a mistake — one router group needs an extra line for SSH timeout. She fixes the inventory grouping and re-runs the check.
Confident now, she runs the playbook for real. Within 90 seconds, all 70 devices are updated. Ansible logs the output: 'changed=70, failed=0, unreachable=0'. She saves this as proof of compliance for the auditors.
A month later, a new security policy requires rotating the SSH keys (public/private key pairs used for authentication). Rather than manually generating 70 new key pairs and copying them, Maria writes a new playbook that:
Generates a new RSA key pair on each device using the 'ios_system' module
Uses the 'ios_config' module to configure the new key as the active one
Verifies connectivity using the 'net_ping' module
This entire operation takes 2 minutes and is completely documented in the playbook itself — meaning anyone on the team can repeat it or audit it.
In the real world, IT professionals use Ansible to:
Apply consistent security baselines across hundreds of devices
Deploy software updates or firmware upgrades to network hardware
Automate the provisioning of new branch offices — spin up switches, assign VLANs, set up routing protocols
Integrate with CI/CD pipelines, where every code change triggers an Ansible run that updates the network to match the new application requirements
Perform compliance checks — run a playbook daily that checks if any device has Telnet enabled or an outdated OS version, and report deviations
The key insight is that Ansible is not just about speed — it is about reliability and repeatability. A human operator might type a command wrong on one device out of 70. Ansible executes the exact same operations every time. In regulated industries (finance, healthcare), this auditability is often a regulatory requirement.
The 200-901 exam tests your knowledge of Ansible concepts, playbook structure, and inventory management at a conceptual level — you will not be asked to write a full playbook from scratch, but you must understand the components and how they fit together. The exam is vendor-agnostic in its automation coverage, so focus on general Ansible principles rather than Cisco-specific command syntax.
What they test heavily:
The three core Ansible components: control node, managed nodes, inventory. You need to know that the control node runs the playbook, the managed nodes are the targets, and the inventory defines the groups.
Agentless architecture: This is a favourite exam point. Ansible does not require an agent on the managed node — it uses SSH or APIs. Compare this with Puppet (which requires an agent) if a question contrasts the two.
Playbook structure: You should be able to identify a YAML playbook snippet and know that it contains plays, which contain tasks, which call modules. Know that 'hosts:' defines the target group, 'tasks:' defines the list of actions, and 'name:' is just a human-readable label.
Idempotency: The exam loves this term. Understanding that running the same playbook twice does not cause duplicate changes unless the configuration has drifted is important.
Modules: You do not need to memorise hundreds of modules, but you should recognise that 'ios_config', 'ios_command', 'copy', 'service' are common ones. The exam may ask what a specific module does in a multiple-choice question.
Inventory files: Understand the INI and YAML formats. Know that you can define groups (like '[routers]') and set variables per host or per group.
Traps to watch out for:
Confusing 'control node' with 'managed node': The control node is where Ansible runs; the managed nodes are the devices it configures. A question might say 'Ansible is installed on the router' — that is wrong unless they are describing a specific edge case.
Believing Ansible is a programming language: Ansible uses YAML — a data format — not a programming language. It does have loops and conditionals, but it is not Turing-complete like Python.
Mixing up push vs pull model: Ansible is push-based — the control node sends configs to managed nodes. Puppet is typically pull-based — managed nodes pull configs from a master. This is a classic comparison question.
Thinking 'idempotent' means 'does nothing': It means 'has the same effect whether run once or multiple times.' The module still checks the state — it just does not repeat changes if the desired state is already achieved.
Concepts to memorise for multiple-choice questions:
YAML: Used for playbooks and inventory files
SSH: Default transport for network devices
Module: The unit of work in Ansible (e.g., ios_config applies configuration lines)
Playbook: A YAML file containing one or more plays
Play: A mapping between a host group and the tasks to run on it
Task: A single call to a module
Inventory: A file listing managed nodes
Group: A logical collection of managed nodes (e.g., all routers)
Variables: Values that can be substituted in playbooks (e.g., {{ vlan_id }})
Facts: Information Ansible gathers about managed nodes (like OS version, hardware details)
The exam may present you with a scenario: 'A network engineer wants to configure SNMP on 100 routers. Which Ansible approach should they use?' The correct answer is to write a playbook that targets the 'routers' group and uses the 'ios_config' module or a dedicated SNMP module. A trap answer might suggest writing a script in Python to SSH into each one — that is also possible, but the exam is testing knowledge of Ansible as the automation tool.
Finally, be aware that the exam expects you to understand basic troubleshooting: if a playbook fails with 'unreachable,' the control node cannot connect to the managed node — likely a network connectivity issue or wrong IP in the inventory.
Ansible is agentless — it does not require any software installed on managed nodes, only SSH or API access.
Playbooks are written in YAML and contain one or more plays, each targeting a group of hosts from the inventory.
Modules are idempotent — running the same task multiple times produces the same result without causing unintended changes.
The control node is the machine where Ansible is installed and from which playbooks are executed; managed nodes are the devices being configured.
Inventory files organise managed nodes into groups (e.g., routers, switches) and allow setting variables per host or group.
Ansible uses a push model — the control node pushes configuration to managed nodes, unlike tools like Puppet that use a pull model.
Idempotency is the property that ensures consistent state: if a device already has the desired configuration, the module makes no changes.
Playbooks are executed sequentially from top to bottom, and each task is run against all hosts in the targeted group before moving to the next task.
These come up on the exam all the time. Here's how to tell them apart.
Ansible (Push Model)
Control node pushes configuration to managed nodes
No agent required on managed nodes
Uses SSH or API for communication
Puppet (Pull Model)
Managed nodes pull configuration from a master server
Requires an agent installed on each managed node
Uses its own protocol for communication
Playbook (YAML)
Declarative — describes desired end state
Idempotent — safe to run repeatedly
Human-readable, non-programming language
Script (e.g., Python or Bash)
Procedural — describes step-by-step instructions
Not idempotent — running again may cause duplication
Requires programming knowledge
Inventory (INI format)
Simple key-value file with groups in brackets
Uses plain text with minimal formatting
Less flexible for complex variables
Inventory (YAML format)
Uses YAML syntax with nested structures
Allows more complex variable definitions and hierarchies
Preferred for larger or more dynamic environments
Mistake
Ansible requires you to install an agent on every device you want to manage.
Correct
Ansible is agentless — it communicates over SSH or APIs without needing any extra software on the managed device.
Many beginners come from tools like Puppet or Chef which do require agents. The word 'agentless' is a key differentiator and is often misunderstood.
Mistake
Ansible playbooks are written in Python.
Correct
Ansible playbooks are written in YAML — a human-readable data serialisation language. Python is used for writing custom modules, but playbooks themselves are YAML.
Beginners see 'Ansible is written in Python' and assume they must write Python. The exam tests recognition of YAML for playbooks.
Mistake
Ansible only works for Linux servers, not network devices.
Correct
Ansible works with any device that supports SSH or an API — including Cisco routers, switches, firewalls, and many other vendors' networking gear.
The exam's network automation focus confuses learners who associate Ansible only with server configuration. Modules like 'ios_config' are network-specific.
Mistake
Once you run an Ansible playbook, it permanently changes the device's configuration and you cannot reverse it.
Correct
Ansible applies changes based on what the playbook says. You can write a separate playbook to revert changes, and because playbooks are text files, you can use version control (like Git) to track and roll back.
This misconception comes from fear of automation breaking things. The exam tests understanding that playbooks are controllable and reversible, not one-way.
Mistake
Ansible is useless if you only have a few devices — you must manually configure them anyway.
Correct
Even with a few devices, Ansible saves time by ensuring consistency and providing an auditable record of changes. It also reduces human error, which is valuable regardless of scale.
Beginners think automation is only for large scale. The exam tests the principle that automation improves reliability at any scale.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you do not need to be a programmer. Playbooks are written in YAML, which is a simple data format designed to be readable. You just need to understand basic concepts like lists and dictionaries.
Yes, Ansible can manage any device that supports SSH (for Linux and network gear) or WinRM (for Windows). There are specific modules for each platform, like ios_config for Cisco and win_feature for Windows.
A playbook is the overall automation script containing plays and tasks. A module is the individual tool that performs a specific action, like configuring a VLAN or copying a file. A playbook calls modules to do the work.
You can use Ansible Vault to encrypt sensitive data like passwords directly in the playbook or inventory file. You can also pass credentials via environment variables or use SSH keys instead of passwords.
Idempotent means that running the same module multiple times will always bring the system to the same desired state. If the state is already correct, the module makes no changes. This prevents accidental duplication or errors.
Ansible does not have a built-in rollback feature, but you can write a separate playbook that applies a known-good configuration. Using version control for your playbooks allows you to revert to an earlier version and reapply it.
You've finished Infrastructure Automation with Ansible. Continue through the 200-901 study guide to build a complete picture of the exam.
Done with this chapter?