Free Cisco 350-401 Practice Questions 2026 | Implementing Cisco Enterprise Network Core Technologies (350-401 ENCOR)

Explanation:

According to Cisco's official documentation, the WLC sources RADIUS traffic from the IP address of its management interface unless a specific condition is met . That exception occurs only when the RADIUS server exists on a VLAN directly accessible via one of the controller's Dynamic interfaces .

Since the question explicitly states that the WLC's interfaces are not in the same subnet as the RADIUS server, this exception does not apply. Therefore, the management interface is the source for all RADIUS authentication and accounting traffic .

Why other options are incorrect

B. the controller virtual interface:
The virtual interface is used for mobility and guest anchor functions, not for sourcing RADIUS traffic .

C. the interface specified on the WLAN configuration:
This is only used when the "RADIUS Server Overwrite interface" feature is explicitly enabled under the WLAN's AAA Servers settings . The question's scenario assumes default behavior, where this feature is not enabled .

D. any interface configured on the WLC:
The source interface is deterministic based on network topology and feature flags, not arbitrary .

References:

Cisco Wireless Controller Configuration Guide: Details the default source behavior for RADIUS traffic .

Cisco Community Discussions: Confirm that the WLC uses the management interface unless the RADIUS server is directly connected to a dynamic interface or the "RADIUS Server Overwrite" feature is enabled .

Explanation:

The REST API response shown contains a taskId and a url pointing to a task status endpoint (/task/{taskId}). This indicates that the request triggered an asynchronous operation. In Cisco Catalyst Center (formerly DNA Center), long-running operations such as device discovery, template provisioning, or software image distribution return a 202 Accepted status code along with a task ID that can be polled to check the progress of the operation.

The POST /discovery endpoint is used to initiate a network discovery process, which is inherently an asynchronous operation. When you send a POST request to start a discovery, the API immediately returns a 202 Accepted response with a task ID, allowing the client to query the task endpoint for status updates.

Why other options are incorrect:

A. POST /auth/token:
This endpoint is used to generate an authentication token and returns a 200 OK response with the token in the body—not a 202 with a task ID.

B. GET /network-device:
This is a synchronous operation that retrieves a list of network devices. It returns a 200 OK with the device list, not a task ID.

C. GET /template-programmer/template/version/{id}: This is also a synchronous GET request that retrieves a specific template version and returns a 200 OK with the template details—not an asynchronous task response.

References:

Cisco Catalyst Center API Documentation: Asynchronous operations return 202 Accepted with a task ID

Cisco DevNet: POST /discovery initiates a discovery job and returns a task ID for polling

Explanation:

In the 4-way handshake of WPA2-Enterprise (and WPA2-Personal), the M4-Message is the final EAPOL-Key frame sent from the client (supplicant) to the Access Point (authenticator). Its purpose is to serve as an acknowledgment, confirming that the client has successfully installed the Pairwise Transient Key (PTK) and the Group Temporal Key (GTK) .

The handshake flows as follows:

Message 1 (M1): The AP sends its nonce (ANonce) to the client.

Message 2 (M2): The client responds with its own nonce (SNonce) and a MIC. Both sides now derive the PTK .

Message 3 (M3): The AP sends the encrypted GTK to the client, along with a request for the client to install the PTK and GTK .

Message 4 (M4): The client sends this final message to confirm the keys have been installed successfully. While it serves no cryptographic purpose for key derivation, it is required to inform the AP that the client is ready to receive encrypted frames .

Receiving the M4-Message validates and confirms the client's successful installation of the GTK. Until the AP receives this confirmation, it will not consider the handshake complete .

Why other options are incorrect:

A. M2-Message: This message contains the client's SNonce and a MIC to allow the AP to derive the PTK. The GTK has not yet been sent by the AP at this stage .

B. M1-Message: This is the initial message from the AP containing only the ANonce to allow the client to derive the PTK. It does not contain the GTK .

C. M3-Message: This message is responsible for delivering the encrypted GTK to the client. It is the client's M4 response that validates and confirms its successful installation .

References:

IEEE 802.11 standard documentation identifies M4 as the confirmation message that informs the authenticator the supplicant has installed the PTK and GTK .

Networking and cybersecurity references consistently describe M4 as the client's final acknowledgment of successful key installation .

Explanation:

