CCNA AI and Network Operations Practice Test 6 — 15 Questions

Question 1

Drag and drop the monitoring technologies on the left to the correct data model and transport descriptions on the right.

Accepted Answer

SNMP: Uses MIB and UDP for polling and traps. All four monitoring technologies—SNMP, NetFlow, Syslog, and IPFIX—are correctly paired with their typical data model and transport. SNMP uses a MIB (Management Information Base) and typically UDP for polling and traps. NetFlow uses flow records and UDP for traffic analysis. Syslog sends text-based log messages via UDP. IPFIX, the standardized version of NetFlow, uses template-based records and UDP (or SCTP) for flow export. Each pairing accurately reflects the standard data model and transport protocol.

Question 2

Drag and drop the following steps into the correct order to retrieve a specific interface configuration via RESTCONF and apply a change to the interface description.

Accepted Answer

Send a GET request to retrieve the current interface configuration.. The correct order to retrieve and modify an interface configuration via RESTCONF is: first send a GET request to retrieve the current interface configuration (step A). Then parse the retrieved JSON/XML data to locate the interface description field (step B). Next, send a PUT request with the modified JSON/XML data to update the interface description (step C). Finally, send a GET request to verify the change was applied successfully (step D). This logical sequence ensures that you have the current configuration before making changes, and you parse the data before sending the update.

Question 3

Drag and drop the following steps into the correct order to retrieve the current OSPF configuration via RESTCONF and apply a change to the OSPF process ID on a Cisco IOS-XE device.

Accepted Answer

Send a GET request to retrieve the current OSPF configuration.. First, send a GET request to retrieve the current OSPF configuration via RESTCONF. Then parse the JSON/XML payload to identify the OSPF process ID. Next, modify the OSPF process ID in the payload. Finally, send a PUT or PATCH request to apply the change.

Question 4

You are connected to R1. Configure R1 as an NTP client to synchronize with NTP server 203.0.113.10, using its Loopback0 interface (192.168.1.1/32) as the source for NTP packets. Additionally, configure logging to syslog server 192.0.2.100 with a trap level that captures events from level 5 (notice) and above. The current configuration shows that NTP is not synchronized (stratum 16) and only debugging messages are being sent to the syslog server. Correct these issues so that R1 is synchronized and important system messages are logged.

Accepted Answer

ntp server 203.0.113.10 source Loopback0
logging trap notifications. The 'ntp server' command on Cisco IOS supports the 'source' parameter to specify the source interface for NTP packets, satisfying the requirement to use Loopback0 as the source. Additionally, 'logging trap notifications' correctly sets the syslog trap level to 5 (notice and above). Option B is incorrect because it unnecessarily separates the NTP server and source into two commands, which is not required and may be less efficient. Option C uses 'logging trap debugging', which is too verbose (captures all messages). Option D omits the NTP source configuration entirely, leaving the source interface unspecified.

Answer

ntp server 203.0.113.10
ntp source Loopback0
logging trap notifications

Answer

ntp server 203.0.113.10 source Loopback0
logging trap debugging

Answer

ntp server 203.0.113.10
logging host 192.0.2.100
logging trap notifications

Question 5

You are connected to R1 via console. The NTP server 198.51.100.10 is already configured on R1, but R1 is not synchronizing because the NTP packets are sourced from the wrong interface. Configure R1 to source NTP packets from its loopback0 interface (IP 10.0.0.1/32). Additionally, configure syslog logging to the remote server 203.0.113.5, ensuring that only messages at severity 'notifications' (level 5) and above are sent. The current configuration shows that syslog is sending all messages (including debug-level) to the server, wasting bandwidth. Fix both issues.

Accepted Answer

Configure 'ntp source Loopback0' and 'logging trap notifications'.. The NTP client is not synchronizing because the NTP packets are not sourced from an interface that the server can reach and reply to; the default source is the outgoing interface, but the server sees a different source IP. The `ntp server 198.51.100.10` command is already configured (not shown), so you only need to specify the source interface with `ntp source Loopback0`. Also, the syslog trap level is set to 'debugging', which sends all messages; change it to 'notifications' to filter out lower-severity messages. After these changes, verify with 'show ntp status' (should show stratum less than 16 and 'synchronized') and 'show ntp associations' (should show a reach count > 0 and a valid ref clock). Check syslog with 'show logging' to confirm trap level is 'notifications'.

