Junos OS Fundamentals practice questions

save

Why wrong: In Junos, `save` is not a command for activating configuration changes; it is typically used within configuration mode to write the candidate configuration to a file (e.g., `/var/tmp/config`) for backup or archive. This action only copies the configuration text to the specified destination—it does not validate, activate, or persist the changes as the running configuration. Therefore, using `save` would leave the device running its previous active configuration and the changes vulnerable to loss.

request system reboot

Why wrong: `request system reboot` is a valid operational command that restarts the Junos device, but it never saves or activates the candidate configuration. If you have made configuration changes and only issued this command, those changes are discarded because they exist only in the candidate store until committed. A reboot loads the last committed configuration from the persistent store, so the device returns to the previous active state—it does not preserve uncommitted edits.

show configuration

Why wrong: The `show configuration` command displays the current active configuration (or, with the `| display` modifiers, the candidate configuration) as formatted text for inspection. It is purely read-only and performs no writes to any configuration database, so it cannot persist changes across reboots or alter the running state. This command is useful for verification, but it is not a substitute for committing configuration.

delete configuration

Why wrong: 'delete configuration' is not a recognized command in Junos. Junos uses configuration mode commands such as 'delete interfacename' or 'set' to modify specific configuration statements, but there is no single command to delete the entire running configuration in one step. The only valid way to revert to a previous state is to use rollback, which is an operational mode command for configuration management.

load override

Why wrong: The 'load override' command is designed to load a complete configuration from a file or URL, replacing the entire candidate configuration with the contents of that saved configuration file. It will not automatically revert to the last committed configuration unless you happen to have saved that exact configuration to a file, which is not the typical scenario for discarding uncommitted changes. This command is useful for restoring a known-good configuration from an archive, but it does not serve the same purpose as a quick rollback.

rollback 1

Why wrong: 'rollback 1' reverts the candidate configuration to the configuration that existed at the previous commit, which is the commit before the current active configuration. If you have uncommitted changes on top of the current committed config, rolling back to 1 would bring back an older configuration and discard the current committed state, which is not what you want. Only 'rollback 0' targets the actual active configuration and is the correct choice for discarding uncommitted changes without altering the last committed state.

request support information

Why wrong: request support information is an operational command that bundles configuration, logs, system statistics, and core files into a single archive, typically for transmission to Juniper Technical Assistance Center (JTAC) or for post-mortem analysis. It is not a targeted diagnostic for immediate high-CPU investigation because it gathers a broad, time-consuming snapshot of the entire system and may take several minutes to complete, during which the command itself can add CPU overhead. Additionally, its output is written to a tar archive (e.g., a .tgz file) rather than displayed in a real-time manner, so the operator cannot interactively sort or drill down into process-level CPU data.

show bgp summary

Why wrong: show bgp summary provides an overview of BGP peering sessions, including neighbor IP addresses, peer AS numbers, up/down times, state (Established/Active), and the number of routes sent and received per peer. While a BGP-related issue (such as route churn or a flapping peer) can cause high CPU utilization in the routing protocol daemon, this command only reveals the external symptoms of those sessions, not the CPU consumption of the underlying processes. It does not display process-level metrics or system-wide CPU usage, so it cannot conclusively identify whether excessive CPU is actually being caused by BGP processing or by another subsystem.

monitor traffic interface

Why wrong: monitor traffic interface puts the specified interface into packet-capture mode and streams packet headers and payload data to the terminal in real time, similar to a built-in tcpdump. The output is focused on network traffic content—source/destination addresses, protocol, port, and raw packet bytes—and has no bearing on process list or CPU consumption. High CPU may occur due to heavy traffic being punted to the Route Engine, but this command shows only the packets themselves, not the computational cost or the specific process responsible, so it is unsuitable for determining why the device's CPU is elevated.

show chassis hardware

Why wrong: `show chassis hardware` displays hardware inventory details such as chassis serial number, Routing Engine model, FPCs, power supplies, and fans by reading hardware EEPROMs. It does not access or display any part of the active configuration, candidate configuration, or committed configuration. This command is strictly for physical component verification, not for inspecting device settings or operational parameters, so it cannot satisfy the requirement to view the current active configuration.

