JNCIA-DevOps Python And PyEZ Practice Test 4 — 15 Questions

Question 1

What is the primary benefit of using PyEZ Table and View abstractions over raw RPC XML parsing in Python scripts?

Accepted Answer

They automatically convert XML into structured Python data structures like dictionaries and lists. PyEZ Table and View abstractions map Junos XML output to Python dictionaries and lists, eliminating the need for manual XML parsing. Tables define the structure and XPath, while Views map XML elements to Python attributes. This provides a clean, programmatic interface to operational data, making scripts more readable and maintainable.

Answer

They eliminate the need to establish a Device connection object

Answer

They allow direct execution of Junos CLI operational commands without NETCONF

Answer

They automatically commit configurations to the active database

Question 2

When using Jinja2 inheritance, which tag is placed in a base template to indicate where child templates can insert their custom content?

Accepted Answer

{% block block_name %} ... {% endblock %}. In Jinja2 template inheritance, the base (parent) template defines placeholders using the '{% block block_name %} ... {% endblock %}' syntax. Child templates then use '{% extends "base.html" %}' and override those named blocks with their own content. This is the standard mechanism for defining replaceable sections in a parent template.

Answer

Answer

{% insert block_name %}

Answer

{% child_content %}

Question 3

Which TWO characteristics describe JSNAPy snapshot operations? (Choose two)

Accepted Answer

It saves captured operational data into snapshot files for later comparison.. Option C is correct because JSNAPy's core function is to capture operational state (for example, via 'show' commands defined in a YAML file) and store that output into snapshot files, which serve as the reference data for later checks. Option E is correct because JSNAPy's primary use case is comparing snapshots — typically a post-change snapshot against a baseline pre-change snapshot — to detect configuration or operational drift, using commands like 'jsnapy --check' or 'jsnapy --snapcheck'. Options A, B, and D are incorrect: JSNAPy does not compile Jinja2 templates into CLI commands (that is the role of tools like Jinja2 templating with PyEZ or Junos PyEZ config utilities), it does not replace PyEZ as the NETCONF RPC library (JSNAPy actually relies on PyEZ under the hood), and it does not modify the active configuration database automatically — it only reports differences and never commits changes.

Answer

It compiles Jinja2 configuration templates directly into Junos CLI commands.

Answer

It replaces PyEZ as the primary library for executing NETCONF RPC calls.

Answer

It modifies the active configuration database automatically upon finding errors.

Question 4

Which TWO of the following are valid ways to instantiate a PyEZ Device object in Python, providing connection parameters? (Choose two)

Accepted Answer

dev = Device(host='192.168.1.1', user='admin', password='secret'). The PyEZ Device constructor accepts connection parameters as keyword arguments, so Device(host='192.168.1.1', user='admin', password='secret') is a valid instantiation that supplies the host, username, and password directly. Option E is also correct because the Device constructor accepts the host as the first positional argument along with keyword parameters such as user and ssh_private_key, so Device('192.168.1.1', user='admin', ssh_private_key='/path/to/key') properly creates a Device object using key-based authentication. Option B is not valid because Device.connect() is not a classmethod for instantiation; connection is performed via the open() method on an already-created Device instance. Option C is not valid because PyEZ does not provide a Device.from_cli() constructor. Option D is not valid because database='candidate' is not a connection parameter for instantiating a Device; the candidate configuration is selected later via the Config or cu.load() mechanisms, not at object creation.

Answer

dev = Device.connect('192.168.1.1')

Answer

dev = Device.from_cli('192.168.1.1')

Answer

dev = Device(database='candidate')

Question 5

Which TWO statements are true regarding PyEZ Table and View definitions? (Choose two)

Accepted Answer

A View defines how individual fields within the returned XML elements are mapped to Python dictionary keys.. Option C is correct because a PyEZ View specifies the mapping between fields in the returned XML (via XPath expressions) and the corresponding Python dictionary keys, allowing structured access to the data. Option D is correct because PyEZ Tables are commonly defined in YAML files, where you declare the table's XPath, view, and key/column mappings. Option A is wrong because Tables are primarily used to retrieve and parse operational state, not to modify configuration. Option B is wrong because Tables parse XML directly using their View definitions; Jinja2 templates are used for configuration templating, not for Table parsing. Option E is wrong because a View is only a schema/mapping definition and still requires a Device object (or an equivalent connection) to fetch data from the device.

Answer

Tables can only be used to modify device configurations, not read operational state.

Answer

Tables require Jinja2 templates to parse raw XML output.

