Junos Automation Stack And DevOps Concepts practice questions

The Junos CLI pipe filter 'match' command

Why it fails: Pipe filters are for manual CLI text manipulation.

Proprietary screen-scraping CLI scripts running in a crontab daemon

Why it fails: Screen-scraping is legacy and non-model-driven.

The physical console cable attached to the Routing Engine

Why it fails: A console cable provides manual CLI access, not a model-driven automation interface.

The SNMP trap notification daemon running on port 162

Why it fails: SNMP is an asynchronous monitoring and management protocol, not a transactional configuration mechanism.

The <rollback> RPC with an explicit configuration revision number

Why it fails: Rollback reverts to a previously committed configuration, not transaction validation.

The 'cli -s' force-override flag in an SSH execution session

Why it fails: This is a CLI construct, not a NETCONF feature.

The local Junos shell (sh) utility

Why it fails: The local shell runs UNIX commands, not NETCONF.

Wireshark packet analyzer

Why it fails: Wireshark is a packet capture and analysis tool.

Junos Space Network Management Platform GUI

Why it fails: Junos Space is a management platform, not a Python-based NETCONF tool.

git history --routing-policy

Why it fails: No such Git command exists.

git diff --author

Why it fails: git diff compares trees or commits, not file-level line history by author.

git status --verbose

Why it fails: git status shows the working tree status, not historical line changes.

Production traffic shedding

Why it fails: Traffic shedding is a mechanism for handling congestion, not testing.

Static code linting

Why it fails: Linting checks file syntax, whereas running a virtual device executes functional tests.

Hardware refactoring

Why it fails: Hardware refactoring refers to physical component changes.

git reset --hard HEAD~1

Why it fails: --hard destroys all working directory changes.

git checkout -f master

Why it fails: This discards local work and switches to master.

git revert --purge

Why it fails: No such command as git revert --purge exists.

Running a traceroute across the management network

Why it fails: Traceroute tests IP packet paths.

Performing a NETCONF <discard-changes> operation

Why it fails: Discarding changes removes the candidate configuration.

Reloading the Junos kernel image

Why it fails: Reloading the kernel reboots the device.

Ansible junipernetworks.junos.junos_config module with 'check_mode: true'

Why it fails: Check mode in Ansible dry-runs tasks, but structural Junos candidate validation is best handled via PyEZ validate or specialized lint tools.

SaltStack junos.commit execution module

Why it fails: junos.commit applies or checks commits, but PyEZ is the native Python library standard for programmatic validation.

git-lfs configuration validator

Why it fails: Git Large File Storage (LFS) is used for managing large binary files, not Junos syntax validation.

junipernetworks.junos.junos_command with 'commands: ["configure", "commit check"]'

Why it fails: junos_command executes raw CLI commands rather than structured declarative configuration management.

ansible.builtin.template with 'dest: /config/juniper.conf'

Why it fails: Directly writing files to the Junos file system bypasses management plane validation and mgd.

netconf_config with 'provider: junos'

Why it fails: While generic netconf modules exist, the dedicated junipernetworks.junos collection is the standard JNCIA-DevOps recommended toolset.

snmpd (Simple Network Management Protocol Daemon)

Why it fails: snmpd handles legacy SNMP polling and traps, not modern Junos automation workflows.

sshd (Secure Shell Daemon)

Why it fails: sshd handles secure shell transport connections, not script execution or Junos API parsing.

httpd (Hypertext Transfer Protocol Daemon)

Why it fails: httpd is a standard web server daemon, not a core Junos automation engine.

PyEZ is only available as a compiled binary for x86 Linux servers and cannot run inside the Junos FreeBSD-based management VM.

Why it fails: PyEZ is pure Python and runs on the Junos FreeBSD-based management VM as well as on external Linux hosts. There is no x86-only binary restriction. Claiming it cannot run on-box contradicts the supported on-box automation model, so this option is technically wrong for the described environment.

PyEZ is included only in Junos Evolved images, not in standard Junos OS images, so the device must be upgraded to Junos Evolved first.

Why it fails: PyEZ is not exclusive to Junos Evolved. It supports standard Junos OS devices through NETCONF over SSH and is commonly used on-box and off-box. Requiring an upgrade to Junos Evolved is unnecessary and incorrect; the library works with the existing Junos OS management VM once installed.

PyEZ is pre-installed on all Junos devices as part of the standard Junos image, so no installation is required.

