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
Transit automation jobs must confirm whether an interface is currently up/down and separately whether intended interface config is present by querying operational state models for live status and configuration datastores for intended/running config separately. Oper and config are different questions in model-driven access; conflating them causes false confidence. YANG tooling expects that separation.
Reading only the candidate datastore because it always mirrors live oper state is wrong—candidate is config intent, not oper. Using traceroute alone proves neither full configuration presence nor precise interface admin/oper status comprehensively. Assuming running-config presence guarantees the link is up ignores cable/optics/protocol faults.
Exam caveat: admin-down vs oper-down vs missing config are distinct failures with different remediations. Operational check: pull config and oper for a lab interface in both up and down states, assert the script branches correctly, then use that logic in transit change validation. Report both dimensions in the job output for NOC clarity. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services.