How does a typical Ansible-to-IOS-XE playbook workflow reach the switches in DEVCOR 5.3.a?
Select an answer to reveal the explanation.
Short Explanation
Ansible phones the switch over SSH like a remote help desk—no Puppet agent living in the wiring closet.
Full Explanation
A typical Ansible-to-IOS-XE playbook workflow in DEVCOR 5.3.a reaches switches agentlessly over SSH/network_cli (or the equivalent network connection)—no device agent required. That model works because Ansible network automation pushes modules from the control node over the device’s management SSH (or other supported network connection plugins); Catalyst/IOS XE does not need a resident Ansible agent. Municipal operations keep switches lean while still converging config from centralized playbooks.
Installing a mandatory Puppet agent on every Catalyst before the play runs fails because Ansible network plays do not depend on Puppet agents. Reaching devices only through a local IOx app container running on each switch as an Ansible agent fails conceptually: IOx apps are not the standard 5.3.a connection model for ordinary IOS XE playbook workflows. Embedding a Terraform provider binary in flash: on the device fails because Terraform providers are not how Ansible connects, and device flash is not the Ansible control path.
Exam caveat: credentials, enable secrets, and network connection variables still matter—agentless does not mean unauthenticated—and some environments use HTTPS APIs, but the classic DEVCOR Ansible-to-IOS-XE picture remains SSH/network_cli without an on-box agent. Operational check: verify ansible_connection (or controller credential) uses network_cli/SSH to a lab switch, confirm a simple facts or ios_command task succeeds without any agent package on the device, then scale that pattern to the civic inventory.