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

✅ Explanation:

Cisco TrustSec modernizes network security by moving beyond rigid IP addresses and VLANs to a more flexible, policy-based approach. Its core mechanism uses Security Group Tags (SGTs) to classify users, devices, and applications based on their role, not their location on the network.

D. Simplified management of network access:
By decoupling access policies from network topology, TrustSec allows administrators to create and manage rules using simple, business-friendly language in a central matrix. This eliminates the complexity of managing countless IP-based Access Control Lists (ACLs) and VLANs across the infrastructure, accelerating tasks like moves, adds, and changes.

E. Consistent network segmentation:
Because policies are tied to identity (SGTs), they are "topology-independent". The same security policy can be applied uniformly across wired, wireless, and VPN networks, ensuring that a user or device receives the same access rights wherever they connect. This enables consistent macro- and micro-segmentation across the entire enterprise.

Why other options are incorrect:

A. unknown file analysis using sandboxing:
This is a feature of advanced threat detection solutions (like Cisco AMP or Firepower), not a primary function of TrustSec. TrustSec focuses on network access and segmentation.

B. advanced endpoint protection against malware:
While TrustSec can help contain threats via segmentation, it does not provide endpoint malware protection. It controls network access and movement, not endpoint security.

C. end-to-end traffic encryption:
Although TrustSec can use MACsec (IEEE 802.1AE) to encrypt data on a hop-by-hop link between switches, it does not provide end-to-end encryption.

✅ Explanation:

Based on the Cisco Catalyst Center documentation, the two southbound interfaces that originate from Catalyst Center (formerly DNA Center) and terminate at fabric underlay switches are ICMP Discovery (A) and TCP 23 Telnet (C). The official port and protocol tables show that Catalyst Center uses these two protocols for southbound communication with the fabric underlay :

A. ICMP Discovery:
Catalyst Center uses ICMP messages to discover network devices and troubleshoot network connectivity issues . This is a critical part of the discovery process, as the controller needs to initially detect and verify the reachability of fabric switches.

C. TCP 23 (Telnet):
Although strongly discouraged by Cisco due to its lack of security mechanisms, Catalyst Center can use Telnet to connect to network devices to read configurations for discovery and to make configuration changes . This is a legacy fallback method.

Why other options are incorrect:

B. UDP 67 DHCP:
This is the port used by the fabric switches as DHCP clients to request IP addresses, particularly during the Plug and Play (PnP) or LAN Automation process . The traffic flow is from the switch to a DHCP server (which could be Catalyst Center), but it is not classified as a primary southbound interface originating from Catalyst Center for ongoing management.

D. UDP 6007 NetFlow:
While Catalyst Center uses UDP 6007 for NetFlow, the primary traffic flow for NetFlow is from the network devices to Catalyst Center to collect telemetry and traffic statistics . It is not a southbound protocol originating from the controller to manage the switches.

E. UDP 162 SNMP:
UDP 162 is the port for SNMP Traps. Similar to NetFlow, SNMP traps are typically sent from the network devices to the Catalyst Center to report asynchronous events and alerts, not from the controller to the devices .

🔗 References:

Cisco Catalyst Center Installation Guide: Lists ICMP, TCP 22 (SSH), and TCP 23 (Telnet) as southbound ports for communication between Catalyst Center and network devices for discovery and configuration .

Cisco DNA Center Required Ports: Details that ICMP, SSH (TCP 22), and Telnet (TCP 23) are used for device discovery and communication .

✅ Explanation:

SNR (Signal-to-Noise Ratio) is the numerical relationship of the wireless signal compared to the noise floor. It is the difference between the received signal strength (RSSI) and the background noise level, typically expressed in decibels (dB). A higher SNR indicates that the signal is stronger relative to the background noise, resulting in better link quality and higher potential data rates .

Why other options are incorrect:

B. RSSI
– Received Signal Strength Indicator is a measure of the absolute power level of the received signal, typically expressed in dBm. It does not represent the relationship of the signal compared to the noise floor; it is the signal strength itself.

