How should I use these Junos Configuration Basics practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Junos Configuration Basics questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Junos Configuration Basics domain.

JN0-106 · topic practice

Junos Configuration Basics practice questions

Junos Configuration Basics covers the candidate/rollback/commit model that makes Junos configuration safe and reversible. JN0-106 tests this through scenario questions: setting commit-confirm timeouts, recovering from a bad commit, and predicting the effect of a commit on firewall filters and interface configuration.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

20 questionsDomain: Junos Configuration Basics

Practice 10 questions Browse domain →

What the exam tests

What to know about Junos Configuration Basics

Be able to configure commit confirmed with a timeout, roll back to a prior configuration, and read a firewall filter to predict which traffic is permitted or rejected. The key skill is knowing that unconfirmed changes revert automatically and that rollback requires a commit to take effect.

Using commit confirmed with a timeout so unconfirmed changes roll back automatically

Rolling back to a previous configuration with rollback n and comparing with show | compare

Applying firewall filters to interfaces to permit or reject specific traffic such as SNMP

Predicting commit results from configuration hierarchies and candidate configuration state

Watch out for

Common Junos Configuration Basics exam traps

▸Confusing commit confirmed with a plain commit: only commit confirmed auto-reverts if not confirmed within the timeout.
▸Assuming rollback restores the running config without a commit; rollback loads the candidate and still needs commit.
▸Forgetting that firewall filter terms are evaluated in order, so a broad reject placed before a permit blocks the intended traffic.

Practice set

Junos Configuration Basics questions

20 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Review the full subnetting walkthrough →

A network engineer is configuring a new Juniper device. They intend to apply a firewall filter to an interface to only allow SSH traffic from a specific management subnet. Which configuration approach best follows Juniper best practices?

Trap 1: Define the filter under 'firewall family inet' and apply it under…

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.

Trap 2: Define the filter under 'firewall family inet' and apply it under…

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.

Trap 3: Define the filter under 'firewall family any' and apply it under…

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.

Study all Junos Configuration Basics common traps →

A
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 it fails: 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.
B
Define the filter under 'firewall family inet' and apply it under 'interfaces lo0 unit 0 family inet filter input filter-name'
Although the filter is correctly defined, applying it to the loopback interface (lo0) means it only affects traffic destined to or sourced from the device itself, such as management or routing protocol packets. Traffic transiting through the physical interface ge-0/0/0 is completely bypassed by this filter, so the intended filtering of user data does not occur. To filter packets entering the network via that interface, the filter must be applied directly to ge-0/0/0's unit, not to lo0.
C
Define the filter under 'firewall family inet' and apply it under 'interfaces ge-0/0/0 unit 0 family inet input'
Why it fails: 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.
D
Define the filter under 'firewall family any' and apply it under 'interfaces ge-0/0/0 unit 0 family any filter input'
Why it fails: 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.

Full breakdown with real-world context →

Question 2easymultiple choice

Review the full routing breakdown →

A junior engineer is asked to change the hostname of a Juniper device from 'Router-1' to 'Core-Router'. Which command sequence correctly commits the change?

Trap 1: set system hostname Core-Router; commit

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.

Study all Junos Configuration Basics common traps →

A
set system host-name Core-Router; commit
This is the canonical Junos command for changing a hostname: 'set system host-name' targets the correct configuration node, and 'commit' makes the change take effect in the active configuration. It is the standard method taught for JNCIA, as it adheres to the exact CLI schema and is both direct and unambiguous. No other statements are required.
B
edit system; set host-name Core-Router; commit
Although 'edit system' changes the configuration context to the [edit system] hierarchy, so that 'set host-name' would be equivalent to 'set system host-name', Junos best practice is to use the complete path in a single command for clarity. The two-step approach may work, but it is unnecessarily verbose and can introduce errors in scripting or copy-paste scenarios. Since the question asks for the proper way, this is not the correct answer.
C
set system hostname Core-Router; commit
Why it fails: 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.
D
set system host-name Core-Router; commit
This sequence correctly uses the required hyphenated 'host-name' identifier, exactly matching Junos schema under [edit system]. The 'set' operation modifies the candidate configuration, and the subsequent 'commit' validates and activates the new hostname. Thus the command is valid and achieves the desired result, unlike the version with 'hostname'.

Full breakdown with real-world context →

Question 3easymultiple choice

Read the full Junos Configuration Basics explanation →

A network administrator wants to view the current candidate configuration that has not yet been committed. Which command should be used?

Trap 1: show configuration | display set

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.

Trap 2: show configuration | compare rollback 0

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.

Trap 3: show interface terse

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

Study all Junos Configuration Basics common traps →

