JNCIA-DevOps Junos Automation Stack And DevOps Concepts — 25 Questions

Question 1

Which Junos automation architecture component provides standardized, model-driven interfaces using NETCONF and gRPC/gNMI to manage and monitor Junos devices?

Accepted Answer

Junos XML API and schema definitions. Junos API and data modeling components like NETCONF and gRPC provide structured, programmatic access to the Junos control plane.

Answer

The Junos CLI pipe filter 'match' command

Answer

Proprietary screen-scraping CLI scripts running in a crontab daemon

Answer

The physical console cable attached to the Routing Engine

Question 2

An automation script connects to a Junos device and attempts to load a candidate configuration using NETCONF. The script needs to ensure that if any part of the configuration fails validation, the entire transaction is discarded and the candidate database is left untouched. Which NETCONF capability or tag should be utilized?

Accepted Answer

The candidate configuration database lock combined with atomic transaction semantics provided by NETCONF and operations.. NETCONF supports robust transaction handling, ensuring that configuration changes are validated as a block and rolled back on error.

Answer

The SNMP trap notification daemon running on port 162

Answer

The <rollback> RPC with an explicit configuration revision number

Answer

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

Question 3

Which Junos automation tool utilizes NETCONF over SSH by default to manage network devices using Python libraries or configuration management frameworks?

Accepted Answer

Junos PyEZ. Ansible, PyEZ, and NETCONF clients communicate with Junos using NETCONF over SSH by default.

Answer

The local Junos shell (sh) utility

Answer

Wireshark packet analyzer

Answer

Junos Space Network Management Platform GUI

Question 4

An enterprise uses Git for tracking Junos configurations. An engineer wants to see the exact line-by-line history of changes made to a specific routing policy file over the past month, including who made each change. Which Git command should they use?

Accepted Answer

git blame or git log -p . 'git blame' shows what revision and author last modified each line of a file, while 'git log' shows commit history.

Answer

git history --routing-policy

Answer

git diff --author

Answer

git status --verbose

Question 5

An automation pipeline tests Junos configuration changes against a virtual Junos device (such as vSRX or cRPD) in a CI environment before deploying to physical hardware. What is this practice called?

Accepted Answer

Virtual staging and pre-deployment validation testing. Testing against virtualized network functions in a staging or CI environment is known as lab validation or digital twinning/staging.

Answer

Production traffic shedding

Answer

Static code linting

Answer

Hardware refactoring

Question 6

An automation engineer is using Git and needs to undo the last local commit while keeping the modified changes in their working directory as unstaged changes. Which command should they execute?

Accepted Answer

git reset HEAD~1 (or git reset --mixed HEAD~1). 'git reset --soft HEAD~1' or 'git reset HEAD~1' resets the commit while keeping working tree files modified/staged depending on flags. 'git reset HEAD~1' defaults to mixed (keeps changes unstaged).

Answer

git reset --hard HEAD~1

Answer

git checkout -f master

Answer

git revert --purge

Question 7

An engineer wants to inspect the differences between two committed configurations on a Junos device using the CLI or automation tools. Which operation does this correspond to in Junos configuration management?

Accepted Answer

Comparing configuration revisions (e.g., rollback comparison) to audit modifications before committing.. Comparing configuration revisions is done using comparison features (e.g., 'show configuration | compare').

Answer

Running a traceroute across the management network

Answer

Performing a NETCONF <discard-changes> operation

Answer

Reloading the Junos kernel image

Question 8

A DevOps engineer is implementing a CI/CD pipeline for automated testing of Junos configurations. During the build stage, the pipeline executes a syntax check on candidate configurations before staging them for deployment. Which tool natively provides configuration syntax validation against the Junos schema without applying the configuration to the routing engine?

Accepted Answer

Junos PyEZ configuration mode via the 'cu.validate()' method. The Junos PyEZ library provides a configuration management module that allows validation of candidate configurations locally or on the device using validate() without committing changes.

Answer

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

Answer

SaltStack junos.commit execution module

Answer

