Automation practice questions

A network engineer needs to automate the backup of running configurations from multiple Cisco IOS XE devices to a central TFTP server. Which tool is best suited for this task in a Python-based automation framework?

Trap 1: RESTCONF

RESTCONF is a model-driven network management protocol that uses HTTP methods (GET, POST, PUT, DELETE) to manipulate YANG-defined data structures over HTTPS. It is designed for structured, API-based device configuration and state retrieval, not for emulating CLI commands or interacting with a device's command-line interface. Backing up a running configuration via CLI requires an SSH/CLI transport, which RESTCONF does not provide, making it unsuitable for this specific task.

Trap 2: Ansible

Ansible is an open-source automation platform that uses YAML playbooks and modules (e.g., ios_command, ios_config) to manage network devices over SSH or other protocols. While Ansible can automate configuration backups, it is a standalone tool requiring an Ansible control node and inventory, not a Python library that can be directly imported into a custom script. Because the engineer needs to integrate SSH-based backup into a Python automation workflow, Ansible would be an external orchestration layer, not the underlying SSH connectivity library.

Trap 3: Paramiko

Paramiko is a pure-Python implementation of the SSHv2 protocol, providing a low-level SSH client (paramiko.SSHClient) that can authenticate with network devices and execute CLI commands directly. It is the foundational library that actually handles SSH session establishment, encryption, and command execution, making it the correct choice when the requirement is to automate backup of the running configuration via SSH from Python. Its low-level API allows precise control over the SSH connection, including handling interactive prompts and command output.

A
RESTCONF
Why it fails: RESTCONF is a model-driven network management protocol that uses HTTP methods (GET, POST, PUT, DELETE) to manipulate YANG-defined data structures over HTTPS. It is designed for structured, API-based device configuration and state retrieval, not for emulating CLI commands or interacting with a device's command-line interface. Backing up a running configuration via CLI requires an SSH/CLI transport, which RESTCONF does not provide, making it unsuitable for this specific task.
B
Ansible
Why it fails: Ansible is an open-source automation platform that uses YAML playbooks and modules (e.g., ios_command, ios_config) to manage network devices over SSH or other protocols. While Ansible can automate configuration backups, it is a standalone tool requiring an Ansible control node and inventory, not a Python library that can be directly imported into a custom script. Because the engineer needs to integrate SSH-based backup into a Python automation workflow, Ansible would be an external orchestration layer, not the underlying SSH connectivity library.
C
Paramiko
Why it fails: Paramiko is a pure-Python implementation of the SSHv2 protocol, providing a low-level SSH client (paramiko.SSHClient) that can authenticate with network devices and execute CLI commands directly. It is the foundational library that actually handles SSH session establishment, encryption, and command execution, making it the correct choice when the requirement is to automate backup of the running configuration via SSH from Python. Its low-level API allows precise control over the SSH connection, including handling interactive prompts and command output.
D
Netmiko
Netmiko is a high-level Python library built on top of Paramiko that abstracts away many SSH and CLI complexities for network device interaction. While Netmiko could also be used to automate configuration backups and is convenient for multi-vendor support, the question specifically targets the underlying SSH library that provides raw SSH connectivity — which is Paramiko. Netmiko adds a layer of device-specific command handling and expects a deterministic CLI prompt, whereas Paramiko is the actual SSH protocol implementation that Netmiko relies on; thus Paramiko is the more fundamental correct answer.

Question 2mediummultiple choice

A network engineer is creating a Python script using the Cisco IOS XE RESTCONF API to configure a loopback interface. The script sends a PUT request to the URI /restconf/data/Cisco-IOS-XE-native:native/interface/Loopback=100 with a JSON body that includes the IP address. The API returns a 201 Created status, but the loopback interface does not appear in the running configuration. What is the most likely issue?

Trap 1: The RESTCONF API returned an error but the script ignored it

201 Created indicates success.

Trap 2: The loopback interface number is incorrect in the URI

The URI syntax is correct.

Trap 3: The script is not authenticated properly

Authentication errors would return 401 or 403.

A
The RESTCONF API returned an error but the script ignored it
Why it fails: 201 Created indicates success.
B
The loopback interface number is incorrect in the URI
Why it fails: The URI syntax is correct.
C
The script is not authenticated properly
Why it fails: Authentication errors would return 401 or 403.
D
The PUT request should be a POST request to create a new resource
POST is used to create a new resource; PUT replaces an existing one.

Study the full ACL explanation →

Question 3mediummultiple choice

A network engineer is troubleshooting an Ansible playbook that uses the ios_config module to apply ACLs. The playbook runs without errors, but the ACLs are not applied to the device. The engineer verifies that the device is reachable and the credentials are correct. What is the most likely cause?

Trap 1: The device is in a different VRF and not reachable

Even if the device resides in a different VRF, the engineer has already confirmed that it is reachable from the control node (e.g., via ping or SSH). A VRF mismatch would typically manifest as a timeout or 'unreachable' error during the connection phase, but since reachability was verified, the playbook would at least be able to open a connection. Therefore, VRF placement cannot be the reason the playbook is failing; the issue lies elsewhere in the Ansible configuration or task definition.

Trap 2: The ACL syntax in the playbook is incorrect

If the ACL syntax in the playbook were truly invalid, Ansible would return a syntax or parsing error during the 'getting started' phase or when the ios_config module attempts to validate the proposed configuration. Such an error would be explicit and would prevent the play from running further, not cause a generic failure before any device interaction. Since the troubleshooting is centered on the playbook failing to connect or execute properly, incorrect ACL syntax is not the root cause; it would be an execution-time error, not a connectivity/precondition issue.

Trap 3: The ios_config module requires the netmiko library to be installed…

The ios_config module, like all native Ansible network modules, uses Ansible's own connection layer–network_cli–which handles SSH natively and is independent of the Netmiko library. Netmiko is an external Python library used by other automation scripts or legacy modules, but it is not a prerequisite for Ansible's network modules. Installing Netmiko on the control node would not change the behavior of the playbook; the failure is due to the missing connection plugin configuration, not a missing third-party library.

A
The device is in a different VRF and not reachable
Why it fails: Even if the device resides in a different VRF, the engineer has already confirmed that it is reachable from the control node (e.g., via ping or SSH). A VRF mismatch would typically manifest as a timeout or 'unreachable' error during the connection phase, but since reachability was verified, the playbook would at least be able to open a connection. Therefore, VRF placement cannot be the reason the playbook is failing; the issue lies elsewhere in the Ansible configuration or task definition.
B
The playbook is missing the connection parameter set to 'network_cli'
Ansible's standard 'ssh' connection plugin is designed for Linux hosts and does not handle the interactive CLI prompts, privilege modes, or device-specific quirks of Cisco IOS. Network modules like ios_config require the 'connection' parameter set to 'network_cli' (or a similar network connection plugin) in the playbook, role, or inventory. Without this, the module cannot properly execute, and the task typically fails with an error indicating that the connection type is unsupported or that the device is unreachable, even though TCP/SSH may be fine.
C
The ACL syntax in the playbook is incorrect
Why it fails: If the ACL syntax in the playbook were truly invalid, Ansible would return a syntax or parsing error during the 'getting started' phase or when the ios_config module attempts to validate the proposed configuration. Such an error would be explicit and would prevent the play from running further, not cause a generic failure before any device interaction. Since the troubleshooting is centered on the playbook failing to connect or execute properly, incorrect ACL syntax is not the root cause; it would be an execution-time error, not a connectivity/precondition issue.
D
The ios_config module requires the netmiko library to be installed on the control node
Why it fails: The ios_config module, like all native Ansible network modules, uses Ansible's own connection layer–network_cli–which handles SSH natively and is independent of the Netmiko library. Netmiko is an external Python library used by other automation scripts or legacy modules, but it is not a prerequisite for Ansible's network modules. Installing Netmiko on the control node would not change the behavior of the playbook; the failure is due to the missing connection plugin configuration, not a missing third-party library.

