Free 350-401 Practice Test Questions 2026

Explanation:

Data modeling languages, such as YANG, JSON Schema, and XML Schema Definition (XSD), provide a standardized way to define the structure, syntax, constraints, and hierarchy of data independent of any specific encoding format. A data model describes what data looks like—its data types, mandatory fields, ranges, relationships, and nesting—without specifying how that data is serialized on the wire. This separation of model from encoding is critical because the same YANG model, for example, can be encoded as XML (used by NETCONF), JSON (used by RESTCONF), or CBOR (used by CoAP), depending on the transport protocol or device capability. This abstraction enables multi-vendor interoperability, as network devices from different vendors can share the same data model (e.g., ietf-interfaces) while using different encoding formats. This is the foundation of model-driven programmability and network automation.

Why the others are wrong:

B (to specify algorithms necessary to decode binary-encoded protocol data units): This describes the function of encoding rules or codecs (e.g., how CBOR encodes data into binary). The data model defines structure; encoding rules define serialization and deserialization.

C (to translate encoded data for interoperability between different CPU architectures): This pertains to network byte order or endianness conversion, a low-level transport concern handled by protocols like TCP/IP, not by data modeling languages. Data models are completely agnostic to CPU architectures.

D (to provide a framework to describe data flow patterns in networks):
This describes data flow diagrams or traffic flow analysis, used in network design and monitoring. This is unrelated to data modeling languages, which focus on data structure, not traffic movement.

References:

RFC 7950 - YANG 1.1: "YANG is a data modeling language used to model configuration and state data... independent of the encoding format."

RFC 8040 - RESTCONF Protocol: "RESTCONF uses YANG data models and can encode data in XML or JSON."

Explanation:

In the Cisco SD-WAN architecture, vManage is the centralized network management system that provides a single pane of glass for configuration, monitoring, and troubleshooting . To interact with the fabric devices such as vEdge routers, cEdge routers, and vSmart controllers, vManage uses southbound APIs .

The term "southbound API" refers to the interface used by a controller or management system to communicate downward with the underlying network devices it manages. In this context, vManage communicates with fabric devices using protocols such as NETCONF, RESTCONF, and OMP (Overlay Management Protocol) over secure TLS/DTLS tunnels . This southbound communication allows vManage to push device configurations (via templates), deploy policies, collect telemetry and statistics, perform software upgrades, and monitor device health across the entire SD-WAN fabric .

The separation between southbound and northbound APIs is a fundamental concept in SDN architectures. Northbound APIs are used to communicate upward from the controller to external applications, orchestration systems, or the user interface, typically using REST APIs .

Why the others are wrong:

A (northbound API): This is used for communication from vManage to external applications or the GUI. While vManage does expose northbound REST APIs for programmatic access, these are not used to interact with the fabric devices themselves .

B (RESTCONF): RESTCONF is a specific protocol that vManage may use as part of its southbound communication, but it is not the general term for the interface. The question asks for what is used to interact with fabric devices, and "southbound API" is the correct architectural term .

D (IPsec): While IPsec is used in SD-WAN for secure data plane tunnels between WAN Edge routers, it is not the primary interface used by vManage to manage and configure fabric devices. vManage uses NETCONF/RESTCONF over TLS/DTLS for management plane communication .

References:

Cisco SD-WAN Architecture Documentation: Southbound APIs are used by controllers to communicate with network devices

Cisco Press - Cisco Catalyst SD-WAN Components: vManage provides configuration, monitoring, and troubleshooting via templates and policies

Explanation:

In LISP (Locator/ID Separation Protocol), when an Ingress Tunnel Router (ITR) needs to forward traffic to a destination but does not have the EID-to-RLOC mapping in its local map-cache, it sends a Map-Request to resolve the destination EID. The map resolver is the specific infrastructure component responsible for accepting these Encapsulated Map-Requests from ITRs and finding the appropriate EID-to-RLOC mapping. Acting like a DNS resolver, the map resolver consults the mapping database system to determine if the destination IP address belongs to the EID namespace and then identifies the correct mapping. Once the map resolver locates the mapping, it forwards the request to the appropriate map server or directly to the Egress Tunnel Router (ETR) that holds the authoritative mapping for that EID prefix. The map resolver is a critical component in the LISP control plane, enabling ITRs to dynamically discover reachability information without requiring manual configuration of every destination.

