Free 350-401 Practice Test Questions 2026

Explanation:

Cisco vManage uses NETCONF (Network Configuration Protocol) to push centralized policies, configurations, and templates to vSmart controllers . vManage serves as the management plane for the SD-WAN solution, and NETCONF/YANG is the protocol it uses to communicate with other components . When a policy is defined through the vManage GUI and activated, it is pushed via a NETCONF transaction to the vSmart controller, where it appears in the running-configuration . Once vSmart receives the policy, it redistributes it to WAN Edge routers using the Overlay Management Protocol (OMP) . vSmart acts as the centralized control plane, implementing control policies, traffic engineering, and topology decisions, while vManage is the interface for creating and storing all policy versions .

Why other options are incorrect:

B. TLS:
TLS (or DTLS) provides the secure transport layer for encrypting control plane communication between all SD-WAN components . It is the underlying security protocol, not the configuration protocol used to push policies.

C. STUN:
STUN (Session Traversal Utilities for NAT) is used for NAT traversal and initial discovery between WAN Edge routers and the vBond orchestrator . It does not handle policy distribution.

D. OMP: OMP (Overlay Management Protocol) is the control plane protocol used between vSmart controllers and WAN Edge routers . While vSmart uses OMP to distribute policies to WAN Edge devices, vManage does not use OMP to communicate with vSmart—NETCONF is used for that purpose .

References:

Cisco Catalyst IR1800 Configuration Guide: "vManage is the management plane... It uses netconf/YANG to talk to vEdge devices"

Cisco Catalyst SD-WAN Manager documentation: "vManage communicates with vSmart to push policies"

Explanation:

The AAA Override feature is specifically designed to allow the wireless LAN controller to accept and apply attributes returned by the RADIUS server (ISE) on a per-client basis . In this scenario, enabling AAA Override on the WLAN is the critical action that allows ISE to specify the guest VLAN by returning the appropriate Tunnel-Private-Group-ID (VLAN ID) in the RADIUS Access-Accept message.


Why other options are incorrect

A. Set RADIUS Profiling:
This is a feature on ISE used to classify endpoints based on their attributes (e.g., device type). While profiling can be used to determine which policy to apply, the setting on the WLC that enables VLAN assignment is AAA Override, not profiling itself.

B. Set AAA Policy name:
This option is vague and doesn't specify an enabling feature. Simply naming an AAA policy does not instruct the controller to accept the RADIUS VLAN attribute; without AAA Override, the controller will ignore it and assign the default VLAN.

C. Enable Network Access Control State:
While NAC State is often enabled alongside AAA Override for Central Web Authentication flows, it is the AAA Override feature that enables dynamic VLAN assignment. NAC triggers the web authentication process but doesn't, by itself, instruct the controller to override the default VLAN.

References

Cisco Configuration Guides: Documents for both AireOS and 9800 controllers explicitly state: "Enable Allow AAA Override... enables you to apply VLAN tagging to individual clients based on the returned RADIUS attributes from the AAA server" .

Cisco WLC CLI: The command to configure this feature is aaa-override under the WLAN or policy profile

Explanation:

The ncclient Python library is used to establish NETCONF sessions with network devices like Cisco IOS XE to perform configuration operations such as edit-config or copy-config. When a script needs to make changes, it is critical to prevent other users or applications from modifying the device simultaneously, which could lead to a conflict. The correct method to achieve this is the lock operation.

According to the ncclient documentation, the lock method takes a mandatory parameter named target, which specifies the configuration datastore to be locked. When a lock is successfully applied to the running datastore, only the owner of the lock can perform edit-config and copy-config operations; other NETCONF sessions attempting to modify the configuration will be blocked. The lock is typically used within a context manager (with statement) to ensure it is automatically released when the operation completes.

The correct syntax is m.lock(target='running') because target is the valid parameter name, and 'running' is the name of the standard configuration datastore to be locked.

Why other options are incorrect:

