Free 350-401 Practice Test Questions 2026

✅ Explanation:

NETCONF YANG represents data structures in a hierarchical, tree-based format that can be encoded in XML.

The NETCONF protocol uses XML to encode the actual data and operations exchanged between clients and servers . A YANG module defines the data model, including the hierarchy of data nodes, their constraints, and how they relate to each other . This model is then translated into an XML format for transmission over the network . The NETCONF protocol defines how this XML data is structured, validated, and used in operations like or .

Why other options are incorrect:

A. as strict data structures defined by RFC 6020:
This is incorrect because YANG does not define "strict data structures" in the sense of a rigid programming language type system. YANG is a modeling language that defines hierarchical data and constraints, but the specific format of that data is determined by the encoding (XML, JSON, etc.) . The model is the structure, and the encoding is the representation .

C. In an HTML format:
This is incorrect. HTML is a markup language for web pages, not a data modeling language for network management protocols. YANG data is encoded using XML, JSON, or CBOR, not HTML .

D. as modules within a tree:
This is partially correct but incomplete. YANG modules are part of the data model, and they can be visualized as a tree, but the question asks how data is represented for NETCONF, which is in XML. While modules are hierarchical , the correct answer is the specific encoding format used for NETCONF (XML) .

References:

RFC 6020: Defines YANG as a data modeling language and specifies XML encoding.

IETF NETMOD Draft: States YANG defines a hierarchy of data as a tree and is directly mapped to XML content transmitted in NETCONF.

✅Explanation:

The technology that collects location information through data packets received by APs—rather than relying on mobile device probes—is FastLocate.

Traditional Wi-Fi location tracking relies on probe request messages from mobile devices to collect RSSI data. However, to conserve battery, devices are probing less frequently, with intervals ranging from 10 seconds to 5 minutes, resulting in inadequate data points to represent real-world movement accurately.

FastLocate solves this by using the more frequent data packets (instead of relying solely on probe requests) to collect RSSI information, enabling higher location refresh rates and more frequent location-based services updates. This provides more data points to accurately represent end-user activity.

Why other options are incorrect:

A. Detect and Locate – This is a Cisco CMX service for viewing and tracking devices in a deployment, not a specific technology for collecting location information through data packets.

C. Hyperlactation – Uses Angle-of-Arrival (AoA) of Wi-Fi signals with specialized hardware (Hyperlactation module) to achieve sub-meter accuracy, not data packet collection.

D. RF Fingerprinting – Uses RF prediction to create a grid mapped to a floor plan, correlating known RF characteristics with real-time user information, but it is not specifically the data packet-based collection method.

🔗 References:

Cisco Catalyst 9800 Fast Locate Configuration Guide: "Fast Locate enables higher location refresh rates by collecting RSSI or location information through data packets received by the APs".

Cisco CMX Fast Locate Deployment Guide: "Fast Locate adds the capability to get RSSI/Location information using data packets received by the AP for higher location refresh rates".

✅ Explanation:

The corporate policy requires a certificate-based authentication system using ISE and user credentials. This describes the 802.1X framework, which is the IEEE standard for port-based network access control . It uses a three-party architecture: the supplicant (client device), the authenticator (access point), and the authentication server (the RADIUS server, such as Cisco ISE) .

Why other options are incorrect:

A. none:
Selecting "none" for authentication key management means the WLAN would have no authentication or encryption, which does not meet the policy requirement.

B. PSK:
PSK (Pre-Shared Key) uses a shared password for authentication and does not support certificate-based authentication with ISE .

D. CCKM: Cisco Centralized Key Management (CCKM) is a fast roaming method that reduces the time required for a client to re-authenticate when roaming between access points . It is a speed-enhancing feature, not an authentication method that supports certificate-based authentication with ISE. It can be used in conjunction with 802.1X, but it is not the correct authentication key option to meet the policy requirement .

🔗 References:
[802.1X as the standard for wireless LAN security ]
[EAP-TLS requirements and flow ]
[Comparison of PSK vs. 802.1X enterprise authentication ]

✅Explanation:

To configure an SSID with a Pre-Shared Key (PSK) on a Cisco Catalyst 9800 WLC, the engineer must edit the WLAN Profile. The WLAN Profile is the specific configuration entity that defines an SSID's wireless characteristics, including its security settings. This is where authentication methods such as PSK, 802.1X, and related encryption settings are configured. The requirement is to use a PSK for authentication, which is a security setting, so the WLAN profile is the appropriate configuration target.

Why other options are incorrect:

A. RF Profile – RF profiles contain settings for radio frequency parameters like data rates, channel assignment, and transmit power, not security or authentication settings.

C. Policy Profile – A Policy Profile defines network policies for the client after authentication, including VLAN assignment, QoS, and ACLs. It does not contain the PSK authentication configuration itself.