Answer

Configure 'ntp server 198.51.100.10 source Loopback0' and 'logging trap warnings'.

Answer

Configure 'ntp source Loopback0' and 'logging trap debugging'.

Answer

Configure 'ntp server 198.51.100.10' and 'logging trap notifications'.

Question 6

You are connected to R1. Configure NTP client to synchronize with the NTP server at 203.0.113.10, using the loopback0 interface (192.168.1.1/32) as the source. Also configure syslog to send messages of severity level 5 (notifications) and below to the syslog server at 198.51.100.20. Currently, NTP shows stratum 16 (unsynchronized) and important syslog messages are being missed.

Accepted Answer

ntp server 203.0.113.10 source Loopback0
logging trap notifications. The NTP command 'ntp server 203.0.113.10 source Loopback0' ensures NTP packets use Loopback0 as the source so replies are routable. For syslog, 'logging trap notifications' sets the severity threshold to level 5, sending messages with severity 0 through 5 to the configured syslog host. 'logging trap informational' would set the threshold to level 6, which also includes notifications but sends less-critical informational messages as well. If the syslog server is not already configured, 'logging host 198.51.100.20' is needed in addition to the trap level.

Answer

ntp server 203.0.113.10 source Loopback0
logging trap informational

Answer

ntp server 203.0.113.10
logging trap notifications

Answer

ntp server 203.0.113.10 source Loopback0
logging trap debugging

Question 7

You are connected to R1 via the console. R1 is a router acting as an NTP client to an external NTP server at 203.0.113.10. The NTP source interface must be Loopback0 (192.0.2.1/32). Additionally, configure R1 to send syslog messages of severity 'critical' and higher to a syslog server at 198.51.100.50. Currently, R1 shows 'Clock is unsynchronized, stratum 16'. Verify that NTP synchronizes and that only critical syslog messages are sent. The existing running configuration already has some NTP and syslog commands that need correction.

Accepted Answer

Configure 'ntp source Loopback0' and 'logging trap critical'. The NTP client was not synchronizing because the NTP source interface was not specified; the router uses the outgoing interface which may not be reachable or consistent. The 'ntp source Loopback0' command ensures NTP packets use a stable, routable IP address. For syslog, the logging trap was set to 'debugging', which sends all messages (severity 7). The requirement is to send only 'critical' (severity 2) and higher. The command 'logging trap critical' changes the filter. After both fixes, 'show ntp status' should show synchronized, stratum <16, and 'show logging' should show 'level critical' for trap logging.

Answer

Configure 'ntp server 203.0.113.10 source Loopback0' and 'logging trap 2'

Answer

Configure 'ntp source Loopback0' and 'logging trap 7'

Answer

Configure 'ntp server 203.0.113.10' and 'logging host 198.51.100.50'

Question 8

You are connected to R1 via the console. R1 should synchronize its clock with the NTP server 192.0.2.10 using its loopback0 interface (IP 10.0.0.1) as the source. Additionally, syslog messages of severity 'notification' (level 5) and above must be sent to the syslog server at 198.51.100.20. Currently, R1 shows NTP stratum 16 (unsynchronized) and syslog messages are not being forwarded. Identify and resolve the issues.

Accepted Answer

