Free 300-430 Practice Test Questions 2026

Explanation:

In Modular QoS CLI (MQC) configuration on Cisco switches, QoS policy enforcement relies on a three-tier hierarchy:

Class Map (class-map): Identifies and classifies incoming traffic flows by matching specific criteria—such as DSCP markings, CoS values, or access lists.

Policy Map (policy-map): Defines the specific actions (e.g., trust, remark, prioritize, or shape) applied to the traffic classes defined within the class map.

Service Policy (service-policy): Binds the policy map to a specific ingress or egress interface.

If the engineer created a policy map on the switch without binding it to a properly defined class map (or without configuring matching parameters inside the class map), the switch cannot classify traffic correctly. As a result, the incoming DSCP/CoS packet markings from the Wireless LAN Controller (WLC) default to standard best-effort processing or get rewritten unexpectedly, corrupting end-to-end QoS preservation.

Why Other Options Are Incorrect:

A. NetFlow:
NetFlow is a monitoring and visibility tool used for IP traffic flow collection and analysis; it plays no active role in preserving or modifying QoS packet markings.

B. port channel:
Port Channel aggregates physical links for redundancy and load balancing. While a policy map can be applied to a port channel, missing a port channel itself does not cause QoS marking preservation errors.

C. ACL:
Access Control Lists can be used inside a class map to match specific IP addresses or ports, but the class map itself is the required structural MQC component that feeds traffic into the policy map.

References:

Cisco Quality of Service Configuration Guide (Modular QoS CLI): Details the required relationship between Class Maps (class-map) and Policy Maps (policy-map) when classifying and preserving DSCP/CoS markings across switch interfaces.

Explanation:

To enable an autonomous AP to authenticate to an upstream switch via 802.1X, you must first create a credentials profile that stores the username and password the AP will use as a supplicant. The correct order of configuration is:

Create the credentials profile using dot1x credentials [PROFILE NAME] in global configuration mode. This enters the credential configuration submode.

Set the username using username username in the credential submode.

Set the password using password {0 | 7 | LINE} in the credential submode (where 0 means plaintext, 7 means encrypted, and LINE is the actual password).
Enter interface configuration mode for the GigabitEthernet 0 port using interface gigabitethernet 0.
Apply the credentials profile to the interface using dot1x credentials [PROFILE NAME] under the interface.

Why the other sequence is wrong:

The other sequence reverses the order of username/password configuration and incorrectly tries to apply the credentials before they are fully defined. Credentials must be created and the username/password configured before the profile is applied to the interface.

References:

Cisco IOS Configuration Guide – 802.1X Supplicant Configuration for Autonomous APs. Cisco 300-430 ENWLSI Official Certification Guide – Chapter on AP Authentication to Wired Infrastructure.

Explanation:

The nmsplb service in CMX is the load balancer responsible for distributing Network Mobility Services Protocol (NMSP) messages to location services . To enable load balancing of NMSP traffic across multiple CMX servers, the nmsplb.cmxgrouping feature flag must be set to true .

Cisco's official documentation specifies the exact command sequence:
Enable the CMX Grouping feature using cmxctl config feature flags nmsplb.cmxgrouping true .
Restart CMX using cmxctl restart .
Verify the feature is enabled using cmxctl config featureflags and checking the value for nmsplb.cmxgrouping .
This configuration spreads NMSP load across multiple CMX servers, optimizing data flow for APs in large networks with heavy location services traffic .

Why Other Options Are Incorrect:

A. nmsplb.cmx-ap-grouping true:
This is an incorrect command string and does not correspond to any documented CMX feature flag for NMSP load balancing .

C. nmsplb.cmx-loadbalance true:
While the name sounds relevant, it is not the correct documented command for enabling CMX grouping load balancing .

D. nmsplb.cmx-rssi-distribute true:
This is not the correct command for enabling NMSP load balancing across CMX servers .

References:
Cisco CMX Command Reference Guide – cmxctl config feature flags nmsplb.cmxgrouping
Cisco Support Documentation – Optimize CMX Performance
Exam discussions for 300-430 ENWLSI

Explanation:

For an Access Point (AP) to authenticate to a wired network switch using 802.1X, it acts as a supplicant and must support the EAP methods configured on the switch's RADIUS server. Cisco APs support EAP-FAST, EAP-PEAP, and EAP-TLS for 802.1X supplicant authentication . However, EAP-TLS is widely supported and considered the most secure option for this scenario . It uses digital certificates for mutual authentication, eliminating the security risks associated with passwords and providing strong identity verification. Cisco Wave 2 and Wi-Fi 6 APs natively support EAP-TLS for 802.1X authentication with switch ports .