D. Flex Profile – A FlexConnect profile configures FlexConnect-specific settings for remote site APs (like local switching and VLAN mapping), not PSK security settings.

🔗 References:

Cisco Catalyst 9800 Wireless Controller Software Configuration Guide: Defines the configuration model where the WLAN profile contains security settings including PSK.

Cisco 9800 WLC iPSK Configuration Guide: Details that PSK is configured under the WLAN profile settings on the Security tab.

Explanation:

A VXLAN Tunnel Endpoint (VTEP) requires a VXLAN Network Identifier (VNI) to operate . The VNI is a fundamental component of the VXLAN protocol, serving as a 24-bit identifier that uniquely distinguishes different overlay networks or segments . A VTEP encapsulates and decapsulates VXLAN packets; it needs the VNI to determine which virtual network traffic belongs to and ensure proper forwarding between endpoints across the Layer 3 underlay network .

Why other options are incorrect:

A. a VXLAN tunnel endpoint identifier – The VTEP is identified by its IP address and configured VNI; there is no separate "VTEP identifier" required. The VTEP's identity is provided by its source IP address .

B. at least one Layer 2 interface and one Layer 3 interface – A VTEP does not strictly require both types of interfaces simultaneously. While a source interface (typically a loopback) and a transport interface are needed, the architecture focuses on the overlay and underlay distinction rather than requiring both Layer 2 and Layer 3 interfaces on the same device .

C. at least one IP for the transit network and one IP for endpoint connectivity – This describes a general networking requirement, not a specific VXLAN requirement. The VTEP's core function is to map VNIs to overlay segments and forward traffic using its configured source IP, not to require multiple IP addresses for different purposes .

🔗 References:

Debian Manpages (ifupdown-ng): "A VXLAN Virtual Tunnel Endpoint (VTEP) interface must an ID set" .

Extreme Networks VOSS Guide: VNID allows up to 16 million VXLAN segments and each VTEP can support multiple VNIDs .

Explanation:

To make Router A become the active VRRP router, its priority must exceed that of Router B (which currently holds a priority of 110), or Router A must become the owner of the virtual IP address.

Option E (vrrp 1 priority 120): By default, Router A has a priority of 100, while Router B has 110. Increasing Router A's priority to 120 ensures it is higher than Router B's priority (120 > 110), triggering an election where Router A becomes the active master router.

Option D (ip address 10.1.0.11 255.0.0.0): In VRRP, the router that owns the primary IP address associated with the virtual router (the IP address owner) automatically assumes a priority of 255, which is the highest possible priority. Since Router B's virtual IP configuration uses 10.1.0.11, changing Router A's physical interface address to 10.1.0.11 makes it the address owner, immediately making it active.

Why Other Options Are Incorrect:

A. vrrp 1 priority 90: Lowering Router A's priority to 90 further reduces its chances of becoming active, as it remains well below Router B's priority of 110.

B. vrrp 1 timers advertise 1: Changing the advertisement timer interval affects how frequently hello messages are sent, but timers play no role in determining which router wins the active master election.

C. vrrp lip 10.1.0.11: This command is syntactically invalid in Cisco IOS for configuring VRRP.

References:

Cisco IOS IP Addressing Services Configuration Guide: Configuring VRRP (Virtual Router Redundancy Protocol) — Explains priority mechanics and IP address ownership.

Cisco 350-401 ENCOR Exam Topics: Section 3.0 Infrastructure — Topic 3.1 Configure and verify First Hop Redundancy Protocols (HSRP, VRRP).

✅ Explanation:

VXLAN is the data plane encapsulation protocol that creates the overlay network in SD-Access. The responsibility for performing this encapsulation and decapsulation lies with specific fabric roles:

Edge Nodes: These are the access layer switches where endpoints (such as PCs, phones, printers, and Access Points) connect to the network. Edge Nodes are responsible for endpoint registration and, crucially, for VXLAN encapsulation and decapsulation of traffic to and from these endpoints. In the case of fabric-enabled wireless, a VXLAN tunnel called an "access-tunnel" is established directly between the Access Point and the Edge Node to carry client traffic.

Border Nodes: These nodes are the gateway between the SD-Access fabric and external networks (e.g., data centers, WAN, internet). They also perform VXLAN encapsulation and decapsulation on traffic entering or leaving the fabric. This ensures seamless policy enforcement and segmentation as traffic moves in and out of the overlay.

Why other options are incorrect:

A. core nodes – "Core" is a traditional networking layer, not a distinct SD-Access node type. In SD-Access, the core function is often integrated with the distribution layer in a collapsed design. These nodes do not directly participate in VXLAN encapsulation.

B. distribution nodes – Distribution is another traditional layer, not a standard SD-Access role. In a typical SD-Access design, the distribution layer is collapsed with either the core or border layer, and its primary role is to provide Layer 3 connectivity in the underlay, not to perform VXLAN tunneling.

