Courseiva

CCNA Junos Configuration Basics Questions

23 questions · Junos Configuration Basics · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

An engineer wants to revert all uncommitted changes in the candidate configuration and start fresh from the currently active configuration. Which command should be used?

A.rollback 0
B.commit check
C.rollback 1
D.load override terminal
AnswerA

In Junos, `rollback 0` directly loads the most recently committed configuration into the candidate configuration, discarding any uncommitted edits or staged changes. This makes the candidate an exact mirror of the active, running configuration without modifying that active configuration until a subsequent commit. It is the standard, intended way to revert all uncommitted changes while preserving the currently effective operational state.

Why this answer

The `rollback 0` command reverts all uncommitted changes in the candidate configuration and restores it to match the currently active configuration (the one most recently committed). This is because Junos stores the last 50 committed configurations, with index 0 always representing the active configuration. Using `rollback 0` effectively discards any uncommitted edits and starts fresh from the last committed state.

Exam trap

The trap here is that candidates often confuse `rollback 0` with `rollback 1`, mistakenly thinking that `rollback 1` reverts uncommitted changes, when in fact `rollback 1` reverts to the configuration before the last commit, not the current active configuration.

How to eliminate wrong answers

Option B is wrong because `commit check` only validates the syntax and semantics of the candidate configuration without committing it; it does not revert any changes. Option C is wrong because `rollback 1` reverts to the configuration that was active before the most recent commit (the previous committed version), not to the currently active configuration. Option D is wrong because `load override terminal` replaces the entire candidate configuration with text entered via the terminal, but it does not automatically revert to the active configuration; it requires manual input and is not a simple undo of uncommitted changes.

Practice this question →
2
MCQeasy

A Juniper device has multiple candidate configurations loaded. The administrator wants to discard all uncommitted changes and revert to the last committed configuration. Which command should be used?

A.rollback 0
B.delete configuration
C.clear configuration
D.load override terminal
AnswerA

The `rollback 0` command reverts the candidate configuration to the last committed configuration by loading revision 0 from the configuration history, which always represents the most recently committed state. This directly satisfies the requirement to discard all uncommitted changes without affecting previously committed configurations, as rollback numbers increment with each commit and 0 is the fixed reference for the last committed configuration.

Why this answer

The 'rollback 0' command reverts the candidate configuration to the last committed configuration, discarding all uncommitted changes. In Junos, the rollback command uses a numeric index where 0 always refers to the most recently committed configuration, effectively undoing any uncommitted edits.

Exam trap

The trap here is that candidates may confuse 'rollback 0' with 'rollback 1', thinking 0 means 'no rollback' or that a higher number is needed to revert changes, when in fact 0 discards uncommitted edits and 1 reverts the last commit.

How to eliminate wrong answers

Option B is wrong because 'delete configuration' is not a valid Junos command; the correct approach to remove configuration is using 'delete' within configuration mode for specific statements, not a global delete. Option C is wrong because 'clear configuration' is not a valid Junos command; 'clear' is used for operational tasks like clearing counters or logs, not for reverting configuration. Option D is wrong because 'load override terminal' is used to replace the entire candidate configuration with text pasted from the terminal, but it does not revert to the last committed configuration; it loads new configuration from scratch.

Practice this question →
3
MCQhard

While in configuration mode, an administrator wants to see the difference between the candidate configuration and the active configuration. Which command accomplishes this?

A.show configuration
B.run show configuration
C.show | compare
D.show system commit
AnswerC

Shows changes between candidate and active.

Why this answer

The 'show | compare' command, when executed in configuration mode, displays the differences between the candidate configuration and the active (committed) configuration. This pipe filter compares the current candidate configuration against the last committed configuration, highlighting additions, deletions, and changes, which is the exact requirement for seeing the difference.

Exam trap

The trap here is that candidates confuse 'show configuration' (which shows the full candidate config) with 'show | compare' (which shows only the differences), or they mistakenly think 'run show configuration' provides a diff, when it simply runs the same full-config display command from operational mode.

How to eliminate wrong answers

Option A is wrong because 'show configuration' in configuration mode displays the entire candidate configuration, not the difference between candidate and active configurations. Option B is wrong because 'run show configuration' executes the operational mode command 'show configuration' from within configuration mode, which also shows the full candidate configuration, not a comparison. Option D is wrong because 'show system commit' displays the commit history (list of past commits with timestamps and IDs), not a diff between candidate and active configurations.

Practice this question →
4
MCQhard

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?