C. EIRP
– Effective Isotropic Radiated Power is the output power of an antenna, measured in dBm, and includes transmitter power, cable losses, and antenna gain. It is a measure of how much power is radiated, not a comparison of signal to noise.

D. gain
– Antenna gain is the measure of how much an antenna focuses power in a direction relative to an isotropic radiator, typically measured in dBi. It does not represent the signal-to-noise relationship.

🔗 References:

IEEE 802.11 Standards: Define SNR as the ratio of signal power to noise power, measured in dB.

Cisco Wireless Design Guides: SNR is calculated as the difference between RSSI and noise floor.

✅ Explanation:

During a Layer 2 inter-controller roam, the client roams between Access Points (APs) connected to different Wireless LAN Controllers (WLCs), but the controllers have wireless LAN interfaces on the same IP subnet. This is a key distinction from a Layer 3 roam.

Because the client stays on the same subnet, it can retain its original IP address. Furthermore, the controllers exchange mobility messages to transfer the client's session context. The new controller requests the client's database entry, including its security context and associations, from the original controller, and this entry is moved to the new controller. This ensures a seamless transition for the client.

Why other options are incorrect:

A. A new security context is applied for each controller to which the client is associated, but the IP address remains the same. This is incorrect. As the client database entry is moved, the security context and associations are carried over and updated for the new AP, but a completely new security context is not applied.

B. The client must be associated to a new controller where a new IP address and security context are applied. This describes a Layer 3 roam, not a Layer 2 roam. In a Layer 3 roam, the client moves to a different subnet and must obtain a new IP address or use a tunnel to maintain its old one.

D. The client is marked as foreign in the database of each new controller to which it is connected. This is also characteristic of a Layer 3 roam. In a Layer 2 roam, the client's entry is moved, not marked as foreign. The "anchor" and "foreign" relationship is established for Layer 3 roams to maintain the client's original IP address when moving across subnets.

🔗 References:

Cisco Wireless Controller Configuration Guide: Interco troller Layer 2 roaming occurs when controllers are on the same IP subnet, and the client database entry is moved to the new controller.

Catalyst 9800 Series Configuration Guide: During Interco troller L2 roaming, the controllers exchange mobility messages and the client database entry is moved to the new controller. The process is transparent to the user.

✅ Explanation:

The character formatting required for DHCP Option 43 to function with current Cisco access point models is Hex.

DHCP Option 43 is used by lightweight access points (LAPs) to discover Wireless LAN Controllers (WLCs) when they are on different subnets. To function correctly, the AP expects the IP address list in a specific hexadecimal format.

Cisco documentation explicitly states: "Add the Option 43 line with this syntax: option 43 hex ". The value must be a hexadecimal TLV (Type-Length-Value) string where:

Type is the sub-option code 0xf1 (decimal 241)
Length is the number of controller IP addresses times 4, in hex
Value is the list of WLC management IP addresses in hex

For example, option 43 hex f108c0a80a05c0a80a14 represents two WLCs with IPs 192.168.10.5 and 192.168.10.20.

Why other options are incorrect:

A. ASCII
Only the legacy Cisco Aironet 1000 Series (VxWorks) APs support ASCII format for Option 43. Current AP models—such as the Catalyst 9100, 9105, 9120, and 9130 series—require Hex format per Cisco documentation. ASCII is no longer standard for modern APs and is explicitly described as a special case for the older 1000 Series.

C. Base64
Base64 is not a format used for Cisco DHCP Option 43. The known formats for vendor-specific options are Hex, ASCII, and IP Address. Base64 is generally used for encoding binary data in contexts like email attachments, not for Cisco AP discovery.

D. MD5
MD5 is a hashing algorithm used for data integrity and password storage, not for formatting DHCP option values. It has no relevance to DHCP Option 43 configuration for APs.

🔗 References

Cisco DHCP Option 43 Configuration Guide: "Add the Option 43 line with this syntax: option 43 hex "

Cisco 1000 Series Special Case: "Add the Option 43 line with this syntax: option 43 ascii "Comma separated IP address list""

✅ Explanation:

An API key is a predetermined, static string that is generated by the API provider and passed from the client to the server with each request to authenticate the calling application. The server validates the key against its database and grants or denies access. API keys are one of the simplest and most common authentication methods for REST APIs, particularly for server-to-server integrations.

