Free 300-430 Practice Test Questions 2026

Explanation:

In a Cisco ISE version 2.1 BYOD deployment using a Single SSID design, the same wireless network is used for both the initial onboarding process and for subsequent, fully authorized network access . For this model to function, the SSID must be configured for 802.1X authentication on the WLC .

Why the others are wrong

A. open authentication & C. no authentication:
While similar, these options are incorrect for the Single SSID model. In Cisco ISE BYOD, an open, unauthenticated WLAN is characteristic of a Dual SSID design. In that flow, the open SSID is used exclusively for device onboarding and redirection to a guest portal, and clients must connect to a separate, secure SSID for full access . The Single SSID model requires a single, secure WLAN from the very beginning .

D. WPA2:
WPA2 is the Wi-Fi security protocol that secures the wireless link between the client and the AP, but it is not an authentication method. The question asks for the configuration on the ISE to enable the authentication flow. For Single SSID BYOD, it is the 802.1X authentication framework on the WLC that facilitates the required EAP exchanges with the ISE .

References:
Cisco BYOD Single SSID Design Overview
ISE BYOD Authorization Policies
Exam discussion on Single SSID vs. Dual SSID authentication

Explanation:

Strict Type Matching Requirement (Option B):
For Cisco CMX High Availability (HA) pairing to form successfully, both the primary and secondary CMX instances must be deployed on the exact same installation model type—meaning both must be virtual appliances (VMs) or both must be dedicated physical appliances. Mixing a physical appliance with a VM causes high availability pairing to fail validation.

Strict Size Matching Requirement (Option D):
Cisco CMX HA mandates that the primary and secondary nodes share identical node footprint sizing (e.g., both Low-End, both Standard, or both High-End instances). Mismatched sizing prevents database replication and state synchronization, leading to HA configuration failure.

Why Other Options Are Incorrect:

A. The Cisco CMX instances are installed in the same subnet:
Being in the same subnet is a valid requirement for Layer 2 High Availability deployments and will not cause HA pairing to fail.

C. The delay between the primary and secondary instance is 200 ms:
Cisco CMX supports Layer 3 HA across routed subnets as long as the round-trip latency (delay) between the primary and secondary nodes is under 250 ms. A delay of 200 ms falls within the acceptable operating threshold.

E. Both Cisco CMX installations are virtual:
Deploying CMX as virtual machines is fully supported, provided both nodes are VMs and share identical resource sizing.

References:

Cisco CMX Configuration Guide (Managing Cisco CMX System Settings - High Availability): Specifies prerequisites for HA, strictly requiring identical node sizes (Low, Standard, High-end), identical installation types (VM vs. Physical), matching software versions, and NTP synchronization across both instances prior to pairing.

Explanation:

The scenario describes a classic symptom of an Active Directory account lockout. The user has already installed the CA certificate, eliminating the most common certificate trust issue. The fact that they were prompted to enter credentials multiple times, and the authentication has not succeeded, is the key diagnostic indicator . Each incorrect credential attempt increments the badPwdCount attribute in Active Directory. Once this count reaches the configured threshold, the account becomes locked, causing all subsequent attempts—even with the correct password—to fail during the RADIUS authentication process . Cisco ISE would stop sending authentication requests for that user to Active Directory, and the WLC would simply reject the client without producing a specific error on the laptop side . This perfectly matches the "prompted multiple times but failed" outcome described in the question.

Why the others are wrong:

A. Invalid policy on authentication server:
This typically causes failures for all users or manifests as specific RADIUS access-reject messages, not repeated credential prompts followed by silent failures.

C. Invalid policy on the authenticator:
The authenticator (the WLC) is functioning correctly because it is prompting the user for credentials and forwarding them to ISE. A policy issue here would usually prevent the EAP process from starting.

D. Laptop has not received a valid IP:
IP address assignment occurs after successful 802.1X authentication. Clients typically use DHCP after the EAP process completes and the port is authorized, so this is a result of the authentication failure, not its cause .

References:

Cisco ISE Administrator Guide – Active Directory user lockout behavior .
Windows 11 802.1X troubleshooting – Credential validation and lockout symptoms .

