Select Two (Multi-Select) Questions

Single quotes can be used interchangeably with double quotes for strings.

Why it fails: JSON strings must be delimited by double quotes; single quotes are not valid delimiters and cause a parse failure in Junos automation tooling. The temptation comes from JavaScript, Python and YAML, where single quotes are accepted, but RFC 8259 permits only double quotes around strings and object keys.

JSON supports inline comments starting with the '#' symbol.

Why it fails: JSON defines no comment syntax at all, so a '#' character begins an invalid token and breaks parsing. Engineers accustomed to Junos configuration, shell scripts or Python reach for '#' comments, but JSON's specification omits comments entirely; only formats such as YAML or JSON5 support them.

Trailing commas are permitted in both arrays and objects.

Why it fails: JSON's grammar forbids a comma after the final element of an array or object; parsers such as Junos's reject it as a syntax error. Trailing commas are a convenience of JavaScript object literals and some YAML or Python structures, so they tempt engineers who write those formats daily, but they are invalid JSON.

Always reboot the Routing Engine after every GET request.

Why it fails: Rebooting the Routing Engine after each GET tears down the session and interrupts the very configuration workflow being automated, causing outages and lost state. It is tempting as a blunt way to guarantee a clean commit, but that is achieved with 'commit confirmed' or rollback, not a restart.

Send raw VT100 terminal escape sequences inside the HTTP body.

Why it fails: The Junos REST API exchanges structured XML or JSON over HTTPS; VT100 escape sequences are terminal control codes and are meaningless in an HTTP body, so requests fail to parse. It is tempting when porting expect-style CLI scripts, but REST automation should send proper XML/JSON payloads instead.

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.

application/yaml

Why it fails: application/yaml is not a media type Junos REST supports in the Accept header; the platform negotiates JSON and XML only. It is tempting because YAML is a common human-readable serialisation format used in automation tooling, and would be correct against APIs that explicitly advertise YAML support.

text/csv

Why it fails: text/csv is a tabular text format, not one of the serialisation formats Junos REST negotiates via the Accept header. It is tempting because CSV is a legitimate MIME type for exporting tabular data, and would be correct when a system exposes CSV reports rather than JSON or XML API responses.

application/octet-stream

Why it fails: application/octet-stream denotes an opaque binary stream, not a structured serialisation format, so Junos REST cannot return parsed configuration through it. It is tempting because it is a valid MIME type for file downloads, and would be correct when transferring raw binary artefacts rather than requesting serialised data.

The REST API communicates directly over TCP port 830.

Why it fails: Port 830 carries NETCONF over SSH, not REST API traffic, which uses HTTPS on port 443. The confusion arises because both interfaces configure Junos devices, so candidates assume shared transport; port 830 would be the correct answer if the question asked which port NETCONF uses.

NETCONF requires explicit SSH key pairs for transport security, whereas REST API cannot use encryption.

Why it fails: Both interfaces support encryption: NETCONF over SSH and REST API over HTTPS with TLS. The option is tempting because NETCONF does rely on SSH transport, but claiming REST API cannot encrypt is false, as HTTPS provides transport security for REST requests.

NETCONF is stateless, whereas REST API maintains persistent interactive sessions by default.

Why it fails: The statement inverts the transports: NETCONF runs over a persistent SSH session, while Junos REST API requests are stateless HTTP calls. It is tempting because persistent sessions genuinely describe NETCONF, but attributing them to REST reverses the actual axis of difference between the two interfaces.

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.

yaml

Why it fails: yaml parses YAML documents, not the JSON payload a Junos REST API returns, so it cannot decode the response body. It is tempting because Junos configuration files are YAML-like, making yaml the right choice when parsing device configuration templates rather than REST responses.

socket

Why it fails: socket provides low-level TCP/IP primitives, leaving HTTP request framing, headers and TLS to be implemented manually, so it does not fetch web content as required. It is tempting because it underpins all network communication, making socket correct when writing a custom protocol client.

pickle

Why it fails: pickle deserialises Python object byte streams, so it cannot parse the JSON text a Junos REST API returns. It is tempting because it serialises and restores Python objects, making pickle correct when caching parsed data between script runs rather than handling web payloads.

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.

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.

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.

Manually crimping CAT6 Ethernet cables in the wiring closet

Why it fails: Physical cabling is a data-centre technician's task, not a DevOps engineer's; the role centres on automating Junos configuration via NETCONF, YANG and CI/CD pipelines. Crimping is tempting because network engineers historically handled cabling, but structured cabling is now a facilities responsibility.

Manually rebooting every switch in the data center daily

Why it fails: Daily manual reboots contradict DevOps automation principles; Junos engineers use Ansible, PyEZ or Junos automation scripts for lifecycle tasks. Rebooting is tempting because routine maintenance occasionally requires restarts, but scheduled reboots belong to change management, not continuous integration or configuration-as-code workflows.

Physical replacement of router power supply units

Why it fails: Swapping power supply units is physical hardware maintenance, not an automated test executed by a CI/CD pipeline against Junos configuration. Such work belongs to field operations; pipeline testing validates syntax, commits and rollback behaviour before production.

Manual approval of physical fiber patch cables by a security guard

Why it fails: Physical cabling is not an automated pipeline test.

.xml

Why it fails: .xml is the extension for XML documents, a markup language with angle-bracket tags, not YAML. It is tempting because both are structured data formats used in automation, but YAML files conventionally use .yaml or .yml, so .xml is invalid here.

