JNCIA-DevOps NETCONF And XML API Practice Test 2 — 15 Questions

Question 1

Which TWO configuration datastores are commonly supported and utilized when interacting with Junos devices via NETCONF? (Choose two)

Accepted Answer

candidate. Option C (candidate) is correct because Junos supports the NETCONF datastore, allowing configuration changes to be staged and validated via before becoming active. Option D (running) is correct because the running datastore holds the device's active configuration and is a standard NETCONF datastore that Junos exposes for retrieval and, in some modes, direct editing. Options A (startup) and E (factory) are not standard NETCONF datastores in Junos; startup and factory-default configurations are handled through Junos CLI mechanisms rather than NETCONF datastore operations. Option B (ephemeral) is a datastore concept used by some vendors (e.g., OpenConfig/NETCONF implementations), but it is not a commonly supported NETCONF datastore on Junos devices.

Answer

startup

Answer

ephemeral

Answer

factory

Question 2

Which TWO attributes or parameters can be used within a NETCONF <edit-config> operation to control how configuration data is merged or replaced? (Choose two)

Accepted Answer

target. The <edit-config> RPC accepts parameters such as target, default-operation, and test-option.

Answer

baud-rate

Answer

ssh-cipher

Question 3

Which TWO elements are mandatory components of every valid NETCONF RPC request sent to a Junos device? (Choose two)

Accepted Answer

Appropriate XML namespace definitions (xmlns). Every NETCONF request must be enclosed in an <rpc> XML element and possess a valid namespace.

Answer

Answer

<lock>

Question 4

Which TWO tools or protocols can be used to interact with the Junos XML API besides NETCONF over SSH? (Choose two)

Accepted Answer

Junos PyEZ library. Option A (Junos PyEZ library) is correct because Junos PyEZ is a Python library that communicates with the Junos XML API over NETCONF, but it also provides programmatic access to the XML API through its own abstractions, allowing interaction with Junos devices without manually crafting NETCONF RPCs. Option C (XML API over HTTP/HTTPS via the mgmt daemon) is correct because Junos supports the XML API directly over HTTP or HTTPS using the management daemon (mgmt), which is an alternative transport to NETCONF over SSH. Option B (Syslog over UDP port 514) is not a tool or protocol for interacting with the Junos XML API; it is used for event logging. Option D (RADIUS authentication protocol) is an AAA protocol for authentication, authorization, and accounting, not for XML API interaction. Option E (SNMP v3 traps) is used for asynchronous notifications and network management, not for XML API operations.

Answer

Syslog over UDP port 514

Answer

RADIUS authentication protocol

Answer

SNMP v3 traps

Question 5

Which TWO operations are valid targets for the NETCONF <get-config> RPC on a Junos device? (Choose two)

Accepted Answer

. The NETCONF RPC requires a element that names a configuration datastore, and on Junos the two valid datastore targets are (option B) and (option E). is correct because Junos maintains a candidate configuration that can be retrieved via before it is committed. is correct because it is the standard NETCONF running datastore, representing the currently active committed configuration on the device. Option A is not a NETCONF datastore target for ; it is a configuration state that must be loaded, not queried directly. Option C is not a Junos NETCONF datastore exposed to ; startup configuration is handled through Junos-specific mechanisms rather than the standard datastore set. Option D is operational data, which is retrieved with rather than , since only returns configuration data.

Answer

<factory-default/>

Answer

Answer

<active-alarm/>

Question 6

Which THREE parameters can be included within a Junos NETCONF <commit> RPC request to customize commit behavior? (Choose three)

Accepted Answer

integer . Option A, integer , is correct because the Junos NETCONF RPC supports this tag to specify the number of minutes the confirmed commit remains active before automatically rolling back if no confirming commit is issued. Option B, , is correct because it triggers a confirmed commit, which requires a follow-up commit within the timeout period or the configuration is automatically reverted. Option D, describing the change , is correct because the RPC accepts a comment tag that stores a descriptive string in the commit history, visible via 'show system commit'. Option C, integer , is incorrect because the maximum number of rollback files is configured under [edit system] with 'set system max-configurations-on-flash', not as a parameter inside the RPC. Option E, string , is incorrect because commit RPCs do not accept an encryption key; configuration encryption is handled separately via 'encrypt-configuration' or the 'load merge ... | encrypt' mechanisms.