Explanation:

This issue arises because the CPU ACL, designed to restrict management access, also blocks the guest web portal . The guest portal is hosted on the WLC's virtual interface (often IP 1.1.1.1), which is processed by the CPU . When a CPU ACL is applied, its rules are evaluated for all traffic destined for the CPU, including portal requests. If the ACL lacks an explicit permit rule for access to the virtual IP, the implicit deny at the end of the ACL blocks the redirection page .

The solution is to add a rule explicitly permitting traffic destined for the virtual interface IP address . For instance, a permit rule for TCP port 80 (HTTP) or 443 (HTTPS) to the virtual IP (e.g., 1.1.1.1) is required, depending on secureweb settings .

Why the others are wrong:

A. The guest portal must be configured on the CPU ACLs:
The guest portal is not configured on the CPU ACL; it is a WLAN setting. The CPU ACL simply needs a rule to permit access to it.

B. Access to Cisco ISE must be allowed on the pre-authentication ACL:
This is relevant for Central Web Authentication (CWA) . For local web authentication, the redirect is to the WLC's virtual interface, not an external ISE server.

C. Management traffic from the guest network must be configured on the ACL rules:
This is the opposite of the engineer's goal. The requirement is to block guest network traffic from reaching the management interface while still allowing portal access.

References:
Cisco Wireless Controller Configuration Guide - CPU ACL and web authentication prerequisites .
Cisco Wireless Controller Configuration Guide - Access Control Lists .

Explanation:

The requirement is to authenticate administrative users from an external repository and, critically, to identify each user and determine their specific access level for managing the WLC. TACACS+ is the protocol specifically designed for this purpose.

Why the others are wrong:

B. RADIUS:
While RADIUS is an AAA protocol, it is primarily used for network access (authenticating wireless clients). Its authorization capabilities are less granular, and it is not the primary protocol recommended for controlling a user's precise access level on a network device .

D. LDAP:
LDAP is a protocol for querying and authenticating against directory services. It can validate user credentials but does not offer the separate, granular authorization services needed to define a user's specific privilege level on the WLC .

A. network policy server:
This is a generic term often referring to a RADIUS server like Cisco ISE and is not a specific protocol. While ISE can act as a TACACS+ server for device administration, the protocol that must be configured on the WLC for this specific function is TACACS+ .

References
Cisco Documentation: TACACS+ implementation and AAA services on WLC
Cisco Documentation: Configuring TACACS+ for WLC device administration with ISE
Cisco Documentation: Authorization tasks mapped to WLC GUI menus

Explanation:

Cisco Wireless LAN Controllers (WLCs) enforce a hard limit of four access points that can be used to contain a single rogue device . This value is configurable and must be set within a range of 1 to 4 . The default setting for auto-containment is to use a single AP, but when set to level 4, the controller coordinates the maximum of four APs to mitigate the threat . When containment is triggered, the controller typically selects the APs with the strongest Received Signal Strength Indicator (RSSI) to the rogue device for the most effective response .

Why the others are wrong:

A. 1: This is the minimum/default number, not the maximum.

B. 2: This is a valid but lower configuration option.

C. 3: While a possible setting, it does not represent the maximum allowed.

References:

Cisco Rogue Detection and Mitigation Guide: A rogue device can be contained using 1-4 APs .

Cisco WLC Configuration Guide: Maximum Number of APs to contain a rogue is a dropdown option of 1, 2, 3, or 4 .

Explanation:

To configure WebEx traffic to adjust the precedence and override the QoS profile on the WLAN, the engineer must create an Application Visibility and Control (AVC) profile for WebEx.

AVC profiles on Cisco Wireless LAN Controllers use Network-Based Application Recognition (NBAR) to classify and mark application traffic. By creating an AVC profile for WebEx, an administrator can define a specific action for WebEx traffic, which includes setting the DSCP (Differentiated Services Code Point) value to adjust the precedence of the traffic. The AVC profile can then be applied to a WLAN to enforce the QoS marking. This allows the wireless network to properly prioritize WebEx traffic over other data, ensuring higher quality for the application.