A
show configuration | display set
Why it fails: 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.
B
show configuration
'show configuration' is the standard Junos CLI command to display the entire candidate configuration in hierarchical (set-style or curly-brace) format. This command reads from the candidate configuration database, which contains both committed configuration and any uncommitted changes made in the current editing session. It is the most direct and complete way to view the full candidate configuration, making it the correct answer.
C
show configuration | compare rollback 0
Why it fails: 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.
D
show interface terse
Why it fails: '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.

Full breakdown with real-world context →

Question 4easymultiple choice

Read the full Junos Configuration Basics explanation →

After making several configuration changes, an engineer wants to see what changes were made in the candidate configuration compared to the last committed configuration. Which command should be used?

Trap 1: show configuration

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.

Trap 2: show system rollback

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.

Trap 3: show log messages

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.

Study all Junos Configuration Basics common traps →

A
show configuration
Why it fails: 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.
B
show configuration | compare
show configuration | compare pipes the candidate configuration against the committed configuration and outputs only the differences, prefixing added lines with "+" and removed lines with "-". This gives an immediate, precise view of exactly what has changed since the last commit, making it the recommended way to review configuration edits before committing.
C
show system rollback
Why it fails: 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.
D
show log messages
Why it fails: 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.

Full breakdown with real-world context →

Question 5mediummulti select

Read the full Junos Configuration Basics explanation →

Which TWO statements are true regarding the Junos OS commit model?

Trap 1: Configuration changes are activated immediately upon entering the…

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

Trap 2: The 'commit check' command activates the candidate configuration if…

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

Trap 3: The 'commit confirmed' command automatically commits changes…

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

Study all Junos Configuration Basics common traps →

A
Configuration changes are activated immediately upon entering the 'set' command.
Why it fails: 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'.
B
The 'commit check' command activates the candidate configuration if syntax is valid.
Why it fails: '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.
C
Multiple users can make changes simultaneously in configure private mode.
In Junos, users enter configuration mode, and by default they share a single candidate configuration with exclusive lock semantics. However, 'configure private' gives each user an independent private candidate configuration, so multiple users can edit and commit separately without stepping on each other's changes. This is useful in multi-admin environments where parallel changes must be isolated until ready to commit.
D
The 'commit confirmed' command automatically commits changes permanently.
Why it fails: '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.
E
The 'commit' command activates the candidate configuration.
The 'commit' command is the explicit action that validates and installs the candidate configuration as the active configuration. It triggers syntax checking, applies the configuration to the running system, and marks it as the current active configuration. Until a commit is performed, all changes remain only in the candidate configuration and have no operational effect.

Full breakdown with real-world context →

Question 6hardmulti select

Read the full Junos Configuration Basics explanation →

Which THREE are valid methods to apply a firewall filter in Junos?

Trap 1: Apply the filter globally using 'firewall family inet filter…

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.

Trap 2: Apply the filter under 'routing-options'

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.

Study all Junos Configuration Basics common traps →

A
Apply the filter to an interface under 'family inet filter input'
This is the standard Junos method for applying a firewall filter to inbound traffic on a specific interface. The 'family inet filter input' stanza attaches the filter to IPv4 packets received on that interface, before any local or forwarding processing occurs. It is the typical way to implement ingress filtering, such as blocking certain source addresses or limiting ICMP rates on a transit link.
B
Apply the filter to an interface under 'family inet filter output'
Applying a firewall filter under 'family inet filter output' on an interface controls packets leaving that interface, after the forwarding decision and before the wire. This egress direction is commonly used for filtering traffic sourced from the local device or from other interfaces that are routed out through this interface. Unlike the input filter, it cannot inspect packets that were received but not yet routed, so it is suitable for traffic shaping or restricting outbound policies.
C
Apply the filter globally using 'firewall family inet filter filter-name'
Why it fails: 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.
D
Apply the filter under 'routing-options'
Why it fails: 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.
E
Apply the filter to the loopback interface under 'family inet filter input'
Applying a firewall filter to the loopback interface (lo0) under 'family inet filter input' is a special case that protects the Routing Engine itself. Because traffic destined to the device's own IP addresses, including management and routing protocol packets, is implicitly sent to lo0, an input filter here can block or rate-limit control-plane traffic from untrusted sources. This is considered a best practice for securing the device, but it is still an interface-level application, not a global one.

Full breakdown with real-world context →

Question 7easymulti select

Read the full Junos Configuration Basics explanation →

Which TWO are correct statements about the Junos configuration hierarchy?

Trap 1: The 'routing-options' hierarchy is used to configure interface IP…

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.

Trap 2: Firewall filters are configured under 'policy-options'.

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.

Trap 3: The 'protocols' hierarchy includes system-level settings like…

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.

Study all Junos Configuration Basics common traps →