Why Other Options Are Incorrect:

A. EAP-GTC:
While this is a valid EAP method, it is not standard for AP supplicant authentication to wired networks and carries a password in a generic way, making it less commonly used than EAP-TLS .

B. EAP-MD5:
VThis method only authenticates the AP to the server and does not provide mutual authentication, making it insecure and not recommended for the primary method in modern networks .

D. EAP-FAST:
Although supported and the default method for some Cisco APs, Cisco's best practice and many deployment guides specifically reference EAP-TLS as the preferred method due to its stronger security posture, especially for the more secure alternatives .

References:

Cisco Documentation: AP 802.1X Supplicant configuration supports EAP-FAST, EAP-TLS, and EAP-PEAP .

EAP-TLS is the recommended method for high-security environments .

Explanation:

When creating a Native Supplicant Profile (NSP) in Cisco Identity Services Engine (ISE) for BYOD onboarding, the profile provisions wireless settings directly to client operating systems (such as Windows, macOS, Android, or iOS).

SSID Name (Option C):
Defines the exact wireless network name (Service Set Identifier) that the client device must target and save to its local wireless profile.

Allowed Protocol (PEAP/TLS) (Option A):
Specifies the EAP authentication protocol allowed for securing communication between the client's native supplicant and the authentication server (such as PEAP-MSCHAPv2 for password-based access or EAP-TLS for certificate-based access).

Why Other Options Are Incorrect:

B. Allowed Protocol (Ms-CHAPv2/ EAP-FAST):
MS-CHAPv2 is an inner authentication method used within protocols like PEAP, rather than a top-level outer EAP protocol option selected during NSP configuration. EAP-FAST is not a standard protocol configuration parameter for general native supplicant profiles.

D. WLC Name:
The wireless controller name is an internal network infrastructure parameter; mobile device native supplicants only require the target network's broadcasted SSID to initiate connections.

E. Allowed Protocol (LEAP/ EAP-TTLS):
LEAP is an obsolete, insecure Cisco proprietary protocol and is not used in modern Cisco ISE Native Supplicant Profiles.

References:

Cisco Identity Services Engine Administrator Guide (Configuring Native Supplicant Profiles): Specifies the mandatory parameters required when building an NSP, which include the target SSID Name, Connection Type, and Allowed Protocol (PEAP or EAP-TLS).

Explanation:

The HA configuration fails because the provided information is missing the cmxadmin password of the secondary server. This is a mandatory parameter for establishing the HA pair .

The Cisco CMX HA setup process explicitly requires this credential. For example, during the CLI configuration process, the system will prompt for it directly with the question, "Please enter the cmxadmin user password for secondary:" . The setup will not proceed without it, which directly matches the described issue.

Why the others are wrong:

B. Use IP protocol 4242:
Port 4242 is used for CMX HA web services , but the issue is a missing authentication credential, not a networking port problem. The correct credential must be provided for the setup to proceed.

C. Place primary and secondary servers in different subnets:
This is incorrect. A key requirement for Cisco CMX HA is that the primary and secondary servers must be in the same subnet so that the virtual IP (VIP) can be switched between them during a failover .

D. Enable the virtual IP address:
While a VIP is typically used for HA, it is a configuration parameter, not a feature that is "enabled" on the primary server. The fundamental failure is the missing authentication credential, which occurs before the VIP can even be configured .

References:

Cisco CMX Configuration Guide – HA requires the secondary IP address and the cmxadmin user password for the secondary server .

Cisco CMX CLI Guide – Enabling HA requires entering the cmxadmin password for the secondary .

Explanation:

When provisioning Cisco CleanAir via Cisco Catalyst Center (formerly DNA Center) for managed wireless infrastructure (including Cisco Catalyst 9800 Series Controllers and APs):

Enable CleanAir Device Reporting (Option D):
Within the CleanAir profile/configuration model inside Catalyst Center, administrators must explicitly enable CleanAir and CleanAir Device Reporting. This instructs the managed Access Points to actively process RF ASIC data, detect non-Wi-Fi interferers (such as Bluetooth, microwave ovens, cordless phones, and video transmitters), and report interference metrics to the controller and Catalyst Center.

Apply Model to Wireless Network Profile (Option E):
In Catalyst Center's design workflow, RRM and CleanAir settings are encapsulated inside RF profiles or configuration models. To push these parameters to specific wireless controllers and access point groups, the created CleanAir configuration model must be attached/applied to a Wireless Network Profile that maps to the target site location.