In a Wi-Fi network, the wireless client device (the station) is solely responsible for making the roaming decision. This includes deciding when it needs to roam and which Access Point (AP) to roam to. The IEEE 802.11 standard and Wi-Fi Alliance do not specify a mandatory algorithm for this decision; it is left to each vendor to implement their own proprietary logic.

Why other options are incorrect:

B. Wireless LAN controller:
While the WLC manages the overall network and facilitates the roaming process (especially between controllers), it does not make the decision for the client to initiate a roam.

C. Access point:
The AP monitors the client's signal and can assist with information (like neighbor reports via 802.11k), but it does not decide when the client should roam.

D. WCS location server:
The location server is used to track client positions for services like asset tracking and does not participate in the client's roaming decision-making process.

References:
IEEE 802.11 standard (Roaming is a client-driven process)
Cisco Voice over Wireless LAN Design Guide: "Roaming is a client decision"
Apple Support Documentation: "D

✅ Explanation:

Cisco SD-Access uses a combination of technologies to automate the discovery and provisioning of network devices like border and edge switches. This process is primarily driven by Cisco Catalyst Center (formerly DNA Center) and relies on a few key mechanisms.

The LAN Automation feature is central to onboarding new switches into the SD-Access fabric . This process leverages the Plug and Play (PnP) agent built into Cisco IOS XE devices . When a new switch is connected, it uses DHCP to discover the Cisco Catalyst Center, which then pushes a configuration to the device, upgrading its software image if necessary and onboarding it into the network . This dynamic process effectively discovers and provisions the switches, including border and edge nodes, without manual configuration .

Why other options are incorrect:

B. It uses VXLAN for the control plane:
This is incorrect because VXLAN is used for the data plane, not the control plane. The control plane in SD-Access is based on the Locator/ID Separation Protocol (LISP) .

C. It uses PnP to discover and provision border and access switches:
While PnP is a crucial part of the discovery process, it is the LAN Automation feature that orchestrates the full discovery and provisioning workflow. PnP is the agent that enables the initial communication , not the entire mechanism itself.

D. It uses GRE for the policy plane:
This is incorrect. The policy plane in SD-Access is based on Cisco TrustSec technology, which uses Security Group Tags (SGTs) to enforce segmentation and policy . GRE (Generic Routing Encapsulation) is not used for the policy plane.

🔗 References:

Cisco SD-Access Solution Design Guide: States that the control plane is based on LISP, the data plane on VXLAN, and the policy plane on Cisco TrustSec. It also explains that Catalyst Center automates the deployment of these planes .

Cisco Catalyst Center LAN Automation Guide: Details how LAN automation uses PnP to discover, upgrade, and configure new switches .

✅ Explanation:

OMP is the control protocol responsible for establishing and maintaining the Cisco SD-WAN control plane . Its primary functions include:

Advertisement of network prefixes and their attributes (A):
This is the core function of OMP. WAN Edge routers advertise their local routes to the vSmart controllers using OMP, and the vSmart controllers then distribute these routes to other routers. These route advertisements include attributes such as the Transport Location (TLOC), origin, preference, and site ID .

Delivery of crypto keys (D):
OMP is responsible for distributing data plane security parameters and encryption keys within the SD-WAN fabric, ensuring secure communication between routers without the scalability issues of traditional IKE key exchange .

Why other options are incorrect:

B. configuration of control and data policies:
This is incorrect. While OMP is used to distribute data and application-aware routing policies, the configuration and definition of these policies are performed on the vSmart controllers, not by OMP itself .

C. gathering of underlay infrastructure data:

This is incorrect. Underlay infrastructure data (such as link quality, path information, and physical network topology) is gathered using different mechanisms like Bidirectional Forwarding Detection (BFD) and Underlay Measurement and Tracing Services (UMTS), not by OMP .

E. segmentation and differentiation of traffic:
This is incorrect. Segmentation and traffic differentiation is enforced in the data plane using tags and policies, not by OMP. The primary function of OMP is to distribute routing, policy, and security information in the control plane.

🔗 References

Cisco OMP Routing Mechanisms Guide: Explains OMP's role in exchanging routing, policy, and security information .

Cisco Unicast Overlay Routing Guide: Details OMP route advertisements and protocol functions .

✅ Explanation:

The script reads device information from a file (devices.txt) and uses an API call to retrieve configuration data from each device. To save each device's configuration to a JSON-formatted file named after the device, the code must be appended inside the for loop to ensure it executes for every device.

