350-401 Automation Practice Question
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?
⚠ Common exam trap
Cisco often tests the misconception that idempotency (check_mode) or simply using raw CLI commands (ios_config) solves version incompatibility, when the real solution is version-aware conditional logic to handle model changes.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add a pre-task that validates the device's OS version and conditionally applies the appropriate module or command set
It directly addresses the root cause: the new IOS XE version uses an incompatible BGP configuration model. By adding a pre-task that validates the OS version, the playbook can conditionally apply the correct module (e.g., ios_bgp for older versions or a different module/CLI for the new model), preventing silent failures and configuration loss. This ensures the automation adapts to version-specific changes, maintaining idempotency and safety.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Add a pre-task that validates the device's OS version and conditionally applies the appropriate module or command set
Why this is correct
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.
- ✗
Implement idempotency checks in the playbook using the 'check_mode' option
Why it's wrong here
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.
- ✗
Set 'gather_facts: no' in the playbook to speed up execution and avoid version detection issues
Why it's wrong here
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.
- ✗
Replace the ios_bgp module with the ios_config module and use raw CLI commands for BGP configuration
Why it's wrong here
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.
Go deeper
Related to this question
About these practice questions
One of 1,923 original 350-401 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-401 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 350-401 exam.