Troubleshooting practice questions

An automation engineer is troubleshooting a Junos REST API script that intermittently fails with HTTP 401 Unauthorized errors when retrieving operational data. The script uses HTTP Basic Authentication with a valid username and password. The engineer confirms that the credentials are correct and that the REST API is enabled. What is the most likely cause of the intermittent failures?

Trap 1: The script is exceeding the maximum number of concurrent REST API…

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.

Trap 2: The device's clock is out of sync with the authentication server,…

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.

Trap 3: The REST API requires the use of a session cookie instead of Basic…

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.

A
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.
B
The device is configured to use RADIUS authentication, and the RADIUS server is occasionally unreachable.
Intermittent 401 errors with correct local credentials often indicate an external authentication server issue. If the Junos device is configured to use RADIUS or TACACS+ for authentication, a temporary network problem or server unavailability can cause authentication to fail, resulting in 401 responses. The REST API relies on the device's authentication mechanisms.
C
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.
D
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.

Question 2mediummulti select

When designing a version control workflow for Junos configurations using Git, which THREE practices are considered industry best standards? (Choose three)

Trap 1: Completely bypassing automated testing to speed up deployments

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.

Trap 2: Storing plaintext administrative passwords directly in public Git…

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.

A
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.
B
Using feature branches for developing new configuration changes before merging into main
Feature branches isolate in-progress Junos configuration edits from the main branch, so unstable or untested changes never reach production until deliberately merged. This satisfies the workflow's requirement for controlled, reviewable integration of configuration changes rather than committing directly to main.
C
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.
D
Requiring peer reviews and pull request approvals prior to merging changes
Pull request approvals enforce a second pair of eyes before any Junos configuration change reaches main, catching syntax or policy errors early. Peer review satisfies the governance constraint that changes be independently verified prior to merging, reducing the risk of an unreviewed misconfiguration propagating to devices.
E
Using semantic or descriptive commit messages to document the intent of configuration updates
Descriptive commit messages record why a Junos configuration changed, not merely what changed, so auditors and engineers can trace intent through Git history. This satisfies the traceability requirement of a version control workflow, enabling rollback decisions and root-cause analysis without inspecting every diff manually.

Question 3hardmultiple choice

An engineer is troubleshooting a script that updates Junos configuration via the REST API. The payload is sent as JSON, but the device returns a 415 Unsupported Media Type error. What is the root cause?

Trap 1: The device is running out of memory buffers.

A 415 response concerns the Content-Type header of the request body, not device memory. Memory exhaustion would surface as 500-level errors or dropped sessions. It is tempting because resource shortages can cause odd failures, but it would be correct only if the stem described 503 responses or buffer allocation errors.

Trap 2: The user account does not have permission to execute PUT requests.

Missing permission produces 401 Unauthorised or 403 Forbidden, since the request is authenticated but not allowed. 415 is independent of authorisation and concerns payload media type. It is tempting because both are client errors, but it would be correct only if the stem described an access-denied response.

Trap 3: The target resource URI path does not exist on the device.

An invalid URI path yields 404 Not Found, because the server cannot map the request to a resource. 415 is raised when the Content-Type or body encoding is unacceptable. It is tempting because both are client-side errors, but it would be correct only if the stem reported a 404 rather than a media type rejection.

A
The device is running out of memory buffers.
Why it fails: A 415 response concerns the Content-Type header of the request body, not device memory. Memory exhaustion would surface as 500-level errors or dropped sessions. It is tempting because resource shortages can cause odd failures, but it would be correct only if the stem described 503 responses or buffer allocation errors.
B
The user account does not have permission to execute PUT requests.
Why it fails: Missing permission produces 401 Unauthorised or 403 Forbidden, since the request is authenticated but not allowed. 415 is independent of authorisation and concerns payload media type. It is tempting because both are client errors, but it would be correct only if the stem described an access-denied response.
C
The Content-Type header provided in the HTTP request is missing or specifies an unsupported media type.
A 415 response is returned by the Junos REST API when the request's Content-Type header does not match the payload format. Since the script sends JSON, the header must be `Content-Type: application/json`; omitting it or specifying another media type causes the device to reject the request before parsing the body.
D
The target resource URI path does not exist on the device.
Why it fails: An invalid URI path yields 404 Not Found, because the server cannot map the request to a resource. 415 is raised when the Content-Type or body encoding is unacceptable. It is tempting because both are client-side errors, but it would be correct only if the stem reported a 404 rather than a media type rejection.

