JN0-106 Junos Configuration Basics Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  use the 'deactivate' command to mark the statements inactive

  Why this is correct

  The 'deactivate' command is the Junos-native method for temporarily disabling a statement or hierarchy from the active configuration. It prepends an 'inactive:' marker to the statement in the candidate configuration, so the configuration text remains fully intact and editable, but the statement is ignored during commit. This allows you to quickly re-enable the configuration with the 'activate' command without re-entering it, and it can be applied to any hierarchy level, from a single parameter to an entire protocol stanza.

• ✗

  delete the statements and later re-add from a backup

  Why it's wrong here

  Deleting statements and later re-adding them from a backup is error-prone and inefficient in Junos because the configuration is a live candidate that must be manually re-applied. If the backup is not byte-for-byte current with the rest of the configuration, you risk overwriting unrelated changes made in the interim. Furthermore, there is no automatic way to 're-add' deleted lines; you would have to load the backup file, which could replace the entire candidate configuration or require a merge that may conflict. Junos specifically provides 'deactivate' to avoid this destructive workflow.

• ✗

  comment out the lines using #

  Why it's wrong here

  Junos does not support using '#' (or other comment characters) to comment out lines in the configuration hierarchy. The configuration parser only accepts Junos configuration statements, and any line beginning with '#' is either rejected as a syntax error or, in some contexts, treated as an unknown string that breaks the configuration load. The only supported way to add non-operative text is the 'annotate' statement, which attaches a comment to a configuration element, but it does not disable that element. Therefore, commenting out lines cannot temporarily disable anything in the active configuration.

• ✗

  set the configuration to a different group and remove apply-groups

  Why it's wrong here

  Moving the statements to a configuration group and removing the 'apply-groups' directive is a disruptive and indirect approach. Configuration groups are intended for reusing shared parameter sets across multiple locations, and removing 'apply-groups' would disable all group-defined settings, not just the specific statements you want to turn off. Additionally, the statements would still exist in the group under the 'groups' hierarchy, and you would later need to re-add the 'apply-groups' statement, which could affect other configuration sections. This approach introduces global side effects and does not pinpoint the targeted configuration that needs to be temporarily disabled.

Go deeper

Related to this question