Free 300-430 Practice Test Questions 2026

Explanation:

Cisco's AutoQoS feature is designed to simplify the deployment of Quality of Service (QoS) across the network. On the Catalyst 9800 Series Wireless Controller, the statement that best describes its function is that it automates deployment of wired QoS and makes wireless QoS implementation easier.

AutoQoS automates the complex task of configuring QoS, allowing network administrators to implement robust QoS policies with minimal manual intervention and expertise. It uses "AutoQoS" for wireless clients and is intended to provide the same simplicity for controller deployments.

Why the others are wrong

A. It has a set of predefined profiles that you cannot modify further:
This is incorrect. While AutoQoS uses predefined templates and profiles for different application classes (like VoIP and Video), it is not a static or unmodifiable set. You can create custom AutoQoS policies to fine-tune or override the default configurations.

B. It matches traffic and assigns each matched packet to QoS groups:
This describes a more granular policy-based classification, which is not the primary, defining feature of AutoQoS. The main purpose of AutoQoS is to automate the entire QoS policy deployment process.

D. It allows the output policy map to put specific QoS queues into specific subgroups:
While AutoQoS will configure the appropriate queuing mechanisms, this statement is too specific and does not capture the primary function of automating deployment.

References:

Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide – AutoQoS and Wireless QoS.
Exam discussion on AutoQoS features.

Explanation:

The goal is to configure the Cisco Catalyst 9800 Wireless Controller so that client traffic exits the network directly at the access point's switch port. This behavior is known as FlexConnect local switching, and it is configured within a Policy Profile.

On the Catalyst 9800, the Policy Profile is the container for all forwarding and security policies applied to a WLAN. To enable local switching, you navigate to the Policy Profile configuration mode and issue the no central switching command. This disables the default behavior of tunneling all traffic back to the controller and allows the AP to switch traffic locally.

Therefore, the correct CLI sequence is to enter global configuration mode, specify the wireless policy profile, disable central switching, and exit.

Why the others are wrong:

A. Option A:
This uses wireless profile policy which is correct, but it uses local switching, which is not a valid command for this purpose. The correct syntax is no central switching.

B. Option B and C. Option C:
These both use the command wireless flexconnect policy, which is not a valid configuration mode on the Catalyst 9800. FlexConnect settings (like local switching) are applied within the wireless profile policy.

References:

Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide (FlexConnect) - CLI configuration steps

Explanation:

In Cisco Identity-Based Networking (IBN) on an AireOS controller, the ACL that a client receives is determined by the authentication and authorization policies applied to that specific user or group. The AAA Override feature enables the controller to accept and apply RADIUS attributes returned from the AAA server (like Cisco ISE) on a per-client basis .

When a client authenticates, the process works as follows:
The ISE server authenticates the user and determines their policy (e.g., HR group).
ISE returns RADIUS attributes, which can include an ACL name. According to Cisco documentation, "The ACL that you choose overrides any ACL that is configured for the interface" .
The controller applies the ACL returned by the AAA server directly to the client's session.

In this scenario, the corporate_clients interface has BASE_ACL applied. However, when an HR user connects, ISE references HR_ACL in its policy. Because AAA Override is enabled, the ACL applied to the individual client session is the one provided by the AAA server—HR_ACL . This is further confirmed by exam discussions on this topic, which state that the ACL referenced by ISE "takes precedence over any ACL applied to the interface" .

Why the others are wrong:

A. HR_ACL appended with BASE_ACL:
ACLs are not combined or appended in this scenario. The AAA-returned ACL overrides the interface ACL; they are not merged.

C. BASE_ACL appended with HR_ACL:
This reverses the order and still assumes a combination of the ACLs. The BASE_ACL is the one that is overridden.

D. BASE_ACL only:
This is incorrect because the client's HR policy specifically provides HR_ACL. The whole point of identity-based networking is to apply specific policies, not the default one.

References:
Cisco Wireless Controller Configuration Guide – "AAA Override" and per-client ACL application .
Cisco 300-430 exam discussion confirming precedence of AAA-returned ACLs .