Why it fails: PyEZ is not bundled with the standard Junos image. The on-box Python environment provides core Python and some Junos-specific modules, but PyEZ is distributed as an external package via pip or the Juniper archive. Assuming it is pre-installed would cause import errors on a freshly imaged device, so this statement is incorrect for the scenario.

junos_config with src and comment

Why it fails: The junos_config module (legacy) can load configuration from a source file, but it does not inherently check for differences before committing. The comment parameter only adds a commit comment. It does not guarantee that commit occurs only if the configuration differs; it may commit even if no changes are present. The scenario requires conditional commit based on difference, which junos_config does not provide by default.

cli_config with lines and backup

Why it fails: cli_config is a generic module for sending CLI commands to network devices, but it is not Junos-specific and does not handle Junos configuration transactions. It can send configuration commands, but it lacks the idempotency and commit-on-difference logic. The backup parameter saves the configuration but does not control commit behavior. This module would not ensure that commit occurs only when the configuration differs.

junos_command with commands and wait_for

Why it fails: junos_command is used to execute operational commands on Junos devices, not to manage configuration. It can run show commands and wait for specific output, but it cannot push configuration changes or commit them. The scenario requires configuration management with conditional commit, which junos_command does not support. It is intended for retrieving information, not for configuration.

Deploying changes directly to production devices and relying on rollback if errors occur.

Why it fails: Deploying directly to production without prior validation is risky and contradicts the goal of validating changes before deployment. While Junos supports rollback, relying on it as the primary safety net can lead to service disruptions. In this scenario, the team wants to validate before deployment, so this practice is not essential and is actually discouraged. It bypasses the validation steps that are central to a robust CI/CD pipeline for network automation.

Automatically committing changes to all devices simultaneously to save time.

Why it fails: Committing changes to all devices simultaneously without validation increases the blast radius of any error. In this scenario, the team aims to validate before deployment, so this practice is counterproductive. It skips the validation steps and can cause widespread outages if a faulty configuration is applied. A controlled rollout with validation stages is preferred. Thus, this practice is not essential and is actually harmful to the goal of safe configuration deployment.

Using a linter to check YAML and Jinja2 templates for syntax errors and style issues.

Why it fails: Linting templates is a useful practice, but it is not sufficient for validating the final Junos configuration. Linters catch syntax errors in templates but do not verify that the rendered configuration is valid on a Junos device. In this scenario, the team needs to validate the actual configuration that will be applied. Linting is a complementary step, but it does not replace device-level validation such as 'commit check'. Therefore, it is not one of the two essential practices for ensuring configuration validity.

Structured data formats take up less memory on the Junos Routing Engine hard drive.

Why it fails: Structured formats such as XML and JSON typically add tags and delimiters, so they often consume more storage than compact CLI text. Their value lies in machine-parseable key-value hierarchies, not disk footprint, making this claim technically backwards for the stated comparison.

They eliminate the need to authenticate when connecting via NETCONF or gRPC.

Why it fails: NETCONF and gRPC still require authentication via SSH keys, certificates, or user credentials; structured payloads only change encoding, not the transport security handshake. Authentication remains mandatory regardless of whether the response is XML, JSON, or YAML.

They automatically convert all IPv4 addresses to IPv6 format.

Why it fails: Structured formats parse into typed fields, so scripts read values directly; they never rewrite addressing, and no XML, JSON or YAML parser performs IPv4-to-IPv6 translation. The tempting association is that structured output supports automated transformation, but dual-stack migration requires explicit tooling such as Junos address translation or configuration templates, not the format itself.

Writing custom Python scripts that use regex to parse 'show route' outputs on the fly.

Why it fails: Regex parsing of live 'show route' output reads operational state rather than declaring routing policy as version-controlled code, so nothing is provisioned reproducibly. It is tempting because Python automation removes manual typing, which would be correct for ad-hoc operational reporting, not for defining policy-options declaratively.

Manually logging into each router via SSH during a maintenance window to type out policy-options statements.

Why it fails: Typing policy-options statements manually over SSH creates no version-controlled, repeatable artefact, so it is configuration by hand rather than Infrastructure as Code. It is tempting because SSH is the standard way to apply Junos configuration, and would be correct for one-off changes where no pipeline or reproducibility is required.

Using dynamic routing protocols like BGP to automatically advertise prefixes without human intervention.

Why it fails: BGP advertises reachability dynamically at runtime; it does not define routing policy as version-controlled, declarative configuration committed through a pipeline. It is tempting because dynamic protocols remove manual intervention, which would be correct for automating prefix propagation, not for expressing policy-options as code.

Immutable infrastructure deployment where devices are replaced rather than updated manually.

