Junos Configuration Basics practice questions

Define the filter under 'firewall family inet' and apply it under 'interfaces ge-0/0/0 unit 0 family inet filter input filter-name'

Why wrong: This is correct because the filter is defined under the inet family, which corresponds to IPv4 traffic, and then applied to the input direction of the ge-0/0/0 interface's IPv4 protocol family. Junos requires that firewall filters be defined in a family-specific context, and applying it under the interface unit's family inet ensures it evaluates all IPv4 packets received on that interface. Specifying 'filter input' is the proper syntax to attach the filter, and it will be processed before any forwarding decisions are made.

Define the filter under 'firewall family inet' and apply it under 'interfaces ge-0/0/0 unit 0 family inet input'

Why wrong: This option fails because the Junos CLI syntax for attaching a firewall filter requires the keyword 'filter' after the family, as in 'family inet filter input filter-name'. The configuration 'family inet input' is missing that keyword, making it an invalid statement that Junos will reject during commit. Even if accepted, there is no 'input' stanza directly under family inet for this purpose; the only valid way to bind a filter is through the 'filter input' hierarchy.

Define the filter under 'firewall family any' and apply it under 'interfaces ge-0/0/0 unit 0 family any filter input'

Why wrong: Using 'family any' is not supported for firewall filters in Junos; filter definitions must be tied to a specific protocol family like inet, inet6, or mpls. Applying a filter under 'family any' on the interface is also non-standard and would not correctly match IPv4 packets, because the filter is not associated with the IPv4 protocol layer. Junos expects the family to match the traffic type being filtered, so 'family inet' is the appropriate context for an IPv4 ACL.

set system hostname Core-Router; commit

Why wrong: Junos uses the leaf identifier 'host-name' under [edit system]; 'hostname' without a hyphen is not recognized by the configuration parser. The set command will return a syntax error because it attempts to create a non-existent hierarchy, so no configuration change is made. Therefore, even with a trailing commit, the commit will either fail or have nothing to apply depending on other pending changes.

show version

Why wrong: show version on a Junos device displays the Junos OS version, hostname, and hardware information. It provides no visibility into BGP peering state, session establishment, or exchanged prefixes. While it might be useful for confirming a fix that required a reboot, it cannot reveal why a BGP session is down or why routes are being rejected.

show interfaces terse

Why wrong: show interfaces terse summarizes the administrative and operational status of all interfaces, along with their configured IP addresses. It does not show the BGP peer's state, such as Active, OpenConfirm, or Established, nor does it report any BGP-specific error or negotiation statistics. Even if the interface is up, the BGP session could be down due to a misconfigured peer, so this command gives no diagnostic value for BGP issues.

show route protocol bgp

Why wrong: show route protocol bgp lists the BGP routes currently installed in the Junos routing table, focusing on the best path to each prefix. It does not explain why a neighbor's advertised routes were not accepted, as rejected routes typically appear as hidden or are simply absent. To see the neighbor's advertised prefixes and the reason for rejection, one must inspect the BGP-specific counters and policy statistics, not the routing table.

commit check

Why wrong: The 'commit check' command validates the candidate configuration by parsing syntax and verifying the statement hierarchy without activating the configuration. It acts as a pre-flight test that reports errors but leaves the running configuration untouched, so it cannot provide the automatic rollback safety required when applying changes to a new router.

commit at

Why wrong: The 'commit at' command schedules the candidate configuration to be committed at a specific time in the future, making it useful for planned maintenance windows. It does not, however, require confirmation after the commit nor does it automatically revert the changes if the network becomes unreachable, so it does not offer the fail-safe that 'commit confirmed' provides.

commit synchronize

Why wrong: The 'commit synchronize' command is used only in multi-chassis systems, such as a chassis cluster or a multi-chassis routing configuration, where the commit must be applied to both members simultaneously. On a single standalone router it is not applicable, and it does not provide any mechanism for confirmation-based rollback, making it irrelevant as a safety measure for a new router.