Read the full Automation explanation →

Question 4hardmulti select

Which THREE are valid methods for automating network device configuration using Cisco IOS XE? (Choose three.)

Trap 1: SNMP Set requests

SNMP is mainly for monitoring, not configuration automation.

Trap 2: Telnet with Expect scripts

Telnet is insecure and not recommended.

A
NETCONF/YANG
NETCONF/YANG provides a model-driven, transactional interface over SSH on Cisco IOS XE, satisfying the requirement for programmatic configuration automation. YANG models define the device schema, letting tooling push validated configuration changes atomically, unlike legacy CLI scraping. This makes it a valid automation method alongside RESTCONF and Python-based scripting.
B
SNMP Set requests
Why it fails: SNMP is mainly for monitoring, not configuration automation.
C
Telnet with Expect scripts
Why it fails: Telnet is insecure and not recommended.
D
CLI via SSH with Python (e.g., Netmiko)
Netmiko opens an SSH session and sends IOS CLI commands programmatically, parsing output as text. This satisfies the automation requirement because IOS XE's CLI remains fully available over SSH, letting Python scripts push configuration without model-driven interfaces.
E
RESTCONF
RESTCONF exposes Cisco IOS XE's YANG-modelled data over HTTPS using RESTful verbs (GET, POST, PUT, PATCH, DELETE), satisfying the automation requirement through structured, programmatic configuration rather than CLI scraping. Its JSON or XML payloads map directly to the device's native data model, enabling idempotent changes.

Read the full Ansible explanation →

Question 5mediummultiple choice

Refer to the exhibit. A network engineer wants to use Ansible to change the IP address of Loopback100 from 10.1.100.1/24 to 10.1.200.1/24. The playbook uses the ios_config module. The playbook runs successfully, but the IP address remains unchanged. What is the most likely reason?

Exhibit

R1#show ip interface brief | include Loopback
Loopback0        10.1.1.1       YES manual up                    up
Loopback100      10.1.100.1     YES manual up                    up

R1#show run interface Loopback100
Building configuration...
Current configuration : 67 bytes
!
interface Loopback100
 ip address 10.1.100.1 255.255.255.0
end

R1#show run | include snmp-server
snmp-server community public RO
snmp-server community private RW

Trap 1: The loopback interface is administratively down

The exhibit shows the loopback interface in an up/up state, so administratively down is factually incorrect. Even if it were down, loopback interfaces are logical and do not carry physical signals, and Ansible's ios_config module is manipulating the running configuration rather than interface state. Since the playbook is already reaching the device to execute configuration changes, a down interface cannot be the reason the intended commands are not applied.

Trap 2: The playbook is sending the wrong CLI commands

The CLI commands in the playbook are syntactically correct and would produce the desired configuration if they were actually pushed to the device. The problem is not the command strings themselves but the module's behavior: by default, ios_config merges changes and does not explicitly remove commands that conflict with the intended state, so existing CLI commands may remain. Therefore, the wrong-commands explanation confuses the module's merge-and-compare logic with a typographical or syntactical error.

Trap 3: The SNMP community strings are not configured correctly

The ios_config module is a network_cli-based Ansible module that connects to the IOS device over SSH, not over SNMP. SNMP community strings are used for read/write management via SNMP protocols, such as for monitoring traps or occasional writes, and play no role in Ansible's configuration workflow. Misconfigured community strings would not prevent the playbook from establishing its SSH connection or from executing configuration commands, so they are irrelevant to the failure.

A
The loopback interface is administratively down
Why it fails: The exhibit shows the loopback interface in an up/up state, so administratively down is factually incorrect. Even if it were down, loopback interfaces are logical and do not carry physical signals, and Ansible's ios_config module is manipulating the running configuration rather than interface state. Since the playbook is already reaching the device to execute configuration changes, a down interface cannot be the reason the intended commands are not applied.
B
The playbook is sending the wrong CLI commands
Why it fails: The CLI commands in the playbook are syntactically correct and would produce the desired configuration if they were actually pushed to the device. The problem is not the command strings themselves but the module's behavior: by default, ios_config merges changes and does not explicitly remove commands that conflict with the intended state, so existing CLI commands may remain. Therefore, the wrong-commands explanation confuses the module's merge-and-compare logic with a typographical or syntactical error.
C
The ios_config module is not configured to replace the existing configuration
By default, the ios_config module operates in merge mode, only adding or updating commands that are missing from the running configuration. To replace the existing configuration with the exact contents of the playbook, the engineer must set `replace: config` and typically `match: strict`; without these parameters, the module will not issue a wholesale replacement and the old configuration persists. Because the playbook lacks the replace option, the module cannot achieve the intended end state, even though it may report a successful change or no change.
D
The SNMP community strings are not configured correctly
Why it fails: The ios_config module is a network_cli-based Ansible module that connects to the IOS device over SSH, not over SNMP. SNMP community strings are used for read/write management via SNMP protocols, such as for monitoring traps or occasional writes, and play no role in Ansible's configuration workflow. Misconfigured community strings would not prevent the playbook from establishing its SSH connection or from executing configuration commands, so they are irrelevant to the failure.

Question 6hardmultiple choice

Refer to the exhibit. A Python script sends the JSON payload shown via a POST request to the RESTCONF URI /restconf/data/ietf-interfaces:interfaces on a Cisco IOS XE device. The API returns 201 Created, but the interface GigabitEthernet1 is not configured. What is the most likely cause?

Exhibit

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet1",
    "type": "iana-if-type:ethernetCsmacd",
    "enabled": true,
    "ietf-ip:ipv4": {
      "address": [
        {
          "ip": "192.168.1.1",
          "netmask": "255.255.255.0"
        }
      ]
    }
  }
}

Trap 1: The script is not authenticated

A RESTCONF server must authenticate every request before processing; if the script lacked credentials, the server would respond with 401 Unauthorized, and the payload would never be processed. The HTTP 201 Created status in the exhibit is definitive proof that the request's authentication (e.g., HTTP Basic, token, or client certificate) was accepted and the resource was created. An unauthenticated client cannot receive a 201, so this is not the cause of the failure.

Trap 2: The URI should be…

When using POST to create a new list entry, RESTCONF targets the collection URL—here /restconf/data/ietf-interfaces:interfaces/interface—and the new instance's key is supplied in the JSON payload, not as a path suffix. A URL with `interface=GigabitEthernet1` would address an existing resource and would be correct for a PUT, PATCH, or DELETE, but not for a POST create. The exhibit's URI is therefore the correct endpoint for the request being made, so this is not the problem.

Trap 3: The JSON syntax is invalid

The exhibit's payload is well-formed JSON; all braces, brackets, quotes, and commas align correctly, so a JSON parser will accept it without error. RESTCONF distinguishes between a parse error and a YANG validation error: a syntax problem would trigger an `invalid-json` error before any data-model processing, whereas the observed failure occurs during semantic validation. Thus, invalid JSON cannot be the cause given the error type described.