Why it fails: Immutability concerns replacing whole device instances, not the practice of storing configuration in version control. Treating configurations as code delivers peer review, versioning and repeatable deployment through pipelines; immutability is a separate deployment pattern used when rebuilds are cheaper than in-place patching.

Compiling the network CLI commands into binary machine code before executing them on Junos devices.

Why it fails: Configuration as code means storing configs in version control and applying them through automated pipelines, not compiling CLI commands into binaries. Compilation tempts as a build concept, yet Junos executes text configuration; the advantage is reviewable, repeatable declarative state.

Automating the complete removal of the command-line interface in favor of graphical topology builders.

Why it fails: Removing the CLI is not the goal; configurations-as-code still drives devices through their existing interfaces. The principle is version-controlled, reviewable, automatically tested configuration. Graphical topology builders address visual design and documentation, which is unrelated to pipeline-driven configuration management.

Continuous Deployment stage

Why it fails: Continuous Deployment is the stage that promotes validated artefacts into production and commits them to live devices. Syntax validation against a Junos device occurs earlier, in the testing or build stage, before any release decision. Continuous Deployment would be correct when automatically pushing an approved configuration to production devices.

Continuous Monitoring stage

Why it fails: Continuous Monitoring observes running systems after deployment, collecting telemetry, logs and alerts on live traffic. Syntax validation happens before commit, so no production system exists yet to monitor. Monitoring would be correct for detecting configuration drift or post-deployment failures once the configuration is already active.

Infrastructure Provisioning stage

Why it fails: Infrastructure Provisioning concerns standing up the underlying compute, network or virtualised resources a pipeline runs on, not checking configuration syntax. Validating candidate configuration against a Junos device is a test activity. Provisioning would be the right stage when creating the devices or environments themselves before deployment begins.

To compile YAML files into Junos microcode for the Packet Forwarding Engine.

Why it fails: Linters parse and validate syntax, indentation and schema; they do not compile YAML into Junos microcode, which is produced by Junos tooling for the Packet Forwarding Engine. Compilation is the correct concern when translating configuration into executable forwarding-plane instructions, not pre-deployment validation.

To automatically execute unit tests against live BGP peering sessions.

Why it fails: A linter parses template syntax and flags malformed YAML or Jinja2; it never opens BGP sessions or runs tests. Unit testing against live peers belongs to a separate test stage using tools such as PyEZ or Robot Framework, so this describes test execution, not static validation of configuration templates.

To encrypt sensitive passwords stored within plaintext configuration files.

Why it fails: Linters detect syntax, schema and style errors; they perform no cryptographic operations and cannot encrypt secrets in plaintext files. Encryption is the right control when protecting credentials at rest, typically via a secrets manager or Ansible Vault rather than a linting stage.

Reboot the Junos routing engine to clear the Git repository cache and force a fast-forward merge.

Why it fails: Rebooting a routing engine has no relationship to Git's index or merge state, and fast-forwarding is impossible once branches have diverged. Rebooting suits clearing device runtime faults; conflict resolution requires editing the marked conflict regions and committing.

Run the 'git force-merge' command to automatically discard the older branch's changes.

Why it fails: No 'git force-merge' command exists in Git, so the operation cannot run at all. Force-style operations such as 'git push --force' overwrite remote history when you intend to discard published commits, not to merge conflicting edits.

Use 'git reset --hard' on the remote repository to delete both conflicting branches entirely.

Why it fails: 'git reset --hard' rewrites the local branch tip and discards uncommitted work; it does not delete remote branches, and destroying both branches loses the reviewed changes. It is used to abandon local commits, not to reconcile divergent edits on a shared line.

Creating a separate permanent branch for every physical router in the network and never merging them.

Why it fails: Permanent per-router branches never merge, so no shared integration point exists to trigger staging tests and configuration drifts per device. Device-specific branches suit isolating hardware-unique overrides; continuous delivery needs short-lived feature branches converging on one integration branch.

Locking the master branch for 12 months while developing a single monolithic configuration update offline.

Why it fails: Locking master for 12 months prevents the frequent merges into a shared integration branch that continuous delivery depends on, and delays feedback until a single large release. Long-lived offline development suits infrequent, tightly controlled releases, not automated staging tests on every merge.

Using tag-based releases exclusively without utilizing any version control branches.

Why it fails: Tags mark commits but create no shared integration branch, so frequent merges cannot trigger staging tests automatically. Tag-based releases suit versioning immutable production artefacts after integration; continuous delivery requires feature branches merging into a common branch that fires the pipeline.