Add 'ntp server 192.0.2.10' and change 'logging trap informational' to 'logging trap notifications'.. The NTP part of the explanation is correct: 'ntp server 192.0.2.10' is required for synchronization. However, the syslog part of the explanation is incorrect. In Cisco IOS, `logging trap <level>` configures the router to send syslog messages with a severity number *equal to or lower* (more severe) than the specified level. Therefore, `logging trap informational` (level 6) would forward messages of severity 0 through 6, which *includes* 'notification' (level 5) messages. The explanation incorrectly states that 'informational' (level 6) is 'too low' and that 'messages of level 5 (notification) are not sent' if the trap is set to 'informational'. If 'notification' messages are currently not being forwarded (as stated in the stem), the existing `logging trap` level must be set to a *more severe* level (lower number) than 'notification' (e.g., `emergencies`, `alerts`, `critical`, `errors`, or `warnings`). The option's premise to 'change logging trap informational' contradicts the problem statement that 'syslog messages are not being forwarded' for notifications, as notifications would already be sent with an 'informational' trap level. Changing from 'informational' (6) to 'notifications' (5) would actually *reduce* the range of messages forwarded, excluding 'informational' messages.

Answer

Add 'ntp server 192.0.2.10' and change 'logging trap notifications' to 'logging trap informational'.

Answer

Add 'ntp server 192.0.2.10' and change 'logging trap notifications' to 'logging trap debugging'.

Answer

Add 'ntp server 192.0.2.10' and change 'logging trap informational' to 'logging trap emergencies'.

Question 9

You are connected to R1 via the console. R1 is a Cisco ISR 4331 router. Your task is to configure SNMPv2c and SNMPv3 traps, and NetFlow export, so that SNMP traps are sent to the NMS at 192.0.2.100 using SNMPv2c with community string 'PublicTrap', and also using SNMPv3 with user 'Admin' (authentication SHA, encryption AES) to the same NMS. Additionally, configure NetFlow to export version 9 flow records to 192.0.2.200 on UDP port 2055. Finally, verify your configurations.

Accepted Answer

Configure SNMPv2c trap community 'PublicTrap' and destination 192.0.2.100, create SNMPv3 user 'Admin' with auth SHA priv AES, set SNMPv3 trap destination 192.0.2.100 user 'Admin', configure NetFlow exporter to 192.0.2.200 port 2055 version 9, apply exporter to an interface, and verify with 'show snmp' and 'show ip cache flow'.. It correctly configures SNMPv2c traps with community string 'PublicTrap' to NMS 192.0.2.100, creates SNMPv3 user 'Admin' with authentication SHA and encryption AES, sets the SNMPv3 trap destination to the same NMS with that user, configures a NetFlow exporter to 192.0.2.200 port 2055 with version 9, applies the exporter to an interface, and uses the proper verification commands 'show snmp' and 'show ip cache flow'. Option B is incorrect because it uses MD5/DES instead of SHA/AES for SNMPv3 and NetFlow version 5 instead of version 9. Option C is incorrect because it fails to apply the NetFlow exporter to an interface, which is required for traffic to be exported. Option D is incorrect because it uses 'show ip flow export' for verification, which shows export statistics but not flow records; the correct command to verify NetFlow data is 'show ip cache flow'.

Answer

Configure SNMPv2c trap community 'PublicTrap' and destination 192.0.2.100, create SNMPv3 user 'Admin' with auth MD5 priv DES, set SNMPv3 trap destination 192.0.2.100 user 'Admin', configure NetFlow exporter to 192.0.2.200 port 2055 version 5, apply exporter to an interface, and verify with 'show snmp' and 'show ip cache flow'.

Answer

Configure SNMPv2c trap community 'PublicTrap' and destination 192.0.2.100, create SNMPv3 user 'Admin' with auth SHA priv AES, set SNMPv3 trap destination 192.0.2.100 user 'Admin', configure NetFlow exporter to 192.0.2.200 port 2055 version 9, and verify with 'show snmp' and 'show ip flow export'.

Answer

Configure SNMPv2c trap community 'PublicTrap' and destination 192.0.2.100, create SNMPv3 user 'Admin' with auth SHA priv AES, set SNMPv3 trap destination 192.0.2.100 user 'Admin', configure NetFlow exporter to 192.0.2.200 port 2055 version 9, apply exporter to an interface, and verify with 'show snmp' and 'show ip flow export'.

Question 10

