Reviewing a playbook for twelve IOS XE access switches, an engineer must apply interface GigabitEthernet1/0/12, switchport mode access and switchport access vlan 30, changing only that interface block. Which Ansible task structure configures the switches correctly?
Select an answer to reveal the explanation.
Short Explanation
You're covered when the ios_config module sets parents as the block context and lines fills it in. It works like telling the switch to step into that interface first, then apply each command there. The command module stays in exec mode, so it can't place config under an interface.
Full Explanation
Cisco's Ansible collection splits responsibilities cleanly, and ios_config is the module that writes configuration. Parents establishes the block context by entering the interface named there, and each entry in lines is applied inside that block, so only the addressed port changes while the rest of the running configuration stays as it was. The module is also idempotent: it compares the candidate lines with what the device already has and sends only the difference. The ios_command module targets exec-level show and test commands, so pushing switchport lines through it never reaches configuration mode at all. Omitting parents drops both switchport commands into global configuration, where they have no interface context and the port stays unchanged. Supplying a whole running-config file from one switch through src drags in device-specific addresses and every other interface, which breaks the requirement to change one block and can disturb neighboring links. Exam caveat: the module moved under the cisco.ios prefix years ago, so older examples may still show the legacy name. Practical check: run the task with check mode and diff enabled and read the block it plans to touch.