Restconf practice questions

Match each HTTP method to its common REST API action.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Retrieve a resource

Create a new resource

Update or replace a resource

Remove a resource

Trap 1: GET - Create data

GET is not designed for creation because it is a safe, read-only operation that must not alter server state or trigger side effects. Creating data requires sending a request payload and invoking server-side processing, which is the semantic role of POST. Using GET to create resources violates HTTP constraints, leading to problems such as unintended cacheable state changes and vulnerability to cross-site request forgery.

Trap 2: POST - Retrieve data

POST is not intended for retrieval because it is designed to submit data to a specified resource for processing, typically causing state changes or resource creation. Retrieval is a read-only operation that should use GET, which is safe and idempotent. Although POST can return data in a response, its primary semantic is server-side processing rather than querying existing resources.

Trap 3: PUT - Partially update data

PUT is defined to replace an entire resource with the representation in the request body, making it inappropriate for partial updates. A partial update modifies only a subset of a resource's fields, which is the purpose of the PATCH method. Because PUT is idempotent and requires the complete new state, applying it to a partial payload would cause missing fields to be reset or removed.

A
GET - Retrieve data
GET is an HTTP method that requests a representation of the specified resource without modifying server state. It is both safe and idempotent, meaning repeated identical GET requests yield the same result and cause no side effects. In REST APIs, GET is the standard operation for read-only retrieval, typically returning a 200 OK response with the resource body.
B
GET - Create data
Why wrong: GET is not designed for creation because it is a safe, read-only operation that must not alter server state or trigger side effects. Creating data requires sending a request payload and invoking server-side processing, which is the semantic role of POST. Using GET to create resources violates HTTP constraints, leading to problems such as unintended cacheable state changes and vulnerability to cross-site request forgery.
C
POST - Retrieve data
Why wrong: POST is not intended for retrieval because it is designed to submit data to a specified resource for processing, typically causing state changes or resource creation. Retrieval is a read-only operation that should use GET, which is safe and idempotent. Although POST can return data in a response, its primary semantic is server-side processing rather than querying existing resources.
D
PUT - Partially update data
Why wrong: PUT is defined to replace an entire resource with the representation in the request body, making it inappropriate for partial updates. A partial update modifies only a subset of a resource's fields, which is the purpose of the PATCH method. Because PUT is idempotent and requires the complete new state, applying it to a partial payload would cause missing fields to be reset or removed.

Question 2mediummulti select

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

Trap 1: NETCONF uses HTTP methods such as GET, POST, PUT, and DELETE to…

NETCONF does not run over HTTP; it uses XML-based Remote Procedure Calls (RPCs) carried over a secure, connection-oriented transport such as SSH (port 830) or TLS. Operations like <get-config>, <edit-config>, and <commit> are exchanged as XML messages, not as HTTP GET/POST/PUT/DELETE requests. HTTP method semantics are specific to RESTCONF, which is a distinct protocol.

Trap 2: NETCONF uses a separate commit operation to apply changes, while…

NETCONF provides a candidate configuration datastore with a distinct <commit> operation (and optional <rollback>) to atomically apply a set of changes. RESTCONF, however, does not implement a separate commit phase; every HTTP request (e.g., POST, PUT, PATCH) directly modifies the intended running datastore immediately. Therefore, saying RESTCONF uses a similar commit mechanism is incorrect; RESTCONF cannot provide multi-change atomic transactions like NETCONF's candidate datastore.

A
NETCONF uses HTTP methods such as GET, POST, PUT, and DELETE to manipulate configuration data.
Why wrong: NETCONF does not run over HTTP; it uses XML-based Remote Procedure Calls (RPCs) carried over a secure, connection-oriented transport such as SSH (port 830) or TLS. Operations like <get-config>, <edit-config>, and <commit> are exchanged as XML messages, not as HTTP GET/POST/PUT/DELETE requests. HTTP method semantics are specific to RESTCONF, which is a distinct protocol.
B
NETCONF uses XML-encoded RPCs over a secure transport such as SSH or TLS.
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.
C
RESTCONF supports both XML and JSON encoding and uses HTTP methods.
RESTCONF is a RESTful protocol defined in RFC 8040 that leverages standard HTTP methods (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS) to access YANG-defined data. It uses HTTP as the transport, thereby inheriting features like caching, authentication, and TLS security. Unlike NETCONF's XML-only encoding, RESTCONF supports both XML and JSON, allowing lighter-weight JSON for web-based tooling.
D
Both NETCONF and RESTCONF rely on YANG data models to define the structure of configuration and operational data.
YANG is a data modeling language used to define the hierarchical structure of configuration and operational data for network devices. Both NETCONF and RESTCONF rely on YANG modules to describe the exact structure of the datastore, which can be queried or modified with protocol-specific operations. This common data model allows interoperability, as the same YANG module can be used with either protocol.
E
NETCONF uses a separate commit operation to apply changes, while RESTCONF uses a similar commit mechanism.
Why wrong: NETCONF provides a candidate configuration datastore with a distinct <commit> operation (and optional <rollback>) to atomically apply a set of changes. RESTCONF, however, does not implement a separate commit phase; every HTTP request (e.g., POST, PUT, PATCH) directly modifies the intended running datastore immediately. Therefore, saying RESTCONF uses a similar commit mechanism is incorrect; RESTCONF cannot provide multi-change atomic transactions like NETCONF's candidate datastore.

Question 3hardmultiple choice

In a controller-based design, which statement best describes a northbound API?

Trap 1: A cable type used between controller clusters

Northbound and southbound are logical labels delineating the controller's interfaces, not physical media types. A cable cannot be 'northbound' because direction is defined by data flow between layers, such as applications above and network devices below the controller. Controller clusters communicate over conventional Ethernet or IP networks, but those links are not called northbound, and they have nothing to do with application-facing APIs.

Trap 2: The link-state protocol the controller uses to reach switches

The northbound API is not a routing protocol like OSPF or IS-IS; it is an application interface used by external systems. Controller-to-switch communication (the southbound interface) may indeed use protocols like OpenFlow or NETCONF, but the question specifically asks about the controller-based design's application-facing interface. A link-state protocol handles routing updates between routers, not API calls from software, so this option confuses data-plane routing with control-plane programmability.

Trap 3: A mechanism that removes the need for authentication

This choice mistakes an API for a security control. Northbound APIs commonly require authentication, typically via HTTPS with credentials, API tokens, or certificates, and they enforce authorization so each application only gets permitted operations. Removing authentication would create a severe vulnerability, so no standard northbound API does that; instead, APIs are interfaces, not trust-elimination mechanisms.