A
The script is not authenticated
Why it fails: A RESTCONF server must authenticate every request before processing; if the script lacked credentials, the server would respond with 401 Unauthorized, and the payload would never be processed. The HTTP 201 Created status in the exhibit is definitive proof that the request's authentication (e.g., HTTP Basic, token, or client certificate) was accepted and the resource was created. An unauthenticated client cannot receive a 201, so this is not the cause of the failure.
B
The URI should be /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1
Why it fails: When using POST to create a new list entry, RESTCONF targets the collection URL—here /restconf/data/ietf-interfaces:interfaces/interface—and the new instance's key is supplied in the JSON payload, not as a path suffix. A URL with `interface=GigabitEthernet1` would address an existing resource and would be correct for a PUT, PATCH, or DELETE, but not for a POST create. The exhibit's URI is therefore the correct endpoint for the request being made, so this is not the problem.
C
The payload is missing a required field for the interface
RESTCONF validates every payload against the target YANG data model, and mandatory nodes must be present even for a valid POST. The given payload omits one or more required leafs—such as `type` in the standard ietf-interfaces model, or a model-specific `description` when defined as mandatory—causing the server to return a 400 Bad Request with a `data-missing` error path. This is a content-model problem, not an authentication, URL, or JSON-syntax problem, making it the correct reason for the failure.
D
The JSON syntax is invalid
Why it fails: The exhibit's payload is well-formed JSON; all braces, brackets, quotes, and commas align correctly, so a JSON parser will accept it without error. RESTCONF distinguishes between a parse error and a YANG validation error: a syntax problem would trigger an `invalid-json` error before any data-model processing, whereas the observed failure occurs during semantic validation. Thus, invalid JSON cannot be the cause given the error type described.

Read the full REST/YANG explanation →

Question 7hardmultiple choice

A service provider uses Cisco IOS XE routers with NETCONF/YANG for configuration management. They have a centralized automation system that pushes configuration changes via NETCONF. Recently, after a maintenance window, several routers lost connectivity to the NETCONF server. The automation system can still SSH to the routers and execute CLI commands. The engineer suspects that the NETCONF server's SSH key changed, causing the routers to reject the connection. However, checking the routers' configuration, the engineer finds that the 'netconf ssh' command is present and the SSH server is enabled. The engineer also notices that the routers have an 'ip ssh server algorithm publickey' configuration specifying a list of allowed public keys. What is the most likely cause of the NETCONF connectivity loss?

Trap 1: The NETCONF server is using a non-standard port

The NETCONF over SSH transport uses the well-known TCP port 830 (or occasionally port 22) on Cisco IOS XE. Since the administrator can successfully open an interactive SSH session, the router is definitely listening on the standard SSH port, meaning the NETCONF client is also reaching the correct port. A non-standard port would cause a TCP connection failure before any SSH handshake, which is not the symptom observed here.

Trap 2: The routers have reached the maximum number of SSH sessions

IOS XE routers have a finite number of VTY lines and concurrent SSH session limits, but those limits apply uniformly to all SSH sessions, including interactive ones. The existing SSH session used by the administrator is working, which proves the router has not exhausted its available SSH session slots. If the maximum had been reached, even the interactive SSH login would fail, so this option cannot explain a failure that only affects the NETCONF client.

Trap 3: The 'netconf ssh' command was removed from the router configuration

The `netconf ssh` command explicitly enables the NETCONF server over SSH on IOS XE, and the command is still present in the router configuration. Therefore, the NETCONF feature itself is active and listening for connections. The failure must be occurring at a lower layer, such as the SSH transport or authentication, rather than because the service is disabled.

A
The NETCONF server is using a non-standard port
Why it fails: The NETCONF over SSH transport uses the well-known TCP port 830 (or occasionally port 22) on Cisco IOS XE. Since the administrator can successfully open an interactive SSH session, the router is definitely listening on the standard SSH port, meaning the NETCONF client is also reaching the correct port. A non-standard port would cause a TCP connection failure before any SSH handshake, which is not the symptom observed here.
B
The routers have reached the maximum number of SSH sessions
Why it fails: IOS XE routers have a finite number of VTY lines and concurrent SSH session limits, but those limits apply uniformly to all SSH sessions, including interactive ones. The existing SSH session used by the administrator is working, which proves the router has not exhausted its available SSH session slots. If the maximum had been reached, even the interactive SSH login would fail, so this option cannot explain a failure that only affects the NETCONF client.
C
The NETCONF server's SSH public key is not in the allowed list on the routers
In SSH, the client must verify the server's identity by checking the server's public host key against a trusted list, such as a known_hosts file or a configured host-key algorithm policy. The NETCONF client on the NMS may be configured to allow only specific server public key algorithms or hashes, and the router's host key does not match that allowlist. This causes the SSH transport handshake to fail during the key-exchange phase, before any NETCONF capability exchange, while interactive SSH sessions still succeed because they use a different, less strict verification path.
D
The 'netconf ssh' command was removed from the router configuration
Why it fails: The `netconf ssh` command explicitly enables the NETCONF server over SSH on IOS XE, and the command is still present in the router configuration. Therefore, the NETCONF feature itself is active and listening for connections. The failure must be occurring at a lower layer, such as the SSH transport or authentication, rather than because the service is disabled.

Read the full Ansible explanation →

Question 8mediummultiple choice

A network engineer is automating configuration backups using Ansible. The playbook uses the ios_config module to retrieve running configurations from Cisco IOS XE devices. However, the playbook fails with a timeout error on a specific device. Other devices respond correctly. What is the most likely cause of the failure?

Trap 1: The device is configured for HTTP/HTTPS access only.

The ios_config module in Ansible uses the network_cli connection plugin, which establishes an SSH session to the device for executing configuration commands. A device that accepts HTTP/HTTPS only cannot be managed through this module, but the failure would occur at the transport layer (connection refused or unreachable), not as an authentication timeout from incorrect vault credentials. Since the scenario points to an SSH authentication failure, an HTTP/HTTPS-only configuration would not be the underlying cause.

Trap 2: The device has NetFlow enabled, consuming CPU cycles.

NetFlow consumes CPU cycles to export flow records, but this traffic is handled by the data plane and the forwarding engine, while SSH management sessions are processed by the control/management plane with typically lower CPU priority. Although high CPU utilization can cause delayed responses, the presence of NetFlow alone does not invalidate SSH credentials or cause an authentication failure. The timeout in this scenario stems from vault credentials, not from data-plane CPU load.

Trap 3: The device has SNMPv3 enabled with authentication traps.

SNMPv3 with authentication traps sends notifications via UDP to a management station when auth failures occur; these traps are independent of the SSH transport that Ansible uses for ios_config. Enabling SNMPv3 authentication traps does not alter SSH credential validation, nor does it block the management plane. Therefore, this would be an unrelated monitoring feature, not the reason for an SSH-based backup timeout.

