Drag and drop the following steps into the correct order to retrieve the operational status of interface GigabitEthernet0/0 using NETCONF and the ietf-interfaces YANG model.

Establish an SSH connection to the network device on TCP port 830, the standard NETCONF port.. First, establish an SSH connection to the device's NETCONF subsystem (TCP port 830). The NETCONF protocol then performs a capability exchange via messages to ensure both sides support the required YANG models. Next, a RPC with an XPath filter is sent to request the specific interface status. The server replies with containing the XML data. The client parses the XML to extract the desired value. Finally, the NETCONF session is closed by a RPC, and the SSH connection is terminated. This order ensures a proper NETCONF transaction lifecycle.

CCNA AI and Network Operations Practice Question

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

6Step 6

Correct answer & explanation

✓

Establish an SSH connection to the network device on TCP port 830, the standard NETCONF port.

First, establish an SSH connection to the device's NETCONF subsystem (TCP port 830). The NETCONF protocol then performs a capability exchange via <hello> messages to ensure both sides support the required YANG models. Next, a <get> RPC with an XPath filter is sent to request the specific interface status. The server replies with <rpc-reply> containing the XML data. The client parses the XML to extract the desired value. Finally, the NETCONF session is closed by a <close-session> RPC, and the SSH connection is terminated. This order ensures a proper NETCONF transaction lifecycle.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Establish an SSH connection to the network device on TCP port 830, the standard NETCONF port.
Why this is correct
Establishing an SSH connection to TCP port 830 is the mandatory transport setup for NETCONF as defined in RFC 6241. Port 830 is the IANA-assigned port for NETCONF over SSH, distinguishing it from the CLI's standard SSH port 22. This step creates a secure, encrypted channel over which all NETCONF XML messages will be exchanged, and it is the foundation upon which the NETCONF session is built. Without this connection, no NETCONF operations can occur.
✓
Exchange NETCONF <hello> messages to negotiate capabilities, including support for the ietf-interfaces YANG model.
Why this is correct
The <hello> message exchange is the first protocol step after the SSH connection is established. Both the client and server send their respective <hello> messages, listing supported capabilities such as NETCONF base revisions and specific YANG models like ietf-interfaces. This negotiation ensures that the client knows which YANG modules are available for data retrieval and which features (e.g., XPath filtering) are supported. The server's <hello> also includes the session-id, which is essential for tracking the session and is a prerequisite before any RPC can be issued.
✓
Send a NETCONF <get> RPC with an XPath filter specifying '/interfaces-state/interface[name='GigabitEthernet0/0']/oper-status'.
Why this is correct
Sending a <get> RPC with an XPath filter is a precise way to retrieve operational state data. The <get> operation retrieves both configuration and state data, but the XPath filter '/interfaces-state/interface[name='GigabitEthernet0/0']/oper-status' restricts the response to only the desired leaf. The filter element uses the type attribute set to 'xpath' and specifies the namespace of the ietf-interfaces model (though the example omits the namespace prefix for brevity). This approach minimizes network overhead and simplifies parsing by returning only the exact operational status of the specified interface.
✓
Receive the NETCONF <rpc-reply> message containing the XML data for the interface operational status.
Why this is correct
The <rpc-reply> is the server's response to the <get> RPC and is an integral part of the NETCONF message protocol. It carries a message-id attribute that matches the corresponding request, allowing the client to correlate responses in concurrent or sequential operations. The reply contains a <data> element (unless an error occurs) that wraps the XML payload matching the filter, with the oper-status node present. Receiving this reply indicates that the server successfully processed the RPC and that the requested data is included in the payload.
✓
Parse the XML response to extract the 'oper-status' element value.
Why this is correct
Parsing the XML response is the client-side step where the extracted oper-status value is obtained from the returned XML document. Using an XML parser like lxml or ElementTree, the client navigates the namespace-aware tree to locate the <oper-status> element, which is nested under the appropriate <interface> and <interfaces-state> nodes. The text content of that element is the operational status string, such as 'up' or 'down', which can then be used for automation logic, validation, or reporting. This step is where the raw XML is converted into machine-readable data that the application can consume.
✓
Close the NETCONF session by sending a <close-session> RPC and terminate the SSH connection.
Why this is correct
The <close-session> RPC is the proper way to terminate a NETCONF session per RFC 6241. When sent, the server responds with an <rpc-reply> containing an <ok> element, after which the NETCONF session is closed and the underlying SSH transport connection is typically torn down. This orderly shutdown releases all resources on the device, including any locks or event subscriptions, and avoids leaving orphaned sessions that might persist until a timeout. Forcing the TCP connection closed without <close-session> can be less graceful and potentially leave device resources in an uncertain state.

CCNA AI and Network Operations Practice Question

Why each option matters

Option-by-option breakdown

Question Discussion