Why the others are wrong

A. Change the WLAN reserved bandwidth for WebEx:
This option is incorrect because reserving bandwidth is a different QoS concept (often related to CAC) and is not the mechanism used to adjust the precedence (DSCP marking) of specific traffic.

C. Create an ACL for WebEx:
Access Control Lists (ACLs) are used for filtering or classifying traffic based on IP addresses and ports, but they do not support the Layer 7 application-specific marking that AVC profiles provide for applications like WebEx.

D. Change the AVC application WebEx-app-sharing to mark:
This option incorrectly assumes that the marking can be applied directly to the application from the global list. The correct method is to create a new AVC profile where the WebEx application is added and its QoS marking is defined.

References
Cisco AVC and QoS for Wireless Configuration Guide
Cisco Wireless LAN Controller (WLC) AVC Configuration

Explanation:

To enable communication between the Mobility Services Engine (MSE) and the Wireless LAN Controller (WLC) over NMSP, you must allow TCP port 16113 through any intermediate firewall or router. Cisco's documentation for CMX and related wireless services consistently identifies this as the required port for NMSP traffic.

Key points regarding this configuration:

Protocol: NMSP runs over TCP. It is a two-way protocol that manages all communication between the MSE and the WLC.

Traffic Handling: When the MSE is in a different network segment, the firewall (or router) between them must be configured to permit TCP traffic on port 16113 in both directions to allow the NMSP session to be established and maintained.

Why the others are wrong

A & D (UDP ports):
The specified UDP ports (16113 and 16666) are incorrect for NMSP communication. The NMSP protocol uses TCP as its transport layer protocol, not UDP. UDP ports are used for other services, such as SNMP (UDP 161/162).

B (TCP/16666):
TCP port 16666 is not the standard port used for NMSP. The documented and verified port for NMSP is 16113.

References
Cisco CMX Configuration Guide: Port matrix documentation confirming NMSP uses TCP port 16113 for communication between CMX/MSE and WLC.

Cisco Hyperlocation Deployment Guide: This guide also states that port 16113 must be open for NMSP traffic between the WLC and CMX.

Explanation:

The primary difference between Protocol Independent Multicast (PIM) Dense Mode and Sparse Mode is how they handle the distribution of multicast traffic:

PIM Dense Mode (PIM-DM):
Uses a flood and prune mechanism. It initially floods multicast traffic to all routers in the network and then prunes branches that do not have interested receivers.
Best suited for networks with many receivers (high density) and high bandwidth availability.
Assumes that receivers are densely populated and that bandwidth is not a major constraint.

PIM Sparse Mode (PIM-SM):
Uses a pull model with distribution trees rooted at a Rendezvous Point (RP). Traffic is only forwarded to routers that explicitly request it.

Best suited for networks with few receivers (low density) and limited bandwidth.
More efficient for large networks or WAN environments where unnecessary flooding would waste bandwidth.

Why the others are wrong

A. Sparse mode supports only one switch. Dense mode supports multiswitch networks:
Incorrect. Both modes support multi-switch networks. Sparse mode uses RPs to build distribution trees across multiple switches, and dense mode floods across all switches.

B. Sparse mode floods. Dense mode uses distribution trees:
Incorrect. This is the reverse of the correct behavior. Sparse mode uses distribution trees; dense mode floods.

D. Sparse mode supports multiswitch networks. Dense mode supports only one switch:
Incorrect. Both modes support multiswitch environments. The limitation is not the number of switches, but the mechanism of traffic distribution.

References
Cisco 300-430 ENWLSI Official Certification Guide – Chapter on Multicast and PIM Modes.
Cisco Multicast Configuration Guide – PIM Dense vs. Sparse Mode comparison.

Explanation:

Open Authentication (Option A):
A rogue AP operating with open authentication requires no pre-shared key or EAP credentials to connect. This poses a severe security risk because corporate client devices with aggressive roaming/probing profiles will automatically associate with open SSIDs, bypassing enterprise layer 2 security and exposing client data to interception (man-in-the-middle attacks).