A
The device is configured for HTTP/HTTPS access only.
Why it fails: The ios_config module in Ansible uses the network_cli connection plugin, which establishes an SSH session to the device for executing configuration commands. A device that accepts HTTP/HTTPS only cannot be managed through this module, but the failure would occur at the transport layer (connection refused or unreachable), not as an authentication timeout from incorrect vault credentials. Since the scenario points to an SSH authentication failure, an HTTP/HTTPS-only configuration would not be the underlying cause.
B
The device has incorrect SSH credentials configured in the Ansible vault.
Ansible vault stores the SSH username and password (or enable secret) in encrypted form; when the playbook runs, it decrypts these values and presents them to the device for SSH login and privilege escalation. If the vault has stale or incorrect credentials, SSH authentication fails, and Ansible's default retry behavior (with SSH timeouts) makes the task eventually fail with a timeout. This precisely matches the symptom of a configuration backup timeout, making it the correct explanation.
C
The device has NetFlow enabled, consuming CPU cycles.
Why it fails: NetFlow consumes CPU cycles to export flow records, but this traffic is handled by the data plane and the forwarding engine, while SSH management sessions are processed by the control/management plane with typically lower CPU priority. Although high CPU utilization can cause delayed responses, the presence of NetFlow alone does not invalidate SSH credentials or cause an authentication failure. The timeout in this scenario stems from vault credentials, not from data-plane CPU load.
D
The device has SNMPv3 enabled with authentication traps.
Why it fails: SNMPv3 with authentication traps sends notifications via UDP to a management station when auth failures occur; these traps are independent of the SSH transport that Ansible uses for ios_config. Enabling SNMPv3 authentication traps does not alter SSH credential validation, nor does it block the management plane. Therefore, this would be an unrelated monitoring feature, not the reason for an SSH-based backup timeout.

Read the full REST/YANG explanation →

Question 9easymultiple choice

Refer to the exhibit. A network engineer sends a RESTCONF PATCH request with the above JSON payload to the URL https://192.168.1.100/restconf/data/ietf-interfaces:interface=GigabitEthernet0/0/0. What is the expected outcome?

Exhibit

Refer to the exhibit.
{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/0/0",
    "description": "Link to Core",
    "enabled": true,
    "ietf-ip:ipv4": {
      "address": [
        {
          "ip": "192.168.1.1",
          "netmask": "255.255.255.0"
        }
      ]
    }
  }
}

Trap 1: A new interface GigabitEthernet0/0/0 is created with the specified…

RESTCONF PATCH targets an existing resource URI; it does not create a new interface. If GigabitEthernet0/0/0 were not present, the server would return a 404 Not Found rather than instantiate it. Creating a new interface would require POST to the interface collection or a PUT with the ?create option.

Trap 2: The request fails because a GET request must be sent first to…

RESTCONF does not impose any prerequisite GET before a PATCH; the server operates directly on the current datastore contents. The optional 'if-match' header uses an ETag from a previous GET for concurrency protection, but omitting it simply allows the PATCH to proceed. A GET is only needed if the client explicitly wants to inspect the current values or obtain a condition for optimistic locking, not as a mandatory step.

Trap 3: The entire interface configuration is replaced with only the fields…

Replacing the entire interface configuration with the payload is the behavior of the PUT method, not PATCH. In RESTCONF RFC 8040, PATCH is defined with an 'update' operation that merges the payload field-by-field, leaving any unspecified nodes, such as MTU or 'enabled', intact. Consequently, sending only the description and IP address cannot wipe the rest of the interface; any fields omitted from the payload remain in effect.

A
A new interface GigabitEthernet0/0/0 is created with the specified IP address.
Why it fails: RESTCONF PATCH targets an existing resource URI; it does not create a new interface. If GigabitEthernet0/0/0 were not present, the server would return a 404 Not Found rather than instantiate it. Creating a new interface would require POST to the interface collection or a PUT with the ?create option.
B
The description and IP address of the existing interface are updated, and the interface remains enabled.
A RESTCONF PATCH performs a merge operation on the existing configuration resource, so only the supplied nodes—'description' and 'ip address'—are modified. Because the payload does not include the 'enabled' node, the interface's shutdown/admin state is preserved. The URI identifies the existing interface, so no resource creation or deletion occurs; the result is an updated interface that remains up.
C
The request fails because a GET request must be sent first to retrieve the current configuration.
Why it fails: RESTCONF does not impose any prerequisite GET before a PATCH; the server operates directly on the current datastore contents. The optional 'if-match' header uses an ETag from a previous GET for concurrency protection, but omitting it simply allows the PATCH to proceed. A GET is only needed if the client explicitly wants to inspect the current values or obtain a condition for optimistic locking, not as a mandatory step.
D
The entire interface configuration is replaced with only the fields in the payload.
Why it fails: Replacing the entire interface configuration with the payload is the behavior of the PUT method, not PATCH. In RESTCONF RFC 8040, PATCH is defined with an 'update' operation that merges the payload field-by-field, leaving any unspecified nodes, such as MTU or 'enabled', intact. Consequently, sending only the description and IP address cannot wipe the rest of the interface; any fields omitted from the payload remain in effect.

Read the full Automation explanation →

Question 10mediumdrag order

Drag and drop the steps for the three-way TCP handshake into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Client sends SYN, client sends ACK, server sends SYN-ACK

This ordering is invalid because the client's ACK is sent before the server has transmitted its SYN-ACK, so the client cannot possibly acknowledge the server's sequence number. The server's SYN-ACK is a response to the initial SYN and must precede any ACK from the client. Without receiving the server's ISN first, the ACK would be meaningless and could not be processed.

Trap 2: Server sends SYN-ACK, client sends SYN, client sends ACK

The server cannot issue a SYN-ACK as the first step because it is responding to a client-initiated SYN; the handshake is always client-driven. Placing the server's SYN-ACK before the client's SYN violates the dependency, as the server would be acknowledging a SYN it never received. Additionally, by the time the client sends its SYN, it would be starting a new handshake after the server has already committed to a connection state.

Trap 3: Client sends ACK, client sends SYN, server sends SYN-ACK

An ACK segment cannot be the first packet of a handshake because it requires an existing sequence number to acknowledge; the client has not yet learned the server's ISN or even sent its own. The handshake must begin with a SYN to synchronize sequence numbers, and the ACK is only valid after both sides have exchanged SYN/SYN-ACK. Sending an ACK first is not only out of order but also lies outside TCP's state machine, which expects a SYN to initiate the LISTEN-to-SYN_SENT transition.

A
Client sends SYN, server responds with SYN-ACK, client sends ACK
The client starts by sending a SYN segment with an initial sequence number (ISN) to the server, which is necessary because the server must know the client's starting sequence number. The server then responds with a SYN-ACK that acknowledges the client's SYN and provides the server's own ISN. Finally, the client sends an ACK to acknowledge the server's ISN, completing the handshake and allowing both sides to synchronize sequence numbers and open the connection for data transfer.
B
Client sends SYN, client sends ACK, server sends SYN-ACK
Why it fails: This ordering is invalid because the client's ACK is sent before the server has transmitted its SYN-ACK, so the client cannot possibly acknowledge the server's sequence number. The server's SYN-ACK is a response to the initial SYN and must precede any ACK from the client. Without receiving the server's ISN first, the ACK would be meaningless and could not be processed.
C
Server sends SYN-ACK, client sends SYN, client sends ACK
Why it fails: The server cannot issue a SYN-ACK as the first step because it is responding to a client-initiated SYN; the handshake is always client-driven. Placing the server's SYN-ACK before the client's SYN violates the dependency, as the server would be acknowledging a SYN it never received. Additionally, by the time the client sends its SYN, it would be starting a new handshake after the server has already committed to a connection state.
D
Client sends ACK, client sends SYN, server sends SYN-ACK
Why it fails: An ACK segment cannot be the first packet of a handshake because it requires an existing sequence number to acknowledge; the client has not yet learned the server's ISN or even sent its own. The handshake must begin with a SYN to synchronize sequence numbers, and the ACK is only valid after both sides have exchanged SYN/SYN-ACK. Sending an ACK first is not only out of order but also lies outside TCP's state machine, which expects a SYN to initiate the LISTEN-to-SYN_SENT transition.