D. aggregation nodes – This is not a role defined in the SD-Access architecture. It is a term from traditional campus networking and is not used to describe nodes that handle VXLAN encapsulation.

🔗 References:

Cisco SD-Access Solution Design Guide: Confirms Edge Nodes perform VXLAN encapsulation/decapsulation. Border Nodes perform VXLAN encapsulation and decapsulation.

Understand Access Tunnel Creation in SD-Access: Documents VXLAN tunnels (access-tunnels) between Edge Nodes and Access Points.

Explanation:

Northbound APIs allow external software, automation scripts, and orchestration systems to interact with network controllers like Cisco Catalyst Center (formerly Cisco DNA Center) and Cisco SD-WAN vManage.

JSON Format (Option B):
Both Cisco DNA Center Intent APIs and vManage Northbound APIs are designed primarily around REST architecture using JavaScript Object Notation (JSON) as the primary data exchange payload format for HTTP GET, POST, PUT, and DELETE requests.

REST / RESTCONF Protocols (Option C):
Northbound controller APIs primarily expose RESTful interfaces over HTTPS. Certain Cisco controller management interfaces also support RESTCONF (RFC 8040) interfaces to access YANG data models programmatically over HTTP/HTTPS.

Why Other Options Are Incorrect:

A. They exchange XML-formatted content: While some legacy or southbound interfaces support XML, Northbound APIs on Catalyst Center and vManage rely almost exclusively on JSON payloads for lightweight data exchange.

D. They implement the NETCONF protocol: NETCONF is used as a Southbound API (communicating down from controllers like vManage to managed network devices/vEdges using SSH and XML), not as a Northbound API.

E. They exchange protobuf-formatted content: Protocol Buffers (protobuf) are typically used for Model-Driven Telemetry (MDT) encoding rather than standard Northbound REST controller APIs.

References:

Cisco DNA Center Platform User Guide: Intent APIs (Northbound RESTful APIs utilizing HTTPS and JSON).

Cisco SD-WAN (vManage) Architecture Guide: vManage REST APIs and Protocol Standards.

✅ Explanation:

The data shows two people, each with a first name, last name, and a list of hobbies. In JSON, an array of objects is represented with square brackets [] containing objects enclosed in curly braces {}. String values must be enclosed in double quotes " ". Object keys must also be in double quotes. Arrays of strings are represented with square brackets.

Why the other options are incorrect:

B. Option B:
The Hobbies values are not enclosed as an array; they are listed as separate key-value pairs with the same key name (Hobbies).
JSON keys must be unique within an object. Repeating the same key is invalid and would overwrite the previous value.
Some string values are missing closing double quotes.

C. Option C:
This option has multiple syntax errors, including missing closing quotes and missing commas.
The Hobbies values are not enclosed as arrays, and the string values are not properly quoted.
It does not correctly represent the list structure of hobbies.

D. Option D:
This contains the same errors as Options B and C.
The Hobbies values are not represented as arrays.
String values are missing proper quotes, making it invalid JSON.

🔗 References:

JSON (JavaScript Object Notation) Specification (RFC 8259): States that JSON is built on two structures: a collection of name/value pairs (object) and an ordered list of values (array).

JSON.org: Keys must be strings in double quotes; values can be strings, numbers, objects, arrays, booleans, or null.

Explanation:

MAB is specifically designed for legacy devices or endpoints that are not 802.1X-capable. When a device connects to a port configured for 802.1X, the switch first attempts 802.1X authentication. If it determines the host does not support 802.1X (e.g., no EAPoL (Extensible Authentication Protocol over LAN) response is received), it falls back to MAB. The switch then uses the device's MAC address as the username and password to query a RADIUS server. The server checks its database to see if the MAC address is authorized; if it is, the port is opened for network access.

Why other options are incorrect:

B. when the attached host supports 802.1X and must authenticate itself based on its MAC address instead of user credentials:This is incorrect. If a host supports 802.1X, it should authenticate using its credentials (like a username/password or certificate) via EAP, not using MAC authentication. MAB is a fallback for non-802.1X devices.

C. when authentication should be bypassed for select hosts based on their MAC address: This is incorrect. Bypassing authentication is not what MAB does. MAB still performs authentication, just using the MAC address as the credential. To truly bypass security, you would configure a port for "auto" or configure an exception, not MAB.

D. when the attached host supports limited 802.1X:This is incorrect. MAB is not for hosts that support 802.1X, even if the support is limited. If a host supports 802.1X, it should use that method. MAB is specifically for hosts that have no 802.1X capability at all. It is considered a fallback authentication method for non-supplicant devices.

References:

Cisco 802.1X Configuration Guide: MAB is used to authenticate hosts that do not have 802.1X supplicant software. The switch uses the MAC address to authenticate the host via RADIUS.

Cisco Identity Services Engine Guide: Defines MAB as a method to authenticate devices that do not support 802.1X, such as printers, IP phones, or legacy devices.