A
The 'routing-options' hierarchy is used to configure interface IP addresses.
Why it fails: 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.
B
The 'interfaces' hierarchy is used to configure physical and logical interfaces.
The 'interfaces' hierarchy serves as the top-level configuration container for all physical and logical interface attributes in Junos. Physical properties include media type, speed, and physical link options, while logical properties, such as unit numbers, VLAN tagging, and protocol family addresses, are configured underneath. This structure allows a single interface to carry multiple logical units, each with its own Layer 3 configuration.
C
The 'system' hierarchy includes settings for NTP and DNS.
The 'system' hierarchy centralizes device-wide configuration, including hostname, NTP servers, DNS name servers, syslog, and management services. NTP and DNS are system-level services that operate independently of any routing protocol or interface, and thus they belong under [edit system]. This organization helps administrators quickly locate global parameters without searching protocol-specific hierarchies.
D
Firewall filters are configured under 'policy-options'.
Why it fails: 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.
E
The 'protocols' hierarchy includes system-level settings like hostname.
Why it fails: 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.

Full breakdown with real-world context →

Question 8hardmultiple choice

Open the full BGP breakdown →

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?

Trap 1: The management instance needs a firewall filter that allows SSH;…

The management instance currently has no filter, but the filter from internet instance is applied globally to loopback.

Trap 2: The firewall filter in the 'internet' instance incorrectly blocks…

The filter is correct for the intended policy; the problem is instance interaction.

Trap 3: The BGP configuration is causing the loopback to be unreachable;…

BGP does not affect SSH access.

Study all Junos Configuration Basics common traps →

A
The management instance needs a firewall filter that allows SSH; add a filter to the management instance's loopback.
Why it fails: The management instance currently has no filter, but the filter from internet instance is applied globally to loopback.
B
The firewall filter in the 'internet' instance incorrectly blocks SSH; modify the filter to allow SSH from any source.
Why it fails: The filter is correct for the intended policy; the problem is instance interaction.
C
The BGP configuration is causing the loopback to be unreachable; disable BGP on the management instance.
Why it fails: BGP does not affect SSH access.
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.
On Juniper MX, the loopback interface lo0.0 is a single physical interface whose logical units belong to routing instances; a filter attached at the physical interface level applies across all instances, so the 'internet' filter drops management SSH despite the management instance having no filter. Apply the filter to the instance-specific logical unit instead.

Full breakdown with real-world context →

Question 9hardmultiple choice

Study the full IPv6 explanation →

Refer to the exhibit. An engineer configures interface ge-0/0/0 with both IPv4 and IPv6 addresses. The engineer notices that the interface is operationally up, but the IPv6 address is not pingable from a directly connected host. The host has an IPv6 address in the same subnet. What is the most likely cause?

Exhibit

Refer to the exhibit.

user@router> show configuration interfaces ge-0/0/0
unit 0 {
    family inet {
        address 10.0.0.1/24;
    }
    family inet6 {
        address 2001:db8::1/64;
    }
}

Trap 1: The interface MTU is too small for IPv6 packets.

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.

Trap 2: The IPv6 address is not configured under the correct unit.

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.

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

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.

Study all Junos Configuration Basics common traps →

A
The interface MTU is too small for IPv6 packets.
Why it fails: 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.
B
The interface does not have IPv6 neighbor discovery enabled.
IPv6 relies on ICMPv6 Neighbor Discovery (ND) for address resolution, duplicate address detection, and neighbor reachability. If ND is disabled or not activated on the interface, the router will not respond to Neighbor Solicitations, so a remote node cannot resolve its link-layer address and IPv6 packets cannot be exchanged. Even with a valid IPv6 address configured on unit 0, the interface will remain operationally unable to communicate over IPv6.
C
The IPv6 address is not configured under the correct unit.
Why it fails: 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.
D
The interface has an IPv4 address, which prevents IPv6 from working.
Why it fails: 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.

Full breakdown with real-world context →

Question 10easymultiple choice

Review the full routing breakdown →

Your company has deployed a Juniper MX router at a branch office. The router has two upstream connections to different ISPs. The configuration currently uses a single static default route to ISP-A. The network team wants to add redundancy so that if ISP-A fails, traffic automatically uses ISP-B. The ISP-B connection is already configured on interface ge-1/0/0 with IP address 203.0.113.2/30. The next-hop IP for ISP-B is 203.0.113.1. The routing table should have a backup default route with a higher metric. Which configuration change meets the requirement?

Trap 1: set routing-options static route 0.0.0.0/0 next-hop 203.0.113.1…

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.

Trap 2: set routing-options static route 0.0.0.0/0 discard

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.

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

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.

Study all Junos Configuration Basics common traps →

A
set routing-options static route 0.0.0.0/0 next-hop 203.0.113.1 metric 1
Why it fails: 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.
B
set routing-options static route 0.0.0.0/0 discard
Why it fails: 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.
C
set routing-options static route 0.0.0.0/0 next-hop 203.0.113.1 metric 2
A static default route with a metric of 2 is less preferred than an existing primary route with a lower metric, so it is retained in the routing table only as a fallback. When the primary route is removed or becomes unreachable, this route becomes active and forwards traffic to ISP-B via 203.0.113.1, ensuring continuous connectivity. This is the standard method for implementing a floating static route for failover in Junos.
D
set routing-options static route 0.0.0.0/0 next-table inet.0
Why it fails: 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.