A. m.lock(config='running'):
Incorrect. The lock method does not accept a parameter named config. The parameter is specifically target, as shown in the official ncclient API and examples. Using this syntax would raise a TypeError as the method would not recognize the argument.

C. m.freeze(target='running'):
Incorrect. There is no method named freeze in the ncclient Manager class for locking a datastore. This method does not exist in the library.

D. m.freeze(config='running'):
Incorrect. This combines two errors—the freeze method does not exist, and the config parameter is not valid for the lock operation even if it did.

References:

ncclient Official Documentation: The lock method uses the target parameter to specify the datastore name (e.g., running).

Cisco IOS XE Programmable Configuration Guide: Confirms that the NETCONF RPC targets a specific datastore, and the target is a mandatory element in the RPC.

Explanation:

IGMPv3 represents a significant evolution from previous versions by introducing source filtering—the ability for a host to report interest in receiving multicast traffic from specific source addresses, or from all but specific source addresses, sent to a particular multicast group . This capability was developed to support Source-Specific Multicast (SSM) .

According to the official IETF specification (RFC 9776), IGMPv3 defines only two primary message types of concern to the protocol itself: the Membership Query (0x11) and the Version 3 Membership Report (0x22) . However, the specification acknowledges that an IGMPv3 implementation must also support three additional message types for backward compatibility with previous IGMP versions: IGMPv1 Membership Report (0x12), IGMPv2 Membership Report (0x16), and IGMPv2 Leave Group (0x17) .

The source-specific membership report is a type of IGMPv3 Membership Report that contains source filtering information. It includes Group Record fields that allow hosts to specify:

MODE_IS_INCLUDE: The host wants to receive data only from the listed source addresses
MODE_IS_EXCLUDE: The host wants to receive data from all sources except those listed

These reports are sent to the destination address 224.0.0.22, which represents all IGMPv3-capable multicast routers on the network segment .

Why other options are incorrect:

A. leave group: This message type (0x17) is explicitly defined in IGMPv2, not IGMPv3. IGMPv3 does not define a separate Leave message—instead, hosts use Membership Report messages with specific Group Record types (such as CHANGE_TO_INCLUDE_MODE with an empty source list) to signal that they are leaving a group . While some implementations may treat a "Leave group" as a subtype of the IGMPv3 Membership Report, the independent "leave group" message type is a characteristic of IGMPv2 .

B. hello: This is not an IGMP message type. "Hello" messages are associated with routing protocols such as OSPF and EIGRP for neighbor discovery, not with IGMP. IANA's official IGMP Type Numbers registry does not list "hello" as a valid message type.

C. graft:
According to IANA's official IGMP Type Numbers registry, "Graft" is a valid message type (Type 0x06) . However, it is used by the PIM-DM (Protocol Independent Multicast - Dense Mode) routing protocol, not by IGMP. The graft message is sent by a PIM router to rejoin a pruned branch in the multicast distribution tree. It is not an IGMP host-to-router message.

References:

RFC 9776 (IGMPv3):Defines the two primary IGMPv3 message types: Membership Query and Version 3 Membership Report, and specifies support for source filtering

Cisco Configuration Guide:
Explains IGMPv3 Membership Reports contain source information for SSM, supporting INCLUDE and EXCLUDE filter modes

Explanation:

The scenario describes an Over-the-Top (OTT) wireless solution within an SD-Access Fabric wired network. In an OTT deployment, the wireless solution operates outside (over the top of) the SD-Access fabric—the fabric acts simply as an IP transport network for wireless traffic . The architect wants APs to register to the WLC and centrally switch traffic.

Local mode is the AP mode that meets this requirement. In local mode, the AP establishes a CAPWAP tunnel to the WLC, and all client data traffic is tunneled back to the controller for centralized processing . This is the standard mode for centralized switching in traditional Cisco wireless deployments and is the supported mode for OTT wireless within an SD-Access fabric . The AP registers to the WLC via CAPWAP, and traffic flows through the fabric to the WLC for switching .

Why other options are incorrect:

