A logistics company must ensure one VLAN exists on many Nexus switches, install no agent on them, and run the job again without creating a duplicate VLAN. Which tool fits?
Select an answer to reveal the explanation.
Short Explanation
You can run an Ansible playbook from an inventory against many Nexus switches without installing an agent, and the NX-OS module leaves an existing VLAN in place when you run it again. A persistent agent is unnecessary, and POAP’s first-boot role is not the right fit for a VLAN change on switches already in service.
Full Explanation
Ansible drives NX-OS from an external control node over SSH or NX-API, so you do not install an agent on each switch. The NX-OS module describes the desired VLAN, and when you run the playbook again, it finds that the VLAN is already present rather than creating another one. This idempotent behavior makes repeat runs safe across the inventory. A persistent agent installed on each switch is not required by this approach, so making one a prerequisite adds a step the requirement does not need. POAP runs at boot when the startup configuration is absent and helps a new switch obtain its first script; it is not the steady-state tool for ensuring a VLAN on switches already in service. A SPAN session copies frames to an analyzer; it does not write the VLAN database or serve as a configuration store. Exam caveat: idempotency depends on the module being given the desired state; a raw command module that always adds the VLAN may not behave safely on repeat runs. Practical check: run the playbook twice and confirm that the second run reports the VLAN in the desired state on each inventory host.