JN0-106 Junos Configuration Basics Practice Question
An administrator is configuring a new Junos device and wants to ensure that configuration changes are applied only after explicit commit confirmation. Which configuration statement should be used?
⚠ Common exam trap
Many exam-takers confuse 'commit confirmed' with 'commit check' or 'commit at', mistakenly thinking that syntax validation or scheduled commits provide the same automatic rollback safety net, when in fact only 'commit confirmed' enforces explicit confirmation to prevent permanent changes.
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
✓
commit confirmed
The 'commit confirmed' statement allows an administrator to apply configuration changes that automatically revert to the previous configuration if not explicitly confirmed within a specified timeout period (default 10 minutes). This ensures changes are only permanently applied after an explicit 'commit' confirmation, providing a safety mechanism to prevent lockout or misconfiguration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
commit synchronize
Why it's wrong here
commit synchronize is designed for dual Routing Engine platforms, such as the MX or PTX series, to apply the same configuration to both REs simultaneously. It keeps the active and standby control planes in sync, but it does not create any confirmation timer or automatic rollback behavior. On a new standalone Junos device, this command is not only irrelevant but also fails to provide the safety net the administrator expects.
- ✗
commit at
Why it's wrong here
commit at schedules the configuration activation for a specific time in the future, often used to delay changes to a maintenance window. However, once the scheduled time arrives, the commit is applied permanently with no confirmation requirement or automatic rollback. If the administrator loses connectivity immediately after the change, there is no self-healing mechanism, so it does not meet the goal of a temporary change with a safety timeout.
- ✗
commit check
Why it's wrong here
commit check performs a syntax and semantic validation of the candidate configuration without activating it. It reveals errors like invalid statements or undefined references, but it makes no change to the running or active configuration. Because nothing is committed, there is no rollback to worry about, but the command also cannot provide an automatic revert option if the change were actually applied. This makes it a pre-commit test, not a commit with safety.
- ✓
commit confirmed
Why this is correct
commit confirmed applies the candidate configuration immediately and starts a countdown timer, defaulting to 10 minutes. If the administrator does not explicitly confirm the commit before the timer expires, the device automatically reverts to the previous configuration. This prevents network lockouts and allows the administrator to test the change, and if it is successful, a simple 'commit' command makes it permanent. This is exactly the functionality needed when configuring a new device remotely.
About these practice questions
This JN0-106 question is part of Courseiva's 326-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 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.