A
An application-facing API used by external software to communicate with the controller
In a controller-based architecture, the northbound API (often RESTful) faces applications and orchestration systems, allowing them to request network services or retrieve telemetry without manual device-level configuration. It abstracts the underlying network complexity, so external software can communicate intent to the controller, which then translates that intent into device-specific actions. This direction is 'north' because it sits above the controller in the logical hierarchy.
B
A cable type used between controller clusters
Why wrong: Northbound and southbound are logical labels delineating the controller's interfaces, not physical media types. A cable cannot be 'northbound' because direction is defined by data flow between layers, such as applications above and network devices below the controller. Controller clusters communicate over conventional Ethernet or IP networks, but those links are not called northbound, and they have nothing to do with application-facing APIs.
C
The link-state protocol the controller uses to reach switches
Why wrong: The northbound API is not a routing protocol like OSPF or IS-IS; it is an application interface used by external systems. Controller-to-switch communication (the southbound interface) may indeed use protocols like OpenFlow or NETCONF, but the question specifically asks about the controller-based design's application-facing interface. A link-state protocol handles routing updates between routers, not API calls from software, so this option confuses data-plane routing with control-plane programmability.
D
A mechanism that removes the need for authentication
Why wrong: This choice mistakes an API for a security control. Northbound APIs commonly require authentication, typically via HTTPS with credentials, API tokens, or certificates, and they enforce authorization so each application only gets permitted operations. Removing authentication would create a severe vulnerability, so no standard northbound API does that; instead, APIs are interfaces, not trust-elimination mechanisms.

Question 4hardmultiple choice

A REST API call uses the GET method against a device inventory endpoint. What is the most likely intent of the call?

Trap 1: To delete the endpoint from the controller.

HTTP DELETE is the method specifically designed to remove a resource from a server, but GET has no such semantics. Using GET to delete an endpoint would violate the HTTP specification, as GET must be safe and should never change the server state. Deleting a device inventory would require a DELETE request, not a GET.

Trap 2: To replace the endpoint with a new resource.

Resource replacement in REST is performed with the HTTP PUT method, which updates or replaces a resource at a given URI, whereas GET is defined for retrieval only. Submitting a GET request to replace the endpoint would violate REST's safe method constraint and lead to unintended side effects. Thus, replacement is entirely outside the scope of a GET request.

Trap 3: To force the device into PPP mode.

PPP mode is a data-link layer encapsulation configuration that is managed via CLI, SNMP, or other network management interfaces, not through HTTP methods. A REST API GET request operates at the application layer and simply retrieves JSON or XML data; it cannot force a device into PPP mode. This option confuses protocol-level management with application-layer API calls.

A
To retrieve information from the endpoint.
The HTTP GET method is used to retrieve a representation of a resource from the server without causing side effects. In RESTful APIs, GET is a safe and idempotent operation, meaning it only reads data and does not modify the server state. Therefore, calling GET against a device inventory returns the current inventory information.
B
To delete the endpoint from the controller.
Why wrong: HTTP DELETE is the method specifically designed to remove a resource from a server, but GET has no such semantics. Using GET to delete an endpoint would violate the HTTP specification, as GET must be safe and should never change the server state. Deleting a device inventory would require a DELETE request, not a GET.
C
To replace the endpoint with a new resource.
Why wrong: Resource replacement in REST is performed with the HTTP PUT method, which updates or replaces a resource at a given URI, whereas GET is defined for retrieval only. Submitting a GET request to replace the endpoint would violate REST's safe method constraint and lead to unintended side effects. Thus, replacement is entirely outside the scope of a GET request.
D
To force the device into PPP mode.
Why wrong: PPP mode is a data-link layer encapsulation configuration that is managed via CLI, SNMP, or other network management interfaces, not through HTTP methods. A REST API GET request operates at the application layer and simply retrieves JSON or XML data; it cannot force a device into PPP mode. This option confuses protocol-level management with application-layer API calls.

Question 5hardmultiple choice

Why is a northbound API valuable to orchestration tools in a controller-based network?

Trap 1: It replaces the need for all physical network devices.

This is wrong because forwarding devices still exist and still matter.

Trap 2: It is a cabling standard for data center uplinks.

This is wrong because northbound API is a software concept, not a cable standard.

Trap 3: It makes security controls unnecessary.

This is wrong because software interfaces still require authentication and authorization.

A
It gives orchestration tools a defined software interface to interact with the controller.
This is correct because northbound APIs are the application-facing path into the controller.
B
It replaces the need for all physical network devices.
Why wrong: This is wrong because forwarding devices still exist and still matter.
C
It is a cabling standard for data center uplinks.
Why wrong: This is wrong because northbound API is a software concept, not a cable standard.
D
It makes security controls unnecessary.
Why wrong: This is wrong because software interfaces still require authentication and authorization.

Question 6mediummulti select

Which two statements about YANG are correct?

Trap 1: It is a replacement for OSPF adjacency formation

OSPF is a dynamic routing protocol that exchanges hello packets to form and maintain adjacencies, and builds link-state databases to compute routes. YANG is not a routing protocol and has no mechanism to send hello messages or calculate routing paths. At best, YANG models can be used to configure OSPF parameters, but they can never replace the protocol's adjacency formation process.

Trap 2: It is the same thing as JSON syntax

JSON is a lightweight data-interchange syntax that encodes key-value pairs, arrays, and nested objects, whereas YANG is a schema language that defines the semantic meaning, types, and constraints of data. Although YANG data can be serialized using JSON syntax, the YANG model itself is not JSON, and a JSON file without a YANG model lacks formal validation rules. They operate at different layers: YANG defines the rules, JSON represents instances.

Trap 3: It automatically discovers neighbors on a LAN

YANG does not send or receive any packets, so it cannot discover neighbors on a LAN. Neighbor discovery is performed by protocols like LLDP, CDP, or IPv6 ND, which exchange messages at Layer 2 or Layer 3. YANG is purely a modeling language that describes data structures; it has no runtime behavior in the data plane.