You are connected to R1 via console. R1 is a Cisco ISR 4321 running IOS-XE 17.3. The initial configuration on R1 already includes the SNMPv2c community string 'CourseivaRO' with read-only access and a corresponding SNMPv2c trap host for 192.0.2.100 (these are already in place and do not need to be reconfigured). Your task is to add the following additional configurations: (a) [already configured] (b) Create an SNMPv3 user 'monitor' with SHA authentication and AES 128-bit encryption, using authentication password 'AuthPass123' and privacy password 'PrivPass456'; (c) Configure SNMP traps (linkUp, linkDown, authenticationFailure) to be sent to the NMS server at 192.0.2.100 using SNMPv3 with only authentication (no privacy). (d) Enable NetFlow on GigabitEthernet0/0/0, with flow export to collector 203.0.113.50 using UDP port 2055, NetFlow version 9, and set the source interface to Loopback0 (IP 10.0.0.1/32). Finally, verify your configuration with show snmp and show ip cache flow.

Accepted Answer

snmp-server user monitor CourseivaRO v3 auth sha AuthPass123 priv aes 128 PrivPass456
snmp-server host 192.0.2.100 version 3 auth monitor
interface GigabitEthernet0/0/0
 ip flow ingress
ip flow-export destination 203.0.113.50 2055
ip flow-export source Loopback0
ip flow-export version 5. It configures SNMPv3 user 'monitor' with SHA authentication and AES 128 encryption, and the trap host command specifies 'auth' for authentication-only traps as required. The NetFlow configuration includes ip flow ingress and version 9, matching the requirements. Note that although the user command references the community string 'CourseivaRO' as a group name, this is acceptable in this context because the community string is predefined and acts as a group in Cisco IOS SNMPv3 configuration (the community string is used as the group name for v3 users).

Answer

snmp-server user monitor CourseivaRO v3 auth sha AuthPass123 priv aes 128 PrivPass456
snmp-server host 192.0.2.100 version 3 auth monitor
interface GigabitEthernet0/0/0
 ip flow ingress
ip flow-export destination 203.0.113.50 2055
ip flow-export source Loopback0
ip flow-export version 9

Answer

snmp-server user monitor CourseivaRO v3 auth md5 AuthPass123 priv des56 PrivPass456
snmp-server host 192.0.2.100 version 3 priv monitor
interface GigabitEthernet0/0/0
 ip flow egress
ip flow-export destination 203.0.113.50 2055
ip flow-export source Loopback0
ip flow-export version 5

Answer

snmp-server user monitor CourseivaRO v3 auth sha AuthPass123 priv aes 128 PrivPass456
snmp-server host 192.0.2.100 version 3 priv monitor
interface GigabitEthernet0/0/0
 ip flow ingress
ip flow-export destination 203.0.113.50 2055
ip flow-export source Loopback0
ip flow-export version 9

Question 11

You are connected to R1 (192.168.1.1). Using RESTCONF, you need to retrieve the current operational status of GigabitEthernet0/0 using the ietf-interfaces YANG module, then change its description to 'WAN Link to R2' via a PATCH request. The device is reachable via HTTPS on port 443, with credentials admin/admin. Identify the correct base URI, YANG path, HTTP headers, and interpret the JSON response. Also, diagnose the error when an incorrect Content-Type or YANG path is used.

Accepted Answer

Base URI: https://192.168.1.1/restconf, YANG path: /data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0, Accept: application/yang-data+json, PATCH body: {"ietf-interfaces:description": "WAN Link to R2"}. The correct RESTCONF base URI is https://192.168.1.1/restconf. For the ietf-interfaces module, the YANG path for an interface is /data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0. The required Accept header is application/yang-data+json. A PATCH request to change just the description must include the module prefix in the JSON key: {"ietf-interfaces:description": "WAN Link to R2"}. Using application/json for Accept (as in Option C) returns a 406 Not Acceptable error because the server cannot provide the response in that format. Using application/json for Content-Type would return a 415 Unsupported Media Type error, but that is not tested by these options. Using the wrong YANG path (e.g., /data/ietf-interfaces:interfaces-state) returns a 404 Not Found because that path is for operational state, not configurable data.