Why this is correct:
It uses f"Hostname.json" to dynamically name the file, though the variable Hostname is defined earlier in the loop.
It writes Response.text to the file. Since requests.get() returns a Response object, .text contains the raw response body, which is JSON-formatted configuration data.
It is placed inside the loop, ensuring one file is created per device.

Why other options are incorrect:

A. Insert after the for loop:
This would run only once after the loop completes, using the last device's Hostname variable. It would also write Response (the object) instead of the actual content, causing a TypeError when write() expects a string.

B. Insert after the for loop:
This has the same placement issue (runs once after the loop) and uses json.dumps(Response.text), which would write a JSON-encoded string of the response text—doubly encoding the JSON data.

D. Insert immediately before the for loop:
This runs only once, before any device data is read, uses a file opening syntax error (Devices is not defined at that scope), and json.load() would attempt to parse the devices file as JSON, which is not its format.

🔗 References

Python requests Library Documentation: Response.text returns the response body as a string, suitable for writing to a file.

Python File I/O: with open() ensures proper file handling; placing it inside the loop ensures one file per iteration.

✅ Explanation:

A client using 802.1X for authentication is referred to as a supplicant. In the 802.1X framework, there are three key roles. The supplicant is the client device (e.g., laptop, smartphone, or other endpoint) that requests access to the network. It runs software that responds to authentication requests from the authenticator (typically a switch or wireless access point) and provides the necessary credentials to the authentication server. This terminology is a fundamental concept of the IEEE 802.1X standard for port-based network access control (PNAC).

Why other options are incorrect:

A. authenticator:
The authenticator is the network device (such as a switch or wireless access point) that acts as a gatekeeper between the supplicant and the authentication server. It controls access to the network based on the authentication result, but it is not the client itself.

B. policy enforcement point:
This is a more general term used in network security architectures (like NAC or SD-Access) to describe where policies are applied (e.g., a firewall or switch). It is not the specific role defined for a client in the 802.1X standard.

C. NAC device:
A Network Access Control (NAC) device is a broader security appliance or solution that enforces policies on endpoints. It is not the specific term for an 802.1X client.

🔗 References

IEEE 802.1X-2020 Standard: Defines the three roles: supplicant, authenticator, and authentication server.

Cisco 802.1X Port-Based Authentication Guide: Describes the supplicant as the client device seeking access to the network.

✅ Explanation:

When designing a Cisco SD-Access fabric, the two essential components are Cisco Catalyst Center and Cisco Identity Service Engine (ISE).

Cisco SD-Access is a solution that automates network provisioning and policy enforcement. It is fundamentally composed of three key pillars: management, policy, and the network infrastructure itself . Catalyst Center (formerly DNA Center) serves as the centralized management and orchestration platform for all SD-Access operations. It provides the single "pane of glass" to design, provision, apply policies, and gain assurance across the entire fabric network . Cisco ISE is the dedicated security policy and access control platform. It acts as the policy engine, performing authentication and authorization services and providing the dynamic mapping of users and devices to Scalable Group Tags (SGTs) for end-to-end policy enforcement .

A. Cisco Catalyst Center (formerly DNA Center) application:
This is a correct component of an SD-Access fabric. However, since the question asks for two components, another correct answer is needed.

C. Identity Service Engine:
This is a correct component of an SD-Access fabric, as it is the mandatory policy engine for network access control and segmentation.

Why other options are incorrect:

B. Firepower Threat Defense:
While Cisco's security portfolio includes Firepower Threat Defense (FTD) for firewall and intrusion prevention, it is not a required core component for the design of the SD-Access fabric itself. Security policies within the fabric are enforced by Cisco ISE .

D. Cisco Data Center Network Manager:
DCNM is a management tool for Cisco Nexus data center switches and storage networking. It is not used in the campus networking environment of an SD-Access fabric .

E. Cisco Prime Infrastructure:
Prime Infrastructure was a legacy network management tool. In the SD-Access architecture, it has been replaced by Catalyst Center as the central management and orchestration platform .

🔗 References

Cisco SD-Access Solution Design Guide: States the solution is provided through a combination of Catalyst Center, ISE, and fabric-capable device platforms .

Cisco Catalyst Center Documentation: Identifies Catalyst Center and Cisco ISE as fundamental pillars of the SD-Access solution .