A. Bridge:
This is not a standard AP mode in Cisco wireless for this purpose. Bridge mode is used for mesh deployments, not for registering APs to a WLC for centralized switching.

B. Fabric:
Fabric mode is the native SD-Access wireless integration, where APs are part of the fabric overlay and wireless traffic is encapsulated in VXLAN and sent directly to the fabric edge node, bypassing the WLC for data traffic . This mode is used for fully integrated SD-Access wireless, not for OTT deployments .

C. FlexConnect:
FlexConnect mode enables local switching at the AP itself, where traffic is switched locally at the remote site rather than being tunneled back to the WLC . This is designed for branch deployments with WAN links, not for centralized switching in an OTT SD-Access scenario.

References:

Cisco Extended Enterprise Design Guide: "Centralized wireless deployment model can be used in SD-Access deployments; in this mode, the SD-Access fabric is simply a transport network for the wireless traffic. This is called Over the Top (OTT)"

Explanation:

For web authentication redirection, the pre-authentication ACL must be constructed with a specific logic: deny traffic destined for the external web server so the controller can intercept and redirect it, but permit traffic to the DNS server and the HTTP/HTTPS ports (80 and 443) the client needs for the initial redirection process. The ACL is applied before authentication, restricting the client's access to only the ISE servers and other necessary services until they log in.

Why other options are incorrect:

Option B:
Contains a deny udp any any eq domain statement for DNS. This would block DNS resolution, preventing the client from resolving ISE's hostname or performing captive portal detection, breaking the authentication process.

Option C: Uses permit statements for the ISE servers instead of deny. This would allow the client to bypass the web authentication redirect entirely, as traffic to the servers would never be intercepted, directly violating the requirement.

Option D: Missing explicit deny ip any any at the end. Cisco Extended ACLs have an implicit deny all, but in web redirect scenarios, the controller interprets permit statements as allowed traffic and deny statements as redirect triggers. While the implicit deny may provide a fallback, the absence of explicit deny entries for the ISE servers means this ACL would allow all traffic to the ISE servers and block necessary redirection traffic for port 80/443, breaking the redirect flow.

References:

Cisco 9800 Configuration Guide: Pre-authentication ACL must deny traffic to the ISE server and permit HTTP/HTTPS for redirect to function correctly.

Cisco Community Documentation: "The ACL for redirect uses deny" – Example ACL shows deny ip any host and permit tcp any any eq 80.

Explanation:

Cisco Hyperlocation is an ultra-precise location solution designed to track wireless clients with significantly improved accuracy compared to traditional RSSI-based methods . The core method used by this solution is Angle of Arrival (AoA) .

AoA technology calculates the direction from which a radio-frequency signal arrives by measuring the time difference of arrival (TDOA) at each element of a specialized antenna array . In a Cisco Hyperlocation deployment, the APs receive Wi-Fi signals from client devices, analyze the phase differences of the incoming signals, and use these measurements to triangulate the device's precise location. The Cisco Hyperlocation module, specifically the WSM2 variant with its 32-antenna configuration, is designed to achieve accuracy of up to one meter .

The location engine uses AoA-phase measurements to triangulate the position of a device, achieving high precision when the device is within the convex hull of the participating access points . In scenarios where the device is outside this optimal zone, the system can fall back to a "Fusion" mode, which combines AoA data with standard RSSI calculations to estimate the most likely location .

Why other options are incorrect:

B. location patterning: This refers to Wi-Fi fingerprinting, which uses stored signal strength profiles to determine location, not the phase-difference measurements used by Hyperlocation .

C. TTL:
Time-to-Live is a field in IP packets used to prevent routing loops, not a method for determining physical location .

D. line of sight:
While line of sight can improve signal strength, Hyperlocation calculates AoA even in Non-Line-of-Sight (NLOS) conditions by analyzing phase differences, making this an inaccurate characterization of its primary technology .

References:

Cisco Hyperlocation Configuration Guide:
"The solution uses the Angle-of-Arrival (AoA) of Wi-Fi signals to determine the location of connected mobile devices"

