JN0-106 Junos OS Fundamentals Practice Question
An engineer notices that a Juniper device is not saving configuration changes across reboots. What is the most likely cause?
⚠ Common exam trap
The trap here is that candidates familiar with Cisco IOS may assume changes are saved automatically or with a 'copy running-config startup-config' equivalent, but Junos requires an explicit 'commit' to make changes persistent across reboots.
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 candidate configuration was not committed.
In Junos OS, configuration changes are stored in a candidate configuration and only become active and persistent across reboots after a 'commit' operation. Without a commit, the changes remain in the candidate buffer and are discarded upon reboot, causing the device to revert to the last committed configuration.
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 rescue configuration is not set.
Why it's wrong here
The rescue configuration is a snapshot saved specifically for disaster recovery; it is not involved in the normal process of saving or applying configuration changes. Setting or not setting a rescue configuration has no effect on whether changes in the candidate configuration are committed to the active configuration. Thus, the absence of a rescue configuration is not the reason the device's changes are not being saved.
- ✗
The device is booting from factory-default configuration.
Why it's wrong here
Booting from factory-default would require that the device were explicitly reset or that no valid committed configuration existed, which is not the case in this scenario. A Junos device normally boots with the last committed configuration stored in /config/juniper.conf.gz, not from factory defaults, unless someone issued 'load factory-default' or similar. Even if the device were booting from default, the real problem remains that the candidate changes were never committed to the active configuration.
- ✓
The candidate configuration was not committed.
Why this is correct
In Junos, configuration changes are held in the candidate configuration until you issue the 'commit' command, which activates and saves them to /config/juniper.conf.gz. Without a commit, the changes exist only in the volatile candidate buffer and are discarded on reboot or when a rollback is performed. Therefore, the most direct explanation for changes not being saved is that the candidate configuration was never committed.
- ✗
The command 'request system reboot' was used instead of 'commit'.
Why it's wrong here
Using 'request system reboot' without first committing the candidate configuration will indeed cause uncommitted changes to be lost, but the command itself is not the root cause; it is merely the event that triggered the loss. A reboot does not alter or erase the committed configuration, so if the changes had been committed first they would survive the reboot. The underlying issue is the failure to run 'commit', which is what actually saves the changes.
Go deeper
Related to this question
About these practice questions
One of 326 original JN0-106 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This JN0-106 practice question is part of Courseiva's free Juniper Networks 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 JN0-106 exam.