CCNA Restconf Questions

Drag & Dropmedium

Drag and drop the following steps into the correct order to send a RESTCONF GET request to retrieve interface configuration from a Cisco IOS-XE device and apply a configuration change based on the response.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order for a RESTCONF GET request workflow is: first, send a GET request to retrieve the current interface configuration. Second, analyze the JSON/XML response to identify required changes. Third, create the updated configuration payload in JSON or XML format.

Finally, apply the configuration change using a PUT or PATCH request. This sequence ensures you read the existing state before modifying it.

Exam trap

The most common mistake is to create the payload before analyzing the current configuration. Always retrieve the current state first to know exactly what to change.

Practice this question →

Multi-Selectmedium

Which THREE statements accurately describe the characteristics of NETCONF and RESTCONF for programmatic network configuration?

Select 3 answers

A.NETCONF uses HTTP methods such as GET, POST, PUT, and DELETE to manipulate configuration data.

B.NETCONF uses XML-encoded RPCs over a secure transport such as SSH or TLS.

C.RESTCONF supports both XML and JSON encoding and uses HTTP methods.

D.Both NETCONF and RESTCONF rely on YANG data models to define the structure of configuration and operational data.

E.NETCONF uses a separate commit operation to apply changes, while RESTCONF uses a similar commit mechanism.

AnswersB, C, D

NETCONF is a network management protocol that encodes all operations, such as <get>, <get-config>, and <edit-config>, as XML Remote Procedure Calls (RPCs). These RPCs are transmitted over a secure, connection-oriented transport: SSH is mandatory for NETCONF (RFC 6242), and TLS is supported as an alternative transport. This XML/RPC architecture differs fundamentally from RESTCONF's HTTP-based REST semantics.

Why this answer

NETCONF uses XML-encoded Remote Procedure Calls (RPCs) over a secure transport such as SSH or TLS, making option B correct. RESTCONF supports both XML and JSON encoding and uses standard HTTP methods (GET, POST, PUT, PATCH, DELETE), so option C is correct. Both NETCONF and RESTCONF rely on YANG data models to define the structure of configuration and operational data, confirming option D.

Option A is incorrect because NETCONF does not use HTTP methods; that is a characteristic of RESTCONF. Option E is wrong because RESTCONF does not use a separate commit operation; changes are applied immediately with each HTTP request, unlike NETCONF's candidate config and commit model.

Exam trap

Cisco often tests the misconception that NETCONF uses HTTP methods like RESTCONF, leading candidates to incorrectly select option A as a correct statement about NETCONF.

Why the other options are wrong

NETCONF uses XML‑encoded RPCs over SSH or TLS, not HTTP methods; HTTP methods are used by RESTCONF.

RESTCONF does not have a separate commit operation; changes are applied immediately with each HTTP request, unlike NETCONF's explicit commit step.

Practice this question →

Multi-Selectmedium

Which two statements about YANG are correct?

Select 2 answers

A.It defines structured models for configuration and state data

B.It is commonly associated with NETCONF and RESTCONF

C.It is a replacement for OSPF adjacency formation

D.It is the same thing as JSON syntax

E.It automatically discovers neighbors on a LAN

AnswersA, B

YANG is a data modeling language used to define the hierarchical structure of configuration and operational state data on network devices. It specifies which data is available, its constraints, and how it is organized, independent of any particular protocol. The models written in YANG serve as the authoritative schema for management systems and devices.

Why this answer

YANG is a data modeling language used to describe configuration and operational state. It is commonly used with NETCONF and RESTCONF, but it is not itself the transport protocol.

Exam trap

A common exam trap is mistaking YANG for a routing protocol or a data format. Some candidates incorrectly believe YANG replaces protocols like OSPF for adjacency formation or that it is the same as JSON syntax. This confusion arises because YANG models can be encoded in JSON or XML, but YANG itself is a modeling language, not a transport or routing protocol.