A
It defines structured models for configuration and state data
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.
B
It is commonly associated with NETCONF and RESTCONF
NETCONF and RESTCONF are network management protocols that rely on YANG modules to define the set of data objects, their relationships, and allowable fields. When a client retrieves or modifies device state, the YANG model dictates the exact XML or JSON structure of the request and response. Thus, YANG provides the schema that these protocols act upon, making them strongly associated.
C
It is a replacement for OSPF adjacency formation
Why wrong: OSPF is a dynamic routing protocol that exchanges hello packets to form and maintain adjacencies, and builds link-state databases to compute routes. YANG is not a routing protocol and has no mechanism to send hello messages or calculate routing paths. At best, YANG models can be used to configure OSPF parameters, but they can never replace the protocol's adjacency formation process.
D
It is the same thing as JSON syntax
Why wrong: JSON is a lightweight data-interchange syntax that encodes key-value pairs, arrays, and nested objects, whereas YANG is a schema language that defines the semantic meaning, types, and constraints of data. Although YANG data can be serialized using JSON syntax, the YANG model itself is not JSON, and a JSON file without a YANG model lacks formal validation rules. They operate at different layers: YANG defines the rules, JSON represents instances.
E
It automatically discovers neighbors on a LAN
Why wrong: YANG does not send or receive any packets, so it cannot discover neighbors on a LAN. Neighbor discovery is performed by protocols like LLDP, CDP, or IPv6 ND, which exchange messages at Layer 2 or Layer 3. YANG is purely a modeling language that describes data structures; it has no runtime behavior in the data plane.

Question 7mediummultiple choice

Which pairing is correct?

Trap 1: JSON — data modeling language used to define network schemas such…

The pairing is incorrect because JSON (JavaScript Object Notation) is a lightweight, text-based data-interchange format, not a data modeling language. It uses curly braces and arrays to represent structured data, but it cannot define network schemas or modules. In the YANG ecosystem, JSON is often used as an encoding format for data that is modeled by YANG, but the modeling language itself is YANG, not JSON.

Trap 2: YANG — lightweight interchange format built from curly braces and…

The pairing is incorrect because YANG (Yet Another Next Generation) is a data modeling language used to define network schemas, constraints, and semantics for configuration and operational data. It uses a hierarchical tree-like syntax with modules and statements, not curly braces and arrays. The description of a lightweight interchange format with curly braces and arrays actually refers to JSON, which is a data serialization format, not a modeling language.

Trap 3: NETCONF — spanning-tree enhancement for rapid convergence

The pairing is incorrect because NETCONF is a network management protocol, defined in RFC 6241, that provides mechanisms to install, manipulate, and delete configuration on network devices using XML-based messages over SSH or TLS. It has nothing to do with spanning-tree or rapid convergence. Rapid convergence is a feature of spanning-tree enhancements like Rapid Spanning Tree Protocol (RSTP) or Multiple Spanning Tree Protocol (MSTP), which are unrelated to NETCONF.

A
JSON — data modeling language used to define network schemas such as YANG modules
Why wrong: The pairing is incorrect because JSON (JavaScript Object Notation) is a lightweight, text-based data-interchange format, not a data modeling language. It uses curly braces and arrays to represent structured data, but it cannot define network schemas or modules. In the YANG ecosystem, JSON is often used as an encoding format for data that is modeled by YANG, but the modeling language itself is YANG, not JSON.
B
YANG — lightweight interchange format built from curly braces and arrays
Why wrong: The pairing is incorrect because YANG (Yet Another Next Generation) is a data modeling language used to define network schemas, constraints, and semantics for configuration and operational data. It uses a hierarchical tree-like syntax with modules and statements, not curly braces and arrays. The description of a lightweight interchange format with curly braces and arrays actually refers to JSON, which is a data serialization format, not a modeling language.
C
RESTCONF — protocol that can use YANG-defined data models over HTTP-based access
RESTCONF is an IETF-standard protocol (RFC 8040) that exposes YANG-defined data models through a RESTful API over HTTP/HTTPS. It uses HTTP methods like GET, POST, PUT, PATCH, and DELETE to access configuration and state data, making it ideal for programmatic network automation and integration with web-based tooling. The pairing is correct because RESTCONF specifically bridges YANG models with HTTP-based access.
D
NETCONF — spanning-tree enhancement for rapid convergence
Why wrong: The pairing is incorrect because NETCONF is a network management protocol, defined in RFC 6241, that provides mechanisms to install, manipulate, and delete configuration on network devices using XML-based messages over SSH or TLS. It has nothing to do with spanning-tree or rapid convergence. Rapid convergence is a feature of spanning-tree enhancements like Rapid Spanning Tree Protocol (RSTP) or Multiple Spanning Tree Protocol (MSTP), which are unrelated to NETCONF.

Question 8easymultiple choice

Which HTTP method is commonly used to retrieve information from a REST API without modifying the resource?

Trap 1: POST

POST submits data to the server for processing, often to create a subordinate resource, and it is not idempotent — multiple identical POSTs can create multiple resources. Its response typically contains a status code and location header, not a fetched representation, so it is unsuitable for retrieving information. Unlike GET, POST is designed to send a payload that causes side effects on the server.

Trap 2: PUT

PUT replaces or creates a resource at a specific URI using the request body, making it the wrong method for retrieval because it focuses on state modification, not data access. It is idempotent, so repeated PUTs produce the same state, but it never returns the resource's data in the response as a primary purpose. Clients use it to upload or update representations, not to read them.

Trap 3: DELETE

DELETE is an unsafe but idempotent method used to remove a specified resource from the server, making it the wrong choice for retrieving information. A successful DELETE response indicates the resource has been deleted, and subsequent requests for that resource will return a 404 Not Found rather than data. Its purpose is destructive, not informational.

A
POST
Why wrong: POST submits data to the server for processing, often to create a subordinate resource, and it is not idempotent — multiple identical POSTs can create multiple resources. Its response typically contains a status code and location header, not a fetched representation, so it is unsuitable for retrieving information. Unlike GET, POST is designed to send a payload that causes side effects on the server.
B
GET
The GET method is designed to retrieve a representation of a specified resource — it is safe, meaning it never changes server state, and idempotent, so multiple identical requests produce the same result. In RESTful APIs, GET is the standard operation for querying or fetching information, and it typically carries no request body, with all parameters in the URL query string.
C
PUT
Why wrong: PUT replaces or creates a resource at a specific URI using the request body, making it the wrong method for retrieval because it focuses on state modification, not data access. It is idempotent, so repeated PUTs produce the same state, but it never returns the resource's data in the response as a primary purpose. Clients use it to upload or update representations, not to read them.
D
DELETE
Why wrong: DELETE is an unsafe but idempotent method used to remove a specified resource from the server, making it the wrong choice for retrieving information. A successful DELETE response indicates the resource has been deleted, and subsequent requests for that resource will return a 404 Not Found rather than data. Its purpose is destructive, not informational.

Question 9mediummulti select

Which two statements accurately describe controller-based networking at the CCNA level?

