The correct URIs are GET and PATCH to https://10.1.1.1:443/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/0, with the Accept header set to application/yang-data+json for the GET and the Content-Type header set to application/yang-data+json for the PATCH, whose body must include the interface name key. This is correct because RESTCONF requires the media type application/yang-data+json to properly negotiate YANG-encoded data; using generic application/json triggers a 406 Not Acceptable error, as the server cannot map generic JSON to the structured YANG model. On the CCNA 200-301 v2 exam, this tests your understanding of RESTCONF’s strict media-type negotiation and the mandatory inclusion of key leafs in PATCH bodies per RFC 8040—a common trap is omitting the “name” field inside the interface container, which causes the request to fail silently. Remember the memory tip: “YANG data, not plain JSON—use yang-data+json or get a 406 rejection.”
CCNA AI and Network Operations Practice Question
This 200-301 practice question tests your understanding of ai and network operations. Read the scenario carefully and evaluate each option against the stated constraints before committing to an answer. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
Network Topology
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.
R1# show running-config | section interface GigabitEthernet0/0
interface GigabitEthernet0/0
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
media-type rj45
no shutdown
!
R1# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.0.0.1 YES NVRAM up up
GigabitEthernet0/1 unassigned YES NVRAM administratively down down
Loopback0 10.0.0.11 YES NVRAM up up
A
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"}]}}}
This URI correctly targets the list instance using the ietf-interfaces YANG module. The Accept header requests yang-data+json, which is required. The PATCH body includes the mandatory key leaf 'name' to identify the list entry, satisfying RESTCONF requirements and preventing ambiguity.
B
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"}}
Why wrong: This is incorrect because RESTCONF requires the media type application/yang-data+json, not application/json. Using application/json will result in a 406 Not Acceptable error. Additionally, the PATCH body uses incorrect JSON structure (missing ietf-interfaces:interface wrapper and wrong field names).
C
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"}}}
Why wrong: This is incorrect because the YANG path uses the native Cisco model (Cisco-IOS-XE-native) instead of the standard ietf-interfaces model. While the path might be valid for the native model, the question specifies using the ietf-interfaces YANG model. Additionally, the PATCH body structure does not match the ietf-interfaces model.
D
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 <interface><ipv4><address><ip>192.0.2.1</ip><netmask>255.255.255.0</netmask></address></ipv4></interface>
Why wrong: This is incorrect because the question specifies using JSON format (Accept: application/json would fail, implying JSON is desired). Using XML is not appropriate here. Additionally, the Accept header should be application/yang-data+xml for XML, not application/xml.
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
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.
Key principle: Count usable hosts — not total addresses — and remember that the network and broadcast addresses are not available to hosts in standard IPv4 subnets.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
✓
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"}]}}}
Why this is correct
This URI correctly targets the list instance using the ietf-interfaces YANG module. The Accept header requests yang-data+json, which is required. The PATCH body includes the mandatory key leaf 'name' to identify the list entry, satisfying RESTCONF requirements and preventing ambiguity.
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"}}
Why it's wrong here
This is incorrect because RESTCONF requires the media type application/yang-data+json, not application/json. Using application/json will result in a 406 Not Acceptable error. Additionally, the PATCH body uses incorrect JSON structure (missing ietf-interfaces:interface wrapper and wrong field names).
✗
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"}}}
Why it's wrong here
This is incorrect because the YANG path uses the native Cisco model (Cisco-IOS-XE-native) instead of the standard ietf-interfaces model. While the path might be valid for the native model, the question specifies using the ietf-interfaces YANG model. Additionally, the PATCH body structure does not match the ietf-interfaces model.
✗
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 <interface><ipv4><address><ip>192.0.2.1</ip><netmask>255.255.255.0</netmask></address></ipv4></interface>
Why it's wrong here
This is incorrect because the question specifies using JSON format (Accept: application/json would fail, implying JSON is desired). Using XML is not appropriate here. Additionally, the Accept header should be application/yang-data+xml for XML, not application/xml.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.
✓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"}]}}}Correct answer▾
Why this is correct
This URI correctly targets the list instance using the ietf-interfaces YANG module. The Accept header requests yang-data+json, which is required. The PATCH body includes the mandatory key leaf 'name' to identify the list entry, satisfying RESTCONF requirements and preventing ambiguity.
✗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"}}Wrong answer — click to see why▾
Why this is wrong here
The specific factual error: RESTCONF mandates the use of application/yang-data+json for Accept and Content-Type headers; application/json is not supported. Also, the JSON body must follow the YANG data structure.
Why candidates choose this
Candidates might think application/json is acceptable because it is a common JSON media type, and they may be unfamiliar with the RESTCONF-specific media type requirement.
✗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"}}}Wrong answer — click to see why▾
Why this is wrong here
The specific factual error: The question explicitly requires the ietf-interfaces YANG model, not the Cisco-native model. Using the wrong model will not retrieve or modify the intended data.
Why candidates choose this
Candidates may confuse the native Cisco model with the standard ietf-interfaces model, especially if they are more familiar with Cisco-specific configurations.
✗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 <interface><ipv4><address><ip>192.0.2.1</ip><netmask>255.255.255.0</netmask></address></ipv4></interface>Wrong answer — click to see why▾
Why this is wrong here
The specific factual error: The question context indicates JSON is the target format (since it mentions Accept: application/json would fail). Using XML is a different format and would require different media types.
Why candidates choose this
Candidates might think XML is acceptable because RESTCONF supports both JSON and XML, but the question's mention of JSON failure implies JSON is the intended format.
Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Common exam traps
Common exam trap: usable hosts are not the same as total addresses
Subnetting questions often tempt you into counting all addresses. In normal IPv4 subnets, the network and broadcast addresses are not usable host addresses.
Detailed technical explanation
How to think about this question
Subnetting questions test whether you can identify the network, broadcast address, usable range, mask and correct subnet. Slow down enough to calculate the block size correctly.
KKey Concepts to Remember
CIDR notation defines the prefix length.
Block size helps identify subnet boundaries.
Network and broadcast addresses are not usable hosts in normal IPv4 subnets.
The required host count determines the smallest suitable subnet.
TExam Day Tips
→Write the block size before choosing the subnet.
→Check whether the question asks for hosts, subnets or a specific address range.
→Do not confuse /24, /25, /26 and /27 host counts.
Key takeaway
Count usable hosts — not total addresses — and remember that the network and broadcast addresses are not available to hosts in standard IPv4 subnets.
Real-world example
How this comes up in practice
A small business has 20 workstations on the 192.168.1.0/24 network and one public IP from its ISP. The router uses PAT (NAT overload) so all 20 devices share one public address using different source ports. NAT questions test whether you understand the four address terms and which direction each translation applies.
Related glossary terms
Concepts from this question explained
These glossary pages explain the core terms tested in this 200-301 question in full detail.
Review block sizes, usable host formulas (2^n − 2), and how to find network and broadcast addresses for /24 through /30. Then practise related 200-301 subnetting questions on CIDR, address ranges, and subnet selection.
AI and Network Operations — This question tests AI and Network Operations — CIDR notation defines the prefix length..
What is the correct answer to this question?
The correct answer is: 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.
What should I do if I get this 200-301 question wrong?
Review block sizes, usable host formulas (2^n − 2), and how to find network and broadcast addresses for /24 through /30. Then practise related 200-301 subnetting questions on CIDR, address ranges, and subnet selection.
What is the key concept behind this question?
CIDR notation defines the prefix length.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. 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.
hard
✓ A.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.
B.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 <interface><enabled>false</enabled></interface>; using Accept: application/xml is fine; using Cisco-IOS-XE-native path gives same data.
C.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.
D.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.
Why A: 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.
Last reviewed: Jun 6, 2026
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
This 200-301 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-301 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.