A.On the primary node, execute 'commit synchronize'.
B.Reboot both nodes to force synchronization.
C.Manually copy the configuration file from primary to secondary.
D.On the secondary node, execute 'commit synchronize'.
AnswerA

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.

Why this answer

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'.

Exam trap

The trap here is that candidates may 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.

How to eliminate wrong answers

Option B is wrong because rebooting both nodes is an unnecessary and disruptive action that would cause traffic loss; it does not directly synchronize the configuration and may not resolve the mismatch if the secondary's configuration remains out of sync. Option C is wrong because manually copying the configuration file from primary to secondary is not a supported or safe method in a cluster; it bypasses Junos's internal synchronization mechanisms and could lead to file corruption or cluster instability. Option D is wrong because executing 'commit synchronize' on the secondary node (node1) is ineffective; the secondary node cannot push its configuration to the primary, and the command would fail or not achieve synchronization since the primary is the authoritative source for cluster configuration.

Practice this question →
5
MCQhard

Scenario: Your company has a Juniper MX Series router at a branch office running Junos 18.4. The device has been in production for two years with a stable configuration. Yesterday, a senior engineer made several changes to the OSPF configuration to optimize routing for a new link. They committed the changes and left for the day. This morning, the branch office experiences intermittent connectivity, and the OSPF neighbor relationships are flapping. You suspect the recent OSPF changes caused the issue. You have remote console access to the router. The goal is to restore network stability as quickly as possible while preserving the ability to re-apply the changes after troubleshooting. Which course of action should you take?

A.Use 'deactivate protocols ospf' to disable OSPF entirely and then manually re-enable pieces.
B.Immediately delete the OSPF configuration sections that were changed and re-add the original settings manually.
C.Use 'rollback 1' to revert to the configuration before the changes, then 'commit confirmed 10' to verify stability.
D.Perform a 'load factory-default' and 'commit' to reset the device to base settings, then reconfigure from backup.
AnswerC

This is the correct approach because rollback 1 reverts the candidate configuration to the last committed configuration prior to the current one, which is exactly the stable state you want. Issuing commit confirmed 10 activates that configuration for 10 minutes; if nothing else is done, the system automatically rolls back to the previous config, ensuring connectivity is restored without a permanent lock-in. You can later issue commit (or commit confirmed again) to make the change permanent once you have verified OSPF stability.

Why this answer

'rollback 1' reverts the active configuration to the previous committed version (before the problematic OSPF changes), and 'commit confirmed 10' applies that rollback with a 10-minute confirmation timer. If connectivity stabilizes, the rollback becomes permanent; if not, the router automatically reverts to the previous configuration, ensuring no prolonged outage. This approach restores stability quickly while preserving the ability to later re-apply and test the OSPF changes in a controlled manner.

Exam trap

The trap here is that candidates may choose Option A (deactivate OSPF) thinking it is a quick fix, but they overlook that deactivating the entire protocol causes a complete routing disruption, whereas 'rollback' with 'commit confirmed' is the precise, safe, and reversible method Junos provides for this exact scenario.

How to eliminate wrong answers

Option A is wrong because 'deactivate protocols ospf' disables the entire OSPF process, which would drop all OSPF adjacencies and potentially cause a complete routing blackout, not just intermittent flapping, and it does not preserve the changed configuration for later re-application. Option B is wrong because manually deleting and re-adding configuration sections is error-prone, time-consuming, and does not leverage Junos's built-in rollback capability, which is the fastest and safest method to revert to a known-good state. Option D is wrong because 'load factory-default' resets the entire device to factory settings, wiping all configurations, including interfaces, security policies, and routing protocols, which would cause a total outage and require full reconfiguration from backup, far exceeding the goal of quickly restoring stability.

Practice this question →
6
MCQmedium

A technician needs to load a new configuration file that replaces only the specific hierarchy paths present in the file, leaving all other existing configuration unchanged. Which load statement is appropriate?

A.load replace
B.load set
C.load override
D.load merge
AnswerD

The 'load merge' command is the correct choice because it combines the contents of the configuration file with the current candidate configuration, adding or updating only the statements present in the file while leaving all other existing configuration untouched. It accepts both hierarchical configuration files and files containing 'set' commands, making it flexible for various file formats. This precisely matches the technician's need to load a new configuration file that applies changes without discarding existing settings.

Why this answer

The 'load merge' command is correct because it merges the contents of the specified configuration file with the current candidate configuration, adding or updating only the hierarchy paths present in the file while preserving all other existing configuration. This matches the requirement to replace only specific hierarchy paths without affecting the rest of the configuration.

Exam trap

