A library branch needs a static route added on an IOS XE edge router through RESTCONF. Which payload content matches the official static-route resource idea?
Select an answer to reveal the explanation.
Short Explanation
A static route is address plus where to send it—like a street number and the driveway out—not an OSPF redesign essay or a prefix with no exit.
Full Explanation
Adding a static route on an IOS XE edge router through RESTCONF requires a payload that matches the static-route YANG resource: destination prefix (and mask/length) plus the forwarding next-hop or outgoing interface the model requires. That content works because a static route is incomplete without both “where” and “how to leave”; YANG models encode those as mandatory or jointly required fields on the route object. Library-branch automation therefore POSTs or PATCHes a fully specified route resource under the static-routing tree rather than a partial destination-only stub.
Sending only an OSPF process ID with no destination prefix fails because that is dynamic IGP process identity, not a static-route object. Providing a BGP peer ASN list used to redesign the entire IGP fails conceptually: BGP peer lists and IGP redesign are out of scope for creating one static route via RESTCONF. Including a destination prefix alone with no next-hop or exit interface fails because the model still needs forwarding information; a prefix without an exit does not install a usable static route.
Exam caveat: some models allow next-hop, outgoing interface, or both—follow the YANG constraints on the device rather than inventing a single universal field set. Operational check: after the RESTCONF write, GET the static-route resource keys and confirm the route appears in the RIB with the intended next-hop or exit; roll back with DELETE if the civic edge blackholes traffic during validation.