show interfaces terse

Why wrong: `show interfaces terse` provides a concise, tabular summary of interface names, administrative status, link status, protocol family, and local addresses. It focuses exclusively on the interface subsystem and does not output the rest of the configuration, such as routing protocols, firewall filters, system settings, or security policies. While it may confirm which interfaces are configured, it is not a complete representation of the active configuration and therefore is an incorrect choice for viewing the full configuration.

show system commit

Why wrong: `show system commit` displays the commit history, including the commit sequence number, timestamp, username, and optional commit comment for each commit operation. This command provides metadata about when and by whom configuration changes were committed, but it does not output the configuration content itself, nor does it show the current active configuration. It is used for auditing or rollback decisions, not for viewing the configuration, so it is incorrect for this task.

request system configuration rescue save

Why wrong: This command saves the current active configuration as the rescue configuration, which is used for recovery from commit errors or system instabilities. It does not load or merge any changes from an external file; instead, it overwrites the rescue configuration with the running configuration. Therefore, executing it would not apply /var/tmp/changes.txt, and it could unintentionally replace a previously saved rescue configuration, undermining its purpose.

load override /var/tmp/changes.txt; commit

Why wrong: The load override command replaces the entire candidate configuration with the contents of the specified file. Since changes.txt presumably contains only the incremental modifications and not the full device configuration, all existing statements not present in the file would be removed. The subsequent commit would then activate this stripped-down configuration, deleting critical settings like interfaces, routing protocols, or security policies, and potentially causing a major outage. This approach is too destructive for applying a maintenance change; a merge is required.

configure; load patch /var/tmp/changes.txt; commit

Why wrong: The load patch command is intended specifically for applying an XML patch file, which represents configuration differences in a structured XML format (e.g., generated with `show configuration | display patch`). It is not designed for plain-text configuration snippets or 'set' command lists. If changes.txt is a standard text configuration, load patch will either raise a syntax error or apply the patch incorrectly because the file does not conform to the expected XML patch schema. Thus, this command is unsuitable for the task.

The rescue configuration is not set.

Why wrong: The rescue configuration is a snapshot saved specifically for disaster recovery; it is not involved in the normal process of saving or applying configuration changes. Setting or not setting a rescue configuration has no effect on whether changes in the candidate configuration are committed to the active configuration. Thus, the absence of a rescue configuration is not the reason the device's changes are not being saved.

The device is booting from factory-default configuration.

Why wrong: Booting from factory-default would require that the device were explicitly reset or that no valid committed configuration existed, which is not the case in this scenario. A Junos device normally boots with the last committed configuration stored in /config/juniper.conf.gz, not from factory defaults, unless someone issued 'load factory-default' or similar. Even if the device were booting from default, the real problem remains that the candidate changes were never committed to the active configuration.

The command 'request system reboot' was used instead of 'commit'.

Why wrong: Using 'request system reboot' without first committing the candidate configuration will indeed cause uncommitted changes to be lost, but the command itself is not the root cause; it is merely the event that triggered the loss. A reboot does not alter or erase the committed configuration, so if the changes had been committed first they would survive the reboot. The underlying issue is the failure to run 'commit', which is what actually saves the changes.

Each change is applied incrementally to the active configuration.

Why wrong: This statement is false because Junos never applies edits directly to the active configuration. Instead, all changes are made to a separate candidate configuration, and a commit applies the entire candidate as a single atomic operation. Therefore, changes are not incremental; they are batched until commit, and no partial changes affect the running configuration.

The candidate configuration is stored in a separate file from the active configuration.

Why wrong: This statement is false because Junos stores the active and candidate configurations in the same configuration database, not as separate files. The candidate is a working copy of the active configuration with your pending edits, maintained in the system's memory and configuration store. There is no distinct file for the candidate; it is a logical copy within the same database.

After a commit, the candidate configuration is automatically discarded.

