Juniper Networks · Free Practice Questions · Last reviewed May 2026
30 real exam-style questions organised by domain, each with the correct answer highlighted and a plain-English explanation of why it's right — and why the others are wrong.
Which NETCONF RPC tag is used to gracefully terminate an active NETCONF session with a Junos device?
<terminate-session>
<close-session>
The `<close-session>` RPC performs a graceful NETCONF session teardown, allowing the Junos device to release locks and resources cleanly before closing the transport. This satisfies the stem's requirement for graceful termination, unlike `<kill-session>`, which forcibly ends another user's session without that orderly shutdown.
<disconnect>
<kill-session>
While executing a NETCONF edit-config operation, you want to ensure that any syntax errors or invalid statements immediately cause the device to roll back the entire transaction without applying partial changes. Which parameter achieves this?
<error-option>rollback-on-error</error-option>
The `<error-option>rollback-on-error</error-option>` parameter instructs the NETCONF server to discard the entire candidate configuration and revert to the previous committed state if any error occurs during the edit-config transaction. This satisfies the stem's requirement that syntax errors or invalid statements trigger a full rollback, preventing partial changes from being applied.
<test-option>test-then-set</test-option>
<default-operation>none</default-operation>
<error-option>stop-on-error</error-option>
Which XML tag encapsulates the entire response returned by a Junos device in reply to a valid NETCONF RPC request?
<rpc-reply>
Every valid NETCONF RPC response is wrapped in the <rpc-reply> element, which carries the message-id matching the request and contains the returned data or errors. This is the mandatory outer envelope defined by RFC 6241, so it encapsulates the entire response.
<response-data>
<xml-reply>
<netconf-response>
You need to lock the candidate configuration datastore in your NETCONF script to prevent concurrent modifications by other administrators. Which XML element accomplishes this?
<lock-config>
<acquire-lock>
<exclusive-edit>
<lock>
The <lock> element targets the candidate datastore, granting the requesting session exclusive write access so concurrent administrators cannot commit changes. This satisfies the requirement to prevent concurrent modifications during the script's edit window, and the lock is released by <unlock> or session termination.
You are writing a Python script to retrieve the operational state of interfaces from a Junos device using NETCONF. Which XML RPC element must be enclosed within the <rpc> tag to request operational data?
<pull-operational>
<get-rpc-reply>
<get-config>
<get>
The <get> RPC retrieves operational state data from the Junos device via NETCONF. Enclosed within <rpc>, it returns configuration and state information, whereas <get-config> returns only configuration. This makes <get> the correct element for requesting interface operational state.
An administrator issues an edit-config RPC with default-operation="replace" targeting the candidate datastore. What is the impact on the existing configuration on the Junos device?
The entire target configuration datastore is replaced by the configuration provided in the RPC payload.
Setting default-operation="replace" on the candidate datastore discards the entire existing configuration and substitutes only the hierarchy supplied in the RPC payload, satisfying the stem's whole-datastore replacement constraint. Unlike "merge", which overlays changes, or "none", which inherits per-level defaults, replace wipes unspecified configuration.
The configuration is merged, and any conflicting nodes generate a validation error.
The candidate datastore is cleared, and only the default factory configuration is loaded.
Only the specific leaf nodes provided in the RPC are updated; everything else remains intact.
Want more NETCONF And XML API practice?
Practice this domainWhich PyEZ utility module should you import if you need to upgrade the Junos operating system on a remote device via a Python script?
from jnpr.junos.utils.upgrade import Upgrade
from jnpr.junos.utils.config import Config
from jnpr.junos.device import OS_Update
from jnpr.junos.utils.sw import SW
The SW class in jnpr.junos.utils.sw exposes install() and related methods that push a Junos image to a remote device, satisfying the OS upgrade requirement. Importing it gives the script direct access to software-management RPCs rather than generic configuration handling.
You are using the PyEZ SW utility to install a new Junos image on a device. Which method parameter allows the script to automatically reboot the device after a successful installation?
auto_reboot=1
reboot=True
The reboot=True parameter instructs the PyEZ SW utility to reboot the device automatically once the new Junos image installs successfully. This satisfies the scenario's constraint of unattended installation, removing the need for a separate manual reboot step after the image is written.
reload_after_install=True
action='reboot'
An engineer is applying a candidate configuration using PyEZ and needs to load it from an external text file named 'interfaces.conf'. Which Config method should be used?
cu.load(path='interfaces.conf', format='text')
The PyEZ Config utility's load() method accepts a path argument pointing to an external file plus a format argument, so text format parses 'interfaces.conf' as Junos configuration text. This satisfies the stem's requirement to load from an external text file.
dev.load_configuration(file='interfaces.conf')
cu.load_file('interfaces.conf')
cu.read_config('interfaces.conf')
You need to execute a custom remote procedure call (RPC) in PyEZ to retrieve the Ethernet switching table. The tag in Junos XML API is get-ethernet-switching-table-information. How should you write this method call in Python?
dev.rpc.get-ethernet-switching-table-information()
dev.get_ethernet_switching_table_information()
dev.execute_rpc('get-ethernet-switching-table-information')
dev.rpc.get_ethernet_switching_table_information()
PyEZ maps XML tags to Python methods by converting hyphens to underscores, so get-ethernet-switching-table-information becomes get_ethernet_switching_table_information. Calling it on the dev.rpc object executes the custom RPC and returns the Ethernet switching table, satisfying the stem's naming constraint.
You are writing a Python script to gather operational state information from a Junos device using PyEZ. Which method should you call on an open Device instance to retrieve standard hardware and OS inventory facts into a dictionary?
dev.facts
Accessing `dev.facts` triggers PyEZ to run the built-in facts gathering routine, returning a dictionary of hardware and OS inventory such as model, serial number, hostname and Junos version. This satisfies the stem's requirement for standard inventory facts from an open Device instance without manual RPC calls.
dev.rpc.get_system_inventory()
dev.gather_facts()
dev.get_facts()
You are writing a script that uses PyEZ to load a partial configuration merge. By default, what configuration database mode does the Config utility lock and load into?
The rescue configuration database
The candidate configuration database
PyEZ's Config utility defaults to locking and loading into the candidate configuration, which satisfies the partial merge requirement without committing to the active database. Changes remain staged until an explicit commit, allowing validation before affecting running device state.
A private configuration database instance
The global active configuration database
Want more Python And PyEZ practice?
Practice this domainWhat is the primary benefit of using structured data formats (such as XML, JSON, or YAML) over unstructured CLI text output in Junos automation?
They allow automation scripts to parse device output reliably without relying on brittle regular expressions.
Structured formats expose explicit keys and hierarchy, so scripts extract fields by name or path instead of pattern-matching raw CLI text. This removes the brittleness of regular expressions that break whenever Junos output formatting or spacing changes.
Structured data formats take up less memory on the Junos Routing Engine hard drive.
They eliminate the need to authenticate when connecting via NETCONF or gRPC.
They automatically convert all IPv4 addresses to IPv6 format.
In a DevOps pipeline managing Junos devices, an engineer implements 'Infrastructure as Code' (IaC). Which practice best exemplifies this methodology when applied to Junos routing policies?
Writing custom Python scripts that use regex to parse 'show route' outputs on the fly.
Defining routing policies in Jinja2 templates and YAML data files, committing them to Git, and automatically pushing them via Ansible playbooks.
Storing Jinja2 templates and YAML data in Git, then deploying via Ansible, treats routing policy as version-controlled, declarative code. This satisfies the IaC requirement by making configuration reproducible and reviewable rather than manually applied on devices.
Manually logging into each router via SSH during a maintenance window to type out policy-options statements.
Using dynamic routing protocols like BGP to automatically advertise prefixes without human intervention.
An engineer needs to explain the primary advantage of treating network configurations as code in a modern DevOps workflow. Which principle best describes this approach?
Immutable infrastructure deployment where devices are replaced rather than updated manually.
Compiling the network CLI commands into binary machine code before executing them on Junos devices.
Storing configurations in a version control system to track history, enable rollbacks, and facilitate collaboration.
Version control stores configurations as text artefacts, giving commit history, rollback to any prior revision, and branch-based collaboration. This satisfies the stem's principle, treating configuration changes with the same review and auditability as application source code.
Automating the complete removal of the command-line interface in favor of graphical topology builders.
You are configuring a CI/CD pipeline for Junos network deployments. The pipeline must validate the syntax of generated candidate configurations against a physical or virtual Junos device before committing them to production. Which stage of the CI/CD pipeline does this validation step represent?
Continuous Deployment stage
Continuous Integration validation stage
Continuous Integration validation suits this scenario because the pipeline must check generated candidate configuration syntax against a Junos device before production commits. CI validation runs automated checks on each code change, catching syntax errors early via `commit check` against the device, satisfying the stem's pre-commit validation constraint.
Continuous Monitoring stage
Infrastructure Provisioning stage
Your CI/CD pipeline includes a linters step before deployment. Why is running a linter against YAML or Jinja2 template files critical in a Junos automation workflow?
To compile YAML files into Junos microcode for the Packet Forwarding Engine.
To automatically execute unit tests against live BGP peering sessions.
To detect syntax errors, indentation issues, and style violations in template and data files before deployment.
Linters parse YAML and Jinja2 files and flag malformed syntax, inconsistent indentation and style violations before the pipeline deploys anything. Because YAML hierarchy depends on whitespace and Jinja2 errors surface only at render time, catching these defects early prevents failed or misconfigured Junos deployments.
To encrypt sensitive passwords stored within plaintext configuration files.
A network engineer is using Git for version control of Junos configurations. During a peer review on a pull request, a merge conflict arises because two engineers modified the same interface description line in different branches. What is the correct procedure to resolve this conflict in Git?
Reboot the Junos routing engine to clear the Git repository cache and force a fast-forward merge.
Run the 'git force-merge' command to automatically discard the older branch's changes.
Use 'git reset --hard' on the remote repository to delete both conflicting branches entirely.
Manually edit the conflict markers in the affected configuration file, stage the resolved file, and complete the merge commit.
Git inserts conflict markers around the competing interface description lines; editing them manually, then running git add followed by git commit, records the resolution. This satisfies the stem's constraint of two engineers changing the same line, which Git cannot merge automatically.
Want more Junos Automation Stack And DevOps Concepts practice?
Practice this domainAn engineer needs to represent an ordered list of IP addresses in a YAML configuration file for a Junos automation playbook. Which valid YAML syntax correctly defines a sequence of items?
ip_addresses = {192.168.1.1, 192.168.1.2}
ip_addresses: [192.168.1.1: 192.168.1.2]
ip_addresses: - 192.168.1.1 - 192.168.1.2
YAML sequences are denoted by a hyphen before each item, indented beneath the parent key. Listing each IP address on its own hyphenated line under 'ip_addresses:' correctly defines an ordered sequence, which is the structure the playbook requires.
ip_addresses: * 192.168.1.1 * 192.168.1.2
A Python script retrieves interface statistics from a Junos device in JSON format, modifies a threshold value, and needs to output it back into a formatted JSON string with an indentation level of 4 spaces for readability. Which Python snippet achieves this?
json.format(data, spacing=4)
json.dumps(data, indent=4)
json.dumps() serialises a Python object into a JSON-formatted string, and its indent parameter inserts the specified number of spaces per nesting level. Passing indent=4 therefore produces the readable, four-space-indented JSON string the script requires, satisfying the formatting constraint in the stem.
json.dump(data, indent=4)
json.stringify(data, spaces=4)
An automation engineer is writing a Python script that takes a complex nested Python dictionary containing Junos telemetry parameters and converts it into a YAML string. Which PyYAML function should be used?
yaml.export()
yaml.serialize_string()
yaml.to_yaml()
yaml.safe_dump()
yaml.safe_dump() serialises Python objects to YAML while restricting output to standard safe types, preventing arbitrary object instantiation. This satisfies the constraint of converting a nested dictionary of telemetry parameters into a YAML string without exposing the script to unsafe deserialisation risks.
A network automation script is reading a YAML configuration file containing Junos device credentials. The script encounters an unhandled exception when attempting to load the file using PyYAML. Upon inspection, the error is caused by a tab character used for indentation instead of spaces. Which YAML specification rule does this violate?
Tab characters are strictly forbidden for indentation in YAML.
YAML's block structure relies on spaces for indentation; tab characters are explicitly prohibited as indentation whitespace, so PyYAML raises a scanner error when it encounters one. This directly satisfies the stem's constraint: the unhandled exception stems from a tab used instead of spaces, violating that specification rule.
Comments must start with a double forward slash (//).
YAML files require all keys to be wrapped in double quotes.
Top-level keys must start with a hyphen (-) character.
You are writing a Python automation script that processes JSON output from a Junos device's 'show interfaces' operational command via PyEZ. One of the interface descriptions contains raw control characters. When the script attempts to dump this data to a JSON string using json.dumps(), it raises a ValueError. Which parameter should you pass to json.dumps() to handle non-printable or out-of-range character encoding gracefully?
skipkeys=True
check_circular=False
ensure_ascii=False
Correct. ensure_ascii=False ensures that non-ASCII or special characters are serialized without crashing the encoder.
allow_nan=True
Which of the following data types is natively supported in JSON without requiring custom serialization handlers?
Python set
Complex number
Python tuple
Boolean
JSON defines a fixed set of native types, and boolean is one of them, serialised as true or false. Parsers map it directly to native language booleans, so no custom handler is needed, unlike types such as dates or binary data that require bespoke encoding.
Want more Data Serialization practice?
Practice this domainWhen executing a configuration change via the Junos REST API, what is the role of the HTTP DELETE method?
To clear operational state counters such as interface packet counters.
To terminate an active REST API session and revoke the auth token.
To delete a specific configuration hierarchy or statement from the candidate configuration.
HTTP DELETE targets a specific configuration hierarchy or statement, removing it from the candidate configuration rather than committing it. This satisfies the stem's constraint that the change executes against the candidate, not the active configuration, so the deletion stays uncommitted until an explicit commit operation is issued.
To discard the entire candidate configuration.
Which data serialization formats are natively supported by the Junos REST API for both input and output payloads?
JSON and XML
The Junos REST API accepts and returns both JSON and XML payloads, selected via the Accept and Content-Type headers. JSON suits lightweight scripting; XML mirrors Junos native hierarchy. Both satisfy the stem's requirement for natively supported input and output serialisation formats.
CSV and HTML
JSON and YAML
YAML and Protocol Buffers
You are writing a Python script to retrieve interface statistics from a Junos device using the REST API. You use HTTP Basic Authentication. Which HTTP header must be included to pass the encoded credentials correctly?
Proxy-Authenticate
Authorization
HTTP Basic Authentication places the Base64-encoded username and password in the Authorization request header, prefixed with "Basic". Without this header the REST API rejects the request as unauthenticated, so it satisfies the credential-passing requirement in the stem.
Junos-Auth-Token
X-API-Key
An engineer compares NETCONF and Junos REST API when fetching operational state via RPCs. How does the REST API transmit an RPC request compared to a NETCONF <rpc> wrapper?
REST API uses HTTP POST/GET requests targeting specific RPC URI paths, translating JSON/XML parameters, whereas NETCONF sends raw XML RPC elements over a dedicated SSH subsystem.
REST maps RPCs onto HTTP verbs and URI paths, encoding arguments as JSON or XML in the request body, and returns the response over HTTPS. NETCONF instead wraps raw XML <rpc> elements inside a persistent SSH subsystem session, giving a single XML-based transport rather than per-request HTTP semantics.
There is no functional difference; REST API is simply an alias for NETCONF over port 830.
NETCONF uses HTTP status codes for error reporting, while REST API uses standard syslog messages.
REST API requires a persistent WebSocket connection that tunnels NETCONF XML streams.
When an automation script issues a POST request to create a new static route via the Junos REST API, what HTTP status code indicates that the resource was successfully created?
200 OK
302 Found
204 No Content
201 Created
201 Created confirms the POST succeeded and a new static route resource now exists. The response typically includes a Location header pointing to the created object, distinguishing it from 200 OK, which signals a successful request without resource creation.
An engineer executes an HTTP GET request to retrieve interface operational details using the Junos REST API, but receives a 403 Forbidden status code. What is the most likely reason?
The HTTP request method should have been POST.
The Accept header was missing from the GET request.
The jpagent service is disabled on the device.
The authenticated user account lacks sufficient RBAC permissions to access the requested resource.
HTTP 403 Forbidden signals the request reached the Junos device and was authenticated, but the account's RBAC class or permission bits deny access to that specific RPC or configuration hierarchy. Insufficient privileges, not malformed syntax or transport failure, produce this authorisation rejection.
Want more Junos REST API practice?
Practice this domainThe JNCIA-DevOps exam has 65 questions and must be completed in 90 minutes. Always confirm current details on the vendor's official exam page.
Scenario-based questions covering exam objectives with detailed answer explanations.
The exam covers 5 domains: NETCONF And XML API, Python And PyEZ, Junos Automation Stack And DevOps Concepts, Data Serialization, Junos REST API. Questions are weighted by domain — higher-weight domains appear more on your actual exam.
No. These are original exam-style practice questions written against the official Juniper Networks JNCIA-DevOps exam objectives. They are not copied from the real exam. Courseiva focuses on genuine understanding, not memorisation of braindumps.
Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.