The trap here is that candidates often confuse 'load merge' with 'load replace' or 'load override', mistakenly thinking 'replace' means partial replacement, when in fact 'replace' replaces the entire candidate configuration, while 'merge' is the correct command for targeted, non-destructive updates.

How to eliminate wrong answers

Option A is wrong because 'load replace' replaces the entire candidate configuration with the contents of the file, not just specific hierarchy paths. Option B is wrong because 'load set' is used to load a set of configuration commands (in 'set' format) and applies them sequentially, which can add or modify paths but does not inherently restrict changes to only the paths in the file—it can also delete or override if the set commands include 'delete' statements. Option C is wrong because 'load override' completely replaces the entire candidate configuration with the file, discarding all existing configuration.

Practice this question →
7
MCQeasy

A network engineer wants to quickly restore the device to a known good configuration after a failed change. What is the recommended approach?

A.Use the 'request system configuration rescue save' command.
B.Use the 'rollback 0' command.
C.Use the 'rollback rescue' command.
D.Use the 'load override terminal' command.
AnswerC

The 'rollback rescue' command loads the previously saved rescue configuration from the rescue area into the candidate configuration. This is the correct restore mechanism because it explicitly retrieves the snapshot created via 'request system configuration rescue save'. The command does not automatically commit the change; the engineer must still run 'commit' to apply the rescued configuration to the active Janos configuration.

Why this answer

The 'rollback rescue' command restores the device to the rescue configuration, which is a known good configuration saved explicitly for recovery after a failed change. The rescue configuration is stored as a separate file and is not affected by normal commit operations, making it the recommended approach for quick restoration.

Exam trap

The trap here is that candidates confuse 'rollback rescue' with 'rollback 0', mistakenly thinking the most recent committed configuration is always a safe fallback, but 'rollback 0' includes the failed change if it was committed, whereas 'rollback rescue' restores a deliberately saved known good state.

How to eliminate wrong answers

Option A is wrong because 'request system configuration rescue save' is used to save the current active configuration as the rescue configuration, not to restore it; it is a save action, not a restore action. Option B is wrong because 'rollback 0' reverts to the most recently committed configuration, which may include the failed change if it was committed; it does not guarantee a known good state. Option D is wrong because 'load override terminal' is used to load a configuration from terminal input, overwriting the candidate configuration; it is not a quick restore mechanism and requires manual entry or pasting of configuration data.

Practice this question →
8
Multi-Selecthard

Which THREE statements about the 'commit' command are correct?

Select 3 answers
A.The 'commit check' command validates the syntax of the candidate configuration.
B.The 'commit synchronize' command is used on a dual-RE system to commit on both REs.
C.The 'commit full' command activates the configuration without performing any validation.
D.The 'commit' command can only be issued when no other users are in configuration mode.
E.The 'commit confirmed 5' command will roll back the configuration after 5 minutes if not confirmed.
AnswersA, B, E

Correct.

Why this answer

The 'commit check' command validates the syntax and semantics of the candidate configuration without activating it. This allows an administrator to verify that the configuration is valid before committing, preventing potential errors from being applied to the active configuration.

Exam trap

The trap here is that candidates often confuse 'commit full' with a validation-skipping command, when in fact it performs a more thorough validation, and they may incorrectly assume that multiple users cannot commit simultaneously in Junos, unlike some other network operating systems.

Practice this question →
9
MCQmedium

An engineer needs to apply a configuration change to the Junos device that must survive a reboot. Which configuration mode command should be used to save the changes?

A.commit
B.commit confirmed
C.commit synchronize
D.commit check
AnswerA

The 'commit' command permanently activates the candidate configuration by copying it into the active configuration and applying it to the routing and forwarding planes. It also writes the configuration to non-volatile storage (e.g., flash), ensuring it survives a reboot or power cycle. This is the standard, definitive way to make configuration changes persistent in Junos.

Why this answer

The 'commit' command is the standard way to apply a candidate configuration to the active configuration in Junos. When you issue 'commit', the changes are saved to the /config/juniper.conf.gz file, which is loaded upon reboot, ensuring the configuration survives a restart.

Exam trap

The trap here is that candidates may confuse 'commit' with 'commit confirmed', thinking the latter is required for persistence, but 'commit confirmed' is specifically designed for safe rollback during maintenance windows, not for permanent saves.

How to eliminate wrong answers