show configuration | display set

Why wrong: This command does show the candidate configuration, but in 'set' format. While it retrieves the candidate config, it is not the standard or most direct command; 'show configuration' alone is the expected answer. The question asks for the command to view the candidate configuration without additional options.

show configuration | compare rollback 0

Why wrong: The pipe filter 'compare rollback 0' instructs Junos to display only the differences between the current candidate configuration and the most recently committed configuration (rollback 0). It outputs a diff-style output showing added, deleted, or changed lines, not the full candidate configuration. While it is a useful diagnostic for reviewing uncommitted changes, it does not satisfy the requirement to 'view the current candidate' in its entirety.

show interface terse

Why wrong: 'show interface terse' is an operational command that provides a concise summary of interface status, including interface names, administrative and operational state, and configured protocol addresses. It does not display the candidate configuration in any form; rather, it presents real-time state information about interfaces. This command is used for monitoring and troubleshooting interface operation, not for inspecting configuration, so it is incorrect for viewing the candidate configuration.

set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/24

Why wrong: This statement configures 10.0.0.2/24 as a new address on the interface unit, but because no secondary keyword is supplied, it is interpreted as the primary address. If an existing primary address is already configured on ge-0/0/0.0, this change will replace that address rather than simply adding an additional one. To preserve the existing primary and add this as an additional IP, you must explicitly include the secondary keyword after the address. Therefore, this command is incorrect for the stated goal.

set interfaces ge-0/0/0 unit 0 family inet secondary address 10.0.0.2/24

Why wrong: This command places the keyword secondary in an invalid hierarchy location. In Junos, secondary is not a configuration node under family inet; it is a qualifier attached to a specific address statement. The correct form is set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/24 secondary. Attempting to set a secondary stanza before address will produce a syntax error or be rejected by the management daemon, so this command cannot add the required secondary IP.

set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/24 primary

Why wrong: Using the primary keyword designates 10.0.0.2/24 as the primary address for the unit, which would either replace the existing primary or prevent the old primary from remaining primary. The task is to add a secondary address without changing the current primary. The primary keyword is intended for explicitly selecting a primary when multiple addresses exist, not for adding an additional address alongside an existing primary. Consequently, this command does not achieve the goal and may disrupt connectivity if the primary address changes.

show configuration

Why wrong: show configuration displays the entire candidate configuration in full, with no reference to the active committed configuration. It provides no diff output or markers for changed lines, so an engineer cannot see what was modified unless they manually save and compare against a previous snapshot, which is inefficient and error-prone for verifying a set of changes.

show system rollback

Why wrong: show system rollback lists the available rollback configuration snapshots with their IDs, dates, and a brief reason, but it does not show any diff or content of those snapshots. It is used to select a previous configuration for rollback, not to compare the current candidate with the committed configuration, so it won't help identify specific changes made.

show log messages

Why wrong: show log messages retrieves the system syslog messages, which record operational events, error conditions, and commit actions, not the actual configuration differences. It could tell you when a commit happened, but it will not display the changed configuration lines, so it is not suitable for verifying the exact modifications made during an editing session.

Configuration changes are activated immediately upon entering the 'set' command.

Why wrong: In Junos, the 'set' command modifies the candidate configuration, which is a separate working copy stored in memory. The active configuration remains unchanged until you explicitly issue the 'commit' command, at which point the candidate configuration is validated and activated. Therefore, configuration changes do not take effect immediately upon entering 'set'.

The 'commit check' command activates the candidate configuration if syntax is valid.

Why wrong: 'commit check' performs a syntax and validity check against the candidate configuration without activating it. It validates that the configuration is consistent and can be committed, but it does not update the active configuration or affect the running system. The candidate configuration remains uncommitted until a real 'commit' is issued.

The 'commit confirmed' command automatically commits changes permanently.