Misunderstanding this can lead to selecting incorrect answers that describe YANG as performing routing or neighbor discovery functions, which it does not. Recognizing YANG’s role as a data modeling language avoids this pitfall.

Why the other options are wrong

Option C is incorrect because YANG is not a routing protocol and does not handle OSPF adjacency formation or any routing functions.

Option D is incorrect as YANG is a modeling language, not a data format like JSON. Although YANG models can be encoded in JSON, they are not the same thing.

Option E is incorrect because YANG does not perform network discovery functions such as automatically discovering neighbors on a LAN; that is outside its scope.

Practice this question →

Drag & Dropmedium

Drag and drop the following steps into the correct order to retrieve the operational status of interface GigabitEthernet0/0 using NETCONF and the ietf-interfaces YANG model.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

6Step 6

Why this order

First, establish an SSH connection to the device's NETCONF subsystem (TCP port 830). The NETCONF protocol then performs a capability exchange via <hello> messages to ensure both sides support the required YANG models. Next, a <get> RPC with an XPath filter is sent to request the specific interface status.

The server replies with <rpc-reply> containing the XML data. The client parses the XML to extract the desired value. Finally, the NETCONF session is closed by a <close-session> RPC, and the SSH connection is terminated.

This order ensures a proper NETCONF transaction lifecycle.

Practice this question →

Drag & Dropmedium

Select the correct sequence of steps to retrieve a specific interface's configuration via RESTCONF and apply a change to the interface description.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for using RESTCONF to modify an interface description is: first retrieve the current configuration with a GET request, parse the JSON or XML response, modify the description field, apply the change with a PUT or PATCH request, and finally verify the change with another GET request. This sequence is correctly described only in option A. Options B, C, and D are incorrect because they either apply changes before retrieving the configuration, modify before retrieving, or verify before applying, which would not work as intended.

Exam trap

The key trap is confusing the order of operations: you must retrieve before modifying, and apply before verifying. Candidates often mix up the sequence, especially placing verification too early or modification before retrieval.

Practice this question →

MCQhard

Why are data models such as YANG important in network automation?

A.They define a structured way to represent configuration and state data

B.They replace IPv4 and IPv6 addressing

C.They remove the need for routing protocols

D.They are used only for naming wireless SSIDs

AnswerA

YANG defines a hierarchical, schema-based data model (RFC 6020/7950) that standardizes how configuration and operational state are represented, enabling programmatic access via NETCONF/RESTCONF. This structured representation allows automation tools to reliably validate, read, and modify device settings across vendors without ad-hoc CLI parsing.

Why this answer

Data models such as YANG standardize how configuration and operational data are described, which improves consistency for automation systems and APIs.

Exam trap

A common exam trap is to mistakenly believe that YANG data models replace fundamental network functions such as IPv4/IPv6 addressing or routing protocols. Some candidates incorrectly assume that because YANG structures configuration data, it eliminates the need for routing protocols like OSPF or EIGRP, or that it changes how IP addresses function. However, YANG is strictly a modeling language that describes how configuration and state data are represented for automation purposes.

It does not alter core networking protocols or addressing schemes. Confusing these roles can lead to selecting incorrect answers that misattribute YANG’s purpose.

Why the other options are wrong

Option B is incorrect because YANG does not replace IPv4 or IPv6 addressing schemes. IP addressing remains a core network function independent of data modeling languages.

Option C is wrong since YANG does not remove the need for routing protocols. Routing protocols like OSPF and EIGRP continue to operate and are configured using data models but are not replaced by them.

Option D is false because YANG’s scope is much broader than naming wireless SSIDs. It models a wide range of network configurations and operational data beyond wireless settings.

Practice this question →

PBQhard

You are connected to R1 (192.0.2.1/24, management IP). The network team needs to automate interface configuration using RESTCONF. Construct a valid RESTCONF GET request to retrieve the operational status of GigabitEthernet0/1 using the ietf-interfaces YANG module, and a PATCH request to set the description of that interface to 'Link to R2' using the Cisco-IOS-XE-native YANG module. Identify the error that occurs if the Accept header is set to application/json instead of application/yang-data+json.

