A playbook must set an interface description, ensure VLAN 20 exists, and add a static route on IOS XE. Which task approach best matches DEVCOR 5.3.a construction?
Select an answer to reveal the explanation.
Short Explanation
Use the right power tools—cisco.ios-style modules for interface, VLAN, and route intent—not a raw CLI crowbar or a Webex chat pretending to be a switch module.
Full Explanation
Setting an interface description, ensuring VLAN 20 exists, and adding a static route on IOS XE from Ansible is best done by calling IOS/IOS-XE oriented modules from the cisco.ios collection family for those network parameters. That approach matches DEVCOR 5.3.a construction because collection modules encode idempotent intent for IOS XE features—interfaces, VLANs, routes—rather than treating the switch as a raw shell. Municipal playbooks stay readable and convergent when tasks name the right network modules.
Using only ansible.builtin.raw to type arbitrary CLI with no module semantics fails because raw CLI bypasses module argument validation and idempotent state handling the workflow is meant to demonstrate. Shelling into each device and pasting show running-config as the configuration method fails conceptually: show output is not a configuration apply path, and manual paste is not playbook construction. Invoking Webex Bot APIs from every task because ChatOps replaces network modules fails because collaboration bots do not configure IOS XE VLANs, interfaces, or routes.
Exam caveat: module names evolve with collections; the scored idea is “use IOS XE–oriented network modules for those parameters,” not memorizing one frozen module argument list. Operational check: map each civic intent (description, VLAN 20, static route) to a dedicated cisco.ios task, enable check/diff in review, and confirm reruns report changed=0 once the intended state is present.