City Wi-Fi segregation requires VLAN 40 created on an IOS XE access switch through the official RESTCONF API. Which construction is correct?
Select an answer to reveal the explanation.
Short Explanation
VLAN 40 is a YANG locker under /restconf/data—write the id and leaves there—not a console paste or a Webex meeting room.
Full Explanation
Creating VLAN 40 on an IOS XE access switch for city Wi-Fi segregation through the official RESTCONF API means addressing the IOS XE VLAN resource under /restconf/data and writing vlan-id plus name/state leaves as the model defines. That construction works because VLANs are YANG list resources keyed by identifier; RESTCONF create/merge against the VLAN path installs the Layer-2 segment the wireless segregation design needs without requiring an interactive console session. Municipal automation stays inside the device-config API the blueprint associates with IOS XE RESTCONF.
Pasting “vlan 40” on the console and calling that a RESTCONF workflow fails because console CLI is not RESTCONF, even if the resulting VLAN looks identical. Configuring a VTP domain name only and skipping any VLAN YANG resource fails conceptually: VTP domain setup does not create the VLAN object via RESTCONF and may not even create VLAN 40 on the local switch as intended. POSTing the VLAN to the Webex Meetings API for network isolation fails because collaboration meeting APIs do not provision IOS XE VLANs.
Exam caveat: VLAN name and active/suspend state are useful leaves, but the vlan-id key is what addresses the resource—do not confuse friendly names with list keys. Operational check: GET the VLAN 40 resource after write, confirm it appears in the VLAN database/operational state on the access switch, and validate that Wi-Fi SSID-to-VLAN mapping still points at 40 before declaring segregation complete.