Hard Difficulty Questions

The script is exceeding the maximum number of concurrent REST API sessions, causing new requests to be rejected with 401.

Why it fails: Exceeding session limits typically results in HTTP 503 Service Unavailable or 429 Too Many Requests, not 401 Unauthorized. A 401 indicates an authentication failure, not a resource exhaustion issue. The maximum session limit is controlled by the 'max-connections' setting under the REST API configuration.

The device's clock is out of sync with the authentication server, causing token-based authentication to fail.

Why it fails: HTTP Basic Authentication does not use tokens or time-based credentials, so clock skew would not cause 401 errors. Clock synchronization is critical for token-based systems like OAuth or Kerberos, but not for Basic Auth. The intermittent nature points to an external authentication dependency.

The REST API requires the use of a session cookie instead of Basic Authentication for operational requests.

Why it fails: The Junos REST API supports HTTP Basic Authentication for both operational and configuration requests. Session cookies are not required. While the API may return a session cookie after login, Basic Auth is sufficient and standard. Intermittent 401 errors are not caused by the absence of a cookie.

They are converted to floating-point numbers.

Why it fails: json.loads() preserves JSON object keys as Python strings, so the integer 443 becomes the string '443', not a float. The option is tempting because JSON numbers are parsed as Python int or float, but that rule applies to values, not to keys, which the JSON specification requires to be strings.

They remain integer objects.

Why it fails: The JSON specification requires object keys to be strings, so json.loads() converts 443 to '443' rather than preserving an int. Integers appear only as values. The option tempts those who expect Python's dict to retain the literal numeric form shown in the payload, but the parser normalises keys to str.

The parser raises a KeyError because JSON keys must be alphabetic.

Why it fails: json.loads() accepts any valid JSON object key, converting it to a string; no KeyError is raised for numeric-looking keys. The error only occurs later if code looks up an integer key against the string-keyed dict. The option tempts anyone who assumes JSON enforces alphabetic key naming, which it does not.

`exception.detail`

Why it fails: PyEZ `CommitError` does not have a `detail` attribute. The detailed error information is stored in the `errs` attribute. Using `exception.detail` would raise an AttributeError, and you would not obtain the device's commit error messages, making troubleshooting difficult.

`exception.message`

Why it fails: The `message` attribute is not the standard way to retrieve detailed commit error text from a PyEZ `CommitError`. While some exceptions may have a `message` attribute, PyEZ's `CommitError` stores the error details in the `errs` attribute, which contains a list of error objects. Relying on `message` may yield incomplete or missing information.

`exception.response`

Why it fails: While some exceptions may have a `response` attribute, for PyEZ `CommitError` the standard way to access error details is through `errs`. The `response` attribute is not guaranteed to contain the parsed error messages and may hold the raw NETCONF response, which requires additional parsing to extract meaningful errors.

By appending numeric indexes to every key name automatically.

Why it fails: xmltodict converts repeated sibling elements into a JSON list under that tag name, not into keys with numeric suffixes. It is tempting because indexes appear in some other converters, and that behaviour would be correct for tools that flatten repeated nodes into uniquely named keys.

By raising a DuplicateElementException.

Why it fails: No standard XML-to-JSON library raises a DuplicateElementException for repeated siblings; xmltodict instead groups them into a list under the shared tag. The exception idea appeals because duplicate keys feel like an error condition, yet JSON arrays exist precisely to hold repeated elements, so libraries use them rather than failing.

By overwriting previous elements so only the last element is retained.

Why it fails: xmltodict preserves repeated siblings by converting that tag's value into a list, so no data is lost. Overwriting would discard all but the final element, which the library does not do. This option is tempting because manual dictionary assignment in Python does overwrite duplicate keys, but that is a scripting behaviour, not XML-to-JSON library behaviour.

Support for numeric floating-point values

Why it fails: Both formats natively represent integers and floating-point numbers.

Support for boolean data types

Why it fails: Both JSON and YAML support boolean data types natively.

Support for nested arrays