Option B is wrong because 'commit confirmed' temporarily activates the configuration but automatically rolls back to the previous configuration if not confirmed within the default 10-minute timeout, so it does not guarantee survival across a reboot unless explicitly confirmed. Option C is wrong because 'commit synchronize' is used in a chassis cluster to commit the configuration on both nodes simultaneously; it is not a general-purpose command for saving changes on a standalone device. Option D is wrong because 'commit check' only validates the syntax and semantics of the candidate configuration without applying or saving it, so no changes survive a reboot.

Practice this question →
10
MCQhard

In a dual Routing Engine (RE) setup, an engineer commits a configuration change that should be applied to both REs synchronously. What is the correct command to ensure both REs receive the same configuration immediately?

A.commit confirmed
B.commit check synchronize
C.commit and-quit
D.commit synchronize
AnswerD

This commits the candidate configuration to both Routing Engines in a single atomic operation, ensuring both have identical active configurations. It is the standard command for applying changes in a dual-RE chassis, and it is essential for maintaining consistency and enabling clean failover. The commit is performed on the local RE and the other RE simultaneously.

Why this answer

The 'commit synchronize' command commits the configuration on the master Routing Engine and then automatically copies and commits the same configuration to the backup RE, ensuring both REs have identical active configurations immediately. This is the standard Junos method for synchronizing configurations in a dual-RE chassis.

Exam trap

The trap here is that candidates confuse 'commit synchronize' with 'commit check' or 'commit confirmed', not realizing that only 'commit synchronize' explicitly pushes the configuration to the backup RE in a dual-RE setup.

How to eliminate wrong answers

Option A is wrong because 'commit confirmed' is used to automatically roll back a commit after a specified timeout if not confirmed, not for synchronizing configurations between REs. Option B is wrong because 'commit check synchronize' is not a valid Junos command; 'commit check' validates syntax but does not apply changes, and the 'synchronize' option is only valid with 'commit'. Option C is wrong because 'commit and-quit' is used in configuration mode to commit and exit, but it does not synchronize the configuration to the backup RE.

Practice this question →
11
MCQhard

A company has a Juniper MX router acting as a BGP route reflector. The router has two routing instances: 'internet' and 'management'. The 'internet' instance uses a firewall filter to block traffic to the router's loopback address from external sources. After a recent configuration change, the engineer notices that SSH access to the router's loopback IP (10.0.0.1) from the internal management network (192.168.0.0/16) is being dropped. The firewall filter for the loopback interface in the 'internet' instance is correctly configured to allow traffic from 192.168.0.0/16. The management instance has no firewall filter applied. The engineer suspects that the issue is related to how the routing instances interact with the loopback interface. Which of the following is the most likely cause and solution?

A.The management instance needs a firewall filter that allows SSH; add a filter to the management instance's loopback.
B.The firewall filter in the 'internet' instance incorrectly blocks SSH; modify the filter to allow SSH from any source.
C.The BGP configuration is causing the loopback to be unreachable; disable BGP on the management instance.
D.The firewall filter applied to the loopback interface is shared across all routing instances; use a separate interface for management traffic or apply the filter only to the 'internet' instance's logical system.
AnswerD

The loopback interface is shared; the filter affects all traffic to the loopback.

Why this answer

In Junos, firewall filters applied to the loopback interface (lo0) are shared across all routing instances by default because the loopback is a single physical interface. Even though the filter is configured in the 'internet' instance, it affects traffic destined to the loopback IP from any instance, including the 'management' instance. To isolate management traffic, you must either use a separate physical interface or apply the filter only to the 'internet' instance's logical system (e.g., using a firewall filter with a routing-instance match condition).

Exam trap

The trap here is that candidates assume firewall filters are instance-specific on the loopback interface, but Junos applies them globally by default, leading to the misconception that adding a filter to the management instance or modifying the existing filter will solve the problem.

How to eliminate wrong answers

Option A is wrong because the management instance has no firewall filter, and adding one would not resolve the issue—the problem is that the filter from the 'internet' instance is blocking traffic. Option B is wrong because the filter is correctly configured to allow SSH from 192.168.0.0/16; modifying it to allow SSH from any source would violate security policy and does not address the root cause of filter sharing. Option C is wrong because BGP configuration does not inherently cause the loopback to be unreachable; BGP is a routing protocol and does not affect firewall filter application on the loopback interface.

Practice this question →
12
MCQeasy

A network engineer needs to make a change to a Junos device and ensure the change can be reverted if it causes issues. Which feature should be used?

A.configure exclusive
B.commit confirmed
C.commit check
D.rollback 0
AnswerB