Answer

Views replace the need to instantiate a Device object.

Question 6

Which THREE exceptions can be raised by PyEZ during script execution when interacting with a Junos device? (Choose three)

Accepted Answer

RpcError. PyEZ raises RpcError (option A) when an RPC sent to the Junos device returns an error response, such as a failed <rpc-error> element from the NETCONF/RPC layer. ConfigError (option C) is raised when a configuration load, commit, or related config operation fails on the device. ConnectError (option D) is raised when PyEZ cannot establish or maintain the connection to the Junos device, for example due to authentication or transport failures. DatabaseLockedError (option B) and TemplateRenderError (option E) are not PyEZ exceptions: DatabaseLockedError is not a standard PyEZ exception class, and TemplateRenderError belongs to Jinja2 templating, not PyEZ's exception hierarchy.

Answer

DatabaseLockedError

Answer

TemplateRenderError

Question 7

Which THREE advanced features or methods are available on a PyEZ Device instance for session management and inspection? (Choose three)

Accepted Answer

dev.timeout property to get or set NETCONF RPC timeout values. Option A is correct because a PyEZ Device object exposes a timeout property that lets you get or set the NETCONF RPC timeout value used for requests. Option B is correct because the connected property returns a boolean indicating whether the NETCONF session to the device is currently active. Option C is correct because the capabilities attribute returns the list of NETCONF server capability URIs advertised by the device, useful for feature inspection. Option D is not a real PyEZ Device method; refreshing facts is done via facts_refresh(), not reload_session(). Option E is not a valid PyEZ Device attribute; commit timeouts are handled through configuration/commit options rather than a commit_timeout property.

Answer

dev.reload_session() for refreshing device facts

Answer

dev.commit_timeout for software installation timing

Question 8

Which TWO benefits are gained by using Python virtual environments when developing PyEZ and Jinja2 automation scripts? (Choose two)

Accepted Answer

They allow installing specific versions of PyEZ, lxml, and Jinja2 independently of system Python.. Option B is correct because a Python virtual environment creates an isolated site-packages directory with its own pip, so you can install pinned versions of PyEZ, lxml, and Jinja2 (e.g., pip install junos-eznc==2.6.3) without touching or conflicting with the system Python's packages. Option E is correct because that same isolation means each project's dependency set is self-contained, so upgrading a library for one automation project cannot break another project that depends on a different version. The unmarked options do not belong: virtual environments do not compile scripts into Junos binaries (A), do not replace SSH clients since PyEZ still uses NETCONF over SSH (C), and do not grant root-level CLI execution on routers (D).

Answer

They automatically compile Python scripts into binary executable files for Junos.

Answer

They remove the need to install SSH clients on the local machine.

Answer

They enable direct root-level execution of Junos CLI commands on physical routers.

Question 9

Which TWO tasks are typically automated using Python and PyEZ in a network DevOps pipeline? (Choose two)

Accepted Answer

Automated pushing of validated Jinja2-generated configurations to candidate databases. Option C is correct because PyEZ (junos-eznc) provides modules such as Config and the load() method with merge/override/replace actions that push Jinja2-rendered configuration text into the candidate database, then commit it — a core use case in network DevOps pipelines for templated, validated config deployment. Option D is correct because PyEZ exposes operational RPCs via the RPC class and facts/table retrieval (e.g., get_interface_information, get_route_information), enabling scripts to run pre-checks before a change and post-checks after a maintenance window to verify state and automatically roll back on failure. Option A is not correct because PyEZ operates at the Junos management/RPC layer over NETCONF or the Junos XML API, not at Layer 1 physical media, where packet capture requires tools like tcpdump or dedicated analyzers. Option B is not correct because firmware assembly is a low-level hardware/vendor engineering task, not something PyEZ automates. Option E is not correct because compiling Junos kernel device drivers in C++ is part of Juniper's internal OS build process, not a PyEZ automation task.

Answer

Direct packet capture inspection at Layer 1 physical media levels

Answer

Writing device firmware assembly code

Answer

Compiling Junos kernel device drivers in C++

Question 10

Which TWO commands or tools are associated with running JSNAPy snapshot verifications from a CLI environment? (Choose two)

Accepted Answer

