Ansible Idempotency for VLAN Configuration
A network engineer is automating the deployment of VLANs across multiple switches using Ansible. The playbook fails with an error indicating that the VLAN ID already exists on one of the switches. Which approach should the engineer use to ensure the playbook completes without errors?
Quick Answer
The correct approach is to use an idempotent Ansible module that checks for existing VLANs before creating them. This is because Ansible idempotency for VLAN configuration ensures that a module like `ios_vlan` will first query the current state of the network device; if the VLAN ID already exists, the module reports an “ok” status and makes no change, preventing the failure and allowing the playbook to complete cleanly. On the Cisco DevNet Associate 200-901 exam, this concept tests your understanding of declarative automation versus imperative scripting—a common trap is to write a playbook that blindly creates resources without checking state, which violates idempotency principles. Remember that idempotent modules are the foundation of reliable network automation, as they guarantee consistent results across multiple runs. Memory tip: think “check before create” to avoid the “already exists” error.
⚠ Common exam trap
Cisco often tests the concept of idempotency in automation tools like Ansible, and the trap here is that candidates may think 'ignore_errors' is a valid workaround for configuration conflicts, when in fact it only hides failures without ensuring the desired state is achieved.
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
✓
Use an idempotent Ansible module that checks for existing VLANs before creating them.
Ansible's idempotent modules, such as `ios_vlan` for Cisco IOS devices, are designed to check the current state of the device before making changes. If the VLAN already exists, the module will report 'ok' and not attempt to create it again, preventing the error and ensuring the playbook completes successfully. This aligns with Ansible's best practice of writing idempotent playbooks that produce the same result regardless of how many times they are run.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Modify the playbook to skip switches where the VLAN already exists.
Why it's wrong here
Skipping switches leaves the VLAN undeployed on those devices, so the automation silently produces an inconsistent configuration. Conditional task execution suits deliberately excluding hosts, but here every switch must end with the VLAN present, so the task must be made idempotent instead.
- ✗
Remove the VLAN from all switches before creating it again.
Why it's wrong here
Deleting the VLAN first causes an outage on every switch already carrying production traffic on it, and the playbook may still fail mid-run. Pre-removal suits lab rebuilds or clean-slate provisioning, not incremental rollout where existing VLANs must remain untouched while missing ones are created.
- ✓
Use an idempotent Ansible module that checks for existing VLANs before creating them.
Why this is correct
Idempotent modules such as ios_vlan query existing VLAN configuration before applying changes, so a pre-existing VLAN ID produces no error and no duplicate. This satisfies the requirement that the playbook complete successfully across switches with differing current state.
- ✗
Add ignore_errors: yes to the VLAN creation task.
Why it's wrong here
ignore_errors lets the task report success while the VLAN remains absent on the failing switch, hiding a real configuration gap. Suppressing errors suits non-critical cleanup tasks; here the VLAN must actually exist, so the module needs idempotent state handling rather than error masking.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 975 original 200-901 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 →
Same concept, more angles
1 more way this is tested on 200-901
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which THREE of the following are best practices for writing Ansible playbooks for network automation? (Select exactly 3.)
hard- A.Run all tasks without checking for errors
- ✓ B.Include a validation task after configuration changes
- ✓ C.Use variables for device-specific parameters
- D.Hardcode device IPs in the playbook
- ✓ E.Use the 'changed_when' condition to ensure idempotency
Why B: Option B is correct because including a validation task after configuration changes confirms the device reached the intended state and catches failed or partial deployments before moving on. Option C is correct because using variables for device-specific parameters (for example, hostnames, IPs, or interface names) keeps playbooks reusable across many devices instead of duplicating logic. Option E is correct because 'changed_when' lets you accurately report whether a task actually modified device state, which is essential for idempotency and reliable reporting in network modules that may not natively detect change. Option A is not a best practice because ignoring errors hides failures and can leave devices in an inconsistent state. Option D is not a best practice because hardcoding device IPs makes playbooks brittle and non-reusable; those values should come from inventory or variables.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-901 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 200-901 exam.