Study the full ACL explanation →

Question 11mediumdrag order

Which of the following represents the correct order of steps to configure an extended access control list (ACL) on a Cisco router?

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Step 1: Enter global configuration mode

This order is incorrect because the access-list command is only available in global configuration mode, not in interface configuration mode. You would have to exit interface mode to create the ACL, making this sequence inefficient and error-prone.

Trap 2: Step 1: Enter global configuration mode

This order is incorrect because the ip access-group command is an interface configuration command; it cannot be executed until you are in interface configuration mode. Applying the ACL before entering interface mode would result in a syntax error.

Trap 3: Step 2: Create extended ACL statements using the access-list…

This sequence fails because the `access-list` command is not recognized until you are in global configuration mode; IOS only accepts it when the prompt ends with `(config)#`. Trying to enter the ACL statement before switching to global configuration mode (from privileged EXEC `#`) will produce an `% Invalid input detected` error, so the ACL definition is never actually created. Even if you later enter interface configuration mode, the `ip access-group` command will fail because the referenced ACL number does not exist in the running configuration. The correct approach is to first enter global configuration mode, then define the ACL, and only then enter interface configuration mode to apply it.

A
Step 1: Enter global configuration mode. Step 2: Create extended ACL statements using the access-list command. Step 3: Enter interface configuration mode. Step 4: Apply the ACL to the interface using the ip access-group command.
This is the only valid sequence because Cisco IOS parses the `access-list` command exclusively in global configuration mode. You must first enter global configuration mode with `configure terminal`, define the extended ACL parameters (e.g., `access-list 101 permit tcp any host 192.168.1.10 eq 80`) before any interface-level reference can exist. After the ACL is created, you enter interface configuration mode (`interface GigabitEthernet0/1`) and bind the ACL to that interface using `ip access-group 101 in`. If you attempt to apply an undefined ACL, IOS will reject the command with an error, so the definition must precede the application.
B
Step 1: Enter global configuration mode. Step 3: Enter interface configuration mode. Step 2: Create extended ACL statements using the access-list command. Step 4: Apply the ACL to the interface using the ip access-group command.
Why it fails: This order is incorrect because the access-list command is only available in global configuration mode, not in interface configuration mode. You would have to exit interface mode to create the ACL, making this sequence inefficient and error-prone.
C
Step 1: Enter global configuration mode. Step 2: Create extended ACL statements using the access-list command. Step 4: Apply the ACL to the interface using the ip access-group command. Step 3: Enter interface configuration mode.
Why it fails: This order is incorrect because the ip access-group command is an interface configuration command; it cannot be executed until you are in interface configuration mode. Applying the ACL before entering interface mode would result in a syntax error.
D
Step 2: Create extended ACL statements using the access-list command. Step 1: Enter global configuration mode. Step 3: Enter interface configuration mode. Step 4: Apply the ACL to the interface using the ip access-group command.
Why it fails: This sequence fails because the `access-list` command is not recognized until you are in global configuration mode; IOS only accepts it when the prompt ends with `(config)#`. Trying to enter the ACL statement before switching to global configuration mode (from privileged EXEC `#`) will produce an `% Invalid input detected` error, so the ACL definition is never actually created. Even if you later enter interface configuration mode, the `ip access-group` command will fail because the referenced ACL number does not exist in the running configuration. The correct approach is to first enter global configuration mode, then define the ACL, and only then enter interface configuration mode to apply it.

Question 12mediummultiple choice

A network engineer is using the Python ncclient library to retrieve the running configuration from a Cisco IOS XE device via NETCONF. The script connects successfully, but the <get-config> RPC returns an empty <data> element even though the requested configuration clearly exists on the device. The engineer confirms the correct datastore is targeted. Which action should the engineer take to resolve this?

Trap 1: Add a <with-defaults> capability element to the RPC to include…

The <with-defaults> capability controls inclusion of default values, not the entire configuration. If the target configuration is explicitly configured (non-default), omitting with-defaults would not make it disappear. The empty response indicates no matching nodes were returned, so this change would not resolve the root cause.

Trap 2: Switch the transport from SSH to TLS by using the ncclient…

NETCONF typically runs over SSH (port 830); TLS is used for RESTCONF. Changing transport to TLS would likely break connectivity because the device is not listening for NETCONF over TLS on that port. The empty data is not caused by the transport type, and switching would not populate the response.

Trap 3: Increase the SSH timeout value in the ncclient connect parameters…

A timeout would produce an exception or incomplete data, not a successful RPC with an empty <data> element. The issue is not related to connection duration; the device responded, so increasing the timeout would not change the content of the reply and would leave the empty result unchanged.

A
Add a <with-defaults> capability element to the RPC to include default configuration values.
Why it fails: The <with-defaults> capability controls inclusion of default values, not the entire configuration. If the target configuration is explicitly configured (non-default), omitting with-defaults would not make it disappear. The empty response indicates no matching nodes were returned, so this change would not resolve the root cause.
B
Specify a subtree filter in the <get-config> RPC that matches the desired configuration hierarchy.
Without a filter, NETCONF <get-config> should return the entire datastore, but some implementations or the script may be using an empty filter that matches nothing. Providing a proper subtree filter scoped to the configuration branch (e.g., native/interface) ensures the device returns the relevant nodes, resolving the empty data issue.
C
Switch the transport from SSH to TLS by using the ncclient 'transport' parameter.
Why it fails: NETCONF typically runs over SSH (port 830); TLS is used for RESTCONF. Changing transport to TLS would likely break connectivity because the device is not listening for NETCONF over TLS on that port. The empty data is not caused by the transport type, and switching would not populate the response.
D
Increase the SSH timeout value in the ncclient connect parameters to allow more time for the response.
Why it fails: A timeout would produce an exception or incomplete data, not a successful RPC with an empty <data> element. The issue is not related to connection duration; the device responded, so increasing the timeout would not change the content of the reply and would leave the empty result unchanged.

Question 13hardmultiple choice

A network engineer is writing a Python script that uses the requests library to interact with a Cisco IOS XE device via RESTCONF. The script authenticates with basic authentication and sends a GET request to retrieve interface statistics. The device returns a 401 Unauthorized error even though the username and password are correct and have privilege level 15. Which configuration is most likely missing on the device?

Trap 1: The 'ip http secure-server' command must be disabled to allow basic…

Disabling the secure server would force HTTP, but basic authentication works over both HTTP and HTTPS. The 401 is not caused by HTTPS being enabled; in fact, RESTCONF typically uses HTTPS. Disabling secure server would reduce security and not address the authentication failure.

Trap 2: The RESTCONF API must be enabled with the 'restconf' global…

If RESTCONF were not enabled, the connection would likely be refused or return a different error, not 401. The 401 indicates authentication failure, not service unavailability. Enabling restconf is necessary for RESTCONF to function, but the symptom of missing restconf is typically connection failure or 404, not 401.

Trap 3: The user account must be configured with the 'username <name>…

The user already has privilege 15 and correct credentials. The issue is not the user configuration itself but the HTTP server's authentication method. Without 'ip http authentication local', the device may use a different method (e.g., AAA) that rejects basic credentials, leading to 401.