Cisco 9800 Configuration Guide:
"The Cisco Hyperlocation radio module provides... 32-antenna angle of arrival (AoA)"

Explanation:

Bidirectional Forwarding Detection (BFD) is a lightweight protocol designed to provide rapid detection of forwarding path failures between network devices. Its primary purpose is to decouple failure detection from routing protocols, enabling sub-second detection regardless of the underlying media or protocol.

BFD provides two key benefits for campus network design:

Speeds up routing convergence time (A):
Traditional routing protocols like OSPF and EIGRP rely on hello timers and dead intervals (typically 10–40 seconds) to detect neighbor failures. When BFD is integrated with these protocols, it triggers a notification to the routing process immediately upon detecting a failure. This eliminates the wait for hold-down timers, allowing the routing protocol to recalculate alternate paths and converge much faster—often within milliseconds. This significantly improves network reliability and reduces traffic loss during failures.

Provides path failure detection in less than a second (B):
BFD achieves sub-second failure detection by sending rapid control packets at intervals as low as 50 milliseconds, with a multiplier of 3, enabling detection within 150 milliseconds. This is far faster than the default behavior of most routing protocols, which require several seconds. BFD's ability to detect failures in milliseconds makes it essential for high-availability campus networks where rapid failover is critical, such as for voice, video, and real-time applications.

Why other options are incorrect:

C. BFD provides fault tolerance by enabling multiple routers to appear as a single virtual router:
This describes the function of First Hop Redundancy Protocols (FHRP) like HSRP, VRRP, or GLBP. BFD does not provide virtual router functionality; it only detects failures between directly connected neighbors. While BFD can be used with FHRP to accelerate failover, it is not responsible for the virtual router abstraction.

D. BFD is an efficient way to reduce memory and CPU usage:
BFD was designed for fast detection, not resource conservation. While the BFD Echo function can reduce CPU overhead by offloading processing, BFD sessions still consume resources to maintain rapid packet exchanges. The protocol's primary benefit is speed, not efficiency.

E. BFD enables network peers to continue forwarding packets in the event of a restart:
This describes Non-Stop Forwarding (NSF) or Graceful Restart mechanisms. BFD detects failures and triggers routing protocol recalculation, but it does not enable peers to continue forwarding through a restarting device.

References:

RFC 5880 - BFD Specification: "BFD provides a lightweight mechanism for detecting path failures in less than a second" Cisco BFD Configuration Guide: "BFD provides sub-second failure detection and triggers faster routing convergence"

Explanation:

EIRP (Effective Isotropic Radiated Power) is the specific calculation used to measure the total radiated power of a signal after it has passed through the entire transmission chain—from the radio transmitter, through the antenna cable (accounting for loss), to the antenna (accounting for gain). EIRP represents the theoretical power that would need to be emitted by an ideal isotropic antenna (which radiates equally in all directions) to produce the same maximum signal strength in the direction of the antenna's main lobe.

The calculation is: EIRP = Transmitter Power (dBm) - Cable Loss (dB) + Antenna Gain (dBi). This formula accounts for all components in the RF path. EIRP is a critical measurement because it determines the actual coverage area of a wireless signal and must comply with regulatory limits (e.g., FCC, ETSI) for legal operation. It is expressed in dBm (decibels relative to 1 milliwatt) but represents the aggregate system power after all gains and losses.

Why other options are incorrect:

B. mW (milliwatt):
This is a basic unit of absolute power, like watts or kilowatts. It does not account for antenna gain or cable loss, which are essential factors in determining the final radiated power. mW is simply a unit of measurement, not a calculation that includes the entire RF chain.

C. dBm:
This is a logarithmic measure of absolute power relative to 1 milliwatt (0 dBm = 1 mW). While dBm is used to express the transmitter's output power and the final EIRP result, it does not, by itself, represent the final radiated power after accounting for cable loss and antenna gain.

