JN0-106 Junos Configuration Basics Practice Question
A company runs a Juniper SRX firewall cluster consisting of two nodes (node0 primary, node1 secondary). The cluster has been stable. During maintenance, you modify the configuration on node0 and commit. After the commit, the cluster status shows node1 as 'ineligible'. You suspect a configuration mismatch. What should you do to synchronize the configuration without disrupting traffic?
⚠ Common exam trap
It's easy for candidates to think the secondary node can initiate synchronization (option D) or that a manual file copy (option C) is acceptable, but Juniper clusters require the primary to be the source of truth for configuration synchronization to maintain cluster integrity and avoid split-brain scenarios.
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
✓
On the primary node, execute 'commit synchronize'.
The 'commit synchronize' command on the primary node (node0) pushes the active configuration to the secondary node (node1) and commits it on both nodes, ensuring configuration consistency without requiring a reboot or traffic disruption. In a Juniper SRX cluster, the primary node is the authoritative source for configuration synchronization, and this command is the standard method to resolve a configuration mismatch that causes a node to become 'ineligible'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
On the primary node, execute 'commit synchronize'.
Why this is correct
On the primary node, execute 'commit synchronize' is the correct approach because in a Juniper chassis cluster, the primary node is the sole controller that can propagate configuration changes to its cluster peer. This command commits the local configuration and then replicates that same candidate configuration to the secondary node over the control link, followed by a commit on both nodes. Without specifying 'synchronize', a normal commit only updates the node on which it is executed, so this is the definitive way to ensure both nodes run identical configurations.
- ✗
Reboot both nodes to force synchronization.
Why it's wrong here
Rebooting both nodes to force synchronization is ineffective and disruptive because the configuration is not automatically copied during reboot. Each node loads its own stored configuration file, and if the configurations have drifted, a reboot will not resolve the discrepancy—it may actually cause the secondary to come up with its outdated configuration. Furthermore, a chassis cluster reboot creates a switchover that interrupts traffic, and it does not invoke the Junos commit-synchronization mechanism, so the problem of divergent configuration remains.
- ✗
Manually copy the configuration file from primary to secondary.
Why it's wrong here
Manually copying the configuration file from primary to secondary is an error-prone workaround that bypasses Junos' intended synchronization mechanism. The active configuration is stored in the Junos configuration database, not simply as a regular file that can be SCP'd, and a manual copy would not perform the necessary validation, translation, and commit operations on the secondary node. This method also fails to update the secondary node's per-node settings and can corrupt the configuration or leave the nodes out of the immediate commit sequence, making the cluster unstable.
- ✗
On the secondary node, execute 'commit synchronize'.
Why it's wrong here
Executing 'commit synchronize' on the secondary node is invalid because only the primary node in the cluster is permitted to initiate configuration synchronization. The secondary node is in standby state and does not have the required mastership to push configuration to the primary; attempting this will result in an error or an error message indicating that the command has to be executed on the primary node. In a properly operating cluster, the secondary is read-only for configuration changes, so any configuration update must be done from the active primary.
Visual reference
Go deeper
Related to this question
About these practice questions
This JN0-106 question is part of Courseiva's 156-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.