git-lfs configuration validator

Question 9

An engineer is automating Junos device deployments using Ansible. They need to push a set of hierarchical configuration changes to a cluster of MX Series routers and ensure the changes are committed only if there are no syntax errors, while keeping the connection open for subsequent tasks. Which Ansible module and parameter combination should be used?

Accepted Answer

junipernetworks.junos.junos_config with 'update: merge' and 'diff: true'. The junipernetworks.junos.junos_config module manages Junos configurations, and the 'confirm' or 'diff' parameters manage operational validation, while the transport connection is handled automatically by the collection.

Answer

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

Answer

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

Answer

netconf_config with 'provider: junos'

Question 10

A network engineer is exploring the core components of the Junos automation architecture. Which TWO components are native Junos daemons or automation frameworks directly involved in script execution or API processing? (Choose TWO)

Accepted Answer

jsd (Junos Script Daemon). Option A, jsd (Junos Script Daemon), is correct because it is the native Junos daemon responsible for executing commit, event, op, and SNMP scripts written in SLAX, XSLT, or Python, and it also handles the Junos XML API and NETCONF session processing. Option D, mgd (Management Daemon), is correct because it is the core Junos management process that parses CLI and configuration input, manages the candidate and active configuration databases, and invokes jsd when scripts must run during commit or operational commands. Option B, snmpd, is not a script-execution or API-processing framework; it implements the SNMP agent for polling and traps, even though it can trigger event scripts indirectly. Option C, sshd, only provides encrypted remote CLI/NETCONF transport and does not itself execute automation scripts or process the Junos API. Option E, httpd, is not a native Junos automation daemon for script execution or API processing in this context.

Answer

snmpd (Simple Network Management Protocol Daemon)

Answer

sshd (Secure Shell Daemon)

Answer

httpd (Hypertext Transfer Protocol Daemon)

Question 11

You are writing a Python script that must run on a Junos device's internal management VM without installing any third-party packages. You need to retrieve the device's running configuration as structured data. Which statement about the Junos PyEZ library's availability on Junos devices is true?

Accepted Answer

PyEZ is not included in the Junos image but can be installed on-box using pip or by extracting the Juniper-provided package to the device's /var/tmp directory.. PyEZ is a Python library distributed outside the base Junos image. To use it on a device's internal management VM, you install it via pip or by extracting the Juniper-provided package and adjusting PYTHONPATH. The other statements incorrectly claim it is bundled, platform-restricted, or exclusive to Junos Evolved, none of which reflect how PyEZ is actually delivered and used.

Answer

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

Answer

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

Answer

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

Question 12

A DevOps engineer is using Ansible to manage Junos devices. The playbook must ensure that a specific configuration stanza is present and that the device commits the change only if the configuration differs from the candidate. Which Ansible module and parameter combination should be used?

Accepted Answer

juniper.device with config and commit=true. The juniper.device module from the Juniper Ansible collection is purpose-built for Junos automation. It supports loading configuration and committing changes, and with commit=true it commits only if there is a difference. The other modules either lack idempotent commit behavior or are not designed for configuration management. This makes juniper.device with config and commit=true the correct choice.

Answer

junos_config with src and comment

Answer

cli_config with lines and backup

Answer

junos_command with commands and wait_for

Question 13

A DevOps team is implementing a CI/CD pipeline for Junos device configuration changes. They want to ensure that configuration changes are validated before being deployed to production devices. Which TWO practices are essential for achieving this validation in a Junos automation pipeline? (Choose two.)

Accepted Answer

Running a syntax check on the candidate configuration using the 'commit check' command on a lab device.. To validate Junos configuration changes before deployment, the team should run 'commit check' on a lab device to verify syntax and semantics, and use version control with peer review to catch logical errors. These practices ensure that changes are technically valid and reviewed before reaching production. Deploying directly to production, relying solely on linters, or committing to all devices at once do not provide the necessary validation and can introduce risk. A robust pipeline combines automated checks with human oversight.

Answer

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

Answer

Automatically committing changes to all devices simultaneously to save time.

