JNCIA-DevOps Python And PyEZ — Timed 40 Questions

Question 1

When managing configuration changes via PyEZ Config utility, which context manager ensures that changes are automatically rolled back if an exception occurs within the block?

Accepted Answer

with Config(dev) as cu:. The PyEZ Config utility provides a context manager that automatically handles locking, loading, committing, and rolling back changes if an exception occurs. The syntax 'with Config(dev) as cu:' opens a configuration session that, upon exiting the block, commits changes if no exception occurred, or rolls back if an exception was raised. This built-in behavior ensures atomic configuration changes.

Answer

with Config(dev, mode='private') as cu:

Answer

try: cu.lock() except: cu.rollback()

Answer

cu.commit(rollback_on_error=True)

Question 2

When writing a Python script using PyEZ, how should you handle connection timeout exceptions when attempting to connect to an unreachable Junos device?

Accepted Answer

except ConnectError:. PyEZ raises ConnectError when it fails to establish a NETCONF session with the target device.

Answer

except NetconfConnectionError:

Answer

except DeviceOpenError:

Answer

except socket.timeout:

Question 3

You are rendering a Jinja2 template in Python that includes a loop over a list of VLANs. Which Jinja2 block syntax correctly iterates over a list named 'vlan_list'?

Accepted Answer

{% for vlan in vlan_list %} ... {% endfor %}. Jinja2 uses `{% %}` delimiters for control-flow statements such as `for`, `if`, and `set`, and requires an explicit `{% endfor %}` to close the loop. The `{{ }}` syntax is reserved for expression output (printing values), so it cannot open a loop. Option C is the only choice that uses the correct statement delimiters and matching end tag.

Answer

{{ for vlan in vlan_list }} ... {{ endfor }}

Answer

[for vlan in vlan_list] ... [endfor]

Answer

<% for vlan in vlan_list %> ... <% endif %>

Question 4

When configuring a JSNAPy test file, which section defines the specific RPCs or CLI commands that should be executed to gather operational data?

Accepted Answer

command: or rpc:. In a JSNAPy test file, the 'command:' or 'rpc:' section defines the specific CLI commands or RPCs to execute on the device to gather operational data. This section is part of the test definition and tells JSNAPy what data to collect for snapshotting and comparison.

Answer

action:

Answer

device_credentials:

Answer

template:

Question 5

You need to write a Python script that extracts interface status from a Junos device using PyEZ and converts the XML output directly into a Python dictionary. Which utility or function can assist with this conversion?

Accepted Answer

Using PyEZ Table and View abstractions. PyEZ Table and View abstractions are designed to parse XML output from Junos devices into structured Python objects, including dictionaries. You define a View that maps XML elements to Python attributes, and a Table that uses the View to return a list of dictionaries. This is the idiomatic way to convert XML to Python data structures in PyEZ.

Answer

dev.rpc.convert_to_dict()

Answer

json.loads(dev.rpc.get_interface_information())

Answer

etree.to_dict()

Question 6

When designing a custom PyEZ Table and View mapping in Python, what configuration parameter in the YAML definition file specifies the RPC or CLI command executed to gather the raw data?

Accepted Answer

rpc:. In a PyEZ Table/View YAML definition, the rpc: key specifies the Junos RPC (or CLI command) that the Table uses to retrieve raw data from the device. When the Table's get() method is called, PyEZ executes the RPC named under rpc: and passes the response to the View for parsing.

Answer

get-rpc:

Answer

exec:

Answer

command_string:

Question 7

You are writing a script that uses PyEZ to load a Junos configuration file, but you want to replace an entire hierarchy level (e.g., protocols bgp) rather than merging the changes. Which parameter should you pass to the load method?

Accepted Answer

action='replace'. The action='replace' parameter tells PyEZ to replace the specified hierarchy level in the candidate configuration.

Answer

overwrite=True

Answer

merge=False

Answer

mode='override'

Question 8

Which Python library does PyEZ depend on under the hood for managing secure SSH connections and NETCONF framing?

Accepted Answer

ncclient. PyEZ depends on ncclient under the hood for managing secure SSH connections and NETCONF framing. ncclient is a Python library that implements the NETCONF protocol and handles SSH transport, XML framing, and RPC execution. PyEZ wraps ncclient to provide a higher-level API for Junos devices.

Answer

paramiko

Answer

fabric

Answer

netmiko

Question 9

When executing a PyEZ RPC call that returns a large dataset (e.g., massive routing table), how can you handle the output efficiently without exhausting local memory?

Accepted Answer

Using parser generators or iterator arguments supported by specific RPC wrappers. Using generators or streaming options in RPC handling prevents loading massive XML trees entirely into memory.

Answer

etree.iterparse() directly on the raw socket stream

Answer

dev.rpc.get_route_information(normalize=True)

Answer

dev.stream_rpc()

Question 10