Full breakdown with real-world context →

Question 11hardmulti select

Read the full Junos Configuration Basics explanation →

Which TWO statements correctly describe Junos configuration hierarchy and management?

Trap 1: The 'deactivate' command permanently removes a configuration…

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.

Trap 2: The 'set' command in configuration mode directly modifies the…

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.

Trap 3: In operational mode, the 'show' command displays the candidate…

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.

Study all Junos Configuration Basics common traps →

A
The 'deactivate' command permanently removes a configuration statement from the candidate.
Why it fails: 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.
B
The 'load merge' command imports configuration from a file and merges it with the current candidate configuration.
The 'load merge' command reads configuration data from a file and merges it into the current candidate configuration, preserving all existing statements. Unlike 'load override', which replaces the entire candidate, 'load merge' adds or updates only the specific hierarchy levels and leaf values present in the file. This is ideal for applying incremental configuration changes or combining saved configuration snippets without wiping out other settings. After the merge, the changes are still only in the candidate and must be committed to become active.
C
The candidate configuration is a separate copy that does not affect the active configuration until committed.
In Junos, the candidate configuration is an isolated, working copy that is separate from the active configuration running on the device. All modifications made in configuration mode, whether via 'set', 'delete', or other commands, are staged in this candidate database. The active configuration remains completely unaffected until you issue the 'commit' command, at which point the candidate is swapped to become the new active configuration. This separation enables you to validate and review changes before applying them, and to discard the entire candidate with 'rollback' if needed.
D
The 'set' command in configuration mode directly modifies the active configuration.
Why it fails: 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.
E
In operational mode, the 'show' command displays the candidate configuration.
Why it fails: 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.

Full breakdown with real-world context →

Question 12easymultiple choice

Read the full Junos Configuration Basics explanation →

Refer to the exhibit. What is the purpose of the 'family inet6' configuration on interface ge-0/0/0?

Exhibit

Refer to the exhibit.

user@router> show configuration interfaces ge-0/0/0
unit 0 {
    family inet {
        address 10.1.1.1/30;
    }
    family inet6 {
        address 2001:db8::1/64;
    }
}

Trap 1: To enable both IPv4 and IPv6 on the interface.

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.

Trap 2: To enable IPv6 ARP on the interface.

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.

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

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.

Study all Junos Configuration Basics common traps →

A
To enable both IPv4 and IPv6 on the interface.
Why it fails: 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.
B
To assign a global unicast IPv6 address to the interface.
The address 2001:db8::1/64 is a global unicast IPv6 address because it falls within the 2000::/3 global unicast prefix range, and it is configured under the 'family inet6' hierarchy. In Junos, the 'family inet6' stanza is the correct place to assign such an address to an interface, enabling the IPv6 protocol stack for global routing. Therefore, this option accurately describes the purpose of the configuration in the exhibit.
C
To enable IPv6 ARP on the interface.
Why it fails: 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.
D
To assign a link-local IPv6 address to the interface.
Why it fails: 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.

Full breakdown with real-world context →

Question 13mediumdrag order

Open the full VLAN trunking answer →

Order the steps to configure a VLAN on an EX Series switch running Junos.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Configure interface as access port and assign VLAN, then create…

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.

Trap 2: Create VLAN under 'vlans' hierarchy, then commit, then configure…

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.

Trap 3: Commit, then create VLAN under 'vlans' hierarchy, then configure…

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.

Study all Junos Configuration Basics common traps →

A
Create VLAN under 'vlans' hierarchy, then configure interface as access port and assign VLAN, then commit, then verify
Creating the VLAN under the 'vlans' hierarchy first ensures the VLAN exists before it is referenced by any interface configuration. Junos commit validation requires that a VLAN name assigned to an access port be defined in the 'vlans' stanza; otherwise, the commit fails with a 'vlan not defined' error. After both the VLAN and the interface assignment are staged, the commit activates the configuration atomically, and verification commands such as 'show vlans' and 'show interfaces ethernet-switching' confirm that the VLAN is operational and the interface is correctly bound.
B
Configure interface as access port and assign VLAN, then create VLAN under 'vlans' hierarchy, then commit, then verify
Why it fails: 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.
C
Create VLAN under 'vlans' hierarchy, then commit, then configure interface as access port and assign VLAN, then verify
Why it fails: 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.
D
Commit, then create VLAN under 'vlans' hierarchy, then configure interface as access port and assign VLAN, then verify
Why it fails: 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.

Full breakdown with real-world context →

Question 14mediumdrag order

Open the full BGP breakdown →

Order the steps to configure a BGP peering session in Junos.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Step 1: Create a BGP group and specify the peer AS

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.