Why the others are wrong:

A (ingress tunnel router): The ITR is the device that initiates the Map-Request and encapsulates traffic into LISP packets. While it triggers the mapping lookup process, it is not responsible for "finding" the mapping from a database perspective. The ITR is the client that asks the question, not the server that answers it.

C (egress tunnel router): The ETR is the authoritative device that holds the actual EID-to-RLOC mapping for its site and responds with a Map-Reply containing the mapping information. However, the ETR does not perform the initial search or database lookup—it only provides the mapping when queried.

D (map server): The map server learns and registers EID-prefix mappings from ETRs and maintains a database of authoritative mappings. While the map server plays a role in forwarding Map-Requests to the correct ETR, the responsibility for initially finding the mapping by consulting the database belongs to the map resolver, not the map server.

References:

RFC 9301 - LISP Specification: "A network infrastructure component that accepts LISP Encapsulated Map-Requests, typically from an ITR... finds the appropriate EID-to-RLOC mapping by consulting a mapping database system."

Cisco LISP Configuration Guide: "The map resolver handles Map-Request messages from ITRs and resolves EID-to-RLOC mappings."

Explanation:

In Cisco SD-Access architecture, the Edge Node is the access-layer device that connects wired endpoints such as users, printers, and servers to the fabric overlay network. The Edge Node performs two primary functions. First, it authenticates and authorizes endpoints using security mechanisms like 802.1X (port-based authentication), MAB (MAC Authentication Bypass), or static configuration. This ensures that only legitimate devices gain access to the network and that each endpoint is assigned the appropriate Scalable Group Tag (SGT) for policy enforcement. Second, the Edge Node maintains a local Host Tracking Database that maps endpoint identifiers (such as IP addresses or MAC addresses) to their current Routing Locator (RLOC), which is the Edge Node's own IP address in the underlay network. This mapping is then registered with the central Control Plane Node (based on LISP), enabling the fabric to track endpoint locations as devices roam across the network. Together, these functions allow the fabric to provide secure access, mobility, and consistent policy enforcement.

Why the others are incorrect:

A (provides multiple entry and exit points for fabric traffic):
This describes the function of a Fabric Border Node, not an Edge Node. Border Nodes provide connectivity between the SD-Access fabric and external networks, serving as multiple gateways for traffic entering or leaving the fabric domain. Edge Nodes only handle endpoint connectivity, not external routing.

B (provides the default exit point for fabric traffic):
This is also a function of the Fabric Border Node, which serves as the default gateway for traffic destined outside the fabric. Border Nodes handle inter-VLAN routing and connectivity to traditional networks, Data Centers, or the Internet.

C (provides the default entry point for fabric traffic):
This is another Border Node function. Border Nodes are the entry points for external traffic entering the SD-Access fabric from outside networks. Edge Nodes do not handle external traffic—they only connect internal endpoints.

References:

Cisco SD-Access Solution Design Guide: "Edge nodes provide endpoint authentication and host tracking database for endpoint-to-RLOC mapping."

Cisco Catalyst Center User Guide: "Edge node acts as an access-layer switch that authenticates endpoints and registers them to the control plane."

Explanation:

A JSON Web Token (JWT) is an open standard (RFC 7519) used for securely transmitting information between parties as a JSON object. The token is a compact, URL-safe string composed of three distinct parts separated by dots (.):

Header: Contains metadata about the token, typically the signing algorithm used (e.g., HS256 or RS256) and the token type (JWT). This is Base64Url-encoded.

Payload: Contains the claims, which are statements about the entity (user) and additional data. Claims can be registered (e.g., iss, exp, sub), public, or private. This is also Base64Url-encoded.

Signature: Created by taking the encoded header and payload, concatenating them with a dot, and signing them using the specified algorithm and a secret key (for HMAC) or a private key (for RSA). The signature ensures the token's integrity and authenticity, allowing the receiver to verify that the token was not tampered with.