Network Topology

Hints

•RESTCONF uses a specific media type for YANG data; check the Accept header.
•The YANG module paths differ between ietf-interfaces and Cisco-IOS-XE-native.
•The interface name must be URL-encoded if it contains special characters; GigabitEthernet0/1 is safe.

A.The server returns a 406 Not Acceptable error because RESTCONF requires the Accept header to be 'application/yang-data+json'.

B.The server returns a 400 Bad Request error because the Accept header must be 'application/json' for RESTCONF.

C.The server returns a 415 Unsupported Media Type error because the Accept header is set incorrectly.

D.The server returns a 200 OK response but ignores the Accept header and returns data in XML format.

AnswerA

solution

! R1
GET request: GET https://192.0.2.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/1 HTTP/1.1
Headers: Host: 192.0.2.1, Accept: application/yang-data+json
PATCH request: PATCH https://192.0.2.1/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=0/1/description HTTP/1.1
Headers: Host: 192.0.2.1, Content-Type: application/yang-data+json, Accept: application/yang-data+json
Body: {"description": "Link to R2"}

Why this answer

The correct base URI for RESTCONF on Cisco IOS-XE is https://<device-ip>/restconf/data. For the ietf-interfaces module, the YANG path is /ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1 (note the percent-encoded slash in the key). For the Cisco-IOS-XE-native module, the path is /Cisco-IOS-XE-native:native/interface/GigabitEthernet=0%2F1/description.

The Accept header must be 'application/yang-data+json'; using 'application/json' returns a 406 Not Acceptable error. The PATCH request body must contain the new description in JSON format. Failing to percent-encode the interface name will result in an invalid URI.

Exam trap

The exam tests your knowledge of RESTCONF media types and URL encoding: remember to percent-encode the slash in interface names (e.g., GigabitEthernet0%2F1) and distinguish between 406 (Accept error) and 415 (Content-Type error).

Why the other options are wrong

The specific factual error: RESTCONF requires 'application/yang-data+json', not 'application/json'.

The specific factual error: 415 relates to Content-Type, not Accept. Accept errors yield 406.

The specific factual error: RESTCONF does not silently fall back; it returns a 406 error.

Practice this question →

Multi-Selecthard

A controller exposes a YANG-modeled interface configuration through an API. Which two statements correctly describe the purpose of YANG in that workflow?

Select 2 answers

A.It provides a structured data model for configuration and operational data

B.It helps standardize how network elements represent managed data

C.It replaces IP addressing on routed interfaces

D.It is a spanning-tree optimization mechanism

AnswersA, B

YANG defines a hierarchical, tree-like schema that organizes both configuration data (intended state) and operational state data (actual state) for network devices. This structured model enables programmatic access and automation, as APIs like NETCONF/RESTCONF use YANG to validate and manipulate the data. It provides a clear, machine-readable representation of what a device can do and how its configuration is structured.

Why this answer

YANG is a modeling language. It defines the structure of network data so controllers and devices can exchange information consistently through APIs such as RESTCONF or NETCONF.

Exam trap

A frequent exam trap is mistaking YANG for a network protocol or function rather than a data modeling language. For example, options suggesting YANG replaces IP addressing or optimizes spanning-tree protocols are incorrect because YANG does not perform routing or Layer 2 operations. Candidates might confuse YANG’s role with actual network services instead of recognizing it as a schema that defines how configuration and state data are structured and exchanged.

This misunderstanding can lead to selecting incorrect answers that describe network functions rather than data modeling purposes.

Why the other options are wrong

Option C is incorrect because YANG does not replace IP addressing on routed interfaces. IP addressing is a network-layer function, while YANG models the data representing such configurations but does not perform addressing itself.

Option D is wrong as YANG has no role in spanning-tree optimization or Layer 2 loop prevention. YANG is a data modeling language and does not influence protocol operations like STP.

Practice this question →

MCQmedium

