Ansible Automation practice questions

A network administrator is comparing configuration management tools and wants to use one that is agentless, uses YAML for playbooks, and communicates with Cisco IOS XE devices over SSH. Which tool best meets these requirements?

Trap 1: Puppet

Puppet typically requires an agent installed on managed nodes, although it can operate in agentless mode with SSH for some modules. However, its manifests are written in a Ruby-based DSL, not YAML, and its primary model is agent-based. For Cisco network devices, Puppet support often relies on dedicated modules and may not be as straightforward for pure SSH-based configuration as the tool described.

Trap 2: Chef

Chef uses Ruby-based recipes and cookbooks, not YAML, and traditionally requires a Chef client agent on managed nodes. While Chef can manage network devices through specific resources, it does not natively use YAML for its configuration definitions. The requirement for agentless operation over SSH with YAML playbooks does not align with Chef's standard architecture.

Trap 3: SaltStack

SaltStack can operate in an agentless mode using SSH, but its default communication model uses a master-minion architecture with agents. Its configuration files are written in YAML, but the typical deployment for network devices often relies on proxy minions rather than direct SSH. The scenario emphasizes agentless SSH and YAML playbooks, which is more characteristic of Ansible's standard workflow.

A
Puppet
Why it fails: Puppet typically requires an agent installed on managed nodes, although it can operate in agentless mode with SSH for some modules. However, its manifests are written in a Ruby-based DSL, not YAML, and its primary model is agent-based. For Cisco network devices, Puppet support often relies on dedicated modules and may not be as straightforward for pure SSH-based configuration as the tool described.
B
Chef
Why it fails: Chef uses Ruby-based recipes and cookbooks, not YAML, and traditionally requires a Chef client agent on managed nodes. While Chef can manage network devices through specific resources, it does not natively use YAML for its configuration definitions. The requirement for agentless operation over SSH with YAML playbooks does not align with Chef's standard architecture.
C
SaltStack
Why it fails: SaltStack can operate in an agentless mode using SSH, but its default communication model uses a master-minion architecture with agents. Its configuration files are written in YAML, but the typical deployment for network devices often relies on proxy minions rather than direct SSH. The scenario emphasizes agentless SSH and YAML playbooks, which is more characteristic of Ansible's standard workflow.
D
Ansible
Ansible is agentless, connecting to devices over SSH, and uses YAML-formatted playbooks to define automation tasks. It includes modules such as ios_config and ios_command that specifically target Cisco IOS XE devices. This matches all stated requirements: no agent, YAML syntax, and SSH communication, making it the correct choice for this scenario.

Question 2easymultiple choice

A network administrator is new to automation and wants to use a simple, agentless tool to push configuration changes to a group of Cisco IOS devices. The administrator prefers a tool that uses YAML for playbooks and does not require installing software on the managed devices. Which tool should the administrator use?

Trap 1: Puppet

Puppet typically requires an agent (Puppet agent) to be installed on managed nodes, although it can operate in agentless mode via SSH for some tasks. However, for network devices like Cisco IOS, Puppet often relies on proxy agents or specialized modules. The requirement for agentless operation and YAML playbooks points more directly to Ansible, as Puppet uses its own DSL (Puppet Language) for manifests, not YAML.

Trap 2: Chef

Chef uses Ruby-based recipes and cookbooks, not YAML playbooks. It also typically requires a Chef agent installed on managed nodes. While Chef can manage network devices via specialized modules, it is not agentless in the same way as Ansible and does not use YAML for its configuration definitions. Therefore, it does not meet the administrator's criteria for simplicity and agentless operation.

Trap 3: SaltStack

SaltStack can operate in an agentless mode using SSH, but it uses YAML for its state files and typically requires a master-minion architecture. While it is powerful, it is more complex to set up than Ansible for simple push-based configuration. The administrator's preference for a simple, agentless tool with YAML playbooks aligns best with Ansible, which is widely used for network automation and has extensive Cisco IOS module support.