Why wrong: 'commit confirmed' allows a temporary commit that automatically rolls back to the previous active configuration if the administrator does not confirm the commit within the specified timeout (default 10 minutes). It is used to protect against locking yourself out or applying a misconfiguration; the changes are not permanent unless explicitly confirmed with 'commit confirm' or 'commit' before the timeout expires.

Apply the filter globally using 'firewall family inet filter filter-name'

Why wrong: The 'firewall family inet filter' hierarchy is only used to define the filter's terms and matching conditions; it does not apply the filter anywhere. Junos does not support a global application command at that level, so packets are never evaluated unless the filter is explicitly referenced under an interface's 'family inet filter' input or output. Configuring only this stanza leaves the filter unbound, and traffic is unaffected.

Apply the filter under 'routing-options'

Why wrong: The 'routing-options' hierarchy controls protocol-independent routing properties such as static routes, router ID, autonomous system, and graceful restart. Firewall filters are not a routing option and checking this box would be syntactically invalid; Junos would reject the configuration with a parse error. Proper application of firewall filters always occurs under 'interfaces' or 'logical-interfaces', not in the routing-options stanza.

The 'routing-options' hierarchy is used to configure interface IP addresses.

Why wrong: The 'routing-options' hierarchy is intended for global router parameters such as static routes, router-id, and autonomous system number, not for interface addressing. Interface IP addresses are configured at the [edit interfaces interface-name unit logical-unit-number family inet address] hierarchy, where each logical interface carries its own protocol family and address. Therefore, using a router-level hierarchy for interface IPs would be a functional misplacement.

Firewall filters are configured under 'policy-options'.

Why wrong: Junos firewall filters are placed under the [edit firewall] hierarchy, where you define filter statements with terms that specify match conditions and actions. In contrast, the [edit policy-options] hierarchy is used for routing policies, including prefix lists, community lists, and AS-path groups, which influence routing decisions in protocols like BGP. Assigning firewall filters to policy-options would conflate packet-filtering with route-selection logic.

The 'protocols' hierarchy includes system-level settings like hostname.

Why wrong: The [edit protocols] hierarchy is dedicated to configuring routing protocol instances, such as OSPF, BGP, and IS-IS, along with protocol-specific attributes like timers and areas. Hostname, on the other hand, is a device identity setting under [edit system host-name]. Placing hostname under protocols would mix device-level identity with Layer 3 protocol operation, violating Junos's separation of configuration concerns.

The commit will succeed but the security policy will be ignored due to a syntax error.

Why wrong: A syntax error in the candidate configuration would cause the commit to fail entirely, not simply cause the security policy to be ignored. Junos validates the full configuration syntax during the commit process, and any error aborts the commit, leaving the running configuration unchanged. The exhibit shows no syntax errors, so both the interface address and the security policy changes are committed successfully.

Only the interface address change will be committed because security policies require a reboot.

Why wrong: Security policies in Junos take effect immediately after a successful commit; they do not require a reboot or any separate activation step. The candidate configuration includes both the interface address and the security policy change, and `commit` activates all staged changes together. Only hardware-specific changes (like certain chassis parameters) may require a reboot, but security policy updates are applied to the data plane instantly.

The configuration will be validated; if errors exist, the commit will fail.

Why wrong: While it is true that Junos validates configurations during commit and would fail if errors exist, the exhibit shows a valid candidate configuration, so this option does not describe the actual outcome. The commit will succeed, and both changes will be activated atomically. This option is not incorrect as a general statement about Junos, but it fails to answer the specific question about what happens with the given changes.

Add a term at the end to permit all from 10.1.1.1

Why wrong: In Junos firewall filters, terms are evaluated in numerical order, and the first matching term's action is applied. If the existing filter already has a term that rejects or discards traffic from 10.1.1.1, any subsequent term—even one that permits—will never be reached for that traffic, because the earlier reject term already terminates evaluation. Therefore, appending a permit term at the end is ineffective; it would be dead configuration that does not resolve the SNMP connectivity issue.