A
The 'ip http secure-server' command must be disabled to allow basic authentication over HTTP.
Why it fails: Disabling the secure server would force HTTP, but basic authentication works over both HTTP and HTTPS. The 401 is not caused by HTTPS being enabled; in fact, RESTCONF typically uses HTTPS. Disabling secure server would reduce security and not address the authentication failure.
B
The RESTCONF API must be enabled with the 'restconf' global configuration command.
Why it fails: If RESTCONF were not enabled, the connection would likely be refused or return a different error, not 401. The 401 indicates authentication failure, not service unavailability. Enabling restconf is necessary for RESTCONF to function, but the symptom of missing restconf is typically connection failure or 404, not 401.
C
The HTTP server must be enabled with the 'ip http server' command, and the user must have the 'privilege 15' and 'ip http authentication local' configured.
RESTCONF on IOS XE relies on the HTTP server. A 401 Unauthorized often occurs when the HTTP server is disabled or authentication is not set to local. Enabling 'ip http server' and ensuring 'ip http authentication local' with a privilege 15 user allows basic authentication to succeed, resolving the 401 error.
D
The user account must be configured with the 'username <name> privilege 15 secret <password>' command and no other authentication method.
Why it fails: The user already has privilege 15 and correct credentials. The issue is not the user configuration itself but the HTTP server's authentication method. Without 'ip http authentication local', the device may use a different method (e.g., AAA) that rejects basic credentials, leading to 401.

Question 14mediummultiple choice

A network engineer is building a Python script to retrieve interface statistics from a Cisco IOS XE device using the RESTCONF API. The device is configured with the 'restconf' and 'netconf-yang' commands. The engineer sends a GET request to https://10.1.1.1/restconf/data/ietf-interfaces:interfaces-state/interface=GigabitEthernet1 and receives a 404 Not Found error. The interface GigabitEthernet1 exists and is up. What is the most likely cause of the error?

Trap 1: The URI is incorrect because RESTCONF uses a different path for…

The error is a 404, indicating the resource path is not found. The suggested URI adds '/statistics', which is not the root cause. The correct base path for operational data is indeed interfaces-state, but the issue is likely the missing 'operational' distinction or incorrect module. This option misleads by suggesting a deeper path, but the device would return 404 if the path is wrong regardless of depth.

Trap 2: The interface name in the URI is case-sensitive and must match the…

RESTCONF URIs are case-sensitive, but the example uses 'GigabitEthernet1' with correct casing. If casing were wrong, the error would still be 404, but the scenario states the interface exists and is up, implying correct name. This option is a distractor because it introduces a plausible but irrelevant detail; the actual issue is likely the data store (config vs. operational).

Trap 3: The RESTCONF API requires the 'Accept: application/yang-data+json'…

Missing or incorrect Accept headers typically result in a 406 Not Acceptable error, not 404. The 404 indicates the resource itself is not found. While headers are important for content negotiation, they do not cause a 404. This option confuses error codes, and the scenario does not mention headers, so it is not the primary cause.

A
The engineer is querying operational data, but the device's RESTCONF implementation only supports configuration data by default, requiring the 'operational' query parameter.
In Cisco IOS XE, RESTCONF supports both configuration and operational data, but operational data is accessed via the 'interfaces-state' container. However, some implementations require the '?content=nonconfig' query parameter or the use of the 'ietf-interfaces:interfaces-state' path correctly. The 404 suggests the path is incorrect; the correct operational path is '/restconf/data/ietf-interfaces:interfaces-state/interface=GigabitEthernet1'. This option correctly identifies that operational data may need specific handling.
B
The URI is incorrect because RESTCONF uses a different path for operational data, such as /restconf/data/ietf-interfaces:interfaces-state/interface=GigabitEthernet1/statistics.
Why it fails: The error is a 404, indicating the resource path is not found. The suggested URI adds '/statistics', which is not the root cause. The correct base path for operational data is indeed interfaces-state, but the issue is likely the missing 'operational' distinction or incorrect module. This option misleads by suggesting a deeper path, but the device would return 404 if the path is wrong regardless of depth.
C
The interface name in the URI is case-sensitive and must match the device's exact casing, such as 'GigabitEthernet1' instead of 'GigabitEthernet1'.
Why it fails: RESTCONF URIs are case-sensitive, but the example uses 'GigabitEthernet1' with correct casing. If casing were wrong, the error would still be 404, but the scenario states the interface exists and is up, implying correct name. This option is a distractor because it introduces a plausible but irrelevant detail; the actual issue is likely the data store (config vs. operational).
D
The RESTCONF API requires the 'Accept: application/yang-data+json' header, and without it, the server returns a 404 error.
Why it fails: Missing or incorrect Accept headers typically result in a 406 Not Acceptable error, not 404. The 404 indicates the resource itself is not found. While headers are important for content negotiation, they do not cause a 404. This option confuses error codes, and the scenario does not mention headers, so it is not the primary cause.

Question 15hardmultiple choice

A network automation team is using a Python script with the ncclient library to configure a Cisco IOS XE device via NETCONF. The script sends an <edit-config> RPC with a candidate datastore and then commits the configuration. After running the script, the team notices that the configuration changes are not present in the running configuration. The script completes without errors. Which is the most likely cause?

Trap 1: The NETCONF session was not closed properly, so the commit was not…

Closing a NETCONF session does not affect the commit operation. The commit is a separate RPC that must be explicitly sent. If the session is closed without committing, the changes remain in the candidate datastore but are not applied to the running configuration. However, the script likely sends the commit; the issue is more specific to the commit operation itself.

Trap 2: The device does not support the candidate datastore, so the…

If the device does not support the candidate datastore, the <edit-config> targeting the candidate would fail with an error, not silently apply to the running datastore. Cisco IOS XE supports the candidate datastore when NETCONF is enabled with the appropriate capability. The script completing without errors suggests the candidate datastore is supported, but the commit step may be missing.

Trap 3: The <commit> RPC was sent to the wrong datastore, such as the…

The <commit> RPC does not require a datastore parameter; it always commits the candidate datastore to the running datastore. Sending it to a different datastore is not possible. The problem is not about targeting the wrong datastore for the commit, but rather about whether the commit was successfully executed or if there were underlying issues with the candidate configuration.

A
The script did not send a <commit> RPC after the <edit-config> operation, so the candidate configuration was not applied to the running configuration.
When using the candidate datastore, changes are made to the candidate configuration and must be explicitly committed to the running configuration using a <commit> RPC. If the script omits this step, the changes remain in the candidate datastore and are not reflected in the running configuration, even though no errors occur. This matches the scenario perfectly.
B
The NETCONF session was not closed properly, so the commit was not applied.
Why it fails: Closing a NETCONF session does not affect the commit operation. The commit is a separate RPC that must be explicitly sent. If the session is closed without committing, the changes remain in the candidate datastore but are not applied to the running configuration. However, the script likely sends the commit; the issue is more specific to the commit operation itself.
C
The device does not support the candidate datastore, so the <edit-config> was applied to the running datastore instead.
Why it fails: If the device does not support the candidate datastore, the <edit-config> targeting the candidate would fail with an error, not silently apply to the running datastore. Cisco IOS XE supports the candidate datastore when NETCONF is enabled with the appropriate capability. The script completing without errors suggests the candidate datastore is supported, but the commit step may be missing.
D
The <commit> RPC was sent to the wrong datastore, such as the running datastore instead of the candidate datastore.
Why it fails: The <commit> RPC does not require a datastore parameter; it always commits the candidate datastore to the running datastore. Sending it to a different datastore is not possible. The problem is not about targeting the wrong datastore for the commit, but rather about whether the commit was successfully executed or if there were underlying issues with the candidate configuration.