Why wrong: This statement is false because after a commit, the candidate configuration is promoted to become the new active configuration. It is not discarded; rather, the active configuration is replaced by the candidate, and the candidate continues to exist as the current active configuration. If you want to discard changes, you must explicitly issue a rollback command before committing.

show configuration

Why wrong: 'show configuration' is an operational command, but it only displays the candidate or active configuration hierarchy; it does not perform active network diagnostics like probing endpoints. It is used for configuration verification and review, not for live reachability or path analysis. Since the question specifically asks for diagnostic commands, this option is incorrect.

request system reboot

Why wrong: 'request system reboot' is a system control command that restarts the device or a specific component, such as a line card or routing engine. It is an operational command but not a diagnostic tool; it changes device state/availability rather than gathering network information. It is not used to test reachability or analyze traffic.

It schedules the configuration to be applied at a later time.

Why wrong: A standard commit operation applies the candidate configuration immediately, not at a later time. To defer activation, Junos provides the 'commit at' command, which schedules a commit for a specified date/time, or 'commit delay' to stage the change for a short interval. The base 'commit' command itself has no scheduling behavior; it acts synchronously as soon as it is issued.

It discards the candidate configuration after saving.

Why wrong: When a commit is executed, the candidate configuration is not discarded; instead, it is promoted to become the active configuration. After the commit completes, the candidate and active configurations are identical, and the system continues to use the newly committed settings. The candidate configuration remains available for further edits, and a subsequent 'rollback' can revert to a previous configuration, so nothing is lost.

It automatically reboots the device to apply the changes.

Why wrong: Committing a configuration does not reboot the device; Junos dynamically applies changes to the running processes without restarting the system. Many configuration changes, such as interface settings or routing policies, are applied on the fly and take effect immediately. Only a few rare changes (like certain system hardware parameters) might require a reboot, but the commit itself never triggers a reboot.

A firewall filter is blocking ICMP traffic.

Why wrong: The exhibit shows no firewall filter configuration or any applied filter that could drop ICMP. In Junos, firewall filters are explicitly configured and applied to interfaces; without such a filter, the packet would not be dropped by a local filter. A ping failure more likely points to routing or neighbor reachability issues, not an invisible filter.

The interface is disabled at the unit level.

Why wrong: A unit-level disable would be indicated by a 'disable' statement under the logical unit configuration, and the operational status would typically show the unit as down or disabled. The exhibit does not display any such configuration, and the unit appears operationally active. In Junos, disabling a logical unit is an administrative action that would be explicitly configured, not assumed.

The interface is administratively down.

Why wrong: The exhibit explicitly shows the administrative status as 'up', which indicates the interface is not administratively down. In Junos, an administratively down interface would have an admin status of 'down' and would require a 'disable' statement in the configuration. Since this is not the case, the problem lies elsewhere, such as the remote destination being unreachable.

Immediately shut down all BGP peers to stop the influx of routes.

Why wrong: Shutting down all BGP peers is a drastic measure that halts route exchange but also disrupts production traffic, causing session flaps and potential packet loss. This action does not help diagnose the underlying memory issue; it only temporarily stops new routes from arriving while leaving the existing oversized routing table untouched. As a diagnostic step, it fails to provide insight into which peers or routes are consuming memory, making it both risky and uninformative.

Configure a prefix limit on all BGP peers.

Why wrong: Configuring a prefix limit on all BGP peers is a preventive policy control that restricts the number of routes accepted per peer, but it does not reveal current memory usage or the characteristics of already-learned routes. While it can mitigate future route influx, it is not a diagnostic command and may drop legitimate routes if thresholds are set incorrectly. For immediate diagnosis of memory exhaustion without disrupting traffic, this option is a management action rather than a troubleshooting step.

Use the 'show route summary' command to check the routing table size and memory usage.