Explanation:

The problem described—all APs receiving multicast traffic instead of only the APs with interested clients—is the classic symptom of IGMP snooping being disabled on the Wireless LAN Controller .

When IGMP snooping is enabled, the controller listens to IGMP reports from wireless clients, which indicate which multicast groups they wish to join. The controller processes these reports, creates unique multicast group IDs (MGIDs) that map to specific client MAC addresses, and updates the AP's MGID table accordingly. When the controller receives multicast traffic for a particular group, it forwards it to all APs via the CAPWAP multicast group, but only the APs that have active clients subscribed to that group will transmit it over the air. The other APs will not transmit it .

Why the others are wrong:

A. The multicast group includes all APs:
Multicast groups are defined by IP addresses, not by APs. APs do not join multicast groups; clients do . This statement does not represent a valid scenario.

B. The wrong multicast address was used:
While an incorrect address would cause the wrong clients to receive traffic or prevent delivery entirely, it would not cause all APs to receive and transmit the traffic. The symptom points to a behavior issue (flooding), not an addressing issue .

C. The multicast group is assigned the wrong VLAN:
Assigning a multicast group to the wrong VLAN would prevent clients in the correct VLAN from receiving traffic, but it would not cause all APs to receive the traffic. This is a configuration issue, not a flooding mechanism issue .

References:

Cisco WLC Configuration Guide – IGMP Snooping behavior and MGID table management

Cisco Catalyst 9800 WLC Configuration Guide – IGMP Snooping and multicast forwarding decisions

Explanation:

Client MAC Address (Option D):
When initiating a location accuracy test via the Cisco CMX Command Line Interface (CLI), the command syntax requires specifying the unique target client identifier. The cmxloc start command prompts for or accepts the client MAC address to target tracking, filter incoming RSSI/AoA packet metrics, and isolate the endpoint under evaluation.

X, Y Real Location (Option A):
To measure error distance and calculate accuracy metrics (such as average error distance in meters), CMX needs a ground-truth baseline. The command mandates inputting the physical X, Y real location coordinates (derived from the map grid) where the test device is physically situated. CMX then compares these known coordinates against calculated location estimates (via RSSI, AoA, or FUSION) to generate precision reports.

Why Other Options Are Incorrect:

B. client description:
Client descriptive strings or friendly names are optional UI metadata and are not parameters used in the cmxloc start execution syntax.

C. AP name:
While APs supply the underlying RSSI and Angle of Arrival (AoA) data frames to CMX, specific AP names are not passed as input arguments to the CLI accuracy test.

E. WLC IP address:
Controller connectivity parameters are pre-configured via NMSP/Fastpath setup, so specifying the WLC IP address is unnecessary when running client-level accuracy commands.

References:

Cisco CMX Command Reference Guide: Documents command syntax and required inputs for cmxloc start, cmxloc monitor, and cmxloc list accuracy utilities.

Cisco Hyperlocation / AP4800 Deployment Guide: Outlines CLI testing procedures for validating Angle of Arrival (AoA) and location accuracy using the cmxloc suite on Cisco CMX.

Explanation:

To prioritize traffic for a specific application like Cisco IP cameras using AVC, the correct action within an AVC rule is Mark .

Cisco AVC uses deep packet inspection to identify the traffic from a specific application and allows you to define actions for that identified traffic . Within an AVC profile, the Mark action enables you to set a Differentiated Services Code Point (DSCP) value on the packets that match the rule . This marking instructs the network to treat that traffic with a specific priority level.

For IP cameras, which typically handle video streams, you would apply the Gold QoS level (DSCP AF41/34) to this traffic . This prioritization ensures that video traffic is queued and forwarded ahead of less critical data, directly addressing the engineer's requirement .

Why the others are wrong:

A. permit-ACL:
This is not a valid action within an AVC rule. The standard actions are permit, drop, mark, and rate-limit.

B. WMM required:
This is a global WLAN setting for enabling 802.11e Quality of Service, not an element configured within a rule for a specific application.