A
Puppet
Why it fails: Puppet typically requires an agent (Puppet agent) to be installed on managed nodes, although it can operate in agentless mode via SSH for some tasks. However, for network devices like Cisco IOS, Puppet often relies on proxy agents or specialized modules. The requirement for agentless operation and YAML playbooks points more directly to Ansible, as Puppet uses its own DSL (Puppet Language) for manifests, not YAML.
B
Ansible
Ansible is an agentless automation tool that uses YAML-based playbooks to define tasks. It connects to managed devices over SSH or NETCONF, so no agent software needs to be installed on the Cisco IOS devices. This makes it ideal for simple, push-based configuration management. Ansible modules like 'ios_config' allow network engineers to automate configuration changes across multiple devices efficiently.
C
Chef
Why it fails: Chef uses Ruby-based recipes and cookbooks, not YAML playbooks. It also typically requires a Chef agent installed on managed nodes. While Chef can manage network devices via specialized modules, it is not agentless in the same way as Ansible and does not use YAML for its configuration definitions. Therefore, it does not meet the administrator's criteria for simplicity and agentless operation.
D
SaltStack
Why it fails: SaltStack can operate in an agentless mode using SSH, but it uses YAML for its state files and typically requires a master-minion architecture. While it is powerful, it is more complex to set up than Ansible for simple push-based configuration. The administrator's preference for a simple, agentless tool with YAML playbooks aligns best with Ansible, which is widely used for network automation and has extensive Cisco IOS module support.

Question 3easymultiple choice

A network engineer is new to automation and wants to use a simple, agentless tool to push configuration changes to a group of Cisco IOS XE switches. The engineer prefers to write the automation tasks in YAML and does not want to install any software on the switches. Which tool should be used?

Trap 1: Puppet

Puppet typically requires an agent installed on managed nodes, although it can operate in agentless mode using SSH for some modules. However, its configuration is written in a domain-specific language (DSL) rather than YAML, and it is more complex for simple configuration pushes. The scenario specifies agentless and YAML, which aligns better with Ansible.

Trap 2: SaltStack

SaltStack can operate in an agentless mode using SSH, but its primary configuration is written in YAML for states, yet it often requires a master and minion architecture. For network devices, it may need additional setup. Ansible is more commonly used for agentless network automation with YAML and has extensive Cisco module support.

Trap 3: Chef

Chef uses a Ruby-based DSL for defining configurations and generally requires a Chef client (agent) on managed nodes. While it can use SSH for some tasks, it is not primarily agentless and does not use YAML for playbooks. The engineer's preference for YAML and no agent installation points away from Chef.

A
Puppet
Why it fails: Puppet typically requires an agent installed on managed nodes, although it can operate in agentless mode using SSH for some modules. However, its configuration is written in a domain-specific language (DSL) rather than YAML, and it is more complex for simple configuration pushes. The scenario specifies agentless and YAML, which aligns better with Ansible.
B
Ansible
Ansible is an agentless automation tool that uses YAML-based playbooks to define tasks. It connects to network devices via SSH or other protocols without requiring any software installation on the managed devices. This matches the engineer's requirements: simple, agentless, and YAML-based configuration management for Cisco IOS XE switches.
C
SaltStack
Why it fails: SaltStack can operate in an agentless mode using SSH, but its primary configuration is written in YAML for states, yet it often requires a master and minion architecture. For network devices, it may need additional setup. Ansible is more commonly used for agentless network automation with YAML and has extensive Cisco module support.
D
Chef
Why it fails: Chef uses a Ruby-based DSL for defining configurations and generally requires a Chef client (agent) on managed nodes. While it can use SSH for some tasks, it is not primarily agentless and does not use YAML for playbooks. The engineer's preference for YAML and no agent installation points away from Chef.

Open the full VLAN trunking answer →