Why wrong: The 'show route summary' command displays aggregate route counts per protocol and the memory consumed by the routing table, enabling you to quickly confirm whether the routing table is oversized. This non-disruptive command helps identify which protocol (e.g., BGP) is contributing the most prefixes and whether memory exhaustion is indeed caused by route volume. It also provides a baseline for further investigation, such as using 'show route protocol bgp' or 'show route prefix-length' to pinpoint specific problem routes, without affecting active traffic.

show interfaces terse

Why wrong: The 'show interfaces terse' command provides a concise summary of all interfaces on the device, including their admin/operational status and any assigned IP addresses. It is a general interface visibility tool and contains no information about firewall filter configuration, packet counters, or the log entries that would reveal why traffic is being dropped by a filter. Therefore, it cannot be used to identify which filter term is denying traffic and preventing forwarding.

show firewall filter counter

Why wrong: The 'show firewall filter counter' command displays only the aggregate packet and byte counts for filter terms that have a 'count' action configured. It does not show per-packet log entries that include timestamps, source/destination IP addresses, or port information, so it cannot tell the engineer which specific packets are being dropped or why the drop is occurring. It only indicates that a counter is incrementing, not the forwarding details needed for a diagnosis.

show firewall filter log

Why wrong: The 'show firewall filter log' command is the operational command that displays the logs of packets that matched filter terms configured with either 'log' or 'syslog' actions. Each log entry includes the timestamp, interface, source and destination IP addresses and ports, protocol, and the action taken (permit or deny), giving the engineer direct visibility into which packets were dropped by the filter. This is the correct command to identify why a Junos device is not forwarding traffic due to firewall filter drops.

Both routes have a preference of 0.

Why wrong: The default preference of a static route in Junos is 5, not 0. In the exhibit, the [Static/5] notation explicitly shows that both routes carry a preference value of 5. A preference of 0 is reserved for directly connected interfaces (and certain special routes), so it would never appear for a configured static route unless explicitly set to 0, which is not the case here. Therefore, stating both routes have a preference of 0 misreads the [Static/5] tag.

Only the 10.0.1.0/24 route is active.

Why wrong: Both routes in the exhibit are marked with the '*' next-hop flag, which is Junos' way of indicating that a route is active and selected for forwarding. The 10.0.1.0/24 route is active, but so is the 10.0.2.0/24 route; the asterisk appears on both entries. A route could become inactive if its next hop becomes unreachable, but nothing in the exhibit suggests that either next hop is down. Choosing only 10.0.1.0/24 ignores the matching asterisk on the second route.

Both routes use the same next-hop IP address.

Why wrong: The exhibit shows two different next-hop IP addresses: 192.168.1.1 for the 10.0.1.0/24 route and 192.168.1.2 for the 10.0.2.0/24 route. In Junos, a static route's next hop is configured individually, and there is no requirement that multiple static routes point to the same gateway. The routing table output lists each route with its own next hop, and the two values are visibly different. Thus, the claim that both routes use the same next-hop IP address contradicts the output.

show configuration interfaces

Why wrong: Incorrect. 'show configuration interfaces' displays the configuration, not operational status.

show interfaces terse

Why wrong: Incorrect. 'show interfaces terse' provides a summary but does not include error counters.

show interface descriptions

Why wrong: Incorrect. 'show interface descriptions' shows only interface descriptions, not operational status or error counters.

0

Why wrong: 0 is incorrect because the route 192.168.1.0/24 has next hops configured.

3

Why wrong: 3 is incorrect because there are only two next-hop addresses, not three. Candidates may mistakenly count lines or include a local interface.

1

Why wrong: 1 is incorrect because there are two next hops, one via 10.0.0.2 and another via 10.0.0.3, not just one.

/altroot: Contains software packages

Why wrong: This is incorrect because /altroot is not a storage location for software packages; instead, it is an alternate root filesystem used for backup and recovery. If the primary root becomes corrupted, /altroot provides a minimal boot environment to recover the system. Installed Junos software packages are actually mounted under /packages, which contains the individual package directories for the OS components.

/packages: Backup root filesystem

Why wrong: This is incorrect because /packages is not a backup root; it is the mount point for the installed Junos software packages. The /packages directory contains subdirectories for each installed package, such as the kernel and base OS components, which are loaded as part of the boot process. The backup root filesystem is /altroot, a separate recovery environment used if the primary root fails.