Trap 1: Controllers eliminate all need for switches and routers.

Controllers do not make switches and routers obsolete; they centralize control-plane decision-making and management, but the underlying devices still handle the data plane, physically forwarding frames and packets. A controller must communicate with those devices, often through southbound protocols, to install forwarding rules or policies, so the physical or virtual network elements remain essential to traffic delivery.

Trap 2: Controllers are unrelated to automation.

Controllers are fundamentally tied to automation because they expose programmatic interfaces, support intent-based configuration, and integrate with orchestration platforms, enabling tasks like zero-touch provisioning, automated policy deployment, and continuous compliance checks. Far from being unrelated, automation is a primary reason organizations adopt controller-based architectures, since the centralized controller can repeatedly apply standardized configurations without manual per-device intervention.

Trap 3: Controllers require Telnet for all communication.

Controllers do not require Telnet for all communication; modern controller architectures rely on secure, standards-based southbound protocols like NETCONF, RESTCONF, OpenFlow, or gRPC to manage network devices, and on encrypted northbound APIs for application interaction. Telnet is an insecure legacy terminal emulation protocol that lacks encryption, making it unsuitable as a universal communication method in contemporary controller-based networks.

A
A controller can centralize management and policy logic.
A controller centralizes management and policy logic, providing a single point from which administrators define and enforce network-wide configurations, security policies, and quality-of-service rules. This abstraction simplifies operations compared with per-device CLI management, allowing consistent policy application across many switches and routers without replacing the forwarding infrastructure itself.
B
Northbound APIs can allow external applications to communicate with the controller.
Northbound APIs act as the interface between the controller and external software, typically using RESTful, RESTCONF, or gRPC calls so applications can retrieve telemetry, adjust settings, or orchestrate connectivity. Because these APIs abstract low-level device details, third-party tools and custom scripts can programmatically control the network while the controller translates those requests into device-specific configurations.
C
Controllers eliminate all need for switches and routers.
Why wrong: Controllers do not make switches and routers obsolete; they centralize control-plane decision-making and management, but the underlying devices still handle the data plane, physically forwarding frames and packets. A controller must communicate with those devices, often through southbound protocols, to install forwarding rules or policies, so the physical or virtual network elements remain essential to traffic delivery.
D
Controllers are unrelated to automation.
Why wrong: Controllers are fundamentally tied to automation because they expose programmatic interfaces, support intent-based configuration, and integrate with orchestration platforms, enabling tasks like zero-touch provisioning, automated policy deployment, and continuous compliance checks. Far from being unrelated, automation is a primary reason organizations adopt controller-based architectures, since the centralized controller can repeatedly apply standardized configurations without manual per-device intervention.
E
Controllers require Telnet for all communication.
Why wrong: Controllers do not require Telnet for all communication; modern controller architectures rely on secure, standards-based southbound protocols like NETCONF, RESTCONF, OpenFlow, or gRPC to manage network devices, and on encrypted northbound APIs for application interaction. Telnet is an insecure legacy terminal emulation protocol that lacks encryption, making it unsuitable as a universal communication method in contemporary controller-based networks.

Question 10easymultiple choice

Which data format is most commonly used in REST APIs because it is lightweight and easy for applications to parse?

Trap 1: YANG

YANG (Yet Another Next Generation) is a data modeling language used to describe the configuration and state data of network devices, primarily for NETCONF and RESTCONF protocols. It defines the structure of data, not how that data is serialized on the wire; REST APIs generally use JSON or XML as the actual data format, so YANG is a modeling framework rather than a format for API messages.

Trap 2: STP

STP (Spanning Tree Protocol) is a Layer 2 protocol that prevents loops in Ethernet networks by dynamically blocking redundant paths and negotiating a loop-free topology. It operates on switches and bridges, dealing with BPDUs and port states, and has nothing to do with data serialization or the payload format of REST APIs, making it entirely irrelevant to this question.

Trap 3: TFTP

TFTP (Trivial File Transfer Protocol) is a network protocol used to transfer files, typically over UDP port 69, and is commonly employed for bootstrapping diskless devices or copying configuration files to network hardware. It is not a data format at all — it is a transport mechanism, so it cannot be used to represent the structure of a REST API request or response body.

A
YANG
Why wrong: YANG (Yet Another Next Generation) is a data modeling language used to describe the configuration and state data of network devices, primarily for NETCONF and RESTCONF protocols. It defines the structure of data, not how that data is serialized on the wire; REST APIs generally use JSON or XML as the actual data format, so YANG is a modeling framework rather than a format for API messages.
B
JSON
JSON is the standard data-interchange format for REST APIs because it is lightweight, human-readable, and natively supported by JavaScript, making it trivial to parse in browsers and servers. It represents structured data as key-value pairs and arrays, mirroring the object literal syntax of many programming languages, and is transmitted with the Content-Type: application/json header. Its low overhead and easy mapping to language objects make it the default choice for most modern web APIs.
C
STP
Why wrong: STP (Spanning Tree Protocol) is a Layer 2 protocol that prevents loops in Ethernet networks by dynamically blocking redundant paths and negotiating a loop-free topology. It operates on switches and bridges, dealing with BPDUs and port states, and has nothing to do with data serialization or the payload format of REST APIs, making it entirely irrelevant to this question.
D
TFTP
Why wrong: TFTP (Trivial File Transfer Protocol) is a network protocol used to transfer files, typically over UDP port 69, and is commonly employed for bootstrapping diskless devices or copying configuration files to network hardware. It is not a data format at all — it is a transport mechanism, so it cannot be used to represent the structure of a REST API request or response body.

Question 11easymulti select

A network engineer is reviewing REST API behavior. Which two statements are true?

Trap 1: DELETE is used to encrypt a payload before transport

DELETE is an HTTP method specifically intended to remove a specified resource from the server, not to secure data in transit. Encryption of payloads is handled by transport-layer protocols such as TLS, not by the HTTP method. While a DELETE request may return 200 OK or 204 No Content, it has no role in encrypting content before transmission.

Trap 2: PUT always retrieves a list of resources

PUT is designed to update or replace an existing resource at a specific URI, not to retrieve a list of resources. It is idempotent, meaning repeated PUT requests yield the same state, which is appropriate for full updates. Retrieving resources is the function of GET, so stating that PUT always retrieves a list conflates the distinct roles of these methods.

Trap 3: GET requires a token in every API design