D. dBi: This is the unit used to express the gain of an antenna relative to an isotropic radiator. It measures how effectively the antenna focuses energy in a specific direction. Gain is a key component of the EIRP calculation, but it is not the calculation itself.

References:

Cisco Wireless Design Guide: "EIRP is the actual radiated power from the antenna and is calculated as transmit power minus cable loss plus antenna gain"

FCC Regulations: "EIRP is the standard measurement for radiated power in wireless systems"

Explanation:

In the Cisco Catalyst SD-WAN architecture, vSmart serves as the centralized control plane controller for the overlay network . Its primary role is to manage and distribute critical information that keeps the fabric operational.

One of its key functions is the distribution of IPsec keys, which are essential for securing the data plane tunnels between WAN Edge routers . Beyond key distribution, vSmart also acts as a route reflector, a central policy engine, and is responsible for dynamically distributing routing information (via OMP) and policies across the network .

Why other options are incorrect:

A. facilitation of NAT detection and traversal:
This is the primary function of the vBond orchestrator, not vSmart. vBond handles the initial authentication and NAT discovery for edge routers joining the network .

B. redistribution between OMP and other routing protocols: While OMP carries routes from protocols like BGP and OSPF, the actual redistribution of these routes into OMP is configured locally on the WAN Edge routers through route policies, not performed centrally by vSmart .

D. execution of localized policies:
This task belongs to the WAN Edge routers (vEdge/cEdge). Localized policies, which affect routing and data flow at the local site, are provisioned on the edge devices themselves, either via CLI or vManage templates . In contrast, vSmart provisions and enforces centralized policies that affect the entire overlay network .

References:

Cisco Catalyst IR1800 Configuration Guide: "vSmart is the control plane... acts as the route reflector, key reflector, and policy engine"

Cisco SD-WAN Migration Guide: "vSmart provides... dynamic distribution of routing information, encryption keys and policies"

Explanation:

In a Cisco Mobility Express wireless deployment, when the primary AP (which runs the virtual controller function) fails, the selection of a new primary AP is determined by an automatic election process . This process is based on Virtual Router Redundancy Protocol (VRRP) and evaluates eligible APs according to a specific order of precedence .

Why other options are incorrect:

A. AP with highest IP address:
IP address is not used as a selection criterion in the primary AP election algorithm. Neither IP address nor IP address order is referenced in Cisco's documentation for this process.

B. AP with the lowest IP address:
Similarly, IP address plays no role in the election. The algorithm is based on controller uptime, VRRP configuration, client load, and MAC address.

C. AP with the highest MAC address:
This is the opposite of the correct MAC address logic. The election process uses the lowest MAC address as the final tie-breaker among APs with equal client load . The highest MAC address is never used.

References:

Cisco Mobility Express User Guide, Release 8.10: "The AP with highest controller up-time compared to other Cisco Mobility Express-capable APs"

Cisco Mobility Express Deployment Guide: "Lowest MAC Address – If all of the Access Points are the same and have the same client load, then Access Point with the lowest MAC will be elected"

Explanation:

Ansible is an open-source automation tool used for configuration management, application deployment, and orchestration. It operates on a push model, meaning the control node initiates communication and pushes changes to managed hosts via SSH or WinRM—no agent software needs to be installed on target devices . Playbooks are written in YAML, but Ansible is built on Python, and its modules can also be developed in Python or Ruby .

Why other options are incorrect:

A. Puppet:
Uses a pull model. The agent on each node periodically checks the master server for updates and applies them . This requires an agent to be installed on every managed host .

C. SaltStack:
Can support push via its master-minion architecture, but requires minion agents to be installed on managed nodes for full functionality . It does have an agentless salt-ssh mode, but agentless operation is not its default.

D. Chef:
Traditionally uses a pull model with an agent on each node . Chef requires the Chef Client agent to be installed, though an agentless mode is available as a newer option .

References:

Cisco DevNet Documentation: "Ansible is a good example of an agent-less configuration management tool"

Educative: "Ansible is agentless and push-based, connects to hosts via SSH, requires no client-side agent"