200-901 Infrastructure and Automation Practice Question
A developer is writing a Python script that uses the ncclient library to configure a Cisco IOS XE device over NETCONF. The script must push a candidate configuration, validate it, and then commit it atomically. Which sequence of NETCONF operations should the script use to guarantee the configuration is only applied if it passes validation?
⚠ Common exam trap
The trap here is assuming that validate must be called after commit, or that the running datastore supports transactional commit like the candidate datastore does.
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
✓
edit-config with the candidate datastore, validate, then commit
NETCONF separates staging from activation through the candidate datastore and the commit operation. Loading the candidate with edit-config, validating it, and then committing ensures the configuration is syntactically and semantically correct before it becomes active, and the commit is atomic. This is the standard approach for safe, transactional configuration changes on devices that support the candidate capability.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
get-config, edit-config with the candidate datastore, then discard-changes
Why it's wrong here
get-config retrieves configuration but does not stage changes. Using discard-changes after edit-config would roll back the candidate configuration, so the intended change would never be committed. This sequence is useful for aborting a change, not for applying a validated configuration to the running datastore.
- ✗
edit-config with the running datastore, validate, then commit
Why it's wrong here
The running datastore is the active configuration. Writing directly to it with edit-config immediately affects device behavior, and the commit operation is not applicable to the running datastore. Even if validate is called, the change may already be active, so this approach cannot guarantee validation before the configuration takes effect.
- ✗
lock the running datastore, edit-config with the running datastore, then unlock
Why it's wrong here
Locking prevents other sessions from modifying the configuration, but edit-config against the running datastore still applies changes immediately without a commit or validation step. The unlock simply releases the lock. This does not provide the atomic, validate-then-commit behavior required by the scenario.
- ✓
edit-config with the candidate datastore, validate, then commit
Why this is correct
The candidate datastore allows a configuration to be staged without affecting the running configuration. After edit-config loads the candidate, the validate operation checks syntax and constraints, and commit applies it atomically. This sequence ensures the change is applied only if validation succeeds, which matches the requirement for validated, atomic deployment.
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.