The `commit confirmed` operation commits the candidate configuration and starts a rollback timer (default 10 minutes, up to 285 minutes with `commit confirmed <minutes>`). If the engineer does not issue a confirming `commit` or `commit confirm` before the timer expires, Junos automatically reverts to the previous active configuration. This provides a safety net for testing break-fix changes, making it the correct answer.

Why this answer

The `commit confirmed` command allows an engineer to commit a configuration change with a timer (default 10 minutes). If the change causes issues and the engineer does not confirm the commit within the timer, the device automatically reverts to the previous active configuration. This provides a safety net to revert changes without manual intervention.

Exam trap

The trap here is that candidates may confuse `commit confirmed` with `rollback 0`, thinking both revert changes, but `rollback 0` is a manual step that does not provide automatic, time-based reversion.

How to eliminate wrong answers

Option A is wrong because `configure exclusive` locks the candidate configuration to a single user, preventing others from making changes, but it does not provide any automatic rollback mechanism if the change causes issues. Option C is wrong because `commit check` validates the syntax and semantics of the candidate configuration without committing it; it does not revert a change after it has been applied. Option D is wrong because `rollback 0` reverts to the most recently committed configuration, but this is a manual action and does not provide an automatic, time-based revert if the change causes issues.

Practice this question →
13
MCQhard

Refer to the exhibit. What is the most likely cause of the error?

A.The IP address 1.1.1.1/32 is already in use.
B.The candidate configuration has no errors and this is a warning.
C.The policy-statement 'test' contains a syntax error in the protocol match condition.
D.The commit check command requires user confirmation.
AnswerC

The error indicates 'protocol is not valid' in the policy-statement.

Why this answer

The error message in the exhibit indicates a syntax error in the policy-statement 'test' when using the protocol match condition. In Junos, the 'protocol' match condition requires a valid protocol name (e.g., 'bgp', 'ospf', 'static'), and if an invalid or misspelled protocol is specified, the commit check fails with a syntax error. This is a common mistake when configuring policy-options, as the Junos CLI validates the protocol against a predefined list.

Exam trap

The trap here is that candidates may misinterpret a syntax error as a warning or an IP conflict, because Junos error messages can be verbose, but the key is to identify the specific line number and the 'syntax error' keyword in the output, which points directly to a configuration mistake in the policy-statement.

How to eliminate wrong answers

Option A is wrong because the error message does not indicate an IP address conflict; a '1.1.1.1/32 already in use' error would appear as a commit error with a specific message about duplicate address, not a syntax error in a policy statement. Option B is wrong because the candidate configuration contains an actual syntax error, not a warning; Junos warnings are typically informational (e.g., 'warning: statement ... is deprecated') and do not prevent a successful commit check, whereas this error blocks the commit. Option D is wrong because the commit check command does not require user confirmation; it validates the configuration and reports errors without prompting for confirmation, and the exhibit shows an error output, not a confirmation prompt.

Practice this question →
14
MCQhard

During a maintenance window, an engineer issues 'commit confirmed 5' but the change causes a connectivity loss. The engineer is unable to reconnect to the device before the timeout expires. What will happen?

A.The engineer must manually rollback using the rollback command.
B.The change remains committed until the next reboot.
C.The device reloads with factory defaults.
D.The device automatically reverts to the previous active configuration.
AnswerD

Commit confirmed automatically rolls back after the timeout if not confirmed.

Why this answer

The 'commit confirmed 5' command activates a candidate configuration and starts a 5-minute rollback timer. If the engineer does not issue a 'commit' or 'commit check' before the timer expires, Junos automatically reverts to the previously active configuration. This ensures the device returns to a known working state without manual intervention, preserving connectivity after the failed change.

Exam trap

The trap here is that candidates may think a 'commit confirmed' requires a manual rollback command (Option A) or that the change persists until a reboot (Option B), but Junos automatically reverts the configuration upon timeout, making it a safety mechanism for remote changes.

How to eliminate wrong answers

Option A is wrong because the automatic rollback occurs without requiring manual intervention; the engineer does not need to use the 'rollback' command after the timeout. Option B is wrong because a confirmed commit is explicitly designed to not remain committed; it automatically reverts if not confirmed, so the change does not persist until the next reboot. Option C is wrong because the device does not reload with factory defaults; it reverts only to the previous active configuration, not to a factory-reset state.

Practice this question →
15
MCQhard

A network engineer accidentally committed a configuration on a Juniper router that caused a loss of management access via SSH and SNMP. The engineer has console access and the device is still operational. Before the change, the engineer had saved a rescue configuration using 'request system configuration rescue save'. Which action should the engineer take to restore management access most quickly?

