A RESTCONF PATCH must update only Loopback100 on an IOS XE router. How should the target interface be identified?
Select an answer to reveal the explanation.
Short Explanation
The interface name is the locker number in the hallway—put it in the URI key, don’t yell “int lo100” at the building or hope VLAN 1 forwards your mail.
Full Explanation
A RESTCONF PATCH that must update only Loopback100 on an IOS XE router identifies the target by including the interface name—or type plus unit in the native tree—as the list key in the RESTCONF path. That identification works because YANG lists are keyed: the path selects exactly one interface instance, and the PATCH body then merges leaves for that instance alone. Municipal automation therefore encodes Loopback100 in the URI the way the chosen module keys interfaces, rather than hoping a body-wide dump or a wrong VLAN target applies the change.
Putting a CLI-style string such as “int lo100” as the entire URL path with no YANG keys fails because RESTCONF paths are YANG resource identifiers, not CLI shorthand. Omitting the interface name from the URI and listing every interface in the JSON body fails conceptually: without a key in the path (or a correctly keyed list edit), you lose precise single-interface targeting and risk broad unintended merges. Addressing vlan 1 only and assuming Loopback100 inherits the change fails because VLAN and loopback are distinct resources; inheritance does not retarget the edit.
Exam caveat: IETF often keys by interface name string, while native trees may use name or type/unit patterns—match the model you chose, don’t mix. Operational check: GET the fully keyed Loopback100 path before and after the PATCH, confirm no sibling interfaces changed, and reject any script whose URI lacks an explicit interface key for a single-interface edit.