Python And PyEZ practice questions

with Config(dev) as cu:

Using `with Config(dev) as cu:` invokes the PyEZ Config context manager, which wraps the candidate configuration in a transaction. If an exception propagates out of the block, the context manager automatically calls `rollback()`, discarding uncommitted changes and satisfying the stem's requirement for automatic rollback on failure.

except ConnectError:

Catching `ConnectError` directly satisfies the stem's requirement to handle unreachable-device timeouts, since PyEZ raises this exception when the NETCONF session cannot be established within the configured timeout. It is the specific exception class for connection failures, unlike broader handlers that would mask unrelated errors.

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

The {% for ... %} ... {% endfor %} block is Jinja2's iteration construct, so it loops over vlan_list and renders the body once per VLAN. This satisfies the requirement to iterate over a list within a template, unlike expression or comment delimiters.

command: or rpc:

The command: and rpc: sections hold the operational checks JSNAPy runs against the device. Each entry names a CLI command or RPC to execute, and the returned output is compared against the expected values defined elsewhere in the test file.

Using PyEZ Table and View abstractions

PyEZ Table and View abstractions parse Junos XML RPC replies into structured Python objects, effectively yielding dictionary-like access to fields such as interface status. This satisfies the stem's requirement to convert XML output directly into a Python dictionary.

rpc:

In a PyEZ Table and View YAML definition, the rpc: parameter names the RPC or CLI command executed to gather raw data before the View maps fields. It directly satisfies the requirement specifying which parameter defines the data-gathering command.

action='replace'

Passing action='replace' to the load method overwrites the specified hierarchy level entirely instead of merging into it. This satisfies the scenario's requirement to replace the whole protocols bgp hierarchy, removing existing statements that are absent from the loaded configuration.

ncclient

PyEZ relies on ncclient to handle SSH transport and NETCONF message framing, satisfying the question's requirement for the underlying library managing secure connections. ncclient implements NETCONF over SSH (RFC 6242), providing the session layer PyEZ builds upon for Junos device automation.

Using parser generators or iterator arguments supported by specific RPC wrappers

Iterator arguments let the RPC stream results incrementally, so PyEZ processes one item at a time instead of materialising the entire routing table in memory. This directly satisfies the stem's constraint of avoiding local memory exhaustion when handling massive datasets. Parser generators complement this by transforming each streamed response on the fly.

from jnpr.junos.exception import ConfigError

ConfigError is raised by PyEZ when Junos reports configuration parsing or load failures, so importing it from jnpr.junos.exception lets the script catch those specific errors. This directly satisfies the stem's requirement to handle exceptions tied to configuration parsing failures.

cu.validate()

cu.validate() checks the loaded candidate configuration against the device's syntax and commit rules, returning errors before any commit occurs. This satisfies the requirement to verify configuration correctness through the PyEZ Config context manager without altering the active configuration.

cu.load(path='config.conf', format='text')

cu.load() accepts a path and format argument, letting you push a local configuration file in text, set, XML or JSON format into the candidate configuration. This satisfies the requirement to load configuration data via the PyEZ Config utility before committing.

cu.rollback()

The `rollback()` method reverts the candidate configuration to a previously committed state, satisfying the stem's requirement for actions available through the Config utility. It accepts an optional rollback index, letting you restore any of the last 50 commits, which is essential for recovering from failed configuration loads during automation.

{% for vlan in vlans %} ... {% endfor %}

Jinja2's {% for %} ... {% endfor %} block is a valid control-flow construct, iterating over the vlans sequence and rendering its body per item. This makes it usable in Junos configuration templates for generating repeated stanzas such as VLAN definitions.

{% if ospf_enabled %} ... {% endif %}

Jinja2's {% if %} ... {% endif %} block is valid control flow, conditionally rendering its body when ospf_enabled evaluates truthy. This suits Junos templates where OSPF configuration should appear only when the variable is set.

{{ interface_list | map(attribute='name') | list }}