A.At the shell prompt, execute 'cli -c "rollback rescue"' and then commit.
B.At the configuration mode, execute 'rollback 0'.
C.Power cycle the device; it will automatically boot with the rescue configuration.
D.Reboot the device and press the space bar to load the rescue configuration.
AnswerA

This loads the rescue configuration without rebooting.

Why this answer

The 'request system configuration rescue save' command stores a rescue configuration that can be rolled back to using 'rollback rescue' in configuration mode. Since the engineer has console access, they can enter configuration mode and execute 'rollback rescue' followed by 'commit' to instantly revert to the last known working configuration, restoring SSH and SNMP access without requiring a reboot.

Exam trap

The trap here is that candidates may confuse 'rollback rescue' with a boot-time recovery mechanism, assuming the rescue configuration loads automatically on reboot, when in fact it requires a manual command after the device is operational.

How to eliminate wrong answers

Option B is wrong because 'rollback 0' reverts to the most recently committed configuration, which is the same problematic configuration that caused the loss of management access, so it would not restore connectivity. Option C is wrong because power cycling the device does not automatically load the rescue configuration; Junos boots from the active file system (e.g., 'junos.conf') unless explicitly instructed otherwise via the boot loader or a rescue configuration load during boot. Option D is wrong because pressing the space bar during boot interrupts the normal boot process to access the loader prompt, but it does not automatically load the rescue configuration; the rescue configuration must be explicitly loaded via the 'load rescue' command in the loader or after booting into the operating system.

Practice this question →
16
Multi-Selecteasy

Which TWO statements about configuration archival in Junos are true?

Select 2 answers
A.Archival stores the candidate configuration.
B.The 'system archival' hierarchy enables automatic backup of configurations.
C.Archival only saves the rescue configuration.
D.Archival can use FTP or SCP to transfer files.
E.Archival automatically archives after every commit without any configuration.
AnswersB, D

This configuration block defines archival settings.

Why this answer

The 'system archival' hierarchy in Junos is specifically designed to enable automatic backup of configuration files. This feature allows administrators to configure periodic transfers of committed configurations to a remote server, ensuring configuration history is preserved without manual intervention.

Exam trap

The trap here is that candidates often confuse the candidate configuration with the committed configuration, assuming archival saves the uncommitted changes, when in fact it only archives the active committed configuration after a successful commit.

Practice this question →
17
MCQmedium

A network engineer needs to restore the factory-default configuration on a Junos device. Which command sequence is correct?

A.set system host-name factory-default
B.request system zeroize
C.load factory-default and then commit
D.delete configuration and reboot
AnswerC

`load factory-default` loads the vendor-provided factory-default configuration file into the candidate configuration, replacing all existing candidate settings. The subsequent `commit` promotes that candidate to the active (committed) configuration, thereby returning the device to its out-of-box state without erasing logs or other non-configuration files. This is the standard, supported procedure for restoring factory defaults on a Junos device.

Why this answer

The correct command sequence to restore factory-default configuration on a Junos device is 'load factory-default' followed by 'commit'. The 'load factory-default' command replaces the current candidate configuration with the factory-default configuration, but it does not take effect until a 'commit' is issued. This ensures the device reverts to its original settings without affecting the currently running configuration until explicitly committed.

Exam trap

The trap here is that candidates confuse 'load factory-default' with 'request system zeroize', thinking both achieve the same result, but 'zeroize' is a security wipe that destroys all data and requires a reboot, while 'load factory-default' is a configuration-only reset that is committed without rebooting.

How to eliminate wrong answers

Option A is wrong because 'set system host-name factory-default' only changes the hostname to 'factory-default', it does not restore the entire configuration to factory defaults. Option B is wrong because 'request system zeroize' is used to erase all data, including configuration files, logs, and user data, for security purposes before decommissioning a device; it does not simply restore factory-default configuration and requires a reboot to complete. Option D is wrong because 'delete configuration and reboot' is not a valid Junos command sequence; deleting the configuration without using 'load factory-default' would leave the device with an empty configuration, potentially causing boot issues or requiring manual recovery.

Practice this question →
18
Multi-Selecthard

Which TWO statements about configuration groups in Junos are correct? (Choose two.)

Select 2 answers
A.Configuration groups are defined under the [edit groups] hierarchy.
B.Configuration groups are stored in separate files that are imported using the 'file' statement.
C.The 'apply-groups' statement is used to include a group's configuration at a specific hierarchy level.
D.The 'replace' tag is used to reference a configuration group.
E.Configuration groups are applied only at the [edit interfaces] hierarchy level.
AnswersA, C