Why Other Options Are Incorrect:

A. Enable Neighbor List Dual Band on the configured WLANs:
Neighbor List settings relate to client roaming steering (such as 802.11k neighbor reports), not non-Wi-Fi RF interference detection via CleanAir.

B. Disable Persistent Device Propagation in the CleanAir configuration model:
Persistent Device Propagation (PDP) allows CleanAir to track interfering devices as clients roam across AP cells; disabling it weakens interference tracking rather than enabling management.

C. Configure the RX SOP threshold to be high:
Receiver Start-of-Packet (RX SOP) adjusts AP receiver sensitivity to ignore weak Wi-Fi frames in high-density deployments; it does not configure CleanAir interferer detection or management profiles.

References:

Cisco Catalyst Center Wireless Network Design & Provisioning Guide: Details creating wireless telemetry models and attaching CleanAir configuration profiles to Site-based Wireless Network Profiles to enforce interference detection across managed WLCs.

Explanation:

When creating a webhook via the Cisco Catalyst Center (DNA Center) API to send HTTP notifications to an external application, the API call must specify both the HTTP method and the certificate trust behavior. For this scenario, the requirements are:

Method: The correct HTTP method to create a new webhook is POST. The POST method is used to create a new resource (the webhook) on the server.

Certificate Trust: The webhook URL https://example.com/webhook uses a self-signed certificate. By default, Cisco Catalyst Center will reject connections to URLs with untrusted certificates. To bypass this, the trustCert parameter must be set to true, explicitly telling the controller to accept the self-signed certificate and establish the HTTPS connection.

Therefore, the payload must contain "method": "POST" and "trustCert": true for the webhook to be created successfully and function correctly.

Why the others are wrong:

Option A ("method": "PUT", "trustCert": true):
PUT is used to update an existing resource, not create a new one. Creating a new webhook requires POST.

Option B ("method": "PUT", "trustCert": false):
Incorrect for both reasons. PUT is for updates, and trustCert: false would fail because the self-signed certificate would be rejected.

Option D ("method": "POST", "trustCert": false):
While POST is correct for creation, trustCert: false is incorrect because it would cause the API to reject the self-signed certificate, preventing the webhook from establishing an HTTPS connection.

References:
Cisco Catalyst Center API Documentation – Webhook Creation Endpoint (POST /dna/integration/webhook).
Cisco Catalyst Center Developer Guide – trustCert parameter for handling self-signed certificates in HTTPS notifications.

Explanation:

When AAA Override (Identity-Based Networking) is enabled on a WLAN, the Cisco Wireless LAN Controller (WLC) accepts vendor-specific RADIUS attributes returned by Cisco Identity Services Engine (ISE) upon successful authentication. These dynamic attributes override default WLAN settings on a per-client basis:

IPv6 ACL (Option C):
ISE returns the Airespace-IPv6-ACL-Name attribute to assign a specific IPv6 Access Control List dynamically to the client, overriding the standard default ACL set on the WLAN.

DSCP Value (Option D):
ISE returns the Airespace-DSCP attribute to enforce custom Layer 3 Quality of Service (QoS) markings on client traffic, dynamically altering packet prioritization from the default QoS profile defined on the WLAN/Policy Profile.

Why Other Options Are Incorrect:

A. DHCP timeout:
DHCP server options and lease timeouts are negotiated directly between the client device and the network's DHCP server; they are not dynamically pushable RADIUS AAA override parameters.

B. DNS server:
Domain Name System server addresses are assigned via standard DHCP options or IPCP during IP address lease acquisition, not via RADIUS AAA override attributes.

E. multicast address:
Multicast group addresses and delivery profiles are bound globally or at the WLAN/interface configuration level rather than being dynamically assigned per individual client via AAA override attributes.

References:

Cisco Wireless LAN Controller Configuration Guide (AAA Administration - Identity Networking): Documents supported RADIUS VSA attributes for AAA Override, including Airespace-IPv6-ACL-Name and Airespace-DSCP for dynamic policy enforcement.

Cisco Catalyst 9800 Series Configuration Guide (Identity-Based Networking Services): Outlines per-client dynamic authorization capabilities using ISE RADIUS return attributes.

Explanation:

The core issue is a fundamental architectural limitation of the Cisco Hyperlocation solution when used with CMX Grouping. While CMX Grouping is designed to load-balance NMSP (Network Mobility Services Protocol) data between multiple CMX servers for RSSI-based location tracking, it cannot be used to distribute AoA (Angle of Arrival) data .

