A DEVCOR practice item asks how to add one intended route on IOS XE with RESTCONF. Which answer stays in scope?
Select an answer to reveal the explanation.
Short Explanation
DEVCOR wants one static-route postcard via RESTCONF—not a CCNP rewrite of every IGP in the metro.
Full Explanation
When a DEVCOR practice item asks how to add one intended route on IOS XE with RESTCONF, the in-scope answer is to create or merge a static-route YANG object with the required prefix and forwarding fields. That stays on the scored idea because task-style device-config items test constructing a RESTCONF edit against the static-routing resource—not redesigning metro routing architecture. City automation demonstrates competence by writing one correct YANG route object end to end.
Redesigning the campus from OSPF to EIGRP and documenting area summarization fails because that is a broad CCNP-style redesign, not a RESTCONF static-route create. Migrating all edge routing to BGP confederations before any RESTCONF call fails conceptually: confederation redesign is out of scope for adding one intended route via the API. Replacing IOS XE with ASA REST so dynamic protocols become irrelevant fails because changing platforms abandons the IOS XE RESTCONF task the item named.
Exam caveat: “create or merge” still implies correct media types, /restconf/data paths, and model-required forwarding fields—scope discipline does not excuse an incomplete route object. Operational check: implement the smallest RESTCONF create/merge that installs the one civic route, validate with GET and RIB checks, and keep IGP/BGP redesign discussions in a separate design review outside this task’s acceptance criteria.