Configuration groups are indeed defined under the 'groups' hierarchy and can be inherited.

Why this answer

Configuration groups in Junos are defined under the [edit groups] hierarchy. This allows you to create reusable configuration snippets that can be applied to multiple parts of the configuration, reducing duplication and simplifying management.

Exam trap

The trap here is that candidates often confuse configuration groups with Junos's 'apply-path' or 'apply-macro' features, or mistakenly think groups are external files, when in fact they are defined inline under [edit groups] and applied via 'apply-groups'.

Practice this question →
19
MCQeasy

Which configuration group feature allows an administrator to apply common configuration settings to multiple interfaces without repeating the configuration?

A.groups statement
B.interface-range
C.apply-groups
D.apply-path
AnswerC

The "apply-groups" statement is the correct feature; it references a named group defined under the "groups" hierarchy and applies that group's configuration to the current hierarchy level. When placed at a particular level, it causes the configuration from the referenced group to be merged or overlaid, providing inheritance and override capabilities. This is the standard method for reusing configuration blocks and applying them to multiple levels.

Why this answer

The `apply-groups` statement is the correct feature because it allows an administrator to define a common configuration template within a `groups` hierarchy and then apply that template to multiple interfaces (or other configuration sections) using the `apply-groups` command. This avoids repeating the same configuration statements across individual interfaces, streamlining management and reducing errors.

Exam trap

The trap here is that candidates confuse `groups` (the definition container) with `apply-groups` (the activation command), often selecting Option A because they think defining the group is sufficient, but without `apply-groups`, the group configuration is never applied.

How to eliminate wrong answers

Option A is wrong because `groups` is the container where common configuration is defined, but it is not the feature that applies the configuration to interfaces; without `apply-groups`, the group configuration is inactive. Option B is wrong because `interface-range` is a feature for creating a named range of interfaces to apply a single configuration block, but it is not a configuration group feature; it is used with `set interfaces interface-range <name>` and applies configuration directly, not via a reusable group template. Option D is wrong because `apply-path` is used to dynamically derive configuration values from the contents of a specified path in the configuration hierarchy (e.g., for BGP or firewall filters), not for applying common settings to multiple interfaces.

Practice this question →
20
MCQhard

An engineer is designing a network and needs to ensure that management traffic (SSH, SNMP) is always permitted, even if an interface firewall filter is applied. Which Juniper best practice should be followed?

A.Use a firewall filter that permits all management traffic at the top of the list on each interface
B.Apply a firewall filter on the loopback interface (lo0) to protect the device
C.Apply a firewall filter to the management interface (fxp0)
D.Disable the firewall filter on all interfaces
AnswerB

The loopback interface (lo0) represents the device's control plane, and all traffic destined to the device's own IP addresses—such as SSH, SNMP, BGP, and OSPF—is processed through it, regardless of the physical ingress interface. Applying a firewall filter to lo0 in the input direction provides a single, centralized point to secure management and routing protocol access. This Juniper-recommended practice ensures consistent protection and simplifies administration, as the filter is applied once rather than on every interface.

Why this answer

Applying a firewall filter to the loopback interface (lo0) is the Juniper best practice for protecting management traffic because the loopback interface is the logical termination point for all control plane traffic, including SSH and SNMP. This ensures that management traffic is always permitted regardless of which physical interface it arrives on, while still allowing interface-specific filters to be applied for data plane traffic without risk of blocking management access.

Exam trap

The trap here is that candidates often think management traffic must be permitted on each physical interface individually (Option A), not realizing that Junos uses the loopback interface as the central control plane filter point, making interface-specific filters unnecessary for management access.

How to eliminate wrong answers

Option A is wrong because placing a firewall filter that permits all management traffic at the top of the list on each interface is not scalable and can inadvertently allow unwanted traffic if the filter is misconfigured or omitted on a new interface; it also violates the principle of separating control plane and data plane filtering. Option B is wrong because it is actually the correct answer, not a wrong option. Option C is wrong because applying a firewall filter to the management interface (fxp0) only protects traffic arriving on that dedicated management port, but management traffic like SSH and SNMP can also arrive on other interfaces (e.g., ge-0/0/0), leaving the device unprotected on those paths.

Option D is wrong because disabling firewall filters on all interfaces removes all traffic filtering, which is not a best practice and would expose the device to unauthorized access or attacks.

Practice this question →
21
MCQhard

A company has two Juniper routers in a high-availability cluster with dual Routing Engines. The administrator performs a commit on the primary RE. What is the effect of using the 'commit synchronize' command?