High RSSI (Option B):
A high Received Signal Strength Indicator (RSSI) measured by managed APs indicates that the rogue AP is physically located inside or immediately adjacent to the facility. High RSSI rogues generate a strong RF footprint that easily overrides surrounding AP signals, inducing nearby clients to associate with the rogue device.

Accepts Clients (Option D):
A rogue AP that actively accepts clients and bridges wireless client traffic to an untrusted or internal wire represents an immediate breach point. Once corporate clients associate, the rogue can inspect, hijack, or corrupt user data sessions, bypassing edge network controls.

Why Other Options Are Incorrect
C. foreign SSID:
An AP broadcasting an unknown or foreign SSID (like a neighbor's Wi-Fi network) generally presents a lower threat level compared to a rogue using a corporate or matching SSID, as internal clients are not typically configured to auto-connect to unrecognized SSIDs.

E. low RSSI & F. distant location:
A low RSSI indicates the rogue AP is situated at a distant location (such as an adjacent building or street). These devices present a minimal threat because their signals are too weak for interior enterprise clients to reliably associate with or maintain connections.

References

Cisco Wireless Controller Configuration Guide (Managing Rogue Devices): Details rogue classification rules and threat scoring, classifying high RSSI values (typically above -70 dBm), open security profiles, and active client associations as critical indicators of high-risk rogue deployments requiring immediate containment or physically locating the device.

Explanation:

The core issue is that a single WLAN with Silver QoS treats all traffic as best-effort (DSCP 0), causing poor voice quality for Cisco Jabber. The requirement is to keep the WLAN's default QoS at Silver but elevate Jabber traffic specifically to Platinum (voice) priority.

Why the others are wrong

B. Configure the WLAN to broadcast on 5 GHz radios only:
While moving to 5 GHz improves overall performance due to less interference, it does not solve the fundamental QoS marking problem. Jabber voice would still be treated as best-effort even on a 5 GHz network.

C. Enable Cisco Centralized Key Management (CCKM):
CCKM is a fast-roaming protocol that reduces authentication times for clients. It has no effect on QoS classification or packet marking.

D. Configure QoS on the mobile devices:
Jabber applications can mark traffic, but the network must be configured to trust and preserve those markings, which is not the case here . The Cisco WLC must explicitly be configured to override the WLAN's Silver QoS for Jabber, which is what the AVC profile does.

References

Cisco Wireless Controller Configuration Guide: AVC profile rules with Mark action override the WLAN QoS profile . Designing the Wireless LAN for Cisco Jabber: Recommends AVC to re-mark Jabber traffic to the appropriate DSCP values .

Explanation:

MAC OUI (Option C):
When a client associates to an AP, the WLC inspects the first 24 bits (3 bytes) of the client's MAC address—known as the Organizationally Unique Identifier (OUI). This value is matched against the IEEE vendor registry to identify the hardware manufacturer (e.g., Apple, Cisco, Intel).

DHCP Options / TLVs (Option B):
As the client requests an IP address via DHCP, the WLC inspects the DHCP broadcast payload. It extracts key fields such as Option 12 (Hostname), Option 60 (Vendor Class Identifier), and Option 55 (Parameter Request List) to accurately determine the device type and operating system family.

HTTP User Agent (Option A):
When a client launches a web browser, the WLC/ISE intercepts HTTP GET requests to read the User-Agent header. This string contains granular information regarding the client's specific operating system version, browser engine, and application environment.

Why Other Options Are Incorrect

D. hostname:
While the hostname string is used within profiling, it is an extracted sub-attribute inside the DHCP payload (Option 12) rather than an independent primary profiling method or protocol property.

E. OS version:
OS version is the result or outcome of the profiling analysis derived from HTTP User-Agent and DHCP option parameters, not an input mechanism used to collect raw data.

F. IP address:
An IP address uniquely identifies a device on a Layer 3 network, but it does not provide identifiable characteristics regarding the underlying vendor, hardware type, or OS.

References:

Cisco Wireless LAN Controller Native Profiling Guide: Specifies that local WLC device classification relies on three primary probe vectors: MAC OUI, DHCP TLV inspection, and HTTP User-Agent parsing.