A network engineer is automating the configuration of a new branch office router. The engineer needs a protocol that uses a YANG data model, supports both configuration and operational state retrieval, and operates over SSH for secure transport. Which protocol should the engineer use?

A.SNMP

B.NETCONF

C.RESTCONF

D.CLI scripting

AnswerB

NETCONF is an IETF-standard protocol that uses YANG data models to define configuration and operational state data, encoding operations like get, edit-config, and commit in XML over a secure SSH transport. It explicitly separates the running configuration from operational state, supports transactional commit/rollback and candidate datastores, and provides a session-oriented, RPC-based mechanism ideal for automating network device configuration securely. These capabilities make NETCONF the correct choice for the scenario.

Why this answer

NETCONF (Network Configuration Protocol) is the correct choice because it uses YANG data models for configuration and operational state retrieval, and it operates over SSH (RFC 6242) for secure transport. Unlike SNMP, NETCONF provides transactional configuration changes and separates configuration from operational state data, making it ideal for automated router configuration.

Exam trap

Cisco often tests the distinction between NETCONF and RESTCONF, where the trap is that both use YANG, but candidates forget that NETCONF specifically requires SSH transport, while RESTCONF uses HTTP/HTTPS, making NETCONF the only correct answer when the question specifies 'operates over SSH'.

Why the other options are wrong

SNMP does not use YANG data models and typically operates over UDP, not SSH.

RESTCONF uses HTTP/HTTPS for transport, not SSH, so it does not meet the requirement of operating over SSH.

CLI scripting lacks a standardized data model like YANG and is not a protocol that operates over SSH in the same structured manner as NETCONF.

Practice this question →

PBQhard

Which option performs the RESTCONF operations correctly?

Network Topology

Hints

•Check the YANG module path: ietf-interfaces vs Cisco-IOS-XE-native
•Ensure the Accept header matches the data format (yang-data+json)
•For PATCH, the Content-Type must be application/yang-data+json, not application/json

A.GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0 with Accept: application/yang-data+json; then PATCH same URI with Content-Type: application/yang-data+json and body {"ietf-interfaces:interface":{"duplex":"full"}}; expect 204 No Content.

B.GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0 with Accept: application/json; then PATCH same URI with Content-Type: application/json and body {"duplex":"full"}; expect 204 No Content.

C.GET /restconf/data/Cisco-IOS-XE-native:interface/GigabitEthernet0/0 with Accept: application/yang-data+json; then PATCH same URI with Content-Type: application/yang-data+json and body {"Cisco-IOS-XE-native:interface":{"duplex":"full"}}; expect 204 No Content.

D.GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0 with Accept: application/yang-data+json; then PATCH same URI with Content-Type: application/yang-data+json and body {"duplex":"full"}; expect 200 OK.

AnswerA

solution

! R1
GET request URI: /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0
GET headers: Accept: application/yang-data+json
PATCH request URI: /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0
PATCH headers: Content-Type: application/yang-data+json
PATCH body: {"ietf-interfaces:interface": {"duplex": "full"}}

Why this answer

The correct base URI for RESTCONF is /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0. The Accept header must be application/yang-data+json. If the Content-Type header is incorrect (e.g., application/json), the router will return a 415 Unsupported Media Type error.

Using the wrong YANG module path, such as Cisco-IOS-XE-native:interface/GigabitEthernet0/0, will result in a 404 Not Found because the data model does not match. After a successful GET, the PATCH request must include the same URI with Content-Type: application/yang-data+json and a JSON body specifying "duplex": "full". The response should be a 204 No Content if successful.

Exam trap

Watch out for the required media type: RESTCONF uses application/yang-data+json, not generic application/json. Also, the YANG path must match the data model; for standard interface settings, use ietf-interfaces, not Cisco-IOS-XE-native. Finally, remember that a successful PATCH returns 204 No Content, not 200 OK.

Why the other options are wrong

The specific factual error is that RESTCONF requires the media type application/yang-data+json for YANG data, not generic application/json.