jsnapy --snap. Option B, `jsnapy --snap`, is correct because JSNAPy's snapshot mode is invoked with the `--snap` flag, which collects the current device state defined in the test file and stores it as a snapshot for later comparison. Option E, `jsnapy --check`, is correct because the `--check` flag runs the verification step, comparing a previously taken snapshot against the current device state to validate that operational values match expectations. Together these two commands form the standard JSNAPy CLI workflow of taking a baseline snapshot and then checking against it. The remaining options do not belong: `pyez-snap --run` (A) is not a real JSNAPy command, `junos-snapshot --verify` (C) is not a JSNAPy CLI tool, and `juniper-snapshot-admin --test` (D) is a fabricated command name not associated with JSNAPy.

Answer

pyez-snap --run

Answer

junos-snapshot --verify

Answer

juniper-snapshot-admin --test

Question 11

When developing Python scripts that utilize PyEZ and Jinja2, which THREE best practices ensure robust and maintainable automation code? (Choose three)

Accepted Answer

Using the PyEZ Config context manager to ensure locks are released and rollbacks occur on error. Option A is correct because the PyEZ Config context manager (with Config(dev) as cu:) automatically acquires the configuration lock, and on an exception it discards the candidate configuration and releases the lock, preventing stale locks and partial commits. Option C is correct because catching specific PyEZ exceptions such as ConnectError, ConfigError, LockError, and CommitError lets scripts handle connection and configuration failures precisely rather than masking all errors with a bare except. Option E is correct because keeping Jinja2 templates in separate .j2 files (loaded via Environment with FileSystemLoader) separates presentation from logic, improving readability, reuse, and maintainability. Option B is wrong because hardcoding administrative passwords in template files exposes credentials and violates secure secret-handling practices. Option D is wrong because omitting device.close() leaks NETCONF/SSH sessions and consumes device and client resources; sessions should be closed when work is complete.

Answer

Hardcoding administrative passwords inside template files for easy rendering

Answer

Avoiding device.close() calls to keep network sessions open permanently

Question 12

An automation engineer is writing a Python script using Juniper PyEZ to connect to a Junos device. Which context manager approach is best practice to ensure the Device session is properly closed even if an exception occurs?

Accepted Answer

with Device(host="192.168.1.1", user="admin", passwd="secret") as dev:. Using the context manager 'with Device(...) as dev:' is best practice because it ensures the NETCONF session is automatically closed when the block exits, even if an exception occurs. The Device class implements the context manager protocol (__enter__ and __exit__), which calls open() on entry and close() on exit. This prevents session leaks and is the recommended pattern in Juniper's PyEZ documentation.

Answer

dev = Device(host="192.168.1.1"); dev.start_session()

Answer

dev = Device(host="192.168.1.1"); dev.open(autoclose=True)

Answer

dev = Device(host="192.168.1.1").connect()

Question 13

When modifying a Junos device configuration using the PyEZ Config table-driven or Context manager (with Config(dev) as cu:), what is the default behavior regarding locking the candidate configuration?

Accepted Answer

It automatically locks the candidate configuration upon entry and unlocks it upon exit.. When entering the Config context manager in PyEZ, it automatically locks the candidate configuration database to prevent concurrent edits and unlocks it upon exiting the context.

Answer

It locks the global database and forces all other users into maintenance mode.

Answer

It requires an explicit cu.lock() call before any load operation can take place.

Answer

It locks the running configuration and restarts the mgd daemon.

Question 14

You are writing a script that uses Jinja2 to dynamically render a Junos interface configuration. Which Python module and function are required to load a template from the local filesystem and render it with a dictionary of variables?

Accepted Answer

from jinja2 import Environment, FileSystemLoader. The standard Jinja2 API for loading templates from disk is to create an Environment with a FileSystemLoader pointed at the template directory, then call get_template() and render() with a variable dictionary. This is the canonical Python Jinja2 pattern and works directly with Junos config templates. PyEZ does not provide its own Jinja2 wrapper module for this purpose.

Answer

from jnpr.junos.cfg import ConfigTemplate

Answer

from jnpr.junos.template import TemplateRenderer

Answer

import jnpr.junos.utils.jinja as jinja

Question 15

An automation script needs to compare pre- and post-change states on a Junos device using JSNAPy (Junos Snapshot Administrator). Which configuration file format is used by JSNAPy to define snapshot checks and test assertions?

Accepted Answer

YAML. JSNAPy uses YAML files to define snapshots and test assertions. Snapshot files (for example, `snapshot.yaml`) list the commands or RPCs to capture, and test files (for example, `test.yaml`) define assertions using operators like `is-equal`, `is-greater-than`, and `contains`. YAML's human-readable structure makes it the standard format for JSNAPy configuration.

Answer

XML

Answer

JSON

Answer

INI