200-901 Cisco Platforms and Development Practice Question
A developer is building a Python application that manages Cisco IOS XE devices through the Python library ncclient. The application must apply a configuration change atomically, validate it before committing, and avoid persisting the change if validation fails. Which approach should the developer take?
⚠ Common exam trap
The trap here is treating the running datastore as if it were staged, when only the candidate datastore supports validate-then-commit semantics.
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
✓
Lock the candidate datastore, edit the candidate, validate it with the validate operation, then commit and unlock
Transactional configuration over NETCONF depends on a staging datastore and an explicit validation step. Locking the candidate, editing it, running the validate operation, and then committing ensures the change is checked before it becomes active. If validation fails, the candidate can be discarded and running is never touched, satisfying the atomic and non-persistent requirements.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Issue a discard-changes operation against running after each edit-config to confirm the edit was accepted
Why it's wrong here
Discard-changes reverts a candidate datastore to match running; it is not a validation or confirmation mechanism for running edits. Invoking it after editing running would simply undo nothing useful and could confuse state. The scenario needs validation before commit, which this sequence never performs.
- ✓
Lock the candidate datastore, edit the candidate, validate it with the validate operation, then commit and unlock
Why this is correct
The candidate datastore exists specifically to stage changes before they take effect. Locking prevents concurrent edits, the validate operation checks the staged configuration, and commit applies it only when validation succeeds. This sequence meets the atomic, validated, non-persistent-on-failure requirement and is the standard ncclient workflow for transactional configuration.
- ✗
Send an edit-config directly to the running datastore with the default merge operation
Why it's wrong here
Editing running applies changes immediately and bypasses any validation step, so a malformed configuration could be partially applied and persist. It also offers no rollback point if the device rejects part of the edit. This does not provide the atomic, validated behaviour the scenario requires.
- ✗
Use the copy-config operation to copy running into startup, then edit startup directly
Why it's wrong here
The startup datastore holds the configuration loaded at boot and is not a staging area for validation. Editing it does not affect the active running configuration, so the change would not take effect until a reload. This approach also lacks a validate step, so it fails the requirement for atomic, validated application.
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.