Trap 2: Step 1: Configure the autonomous system (AS) number on the router

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.

Trap 3: Step 1: Configure the autonomous system (AS) number on the router

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.

Study all Junos Configuration Basics common traps →

A
Step 1: Configure the autonomous system (AS) number on the router. Step 2: Create a BGP group and specify the peer AS. Step 3: Define the neighbor IP address in the BGP group. Step 4: Commit the configuration and verify using 'show bgp summary'.
This is the correct order because you must first define the local AS, then create a BGP group that includes the peer AS, then add the neighbor to that group, and finally commit and verify the peering.
B
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 it fails: 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.
C
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 it fails: 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.
D
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 it fails: 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.

Full breakdown with real-world context →

Question 15mediummatching

Read the full Junos Configuration Basics explanation →

Match each Junos configuration mode command to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Adds or modifies a configuration statement

Removes a configuration statement

Displays the current configuration

Activates the candidate configuration

Reverts to a previous configuration

Trap 1: set: Removes a configuration element

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.

Trap 2: rename: Navigates to a specific configuration hierarchy level

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.

Study all Junos Configuration Basics common traps →

A
set: Modifies a configuration parameter
The 'set' command in Junos configuration mode is used to add or change configuration parameters within the current hierarchy level. For example, 'set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/24' defines or overwrites the specified address. It is a non-destructive operation that directly modifies the candidate configuration, and it cannot remove existing statements or entire configuration elements.
B
edit: Navigates to a specific configuration hierarchy level
The 'edit' command changes your working location in the configuration hierarchy, similar to 'cd' in a Unix shell. It does not itself modify any configuration values; instead, it allows subsequent commands like 'set', 'delete', or 'rename' to be executed relative to the chosen hierarchy level. For instance, 'edit interfaces' moves you to the 'interfaces' level, after which you can manage interface-specific settings without repeatedly typing the full path.
C
delete: Removes a configuration element
The 'delete' command removes configuration elements from the candidate configuration. It can target a single leaf statement, such as 'delete interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/24', or an entire hierarchy like 'delete interfaces ge-0/0/0'. This operation is destructive and permanent within the candidate configuration until you commit or explicitly save a rollback point, so care must be taken when using it.
D
rename: Changes the identifier of a configuration object
The 'rename' command changes the identifier of a configuration object, such as an interface, firewall rule, or logical unit, without altering its underlying configuration values. For example, 'rename interfaces ge-0/0/0 to ge-0/0/1' preserves all child statements under the renamed node. This command is distinct from 'edit' because it does not move you through the hierarchy, and it is distinct from 'set' because it only re-identifies an existing element rather than adding or changing its parameters.
E
set: Removes a configuration element
Why it fails: 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.
F
rename: Navigates to a specific configuration hierarchy level
Why it fails: 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.

Full breakdown with real-world context →

Question 16mediummatching

Read the full Junos Configuration Basics explanation →

Match each Junos software process to its role.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Management daemon for CLI and configuration

Routing protocol daemon

Device control daemon for interface configuration

Chassis daemon for hardware monitoring

SNMP agent daemon

Trap 1: rpd: Monitors chassis hardware.

Attribute chassis hardware monitoring to neither rpd's place nor its purpose. rpd is concerned with control-plane protocol exchange and route computation, not with fans, power supplies, or thermal sensors; those environmental duties belong to chassisd. Pairing rpd with chassis monitoring is a category error in Junos architecture.

Trap 2: mgd: Handles routing protocols.

mgd is not a routing protocol process and never participates in OSPF or BGP state machines. It operates on the management plane, translating user input into configuration; routing-protocol behavior is implemented by rpd, which exchanges hellos, builds adjacencies, and maintains the routing table.

Study all Junos Configuration Basics common traps →

A
rpd: Handles routing protocols such as OSPF and BGP.
The Routing Protocol Daemon (rpd) runs in the Junos control plane and executes routing protocol state machines, including OSPF and BGP. It exchanges routing information with neighboring routers, applies policy and preference rules, and installs active routes into the inet.0 routing table so the forwarding engine can use them.
B
mgd: Provides the CLI and XML API for configuration.
The Management Daemon (mgd) is the user-facing process that owns the management interface: it accepts CLI commands and XML API requests, parses them, validates configuration syntax against the Junos schema, and commits configuration changes by applying them to the candidate and active databases.
C
dcd: Manages physical interface properties.
The Device Control Daemon (dcd) directly programs physical interface hardware on the line cards and FPCs. It sets link status, speed, duplex mode, and optical transceiver parameters, and it reacts to physical-layer state changes by reporting them to other Junos processes for operational visibility.
D
chassisd: Monitors chassis hardware components.
The Chassis Daemon (chassisd) serves as the environmental monitor for the router or switch. It polls chassis components such as fans, power supply modules, and temperature sensors, generates alarms and syslog messages when hardware thresholds are crossed, and passes this state upward for operational display.
E
rpd: Monitors chassis hardware.
Why it fails: Attribute chassis hardware monitoring to neither rpd's place nor its purpose. rpd is concerned with control-plane protocol exchange and route computation, not with fans, power supplies, or thermal sensors; those environmental duties belong to chassisd. Pairing rpd with chassis monitoring is a category error in Junos architecture.
F
mgd: Handles routing protocols.
Why it fails: mgd is not a routing protocol process and never participates in OSPF or BGP state machines. It operates on the management plane, translating user input into configuration; routing-protocol behavior is implemented by rpd, which exchanges hellos, builds adjacencies, and maintains the routing table.

