Requirements: no agent on the device, reuse existing SSH reachability, and express changes as ordered tasks in plays. Which tool identification matches?
Select an answer to reveal the explanation.
Short Explanation
No agent, SSH already works, think in tasks—that is Ansible’s lane. Puppet agents contradict “agentless,” and UCS XML is the wrong platform story.
Full Explanation
Requirements of no agent on the device, reuse of existing SSH reachability, and expressing changes as ordered tasks in plays identify Ansible for municipal campus automation. Ansible is agentless over SSH and models change as play tasks—matching how city NOCs already reach IOS XE boxes without installing on-box agents for VLAN and interface work.
Terraform provider resources only, claimed because “providers install agents on IOS XE,” fails both fact and fit: Terraform providers do not impose on-box agents as the play model, and the stem asked for ordered play tasks, not declarative resource/state workflow. Puppet agents as the agentless SSH solution fails by contradiction—agents are not agentless. UCS Manager XML API as the playbook engine for campus switches fails platform scope: UCS XML is not the campus play-oriented CM identification for this municipal requirement.
Exam caveat: Terraform remains the right identification when the stem emphasizes plan/apply and state ownership; score the stated constraints, not a universal “Ansible always” rule across every civic estate.
Operational check: verify no agent packages on the switches, SSH inventory works from the automation host, and the municipal change is expressed as Ansible play tasks—then select Ansible as the matched CM tool under 5.4.