Question 4mediummultiple choice

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?

Trap 1: To compile YAML files into Junos microcode for the Packet…

Linters parse and validate syntax, indentation and schema; they do not compile YAML into Junos microcode, which is produced by Junos tooling for the Packet Forwarding Engine. Compilation is the correct concern when translating configuration into executable forwarding-plane instructions, not pre-deployment validation.

Trap 2: To automatically execute unit tests against live BGP peering…

A linter parses template syntax and flags malformed YAML or Jinja2; it never opens BGP sessions or runs tests. Unit testing against live peers belongs to a separate test stage using tools such as PyEZ or Robot Framework, so this describes test execution, not static validation of configuration templates.

Trap 3: To encrypt sensitive passwords stored within plaintext…

Linters detect syntax, schema and style errors; they perform no cryptographic operations and cannot encrypt secrets in plaintext files. Encryption is the right control when protecting credentials at rest, typically via a secrets manager or Ansible Vault rather than a linting stage.

A
To compile YAML files into Junos microcode for the Packet Forwarding Engine.
Why it fails: Linters parse and validate syntax, indentation and schema; they do not compile YAML into Junos microcode, which is produced by Junos tooling for the Packet Forwarding Engine. Compilation is the correct concern when translating configuration into executable forwarding-plane instructions, not pre-deployment validation.
B
To automatically execute unit tests against live BGP peering sessions.
Why it fails: A linter parses template syntax and flags malformed YAML or Jinja2; it never opens BGP sessions or runs tests. Unit testing against live peers belongs to a separate test stage using tools such as PyEZ or Robot Framework, so this describes test execution, not static validation of configuration templates.
C
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.
D
To encrypt sensitive passwords stored within plaintext configuration files.
Why it fails: Linters detect syntax, schema and style errors; they perform no cryptographic operations and cannot encrypt secrets in plaintext files. Encryption is the right control when protecting credentials at rest, typically via a secrets manager or Ansible Vault rather than a linting stage.

Read the full REST/YANG explanation →

Question 5hardmulti select

When interacting with Junos devices via NETCONF, which TWO RPC operations are part of standard NETCONF protocol capabilities? (Choose two)

Trap 1: <reboot-routing-engine-force>

<reboot-routing-engine-force> is a Junos extension RPC, not part of the base NETCONF capability set defined in RFC 6241. It is tempting because Junos exposes it over the same NETCONF session, and it is valid when you specifically need a forced routing-engine restart on Juniper hardware, but standard operations are get-config, edit-config, lock and close-session.

Trap 2: <format-hard-drive>

Not a NETCONF operation.

Trap 3: <traceroute-packet>

Not a standard NETCONF RPC.

A
<reboot-routing-engine-force>
Why it fails: <reboot-routing-engine-force> is a Junos extension RPC, not part of the base NETCONF capability set defined in RFC 6241. It is tempting because Junos exposes it over the same NETCONF session, and it is valid when you specifically need a forced routing-engine restart on Juniper hardware, but standard operations are get-config, edit-config, lock and close-session.
B
<get-config>
<get-config> is a base NETCONF capability defined in RFC 6241, retrieving all or part of a specified configuration datastore. It satisfies the stem's requirement for a standard protocol RPC operation, unlike Junos-specific or vendor extension operations.
C
<format-hard-drive>
Why it fails: Not a NETCONF operation.
D
<traceroute-packet>
Why it fails: Not a standard NETCONF RPC.
E
<edit-config>
`<edit-config>` is a base NETCONF capability defined in RFC 6241, used to load configuration data into a target datastore such as candidate or running. It satisfies the stem's requirement for standard NETCONF RPC operations, unlike Junos-specific extensions.

Question 6hardmulti select

When troubleshooting REST API authentication and authorization on Junos devices, which THREE log files or diagnostic tools can an administrator inspect? (Choose three)

Trap 1: Kernel core dump files located in /var/crash/kernel.

Kernel core dumps record crashes, not REST API authentication or authorisation events, so they contain no relevant request or token data. It is tempting as a general Junos diagnostic location, but the correct sources are the messages and httpd logs plus traceoptions for the API daemon.

Trap 2: BGP peer state packet captures in Wireshark.