Change the source-address in term 1 to 10.0.0.0/8 except 10.1.1.1

Why wrong: Junos firewall filter match conditions do not support an 'except' keyword for a single prefix. A source-address statement can contain one or more prefixes, but you cannot specify '10.0.0.0/8 except 10.1.1.1' as a single match. To exclude a specific host, you must configure a separate term that permits 10.1.1.1 before the term that blocks the larger range; otherwise, the filter will still match the host to the broader prefix and apply the deny action. Thus, modifying term 1 as suggested is both syntactically impossible and would not achieve the desired result.

Remove the filter and apply a new filter that permits SNMP from 10.1.1.1

Why wrong: Removing and reapplying a firewall filter is unnecessarily disruptive and risks leaving the interface without traffic filtering during the transition. Junos supports editing an existing filter configuration and committing changes atomically, so you can insert a term at the top to permit the specific SNMP source without any downtime. Additionally, a new filter that only permits SNMP from 10.1.1.1 would inadvertently block all other traffic unless you fully replicate the existing filter rules, making this approach more complex and error-prone than a targeted modification.

load override

Why wrong: load override replaces the entire candidate configuration with the contents of a file or terminal input. However, it only modifies the candidate configuration; it does not activate it. To make the loaded configuration effective, you must issue a commit command. In this scenario, since the engineer needs to apply a change immediately, merely loading it without committing would not meet the requirement.

commit confirmed

Why wrong: commit confirmed is a safety mechanism that applies a configuration temporarily and automatically rolls back if the engineer does not confirm within a specified timeout (default 10 minutes). It is not appropriate for the task because the intent is to apply a static route persistently, not to test a change with an automatic revert. The engineer would need to issue a standard commit to make the change permanent.

rollback

Why wrong: rollback is used to revert the candidate or active configuration to a previously committed configuration snapshot. It does not add new configuration changes like a static route. Instead, it discards candidate changes or reverts to a prior operational state, which is the opposite of what the engineer intends to achieve.

The interface MTU is too small for IPv6 packets.

Why wrong: If the IPv4 configuration on the interface is operational, the MTU is certainly large enough to carry IPv6 traffic, because IPv6 has a fixed minimum MTU of 1280 bytes and typical Ethernet MTUs are 1500 bytes. A genuinely insufficient MTU would cause fragmentation or PMTU discovery failures rather than a complete absence of IPv6 address resolution. Therefore, this cannot be the reason IPv6 is failing.

The IPv6 address is not configured under the correct unit.

Why wrong: A closer inspection of the exhibit shows the IPv6 address is configured under the logical unit 0, which is the appropriate unit for the physical interface in this setup. If the address were accidentally placed under unit 1 or another unit, that unit would likely not be tied to the active physical link, causing IPv6 to appear non-functional. Since the configuration already has it under unit 0, this explanation cannot be the cause.

The interface has an IPv4 address, which prevents IPv6 from working.

Why wrong: Junos fully supports dual-stack operation, meaning IPv4 and IPv6 can coexist on the same interface without interference. The presence of an IPv4 address does not disable IPv6 protocol processing; each address family is enabled independently under the logical unit. Therefore, having IPv4 configured is not a valid explanation for IPv6 not working.

set routing-options static route 0.0.0.0/0 next-hop 203.0.113.1 metric 1

Why wrong: Setting the same metric as the primary default route for the same prefix creates an ECMP (equal-cost multipath) scenario, causing the router to load-balance traffic across both next-hops rather than preserving one as a backup. This introduces unpredictability and potential asymmetric routing, and it fails to provide deterministic failover because traffic will still be sent to the primary next-hop even when that link is down. A backup route must have a higher metric so it remains inactive until the preferred route disappears.

set routing-options static route 0.0.0.0/0 discard