Why option D is correct:
The Hyperlocation/AoA feature is designed to work with a single, designated Hyperlocation-enabled CMX server . If you add a second virtual CMX server and enable Hyperlocation on it, you create a configuration conflict . The system essentially expects a single "primary" CMX instance to process the specialized AoA packets. Load distribution for Hyperlocation is not supported across multiple CMX instances .

Why the other options are wrong:

A. Enable Hyperlocation on the WLC:
While this is a necessary prerequisite for the feature (done under Wireless > Access Points > Global Configuration) , the question states the network is already sending AoA data to a CMX 3375 Appliance, implying this is likely already enabled. The problem is not the WLC setting, but the presence of a second Hyperlocation-enabled CMX server .

B. Enable the HALO module on the CMX appliance:
The "HALO module" refers to a physical component (antenna and radio module) for AP models like the 3600 and 3700 series . It is not a software feature that can be "enabled" on the CMX appliance itself. It is a hardware requirement on the access points .

C. Allow port 2003 for AoA packets:
Port 2003 is indeed the UDP port used for AoA packets to flow from the WLC to the CMX . However, the issue is not network connectivity. The AoA metrics are missing because the virtual server receiving the data is not configured to process it correctly (due to the Hyperlocation conflict), not because the traffic is blocked .

References:

Cisco documentation confirms that a single controller can only have one active Hyperlocation-enabled CMX server .

Hyperlocation diagnostics on CMX include checks for this configuration .

Explanation:

In a Cisco Central Web Authentication (CWA) architecture using Auto-Anchor mobility (Foreign-Anchor setup for guest traffic):

Traffic Termination on Anchor: Client traffic is EoIP/CAPWAP tunneled from the Foreign controller directly to the Anchor controller located in the DMZ. Therefore, the Anchor controller is responsible for enforcing pre-authentication ACLs and handling Layer 3 HTTP/HTTPS redirection.

Matching ACL Names: RADIUS attributes (such as url-redirect-acl) pushed from Cisco ISE tell the WLC which redirection ACL to apply. For HTTP redirection to take place, the designated ACL name must exist and be configured on the Anchor controller. If the ACL definition is missing on the Anchor controller, the controller cannot intercept HTTP traffic to initiate the WebAuth redirection flow.

Why Other Options Are Incorrect:

B. Enabled DHCP option 7:
DHCP Option 7 specifies a server for the Logging/Syslog protocol and plays no role in web authentication or HTTP redirect mechanisms.

C. Remove the CN entry from the SAN:
Certificates require matching Subject Alternative Names (SAN) and Common Names (CN) for HTTPS portal trust; removing valid CN entries causes certificate trust failures rather than resolving redirection mechanisms.

D. Allow ICMP toward the portal:
While reachability to the web portal is necessary, HTTP/HTTPS redirection is driven by TCP port 80/443 interception; permitting ICMP (ping) is not the underlying requirement to trigger HTTP portal redirection.

References:

Cisco Central Web Authentication with Cisco ISE Deployment Guide: Specifies that in Mobility Anchor deployment scenarios, redirect ACLs pushed via RADIUS override attributes must be defined locally on the Anchor WLC where the client's traffic terminates.

Explanation:

To improve roaming for remote branches connected by low-bandwidth VPN links, Cisco Centralized Key Management (CCKM) must be configured within an AP Group .

CCKM is a fast-roaming mechanism that significantly reduces authentication delay when a client roams between access points . Instead of requiring a full EAP authentication exchange with the RADIUS server—which would be slow and costly over a low-bandwidth VPN—the controller caches the client's Pairwise Master Key (PMK) .

Why the other options are wrong:

B. FlexConnect:
While FlexConnect groups are used to group APs at remote sites for features like local switching and local authentication , the search results indicate that CCKM fast roaming requires an AP Group to be configured for the key cache to be shared . FlexConnect is a deployment mode, not the specific grouping mechanism for CCKM sharing.

A. RF:
RF (Radio Frequency) groups are used for coordinating Radio Resource Management (RRM) algorithms like dynamic channel assignment and transmit power control . They do not play a role in caching client security keys for fast roaming.

C. Interface:
This is not a type of group used in this context. An "interface" is a logical network interface on the WLC or AP, not a grouping mechanism for sharing roaming credentials.

References:
ExamTopics Discussion: CCKM PMK sharing occurs via AP Groups .
Cisco Wireless Configuration Guide: AP Groups share CCKM/PMK cache .