Typically, the client includes the API key in the HTTP request header (e.g., Authorization: Bearer YOUR_API_KEY or X-API-Key: YOUR_API_KEY) . It is strongly discouraged to send API keys in URLs, as they can be logged in server logs, browser history, or referrer headers.

Why other options are incorrect:

A. a credential that is transmitted unencrypted
This is incorrect. While it is true that API keys can be vulnerable if transmitted over an insecure channel, the option does not define the API key itself. The security practice is to always use HTTPS (TLS) to encrypt the transmission. The key is not inherently "unencrypted"; the protocol used determines its transmission security.

B. one-time encrypted token

This is incorrect. A one-time encrypted token describes a different authentication mechanism, such as a JWT (JSON Web Token) or OAuth 2.0 token, which is often short-lived and can be encrypted. API keys are static and do not expire by default; they are not one-time or inherently encrypted .

C. a username that is stored in the local router
This is incorrect. API keys are not usernames stored locally on a router. They are application credentials stored on the server-side and provided to the client. They can be scoped to specific permissions or resources, but they are not usernames .

🔗 References:

Scaler API Key Definition: "An API key is a unique string that identifies and authenticates an application or project when it calls an API" .

TechTarget API Key Overview: "The API keys approach... uses machine-generated strings to create unique pairs of identifying credentials and API access tokens" .

Explanation:

A VMDK (Virtual Machine Disk) file is the primary file format used by VMware virtualization products to store the contents of a virtual machine's hard disk drive. It contains the complete disk image, including the guest operating system, applications, system files, and user data. It is the virtual equivalent of a physical hard drive.

VMDK files can be configured as fixed-size (pre-allocated) or dynamically growing (thin-provisioned). They can also be split into multiple files (extents) to facilitate large disk sizes or storage management. This format is fundamental to VMware ESXi and Workstation, and has also been adopted by other virtualization platforms as a standard.

Why other options are incorrect:

A. A file containing information about snapshots of a virtual machine:
Snapshot data is stored in delta or redo log files (e.g., -delta.vmdk), not the base VMDK disk file. Snapshots reference the base disk but are stored separately.

B. A zip file connecting a virtual machine configuration file and a virtual disk:
This describes an OVA (Open Virtual Appliance) or OVF (Open Virtualization Format) file, which is a packaging format containing multiple files (configuration, disk, and metadata) bundled into a TAR archive.

C. A configuration file containing settings for a virtual machine such as a guest OS:
VM configuration settings (guest OS, memory, CPU, network) are stored in a separate file with a .vmx extension, not the .vmdk disk file.

🔗 References:

VMware Virtual Machine Disk Format (VMDK): The native disk format for VMware products.


VMDK File Types and Functions: "The base VMDK file... stores the virtual machine's disk data" .

Explanation:

Cisco Catalyst SD-WAN is designed with a clear separation between the data plane, control plane, and management plane, which enables centralized management and policy control for large-scale networks while simplifying operations.

Secure Control Plane (Option A):
The control plane is a key architectural component of Catalyst SD-WAN. The control plane connections between the SD-WAN Controllers (vSmart), routers (vEdge), and the management system are secured using Datagram Transport Layer Security (DTLS) or Transport Layer Security (TLS) tunnels. This ensures that all control traffic, including routing and policy information, is authenticated and encrypted.

Centralized Policies (Option E):
The architecture is policy-driven and centralized. The SD-WAN Controllers manage the control plane, using the Overlay Management Protocol (OMP) to exchange routes, next hops, keys, and policy information. The controllers apply centralized policy to provide reachability, security, and application policies across the entire WAN fabric. These policies are orchestrated by a central authority rather than being configured hop-by-hop on each device.

Why other options are incorrect:

B. time-consuming configuration and maintenance
This is the opposite of a key benefit. The solution is designed to reduce operational overhead and simplify network management with a centralized approach, reducing the complexity of traditional WANs. As noted, a traditional distributed control plane model results in each node needing individual routing and security configurations, increasing complexity.