You are building a custom PyEZ application and need to catch exceptions specific to configuration parsing failures returned by Junos. Which exception class should your script import?

Accepted Answer

from jnpr.junos.exception import ConfigError. The jnpr.junos.exception module is the canonical location for all PyEZ exception classes, and ConfigError is the specific exception raised when Junos returns a configuration parsing or load failure (for example, a syntax error detected by the CLI/commit check). Importing it from jnpr.junos.exception allows the script to catch configuration-related failures distinctly from connection or RPC errors. This is the documented pattern in Juniper's PyEZ library for handling config load errors.

Answer

from jnpr.junos.device import ConfigurationFailed

Answer

from jnpr.junos.utils.config import ConfigError

Answer

from jnpr.junos.exception import ParseError

Question 11

When working with the PyEZ Config utility, which THREE actions can be performed using the configuration context manager or its methods? (Choose three)

Accepted Answer

cu.validate(). Option B, cu.validate(), is correct because the PyEZ Config utility exposes a validate() method that checks the candidate configuration for syntax and commit-check errors before it is committed. Option C, cu.load(path='config.conf', format='text'), is correct because load() is the core method for loading configuration data into the candidate configuration, and it accepts parameters such as path and format (text, set, xml, or json). Option D, cu.rollback(), is correct because the Config utility provides rollback() to revert the candidate configuration to a previously committed configuration (for example, rollback(1) restores the last committed config). Option A, cu.gather_facts(), is not part of the Config utility; fact gathering is performed by the Device object (dev.facts or facts gathering via the Facts/Device classes). Option E, cu.upgrade_os(), is not a Config method; OS upgrades are handled by separate PyEZ utilities such as the SW package management classes, not the configuration context manager.

Answer

cu.gather_facts()

Answer

cu.upgrade_os()

Question 12

When writing Jinja2 templates for Junos configurations, which THREE control flow or filtering constructs are valid? (Choose three)

Accepted Answer

