200-901 Infrastructure and Automation Practice Question
A developer is building a Python script to configure a Cisco IOS XE device using NETCONF. The script must send an <edit-config> RPC that places the target datastore in candidate mode, changes the description of GigabitEthernet0/0, and commits the change. Which NETCONF capability must the device advertise for the script to use the candidate datastore?
⚠ Common exam trap
The trap here is assuming that any edit-config operation requires the candidate capability, when in fact only workflows that explicitly target the candidate datastore and commit need it.
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 capability is required because the script edits a candidate datastore and then commits the change to running. NETCONF capabilities are advertised in the server's <hello> message; a client must check for the candidate capability before using <edit-config> with a candidate target and <commit>. Rollback-on-error, validate, and writable-running serve different purposes and do not enable the candidate datastore workflow.
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 capability allows a client to edit a candidate datastore and then commit those changes to the running datastore. Because the script edits the candidate and commits, the device must advertise this capability. Without it, the client cannot use <edit-config> with a candidate target or issue <commit>, so this is the required capability for the described workflow.
- ✗
urn:ietf:params:netconf:capability:rollback-on-error:1.0
Why it's wrong here
Rollback-on-error lets the server automatically discard a failed edit-config operation, but it does not provide a candidate datastore. The script explicitly needs to edit a candidate and then commit, which requires the candidate capability. Rollback-on-error is useful for transactional safety, but it is not the capability that enables the candidate datastore workflow described.
- ✗
urn:ietf:params:netconf:capability:writable-running:1.0
Why it's wrong here
Writable-running allows direct edits to the running datastore. The script instead edits a candidate datastore and then commits, so writable-running is not the capability required. In fact, using writable-running would bypass the candidate/commit workflow the developer wants, making it the wrong choice for this scenario.
- ✗
urn:ietf:params:netconf:capability:validate:1.0
Why it's wrong here
The validate capability allows a client to validate configuration content before applying it, typically against the candidate datastore. However, validation alone does not create or expose a candidate datastore. The script needs to place the target datastore in candidate mode, which is enabled by the candidate capability, not by validate.
Go deeper
Related to this question
About these practice questions
One of 975 original 200-901 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.