D. rate-limit:
This action is used to restrict the bandwidth of an application, which is the opposite of what is needed to prioritize its traffic .

References:

Cisco Wireless Controller Configuration Guide for AVC .
Cisco BYOD and AVC Design Guide, which outlines the configuration steps for a Cisco IP Camera with the "Gold" marking .

Explanation:

Software Version Prerequisite (Option D):
Multicast Domain Name System (mDNS) Gateway / Bonjour services support on Cisco Wireless LAN Controllers was introduced in AireOS release 7.4.100.0. Therefore, controller code must be newer than legacy 7.0 builds (specifically 7.0.6+) for mDNS snooping and policy controls to function.

IPv6 Protocol Restriction (Option E):
In legacy Cisco AireOS WLC releases, mDNS profile snooping, service discovery, and policy mapping are explicitly restricted to IPv4 unicast/multicast environments. IPv6 mDNS packet snooping and cross-VLAN bridging are unsupported across these wireless controller frameworks.

Why Other Options Are Incorrect:

A & B. UDP Port Restrictions:
mDNS operates natively and strictly over UDP port 5353 as defined by RFC 6762. Option A is incorrect because port 5436 is not used by mDNS, and Option B is incorrect because mDNS must use port 5353.

C. mDNS on FlexConnect APs:
While mDNS originally had limitations on remote sites, Cisco added full support for mDNS snooping on FlexConnect APs with locally switched WLANs using local mDNS profiles and AP-group configurations.

References:

Cisco Wireless LAN Controller Configuration Guide (Configuring mDNS): Details mDNS service discovery prerequisites and restrictions, explicitly noting that mDNS snooping requires AireOS software release 7.4 or later and is limited strictly to IPv4 packets.

Explanation:

The VideoStream/Multicast Direct feature improves the delivery of multicast video traffic over a wireless network. The mechanism works by converting the unicast frames it receives from the controller into multicast frames when they are transmitted over the air to clients . This makes it an efficient method for delivering high-bandwidth, low-latency traffic like video to multiple clients simultaneously.

Why the others are wrong

A. IP multicast traffic is reliable over WLAN by default as defined by the IEEE 802.11 wireless multicast delivery mechanism. This is false. The IEEE 802.11 multicast delivery mechanism is inherently unreliable. It does not use acknowledgments or retransmissions, making it "send and hope for the best."

B. Each VideoStream client acknowledges receiving a video IP multicast stream. This is incorrect. VideoStream clients do not send acknowledgments for the video stream. If they did, the feature would not be efficient for large groups.

D. It makes the delivery of the IP multicast stream less reliable over the air, but reliable over Ethernet. This is also false. The feature is designed to make the delivery of the IP multicast stream more reliable over the air by using mechanisms like client feedback and rate adaptation, but it does not reduce reliability.

References
Cisco VideoStream Deployment Guide
Cisco WLC Configuration Guides

Explanation:

When configuring multicast for two Wireless LAN Controllers in different locations, each controller must be assigned a unique CAPWAP multicast group address. The CAPWAP multicast group address is used by the controller to forward multicast traffic to its associated APs in a single stream, reducing CPU load .

If both controllers share the same group address, APs from one controller will receive multicast traffic from the other controller . While the AP will discard packets from a foreign controller based on the source management address, this still creates unnecessary network traffic and congestion . Assigning unique addresses prevents this cross-controller traffic duplication, localizing multicast traffic to each controller's associated APs . The multicast address is typically chosen from the 239.0.0.0/8 range .

Why the others are wrong:

B. Each WLC management address must be in the same multicast group:
Incorrect. The management address is a unicast IP used as the source for multicast packets, not an address assigned to a multicast group .

C. Both WLCs must be assigned the same multicast group address:
This is the exact behavior that should be avoided as it causes unnecessary traffic duplication .

D. Each WLC management address must be in a different multicast group:
This incorrectly conflates the management interface IP (unicast) with the CAPWAP multicast group address (multicast) .