{% for vlan in vlans %} ... {% endfor %}. Option C is correct because Jinja2 uses the {% for vlan in vlans %} ... {% endfor %} block syntax for iteration, which is the standard way to loop over a list such as VLANs when generating Junos configuration stanzas. Option D is correct because {% if ospf_enabled %} ... {% endif %} is the valid Jinja2 conditional block, allowing conditional inclusion of OSPF configuration based on a variable's truthiness. Option E is correct because {{ interface_list | map(attribute='name') | list }} uses Jinja2's expression delimiters {{ }} with valid filters: map(attribute='name') extracts the 'name' attribute from each item and list converts the generator into a list, a common pattern for building interface name lists. Option A is incorrect because [# ... #] is not Jinja2 delimiter syntax; Jinja2 uses {% %} for statements, and there is no 'foreach' keyword (the keyword is 'for'). Option B is incorrect because << ... >> is not Jinja2 delimiter syntax; conditionals must use {% if ... %} ... {% endif %} rather than angle-bracket tags.

Answer

[# foreach item in list #] ... [# endfor #]

Answer

<< if interface_active >> ... << endif >>

Question 13

Which TWO methods or attributes are valid when using the PyEZ SW utility to manage Junos software? (Choose two)

Accepted Answer

sw.install(remote_path='/var/tmp/image.tgz'). Option A is correct because the PyEZ SW utility's install() method accepts a remote_path argument pointing to the software image location on the device (e.g., /var/tmp/image.tgz), which is the standard way to install a Junos package already staged on the target device. Option B is correct because SW.upgrade() is a valid PyEZ method that takes a package parameter (the image filename) and a reboot flag to control whether the device reboots after the upgrade completes. Option C is not a valid PyEZ SW method; rollback is performed via the CLI (request system software rollback) or other RPCs, not sw.rollback_software(). Option D is not part of the SW utility; get_os_facts() is not a PyEZ SW method (OS facts are gathered through other means such as the Facts class). Option E is not a valid PyEZ SW method; commit_os() does not exist in the SW utility API.

Answer

sw.rollback_software()

Answer

sw.get_os_facts()

Answer

sw.commit_os()

Question 14

When configuring JSNAPy, which THREE components or sections are typically required within a YAML check/snapshot file? (Choose three)

Accepted Answer

command: or rpc: specifying the operational commands to run. Option A is correct because a JSNAPy snapshot/check YAML file must include a command: or rpc: key that lists the operational CLI commands or NETCONF RPCs to execute on the device. Option B is correct because the file requires a dev: or device: section that specifies the target device connection details (host, user, password, port, and connection method) used to reach the Junos device. Option E is correct because the action: key defines the test parameters and the operation mode, such as snap for capturing a snapshot or check for comparing against a reference snapshot. Option C is not required because jinja_template is not a mandatory JSNAPy section for defining checks or snapshots. Option D is not required because candidate_database and NETCONF lock parameters are not part of the standard required JSNAPy YAML structure.

Answer

jinja_template: defining external configuration templates

Answer

candidate_database: defining NETCONF lock parameters

Question 15

Which TWO methods are valid for loading configuration data into the PyEZ Config utility from different sources? (Choose two)

Accepted Answer

cu.load(text='set system hostname router1', format='set'). Option A is correct because the PyEZ Config utility's load() method accepts a 'text' parameter containing configuration data in a specified format, and passing format='set' with a set-style command such as 'set system hostname router1' is a valid way to load configuration from an inline string. Option E is correct because load() also accepts a 'path' parameter pointing to a configuration file on disk, and specifying format='xml' correctly indicates that the file contains XML-format configuration data. Option B is incorrect because loading a Jinja2 template is done through the Template class (or template-related parameters), not by passing template_file and engine to Config.load(). Option C is incorrect because 'database' is not a valid load() parameter for selecting a configuration source; the Config utility loads data from strings, files, or templates, not by naming a database. Option D is incorrect because 'action' is not a load() parameter; committing changes is performed with the commit() method (or commit_check()), not by passing action='commit' to load().

Answer

cu.load(template_file='config.j2', engine='jinja2')

Answer

cu.load(database='active')

Answer

cu.load(action='commit')

Question 16

When executing raw XML RPCs via PyEZ, which THREE approaches or parameters can be used to handle or inspect the response XML? (Choose two) -> Wait, let's make it THREE since the prompt requires HALF of multi-select to be 'Which THREE'. Let's verify prompt: 'HALF use 'Which TWO', HALF use 'Which THREE'.' Total multi-select = 6. 3 use TWO, 3 use THREE. Let's make this one THREE. Which THREE approaches...

Accepted Answer

Using etree.tostring(response, encoding='unicode') to view raw XML text. RPC responses can be converted, queried with XPath, or printed as strings.

Answer

Using dev.rpc.to_dict() to automatically serialize all RPC outputs

Answer

Using json.loads() directly on the RPC response object

Question 17

You need to retrieve operational data from a Junos device using a PyEZ RPC call that equates to the CLI command 'show system information'. Which Python statement correctly invokes this RPC?

Accepted Answer

dev.rpc.get_system_information(). In PyEZ, CLI commands can be translated to RPC methods by converting dashes to underscores. 'show system information' becomes dev.rpc.get_system_information().

Answer

dev.execute("show system information")

Answer

dev.get_config(cli="show system information")

Answer

dev.rpc.show_system_information()

Question 18

When loading configuration changes via PyEZ using cu.load(format='xml', action='update'), what is the precise impact of the 'update' action compared to 'merge' or 'override'?

Accepted Answer

It merges configuration changes with the existing candidate configuration, modifying or adding specified nodes while preserving unreferenced nodes.. The 'update' action merges configuration elements based on matching keys or identifiers, allowing precise modification of existing hierarchical statements without replacing entire blocks.

Answer

It overwrites the entire candidate configuration, discarding all prior uncommitted changes.

Answer

It completely replaces the running configuration with the provided payload.

Answer

It deletes the matching hierarchy nodes entirely before inserting new ones.

Question 19

Which TWO of the following methods or attributes are valid ways to handle rollback operations or commit errors when using the PyEZ Config utility (cu)?

Accepted Answer

cu.rollback(id=1). Option B, cu.rollback(id=1), is correct because the PyEZ Config utility exposes a rollback() method that accepts an id parameter to load a previously committed configuration (rollback 1 is the last committed config) and restore it, which is the standard way to undo a bad change. Option D, cu.commit(comment="Automated deployment", timeout=30), is correct because commit() is the method that applies the candidate configuration, and it accepts a comment for the commit log and a timeout value to control how long to wait for the commit to complete, which is how you handle commit errors and ensure the operation finishes. Option A, cu.force_commit(), is not a valid PyEZ Config method; there is no such API. Option C, cu.undo(), does not exist in the PyEZ Config utility. Option E, cu.revert(rollback=0), is not a valid method signature; rollback is performed via cu.rollback(id=...) and rollback 0 is the current candidate, not a committed rollback point.

Answer

cu.force_commit()

Answer

cu.undo()

Answer

cu.revert(rollback=0)

Question 20

You are developing a PyEZ script that loads a configuration from a Jinja2 template and commits it. The template uses variables that must be provided. Which PyEZ method should you use to load the rendered configuration while also performing a syntax check before commit?

Accepted Answer

`dev.load(merge=True)` followed by `dev.commit_check()`. To load a configuration and perform a syntax check, you must call `load()` and then `commit_check()`. The `load()` method alone does not validate syntax. Using `commit_check()` after loading ensures errors are caught before committing, which is a best practice in automation.

Answer

`dev.load(overwrite=True)`

Answer

`dev.load()`

Answer

`dev.load(merge=True)`