Why wrong: Configuring the default route with the discard action installs a null route that silently drops all matching traffic instead of forwarding it to ISP-B via 203.0.113.1. This would blackhole all internet-bound traffic at the branch router, which is the opposite of the intended backup behavior. Discard routes are typically used for loop prevention or to summarize unreachable networks, not for defining a next-hop toward an ISP.

set routing-options static route 0.0.0.0/0 next-table inet.0

Why wrong: The next-table statement is designed to direct packet lookups to a different routing table—used in policy-based routing or for VRF traversal—not to define a backup next-hop for a prefix. Configuring a default route with next-table inet.0 would cause the router to recursively consult the inet.0 table for forwarding decisions, which does not specify ISP-B as the next hop and does not establish a functional backup default route. This option is semantically incorrect for the intended failover purpose.

The 'deactivate' command permanently removes a configuration statement from the candidate.

Why wrong: The 'deactivate' command does not permanently remove a configuration statement; instead, it disables the statement in the candidate configuration while retaining it in the configuration hierarchy. The statement remains present but is marked as inactive, so it has no operational effect after a commit. You can later re-enable it with the 'activate' command, proving that it was never permanently deleted.

The 'set' command in configuration mode directly modifies the active configuration.

Why wrong: The 'set' command in configuration mode modifies only the candidate configuration, not the active configuration. Junos deliberately separates the editing environment from the operational state so that changes do not take effect immediately. To make 'set' changes active, you must explicitly execute a 'commit' command, which applies the entire candidate configuration as a single atomic transaction. Therefore, saying 'set' directly modifies the active configuration is incorrect because the active configuration is untouched until commit.

In operational mode, the 'show' command displays the candidate configuration.

Why wrong: In operational mode, the 'show' command, such as 'show configuration', displays the active (committed) configuration, not the candidate configuration. The candidate configuration is only visible while you are in configuration mode, where you can issue 'show' to see the staged changes. To compare the candidate against the active configuration, you use 'show | compare' from within configuration mode. Since operational mode 'show' reflects what is currently running, it does not expose uncommitted edits, making the statement false.

To enable both IPv4 and IPv6 on the interface.

Why wrong: The 'family inet6' hierarchy is exclusively for IPv6 configuration and cannot enable IPv4. In Junos, IPv4 addressing and routing require a separate 'family inet' stanza on the same interface; simply configuring 'family inet6' does not automatically activate the IPv4 protocol family. Thus, this option is incorrect because the stanza shown is not a combined IPv4/IPv6 enablement, but exclusively an IPv6 configuration statement.

To enable IPv6 ARP on the interface.

Why wrong: IPv6 does not use Address Resolution Protocol (ARP) for layer-2 address discovery; that mechanism is exclusively for IPv4. Instead, IPv6 relies on Neighbor Discovery Protocol (NDP), which uses ICMPv6 messages such as Neighbor Solicitation and Neighbor Advertisement to resolve IPv6 addresses to MAC addresses. While 'family inet6' does enable IPv6 and NDP automatically, it has no role in enabling 'IPv6 ARP' because that protocol does not exist.

To assign a link-local IPv6 address to the interface.

Why wrong: The address configured on the interface is 2001:db8::1/64, which belongs to the 2000::/3 global unicast range, not the fe80::/10 link-local prefix. While Junos will automatically generate a link-local IPv6 address when 'family inet6' is enabled, the explicit address shown is a global unicast, and the stanza's purpose here is to assign that global address. Thus, claiming the purpose is to assign a link-local address misidentifies the address type.

Configure interface as access port and assign VLAN, then create VLAN under 'vlans' hierarchy, then commit, then verify

Why wrong: Assigning an interface to a VLAN that has not yet been created in the 'vlans' hierarchy is a forward reference that Junos does not resolve during edit or commit. While the CLI may accept the 'set interface vlan members' command, the subsequent commit will throw an error stating that the VLAN is not defined, causing the entire configuration session to be rejected. The correct sequence is to define the VLAN first, because the commit engine validates all references before applying any changes to the active configuration.