Token-based authentication is a common API practice, but it is not a requirement of the HTTP GET method itself. Many APIs use API keys, basic authentication, or no authentication at all for public endpoints. The HTTP specification defines GET as a retrieve operation without mandating any particular authentication mechanism, so tokens are an implementation choice, not a universal rule.

A
GET is commonly used to retrieve information from an API
GET is the standard read method in REST APIs, designed to retrieve a representation of a resource without modifying server state. Because it is safe and idempotent, repeated identical GET requests produce the same result, making it the natural choice for queries. A successful GET commonly returns a 200 OK response with the requested payload.
B
POST is commonly used to create a new resource
POST is used to submit data to the server to create a new resource, especially when the client does not determine the URI. Unlike PUT, POST is non-idempotent, meaning identical POST requests can create multiple resources. A typical response is 201 Created, optionally including a Location header identifying the newly created resource.
C
DELETE is used to encrypt a payload before transport
Why wrong: DELETE is an HTTP method specifically intended to remove a specified resource from the server, not to secure data in transit. Encryption of payloads is handled by transport-layer protocols such as TLS, not by the HTTP method. While a DELETE request may return 200 OK or 204 No Content, it has no role in encrypting content before transmission.
D
PUT always retrieves a list of resources
Why wrong: PUT is designed to update or replace an existing resource at a specific URI, not to retrieve a list of resources. It is idempotent, meaning repeated PUT requests yield the same state, which is appropriate for full updates. Retrieving resources is the function of GET, so stating that PUT always retrieves a list conflates the distinct roles of these methods.
E
GET requires a token in every API design
Why wrong: Token-based authentication is a common API practice, but it is not a requirement of the HTTP GET method itself. Many APIs use API keys, basic authentication, or no authentication at all for public endpoints. The HTTP specification defines GET as a retrieve operation without mandating any particular authentication mechanism, so tokens are an implementation choice, not a universal rule.

Question 12mediumdrag order

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

5Step 5

A
Send GET request to retrieve current interface configuration
The first action in any RESTCONF-based configuration workflow is to issue a GET request against the specific interface's resource URI, such as /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0/1. This retrieves the current running configuration for that interface, which serves as the authoritative baseline for subsequent analysis. The GET response also confirms the exact YANG module namespace and data encoding, providing the correct structure and media type to use when constructing the payload for the update step.
B
Analyze the JSON/XML response to identify required changes
After retrieving the configuration, you must parse the structured JSON/XML body returned by the GET request to determine the current operational state of the interface. This analysis involves comparing the retrieved attributes (e.g., speed, duplex, IP address) against the intended target configuration to identify which parameters need to be added, removed, or modified. Without this step, you risk constructing a payload that does not accurately reflect the delta between the current and desired state, potentially causing errors or unintended interface resets.
C
Create the updated configuration payload in JSON or XML format
Based on the analysis of the current configuration, you build a new JSON or XML document that represents the desired final state of the interface. The payload must match the YANG schema exactly, including the correct element/attribute names, mandatory leafs, and the proper namespace or module identifier, otherwise the device will reject the request. For a PUT request, this payload must be a complete representation of the interface configuration; for a PATCH, it should contain only the modified fields to minimize the risk of overwriting unrelated parameters.
D
Apply the configuration change using a PUT or PATCH request
This step sends the actual configuration update to the device using the HTTP PUT or PATCH method. PUT is used to fully replace an existing resource, meaning you must include every attribute you want to preserve, while PATCH allows you to update only the specific fields that need to change, leaving others untouched. The request must include the appropriate Content-Type header (e.g., application/yang-data+json) and a valid payload that conforms to the YANG model of the interface, ensuring the device accepts the change without validation errors.

Question 13mediummatching

Drag and drop the protocol/model on the left to the correct description on the right.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Data modeling language used to define configuration and state data structures

Protocol using XML over SSH for configuration management and transactional operations

RESTful API using HTTP methods (GET, PUT, POST, DELETE) over HTTPS

Operation to modify configuration with options like merge, replace, create, delete

HTTP method used for partial updates to a resource

A
YANG: Data modeling language used to define configuration and state data structures
YANG (RFC 7950) is a data modeling language that describes the structure, constraints, and semantics of configuration and state data in a hierarchical tree. It is transport-agnostic and acts as the schema foundation for both NETCONF (XML) and RESTCONF (JSON), enabling interoperable data exchange between network devices and controllers through standardized models like ietf-interfaces.
B
NETCONF: Protocol using XML over SSH for configuration management and transactional operations
NETCONF is a network management protocol that encodes RPCs in XML and typically runs over SSH (transport port 830), enabling secure, transactional configuration changes across entire devices. It distinguishes between several datastores (candidate, running, startup), uses a <commit> operation to apply candidate configurations, and supports subscriptions, locking, and an extensible set of operations—making it far more robust than SNMP for day-2 operations.
C
RESTCONF: RESTful API using HTTP methods (GET, PUT, POST, DELETE) over HTTPS
RESTCONF is a RESTful protocol defined in RFC 8040 that uses HTTP methods (GET, PUT, POST, DELETE) over HTTPS to access YANG-defined data on network devices. It supports both JSON and XML encoding, and relies on the Uniform Resource Locator (URL) path to identify resources, making it a lightweight, stateless alternative to NETCONF for programmatic configuration and state retrieval.
D
NETCONF <edit-config>: Operation to modify configuration with options like merge, replace, create, delete
The NETCONF <edit-config> operation is a core RPC defined in RFC 6241 that allows a client to change the target configuration datastore (candidate or running) by specifying a set of operations: merge, replace, create, delete, and remove. It uses the 'operation' attribute to control how each data node is applied, and supports options like 'error-option' and 'test-option'—giving network engineers fine-grained transactional control over configuration updates.
E
RESTCONF PATCH: HTTP method used for partial updates to a resource
The RESTCONF PATCH method, defined in RFC 8040, applies a partial update to a target resource using the media type 'application/yang-data+json' (or XML). Unlike PUT, which replaces the entire resource, PATCH modifies only the fields specified in the request body, preserving all other existing data—ideal for incremental configuration changes in network automation workflows.

Question 14mediummatching

Match each REST API method to the action it most closely represents in a typical network automation workflow.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Retrieve a resource

Create a new resource

Update or replace a resource

Remove a resource

Trap 1: GET retrieves data, POST creates new resources, PUT partially…

This incorrect mapping also swaps PUT and PATCH, but the more fundamental issue is that it treats the method semantics as interchangeable. In RESTful APIs, using PATCH for a full update would require a standard body where none exists, and using PUT for a partial update violates the requirement that PUT's payload be the same as what a GET would return. For network automation, this can lead to inconsistent state and failed idempotent retries.