Question 4easymultiple choice

A network administrator wants to use a declarative, agentless automation tool to push VLAN configurations to a group of Cisco IOS XE switches. The tool should connect over SSH, use YAML playbooks, and require no software installation on the switches. Which tool best fits these requirements?

Trap 1: SaltStack with minions deployed on each switch and states written…

SaltStack typically uses a master-minion architecture where minions run on managed nodes. Deploying a Salt minion on a Cisco IOS XE switch is not supported. Although Salt states can be written in YAML, the agent requirement disqualifies it. This option fails the agentless requirement central to the scenario.

Trap 2: Chef Infra Client installed on each switch with recipes written in…

Chef requires the Chef Infra Client agent to be installed on managed nodes. Cisco IOS XE switches do not support installing arbitrary agents. Chef recipes are written in Ruby DSL, not YAML. This option fails the agentless and YAML criteria and is not a viable approach for IOS XE switches.

Trap 3: Puppet with the Cisco IOS module installed on each switch

Puppet typically requires an agent on managed nodes, or at least a master-agent architecture. While it can be agentless in some proxy modes, the standard model installs a Puppet agent on the device, which is not possible on most Cisco IOS XE switches. It also uses its own DSL rather than YAML playbooks, so it does not meet the stated criteria.

A
SaltStack with minions deployed on each switch and states written in YAML
Why it fails: SaltStack typically uses a master-minion architecture where minions run on managed nodes. Deploying a Salt minion on a Cisco IOS XE switch is not supported. Although Salt states can be written in YAML, the agent requirement disqualifies it. This option fails the agentless requirement central to the scenario.
B
Chef Infra Client installed on each switch with recipes written in Ruby
Why it fails: Chef requires the Chef Infra Client agent to be installed on managed nodes. Cisco IOS XE switches do not support installing arbitrary agents. Chef recipes are written in Ruby DSL, not YAML. This option fails the agentless and YAML criteria and is not a viable approach for IOS XE switches.
C
Puppet with the Cisco IOS module installed on each switch
Why it fails: Puppet typically requires an agent on managed nodes, or at least a master-agent architecture. While it can be agentless in some proxy modes, the standard model installs a Puppet agent on the device, which is not possible on most Cisco IOS XE switches. It also uses its own DSL rather than YAML playbooks, so it does not meet the stated criteria.
D
Ansible with the cisco.ios collection and an inventory of the switches
Ansible is agentless, connecting over SSH, and uses YAML playbooks. The cisco.ios collection provides modules like ios_vlan and ios_config to manage IOS XE devices. No software needs to be installed on the switches beyond SSH and proper credentials. This matches all requirements: declarative, agentless, YAML-based, and SSH connectivity.

Question 5easymultiple choice

A network administrator is new to automation and wants to start using Ansible to manage a group of Cisco IOS XE switches. The administrator has installed Ansible on a Linux control node and created an inventory file listing the switches. The administrator now needs to create a playbook that will gather facts from the switches and display them. Which Ansible module should the administrator use in the playbook to collect operational facts from the Cisco IOS XE devices?

Trap 1: ios_config

The ios_config module is used to manage configuration lines on IOS devices, such as applying ACLs or interface settings. It is not intended for gathering facts. Using it to collect operational data would be ineffective and could inadvertently change configurations. The administrator needs a read-only module for facts, so ios_config is incorrect.

Trap 2: ios_command

The ios_command module is used to execute arbitrary operational commands on IOS devices and return the output. While it can be used to run show commands, it does not automatically gather structured facts. The administrator would have to manually parse the output. For fact gathering, ios_facts is the purpose-built module that returns structured data.

Trap 3: setup

The setup module is a generic Ansible module that gathers facts from Linux hosts, not network devices. It runs on the target host and collects system information. For Cisco IOS XE devices, which are network appliances, the setup module is not applicable. The administrator must use a network-specific module like ios_facts to retrieve device facts.