Full breakdown with real-world context →

Question 17mediummultiple choice

Open the full BGP breakdown →

An administrator wants to apply the same BGP configuration to all interfaces whose names start with 'ge-'. Which approach would dynamically match these interfaces?

Trap 1: Create a firewall filter that matches ge- interfaces

Incorrect. Firewall filters filter traffic, not match interfaces for configuration application.

Trap 2: Use apply-path referencing a regular expression in the…

Incorrect. 'apply-path' does not support regular expression matching for interface names; it is used to include configuration from an external file or reference a path.

Trap 3: Use an interface-range named 'ge-interfaces' listing all ge-…

Incorrect. An interface-range requires manual listing of interfaces, which is not dynamic.

Study all Junos Configuration Basics common traps →

A
Define a configuration group and use apply-groups with [edit interfaces ge-*]
Correct. Defining a configuration group with wildcard interface names like 'ge-*' and applying it globally will apply the BGP configuration to all interfaces starting with 'ge-'.
B
Create a firewall filter that matches ge- interfaces
Why it fails: Incorrect. Firewall filters filter traffic, not match interfaces for configuration application.
C
Use apply-path referencing a regular expression in the configuration group
Why it fails: Incorrect. 'apply-path' does not support regular expression matching for interface names; it is used to include configuration from an external file or reference a path.
D
Use an interface-range named 'ge-interfaces' listing all ge- interfaces
Why it fails: Incorrect. An interface-range requires manual listing of interfaces, which is not dynamic.

Full breakdown with real-world context →

Question 18mediummultiple choice

Read the full Junos Configuration Basics explanation →

Under what circumstance would the 'deactivate' command be useful in Junos configuration?

Trap 1: To delete a configuration statement after commit

Deactivate does not remove the statement from the configuration; it merely sets the inactive flag in the candidate configuration. Deleting a configuration statement requires the 'delete' command, which removes the statement entirely from the hierarchy. After commit, the deactivated statement remains present but disabled, whereas a deleted statement no longer exists in the configuration.

Trap 2: To permanently remove a configuration statement

Permanently removing a configuration statement is done with 'delete' and then committing the candidate configuration. Deactivation does not permanently remove anything; it only toggles an 'inactive' marker that can be reversed with 'activate' at any time. The statement remains in the configuration text, typically preceded by the 'inactive:' indicator, and can be re-enabled without re-entering the original commands.

Trap 3: To mark a statement as inactive while keeping it in the active…

Deactivation takes effect only after you commit the candidate configuration; it does not simultaneously keep the statement active. If you want to mark a statement as inactive in the active configuration, you must commit the deactivation. The statement is then present in the active configuration but marked with 'inactive:' and is not enforced by Junos. Simply marking it as inactive while it remains active is contradictory—deactivation is a change that becomes effective only upon commit.

Study all Junos Configuration Basics common traps →

A
To delete a configuration statement after commit
Why it fails: Deactivate does not remove the statement from the configuration; it merely sets the inactive flag in the candidate configuration. Deleting a configuration statement requires the 'delete' command, which removes the statement entirely from the hierarchy. After commit, the deactivated statement remains present but disabled, whereas a deleted statement no longer exists in the configuration.
B
To permanently remove a configuration statement
Why it fails: Permanently removing a configuration statement is done with 'delete' and then committing the candidate configuration. Deactivation does not permanently remove anything; it only toggles an 'inactive' marker that can be reversed with 'activate' at any time. The statement remains in the configuration text, typically preceded by the 'inactive:' indicator, and can be re-enabled without re-entering the original commands.
C
To temporarily disable a configuration statement without removing it from the configuration
The 'deactivate' command is used to disable a configuration statement for a temporary period, e.g., during maintenance or troubleshooting. It preserves the full configuration hierarchy and parameters, allowing you to quickly re-enable the statement with the 'activate' command. Because the statement remains in the candidate configuration, it is still visible and can be edited, but is not applied to the running configuration until reactivated. This is ideal for testing changes without permanently deleting configuration elements.
D
To mark a statement as inactive while keeping it in the active configuration
Why it fails: Deactivation takes effect only after you commit the candidate configuration; it does not simultaneously keep the statement active. If you want to mark a statement as inactive in the active configuration, you must commit the deactivation. The statement is then present in the active configuration but marked with 'inactive:' and is not enforced by Junos. Simply marking it as inactive while it remains active is contradictory—deactivation is a change that becomes effective only upon commit.

