CCNA AI and Network Operations Practice Test 15 — 15 Questions

Question 1

You are connected to R1, a router that must send SNMP traps to a management server at 203.0.113.10 and export NetFlow data to a collector at 203.0.113.20. Currently, SNMPv2c traps are not being sent, and SNMPv3 is not configured for read-only access with authentication and privacy. Additionally, NetFlow export is missing the destination and version configuration. Configure the necessary commands on R1 to enable SNMPv2c traps (community string 'public'), configure SNMPv3 user 'admin' with SHA authentication and AES 128 encryption (password 'cisco123' for both auth and priv), and set NetFlow export to version 9.

Accepted Answer

snmp-server host 203.0.113.10 traps version 2c public
snmp-server group MyGroup v3 priv
snmp-server user admin MyGroup v3 auth sha cisco123 priv aes 128 cisco123
ip flow-export version 9. The configuration is missing SNMPv3 user setup, trap destination, and NetFlow export version. First, enable SNMPv2c traps with `snmp-server host 203.0.113.10 traps version 2c public`. Then, configure SNMPv3 user with `snmp-server user admin MyGroup v3 auth sha cisco123 priv aes 128 cisco123` after creating a group with `snmp-server group MyGroup v3 priv`. For NetFlow, set the export version with `ip flow-export version 9`. Finally, verify with `show snmp` to see trap host and v3 user, and `show ip cache flow` to confirm export configuration.

Answer

snmp-server host 203.0.113.10 traps version 2c public
snmp-server group MyGroup v3 auth
snmp-server user admin MyGroup v3 auth sha cisco123 priv aes 128 cisco123
ip flow-export version 9

Answer

snmp-server host 203.0.113.10 traps version 2c public
snmp-server user admin v3 auth sha cisco123 priv aes 128 cisco123
ip flow-export version 9

Answer

snmp-server host 203.0.113.10 traps version 2c public
snmp-server group MyGroup v3 priv
snmp-server user admin MyGroup v3 auth sha cisco123 priv aes 128 cisco123
ip flow-export destination 203.0.113.20 2055

Question 2

You are connected to R1, a Cisco router running IOS-XE. Configure SNMP v2c with a read-only community string 'publicRW' (note: the string is intentionally misnamed for the task), and SNMP v3 with user 'admin' using MD5 authentication (password 'cisco123') and DES encryption (password 'cisco456'). Ensure SNMP traps for linkUp/linkDown are sent to the management server at 192.0.2.100. Additionally, configure NetFlow export to send version 9 flow records to 192.0.2.200 on UDP port 2055, and ensure that only inbound traffic on GigabitEthernet0/0 is monitored. Finally, verify your configuration using 'show snmp' and 'show ip cache flow'.

Accepted Answer

snmp-server community publicRW ro
snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456
snmp-server enable traps snmp linkdown linkup
snmp-server host 192.0.2.100 traps version 2c publicRW
ip flow-export destination 192.0.2.200 2055
ip flow-export version 9
interface GigabitEthernet0/0
 ip flow ingress. The initial configuration has an SNMP v2c community string 'publicRW' set as RO, but the task requires it to be the read-only string. The SNMP v3 user 'admin' with MD5/DES is missing entirely, as are trap destinations and NetFlow export. To fix, first add the SNMP v3 user with 'snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456', then enable traps with 'snmp-server enable traps snmp linkdown linkup' and 'snmp-server host 192.0.2.100 traps version 2c publicRW'. For NetFlow, configure 'ip flow-export destination 192.0.2.200 2055', 'ip flow-export version 9', and apply flow monitoring on an interface (e.g., 'interface GigabitEthernet0/0' with 'ip flow ingress'). The 'show snmp' command will display the community strings and trap receivers, while 'show ip cache flow' will show flow records.

Answer

snmp-server community publicRW ro
snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456
snmp-server enable traps snmp linkdown linkup
snmp-server host 192.0.2.100 traps version 2c publicRW
ip flow-export destination 192.0.2.200 2055
ip flow-export version 9

Answer

snmp-server community publicRW ro
snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456
snmp-server enable traps snmp linkdown linkup
snmp-server host 192.0.2.100 traps version 2c publicRW
ip flow-export destination 192.0.2.200 2055
ip flow-export version 9
interface GigabitEthernet0/0
 ip flow egress

Answer

snmp-server community publicRW ro
snmp-server user admin admin v3 auth md5 cisco123 priv des cisco456
snmp-server enable traps snmp linkdown linkup
snmp-server host 192.0.2.100 traps version 2c publicRW
ip flow-export destination 192.0.2.200 2055
ip flow-export version 9
interface GigabitEthernet0/0
 ip flow monitor FLOW-MONITOR input