C. distributed control plane
This is incorrect. Catalyst SD-WAN features a centralized control plane managed by the SD-WAN Controllers. In contrast, traditional networks operate on a distributed control plane model.

D. unified data plane and control plane
This is incorrect. Catalyst SD-WAN separates the data plane, control plane, and management plane, providing a clear separation of duties. Traditional networks often unify these planes, but the SD-WAN architecture is explicitly distributed and separated.

🔗 References:

Cisco Catalyst SD-WAN Solution Overview: Separates control, management, and data planes; centralizes policies .

Cisco Catalyst SD-WAN Security Configuration Guide: Control plane operates over DTLS/TLS tunnels .

✅ Explanation:

The error message % telnet connections not permitted from this terminal indicates that the outbound Telnet connections are restricted. This is controlled by the transport output command on the VTY lines (which are used for outgoing connections like Telnet), not the console line.

Why other options are incorrect:

A. Option A:
This applies an access list to the console line (which is for inbound console sessions) using access-class, which is used to restrict incoming connections, not outbound. It does not address the transport output restriction for outgoing Telnet.

B. Option B:
This applies an access list to the VTY lines but uses the out direction. Standard access-class on VTY lines restricts incoming Telnet/SSH sessions to the router (using in), not outgoing connections. The syntax is also incorrect for controlling outbound Telnet.

D. Option D:
This applies the transport output command to the console line, which is used for physical console access, not for network connections. The console line does not control outbound Telnet sessions; the VTY lines do.

🔗 References

Cisco IOS Configuration Fundamentals: The transport output command is used on VTY lines to specify which protocols are allowed for outgoing connections.

Cisco IOS Security Command Reference: The default for VTY lines is transport output telnet ssh; if it is restricted, this command is required to enable Telnet outbound.

✅ Explanation:

In the Cisco SD-Access architecture for fabric-enabled wireless, the control and data plane traffic are split to provide centralized management with a distributed, optimized data path .

Control Plane (CAPWAP): The Control and Provisioning of Wireless Access Points (CAPWAP) protocol is used exclusively for control plane traffic . This means that management, configuration, and client authentication traffic travel between the AP and the Wireless LAN Controller (WLC) . The WLC remains the central manager for all wireless functions, but it does not process client data traffic .

Data Plane (VXLAN): For the user data plane, the AP establishes a direct Virtual Extensible LAN (VXLAN) tunnel to the first-hop fabric edge switch . The AP encapsulates the wireless client's Ethernet frames into VXLAN and sends them directly to the edge switch, where they are placed onto the wired fabric network . This distributed data plane eliminates the need for traffic to be hair-pinned back to a centralized controller, improving performance and scalability .

This split design provides the best of both worlds: centralized control for simplified management and a distributed data plane for optimal traffic flow and consistent policy enforcement across wired and wireless networks.

Why other options are incorrect:

A. Control plane traffic and data plane traffic are sent to the WLC through VXLAN.
Incorrect. The WLC is reached via the CAPWAP control plane tunnel, not VXLAN . The VXLAN tunnel is from the AP to the fabric edge node for data traffic .

C. The control plane traffic is sent to the WLC through VXLAN, and the data plane traffic is sent to the WLC through CAPWAP tunnels.
Incorrect. This reverses the roles of the protocols. Control plane traffic uses CAPWAP, and data plane traffic uses VXLAN .

D. Control plane traffic and data plane traffic are sent to the WLC through CAPWAP tunnels.
Incorrect. This describes the traditional, non-fabric "Over-the-Top" (OTT) wireless model, not the optimized fabric-enabled design . In fabric-enabled wireless, the data plane is decoupled from the WLC and distributed .

🔗 References

Cisco Live 2024 Presentation on SD-Access Fabric-Enabled Wireless: "CAPWAP Control Plane, VXLAN Data plane... Optimized for 802.11ac & 802.11ax APs" .

Cisco Catalyst 9800 Configuration Guide: "Control plane traffic between the fabric APs and the fabric wireless controller is through the CAPWAP tunnel. For the data plane, a fabric AP establishes a VXLAN tunnel to the fabric edge node" .