A port authority is automating VLAN and interface configuration on Catalyst IOS XE and must target the correct config tree. Which practice best ensures the script edits the intended YANG model family?
Select an answer to reveal the explanation.
Short Explanation
YANG models are like filing cabinets—native Cisco and OpenConfig keep VLAN papers in different drawers. Confirm which cabinets the switch actually supports, then write to that exact path. Guessing or stuffing CLI into RESTCONF is how you edit the wrong tree.
Full Explanation
Port-authority automation of VLAN and interface configuration on Catalyst IOS XE must target the correct config tree by identifying device-supported native or OpenConfig models for interfaces/VLANs and addressing those module paths explicitly. Guessing paths or stuffing CLI into RESTCONF bodies bypasses the model contract and breaks portably. Explicit module selection is core YANG literacy for EI automation.
Picking any OpenConfig leaf at random because all models supposedly expose identical VLAN paths causes edit failures or wrong trees. Sending unstructured CLI snippets inside a RESTCONF PUT so YANG paths do not matter defeats model-driven configuration. Using only SNMP MIBs because YANG cannot represent Layer-2 interfaces is false on modern IOS XE.
Exam caveat: native Cisco models and OpenConfig may both exist—choose one family consistently per use case and verify hello/capabilities. Operational check: query schemas/capabilities, map the VLAN/interface leaves required, perform a lab edit-config/RESTCONF PATCH, and verify running config. Document the chosen model family in the port automation standard. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services.