Trap 2: GET retrieves data, POST updates/replaces, PUT creates new…

This option inverts the roles of POST and PUT. In REST, POST is used to create a new resource (e.g., adding a VLAN), while PUT replaces the entire representation of an existing resource (e.g., updating a full interface config). Because PUT is idempotent and POST is not, swapping them breaks the contract that network automation tools rely on for safe retries.

Trap 3: GET retrieves data, POST creates new resources, PUT partially…

This option mistakenly assigns partial updates to PUT and full replacement to PATCH. The HTTP method PUT is defined by RFC 7231 to replace the target resource with the enclosed representation, making it idempotent, whereas PATCH is explicitly for partial modifications, such as changing only the description field of a device interface. Swapping these would cause a client sending a small change via PUT to wipe out unrelated configuration.

A
GET retrieves data, POST creates new resources, PUT updates/replaces, PATCH partially updates, DELETE removes, and OPTIONS queries available methods.
This is correct because it accurately describes the standard REST API methods and their actions in network automation workflows. GET is used to retrieve configuration or status data, POST to create new resources like interfaces or VLANs, PUT to replace entire resources, PATCH to apply partial updates, DELETE to remove resources, and OPTIONS to discover supported methods.
B
GET retrieves data, POST creates new resources, PUT partially updates, PATCH updates/replaces, DELETE removes, and OPTIONS queries available methods.
Why wrong: This incorrect mapping also swaps PUT and PATCH, but the more fundamental issue is that it treats the method semantics as interchangeable. In RESTful APIs, using PATCH for a full update would require a standard body where none exists, and using PUT for a partial update violates the requirement that PUT's payload be the same as what a GET would return. For network automation, this can lead to inconsistent state and failed idempotent retries.
C
GET retrieves data, POST updates/replaces, PUT creates new resources, PATCH partially updates, DELETE removes, and OPTIONS queries available methods.
Why wrong: This option inverts the roles of POST and PUT. In REST, POST is used to create a new resource (e.g., adding a VLAN), while PUT replaces the entire representation of an existing resource (e.g., updating a full interface config). Because PUT is idempotent and POST is not, swapping them breaks the contract that network automation tools rely on for safe retries.
D
GET retrieves data, POST creates new resources, PUT partially updates, PATCH updates/replaces, DELETE removes, and OPTIONS queries available methods.
Why wrong: This option mistakenly assigns partial updates to PUT and full replacement to PATCH. The HTTP method PUT is defined by RFC 7231 to replace the target resource with the enclosed representation, making it idempotent, whereas PATCH is explicitly for partial modifications, such as changing only the description field of a device interface. Swapping these would cause a client sending a small change via PUT to wipe out unrelated configuration.

Question 15mediummatching

Drag each automation or API concept from the left to its corresponding description on the right. Not all descriptions are used.

Concepts: - Northbound API - Southbound API - JSON - HTTPS

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Application-facing interface to the controller

Controller-facing interface toward managed infrastructure

Structured data format

Secure transport for API communication

A
Application-facing interface to the controller
This is the correct match for a Northbound API. A northbound API is the programmatic interface exposed by an SDN controller to applications, orchestration platforms, or business logic, allowing them to request network services, retrieve telemetry, and configure policies without low-level device details. Because it faces the application layer, 'Application-facing interface to the controller' precisely captures its role.
B
Controller-facing interface toward managed infrastructure
This is the correct match for a Southbound API. The southbound API is used by the SDN controller to communicate with the managed network infrastructure, such as switches, routers, and wireless access points, using protocols like OpenFlow, NETCONF, or SNMP. The phrase 'Controller-facing interface toward managed infrastructure' accurately describes this downward communication path from the controller to devices.
C
Structured data format
This is the correct match for JSON (JavaScript Object Notation). JSON is a text-based, structured data format that represents objects as collections of key-value pairs and arrays, making it ideal for exchanging data between REST API clients and servers. Its structure is human-readable while still being easily parsed by programming languages, so 'Structured data format' is the right definition.
D
Secure transport for API communication
This is the correct match for HTTPS (Hypertext Transfer Protocol Secure). HTTPS encapsulates HTTP traffic within a TLS (Transport Layer Security) session, providing confidentiality, integrity, and authentication for REST API requests and responses over the network. Because it secures the transport channel, the description 'Secure transport for API communication' directly aligns with HTTPS.

Question 16hardmultiple choice

Why is a northbound API generally more useful to orchestration software than a human-readable CLI screen?

Trap 1: Because CLI output cannot be read by humans.

This is incorrect because CLI output is actually formatted specifically for human engineers, using tables, spacing, and colors that are easy to read but hard to parse reliably. The real disadvantage of CLI is its irregular, presentation-oriented syntax, not that humans can't read it. Orchestration platforms struggle to extract data from CLI text, whereas an API returns consistent fields and types.

Trap 2: Because APIs remove the need for authentication.

This assertion is false because APIs, including northbound APIs, always require authentication and authorization, typically via API keys, OAuth tokens, or certificates. Rather than removing security, these APIs enforce it over HTTPS while allowing granular, programmatic access. Orchestration software must still present valid credentials to interact with the controller or network device.

Trap 3: Because orchestration software cannot use HTTPS.

This is erroneous because orchestration platforms extensively use HTTPS, especially with REST-based northbound APIs, which are built on standard HTTP methods over TLS. HTTPS is not a limitation; it is the preferred secure transport for machine-to-machine communication. Software can easily consume HTTPS APIs through common libraries, whereas CLI and other methods are less standardized.

A
Because the API provides a structured interface intended for software interaction.
This is correct because a northbound API exposes network functions through a structured, software-friendly interface, typically using JSON or XML models. This enables orchestration tools to programmatically query state, push configuration changes, and validate results in a predictable, machine-readable format. Such structured interaction is far more efficient and reliable for automation than screen-scraping or manual commands.
B
Because CLI output cannot be read by humans.
Why wrong: This is incorrect because CLI output is actually formatted specifically for human engineers, using tables, spacing, and colors that are easy to read but hard to parse reliably. The real disadvantage of CLI is its irregular, presentation-oriented syntax, not that humans can't read it. Orchestration platforms struggle to extract data from CLI text, whereas an API returns consistent fields and types.
C
Because APIs remove the need for authentication.
Why wrong: This assertion is false because APIs, including northbound APIs, always require authentication and authorization, typically via API keys, OAuth tokens, or certificates. Rather than removing security, these APIs enforce it over HTTPS while allowing granular, programmatic access. Orchestration software must still present valid credentials to interact with the controller or network device.
D
Because orchestration software cannot use HTTPS.
Why wrong: This is erroneous because orchestration platforms extensively use HTTPS, especially with REST-based northbound APIs, which are built on standard HTTP methods over TLS. HTTPS is not a limitation; it is the preferred secure transport for machine-to-machine communication. Software can easily consume HTTPS APIs through common libraries, whereas CLI and other methods are less standardized.

