200-901 Network Fundamentals Practice Question
A network automation engineer is using the NETCONF protocol to configure a Cisco IOS XE device. The engineer sends an <edit-config> RPC with a candidate datastore, but the configuration does not take effect until a <commit> operation is performed. Which NETCONF capability must be supported by the device to allow this workflow?
⚠ Common exam trap
A common mix-up: candidates confuse the candidate datastore capability with related features like confirmed-commit or rollback-on-error, which are not required to use a candidate datastore.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
urn:ietf:params:netconf:capability:candidate:1.0
The candidate datastore capability enables a two-step configuration process where changes are made to a candidate datastore and then applied to the running datastore via a commit. This is exactly the workflow described. The other capabilities provide additional features like confirmed commit, direct running edits, or error rollback, but they are not the fundamental requirement for using a candidate datastore.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
urn:ietf:params:netconf:capability:candidate:1.0
Why this is correct
The candidate datastore capability allows a device to support a candidate configuration that can be edited and then committed to the running datastore. This matches the workflow described, where changes are made to a candidate and only applied after a commit. Without this capability, the device would not support the candidate datastore, and the <edit-config> targeting candidate would fail.
- ✗
urn:ietf:params:netconf:capability:rollback-on-error:1.0
Why it's wrong here
Rollback-on-error allows the server to automatically roll back to the previous configuration if an error occurs during an edit. It is not related to the use of a candidate datastore or the need to commit changes. The scenario requires staging changes in a candidate and then committing, which is independent of error handling. This capability does not fulfill the requirement.
- ✗
urn:ietf:params:netconf:capability:confirmed-commit:1.0
Why it's wrong here
The confirmed-commit capability allows a commit to be automatically rolled back if not confirmed within a timeout. While useful, it is not required to use a candidate datastore. The scenario only requires that changes are staged and then committed, which is provided by the candidate capability. Confirmed-commit is an additional feature that builds on candidate but is not the foundational capability needed here.
- ✗
urn:ietf:params:netconf:capability:writable-running:1.0
Why it's wrong here
Writable-running allows direct edits to the running configuration without a candidate. This is the opposite of the described workflow, where changes are made to a candidate and then committed. If the device only supported writable-running, the engineer could not use a candidate datastore. Thus, this capability does not enable the required staged configuration process.
Go deeper
Related to this question
About these practice questions
Courseiva writes every 200-901 question from scratch — 975 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Cisco exam blueprint
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.