CCNA Restconf Questions

The specific factual error: The GET URI is missing ?content=nonconfig, and the Accept header should be application/yang-data+json. The error for wrong Accept is 406, not 404.

The specific factual error: The YANG module path should be ietf-interfaces:interfaces/interface=..., not Cisco-IOS-XE-native:interface/.... The error for wrong path is 404, not 406.

The specific factual error: The Accept header must be application/yang-data+json; application/json is not acceptable and returns 406, not 404.

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.

The specific factual error is that the ietf-interfaces model's operational data cannot be modified via PATCH; the writable description is under Cisco-IOS-XE-native. Also, the Accept header should be application/yang-data+json.

The specific factual error is that the GET request should use ietf-interfaces for operational data, and the PATCH request should use the native model with correct Content-Type.

The specific factual error is that the Content-Type header must be application/yang-data+json, not application/json, to indicate the payload is YANG-encoded JSON.

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.

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.

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.

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.

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.

The specific factual error is that interfaces-state is an operational data node, not configurable. RESTCONF requires the /data path for configuration and /operations for RPCs.

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

The specific factual error is that in RESTCONF, when modifying data from a specific YANG module, the JSON key must include the module prefix to avoid ambiguity.

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.

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.

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.

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.

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.

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.

The specific factual error is that Cisco IOS XE RESTCONF implementation does not support XML content type; it only supports JSON.

The specific factual error is that the admin status is not available under the native YANG model; it is under ietf-interfaces.

The specific factual error is that RESTCONF requires the media type application/yang-data+json, not generic application/json. Additionally, the module name prefix is required in the JSON body.

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