City hall needs GigabitEthernet1/0/10 given an IPv4 address and description through RESTCONF on IOS XE. What is the correct construction focus?
Select an answer to reveal the explanation.
Short Explanation
You’re editing one labeled locker (the interface resource) and writing the tags that matter—IP, enable, description—not redesigning campus switching or hoping Assurance telepathy works.
Full Explanation
Giving GigabitEthernet1/0/10 an IPv4 address and description through RESTCONF on IOS XE is a resource-construction task: address the interface in an official YANG family and write the IP, enable/admin, and description leaves on that resource. That focus works because RESTCONF edits are path-plus-payload against modeled interface objects; city hall automation succeeds when it targets the correct interface key and sets the operational leaves the model exposes, not when it redesigns unrelated campus features.
Designing an EtherChannel hashing algorithm and leaving RESTCONF unused fails because hashing policy is a different switching topic and does not perform the RESTCONF interface write. Posting only to DNA Center Assurance and assuming the switch interface updates itself fails conceptually: Assurance is telemetry/analytics oriented, not a substitute for writing interface YANG leaves on the device (or an intentional controller config workflow the item did not ask for). Telnetting into the switch and ignoring YANG resources fails because interactive CLI bypasses the official RESTCONF construction the DEVCOR task is testing.
Exam caveat: which exact leaves and container names you set depend on IETF versus native models—know the construction idea (interface resource + address/description/enable leaves), not a single forever-frozen path. Operational check: after the write, GET the same interface resource and verify IPv4 and description in YANG form, then cross-check show/ip interface brief or equivalent so the civic ops team sees RESTCONF state and operational state agree.