Question 16mediummultiple choice

A network engineer is using the Python ncclient library to retrieve interface statistics from a Cisco IOS XE device. The script connects successfully but the returned data is a large XML document that is difficult to parse. The engineer wants to work with data in a structured, vendor-neutral format that can be validated against a model. Which action should be taken to achieve this?

Trap 1: Switch from NETCONF to RESTCONF and request the data in JSON format…

While RESTCONF supports JSON, the scenario specifies that the engineer is already using NETCONF. Switching protocols may not be feasible or desired. Moreover, RESTCONF also relies on YANG models for structure; simply switching to RESTCONF does not inherently provide vendor-neutral modeling unless YANG is used. This option is a distraction because it changes the protocol rather than addressing the core issue of data structure.

Trap 2: Convert the NETCONF RPC reply from XML to JSON using the ncclient…

The ncclient library does not provide a to_json() method to convert XML replies. While JSON is structured, NETCONF natively returns XML, and ncclient does not automatically transform it. The engineer would need to manually parse XML or use a separate library, but this does not address the need for a vendor-neutral model. This option is incorrect because it assumes a non-existent feature.

Trap 3: Enable the 'format json' option in the NETCONF hello message to…

NETCONF does not support a 'format json' option in the hello message. NETCONF messages are always XML-encoded. JSON is not a valid encoding for NETCONF. This option is incorrect because it misrepresents the NETCONF protocol capabilities. The engineer cannot request JSON via NETCONF; XML is the only supported format.

A
Switch from NETCONF to RESTCONF and request the data in JSON format using the Accept: application/json header.
Why it fails: While RESTCONF supports JSON, the scenario specifies that the engineer is already using NETCONF. Switching protocols may not be feasible or desired. Moreover, RESTCONF also relies on YANG models for structure; simply switching to RESTCONF does not inherently provide vendor-neutral modeling unless YANG is used. This option is a distraction because it changes the protocol rather than addressing the core issue of data structure.
B
Use the YANG models supported by the device to filter and structure the data, then parse the XML using the model's schema.
YANG models define the structure and semantics of the data returned by NETCONF. By leveraging the YANG models, the engineer can filter the XML output and parse it according to the model's schema, resulting in structured, vendor-neutral data. This approach is standard for NETCONF and enables validation and easier integration with other systems. It directly addresses the difficulty of parsing raw XML.
C
Convert the NETCONF RPC reply from XML to JSON using the ncclient library's built-in to_json() method.
Why it fails: The ncclient library does not provide a to_json() method to convert XML replies. While JSON is structured, NETCONF natively returns XML, and ncclient does not automatically transform it. The engineer would need to manually parse XML or use a separate library, but this does not address the need for a vendor-neutral model. This option is incorrect because it assumes a non-existent feature.
D
Enable the 'format json' option in the NETCONF hello message to receive JSON-encoded responses.
Why it fails: NETCONF does not support a 'format json' option in the hello message. NETCONF messages are always XML-encoded. JSON is not a valid encoding for NETCONF. This option is incorrect because it misrepresents the NETCONF protocol capabilities. The engineer cannot request JSON via NETCONF; XML is the only supported format.

Study the full SD-WAN breakdown →

Question 17mediummultiple choice

A network engineer is using the Cisco SD-WAN vManage REST API to retrieve a list of devices. The API requires authentication via a session token. The engineer successfully obtains a token using the /j_security_check endpoint but then receives a 403 Forbidden error when calling /dataservice/device. What is the most likely cause?

Trap 1: The engineer must use HTTP Basic Authentication instead of…

vManage REST API supports session-based authentication via /j_security_check. Basic authentication is not the standard method and may not be enabled. The engineer already obtained a token, so switching to basic auth is unnecessary and would not address the missing cookie issue.

Trap 2: The engineer must use the /dataservice/client/token endpoint to…

The /dataservice/client/token endpoint provides a CSRF token for certain write operations, but it is not the primary authentication mechanism. The 403 error here is due to missing session cookie, not CSRF. Using this endpoint alone without the session cookie would not authenticate the request.

Trap 3: The API call must use the POST method instead of GET to retrieve…

The /dataservice/device endpoint uses GET to retrieve data. Changing to POST would not resolve a 403 error; it would likely return a 405 Method Not Allowed. The 403 indicates authorization failure due to missing authentication credentials, not an incorrect HTTP method.

A
The engineer must use HTTP Basic Authentication instead of session-based authentication.
Why it fails: vManage REST API supports session-based authentication via /j_security_check. Basic authentication is not the standard method and may not be enabled. The engineer already obtained a token, so switching to basic auth is unnecessary and would not address the missing cookie issue.
B
The engineer must use the /dataservice/client/token endpoint to obtain a CSRF token and include it as a header.
Why it fails: The /dataservice/client/token endpoint provides a CSRF token for certain write operations, but it is not the primary authentication mechanism. The 403 error here is due to missing session cookie, not CSRF. Using this endpoint alone without the session cookie would not authenticate the request.
C
The token is not included in the request headers as a cookie named JSESSIONID.
vManage uses session-based authentication. After login via /j_security_check, the server returns a JSESSIONID cookie. Subsequent API calls must include this cookie in the request headers. If omitted, the server treats the request as unauthenticated and returns 403 Forbidden. Including the cookie resolves the error.
D
The API call must use the POST method instead of GET to retrieve device information.
Why it fails: The /dataservice/device endpoint uses GET to retrieve data. Changing to POST would not resolve a 403 error; it would likely return a 405 Method Not Allowed. The 403 indicates authorization failure due to missing authentication credentials, not an incorrect HTTP method.

Study the full SD-WAN breakdown →

Question 18mediummultiple choice

A network engineer is using the Cisco SD-WAN vManage REST API to retrieve a list of all devices managed by the controller. The engineer sends a GET request to https://vmanage.example.com:8443/dataservice/device with the header 'Accept: application/json' and receives an HTTP 200 OK response containing a JSON payload. The engineer now needs to extract only the device IDs of the devices that are in a 'reachable' state. Which Python code snippet correctly parses the response and filters the devices?

Trap 1: import requests response =…

The vManage API does not use a 'devices' key; it uses 'data'. Also, device identifiers are under 'deviceId', not 'id', and the reachability field is 'reachability', not 'status'. Using incorrect keys will cause a KeyError or return no results. This snippet would fail to extract the desired information from the actual API response.

Trap 2: import requests response =…

The field indicating reachability in the vManage API is 'reachability', not 'status'. Using 'status' will either raise a KeyError or result in an empty list because the condition never matches. The device ID extraction is correct, but the filter field is wrong, so it fails to identify reachable devices.

Trap 3: import requests response =…

This code iterates over the top-level JSON object instead of the 'data' list. Since the top-level object is a dictionary, iterating yields keys as strings, and attempting to access 'deviceId' on a string will raise a TypeError. The correct approach is to access the 'data' key first to get the list of devices.

