200-901 Infrastructure and Automation Practice Question
A developer is writing a Python script that authenticates to a Cisco IOS XE device using NETCONF over SSH on port 830. The script must send a candidate configuration and commit it atomically. Which NETCONF capability must the device advertise for the script to use the candidate datastore?
⚠ Common exam trap
The trap here is assuming that rollback-on-error or validate implies a candidate datastore, when in fact candidate is its own distinct capability URI that must be advertised independently.
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 is the only one that introduces a separate staging area plus a commit operation, enabling atomic configuration changes. Writable-running, rollback-on-error, and validate are separate capabilities that do not create a candidate store. When a NETCONF client must edit offline and commit transactionally, the hello message must include the candidate capability URI before the client can target candidate in edit-config.
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 means the client may edit the running datastore directly, which is the opposite of the transactional candidate workflow. It does not provide a staging area, rollback-on-error semantics, or an explicit commit step. A script needing atomic commit of a candidate configuration cannot rely on this capability alone, so it fails to satisfy the requirement described.
- ✓
urn:ietf:params:netconf:capability:candidate:1.0
Why this is correct
The candidate capability URI is exactly what signals the device supports a separate candidate datastore that can be edited, validated, and committed atomically. Without this capability in the hello message, the client cannot legally target <candidate/> in edit-config or issue a commit, so the script would fail. Advertising this capability is a prerequisite for the transactional workflow the developer requires.
- ✗
urn:ietf:params:netconf:capability:rollback-on-error:1.0
Why it's wrong here
Rollback-on-error only tells the client that the server will revert an edit-config if any part of it fails; it does not create a candidate datastore or a commit operation. The developer could still only edit the running datastore. This capability is useful but insufficient for the atomic candidate-and-commit workflow the scenario demands.
- ✗
urn:ietf:params:netconf:capability:validate:1.1
Why it's wrong here
Validate 1.1 allows the client to syntax-check a configuration before applying it, which is valuable but orthogonal to having a candidate datastore. A device could advertise validate without candidate, and the script could still not stage and commit atomically. The scenario explicitly requires the candidate datastore, so this capability alone does not meet the need.
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.