Full breakdown with real-world context →

Question 19mediummulti select

Read the full Junos Configuration Basics explanation →

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

Trap 1: The 'apply-groups' statement is only valid at the top level of the…

The 'apply-groups' statement is not limited to the top level; it can be used at any hierarchy level, such as under 'interfaces' or 'protocols'. When placed in a stanza, it applies the referenced group's configuration exactly at that level, allowing scoped reuse of configuration snippets.

Trap 2: Configuration groups can only contain interface-related…

Configuration groups are generic templates that can hold any valid Junos configuration, including routing-options, policy-options, firewall filters, and system settings. They are not restricted to interface-related statements; they simply provide a way to factor out reusable blocks of configuration regardless of the functional area.

Trap 3: The 'apply-groups' statement can be used to apply only specific…

The 'apply-groups' statement always applies the entire contents of the named group as a whole; there is no syntax to selectively apply only certain statements within a group. To apply a subset, you must define a smaller group or use 'apply-groups-except' to exclude specific statements, but the base statement itself does not support per-statement filtering.

Study all Junos Configuration Basics common traps →

A
The 'apply-groups' statement is only valid at the top level of the configuration.
Why it fails: The 'apply-groups' statement is not limited to the top level; it can be used at any hierarchy level, such as under 'interfaces' or 'protocols'. When placed in a stanza, it applies the referenced group's configuration exactly at that level, allowing scoped reuse of configuration snippets.
B
Configuration groups can only contain interface-related configuration.
Why it fails: Configuration groups are generic templates that can hold any valid Junos configuration, including routing-options, policy-options, firewall filters, and system settings. They are not restricted to interface-related statements; they simply provide a way to factor out reusable blocks of configuration regardless of the functional area.
C
The 'apply-groups' statement can be used to apply only specific statements from a group.
Why it fails: The 'apply-groups' statement always applies the entire contents of the named group as a whole; there is no syntax to selectively apply only certain statements within a group. To apply a subset, you must define a smaller group or use 'apply-groups-except' to exclude specific statements, but the base statement itself does not support per-statement filtering.
D
Multiple groups can be applied, and the order of application determines priority.
Multiple groups can be applied to the same configuration hierarchy, and the order in which they are listed is significant. The groups are processed sequentially, with later groups overriding earlier groups when the same parameter is set in more than one group; this precedence rule is a key part of how configuration groups are resolved.
E
Configuration groups are defined under the 'groups' hierarchy.
Configuration groups are defined under the 'groups' hierarchy in the configuration, typically using 'edit groups group-name'. This hierarchy acts as a repository for reusable configuration templates; the statements within a group do not take effect until the group is referenced via 'apply-groups' at the desired level of the active configuration.

Full breakdown with real-world context →

Question 20mediummultiple choice

Read the full Junos Configuration Basics explanation →

Refer to the exhibit. What is the most likely cause of the commit check failure?

Exhibit

Refer to the exhibit.

[edit]
user@router# commit check
[edit interfaces xe-0/0/0 unit 0 family inet]
    'address 10.1.1.1/24'
    Error: Cannot configure an address on an interface that is not enabled with 'unit 0'
error: configuration check-out failed

Trap 1: The routing instance has not been created.

In Junos, a routing instance that does not exist is resolved during commit, generating errors like 'routing instance not found' or a parse/commit failure, not an operational error at the [edit interfaces] hierarchy. The error in the exhibit specifically references the interface being 'not enabled', which is a state of the physical or logical interface itself, independent of any routing instance association. A missing routing instance would not block address assignment; the interface can be configured even if it is not assigned to a custom routing instance.

Trap 2: The interface xe-0/0/0 has been disabled using the 'disable'…

The 'disable' statement at the [edit interfaces xe-0/0/0] hierarchy level administratively brings the interface down. Junos enforces that you cannot assign an IP address to a unit on a disabled interface, because the interface is not operationally able to pass traffic. This produces exactly the error message shown: 'cannot configure an address on an interface that is not enabled.' To fix it, remove the disable statement with 'delete interfaces xe-0/0/0 disable' and commit, or re-enable the interface explicitly.

Trap 3: The IP address is a duplicate on the subnet.

A duplicate IP address on the same subnet would typically trigger an ARP/ND conflict detection or a commit-time warning like 'duplicate address' or 'is already in use', not a configuration rejection. The error shown occurs before any address binding, at the point of adding the address, and it refers to the interface's enabled state rather than to address uniqueness. Additionally, Junos does not check for duplicate addresses on a subnet during address configuration; that is a runtime concern handled by protocols such as ARP.

Study all Junos Configuration Basics common traps →