Answer

Base URI: https://192.168.1.1/restconf, YANG path: /data/ietf-interfaces:interfaces-state/interface=GigabitEthernet0/0, Accept: application/yang-data+json, PATCH body: {"description": "WAN Link to R2"}

Answer

Base URI: https://192.168.1.1/restconf, YANG path: /data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0, Accept: application/json, PATCH body: {"description": "WAN Link to R2"}

Answer

Base URI: https://192.168.1.1/restconf, YANG path: /data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0, Accept: application/yang-data+json, PATCH body: {"description": "WAN Link to R2"}

Question 12

You are connected to R1. Using RESTCONF, you need to retrieve the current IP address of interface GigabitEthernet0/0 using the ietf-interfaces YANG model, then change it to 192.0.2.1/24 using a PATCH request. The device is reachable at 10.1.1.1 with port 443 and credentials admin/cisco. Identify the correct URIs and required HTTP headers, and explain why a GET with Accept: application/json would fail.

Accepted Answer

GET https://10.1.1.1:443/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0 with Accept: application/yang-data+json; PATCH same URI with Content-Type: application/yang-data+json and body {"ietf-interfaces:interface":{"name":"GigabitEthernet0/0","ietf-ip:ipv4":{"address":[{"ip":"192.0.2.1","prefix-length":24}]}}} [CORRECT]. A valid request would be GET https://10.1.1.1:443/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F0 with Accept: application/yang-data+json, then PATCH to the same URI with Content-Type: application/yang-data+json and body {"ietf-interfaces:interface":{"name":"GigabitEthernet0/0","ietf-ip:ipv4":{"address":[{"ip":"192.0.2.1","prefix-length":24}]}}}. Generic application/json is rejected by RESTCONF, which requires yang-data+json.

Answer

GET https://10.1.1.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0 with Accept: application/json; PATCH same URI with Content-Type: application/json and body {"interface":{"ip":"192.0.2.1","mask":"255.255.255.0"}}

Answer

GET https://10.1.1.1:443/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=0/0/ip/address with Accept: application/yang-data+json; PATCH same URI with Content-Type: application/yang-data+json and body {"address":{"primary":{"address":"192.0.2.1","mask":"255.255.255.0"}}}

Answer

GET https://10.1.1.1:443/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0 with Accept: application/xml; PATCH same URI with Content-Type: application/xml and body

192.0.2.1255.255.255.0

Question 13

You are connected to R1 (10.0.0.1/30). You need to use RESTCONF to verify the current administrative status of interface GigabitEthernet0/1 on R1, then change it to 'down'. The YANG data model is ietf-interfaces, and the base URI is https://10.0.0.1/restconf. Provide the correct GET and PATCH request URIs with appropriate HTTP headers. Also identify what error would occur if you used 'application/xml' as the Accept header or if you used the path 'Cisco-IOS-XE-native:native/interface/GigabitEthernet' instead of the correct ietf-interfaces path.

Accepted Answer

GET https://10.0.0.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/1 with Accept: application/yang-data+json; PATCH same URI with Content-Type: application/yang-data+json and body {"ietf-interfaces:interface": {"enabled": false}}; using Accept: application/xml gives 406 Not Acceptable; using Cisco-IOS-XE-native path gives 404 or incorrect data.. The correct GET request URI is https://10.0.0.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/1 with Accept: application/yang-data+json. The correct PATCH request uses the same URI, Content-Type: application/yang-data+json, and a JSON body per the ietf-interfaces model: {"ietf-interfaces:interface": {"enabled": false}}. Using Accept: application/xml would likely result in 406 Not Acceptable because application/xml is not a RESTCONF-defined media type; RESTCONF uses application/yang-data+xml for XML. Using the Cisco-IOS-XE-native:native/interface path would not access the ietf-interfaces 'enabled' leaf; the native model uses 'shutdown' for administrative state, and the path is not list-keyed in the same way, so it would 404 or return data lacking the required 'enabled' leaf.

Answer