The specific factual error is that the duplex setting is defined in the ietf-interfaces YANG model, not in Cisco-IOS-XE-native. The URI path must match the data model.

The specific factual errors are: (1) The PATCH body must be structured as {"ietf-interfaces:interface":{"duplex":"full"}} to match the YANG data tree; (2) The success response for PATCH is 204 No Content, not 200 OK.

Practice this question →

PBQhard

You are connected to R1 (192.0.2.1/24). Use RESTCONF to query the operational state of GigabitEthernet0/0 using the ietf-interfaces YANG module. Then, send a PATCH request to disable the interface (set 'enabled' to false) using the Cisco-IOS-XE-native YANG module. Identify the error when a PATCH request is sent with the wrong Content-Type header (application/json instead of application/yang-data+json) and when the PATCH URI uses an incorrect YANG path (ietf-interfaces instead of Cisco-IOS-XE-native).

Hints

•RESTCONF requires Content-Type: application/yang-data+json for write operations.
•The ietf-interfaces module is read-only for operational state; use Cisco-IOS-XE-native for configuration changes.
•Check the URI path: /restconf/data/ followed by the YANG module and container/leaf.

A.The PATCH request fails with a 415 Unsupported Media Type error because the Content-Type header must be application/yang-data+json, not application/json.

B.The PATCH request fails with a 404 Not Found error because the URI uses ietf-interfaces, which is a read-only module for operational state; the server cannot write to it.

C.The PATCH request succeeds but the interface is not disabled because the body must use 'shutdown' instead of 'enabled'.

D.The PATCH request fails with a 400 Bad Request error because the body must be XML, not JSON.

AnswerA

solution

! R1
GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0 --header 'Accept: application/yang-data+json'
PATCH /restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=0/0 --header 'Content-Type: application/yang-data+json' -d '{"Cisco-IOS-XE-native:interface":{"GigabitEthernet":[{"name":"0/0","shutdown":true}]}}'

Why this answer

The correct GET request uses the ietf-interfaces YANG module path to retrieve interface state. For the PATCH, the Cisco-IOS-XE-native module is used because it supports writing native configuration (including shutdown). Sending PATCH with Content-Type: application/json is rejected because RESTCONF requires application/yang-data+json.

Using ietf-interfaces in the PATCH URI fails because that module is read-only for operational state; the server returns 404 or 405. The correct PATCH body sets 'shutdown' to true within the native interface container.

Exam trap

The trap is that candidates may focus on the YANG module path error (ietf-interfaces vs Cisco-IOS-XE-native) and miss that the question explicitly asks about the error when the Content-Type header is wrong. Always read the question carefully to identify the specific condition being tested.

Why the other options are wrong

The specific factual error is that the question asks about the error when the Content-Type header is wrong, not the URI path. The URI path error is a separate issue.

The specific factual error is that a wrong Content-Type header causes a rejection before any body parsing, so the request does not succeed.

The specific factual error is that RESTCONF does accept JSON; the issue is the exact media type string, not the format.

Practice this question →

PBQmedium

You are connected to R1 via the console. R1 is a Cisco ISR 4321 router running IOS-XE. The network manager wants to monitor interface utilization changes. Use RESTCONF to retrieve the operational state of GigabitEthernet0/0/0 on R1. The device has RESTCONF enabled with username 'admin' and password 'cisco'. The management IP is 192.168.1.1.

Hints

•RESTCONF uses HTTPS on port 443 by default.
•The interface name in the URI must be URL-encoded (e.g., '/' becomes '%2F').
•Use the 'Accept' header to request JSON data.

A.curl -X GET -u admin:cisco https://192.168.1.1/restconf/data/ietf-interfaces:interfaces-state/interface=GigabitEthernet0%2F0%2F0

B.curl -X GET -u admin:cisco https://192.168.1.1/restconf/data/ietf-interfaces:interfaces/GigabitEthernet0/0/0

C.curl -X POST -u admin:cisco https://192.168.1.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0%2F0