Question 17mediummatching

Match each HTTP method to the most accurate action it commonly represents in REST-style APIs.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Retrieve existing information

Submit or create data

Update or replace an existing resource

Remove a resource

Trap 1: GET: Create a new resource

Creating a new resource involves submitting a payload to the server, which GET cannot carry reliably since its parameters are typically limited to the URL and it is defined as a safe method. The POST method is designed for creating resources, sending data in the request body and returning a 201 Created status. If GET were used for creation, it would break safety guarantees, and any intermediate proxy or browser preloader could unknowingly execute the operation.

Trap 2: GET: Update an existing resource

Updating a resource changes its state, which contradicts GET's mandatory safety constraint that forbids side effects. The PUT method replaces an entire resource, while PATCH applies partial modifications, both explicitly supporting request bodies and state changes. Using GET to update resources is non-conformant, and because GET requests should be idempotent and cacheable, such misuse would lead to unintended repeated updates and caching anomalies.

Trap 3: GET: Delete a resource

Deleting a resource requires state-changing semantics that GET explicitly lacks, as GET requests are meant to be safe and require no server-side modifications. The DELETE method is the correct HTTP verb for removal, offering explicit intent and idempotency. Using GET to delete a resource violates RFC 9110 and can be accidentally triggered by prefetching, cache warmers, or automated link checkers, leading to data loss.

A
GET: Retrieve data from a resource
GET is a safe and idempotent HTTP method defined by RFC 9110, meaning it must not alter server state and returns a representation of a specified resource. In RESTful CRUD operations, this maps directly to the read operation, allowing clients to fetch data without side effects. Repeating the same GET request yields the same result, confirming its read-only nature.
B
GET: Create a new resource
Why wrong: Creating a new resource involves submitting a payload to the server, which GET cannot carry reliably since its parameters are typically limited to the URL and it is defined as a safe method. The POST method is designed for creating resources, sending data in the request body and returning a 201 Created status. If GET were used for creation, it would break safety guarantees, and any intermediate proxy or browser preloader could unknowingly execute the operation.
C
GET: Update an existing resource
Why wrong: Updating a resource changes its state, which contradicts GET's mandatory safety constraint that forbids side effects. The PUT method replaces an entire resource, while PATCH applies partial modifications, both explicitly supporting request bodies and state changes. Using GET to update resources is non-conformant, and because GET requests should be idempotent and cacheable, such misuse would lead to unintended repeated updates and caching anomalies.
D
GET: Delete a resource
Why wrong: Deleting a resource requires state-changing semantics that GET explicitly lacks, as GET requests are meant to be safe and require no server-side modifications. The DELETE method is the correct HTTP verb for removal, offering explicit intent and idempotency. Using GET to delete a resource violates RFC 9110 and can be accidentally triggered by prefetching, cache warmers, or automated link checkers, leading to data loss.

Question 18mediummultiple choice

A network engineer needs to automate the configuration of multiple Cisco IOS XE routers in a data center. The team requires a standard, vendor-neutral data modeling language to define the configuration parameters, and they need a protocol that uses XML-based remote procedure calls over SSH for secure, reliable configuration transactions. Which combination of technologies best meets these requirements?

Trap 1: Use YANG data models combined with RESTCONF over HTTPS.

YANG models can describe network state, but RESTCONF is the wrong management protocol here because it is a RESTful HTTP-based API that runs over HTTPS and uses JSON/XML representations, not XML-based RPC sessions. NETCONF is the protocol that establishes an SSH transport and issues XML RPCs for configuration; RESTCONF does not use SSH for its transport and does not define the same remote-procedure-call model. Therefore, although YANG is acceptable, RESTCONF fails the transport requirement.

Trap 2: Use CLI commands combined with NETCONF over SSH.

CLI commands are device-specific, interactive, and text-based, so they do not constitute a structured data model for NETCONF to manipulate; NETCONF expects YANG-defined data trees and uses XML RPCs, not screen-scraping of command-line output. Although NETCONF does run over SSH, adding CLI commands does not make the solution model-driven or vendor-neutral, and it still relies on the device's proprietary command syntax rather than a standardized model. Thus, the transport is correct but the data-modeling element is missing.

Trap 3: Use CLI commands combined with RESTCONF over HTTPS.

This combination fails on both counts: CLI commands are not a data-modeling language, and RESTCONF is a RESTful API using HTTPS rather than an XML-RPC protocol over SSH. A RESTCONF request targets a URI that maps to YANG containers or lists, so sending arbitrary CLI text would not map to any standard resource. Additionally, SSH and XML-RPC framing are never provided by RESTCONF, so this selection does not meet the secure, standardized RPC requirement at all.

A
Use YANG data models combined with RESTCONF over HTTPS.
Why wrong: YANG models can describe network state, but RESTCONF is the wrong management protocol here because it is a RESTful HTTP-based API that runs over HTTPS and uses JSON/XML representations, not XML-based RPC sessions. NETCONF is the protocol that establishes an SSH transport and issues XML RPCs for configuration; RESTCONF does not use SSH for its transport and does not define the same remote-procedure-call model. Therefore, although YANG is acceptable, RESTCONF fails the transport requirement.
B
Use YANG data models combined with NETCONF over SSH.
YANG plus NETCONF over SSH is the standard model-driven management combination: YANG provides a vendor-neutral, hierarchical data model for configuration and state data, while NETCONF carries those models in XML-encoded RPCs over an encrypted SSH session. The NETCONF session supports transactions across multiple configuration datastores (candidate, running, startup), giving reliable commit/rollback behavior. This pairing exactly matches the requirements for a standardized data model and secure, remote procedure-style configuration exchange.
C
Use CLI commands combined with NETCONF over SSH.
Why wrong: CLI commands are device-specific, interactive, and text-based, so they do not constitute a structured data model for NETCONF to manipulate; NETCONF expects YANG-defined data trees and uses XML RPCs, not screen-scraping of command-line output. Although NETCONF does run over SSH, adding CLI commands does not make the solution model-driven or vendor-neutral, and it still relies on the device's proprietary command syntax rather than a standardized model. Thus, the transport is correct but the data-modeling element is missing.
D
Use CLI commands combined with RESTCONF over HTTPS.
Why wrong: This combination fails on both counts: CLI commands are not a data-modeling language, and RESTCONF is a RESTful API using HTTPS rather than an XML-RPC protocol over SSH. A RESTCONF request targets a URI that maps to YANG containers or lists, so sending arbitrary CLI text would not map to any standard resource. Additionally, SSH and XML-RPC framing are never provided by RESTCONF, so this selection does not meet the secure, standardized RPC requirement at all.