Answer

<max-rollback-files> integer </max-rollback-files>

Answer

<encryption-key> string </encryption-key>

Question 7

Which TWO conditions will cause a NETCONF <edit-config> transaction to fail on a Junos device? (Choose two)

Accepted Answer

Syntax errors in the XML payload structure.. Option C is correct because NETCONF operations are parsed as XML, and any malformed XML payload (unclosed tags, invalid element nesting, or a missing namespace declaration) causes the device to reject the request with an RPC error such as 'malformed-message' before any configuration is applied. Option E is correct because Junos performs semantic validation when the candidate configuration is committed; if the edited configuration violates Junos rules (for example, referencing a nonexistent interface or an invalid protocol value), the commit fails with a validation error and the transaction does not complete. Option A is not a failure condition: a successful immediately after editing is the normal, expected workflow that finalizes the transaction. Option B is not a failure condition: a valid namespace prefix declared in the NETCONF hello message is required for correct XML parsing and enables, rather than prevents, the edit. Option D is not a failure condition: locking the candidate datastore before editing is a recommended practice that reserves the datastore and prevents conflicting concurrent edits.

Answer

Executing a successful <commit> immediately after editing.

Answer

Using a valid namespace prefix declared in the NETCONF hello message.

Answer

Locking the candidate datastore prior to making edits.

Question 8

An automation script connects to a Junos device using NETCONF over SSH and retrieves the running configuration. The engineer notices that the retrieved XML elements contain attributes like 'operation="inherit"'. What do these attributes represent in the context of Junos XML API?

Accepted Answer

They describe the configuration hierarchy manipulation state, indicating whether a statement is inherited from apply-groups or explicitly defined.. Junos XML output uses attributes such as 'operation' to indicate how configuration statements relate to inheritance, deletion, or modification within hierarchical structures.

Answer

They indicate the automation user permission level required to modify that specific node.

Answer

They represent transient states of the NETCONF parser buffer indicating stream synchronization status.

Answer

They represent mapping hints for how Junos hierarchical statements map to hierarchical template inheritances during operational state generation.

Question 9

An automation engineer is writing an application that sends an RPC to a Junos device to load a replacement configuration. The requirement is to completely replace the candidate configuration with the provided configuration content. Which element and attribute combination should be used inside the request?

Accepted Answer

replace. In NETCONF's operation, the element controls how the provided configuration data is merged with the target datastore. Setting replace tells the device to replace the entire target configuration with the content supplied in the RPC, which is exactly the 'complete replacement' behavior required. This is defined in RFC 6241 and is the standard mechanism for full-config replacement via NETCONF.

Answer

<load-options>replace</load-options>

Answer

replace-all

Answer

<action>overwrite</action>

Question 10

During troubleshooting of a Python script using the ncclient library to interact with a Junos device, an automation engineer observes a 'rpc-error' response containing an error-tag of 'operation-failed'. Upon examining the Junos system logs, it is discovered that the candidate configuration had syntax errors introduced by an uncommitted previous session. Which NETCONF capability negotiation mechanism ensures that the client is aware of the exact XML schema constraints before sending the RPC?

Accepted Answer

NETCONF capability URIs exchanged during the initial hello message exchange.. NETCONF hello messages exchange capabilities, which include URLs pointing to XML namespaces and data models such as YANG modules or Junos specific DTDs/XSDs.

Answer

The <get-schema> RPC operation defined in RFC 6020.

Answer

The automatic download of Junos PyEZ schema definitions during the SSH handshake phase.

Answer

The automated execution of a pre-flight XML validation check via the <validate> RPC.

Question 11

An administrator needs to execute a NETCONF RPC that triggers a Junos operational command equivalent to 'clear interfaces statistics ge-0/0/0'. How should this request be formatted using the Junos XML API?

Accepted Answer

ge-0/0/0