Why it fails: Both formats natively support nesting arrays and lists.

set protocols rest-api https port 8443

Why it fails: Protocols is the wrong hierarchy; REST is a system service.

set system services rest port 8443 secure

Why it fails: This CLI path is incorrect for Junos REST configuration.

set system services netconf https-port 8443

Why it fails: This configures NETCONF parameters, not jpagent.

Send an HTTP GET request with ?action=reset.

Why it fails: The Junos REST API exposes no ?action=reset query parameter; GET retrieves configuration or operational state and cannot discard candidate changes. It is tempting because action-style query parameters appear elsewhere in REST APIs, and GET with such parameters would be correct for read-only RPCs, not configuration rollback.

Issue an HTTP DELETE request to the root /api/configuration path.

Why it fails: DELETE on the configuration root is not the Junos REST mechanism for discarding candidate changes; the API expects a dedicated RPC-style operation. It is tempting because DELETE conventionally removes resources in REST design, and would be correct in an API where the candidate configuration is modelled as a deletable resource.

Restart the routing engine process (RE switchover).

Why it fails: An RE switchover restarts the control plane and fails over to the backup Routing Engine; it does not discard uncommitted candidate configuration, and may itself lose those changes. It is tempting because RE switchover is a genuine high-availability operation, correct when the primary Routing Engine fails rather than when edits must be abandoned.

Transfer-Encoding: chunked

Why it fails: Transfer-Encoding: chunked governs how the response body is framed during transmission, not its serialisation format, so Junos still returns XML. It is tempting because chunked encoding is genuinely used for streaming large configuration payloads, but it would be the right header only when the response size is unknown in advance.

Content-Type: text/xml

Why it fails: Content-Type describes the media type of the request body being sent, so on a GET with no payload it cannot negotiate the response format; Junos returns XML by default. It is tempting because Content-Type is genuinely used on POST requests to tell Junos the format of configuration being submitted.

X-Junos-Data-Format: json

Why it fails: Junos REST API selects response serialisation through the Accept header, not a vendor-specific X-Junos-Data-Format header, which Junos ignores and answers in XML. It is tempting because Junos CLI and NETCONF do expose format-selection mechanisms, so a Junos-prefixed header looks plausible.

YAML automatically guarantees lossless round-trip conversion for all Python objects.

Why it fails: YAML preserves only its own tag set, so Python-specific objects such as tuples, sets and custom classes lose type fidelity on round-trip. It is tempting because simple scalars, lists and maps do survive, and that holds for typical Junos configuration trees, but not for arbitrary Python objects.

JSON files natively support YAML anchors and aliases.

Why it fails: Anchors and aliases are YAML-only constructs; JSON has no syntax for them, so any conversion flattens or duplicates the referenced nodes. It is tempting because JSON's object nesting superficially resembles YAML mapping structure, yet JSON offers no mechanism to express shared references or merge keys.

from jnpr.jsnapy.verify import VerifyEngine

Why it fails: The jnpr.jsnapy.verify module holds internal comparison helpers, not the VerifyEngine class named here. It is tempting because 'verify' matches the task wording, yet the class that runs snapshots and diffs programmatically is JSNAPy, imported from jnpr.jsnapy.

from jnpr.junos.utils.jsnapy import JSNAPy

Why it fails: Importing JSNAPy from `jnpr.junos.utils.jsnapy` targets the PyEZ utility wrapper, which shells out to the `jsnapy` CLI rather than exposing the snapshot-comparison engine as an instantiable Python class. It is tempting because PyEZ utilities do wrap JSNAPy for Junos device interaction, but programmatic snapshot comparison requires the `jnpr.jsnapy.SnapAdmin` class instead.

from jnpr.jsnapy.runner import JSNAPyRunner

Why it fails: No JSNAPyRunner class exists in jnpr.jsnapy.runner; that module exposes the CLI entry point, not an instantiable runner. Importing it is tempting because the name mirrors the jsnapy command, but programmatic comparison requires the JSNAPy class.

Hardcoding administrative passwords inside template files for easy rendering