D.curl -X GET -u admin:cisco https://192.168.1.1/restconf/data/Cisco-IOS-XE-interfaces-oper:interfaces/GigabitEthernet0/0/0

AnswerA

solution

! R1
curl -k -X GET https://192.168.1.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0%2F0 -u admin:cisco -H "Accept: application/yang-data+json"

Why this answer

RESTCONF uses GET to retrieve data. To retrieve operational state (including interface counters), the path must lead to the `interfaces-state` container, not `interfaces`. The correct YANG data model for operational interface state is `ietf-interfaces:interfaces-state`, and the interface name must be URL-encoded to replace slashes with `%2F`.

Option C uses POST, which is wrong. Option B lacks URL encoding and uses the config container. Option D uses a Cisco-specific module and unencoded slashes, and is not the standard operational state path.

Exam trap

The most common mistake is using the `ietf-interfaces:interfaces` configuration container instead of the `ietf-interfaces:interfaces-state` operational state container, causing retrieval of the running configuration rather than live interface counters and utilization.

Why the other options are wrong

The request uses unencoded slashes in the interface name and the configuration container `interfaces`, not `interfaces-state`, so it will not retrieve operational state.

RESTCONF uses GET for retrieval; POST is used to create new resources or invoke operations, not to read operational data.

This uses a Cisco-IOS-XE-specific module and unencoded slashes, while the task expects the standard ietf-interfaces operational state path.

PBQhard

You are connected to R1. Use RESTCONF to retrieve all operational interface statistics from the ietf-interfaces YANG module, then modify the description of GigabitEthernet0/1 to 'Link to R2 via RESTCONF' using a PATCH request. The device is reachable at 203.0.113.1 with port 443, username 'admin', password 'cisco123'. Identify the error that would occur if you used a PATCH with Content-Type: application/json instead of application/yang-data+json.

Network Topology

Hints

•RESTCONF base URI is always /restconf.
•Use the YANG module 'ietf-interfaces' for operational state and configuration.
•The correct media type for RESTCONF is application/yang-data+json, not generic application/json.

A.The server returns a 415 Unsupported Media Type error because RESTCONF requires the Content-Type header to be application/yang-data+json.

B.The server returns a 400 Bad Request error because the JSON payload is malformed when using application/json.

C.The server returns a 404 Not Found error because the URI is incorrect when using application/json.

D.The server returns a 204 No Content response but ignores the description change because application/json is not supported.

AnswerA

solution

! R1
GET https://203.0.113.1/restconf/data/ietf-interfaces:interfaces-state/interface
Accept: application/yang-data+json
PATCH https://203.0.113.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/1
Content-Type: application/yang-data+json
{"ietf-interfaces:interface": [{"name": "GigabitEthernet0/1", "description": "Link to R2 via RESTCONF"}]}

Why this answer

The correct base URI for RESTCONF is https://203.0.113.1/restconf. To retrieve operational interface statistics, use GET with the path /data/ietf-interfaces:interfaces-state/interface. For the PATCH to modify the description, the URI must target /data/ietf-interfaces:interfaces/interface=GigabitEthernet0/1 with a JSON payload containing the 'description' leaf.

The required Content-Type and Accept headers must be 'application/yang-data+json'. Using 'application/json' will result in a 415 Unsupported Media Type error because RESTCONF requires the specific YANG media type.

Exam trap

The exam tests your knowledge of RESTCONF's strict media type requirements. Many candidates assume that application/json is acceptable because it is common in REST APIs, but RESTCONF specifically requires 'application/yang-data+json'. Remember that using any other media type results in a 415 error.

Why the other options are wrong

The specific factual error is that a 400 Bad Request is not triggered by an incorrect Content-Type; it is triggered by malformed syntax or invalid data.

The specific factual error is that the Content-Type header does not affect resource discovery; it only affects how the server interprets the payload.

The specific factual error is that an unsupported media type results in a client error (4xx), not a success response (2xx).

Practice this question →