. Operational commands (RPCs) are sent as raw XML elements corresponding to CLI commands under the wrapper or directly as named RPC tags (e.g., clear interfaces statistics interface-name ge-0/0/0 or its native equivalent).

Answer

clear interfaces statistics ge-0/0/0

Answer

Answer

Question 12

An automation engineer is designing a Junos XML API workflow that uses the <get-config> operation. Which THREE parameters or filtering methods are valid when retrieving configuration data from a Junos device using NETCONF? (Choose three.)

Accepted Answer

Specifying the source datastore (e.g., ).. Option B is correct because NETCONF's operation requires a element identifying the datastore to read, such as (or candidate/startup), which is mandatory in the RFC 6241 operation. Option C is correct because subtree filtering is a standard NETCONF filtering method placed inside the element, allowing retrieval of specific configuration nodes by element names, attributes, and content-match expressions. Option D is correct because Junos supports XPath filtering via with an XPath expression, a valid Junos XML API extension for selecting configuration hierarchies. Option A is not valid because is a Junos-specific mechanism for querying operational data (not configuration) and is not part of the NETCONF filtering parameters. Option E is not valid because is not a NETCONF attribute; depth control is not a standard parameter of that operation.

Answer

Using SQL queries enclosed in <sql-query> tags to extract table rows directly from the configuration database.

Answer

Using the attribute within the tag to limit configuration tree traversal.

Question 13

When executing a NETCONF transaction on a Junos device, an automation script encounters an error or needs to discard changes made in the candidate datastore. Which THREE RPC elements or concepts apply to discarding or rolling back changes in Junos NETCONF workflows? (Choose three.)

Accepted Answer

Unlocking the configuration datastore using ensures other administrators are not permanently locked out if a script terminates unexpectedly.. Option C is correct because Junos NETCONF uses a candidate datastore that is locked with during a transaction; if a script crashes or exits without releasing the lock, the configuration remains locked, so issuing (or ensuring the lock is released) prevents other administrators from being permanently locked out. Option D is correct because is the standard Junos NETCONF RPC that discards all uncommitted edits in the candidate configuration and reverts it to match the current running configuration, which is exactly the rollback/discard behavior needed when a transaction fails. Option E is correct because Junos supports commit-time rollback via the RPC with a N parameter (for example 1), which reverts the configuration to a previous committed checkpoint, a valid rollback mechanism in NETCONF workflows. Option A is incorrect because is not a standalone top-level NETCONF operation defined in RFC 6241; rollback in Junos is done through commit rollback parameters or configuration rollback commands, not that RPC. Option B is incorrect because there is no standard RPC in NETCONF for canceling an active streaming configuration edit; aborting is handled by discarding changes or closing the session, not by an operation.

Answer

The <rollback-config> operation is a standalone top-level NETCONF protocol operation defined in RFC 6241.

Answer

The <abort> RPC can be used mid-transaction to cancel an active streaming configuration edit.

Question 14

An automation engineer is writing a Python script that uses the Junos XML API over a NETCONF session to retrieve the device's hostname. The script must send an RPC that returns the hostname as a structured XML element. Which RPC should the script use?

Accepted Answer

. To retrieve a specific configuration value such as the hostname, the script should use the RPC with a subtree filter that selects the element under . This returns the value as structured XML, which can be easily parsed. Other RPCs provide operational or software information but not the configured hostname.

Answer

<get-hostname>

Answer

<get-system-information>

Answer

<get-software-information>

Question 15

An automation engineer is using the Junos XML API to manage configuration changes on a Junos device. The engineer needs to ensure that the operation is atomic and that the configuration is validated before committing. Which TWO attributes or elements must be included in the RPC to achieve this? (Choose two.)

Accepted Answer

The element set to "rollback-on-error".. To achieve atomic and validated configuration changes, the RPC must target the candidate datastore and include the error-option set to rollback-on-error. Targeting the candidate allows validation before commit, and rollback-on-error ensures that partial failures do not leave the configuration in an inconsistent state. Other attributes like merge or replace do not provide these guarantees.

Answer

The <default-operation> element set to "replace".

Answer

The element within the RPC.

Answer

The operation attribute set to "merge" on the configuration hierarchy.