.jsn

Why it fails: .jsn is not a recognised YAML file extension; YAML files use .yaml or .yml. It is tempting because it resembles .json, another structured data format, but YAML's own extensions are .yaml and .yml, so .jsn fails the question.

.txt

Why it fails: YAML files conventionally carry .yaml or .yml extensions; .txt denotes plain text and provides no schema or parser association. It is tempting because YAML is human-readable text, so editors open it fine, but that readability does not make .txt a recognised YAML extension.

The client uses the hello message to lock the configuration database before session initialization.

Why it fails: Locking occurs via the lock operation on a datastore after the session is established, not within the hello exchange. Hello messages only advertise capabilities and session IDs. Locking is correct when preventing concurrent configuration edits during a transaction, which happens after capability negotiation, not during it.

The client hello message must include the list of YANG modules it intends to modify during the session.

Why it fails: The hello message advertises supported NETCONF capabilities and YANG modules the peer can use, not the modules a client intends to modify; modification intent is expressed later in edit-config operations. Capability advertisement is correct when negotiating supported datastores and features at session start, not for declaring write targets.

The hello message exchange is optional if a pre-shared SSH key is used for authentication.

Why it fails: The hello exchange is mandatory for every NETCONF session regardless of authentication method, as it establishes capabilities and session IDs. SSH keys only authenticate the transport. Hello is correctly omitted only in non-NETCONF management protocols, not when SSH key authentication is used.

Completely bypassing automated testing to speed up deployments

Why it fails: Skipping automated testing removes the validation gate that catches syntax and policy errors before a Junos configuration reaches production devices. Best practice pairs Git commits with pipeline tests such as commit checks or Junos PyEZ validation. It is tempting when deployment speed matters, but bypassing tests suits only disposable lab topologies, never production.

Storing plaintext administrative passwords directly in public Git repositories

Why it fails: Plaintext credentials in a public repository expose administrative access to anyone, and Git history retains them permanently even after deletion. Secrets belong in a vault or encrypted store referenced by the configuration. It is tempting because committing a working config verbatim is quick, but that suits only throwaway lab repositories containing no real credentials.

git init

Why it fails: git init creates an empty repository and its .git directory, so it cannot combine commits from two branches. It is tempting as the first command in any new project, but branch integration within an existing repository is performed by git merge or git rebase.

git status

Why it fails: git status only reports working-tree and staging state; it modifies no branches and writes no commits. It is tempting because it reveals divergence between branches, but actually integrating those changes requires git merge or git rebase.

git clone

Why it fails: git clone creates a local copy of a remote repository, establishing a new working tree; it performs no branch-to-branch integration. It is tempting because it does move commits between repositories, but integrating changes within one repository requires git merge or git rebase.

max_depth

Why it fails: json.dumps() exposes no max_depth parameter; nesting depth is not configurable, and recursion limits come from Python itself. The name is tempting because depth sounds like a readability control alongside indent, and max_depth would be the right parameter if the goal were capping how deeply nested structures are serialised.

strict_mode

Why it fails: json.dumps() has no strict_mode parameter; strict is a boolean argument controlling whether control characters are permitted inside strings. The name is tempting because strict sounds like a formatting or validation toggle, and strict would be the correct parameter if the requirement were rejecting unescaped control characters rather than controlling readability.

The physical routing engine is immediately powered down to prevent hardware wear.

Why it fails: Locking the candidate or running configuration database grants exclusive edit access to the session; it never powers down hardware. It is tempting because lock operations do restrict concurrent access, which superficially resembles taking a device out of service during maintenance windows.

All operational state monitoring (such as 'show route') is permanently disabled.

Why it fails: Locking the configuration database blocks concurrent configuration edits only; operational commands such as 'show route' continue running unaffected. It is tempting because locking does exclude other sessions from the candidate configuration, which sounds like suspending device activity generally.

All firewall filters on all interfaces are automatically deleted.

Why it fails: A lock restricts other NETCONF sessions from modifying the configuration database; it does not delete firewall filters or any configuration objects. It is tempting because locks do prevent conflicting concurrent edits, so candidates confuse exclusion of writers with removal of existing configuration.

Adobe Photoshop

Why it fails: Adobe Photoshop edits raster images and has no version control or repository hosting capability for code. It would be the correct choice for creating diagrams or topology graphics for documentation, not for storing and versioning Junos automation scripts.

Microsoft Word

Why it fails: Microsoft Word is a document editor; it cannot track commits, branches or merges across a codebase. It would be the right choice for drafting a design document describing the automation, not for hosting the Junos automation repository itself.

VLC Media Player

Why it fails: VLC is a media player for audio and video playback, offering no repository hosting, commit history or branching. It would be the correct tool for playing a recorded training video about Junos automation, not for storing and versioning the code itself.

Anonymous guest access without credentials

Why it fails: Junos NETCONF requires authenticated SSH transport; anonymous guest access is not a configurable authentication method on the device. It is tempting because some REST or guest portals permit unauthenticated reads, but NETCONF always binds to a user account with defined permissions.

Unencrypted cleartext Telnet on TCP port 23

Why it fails: NETCONF runs exclusively over SSH on TCP port 830, so cleartext Telnet on port 23 cannot carry it. Telnet is tempting because it is a legacy Junos CLI access method, but it lacks the encryption and subsystem negotiation NETCONF requires.