Question 3

You are connected to R1, a Cisco ISR 4321 running IOS-XE. Configure SNMPv2c with a read-only community string 'public' and SNMPv3 with user 'admin' using SHA authentication and AES encryption. Ensure SNMP traps are sent to the management server at 203.0.113.10. Additionally, configure NetFlow export to destination 203.0.113.20 on UDP port 2055 using version 9. Verify your configuration with appropriate show commands. The current running-config is incomplete; you must add the missing commands.

Accepted Answer

snmp-server community public ro
snmp-server user admin snmp-group v3 auth sha cisco priv aes 128 cisco
snmp-server host 203.0.113.10 traps version 2c public
ip flow-export destination 203.0.113.20 2055
ip flow-export version 9. The initial config has only a basic SNMPv2c community string. To meet requirements: enable SNMPv3 with a user 'admin' using SHA authentication and AES 128-bit encryption. The correct command requires a group name and the 'v3' keyword, e.g., 'snmp-server user admin snmp-group v3 auth sha cisco priv aes 128 cisco'. Configure SNMP trap destination with 'snmp-server host 203.0.113.10 traps version 2c public'. For NetFlow, use 'ip flow-export destination 203.0.113.20 2055' and 'ip flow-export version 9'. Verify with 'show snmp' and 'show ip cache flow'. Option B incorrectly uses version 3 traps with a community string; version 3 requires a security name. Option C uses insecure MD5/DES56 instead of SHA/AES. Option D uses NetFlow version 5 instead of version 9.

Answer

snmp-server community public ro
snmp-server user admin snmp-group v3 auth sha cisco priv aes 128 cisco
snmp-server host 203.0.113.10 traps version 3 auth public
ip flow-export destination 203.0.113.20 2055
ip flow-export version 9

Answer

snmp-server community public ro
snmp-server user admin snmp-group v3 auth md5 cisco priv des56 cisco
snmp-server host 203.0.113.10 traps version 2c public
ip flow-export destination 203.0.113.20 2055
ip flow-export version 9

Answer

snmp-server community public ro
snmp-server user admin snmp-group v3 auth sha cisco priv aes 128 cisco
snmp-server host 203.0.113.10 traps version 2c public
ip flow-export destination 203.0.113.20 2055
ip flow-export version 5

Question 4

You are connected to R1, a Cisco ISR 4331 router running IOS-XE. Your task is to enable SNMP v2c with community string 'public' (read-only) and 'private' (read-write), and configure SNMP v3 with a user 'admin' using SHA authentication (password 'Cisco123') and AES 128 encryption (password 'Cisco456'). Additionally, configure SNMP traps to be sent to a management server at 203.0.113.10 for both v2c and v3. Finally, enable NetFlow export to a collector at 203.0.113.20, using version 9. Verify your configuration using 'show snmp' and 'show ip cache flow'.

Accepted Answer

snmp-server community public RO
snmp-server community private RW
snmp-server user admin v3group v3 auth sha Cisco123 priv aes 128 Cisco456
snmp-server enable traps
snmp-server host 203.0.113.10 version 2c public
snmp-server host 203.0.113.10 version 3 auth admin
ip flow-export destination 203.0.113.20 2055
ip flow-export version 9. The router lacks SNMP and NetFlow configuration. For SNMP v2c, you must define community strings with 'snmp-server community public RO' and 'snmp-server community private RW'. For SNMP v3, you create a user within a group; the command requires a group name, e.g., 'snmp-server user admin v3group v3 auth sha Cisco123 priv aes 128 Cisco456'. Traps are enabled and sent to 203.0.113.10 via v2c with the public community and v3 with the admin user. NetFlow export uses version 9 to collector 203.0.113.20. Verification commands show SNMP details and flow cache export settings.

Answer

snmp-server community public
snmp-server community private
snmp-server user admin v3 auth md5 Cisco123 priv des56 Cisco456
snmp-server enable traps
snmp-server host 203.0.113.10 version 2c public
snmp-server host 203.0.113.10 version 3 auth admin
ip flow-export destination 203.0.113.20 2055
ip flow-export version 9

Answer

snmp-server community public RO
snmp-server community private RW
snmp-server user admin v3 auth sha Cisco123 priv aes 128 Cisco456
snmp-server enable traps
snmp-server host 203.0.113.10 version 2c private
snmp-server host 203.0.113.10 version 3 auth admin
ip flow-export destination 203.0.113.20 2055
ip flow-export version 9

Answer