Why other options are incorrect:

A. header and payload:
This omits the signature, which is essential for verifying token integrity. Without the signature, the token would be just an unverified JSON object, compromising security. All three parts are required for a valid JWT.

B. three parts separated by dots:
version, header, and signature: This is incorrect because JWT does not include a version field. The first part is the header, not a version. The dot-separated format always follows header, payload, and signature.

C. payload and signature:
This omits the header, which is necessary to inform the recipient about the signing algorithm used to validate the signature. Without the header, the recipient cannot determine how to verify the token's authenticity.

References:

RFC 7519 - JSON Web Token (JWT): "A JWT is represented as a sequence of base64url-encoded values, separated by period characters. The three parts are: Header, Payload, and Signature."

IETF RFC 7519: "The header and payload are Base64Url-encoded JSON objects, and the signature is generated using the algorithm specified in the header."

Explanation:

The Cisco Embedded Event Manager (EEM) applet is triggered when a user enters configuration mode via the conf t command. The requirement is to generate both an SNMP trap and a critically level log message. For the log message to be sent at critical level, the syslog action must include the priority critical keyword. Additionally, the order of action labels (e.g., 1.0 and 1.1) is irrelevant as EEM executes actions sequentially based on the label numbering. Option D correctly configures two separate actions:

action 1.0 snmp-trap strdata "Configuration change alarm" – sends an SNMP trap with the specified string.

action 1.1 syslog priority critical msg "Configuration change alarm" – generates a syslog message at critical severity.

This meets the requirement of receiving both an SNMP trap and a critical-level log message.


Why other options are incorrect:

A. Option A – This is missing the priority critical keyword, so the syslog message would be sent at the default severity (usually informational), not at critical level. This violates the requirement.

B. Option B – This only generates an SNMP trap and does not produce any syslog message. Without the syslog action, the critical-level log requirement is not fulfilled.

C. Option C– While this uses the priority critical keyword, it incorrectly applies it to the snmp-trap action. The priority critical parameter is only valid for the syslog action, not for snmp-trap. This would cause a syntax error and the applet would fail to execute properly.

References:

Cisco IOS Embedded Event Manager Command Reference: "syslog priority critical – Specifies the severity level of the syslog message"

Cisco EEM Configuration Guide: "The snmp-trap action generates an SNMP trap; the syslog action generates a syslog message with optional priority"

Explanation:

Cisco SD-Access is built on a fabric architecture that separates network functions into distinct planes. The control plane in SD-Access is based on LISP (Locator/ID Separation Protocol). LISP is responsible for mapping endpoint identifiers (EIDs) to routing locators (RLOCs), enabling the fabric to track endpoint locations as devices move across the network. When an endpoint connects to an Edge Node, its location is registered with the control plane. When another device needs to communicate with that endpoint, the control plane provides the correct mapping, allowing traffic to be forwarded to the current location without relying on traditional Layer 2 flooding or MAC address learning. LISP is the foundational protocol that enables host mobility, scalability, and segmentation in the SD-Access fabric.

Why other options are incorrect:

A. IS-IS:
This is a routing protocol used in the underlay network to provide reachability between fabric devices (typically OSPF or IS-IS). It is not the control plane protocol for the overlay SD-Access fabric.

C. Cisco TrustSec:
This provides the policy plane in SD-Access, using Scalable Group Tags (SGTs) for group-based segmentation and policy enforcement. It does not handle endpoint-to-location mapping.

D. VXLAN: This is the data plane encapsulation protocol used in SD-Access. It provides overlay segmentation using VNIs but does not handle control plane functions.

References:

Cisco SD-Access Solution Design Guide: "The control plane is based on LISP, which provides endpoint-to-location mapping"

ENCOR 350-401 Official Cert Guide, Chapter 23: "LISP provides the control plane for SD-Access, handling EID-to-RLOC mapping and host mobility"

Explanation:

RESTCONF is an HTTP-based protocol defined in RFC 8040 that uses standard HTTP methods to provide Create, Read, Update, Delete (CRUD) operations on YANG-defined data . The protocol supports a specific set of HTTP methods: OPTIONS, HEAD, GET, POST, PATCH, PUT, and DELETE .

