200-901 Cisco Platforms and Development Practice Question
A developer needs to configure a Cisco IOS XE device using NETCONF and wants to ensure the session supports candidate configuration and confirmed commit. Which capability must the device advertise in its NETCONF hello message?
⚠ Common exam trap
The trap here is assuming that writable-running is enough for transactional changes, when candidate configuration and confirmed commit require the candidate capability specifically.
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
NETCONF defines capabilities in the hello exchange, and candidate configuration is advertised via the candidate capability URN. When a device supports it, clients can edit the candidate datastore, validate it, and commit atomically. Confirmed commit builds on this by requiring an explicit confirmation within a timeout, otherwise the device reverts. The candidate capability is therefore the prerequisite for the described 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:writable-running:1.0
Why it's wrong here
Writable-running indicates that the running configuration can be edited directly, but it does not provide candidate configuration or confirmed commit. The developer needs the candidate datastore to stage changes and the confirmed-commit capability to auto-rollback if the session drops, so this capability alone is insufficient.
- ✓
urn:ietf:params:netconf:capability:candidate:1.0
Why this is correct
The candidate capability means the device supports a candidate configuration datastore that can be edited, validated, and then committed atomically. Combined with confirmed-commit, this allows the developer to stage changes and have them automatically rolled back if the commit is not confirmed, which is exactly the safe configuration workflow described.
- ✗
urn:ietf:params:netconf:capability:startup:1.0
Why it's wrong here
The startup capability indicates that a separate startup configuration datastore exists and can be manipulated. It has nothing to do with candidate configuration or confirmed commit, so it does not enable the safe staging workflow the developer needs. Relying on it would leave the developer without the required transactional behavior.
- ✗
urn:ietf:params:netconf:capability:rollback-on-error:1.0
Why it's wrong here
Rollback-on-error causes the server to discard a failed commit, but it does not create a candidate datastore or support confirmed commit. Without the candidate capability, the developer cannot stage changes before applying them, so this capability does not satisfy the requirement for candidate configuration and confirmed commit.
Go deeper
Related to this question
About these practice questions
This 200-901 question is part of Courseiva's 975-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.