snmp-server community public RO
snmp-server community private RW
snmp-server user admin v3 auth sha Cisco123 priv aes 128 Cisco456
snmp-server enable traps
snmp-server host 203.0.113.10 version 2c public
snmp-server host 203.0.113.10 version 3 auth admin
ip flow-export destination 203.0.113.20 2055
ip flow-export version 5

Question 5

You are connected to R1. Configure SNMPv3 with authentication (SHA) and encryption (AES-128) for user 'monitor' in group 'AdminGroup', and also configure SNMPv2c read-only community string 'cisco123' to send traps to the management server at 192.0.2.100. Additionally, configure NetFlow on interface GigabitEthernet0/0 to export flow data to 198.51.100.50 using version 9. Verify your configuration using the appropriate show commands.

Accepted Answer

snmp-server group AdminGroup v3 priv read AdminView; snmp-server user monitor AdminGroup v3 auth sha cisco123 priv aes 128 cisco123; snmp-server community cisco123 ro; snmp-server host 192.0.2.100 traps version 2c cisco123; interface GigabitEthernet0/0; ip flow-export destination 198.51.100.50 9996; ip flow-export version 9; ip flow ingress. The configuration was missing SNMPv3 user, group, and trap settings. We added the SNMPv3 user 'monitor' with SHA authentication and AES-128 encryption, created a view and group 'AdminGroup' with read access, and configured the SNMPv2c community string 'cisco123' for read-only access. We also enabled SNMP traps to the manager at 192.0.2.100 and configured NetFlow on GigabitEthernet0/0 to export to 198.51.100.50 using version 9. Verification commands show the SNMP configuration and NetFlow flow cache.

Answer

snmp-server group AdminGroup v3 auth read AdminView; snmp-server user monitor AdminGroup v3 auth sha cisco123 priv aes 128 cisco123; snmp-server community cisco123 ro; snmp-server host 192.0.2.100 traps version 2c cisco123; interface GigabitEthernet0/0; ip flow-export destination 198.51.100.50 9996; ip flow-export version 9; ip flow ingress

Answer

snmp-server group AdminGroup v3 priv read AdminView; snmp-server user monitor AdminGroup v3 auth sha cisco123 priv des 56 cisco123; snmp-server community cisco123 ro; snmp-server host 192.0.2.100 traps version 2c cisco123; interface GigabitEthernet0/0; ip flow-export destination 198.51.100.50 9996; ip flow-export version 9; ip flow ingress

Answer

snmp-server group AdminGroup v3 priv read AdminView; snmp-server user monitor AdminGroup v3 auth sha cisco123 priv aes 128 cisco123; snmp-server community cisco123 ro; snmp-server host 192.0.2.100 traps version 2c cisco123; interface GigabitEthernet0/0; ip flow-export destination 198.51.100.50 9996; ip flow-export version 5; ip flow ingress

Question 6

You are connected to R1, a Cisco IOS-XE router. Configure SNMP v2c with read-only community 'NetOpsRO' and SNMP v3 with user 'AdminUser' using SHA authentication (password: AuthPass1) and AES-128 encryption (password: PrivPass2). Also enable SNMP traps to the NMS at 192.0.2.10 with community 'TrapComm'. Additionally, configure NetFlow export to 192.0.2.20 using version 9, and ensure the flow exporter is applied to GigabitEthernet0/0. Verify your configuration using 'show snmp' and 'show ip cache flow'.

Accepted Answer

snmp-server community NetOpsRO ro
snmp-server group AdminGroup v3 priv
snmp-server user AdminUser AdminGroup v3 auth sha AuthPass1 priv aes 128 PrivPass2
snmp-server enable traps
snmp-server host 192.0.2.10 TrapComm
flow exporter EXPORTER
destination 192.0.2.20
version 9
!
flow monitor FLOW-MONITOR
exporter EXPORTER
record netflow ipv4 original-input
!
interface GigabitEthernet0/0
ip flow monitor FLOW-MONITOR input. Option A is the only complete configuration. It defines the SNMPv3 group and user, enables traps, sets up the flow exporter, and crucially defines a flow monitor globally before applying it to the interface. Without the global `flow monitor` definition, the `ip flow monitor ... input` command on the interface would be rejected. Option B omits the SNMP group and uses the deprecated `ip flow export` instead of the modern flow monitor method. Option C is missing the flow monitor definition, and its `snmp-server host` version syntax is unnecessary but not harmful; the real flaw is the absent monitor. Option D attempts to add the flow monitor but incorrectly places the global definition commands inside the interface configuration, which would cause a syntax error.

Answer