E. The GET method is used to retrieve data and metadata about a resource. When a client sends a GET request, the server returns the requested configuration data, state data, or both in the response body using either XML or JSON encoding .

C. The HEAD method is identical to GET except that the server only returns the response headers without the message body. It is supported for all resources that support the GET method and is commonly used to verify whether a resource exists or to check metadata (such as content type or last-modified time) without retrieving the full data payload .

Why other options are incorrect:

A. PULL: This is not an HTTP method and is not supported by RESTCONF. RESTCONF uses standard HTTP methods only. "PULL" typically refers to a data retrieval pattern, not a protocol operation .

B. ADD: This is not a valid HTTP method. The create operation in RESTCONF is performed using the POST method (for creating resources) or PUT (for creating or replacing a resource) .

D. REMOVE: This is not a valid HTTP method. The delete operation in RESTCONF is performed using the DELETE method .

F. PUSH:This is not an HTTP method and is not supported by RESTCONF. "Push" typically refers to server-sent events or notifications, which are not standard RESTCONF operations .

References:

RFC 8040 - RESTCONF Protocol: Specifies the standard methods supported: OPTIONS, HEAD, GET, POST, PATCH, PUT, and DELETE

CCNP and CCIE Enterprise Core ENCOR 350-401 Official Cert Guide: Lists supported operations as "DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT"

Explanation:

The Access Point (AP) mode that is specifically designed to analyze the spectrum and detect sources of RF interference is the Monitor mode.

Cisco's Spectrum Expert™ Wi-Fi solution integrates with the wireless network to deliver real-time spectrum intelligence. It detects, classifies, and locates sources of interference in the 2.4-GHz and 5-GHz bands.

To perform a full spectrum analysis across multiple channels, you must configure the AP in Monitor mode. This dedicates the AP's radios to monitoring and analyzing the RF environment, enabling the network administrator to identify sources of interference like analog cordless phones, wireless video cameras, or microwave ovens.

Why other options are incorrect:

B. Rogue detector:
In this mode, the AP radios are disabled, and the AP monitors the LAN to detect on-wire rogue activity. It does not perform spectrum analysis.

C. SE-Connect:
This mode provides a dedicated connection for spectrum analysis software like Cisco Spectrum Expert or Chanalyzer. While it is used for spectrum analysis, it is the SE-Connect mode that facilitates the connection, but the core function of analyzing the spectrum to detect interference is accomplished by the Monitor mode AP.

D. Sniffer:
In this mode, the AP operates in promiscuous mode to capture all Wi-Fi traffic on a particular channel. These packets are tunneled to the controller and forwarded to a machine running packet analyzer software like Wireshark for deep packet analysis. It is used for troubleshooting network activity, not for detecting RF interference.

References:

Cisco Wireless Controller Configuration Guide: "You need to configure the AP in the monitor mode to view all spectrum analysis..."

Cisco Wireless Controller Configuration Guide, Release 8.8: "Monitor: In this mode, the AP radios are dedicated to monitoring the Wi-Fi channel for RRM and rogue detection"

Explanation:

In IGMPv2, the querier uses the link-local multicast address 224.0.0.1 to send general query messages to all multicast-capable hosts on the local network segment . This address is well-known as the "all systems on this subnet" group .

Why other options are incorrect

A. 239.0.0.2: This falls within the range of administratively scoped IPv4 multicast addresses (239.0.0.0/8) and is not used for IGMP query messages. The querier does not send general queries to this address.

C. 239.0.0.1: Also within the administratively scoped range (239.0.0.0/8), this is not a standard destination for IGMP general queries.

D. 224.0.0.2: This is the "all routers on this subnet" address . It serves different purposes in IGMP, primarily as the destination for Leave Group messages sent by hosts when they want to stop receiving traffic from a multicast group .

References
Cisco Security documentation clearly states that address 224.0.0.1 is assigned to all systems on a subnet .

Official configuration guides confirm that general queries are sent to 224.0.0.1