Create VLAN under 'vlans' hierarchy, then commit, then configure interface as access port and assign VLAN, then verify

Why wrong: Committing immediately after creating the VLAN, but before assigning any interfaces, leaves the VLAN in a dormant, non-operational state because no access or trunk ports are bound to it. This intermediate commit also introduces an unnecessary configuration session, and the later interface assignment requires a second commit, which is inefficient and violates the workflow of staging all related changes before a single commit. In Junos, a configuration change is not considered complete until the affected interfaces are attached and the entire set of changes is committed together.

Commit, then create VLAN under 'vlans' hierarchy, then configure interface as access port and assign VLAN, then verify

Why wrong: Performing a commit before any changes have been staged is a no-op, as the commit operation only applies modifications present in the candidate configuration to the active configuration. With an empty candidate, the commit has no effect, and creating the VLAN and assigning the interface afterward still leaves the changes uncommitted until another commit is executed. This ordering is fundamentally broken because it treats commit as a starting point rather than the final activation step, and it does not satisfy the Junos edit-commit-verify workflow required for configuration changes to take effect.

Step 1: Create a BGP group and specify the peer AS. Step 2: Configure the autonomous system (AS) number on the router. Step 3: Define the neighbor IP address in the BGP group. Step 4: Commit the configuration and verify using 'show bgp summary'.

Why wrong: This incorrectly places the BGP group configuration before the local AS number. In Junos, the `routing-options { autonomous-system; }` statement must be committed before BGP can interpret a group's `peer-as` value, because the router needs its own AS to classify the session as eBGP or iBGP and to enforce the correct update behavior. Configuring `protocols bgp group` with a `peer-as` before setting the local AS leaves BGP without the required local AS context, so the configuration cannot be validated or used as the foundation for peering.

Step 1: Configure the autonomous system (AS) number on the router. Step 2: Define the neighbor IP address in the BGP group. Step 3: Create a BGP group and specify the peer AS. Step 4: Commit the configuration and verify using 'show bgp summary'.

Why wrong: This sequence tries to add the neighbor IP address before the BGP group exists. In the Junos hierarchy, a BGP neighbor can only exist under `protocols bgp group <group-name> neighbor <ip-address>`, so there is no configuration object in which to place the neighbor until the group is created. The group also supplies the `peer-as` and inheritable export/import policies that the neighbor must rely on, so defining the neighbor first is not only a syntax error but also leaves the neighbor without its required peer AS and policy context.

Step 1: Configure the autonomous system (AS) number on the router. Step 2: Create a BGP group and specify the peer AS. Step 3: Commit the configuration and verify using 'show bgp summary'. Step 4: Define the neighbor IP address in the BGP group.

Why wrong: Committing and verifying before adding the neighbor is premature because the BGP process will have a group with no peers to establish a session with. At commit time, `protocols bgp` requires at least one `neighbor` statement under the group to create any BGP peering, and `show bgp summary` would show zero configured neighbors and no established sessions. The neighbor must be present in the committed configuration before the commit is meaningful; only after it is added can `show bgp summary` validate the peering state.

set: Removes a configuration element

Why wrong: This statement is incorrect because 'set' is used to add or modify configuration parameters, not to remove them. In Junos, removing a configuration element is performed exclusively with the 'delete' command. Using 'set' to attempt removal would either add a new value or overwrite an existing one, leaving the configuration element intact rather than eliminating it, which could lead to unintended configuration state.

rename: Navigates to a specific configuration hierarchy level

Why wrong: This statement is incorrect because 'rename' changes the identifier of a configuration object, not the current working location within the configuration tree. Navigation to a specific hierarchy level is accomplished with the 'edit' command, which moves you to a new context for subsequent commands. 'Rename' simply renames a node and does not alter your position, so confusion between these commands can lead to commands being applied at the wrong hierarchy level.