Answer

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

Question 14

What is the primary benefit of using structured data formats (such as XML, JSON, or YAML) over unstructured CLI text output in Junos automation?

Accepted Answer

They allow automation scripts to parse device output reliably without relying on brittle regular expressions.. Structured data formats can be easily parsed programmatically without relying on fragile regular expressions.

Answer

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

Answer

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

Answer

They automatically convert all IPv4 addresses to IPv6 format.

Question 15

In a DevOps pipeline managing Junos devices, an engineer implements 'Infrastructure as Code' (IaC). Which practice best exemplifies this methodology when applied to Junos routing policies?

Accepted Answer

Defining routing policies in Jinja2 templates and YAML data files, committing them to Git, and automatically pushing them via Ansible playbooks.. IaC defines infrastructure in declarative configuration files stored in version control, allowing automated testing and deployment.

Answer

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

Answer

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

Answer

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

Question 16

An engineer needs to explain the primary advantage of treating network configurations as code in a modern DevOps workflow. Which principle best describes this approach?

Accepted Answer

Storing configurations in a version control system to track history, enable rollbacks, and facilitate collaboration.. Treating network configurations as code allows infrastructure to be version-controlled, repeatedly deployed, and tested just like software code.

Answer

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

Answer

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

Answer

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

Question 17

You are configuring a CI/CD pipeline for Junos network deployments. The pipeline must validate the syntax of generated candidate configurations against a physical or virtual Junos device before committing them to production. Which stage of the CI/CD pipeline does this validation step represent?

Accepted Answer

Continuous Integration validation stage. The validation of candidate configuration syntax against a Junos device before committing to production is a pre-merge quality gate, which is the essence of the Continuous Integration (CI) validation stage. In CI, every code change triggers automated builds and tests to catch errors early. Here, the 'code' is the generated Junos configuration, and the test is a syntax check using the device's configuration parser (e.g., via `commit check` or loading the config with `load merge` and `commit check`). This ensures that only syntactically valid configurations proceed to deployment, preventing broken commits from reaching production.

Answer

Continuous Deployment stage

Answer

Continuous Monitoring stage

Answer

Infrastructure Provisioning stage

Question 18

Your CI/CD pipeline includes a linters step before deployment. Why is running a linter against YAML or Jinja2 template files critical in a Junos automation workflow?

Accepted Answer

To detect syntax errors, indentation issues, and style violations in template and data files before deployment.. Linters analyze source code or configuration files for syntax errors, indentation issues, and style violations without executing them. In a Junos automation workflow, running a linter against YAML or Jinja2 templates before deployment catches errors early, preventing failed deployments and reducing troubleshooting time. This is critical because YAML is indentation-sensitive and Jinja2 templates can have syntax errors that only surface at render time.

Answer

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

Answer

To automatically execute unit tests against live BGP peering sessions.

Answer

To encrypt sensitive passwords stored within plaintext configuration files.

Question 19

A network engineer is using Git for version control of Junos configurations. During a peer review on a pull request, a merge conflict arises because two engineers modified the same interface description line in different branches. What is the correct procedure to resolve this conflict in Git?

Accepted Answer

Manually edit the conflict markers in the affected configuration file, stage the resolved file, and complete the merge commit.. Git marks the conflicting lines in the file, requiring manual editing to choose the correct changes or combine them, followed by staging and committing the resolution.

Answer

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

Answer

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

Answer

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

Question 20

An automation engineer is designing a deployment strategy for Junos devices using Git branches. Which branching strategy model aligns best with continuous delivery where feature branches are merged frequently into a shared integration branch that automatically triggers staging tests?

Accepted Answer

Trunk-based development where developers merge small, frequent changes into a central main branch that drives automated pipelines.. Trunk-based development aligns best with continuous delivery because developers merge small, frequent changes into a central main branch, which automatically triggers staging tests via CI/CD pipelines. This reduces merge conflicts, shortens feedback loops, and keeps the main branch always deployable.

Answer

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

Answer

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

Answer

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