Why it fails: Embedding credentials in Jinja2 templates exposes secrets in version control and rendered configs; credentials belong in vaults or environment variables. It tempts because inline variables render quickly, but secret management is a separate concern from template rendering.

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

Why it fails: Leaving sessions open leaks NETCONF connections and exhausts device session limits; scripts should close sessions with device.close() or context managers. It tempts as a performance shortcut to avoid reconnect overhead, but persistent sessions belong in long-running daemons, not short automation scripts.

import jnpr.junos.debug; jnpr.junos.debug.enable()

Why it fails: No module named jnpr.junos.debug exists in PyEZ, so this import raises ImportError and never enables NETCONF XML logging. It is tempting because a dedicated debug helper sounds plausible, and such a module would be the right approach if PyEZ shipped one for toggling wire-level tracing.

dev.rpc.trace(enabled=True)

Why it fails: PyEZ exposes NETCONF XML tracing through the device object's log utility, not an rpc.trace method, so this call raises an attribute error. It is tempting because dev.rpc is the correct object for invoking RPCs, but tracing is configured on the device handle's logging, not on rpc itself.

dev.debug = True

Why it fails: Setting dev.debug to True enables PyEZ's own debug logging, not the NETCONF XML wire trace the question requires; that trace comes from the ncclient logger. It is tempting because dev.debug sounds like full protocol debugging, and it is genuinely useful for diagnosing PyEZ library behaviour rather than raw XML.

Manual terminal emulation sessions using Telnet

Why it fails: Manual Telnet sessions provide no programmatic interface, structured data models or automation framework, so they cannot form part of a model-driven architecture. They remain relevant for out-of-band emergency access. Model-driven automation on Junos depends on NETCONF, REST APIs and YANG models rather than interactive terminal sessions.

Proprietary screen-scraping PERL scripts parsing raw CLI text

Why it fails: Screen-scraping PERL scripts parse raw CLI text, which is the opposite of model-driven automation; they lack structured YANG models, NETCONF or REST APIs. They remain useful for legacy devices without programmable interfaces. A model-driven architecture on Junos requires structured data models and API-based interaction, not text parsing.

Physical serial port multiplexers

Why it fails: Serial port multiplexers only provide physical console access to devices; they carry no data models, APIs or automation capability. They are useful for out-of-band management when network access fails. A model-driven architecture on Junos requires YANG-modelled interfaces such as NETCONF or REST, which multiplexers do not supply.

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.

There is no functional difference; REST API is simply an alias for NETCONF over port 830.

Why it fails: REST API and NETCONF are distinct interfaces: REST sends JSON or XML over HTTPS to URI endpoints, while NETCONF wraps XML in an <rpc> element over SSH on port 830. Treating REST as an alias tempts because both can invoke the same Junos RPCs.

NETCONF uses HTTP status codes for error reporting, while REST API uses standard syslog messages.

Why it fails: NETCONF returns errors inside the RPC reply payload, not as HTTP status codes, and neither protocol reports faults via syslog. The option tempts by borrowing HTTP semantics, which apply to the REST API's own transport rather than to NETCONF's XML reply.

REST API requires a persistent WebSocket connection that tunnels NETCONF XML streams.

Why it fails: REST API does not tunnel NETCONF XML over WebSockets; it sends RPCs as HTTP requests (GET/POST) to URI endpoints, with responses in JSON or XML. WebSocket tunnelling describes streaming telemetry, not request-response RPCs, which is why it tempts engineers familiar with push-based telemetry subscriptions.

JSON allows trailing commas in arrays and objects.

Why it fails: JSON does not allow trailing commas. A trailing comma before a closing bracket or brace will cause a parse error in strict JSON parsers. While some JSON5 or JavaScript parsers might tolerate them, standard JSON as used in Junos REST APIs does not. This statement is incorrect.

JSON natively supports multi-line strings without escaping newlines.