A
ios_facts
The ios_facts module is specifically designed to collect facts from Cisco IOS devices, including IOS XE. It gathers information such as hostname, version, interfaces, and hardware details. Using this module, the administrator can retrieve operational data and display it using the debug or other output mechanisms. It is the correct choice for fact gathering on Cisco IOS XE platforms.
B
ios_config
Why it fails: The ios_config module is used to manage configuration lines on IOS devices, such as applying ACLs or interface settings. It is not intended for gathering facts. Using it to collect operational data would be ineffective and could inadvertently change configurations. The administrator needs a read-only module for facts, so ios_config is incorrect.
C
ios_command
Why it fails: The ios_command module is used to execute arbitrary operational commands on IOS devices and return the output. While it can be used to run show commands, it does not automatically gather structured facts. The administrator would have to manually parse the output. For fact gathering, ios_facts is the purpose-built module that returns structured data.
D
setup
Why it fails: The setup module is a generic Ansible module that gathers facts from Linux hosts, not network devices. It runs on the target host and collects system information. For Cisco IOS XE devices, which are network appliances, the setup module is not applicable. The administrator must use a network-specific module like ios_facts to retrieve device facts.

Question 6hardmultiple choice

A network automation team is using Ansible to push configuration changes to a fleet of Cisco IOS XE devices. The playbook uses the 'ios_config' module with the 'backup: yes' option. During a recent run, the playbook failed on one device due to a syntax error in the configuration lines. The team wants to ensure that if a failure occurs, the device automatically reverts to its previous configuration without manual intervention. Which Ansible feature should be used to achieve this?

Trap 1: Use the 'ios_config' module with the 'rollback' parameter set to…

The 'ios_config' module does not have a 'rollback' parameter. While Cisco IOS XE supports configuration rollback via the 'configure replace' command, Ansible's ios_config module does not natively expose this as a simple parameter. The team would need to implement rollback using other methods, such as the 'cli_command' module with 'configure replace'.

Trap 2: Set the 'ansible_command_timeout' to a higher value to prevent…

Increasing the command timeout only affects how long Ansible waits for a command to complete. It does not provide rollback capability. If a syntax error occurs, the device will reject the configuration, and the timeout setting will not revert changes. This option misinterprets the cause of failure as a timeout rather than a configuration error.

Trap 3: Enable 'config' mode with the 'save_when' parameter set to…

'save_when: modified' saves the running configuration to startup when changes are made, but it does not provide automatic rollback on failure. If the configuration fails, the running configuration may be partially applied. This option does not revert changes; it only persists them, which could worsen the situation by saving a broken configuration.

A
Use the 'ios_config' module with the 'rollback' parameter set to 'yes'.
Why it fails: The 'ios_config' module does not have a 'rollback' parameter. While Cisco IOS XE supports configuration rollback via the 'configure replace' command, Ansible's ios_config module does not natively expose this as a simple parameter. The team would need to implement rollback using other methods, such as the 'cli_command' module with 'configure replace'.
B
Implement a 'block' and 'rescue' section in the playbook to run a rollback task if the configuration fails.
Ansible's block/rescue structure allows error handling. The configuration task can be placed in a block, and if it fails, the rescue section can execute a rollback task, such as using 'cli_command' to run 'configure replace' with a previously saved configuration file. This provides automatic rollback without manual intervention, directly addressing the requirement.
C
Set the 'ansible_command_timeout' to a higher value to prevent premature failure.
Why it fails: Increasing the command timeout only affects how long Ansible waits for a command to complete. It does not provide rollback capability. If a syntax error occurs, the device will reject the configuration, and the timeout setting will not revert changes. This option misinterprets the cause of failure as a timeout rather than a configuration error.
D
Enable 'config' mode with the 'save_when' parameter set to 'modified'.
Why it fails: 'save_when: modified' saves the running configuration to startup when changes are made, but it does not provide automatic rollback on failure. If the configuration fails, the running configuration may be partially applied. This option does not revert changes; it only persists them, which could worsen the situation by saving a broken configuration.