BGP peer state captures show routing adjacency transitions, not REST API authentication or authorization events, so they reveal nothing about API tokens, login failures or permission denials. Packet capture is tempting when diagnosing routing protocol flaps or TCP-level connectivity, but the stem asks specifically about REST API auth logging.

A
Kernel core dump files located in /var/crash/kernel.
Why it fails: Kernel core dumps record crashes, not REST API authentication or authorisation events, so they contain no relevant request or token data. It is tempting as a general Junos diagnostic location, but the correct sources are the messages and httpd logs plus traceoptions for the API daemon.
B
HTTP response headers and status codes returned by the API client.
HTTP response headers and status codes expose authentication and authorisation outcomes directly: 401 signals failed credentials, 403 signals insufficient privileges, and WWW-Authenticate reveals the required scheme. Inspecting these on the API client satisfies the stem's need to diagnose REST authentication and authorisation faults without device-side log access.
C
jpagent traceoptions log file (if configured under system services jpagent)
The jpagent traceoptions log records REST API request handling, including authentication attempts and authorisation failures, when tracing is enabled under system services jpagent. It isolates API-layer activity from general daemon logging, directly satisfying the troubleshooting requirement for REST API authentication and authorisation diagnostics.
D
BGP peer state packet captures in Wireshark.
Why it fails: BGP peer state captures show routing adjacency transitions, not REST API authentication or authorization events, so they reveal nothing about API tokens, login failures or permission denials. Packet capture is tempting when diagnosing routing protocol flaps or TCP-level connectivity, but the stem asks specifically about REST API auth logging.
E
/var/log/messages system log file for daemon startup and authentication events.
/var/log/messages captures daemon startup and authentication events, including those logged by the Junos REST API daemon during login attempts. This satisfies the scenario's need to inspect authentication and authorisation activity, complementing API-specific traces with system-level event records.

Question 7hardmulti select

A DevOps engineer is designing a CI/CD pipeline for validating Junos configuration changes prior to deployment. Which THREE actions are typically performed during the automated CI pipeline 'test' or 'validate' stage? (Choose THREE)

Trap 1: Immediately rebooting the production core routing engine to apply…

Rebooting the production core routing engine applies changes to live infrastructure, which is the deployment stage, not validation; the test stage verifies configuration offline before any production impact. It is tempting because a reboot does commit and activate a candidate configuration, but that belongs to a controlled change window, not automated pre-deployment testing.

Trap 2: Manually logging into physical CLI consoles to troubleshoot cabling

Manual console troubleshooting is an interactive, human-driven diagnostic activity, not an automated pipeline step; the validate stage runs scripted checks such as commit check, syntax validation and unit tests. It is tempting because physical console access is genuinely required when a device is unreachable, but that is break-fix work, not CI validation.

A
Performing dry-run validation checks against staging or virtual Junos instances (vSRX)
Dry-run validation against staging or vSRX instances exercises the candidate Junos configuration on a non-production device, catching syntax and commit errors before production deployment. This satisfies the pipeline's validate-stage constraint by confirming the configuration commits cleanly without touching live infrastructure.
B
Immediately rebooting the production core routing engine to apply all updates
Why it fails: Rebooting the production core routing engine applies changes to live infrastructure, which is the deployment stage, not validation; the test stage verifies configuration offline before any production impact. It is tempting because a reboot does commit and activate a candidate configuration, but that belongs to a controlled change window, not automated pre-deployment testing.
C
Running automated linters and style checks on Python automation scripts and Jinja2 templates
Linters and style checks statically analyse Python scripts and Jinja2 templates, catching syntax errors, undefined variables and formatting violations before rendering. This satisfies the stem's pre-deployment validation constraint, since faults surface in the CI pipeline rather than on production Junos devices.
D
Executing static syntax and semantic validation of candidate configurations against device schemas
Static syntax and semantic validation checks candidate configurations against Junos device schemas before deployment, catching malformed syntax and invalid hierarchies without touching production devices. This satisfies the pipeline's pre-deployment validation constraint, since the test stage must verify configuration correctness offline, ensuring only schema-compliant changes proceed to the deployment stage.
E
Manually logging into physical CLI consoles to troubleshoot cabling
Why it fails: Manual console troubleshooting is an interactive, human-driven diagnostic activity, not an automated pipeline step; the validate stage runs scripted checks such as commit check, syntax validation and unit tests. It is tempting because physical console access is genuinely required when a device is unreachable, but that is break-fix work, not CI validation.