A
The routing instance has not been created.
Why it fails: In Junos, a routing instance that does not exist is resolved during commit, generating errors like 'routing instance not found' or a parse/commit failure, not an operational error at the [edit interfaces] hierarchy. The error in the exhibit specifically references the interface being 'not enabled', which is a state of the physical or logical interface itself, independent of any routing instance association. A missing routing instance would not block address assignment; the interface can be configured even if it is not assigned to a custom routing instance.
B
The interface xe-0/0/0 has been disabled using the 'disable' statement.
Why it fails: The 'disable' statement at the [edit interfaces xe-0/0/0] hierarchy level administratively brings the interface down. Junos enforces that you cannot assign an IP address to a unit on a disabled interface, because the interface is not operationally able to pass traffic. This produces exactly the error message shown: 'cannot configure an address on an interface that is not enabled.' To fix it, remove the disable statement with 'delete interfaces xe-0/0/0 disable' and commit, or re-enable the interface explicitly.
C
The IP address is a duplicate on the subnet.
Why it fails: A duplicate IP address on the same subnet would typically trigger an ARP/ND conflict detection or a commit-time warning like 'duplicate address' or 'is already in use', not a configuration rejection. The error shown occurs before any address binding, at the point of adding the address, and it refers to the interface's enabled state rather than to address uniqueness. Additionally, Junos does not check for duplicate addresses on a subnet during address configuration; that is a runtime concern handled by protocols such as ARP.
D
The 'family inet' statement is missing under unit 0.
The 'family inet' statement under unit 0 is clearly present in the exhibit, so this option is factually incorrect. Even if it were missing, the resulting error would be a configuration hierarchy or 'missing family' parse error, not the exact message stating that the interface is 'not enabled'. This error is tied specifically to the interface-level 'disable' statement, which is a separate condition from the presence or absence of a protocol family.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Junos Configuration Basics sessions

Start a Junos Configuration Basics only practice session

Every question in these sessions is drawn from the Junos Configuration Basics domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Junos Configuration Basics questions →Mixed JN0-106 session

Frequently asked questions

What does the JN0-106 exam test about Junos Configuration Basics?: Be able to configure commit confirmed with a timeout, roll back to a prior configuration, and read a firewall filter to predict which traffic is permitted or rejected. The key skill is knowing that unconfirmed changes revert automatically and that rollback requires a commit to take effect.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Junos Configuration Basics questions in a focused session?: Yes — the session launcher on this page draws every question from the Junos Configuration Basics domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other JN0-106 topics?: Use the topic links above to move to related areas, or go back to the JN0-106 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the JN0-106 exam covers. They are not copied from any real exam or dump site.

Junos Configuration Basics only

10 questions 20 questions 30 questions 50 questions

Mixed JN0-106 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All JN0-106 questions Junos Configuration Basics domain overview JN0-106 exam guide

Exam traps to avoid

▸Confusing commit confirmed with a plain commit: only commit confirmed auto-reverts if not confirmed within the timeout.
▸Assuming rollback restores the running config without a commit; rollback loads the candidate and still needs commit.
▸Forgetting that firewall filter terms are evaluated in order, so a broad reject placed before a permit blocks the intended traffic.

Junos Configuration Basics practice questions

What to know about Junos Configuration Basics

Common Junos Configuration Basics exam traps

Junos Configuration Basics questions

A network engineer is configuring a new Juniper device. They intend to apply a firewall filter to an interface to only allow SSH traffic from a specific management subnet. Which configuration approach best follows Juniper best practices?

A junior engineer is asked to change the hostname of a Juniper device from 'Router-1' to 'Core-Router'. Which command sequence correctly commits the change?

A network administrator wants to view the current candidate configuration that has not yet been committed. Which command should be used?

After making several configuration changes, an engineer wants to see what changes were made in the candidate configuration compared to the last committed configuration. Which command should be used?

Which TWO statements are true regarding the Junos OS commit model?

Which THREE are valid methods to apply a firewall filter in Junos?

Which TWO are correct statements about the Junos configuration hierarchy?

Exhibit

Which TWO statements correctly describe Junos configuration hierarchy and management?

Refer to the exhibit. What is the purpose of the 'family inet6' configuration on interface ge-0/0/0?

Exhibit

Order the steps to configure a VLAN on an EX Series switch running Junos.

Order the steps to configure a BGP peering session in Junos.

Match each Junos configuration mode command to its purpose.

Match each Junos software process to its role.

An administrator wants to apply the same BGP configuration to all interfaces whose names start with 'ge-'. Which approach would dynamically match these interfaces?

Under what circumstance would the 'deactivate' command be useful in Junos configuration?

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

Refer to the exhibit. What is the most likely cause of the commit check failure?

Exhibit

Track your progress over time

Start a Junos Configuration Basics only practice session

Related JN0-106 topic practice pages

User Interfaces practice questions