Capability of Model-Driven Programmability
What is a capability of model-driven programmability for infrastructure automation?
Community Votes
60% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Tests what model-driven programmability actually delivers — decoupled, standardized APIs — against the misconception that one global data model spans the whole network.
Model-driven programmability exposes generic, model-based APIs such as NETCONF and RESTCONF running on standardized YANG models, so the same automation can drive multiple platforms.
Learners choose "a single data model across the network", but models are defined per device (native, OpenConfig, IETF); standardization means vendor-neutral APIs, not one universal model.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Model-driven programmability describes device data with structured models — most commonly YANG — and serves that data through generic, protocol-based APIs such as NETCONF and RESTCONF. Because the model (what the data means) is decoupled from the transport, protocol and encoding, the same API and tooling can drive devices from different platforms and vendors. That vendor-neutral, reusable API surface is the capability the question asks about, and it is what lets automation scale beyond a single hardware family.
Why the Other Options Are Wrong
Compatibility with "any" networking device is an overstatement: a device must implement the relevant model and management protocol, and legacy or closed platforms often do not. Automatic version control is a workflow benefit of automation tooling such as Git, not a property that model-driven programmability itself provides. A single data model across the whole network is a common misconception — each device exposes its own native model alongside shared standards such as IETF and OpenConfig, so there is no one universal model for everything.
Community Comment Notes
Most commenters back this option and tie it to YANG. One explains that standardized models like YANG yield "generic APIs that facilitate interoperability across various platforms", and a third learner reaches the same conclusion. The dissenting note simply asserts the single-model option without argument, which matches the misconception the distractors are built on.
Official Reference
Exam Strategy
Remember the decoupling: model-driven APIs separate the data model from transport, protocol and encoding. That is why one API toolset can target many platforms — the wording the exam rewards.
Frequently Asked Questions
Why is "a single data model" wrong?
Each device exposes its own model, plus shared standards such as IETF and OpenConfig. Model-driven programmability standardizes the API, not one model for the entire network.
Which protocols do these generic APIs use?
The core model-driven protocols are NETCONF and RESTCONF (and gRPC), carrying YANG-modelled data in JSON or XML over SSH, TLS or HTTP.
Related Analysis
Practice All 200-901 Questions
Access 105 questions with complete answers and detailed explanations.
View Full 200-901 Practice Test →