A transit authority automation job must confirm whether an interface is currently up/down and separately whether the intended interface config is present. How should model-driven access treat those needs?
Select an answer to reveal the explanation.
Short Explanation
Config is the written schedule; oper state is whether the train is actually moving. Ask the operational YANG tree for up/down and the config datastore for what was provisioned. Mixing them up is how you declare a link healthy because the config stanza exists.
Full Explanation
Model-driven management on IOS XE separates configuration datastores (for example running/candidate intent) from operational state models that reflect live conditions such as interface oper status. Automation should query each for its purpose. Candidate/running config does not imply link-up; traceroute is not a datastore read.