A
import requests response = requests.get('https://vmanage.example.com:8443/dataservice/device', headers={'Accept': 'application/json'}, verify=False) data = response.json() reachable_devices = [dev['deviceId'] for dev in data['data'] if dev['reachability'] == 'reachable']
The vManage API returns a JSON object with a 'data' key containing a list of device dictionaries. Each device dictionary includes 'deviceId' and 'reachability' fields. The list comprehension iterates over data['data'], filters those with reachability equal to 'reachable', and extracts deviceId. This matches the actual API response structure, so it correctly parses and filters the devices.
B
import requests response = requests.get('https://vmanage.example.com:8443/dataservice/device', headers={'Accept': 'application/json'}, verify=False) data = response.json() reachable_devices = [dev['id'] for dev in data['devices'] if dev['status'] == 'up']
Why it fails: The vManage API does not use a 'devices' key; it uses 'data'. Also, device identifiers are under 'deviceId', not 'id', and the reachability field is 'reachability', not 'status'. Using incorrect keys will cause a KeyError or return no results. This snippet would fail to extract the desired information from the actual API response.
C
import requests response = requests.get('https://vmanage.example.com:8443/dataservice/device', headers={'Accept': 'application/json'}, verify=False) data = response.json() reachable_devices = [dev['deviceId'] for dev in data['data'] if dev['status'] == 'reachable']
Why it fails: The field indicating reachability in the vManage API is 'reachability', not 'status'. Using 'status' will either raise a KeyError or result in an empty list because the condition never matches. The device ID extraction is correct, but the filter field is wrong, so it fails to identify reachable devices.
D
import requests response = requests.get('https://vmanage.example.com:8443/dataservice/device', headers={'Accept': 'application/json'}, verify=False) data = response.json() reachable_devices = [dev['deviceId'] for dev in data if dev['reachability'] == 'reachable']
Why it fails: This code iterates over the top-level JSON object instead of the 'data' list. Since the top-level object is a dictionary, iterating yields keys as strings, and attempting to access 'deviceId' on a string will raise a TypeError. The correct approach is to access the 'data' key first to get the list of devices.

Question 19mediummulti select

A network engineer is designing a Python script to interact with a Cisco IOS XE device using RESTCONF. The engineer wants to ensure the script can perform both read and write operations on the device's configuration. Which two actions must be taken to enable RESTCONF and allow the script to authenticate? (Choose two.)

Trap 1: Install a CA-signed certificate on the device to enable HTTPS.

While RESTCONF can use HTTPS, a CA-signed certificate is not strictly required for basic operation. The device can use a self-signed certificate, and the script can be configured to ignore certificate validation. The scenario does not specify a requirement for a trusted certificate; the essential steps are enabling RESTCONF and providing credentials.

Trap 2: Configure a YANG model repository on the device to store custom…

A YANG model repository is not a requirement for basic RESTCONF operation. Cisco IOS XE devices come with built-in YANG models for standard configurations. Custom models are only needed for non-standard data, which is not mentioned in the scenario. The script can use the built-in models without any additional repository.

Trap 3: Enable the NETCONF service on the device using the netconf-yang…

The netconf-yang command enables NETCONF, not RESTCONF. While both are YANG-based, they are separate protocols with different transport mechanisms. Enabling NETCONF does not enable RESTCONF, and the script uses RESTCONF, so this action is irrelevant. RESTCONF must be enabled separately.

A
Configure an HTTP client with a valid username and password for authentication.
RESTCONF uses HTTP-based authentication, typically HTTP Basic Authentication. The script must include valid credentials, such as a username and password with appropriate privilege level, to authenticate. Without credentials, the device returns 401 Unauthorized. This is required for both read and write operations.
B
Enable the RESTCONF service on the device using the restconf global configuration command.
The restconf command under global configuration enables the RESTCONF service on Cisco IOS XE. Without this, the device will not listen for RESTCONF requests, and the script will receive connection errors. This is a prerequisite for any RESTCONF interaction, whether for reading or writing configuration data.
C
Install a CA-signed certificate on the device to enable HTTPS.
Why it fails: While RESTCONF can use HTTPS, a CA-signed certificate is not strictly required for basic operation. The device can use a self-signed certificate, and the script can be configured to ignore certificate validation. The scenario does not specify a requirement for a trusted certificate; the essential steps are enabling RESTCONF and providing credentials.
D
Configure a YANG model repository on the device to store custom models.
Why it fails: A YANG model repository is not a requirement for basic RESTCONF operation. Cisco IOS XE devices come with built-in YANG models for standard configurations. Custom models are only needed for non-standard data, which is not mentioned in the scenario. The script can use the built-in models without any additional repository.
E
Enable the NETCONF service on the device using the netconf-yang command.
Why it fails: The netconf-yang command enables NETCONF, not RESTCONF. While both are YANG-based, they are separate protocols with different transport mechanisms. Enabling NETCONF does not enable RESTCONF, and the script uses RESTCONF, so this action is irrelevant. RESTCONF must be enabled separately.

Study the full ACL explanation →

Question 20hardmultiple choice

A network engineer is using Ansible to configure a Cisco IOS XE device. The playbook uses the 'ios_config' module to apply an ACL. The playbook runs successfully, but the ACL is not present on the device. The engineer verifies that the device is reachable and credentials are correct. Which action should the engineer take to troubleshoot the issue?

Trap 1: Add the 'save_when: modified' parameter to the ios_config task to…

The 'save_when' parameter controls when to save the running configuration to startup, but it does not affect whether the configuration is applied to the running configuration. If the ACL is not present, saving would not help. The issue is likely that the configuration was not applied at all, so this parameter is irrelevant to the problem.

Trap 2: Use the 'debug' module to enable debugging on the device and…

Enabling device debugging might show the commands, but it is not the most direct way to troubleshoot Ansible. The 'ios_config' module has a 'backup' option or can be run with increased verbosity. Debugging on the device could impact performance and is not the recommended first step. This option is plausible but less efficient than checking Ansible's output.

Trap 3: Check the device's syslog for errors related to ACL configuration…

Checking syslog is useful, but if the ACL was never sent, there would be no syslog errors. The engineer should first confirm the commands were sent. While verifying the ACL name is good practice, it is not the primary troubleshooting step. This option is a secondary check, not the most effective initial action.

A
Add the 'save_when: modified' parameter to the ios_config task to ensure the configuration is saved to startup.
Why it fails: The 'save_when' parameter controls when to save the running configuration to startup, but it does not affect whether the configuration is applied to the running configuration. If the ACL is not present, saving would not help. The issue is likely that the configuration was not applied at all, so this parameter is irrelevant to the problem.
B
Run the playbook with the '-vvv' flag to enable verbose output and inspect the exact commands sent to the device.
The '-vvv' flag increases Ansible's verbosity, showing the exact commands sent to the device and the responses. This helps identify if the ACL commands were generated and sent correctly. If the commands were sent but not applied, the output might reveal errors or mismatches. This is the most direct troubleshooting step for Ansible playbook issues.
C
Use the 'debug' module to enable debugging on the device and capture the configuration commands sent by Ansible.
Why it fails: Enabling device debugging might show the commands, but it is not the most direct way to troubleshoot Ansible. The 'ios_config' module has a 'backup' option or can be run with increased verbosity. Debugging on the device could impact performance and is not the recommended first step. This option is plausible but less efficient than checking Ansible's output.
D
Check the device's syslog for errors related to ACL configuration and verify that the ACL name matches the one in the playbook.
Why it fails: Checking syslog is useful, but if the ACL was never sent, there would be no syslog errors. The engineer should first confirm the commands were sent. While verifying the ACL name is good practice, it is not the primary troubleshooting step. This option is a secondary check, not the most effective initial action.