show chassis hardware

Why wrong: The 'show chassis hardware' command is designed to inventory physical components such as the Routing Engine, PICs, power supplies, and their serial numbers and revision levels. It does not display the logical system hostname because the hostname is a configuration property, not a hardware attribute. While some hardware outputs may include a device name in a banner or header, that is incidental and not a reliable or intended method for hostname lookups, making this option incorrect for the task.

show configuration system host-name

Why wrong: The 'show configuration system host-name' command is valid only in configuration mode and displays the hostname as defined in the candidate or committed configuration, not necessarily the active operational hostname if an uncommitted change exists. It requires configuration-mode authority, which is a higher privilege level than what is needed for the simple operational command 'show system host-name'. The question asks for a command to display the current hostname, and this option, while related, is not the direct operational-mode command that answers the requirement.

show system uptime

Why wrong: The 'show system uptime' command reports the system's current time, uptime duration, number of users logged in, and load averages. It focuses on system availability and performance metrics, and its output contains no hostname information whatsoever. The hostname is a discrete identifier that is not bundled into uptime or load statistics, so this command cannot satisfy the request to display the device's hostname.

set system login user admin class operator

Why wrong: Assigning the operator class to the admin user grants read-write privileges, not read-only access. Within Junos, the operator class allows the user to edit and commit configuration changes, along with executing operational commands such as show and ping. Because the administrator requires read-only access, this configuration would exceed the requested permission level and is therefore incorrect.

set system login user readonly class super-user

Why wrong: The super-user class provides unrestricted administrative access to the entire Junos system, including configuration changes, user management, and the Unix shell. Granting this class to the readonly user would provide far more than read-only access, creating a significant security risk. Since the requirement is strictly read-only, this option must be rejected.

set system login user guest class operator

Why wrong: Although the username 'guest' suggests a limited account, the assigned class determines the actual privilege level. The operator class provides read-write access, allowing the user to modify and commit configuration changes, which is inappropriate for a read-only requirement. This configuration would give the guest account more access than intended, making it an invalid choice.

show system commit

Why wrong: The `show system commit` command displays the commit log, which records when each configuration was committed, the user who performed the commit, and any commit comment. It does not display the individual CLI commands typed during an interactive session. This command is useful for auditing configuration changes, not for recalling command-line input.

show configuration

Why wrong: The `show configuration` command outputs the current committed configuration (or the candidate configuration when in configuration mode), presenting it as a set of hierarchy statements. It is a static snapshot of the device's configuration, not a record of the commands that created it. This command is used to inspect the running configuration, not to review CLI command history.

show log messages

Why wrong: The `show log messages` command displays the contents of the system log file `/var/log/messages`, which contains syslog messages generated by the Junos OS, such as alerts, errors, and authentication events. While it may contain some indirect evidence of commands (e.g., if logging is configured), it is not a command history and does not list the specific CLI commands typed by the user. Its purpose is to review system events and operational issues.

rollback 0

Why wrong: The Junos 'rollback 0' command is a configuration rollback operation that reverts the candidate configuration to the most recently committed configuration. It discards uncommitted changes and restores the prior configuration state, but it has absolutely no effect on the Junos OS software image or the active software partition. Therefore, it cannot undo a software upgrade.

request system reboot

Why wrong: The 'request system reboot' command simply restarts the device and loads the software partition that is currently marked as the primary boot image. If the upgraded software is already active and set as primary, a reboot will bring the system back to the same upgraded version, not the previous one. It does not select or activate a different software partition, so it cannot revert an upgrade.

request system software delete jinstall-*.tgz

Why wrong: The 'request system software delete jinstall-*.tgz' command removes the software package file from the device's storage, but it does not uninstall or deactivate the currently running software. The upgraded OS remains active in its dedicated software partition and will continue to be used on subsequent reboots. Deleting the package merely frees disk space; it does not cause a fallback to the previous Junos version.