Why it fails: JSON does not support multi-line strings directly; newlines must be escaped as \n within a string. YAML, on the other hand, supports multi-line strings using literal (|) or folded (>) block scalars. This makes YAML more convenient for configuration snippets that span multiple lines. Therefore, this statement is incorrect.

JSON supports comments, which can be used to annotate configuration sections.

Why it fails: JSON does not support comments. Any attempt to include comments in a JSON file will result in a parse error. This is a common misconception because YAML supports comments. For configuration annotations, YAML is preferred, but JSON strictly disallows comments. Therefore, this statement is incorrect.

The parser raises a ScannerError because anchors are prohibited in safe mode.

Why it fails: yaml.safe_load() resolves anchors and aliases normally; it only blocks arbitrary Python object construction via tags such as !!python/object. ScannerError arises from malformed syntax, not anchors. The aliased nodes are expanded into full copies, so the script sees duplicated policy definitions with no anchor references remaining.

The aliases are ignored, resulting in empty values for those configuration blocks.

Why it fails: PyYAML resolves anchors and aliases during parsing, so aliased nodes are populated with the anchored mapping's content, not left empty. The option is tempting because anchors are a YAML authoring convenience that some assume safe_load strips for safety, but safe_load only blocks arbitrary Python object construction, not alias resolution.

The parser treats the anchor syntax as literal string data.

Why it fails: yaml.safe_load() resolves the anchor and alias into shared Python objects, so the ampersand and asterisk syntax never survives as string data. Treating them as literals is tempting if you assume safe_load disables all YAML features, but it only restricts object construction tags, leaving anchors, aliases and merge keys intact.

dev.get_config(format='xml')

Why it fails: get_config() retrieves the device's configuration hierarchy, not operational state, so it never invokes get-interface-information. It tempts engineers because it is a genuine PyEZ RPC-style method returning structured XML, making it the right choice when auditing or backing up committed configuration rather than reading interface counters.

dev.load(action='set', format='xml')

Why it fails: load() pushes configuration changes onto the device, so it cannot invoke an operational RPC or return interface statistics. It tempts engineers because it is the standard PyEZ method for loading set-format configuration snippets during automated provisioning, but retrieval requires an RPC-executing method such as dev.rpc.get_interface_information().

dev.execute_cli('show interfaces')

Why it fails: execute_cli returns raw CLI text, contradicting the requirement for structured XML from an RPC. The correct method invokes the RPC and returns parsed XML. execute_cli is appropriate when no RPC exists for the desired command or when replicating exact CLI output is genuinely required.

YAML anchors and aliases will be automatically preserved as native references in the resulting JSON output.

Why it fails: PyYAML resolves anchors and aliases during parsing, producing shared Python object references; json.dump then serialises each occurrence as a full duplicate, since JSON has no anchor or alias syntax. It is tempting because anchors do reduce YAML file size, and would be correct if the target format also supported reference syntax.

JSON supports multi-document streams natively in a single file just like YAML.

Why it fails: JSON has no multi-document stream syntax; json.load parses exactly one value, so a YAML file containing several documents separated by --- must be split and converted individually. It is tempting because YAML's --- separators look like ordinary delimiters, and multi-document YAML would be correct input for yaml.safe_load_all.

Views must be defined in a separate YAML file and cannot be coded in Python.

Why it fails: Views can be defined in Python as classes, or in YAML files for use with `Table` and `View` factories. They are not restricted to YAML. Many examples define Views directly in Python for simplicity. The statement that they must be in a separate YAML file is incorrect.

Tables automatically convert all XML responses into JSON format.

Why it fails: Tables do not automatically convert XML to JSON. They use Views to extract specific fields into Python dictionaries. While the resulting data can be serialized to JSON, the conversion is not automatic and is not the primary function of Tables. The output is a list of dictionaries, not JSON strings.

Tables can only retrieve configuration data, not operational data.

Why it fails: Tables are designed to retrieve operational data by calling RPCs that return operational state, such as `get_interface_information`. They are not limited to configuration data. Configuration data is typically handled through `dev.rpc.get_config` or similar, but Tables are primarily used for operational data parsing.