JN0-106 User Interfaces Practice Question
During a maintenance window, an engineer makes critical changes and wants the configuration to automatically revert if they lose connectivity. Which command should they use before committing?
⚠ Common exam trap
A common mix-up: candidates confuse 'commit confirmed' with 'commit check', thinking syntax validation alone provides safety, or they may assume 'commit at' offers automatic rollback, but neither command includes the confirmation-based rollback mechanism that 'commit confirmed' provides.
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
'commit confirmed', is correct because it allows the engineer to commit a configuration change with a default 10-minute rollback timer. If the engineer loses connectivity and does not confirm the commit within that period, the system automatically reverts to the previous configuration, ensuring the device remains reachable.
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
Why it's wrong here
A standard `commit` immediately activates the candidate configuration and makes it the active configuration with no confirmation required. This means that a typo or unintended change takes effect at once, potentially disrupting the network until an engineer manually rolls back or reloads a rescue configuration. During a critical maintenance window, using plain `commit` carries the risk that any mistake becomes permanent without an automatic safety net, unlike `commit confirmed`.
- ✓
commit confirmed
Why this is correct
`commit confirmed` activates the candidate configuration for a specified confirmation period (default 10 minutes unless you append a time). The engineer must issue a second commit—either `commit` or another `commit confirmed`—before the timer expires; otherwise, Junos automatically rolls back to the previous configuration. This provides a crucial safety net for critical maintenance changes: if connectivity is lost or the change breaks something, the device restores the working configuration without manual intervention.
- ✗
commit check
Why it's wrong here
`commit check` only validates the candidate configuration's syntax, semantics, and system resource limits without activating it. It does not alter the running configuration and offers no rollback mechanism, so passing a commit check does not mean the change is safe to keep. During maintenance, `commit check` alone leaves the device unchanged; you must still follow it with `commit` or `commit confirmed` to actually apply the intended changes.
- ✗
commit at
Why it's wrong here
`commit at` schedules the commit to take effect at a specific future time, but it is not a confirmation-based rollback mechanism. Once the scheduled time arrives, the configuration is activated unconditionally, and if the change causes problems, there is no automatic revert. This is useful for delaying changes to a low-traffic window, but it lacks the safety of `commit confirmed`, which requires a follow-up confirmation within a timeout to avoid rolling back.
Go deeper
Related to this question
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.