snmp-server community NetOpsRO ro
snmp-server user AdminUser v3 auth sha AuthPass1 priv aes 128 PrivPass2
snmp-server enable traps
snmp-server host 192.0.2.10 TrapComm
flow exporter EXPORTER
destination 192.0.2.20
version 9
!
interface GigabitEthernet0/0
ip flow export EXPORTER

Answer

snmp-server community NetOpsRO ro
snmp-server group AdminGroup v3 priv
snmp-server user AdminUser AdminGroup v3 auth sha AuthPass1 priv aes 128 PrivPass2
snmp-server enable traps
snmp-server host 192.0.2.10 version 2c TrapComm
flow exporter EXPORTER
destination 192.0.2.20
version 9
!
interface GigabitEthernet0/0
ip flow monitor FLOW-MONITOR input

Answer

snmp-server community NetOpsRO ro
snmp-server group AdminGroup v3 priv
snmp-server user AdminUser AdminGroup v3 auth sha AuthPass1 priv aes 128 PrivPass2
snmp-server enable traps
snmp-server host 192.0.2.10 TrapComm
flow exporter EXPORTER
destination 192.0.2.20
version 9
!
interface GigabitEthernet0/0
ip flow monitor FLOW-MONITOR input
flow monitor FLOW-MONITOR
exporter EXPORTER

Question 7

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.

Accepted Answer

The server returns a 406 Not Acceptable error because RESTCONF requires the Accept header to be 'application/yang-data+json'.. 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.

Answer

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

Answer

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

Answer

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

Question 8

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.

Accepted Answer

The server returns a 415 Unsupported Media Type error because RESTCONF requires the Content-Type header to be application/yang-data+json.. 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.

Answer

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

Answer

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

Answer

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

Question 9

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 Content-Type returns a 415 Unsupported Media Type error. 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 10

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/0 with Accept: application/yang-data+json; PATCH same URI with Content-Type: application/yang-data+json and body {"ietf-interfaces:interface":{"name":"GigabitEthernet0/0","ipv4":{"address":[{"ip":"192.0.2.1","netmask":"255.255.255.0"}]}}}. The correct base URI for RESTCONF is /restconf/data. The YANG path uses /ietf-interfaces:interfaces/interface=GigabitEthernet0/0. The Accept header must specify application/yang-data+json; generic application/json causes a 406 error. For PATCH, the same URI is used with Content-Type: application/yang-data+json. Crucially, the PATCH body must contain the key leaf 'name' ('GigabitEthernet0/0') inside the container to identify the list instance per RFC 8040; omitting it can cause failure. A wrong YANG path like Cisco-IOS-XE-native would yield 404.

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 11

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: GET https://10.0.0.1/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/1 with Accept: application/yang-data+json. The correct PATCH request URI is the same, with Content-Type: application/yang-data+json and a JSON body {"ietf-interfaces:interface": {"enabled": false}}. Using Accept: application/xml would result in a 406 Not Acceptable error because the server only supports yang-data+json. Using the Cisco-IOS-XE-native path would return a 404 or incorrect data because the operational state of the interface (admin status) is modeled under ietf-interfaces, not under the native YANG model which is used for configuration only.

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 12

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).

Accepted Answer

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.. 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.

Answer

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.

Answer

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

Answer

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

Question 13

Which option performs the RESTCONF operations correctly?

Accepted Answer

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.. 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.

Answer

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.

Answer

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.

Answer

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.

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/interface=GigabitEthernet0/0?content=nonconfig, PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0, Accept: application/yang-data+json, error: 406 Not Acceptable. The correct GET URI is /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0?content=nonconfig to retrieve operational status. The PATCH URI is /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0 with a JSON body containing the new description. Both requests require the header Accept: application/yang-data+json. If Accept: application/json is used, the router returns a 406 Not Acceptable error because IOS-XE RESTCONF only accepts application/yang-data+json. The YANG module path must use the ietf-interfaces module name; using a wrong path like /restconf/data/Cisco-IOS-XE-native:interface/GigabitEthernet0/0 would return a 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 YANG path and Accept header to retrieve the interface operational data. The PATCH request fails because it attempts to modify 'description' under the ietf-interfaces model, which is read-only for operational data; the writable 'description' is under Cisco-IOS-XE-native:native/interface/GigabitEthernet. The correct PATCH URI targets the Cisco-IOS-XE-native YANG module path, and the Content-Type must be application/yang-data+json. The 400 error indicates a mismatch between the YANG path in the URI and the data payload.

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"}

CCNA AI and Network Operations Practice Test 15 — 15 Questions

Exhibit

CCNA AI and Network Operations Practice Test 15 — 15 Questions

Exhibit