Open the full BGP breakdown →

Question 7hardmultiple choice

A large enterprise uses a centralized automation platform based on Ansible Tower to manage its network infrastructure. The network consists of 500 Cisco IOS XE routers and switches distributed across multiple sites. The automation team has created a playbook that configures BGP peerings on all devices. The playbook uses the ios_bgp module. Recently, during a maintenance window, the playbook was run against a subset of devices that were supposed to be upgraded to a new IOS XE version. However, after the run, several devices lost their BGP configurations entirely. The team discovers that the new IOS XE version introduced a new BGP configuration model that is not fully compatible with the ios_bgp module's expected CLI commands. The playbook failed silently on those devices, and the existing BGP configuration was removed. The team needs to prevent this from happening in future maintenance windows. Which action should be taken?

Trap 1: Implement idempotency checks in the playbook using the 'check_mode'…

Check mode is a dry-run that computes and reports what would change without actually applying the configuration. It does not test whether the ios_bgp module's internal code matches the device's OS version; module incompatibility errors occur during execution, and check mode may still fail or bypass the relevant code paths. The root issue here is module/OS mismatch, not a lack of idempotency checks.

Trap 2: Set 'gather_facts: no' in the playbook to speed up execution and…

Disabling fact collection with gather_facts: no prevents Ansible from learning critical attributes like the device's operating system version, which is exactly the information needed to implement a version-aware workaround. The failure stems from the module's execution on the newer OS, not from the overhead of gathering facts, so removing it both eliminates the data needed for conditional logic and misses the actual problem.

Trap 3: Replace the ios_bgp module with the ios_config module and use raw…

Falling back to ios_config with raw CLI commands only shifts the problem rather than solving it. If the BGP command syntax has changed in the new IOS version, the raw commands will fail identically, and, even if they work, the approach becomes non-idempotent unless extra logic is added to compare running config. The robust solution is to conditionally use the appropriate module based on the device's OS version, preserving idempotency and adaptability.

A
Add a pre-task that validates the device's OS version and conditionally applies the appropriate module or command set
Running a pre-task that inspects ansible_net_version and then uses conditional logic to select either the native ios_bgp module or an alternative module (e.g., ios_config) ensures that the playbook aligns with the device's supported API and syntax. This avoids silent failures caused by module versions that do not recognize the running IOS release, and it is the recommended pattern for maintaining idempotent, OS-aware automation across a heterogeneous fleet.
B
Implement idempotency checks in the playbook using the 'check_mode' option
Why it fails: Check mode is a dry-run that computes and reports what would change without actually applying the configuration. It does not test whether the ios_bgp module's internal code matches the device's OS version; module incompatibility errors occur during execution, and check mode may still fail or bypass the relevant code paths. The root issue here is module/OS mismatch, not a lack of idempotency checks.
C
Set 'gather_facts: no' in the playbook to speed up execution and avoid version detection issues
Why it fails: Disabling fact collection with gather_facts: no prevents Ansible from learning critical attributes like the device's operating system version, which is exactly the information needed to implement a version-aware workaround. The failure stems from the module's execution on the newer OS, not from the overhead of gathering facts, so removing it both eliminates the data needed for conditional logic and misses the actual problem.
D
Replace the ios_bgp module with the ios_config module and use raw CLI commands for BGP configuration
Why it fails: Falling back to ios_config with raw CLI commands only shifts the problem rather than solving it. If the BGP command syntax has changed in the new IOS version, the raw commands will fail identically, and, even if they work, the approach becomes non-idempotent unless extra logic is added to compare running config. The robust solution is to conditionally use the appropriate module based on the device's OS version, preserving idempotency and adaptability.