The {{ ... }} expression delimiter is valid Jinja2 syntax, and the map filter with attribute='name' extracts each object's name, with list converting the generator to a list. This satisfies the requirement for a valid filtering construct in Junos templates.

sw.install(remote_path='/var/tmp/image.tgz')

The PyEZ SW utility's install() method accepts a remote_path argument pointing to the software image already staged on the device, satisfying the requirement for a valid method or attribute. This lets you install an image from local device storage without uploading it again.

sw.upgrade(package='junos-install-srx-x86-64-20.4R1.3.tgz', reboot=True)

The PyEZ SW utility's upgrade() method accepts package and reboot arguments, satisfying the requirement for a valid method or attribute. It uploads the specified Junos image and reboots the device afterwards, combining transfer and activation in one call.

command: or rpc: specifying the operational commands to run

JSNAPy snapshot and check files must declare the operational data to collect, so the command: or rpc: section is essential; without it JSNAPy has no source data to capture or compare against the stored baseline.

dev: or device: specifying target device connection details

The `dev:` (or `device:`) section supplies the connection parameters JSNAPy needs to reach the target Junos device, including host, user and authentication method. Without it, JSNAPy cannot establish the NETCONF session required to gather or compare state, so this section satisfies the stem's requirement for a device-connection component.

action: defining test parameters or actions like snap or check

The `action` key specifies whether JSNAPy performs a snapshot or a check, directly satisfying the requirement for a section defining test parameters. Without it, JSNAPy cannot determine the operation mode, so the file fails validation. This makes `action` one of the three required components alongside the test and command sections.

cu.load(text='set system hostname router1', format='set')

Config.load accepts a text argument containing configuration data plus a format argument specifying its syntax, so passing set-format commands with format='set' loads them correctly. This satisfies loading configuration from an inline string source rather than a file.

cu.load(path='/path/to/config.xml', format='xml')

Loading from a local file path satisfies the requirement to source configuration data from disk. The `format='xml'` argument tells the Config utility to parse the file as Junos XML, which is the native encoding PyEZ expects for structured configuration. This lets you push an offline XML file without a live device connection.

Using etree.tostring(response, encoding='unicode') to view raw XML text

Correct. Converting the XML element to string helps inspect raw output.

Using lxml.etree methods directly on the returned element object

Correct. Since PyEZ returns lxml elements, lxml parsing methods apply.

Using XPath expressions to search specific nodes within the response element

Correct. XPath queries are fully supported on lxml elements.

dev.rpc.get_system_information()

The PyEZ `dev.rpc` object exposes each Junos RPC as a method, and `get_system_information` maps directly to the `show system information` command, returning structured XML. This satisfies the stem's requirement to retrieve operational data via an RPC call equivalent to that CLI command, without needing raw CLI execution.

It merges configuration changes with the existing candidate configuration, modifying or adding specified nodes while preserving unreferenced nodes.

The update action performs a merge-style load: specified nodes are added or modified while unreferenced configuration is preserved. This differs from override, which replaces the entire candidate hierarchy, and from a plain merge only in its handling of existing statements.

cu.rollback(id=1)

`cu.rollback(id=1)` invokes the PyEZ Config utility's rollback method, loading a previously committed candidate configuration by its rollback identifier. Passing `id=1` restores the most recent prior commit, directly satisfying the stem's requirement for a valid rollback operation via the Config utility.

cu.commit(comment="Automated deployment", timeout=30)

cu.commit(comment=..., timeout=...) commits the candidate configuration with an audit comment and a bounded wait for completion. This satisfies the question's requirement for a valid commit method, and the timeout parameter handles slow commits or errors.

`dev.load(merge=True)` followed by `dev.commit_check()`

This sequence loads the configuration with a merge action and then explicitly runs a commit check to validate the syntax. `commit_check()` sends a commit check RPC to the device, returning any errors without committing. This approach ensures the configuration is syntactically correct before the actual commit, reducing the risk of a failed commit.