GET https://10.0.0.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/1 with Accept: application/xml; PATCH same URI with Content-Type: application/xml and body false; using Accept: application/xml is fine; using Cisco-IOS-XE-native path gives same data.

Answer

GET https://10.0.0.1/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet0/1 with Accept: application/yang-data+json; PATCH same URI with Content-Type: application/yang-data+json and body {"Cisco-IOS-XE-native:interface": {"enabled": false}}; using Accept: application/xml gives 406; using ietf-interfaces path gives 404.

Answer

GET https://10.0.0.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/1 with Accept: application/json; PATCH same URI with Content-Type: application/json and body {"interface": {"enabled": false}}; using Accept: application/xml gives 406; using Cisco-IOS-XE-native path gives 404.

Question 14

You are connected to R1 (192.168.1.1/24, GigabitEthernet0/0). Using RESTCONF, you need to retrieve the operational status of interface GigabitEthernet0/0 and then change its description to 'Uplink to R2'. The correct base URI is https://192.168.1.1/restconf. Provide the GET and PATCH request URIs, required HTTP headers, and identify the error that occurs if you use Accept: application/json instead of application/yang-data+json.

Accepted Answer

GET /restconf/data/ietf-interfaces:interfaces-state/interface=GigabitEthernet0/0, PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0, Accept: application/yang-data+json, error: 406 Not Acceptable. To retrieve interface operational status, the GET URI must be /restconf/data/ietf-interfaces:interfaces-state/interface=GigabitEthernet0/0. The PATCH URI for changing description is /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0. Both require Accept: application/yang-data+json. Using Accept: application/json returns 406 Not Acceptable. A wrong module path (e.g., Cisco-IOS-XE-native) would return 404 Not Found.

Answer

GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0, PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0, Accept: application/json, error: 404 Not Found

Answer

GET /restconf/data/Cisco-IOS-XE-native:interface/GigabitEthernet0/0?content=nonconfig, PATCH /restconf/data/Cisco-IOS-XE-native:interface/GigabitEthernet0/0, Accept: application/yang-data+json, error: 406 Not Acceptable

Answer

GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0?content=nonconfig, PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0, Accept: application/json, error: 404 Not Found

Question 15

You are connected to R1 (198.51.100.1/24). Using RESTCONF, you need to retrieve the current operational status of GigabitEthernet0/0/0 via the ietf-interfaces YANG model, then update its description to 'WAN-Link-to-R2' using a PATCH request with the Cisco-IOS-XE-native YANG model. The candidate must identify the correct base URI, YANG module path, HTTP headers (Accept: application/yang-data+json), interpret the JSON response, and recognize the error that occurs when an incorrect Content-Type header or wrong YANG path is used.

Accepted Answer

GET request to /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0/0 with Accept: application/yang-data+json; PATCH request to /restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=0/0/0 with Content-Type: application/yang-data+json and body {"Cisco-IOS-XE-native:description": "WAN-Link-to-R2"}. The GET request correctly uses the ietf-interfaces module and Accept: application/yang-data+json to retrieve interface data. For the update, the task requires the Cisco-IOS-XE-native model. The PATCH must be sent to /restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=0/0/0 with Content-Type: application/yang-data+json and a body containing the description (optionally module-qualified). Although ietf-interfaces also has a writable description, using it would not match the requirement to use the native model. Incorrect Content-Type or wrong YANG path (e.g., PATCHing to ietf-interfaces) would result in an error.

Answer

GET request to /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0/0 with Accept: application/json; PATCH request to /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0/0 with Content-Type: application/yang-data+json and body {"description": "WAN-Link-to-R2"}

Answer

GET request to /restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=0/0/0 with Accept: application/yang-data+json; PATCH request to /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0/0 with Content-Type: application/json and body {"description": "WAN-Link-to-R2"}

Answer

GET request to /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0/0 with Accept: application/yang-data+json; PATCH request to /restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=0/0/0 with Content-Type: application/json and body {"Cisco-IOS-XE-native:description": "WAN-Link-to-R2"}