References:

Cisco WLC Configuration Guide: "If you have multiple controllers, configure different group address for different controllers" .

Controller-based Wireless LAN Fundamentals: "The current recommendation is to define a unique multicast group address per WLC in the mobility domain" .

Explanation:

The problem described (both primary and backup Cisco CMX servers reporting as primary) indicates a misconfiguration in the high availability (HA) state, and the fix is to correctly designate one of the servers as the backup.

Cisco CMX's command-line interface provides the cmxha secondary command for all secondary server-related operations. Its specific syntax is cmxha secondary { convert | info }. The convert subcommand is what makes the current system function as the backup server, which resolves the issue of an incorrect state.

This command should be executed on the server intended to be the secondary node to properly establish its role in the HA pair. Once converted, it will function as the backup to the primary server.

Why the others are wrong:

A. cmxha convert backup and B. cmxha backup convert:
These are not valid CLI commands. Cisco documentation for CMX HA uses primary and secondary as keywords (e.g., cmxha primary convert, cmxha secondary info), not backup.

C. cmxha secondary convert:
This reverses the order of the syntax. The official documentation consistently uses the format cmxha secondary { convert | info }, making cmxha convert secondary the correct sequence to designate the system's role.

References:
Cisco CMX Command Reference Guide: cmxha secondary command syntax and usage.
Cisco CMX High Availability Configuration Guide: Command procedures for configuring HA roles.

Explanation:

The APs are failing to rejoin the controller after a reboot because their accounts in Cisco ISE are being disabled. The issue stems from using AP MAC addresses as local user accounts in ISE for AP Authorization. These static credentials never change. Because the ISE password policy enforces a periodic password change (e.g., after a set number of days if not changed), these accounts become disabled, leading to authentication failures and blocking the APs from re-joining the controller . The solution is to disable the password expiry policy for these specific user accounts in ISE .

Why the others are wrong:

A. Remove APs from the exclusion list:
The exclusion list is for clients that behave badly (e.g., too many failed attempts), not for a simple authorization failure due to a disabled account.

C. Install a valid EAP certificate:
APs are using MAC address authentication ("MAC as username/password") for authorization, not a certificate-based EAP method like EAP-TLS .

D. Upgrade Cisco ISE:
The issue is not a bug but a documented behavior of ISE's local user password policies .

References:

Cisco AP Authorization Guide: The password policy must be lowered as the MAC address (used as password) never changes .

Cisco ISE Administrator Guide: Account Disable Policy for users whose passwords are not changed .

Explanation:

Virtual MSE Sizing Requirements: Cisco Mobility Services Engine (MSE) virtual appliances are deployed using specific capacity templates (Low End, Standard, and High End) based on the scale of managed Access Points (APs) and tracking licenses (such as wIPS or Context Aware CAS licenses).

Scaling Criteria Thresholds:
Low End: Supports up to 500 APs / 2,000 licenses.
Standard: Supports up to 2,000 APs / 5,000 licenses.
High End: Supports up to 5,000 APs and 10,000 wIPS/CAS licenses.

Because the network requirements (3,000 APs and 7,000 IPS licenses) exceed the upper boundaries of a Standard MSE instance (2,000 APs / 5,000 licenses), the deployment must be scaled up to a High End virtual server profile to handle the resource demands.

Why Other Options Are Incorrect:

A. virtual:
"Virtual" indicates the deployment mechanism (OVA/VMware deployment), not the resource/sizing profile required for the appliance.

B. standard:
Standard mode tops out at 2,000 APs and 5,000 licenses; deploying standard mode for 3,000 APs and 7,000 licenses will cause severe performance bottlenecks and license registration failures.

D. low end:
Low End mode is designed for branch/small office setups and caps out at 500 APs and 2,000 licenses.

References:

Cisco MSE Virtual Appliance Configuration Guide: Outlines OVA scaling specs and resource allocation tables (vCPU, RAM, Disk Space) for Low-End, Standard, and High-End deployment tiers based on tracked AP and endpoint/license density.