A.It performs a commit check on both REs but does not activate the config.
B.It commits the configuration on both Routing Engines simultaneously.
C.It commits the configuration only on the primary RE.
D.It commits the configuration only on the backup RE.
AnswerB

The correct behavior is 'commit synchronize', a Junos command that loads and activates the candidate configuration on both the primary and backup Routing Engines simultaneously, ensuring they operate with identical active configurations. This is critical for high-availability clusters because it prevents config drift, so failover to the backup will use the same settings and policies as the primary. The simultaneous commit minimizes the window of inconsistency and is the standard method for configuring both REs in one operation.

Why this answer

The 'commit synchronize' command on Juniper routers with dual Routing Engines ensures that the configuration is committed on both the primary and backup REs simultaneously. This is critical for maintaining configuration consistency in a high-availability cluster, as it prevents a split-brain scenario where the backup RE has a different active configuration than the primary. The command performs a full commit (including validation and activation) on both REs, not just a check.

Exam trap

The trap here is that candidates often confuse 'commit synchronize' with 'commit check' or assume it only affects one RE, failing to recognize that Juniper's high-availability design requires explicit synchronization to maintain configuration consistency across both Routing Engines.

How to eliminate wrong answers

Option A is wrong because 'commit synchronize' performs a full commit (validation and activation) on both REs, not just a commit check; the 'commit check' command is used for validation only. Option C is wrong because 'commit synchronize' explicitly commits on both REs, not only the primary; committing only on the primary would leave the backup out of sync. Option D is wrong because 'commit synchronize' commits on both REs, not only the backup; committing only on the backup would not update the primary's active configuration.

Practice this question →
22
Multi-Selecteasy

Which TWO statements about configuration storage in Junos are true?

Select 2 answers
A.The rescue configuration is stored in /config/rescue.conf.gz.
B.The rollback configurations are stored in /config/juniper.conf.0.gz, .1.gz, etc.
C.The active configuration is stored in /config/juniper.conf.gz.
D.The candidate configuration is stored in /config/.
E.The factory default configuration is stored in /etc/config/.
AnswersA, C

Rescue configuration is a special saved configuration.

Why this answer

The rescue configuration is stored as a compressed file at /config/rescue.conf.gz on Junos devices. This configuration is saved using the 'request system configuration rescue save' command and can be loaded with 'rollback rescue' to recover from a configuration that prevents the device from booting properly.

Exam trap

The trap here is that candidates often confuse the numbering of rollback files (thinking .0.gz is a rollback instead of the active configuration) or assume the candidate configuration is stored persistently on disk rather than existing only in memory until committed.

Practice this question →
23
MCQmedium

A network operations team has received a new Juniper router to replace an existing legacy router. The team needs to apply a baseline configuration that includes system settings, interfaces, and security policies. The configuration is provided as a text file containing Junos configuration hierarchy syntax (e.g., 'system { host-name... }'). The engineer connects to the console and sees the prompt 'root@%'. What is the most efficient way to apply the configuration?

A.Use the 'load set' command to load a set of configuration commands.
B.Use FTP to transfer the file and then commit.
C.Enter configuration mode and manually type each command.
D.Use the 'load merge' command to merge the configuration file.
AnswerD

The 'load merge' command is the correct choice because it reads a configuration file in the Junos hierarchy format and merges its contents into the current candidate configuration. This is the standard way to apply a full or partial configuration file without wiping out existing settings; overlapping statements are updated while untouched parts remain intact. After the merge, the candidate can be reviewed and then committed with 'commit'.

Why this answer

The engineer is at the shell prompt (root@%), not in configuration mode. The 'load merge' command is used within configuration mode to merge a configuration file (in Junos hierarchy syntax) into the candidate configuration, which is the most efficient way to apply a pre-written baseline configuration without manual typing or complex file transfers.

Exam trap

The trap here is that candidates may confuse the shell prompt (root@%) with the configuration mode prompt (root@#) and attempt to use 'load merge' directly at the shell, which fails; they must first enter configuration mode with 'configure' or 'edit' before loading the file.

How to eliminate wrong answers

Option A is wrong because 'load set' is used to load a file containing 'set' commands (flat format), not the hierarchical configuration syntax provided; using it on a hierarchy file would cause syntax errors. Option B is wrong because FTP transfer is unnecessary and inefficient; Junos supports loading configuration files directly from local storage or via SCP/HTTP, and FTP adds security risks and extra steps. Option C is wrong because manually typing each command is time-consuming and error-prone, defeating the purpose of having a pre-written configuration file.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Junos Configuration Basics questions.

Start 20-question session