JN0-106 Junos Configuration Basics Practice Question
Which THREE statements about the commit operation are correct? (Choose three.)
⚠ Common exam trap
Watch out — candidates often confuse the candidate configuration with the active configuration file (juniper.conf) or assume that a commit automatically updates the rescue configuration, when in fact the rescue configuration is a manually saved snapshot used for disaster recovery.
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 'commit check' command validates the syntax of the candidate configuration without activating it.
Option A is correct because 'commit check' performs a syntax and semantic validation of the candidate configuration and reports errors without activating or applying it, leaving the active configuration unchanged. Option B is correct because a successful commit copies the candidate configuration into the active configuration (the running configuration that the device uses), making the candidate the active one. Option C is correct because a commit can be issued with a confirmation timeout (for example, 'commit confirmed 10'), which automatically reverts to the previous configuration unless the commit is confirmed within that period. Option D is not correct because the active configuration is stored in 'juniper.conf' (with backups like juniper.conf.1.gz), while the candidate configuration is held in a separate candidate database, not in 'juniper.conf'. Option E is not correct because the rescue configuration is not saved automatically by a commit; it must be saved explicitly with 'request system configuration rescue save'.
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 'commit check' command validates the syntax of the candidate configuration without activating it.
Why this is correct
The 'commit check' command performs a dry-run validation of the candidate configuration, parsing the configuration statements and verifying that their syntax is correct, but it does not activate the changes. It is useful for pre-commit validation in production environments because it leaves the running configuration untouched and reports any syntax errors before an actual commit is attempted.
- ✓
After a successful commit, the candidate configuration becomes the active configuration.
Why this is correct
A successful commit operation applies the candidate configuration to the active configuration, making it the new operational configuration that the device uses. The candidate configuration is copied from the ephemeral editing buffer into the active configuration store, so the running configuration now matches the validated candidate, and the previous configuration becomes available as a rollback point.
- ✓
A commit can be scheduled to revert automatically if not confirmed within a certain time.
Why this is correct
Yes, Junos supports a 'commit confirmed' feature where you can issue a commit with a timeout value, typically in minutes, and the system automatically reverts to the previous configuration if you do not issue a second 'commit confirm' command before the timer expires. This is used to avoid being locked out or breaking connectivity by ensuring a failsafe rollback when a configuration change is applied remotely.
- ✗
The candidate configuration is stored in a file named 'juniper.conf' on the flash drive.
Why it's wrong here
The candidate configuration is not stored as a plain text file named 'juniper.conf' on the flash drive. Instead, the candidate configuration is held in memory as part of the configuration database, while the active configuration is what gets stored as the 'juniper.conf' file in the '/config' directory on the media. Committing the candidate saves it to that file, but the candidate itself is not directly stored as a file until the commit operation writes it to the active configuration store.
- ✗
A commit operation automatically saves the rescue configuration.
Why it's wrong here
A commit operation does not automatically save or update the rescue configuration. The rescue configuration is a separate, predetermined fallback configuration that must be explicitly saved using the 'request system configuration rescue save' command, and it is used to recover the device if the active configuration becomes unusable. Commit only activates the candidate configuration; it performs no additional rescue-related actions.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every JN0-106 question from scratch — 326 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 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.