Question 19mediummultiple choice

A network engineer is evaluating monitoring technologies for a large enterprise network that requires high-frequency, low-latency traffic data collection with support for custom fields. The solution must also support encryption and authentication to prevent tampering. Which technology best meets these requirements?

Trap 1: Configure SNMPv2c with community strings and polling every 30…

SNMPv2c relies on plaintext community strings passed in every packet, offering no encryption, and its polling model means data is only collected at intervals, missing high-frequency or event-driven changes. A 30-second polling interval introduces significant latency and overhead, and it cannot push data on demand or support custom data models for granular, real-time metrics. This approach fundamentally lacks the low-latency, push-based architecture needed for streaming telemetry.

Trap 2: Deploy NetFlow v9 with custom flow records and SNMPv3 for…

NetFlow v9 is designed for export of sampled flow records, not for real-time streaming of device state or telemetry; its pull-based or scheduled export adds delay and is not event-driven. Adding SNMPv3 for encryption does not protect NetFlow data because they are separate protocols, and NetFlow v9 itself has no built-in security. Custom flow records still operate within the rigid flow template structure, falling short of the flexible, YANG-modeled data supported by gRPC streaming.

Trap 3: Use IPFIX with UDP export and add authentication via MD5 hashing.

IPFIX over UDP cannot provide the reliable, low-latency push required for streaming telemetry; UDP is connectionless and subject to packet loss without retransmission. MD5 hashing only authenticates message integrity, not confidentiality, and IPFIX templates must be exchanged out-of-band, adding complexity. Furthermore, IPFIX is flow-based, not a mechanism for continuous model-driven state streaming.

A
Configure SNMPv2c with community strings and polling every 30 seconds.
Why wrong: SNMPv2c relies on plaintext community strings passed in every packet, offering no encryption, and its polling model means data is only collected at intervals, missing high-frequency or event-driven changes. A 30-second polling interval introduces significant latency and overhead, and it cannot push data on demand or support custom data models for granular, real-time metrics. This approach fundamentally lacks the low-latency, push-based architecture needed for streaming telemetry.
B
Implement streaming telemetry using gRPC with TLS and YANG data models.
Streaming telemetry with gRPC over TLS delivers continuous, high-frequency push updates, avoiding the overhead of repeated polling requests and reducing latency to near-real-time. The use of YANG data models provides a structured, vendor-neutral schema that supports custom fields and hierarchical data, unlike fixed-format flow records. TLS ensures both encryption and authentication, protecting the data stream in transit, which makes this the correct choice for modern scalable network monitoring.
C
Deploy NetFlow v9 with custom flow records and SNMPv3 for encryption.
Why wrong: NetFlow v9 is designed for export of sampled flow records, not for real-time streaming of device state or telemetry; its pull-based or scheduled export adds delay and is not event-driven. Adding SNMPv3 for encryption does not protect NetFlow data because they are separate protocols, and NetFlow v9 itself has no built-in security. Custom flow records still operate within the rigid flow template structure, falling short of the flexible, YANG-modeled data supported by gRPC streaming.
D
Use IPFIX with UDP export and add authentication via MD5 hashing.
Why wrong: IPFIX over UDP cannot provide the reliable, low-latency push required for streaming telemetry; UDP is connectionless and subject to packet loss without retransmission. MD5 hashing only authenticates message integrity, not confidentiality, and IPFIX templates must be exchanged out-of-band, adding complexity. Furthermore, IPFIX is flow-based, not a mechanism for continuous model-driven state streaming.

Question 20mediummultiple choice

An automation script must retrieve the current configuration state of a device from a REST API without modifying anything. Which HTTP method should it use?

Exhibit

Goal: Read existing data only

Trap 1: DELETE

DELETE is wrong because it is an HTTP method whose sole purpose is to remove the identified resource from the server. Issuing DELETE against a network device would attempt to delete the configuration or the resource path itself, not return its contents. Even if the request were denied, it represents a state-changing operation, which directly contradicts the requirement to merely retrieve the current configuration.

Trap 2: PUT

PUT is wrong because it is designed to replace or create a resource using the payload sent in the request body, not to fetch one. In network automation, PUT would overwrite the entire configuration with whatever data the script supplies, causing an unintended change. Although PUT is idempotent, its idempotency applies to repeated writes, and it cannot serve as a read operation for retrieving the existing configuration.

Trap 3: POST

POST is wrong because it is intended for submitting data to be processed, typically creating a new subordinate resource or triggering an action on the server. Using POST to retrieve configuration would either create an unwanted object or execute an operation, both of which violate the requirement for a non-mutating read. Unlike GET, POST is not defined as a safe or idempotent method, so it cannot reliably be used to simply return the current configuration.

A
DELETE
Why wrong: DELETE is wrong because it is an HTTP method whose sole purpose is to remove the identified resource from the server. Issuing DELETE against a network device would attempt to delete the configuration or the resource path itself, not return its contents. Even if the request were denied, it represents a state-changing operation, which directly contradicts the requirement to merely retrieve the current configuration.
B
GET
GET is the correct choice because it is a safe, idempotent HTTP method defined by RFC 7231 specifically for retrieving the current representation of a resource. It performs no state change on the server, so the script can fetch the running configuration without risking any modification. The response body carries the requested configuration data, making GET the semantically exact operation for a read-only retrieval.
C
PUT
Why wrong: PUT is wrong because it is designed to replace or create a resource using the payload sent in the request body, not to fetch one. In network automation, PUT would overwrite the entire configuration with whatever data the script supplies, causing an unintended change. Although PUT is idempotent, its idempotency applies to repeated writes, and it cannot serve as a read operation for retrieving the existing configuration.
D
POST
Why wrong: POST is wrong because it is intended for submitting data to be processed, typically creating a new subordinate resource or triggering an action on the server. Using POST to retrieve configuration would either create an unwanted object or execute an operation, both of which violate the requirement for a non-mutating read. Unlike GET, POST is not defined as a safe or idempotent method, so it cannot reliably be used to simply return the current configuration.