CCNP Automation Practice Question
A network engineer is developing a Python script to configure OSPF on a Cisco IOS XE device using the NETCONF protocol. The script establishes an SSH session and sends a <edit-config> RPC with the target datastore set to 'running'. The configuration is applied successfully, but after a device reload, the OSPF configuration is missing. The engineer verifies that the <edit-config> operation included the 'default-operation' parameter set to 'merge'. What is the most likely reason for the configuration loss?
⚠ Common exam trap
The trap here is assuming that NETCONF automatically saves changes to startup, when it only modifies the running configuration.
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
✓
The NETCONF <edit-config> operation modifies the running configuration but does not automatically save it to the startup configuration; a separate <copy-config> or <commit> to startup is required.
NETCONF <edit-config> operations on Cisco IOS XE modify the running configuration. To persist changes across a reload, the running configuration must be explicitly saved to the startup configuration using a <copy-config> RPC or equivalent. The scenario describes a classic case where the configuration is applied but not saved, leading to loss after reload. The other options incorrectly attribute the loss to datastore targeting, merge behavior, or session handling.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The <edit-config> operation was applied to the 'candidate' datastore instead of the 'running' datastore, and the candidate was not committed.
Why it's wrong here
The scenario explicitly states that the target datastore was set to 'running'. If the operation had targeted the 'candidate' datastore without a subsequent <commit>, the configuration would not have been applied at all, not even temporarily. Since the configuration was applied successfully during the session, this is not the cause. The issue is persistence across reload, which points to the startup configuration.
- ✗
The 'default-operation' parameter should have been set to 'replace' instead of 'merge' to ensure the configuration is saved to NVRAM.
Why it's wrong here
The 'default-operation' parameter determines how the configuration is merged or replaced within the target datastore, but it does not affect persistence to NVRAM. Setting it to 'replace' would overwrite the entire configuration, which is dangerous and unrelated to saving to startup. The issue is not the merge operation but the lack of a save operation to the startup datastore.
- ✗
The NETCONF session was not closed properly, causing the device to roll back the configuration upon session termination.
Why it's wrong here
NETCONF sessions do not automatically roll back changes made to the running datastore upon session termination unless a confirmed-commit was used with a timeout. The scenario does not mention confirmed-commit. Improper session closure would not cause a rollback of already-committed changes. The configuration loss is due to the running configuration not being saved to startup, not session handling.
- ✓
The NETCONF <edit-config> operation modifies the running configuration but does not automatically save it to the startup configuration; a separate <copy-config> or <commit> to startup is required.
Why this is correct
NETCONF <edit-config> on Cisco IOS XE modifies the running configuration. To persist changes across a reload, the running configuration must be copied to the startup configuration. This can be done with a <copy-config> RPC targeting the 'startup' datastore or by using the 'copy running-config startup-config' command. Without this step, the configuration is lost on reload, which matches the scenario.
Visual reference
Quick reference
Routing Protocol Comparison
| Protocol | Metric | Max Hops | Algorithm | Type |
|---|---|---|---|---|
| RIP v2 | Hop count | 15 | Bellman-Ford | Distance vector |
| OSPF | Cost (bandwidth) | Unlimited | Dijkstra (SPF) | Link state |
| EIGRP | Composite metric | Unlimited | DUAL | Hybrid |
| IS-IS | Cost | Unlimited | Dijkstra | Link state |
| BGP | Policy / attributes | Unlimited | Path vector | Path vector |
RIP's 15-hop limit makes it unsuitable for large networks. OSPF and EIGRP dominate modern enterprise deployments.
About these practice questions
This 350-401 question is part of Courseiva's 1,923-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 350-401 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 350-401 exam.