Free 300-430 Practice Test Questions and Answers (2026)

In a Cisco Wireless LAN Controller (WLC), rogue access points are APs detected in the RF environment that are not part of the managed wireless network. When other legitimate wireless networks exist in close proximity, such as in a multitenant building, their APs will be detected as rogues. The correct procedure is to classify these known, non-threatening APs as "friendly." This classification informs the system that the AP is a known entity and not a security threat, thereby preventing false positives and unnecessary security alerts while still tracking its presence.

A. adhoc: This classification is specifically for wireless devices operating in a peer-to-peer mode, not for infrastructure access points, which are described in the scenario.

C. malicious: This classification is reserved for APs that are identified as a direct security threat, such as an evil twin or an unauthorized AP connected to the corporate network.

D. unclassified: This is the default, initial state for any newly detected rogue AP. The question requires performing a classification, not leaving the AP in its default state.

1. Cisco Wireless LAN Controller Configuration Guide

Release 8.5

"Configuring Rogue Detection" chapter

"Information About Rogue Detection" section. This guide states

"A rogue AP is classified as one of the following: ... Friendly—The rogue AP is classified as a known AP." This directly supports classifying known

neighboring APs as friendly.

2. Enterprise Mobility 8.5 Design Guide

"Wireless Security" chapter

"Rogue AP Detection and Containment" section. This document clarifies the use case: "Rogues are classified as either friendly or malicious... A friendly rogue might be an AP in a neighboring office." This perfectly describes the multitenant building scenario.

3. Cisco AireOS 8.10 MR5 Configuration Guide

"Rogue Access Points" section. This guide outlines the classification states

confirming that "Friendly" is the appropriate state for a known AP that is not a threat

distinguishing it from "Malicious" and the initial "Unclassified" state. It notes

"When a rogue AP is declared

it is listed as an unclassified rogue. You can change the classification of the rogue AP..."

The Clients and Users → Client Summary report in Cisco Prime Infrastructure presents a graphical, time-bounded overview that counts all associated wireless clients and groups them by WLAN, band, AP, authentication type, device type, and other categories—exactly the “summary grouped data of the total number of wireless clients” requested.

A. Client Traffic Stream Metrics – focuses on packet-level airtime and throughput per client, not total‐client count summaries.

C. Posture Status Count – shows ISE posture-assessment states (compliant, non-compliant) rather than client association totals.

D. Mobility Client Summary – reports mobility (anchor/foreign) client details; limited to roaming/mobility events, not overall client population.

1. Cisco Prime Infrastructure 3.2 User Guide

“Reports > Clients and Users Reports > Client Summary” (OL-32112-01

p. 1364-1365): “Provides a summary of the number of wireless clients associated to the network

grouped by WLAN

AP

radio band… Displayed graphically.”

2. Cisco Prime Infrastructure 3.6 Administration Guide

Ch. 12 “Generating a Client Summary Report

” Table 12-6.

3. Cisco Prime Infrastructure 3.5 Quick Start Guide

“Client Summary report shows total number of clients and grouping options.”

The Cisco DNA Center Assurance interface provides tools to monitor network health, which includes viewing current and historical issues and alarms. When filtering this data, the user interface presents several predefined time ranges. The available options are typically the last 3 hours, the last 24 hours, and the last 7 days. The question asks for the maximum time range that can be viewed, which, according to the standard options provided in the interface, is 7 days. This allows administrators to analyze trends and investigate problems that have occurred over the past week.

A. 3 hours: This is a valid time-range option for viewing recent events, but it is the minimum predefined duration, not the maximum.

B. 24 hours: This is a standard and useful time range for daily analysis, but it is not the maximum available option.

C. 3 days: This is not a standard, predefined time-range option available in the Cisco DNA Center issues and alarms filter dropdown menu.

1. Cisco DNA Center User Guide

Release 2.3.5

"View Issues" Chapter. In the "Filter Issues" section

Step 3 explicitly states the available time range options: "From the Time Range drop-down list

choose the time range for which you want to view issues. You can view issues for the last 3 hours

24 hours

or 7 days." This confirms that 7 days is the maximum predefined selection.

2. Cisco DNA Center Assurance User Guide

Release 2.1.2

"Work with Issues" Chapter. The "Filter the List of Issues" section provides similar guidance: "In the Time Range field

click the down arrow and choose the time range for the issues you want to view (the last 3 hours

24 hours

or 7 days)." This corroborates the 7-day maximum across different versions of the software.

When integrating a Cisco Wireless LAN Controller (WLC) with a TACACS+ server for administrative access, specific attribute-value pairs must be configured in the user's shell profile on the server. The WLC maps these attributes to its internal management user roles. For a user requiring read-only permissions, the role attribute must be set to the value MONITOR. This value grants the user the ability to view all configurations, monitor status, and see logs on the WLC, but prohibits them from making any configuration changes, which directly corresponds to read-only access.

A. ADMIN: This value grants full read-write administrative privileges, which is more than the required read-only access.

B. MANAGEMENT: This is not a standard, predefined role value used by the WLC for TACACS+ integration.

D. READ: While descriptive, "READ" is not the specific keyword the WLC expects. The correct value for this access level is MONITOR.

1. Cisco Wireless Controller Configuration Guide

Release 8.5

"Configuring Security Solutions" Chapter

"Information About TACACS+" section: This guide explicitly lists the TACACS+ custom attributes for management user roles. It states

"For Read-Only role

the attribute is role=MONITOR."

Source: Cisco. (2017). Cisco Wireless Controller Configuration Guide

Release 8.5. Retrieved from Cisco.com. Specifically

the table detailing TACACS+ custom attributes for management user roles.

2. Security Configuration Guide

Cisco Wireless Controller

Release 8.10

"Configuring TACACS+" section: This document confirms the required attribute-value pairs for different access levels. It specifies that for a user to have Read-Only access

the TACACS+ server must return the cisco-av-pair shell:role=MONITOR.

Source: Cisco. (2021). Security Configuration Guide

Cisco Wireless Controller

Release 8.10. Retrieved from Cisco.com. The section on "Configuring TACACS+ (GUI)" details the required attributes.

In a Cisco Connected Mobile Experiences (CMX) high-availability (HA) deployment, a "split-brain" condition occurs when both servers assume the primary role, typically due to a network partition. To recover from this state, the administrator must manually intervene on the server that is intended to be the backup. The correct command to run on this server is cmxha backup convert. This command reverts the node's status from an erroneous primary state back to its designated backup role, allowing it to re-establish communication and synchronization with the legitimate primary server.

A. cmxha convert backup: This is incorrect syntax. The command structure requires the object (backup) to precede the action (convert).

C. cmxha secondary convert: This is incorrect syntax. The command uses the keyword backup, not secondary, and the word order is reversed.

D. cmxha convert secondary: This is incorrect syntax. The command uses the keyword backup, not secondary, for specifying the role conversion.

1. Cisco CMX Configuration Guide

Release 10.6

"Configuring High Availability" chapter

"Recovering from a Split Brain Scenario" section. The guide explicitly states: "To convert the secondary CMX server back to its original state

run the cmxha backup convert command on the secondary CMX server." This confirms the exact command and its purpose in resolving a split-brain issue.

When a public-facing NAT IP address is configured on the Wireless LAN Controller's (WLC) management interface, the WLC's default behavior is to respond only to AP discovery and join requests destined for that NAT IP address. This configuration prevents APs on the internal network, which use the WLC's private management IP, from joining. The command config network ap-discovery nat-ip-only disable modifies this behavior, allowing the WLC to respond to join requests sent to both its internal management IP and its external NAT IP. This ensures that both internal APs and external OfficeExtend APs (OEAPs) can successfully associate with the same controller.

A. config flexconnect office-extend nat-ip-only disable: This command does not exist in the documented CLI. The nat-ip-only setting is a global network discovery parameter, not a FlexConnect-specific one.

B. config network ap-discovery nap-ip-only enable: This command contains a typo (nap-ip-only). If corrected to nat-ip-only enable, it would enforce the problematic behavior, forcing the WLC to respond only to the NAT IP.

C. config flexconnect office-extend nat-ip-only enable: This command does not exist. Even if it did, enabling a nat-ip-only feature would restrict, not expand, the WLC's responsiveness, failing to solve the issue for internal APs.

1. Cisco Wireless LAN Controller Configuration Guide

Release 8.5

"Configuring the Controller for Network Address Translation" section: "If you have both internal and external access points

and you want them to be able to join the controller

you must disable the NAT-only setting by entering this command: config network ap-discovery nat-ip-only disable."

2. Cisco OfficeExtend Access Point Deployment Guide

"WLC Behind a NAT Device" section: "When the WLC is configured with a NAT IP address

the WLC sends its NAT IP address in the discovery response to the OEAP. ... If you have APs on the LAN side of the WLC

you must disable the 'AP discovery on NAT IP only' feature using the config network ap-discovery nat-ip-only disable CLI command."

3. Cisco AireOS Command Reference

"config network" commands: This reference documents the config network ap-discovery nat-ip-only {enable | disable} command

explaining its function is to control whether the controller responds to discovery requests on its management interface when a NAT IP is also configured. The disable option is specified for environments with both internal and external APs.

The exhibit from Cisco Prime Infrastructure displays information about non-802.11 interferers. The "Interferer Types" and "Top N Interferers" sections clearly show three distinct devices: a Bluetooth Link, a Bluetooth Discovery device, and a Video Camera. The "Interferer Severity" pie chart shows zero devices in the "Severe," "Significant," or "Moderate" categories. The detailed list confirms this, assigning each interferer a minimal severity of 1 and a low duty cycle of 1%. This evidence directly supports the conclusion that there are "several light interferers." While their impact is likely minimal, they are present and have been detected by CleanAir as potential sources of interference.

A: This is incorrect. The severity chart and the detailed list explicitly show that there are no strong (severe or significant) interferers; all have a minimal severity of 1.

C: This is incorrect. The provided output is a report on interferers and contains no information about AP locations, signal coverage, or physical "clusters," making any conclusion about AP placement impossible.

D: This is incorrect. The presence of only three minor interferers with a 1% duty cycle suggests a relatively clean RF environment, not one that is incapable of providing adequate performance.

1. Cisco

"Cisco CleanAir Technology White Paper": This document explains the core concepts of CleanAir. It defines the Severity Index (SI) as a value from 0 to 100

calculated from duty cycle and RSSI

which represents the potential impact of an interferer. A severity of 1

as shown in the exhibit

is the lowest possible non-zero value

classifying the interferers as minor or light. (See section "Interference Classification and Severity Index").

2. Cisco

"Radio Resource Management under Unified Wireless Networks

Cisco IOS XE Cupertino 17.9": This guide details how CleanAir functions within a Cisco wireless network. It states

"CleanAir is a spectrum analysis tool that can detect

classify

locate

and mitigate interference." The exhibit is a direct output of this detection and classification function

showing several light interferers have been identified. (See "CleanAir" section).

3. Cisco

"Cisco Prime Infrastructure 3.10 User Guide": The user guide for Prime Infrastructure explains how to interpret the dashboards. The "Interferers" dashboard

similar to the one in the exhibit

is used to "view a list of interferers that are active in your network." The data presented (type

severity

duty cycle) is for identifying these sources. The low values indicate the interferers are light. (See Chapter: "Monitoring Wireless Devices

" section "Monitoring Interferers").

The Cisco DNA Center AP health score for interference is calculated based on two key factors. First, the score only considers non-802.11 interference data that is specifically detected and classified by the Cisco CleanAir feature. Interference from other sources, such as co-channel Wi-Fi traffic, does not impact this particular KPI. Second, the health score is only degraded if the detected CleanAir interference exceeds a specific threshold. For the 5 GHz radio band, the health score remains at its maximum (a score of 10) as long as the interference level is 30% or less. Therefore, the score can be unaffected because the interference is not a CleanAir type or because it is below the reporting threshold.

A. The interference is less than or equal to 30% on the 2.4 GHz radio.

This is incorrect. The health score threshold for the 2.4 GHz band is 50%, not 30%.

B. The interference is less than or equal to 50% on the 2.4 GHz radio.

While this is a factually correct threshold, modern enterprise deployments prioritize the 5 GHz band, making its health parameters (Option D) a more likely and relevant answer in an unspecified scenario.

E. Cisco DNA Center does not include interference in the AP health score.

This is incorrect. Interference, as measured by Cisco CleanAir, is a fundamental Key Performance Indicator (KPI) used to calculate the overall AP health score in Cisco DNA Center.

1. Cisco DNA Center User Guide

2.3.5

"Health Dashboards" section.

In the subsection "About the Health Score

" the guide details the KPIs for Access Point health. It explicitly states for the Interference KPI: "Percentage of time the channel is occupied by non-802.11 interference

as detected by Cisco CleanAir. A score of 10 is assigned if interference is less than or equal to 30% on the 5-GHz radio

and less than or equal to 50% on the 2.4-GHz radio." This single statement directly validates that the calculation is exclusive to CleanAir (Option C) and that the 5 GHz threshold is 30% (Option D). It also confirms the thresholds for the other options.

2. Cisco DNA Center Assurance User Guide

"Monitor the Health of Your Network" chapter.

This guide reinforces the concept of health scores being composed of multiple KPIs. The section on AP health details that interference is a critical component

but its measurement is tied to specific technologies (CleanAir) and predefined thresholds

explaining why detected interference might not always impact the score.

A CPU Access Control List (ACL) on a Cisco Wireless LAN Controller (WLC) filters traffic destined for the controller's own CPU. This includes management traffic (HTTP/S, SSH) and client-related control plane traffic, such as Web Authentication redirects. The stated policy restricts access to the IT subnet only. When a guest client connects, the WLC intercepts its initial web request to redirect it to the authentication portal. This intercepted traffic originates from the guest subnet and is destined for the WLC's CPU. The overly restrictive CPU ACL, which only permits traffic from the IT subnet, will block the guest's request, causing the connection to time out.

B: Web Authentication is fully supported with CPU ACLs; the feature is designed to selectively permit such traffic while blocking other unwanted traffic.

C: An incorrect DNS server on the controller would affect its ability to resolve external hostnames, not the initial IP-based redirection to its internal web portal.

D: Web Authentication uses standard HTTP/HTTPS redirects and is browser-agnostic; it is not limited to a specific browser like Internet Explorer.

1. Cisco Wireless LAN Controller Configuration Guide

Release 8.5

"Configuring CPU ACLs" section: "The controller has a CPU ACL. This ACL is configurable and is used to protect the controller CPU from DoS attacks and other malicious traffic... When you create a CPU ACL

you must permit the traffic from your wireless clients that require access to the controller CPU. For example

if you are using web authentication

you must permit HTTP and HTTPS." This confirms that a misconfigured ACL will block web authentication.

2. Cisco

"Cisco Wireless LAN Controller (WLC) CPU ACLs" White Paper: "The CPU ACLs are applied to traffic that is destined to the CPU of the WLC. This includes management traffic (Telnet

SSH

HTTP

HTTPS

and SNMP) and traffic from wireless clients that is terminated on the WLC

such as web authentication." This document explicitly states that web authentication traffic is processed by the CPU ACL.

3. Enterprise Mobility 8.5 Design Guide

"WLC Platform Features > CPU ACL" section: "The purpose of the CPU ACL is to protect the WLC CPU from being overloaded by traffic that is not essential to the operation of the WLC... If you configure a CPU ACL

you must be sure to permit all of the traffic that you want the WLC to process. For example

if you are using external web authentication

you must be sure to permit traffic from the web server to the WLC." This highlights the necessity of correctly permitting required traffic.

To prioritize specific application traffic using Cisco Application Visibility and Control (AVC) on a Wireless LAN Controller (WLC), the engineer configures a rule to 'mark' the traffic. This action assigns a Differentiated Services Code Point (DSCP) value, which maps to a pre-defined Quality of Service (QoS) profile (e.g., Platinum, Gold). Network devices use this marking to apply preferential queuing and forwarding, ensuring higher priority for the designated traffic, such as video streams from IP cameras. The other actions available are 'drop' or 'rate-limit', which are used to block or de-prioritize traffic, respectively.

A. permit-ACL: An ACL is a filter to permit or deny traffic based on network addresses and ports, not the primary mechanism for QoS prioritization within an AVC rule.

B. WMM required: Wi-Fi Multimedia (WMM) is a foundational QoS mechanism for the entire WLAN, not a specific action configured within an individual AVC rule to prioritize one application.

D. rate-limit: Rate-limiting restricts the bandwidth for an application. This is an action to de-prioritize or control traffic, which is the opposite of the required prioritization.

1. Cisco Wireless Controller Configuration Guide

Release 8.10: In the chapter "Configuring Quality of Service

" the section "Configuring AVC Profiles (GUI)" outlines the configuration steps. Step 6 explicitly lists the available rule actions: "From the Action drop-down list

choose one of the following actions to be applied to the application traffic: Drop

Mark

Rate-Limit (Ingress)

Rate-Limit (Egress)." The 'Mark' action is used for QoS prioritization.

2. Enterprise Mobility 8.5 Design Guide: In the "Wireless QoS Design" chapter

the "Application Visibility and Control" section states

"The AVC profile contains the different applications and the action to be taken on them. The action can be to drop

mark

or rate-limit the application." It clarifies that marking is the method to assign QoS levels for prioritization. (Cisco Validated Design

Document ID: CVD-1113

Page 138).

3. Application Visibility and Control Deployment Guide: The "Configuring Application Visibility" section details the three possible actions for classified traffic within an AVC profile: drop

mark

and rate-limit. The guide explains that the 'mark' action is used to apply a specific QoS policy to the application's traffic flow. (Document ID: OL-27226-01

"AVC Profile Configuration" section).

A CPU Access Control List (ACL) on a Cisco Wireless LAN Controller (WLC) is designed to protect the controller's central processing unit by filtering traffic destined for the controller itself. This includes management traffic (such as SSH, HTTPS, Telnet, SNMP) and control plane traffic. Such traffic can originate from devices on the wired network (e.g., a network administrator's workstation, a RADIUS server, or Access Points) as well as from wireless clients (e.g., for authentication or management purposes). Therefore, enabling a CPU ACL affects both wired and wireless traffic that is addressed to the WLC's IP addresses.

A. wireless traffic only: This is incorrect because CPU ACLs also filter traffic from wired sources, such as management stations or network infrastructure devices communicating with the controller.

B. wired traffic only: This is incorrect because CPU ACLs also filter traffic originating from wireless clients, particularly traffic that needs to be processed directly by the controller.

C. VPN traffic: This is too specific and incomplete. While some VPN traffic terminating on the WLC would be subject to the CPU ACL, the ACL's scope is much broader.

1. Cisco Wireless LAN Controller Configuration Guide

Release 8.5: In the "Configuring ACLs" chapter

the section "CPU ACLs" states

"CPU ACLs are configured to prevent or allow certain traffic from either the wired or wireless clients from reaching the controller CPU." This explicitly confirms the ACL applies to both traffic types.

2. Cisco AireOS 8.10 - CPU ACLs Configuration Example: The introduction of this document states

"CPU ACLs are an ACL that is applied to traffic that is destined for the controller's CPU. This can be traffic from wireless clients or from the wired side." This directly supports that both wired and wireless traffic are affected.

3. Cisco Catalyst 9800 Series Wireless Controller Configuration Guide

IOS-XE Amsterdam 17.3.x: While the question's menu path points to AireOS

the principle is identical on modern controllers. In the "System Management Guide > Configuring CPU ACLs" section

it describes applying ACLs to the control plane

which processes traffic from both wired and wireless sources destined for the controller.

In a typical enterprise BYOD (Bring Your Own Device) or guest wireless implementation using Cisco Identity Services Engine (ISE), policies are configured to control network access. While the self-registration portal allows a user to register multiple personal devices, a common security and resource management policy is to limit the number of concurrent active sessions. This means that although an employee might have four devices registered in the "My Devices Portal," the authorization policy can be set to permit only one active network connection at a time. When the user connects a second device, ISE can issue a Change of Authorization (CoA) to terminate the session of the first device, thus enforcing the "one-at-a-time" access rule.

A. The last device is removed and the newly added device is updated as active device.

This describes a device replacement policy for registration, not a policy for managing concurrent active network connections. Standard ISE behavior is to deny, not replace, registrations beyond the configured limit.

C. All devices are allowed on the network simultaneously.

This is only true if no limiting policies are configured. In a properly designed enterprise network, limits on guest/BYOD devices are standard practice for security and resource management.

D. Purge time dictates how long a device is registered to the portal.

The endpoint purge policy concerns the removal of inactive device records from the ISE database after a set period; it does not control the number of active simultaneous connections.

1. Cisco Identity Services Engine Administrator Guide

Release 3.1

"Session Management" Chapter: This chapter details how ISE tracks network sessions. It explains that authorization policies can be configured to act based on active session counts for a user. The mechanism to enforce a single session is to configure an authorization profile to send a Re-authentication or Port Bounce/Shutdown CoA request to the network access device (NAD) hosting the older session when a new session is detected for the same user. This directly results in the outcome described in option B.

2. Cisco Identity Services Engine Administrator Guide

Release 3.1

"Configure My Devices Portal Settings" Section: This section describes the "Maximum devices per user" setting. The documentation states

"When this limit is reached

the user cannot register any more devices." This confirms that the default behavior for exceeding a registration limit is denial

not replacement (as in option A) or allowing only one active session. This highlights the distinction between registration limits and session limits.

3. Cisco Identity Services Engine Administrator Guide

Release 3.1

"Endpoint Purge Policy" Section: This section defines the purge policy as a mechanism to "delete endpoints that are inactive for a specified number of days from the ISE database." This confirms that purging is related to the lifecycle of inactive endpoints

not the control of concurrent active sessions (as in option D).

When an external LDAP directory is unavailable, the most direct alternative that provides the same security and user experience for Local Web Authentication (LWA) is to use the internal user database of the RADIUS server, which is Cisco ISE in this scenario. This solution meets the requirement for user-based authentication, providing security comparable to LDAP (individual credentials). The user experience is identical, as the LWA captive portal presents the same username and password fields regardless of whether the back-end identity store is an external LDAP server or the ISE internal database. This is a self-contained, straightforward solution for a startup without existing directory infrastructure.

A. Use SAML: This involves redirecting the user to an external Identity Provider for authentication. While a valid authentication method, this redirection creates a different user experience than the direct login portal of LWA with LDAP.

C. Use a preshared key on the corporate WLAN: A PSK provides device-level authentication, not user-level authentication. All users share the same key, which does not meet the security requirement of authenticating individual users against a directory.

D. Use Novell eDirectory: Novell eDirectory is a directory service that is accessed using the LDAP protocol. Proposing this solution contradicts the fundamental constraint of the question that "LDAP is unavailable."

1. Cisco Identity Services Engine Administrator Guide

Release 3.1

"Identity Sources" Chapter: This guide lists the "Cisco ISE Internal User Database" as a primary type of identity source. It states

"You can create users and user groups in the internal database and use them for authentication and authorization." This confirms the viability of using the internal database as a directory for authentication.

2. Cisco Identity Services Engine Administrator Guide

Release 3.1

"Configure Guest Access" Chapter: This chapter details the configuration of web portals for guest services

including LWA. The user flow described involves a redirection to a login page where credentials are entered. This user-facing experience remains consistent whether the backend is the internal database or an external one like LDAP.

3. Cisco Identity Services Engine Administrator Guide

Release 3.1

"SAML SSO" Chapter: The guide describes the SAML flow: "When a user tries to access a protected service provider resource

the service provider redirects the user to the Cisco ISE portal for authentication. Cisco ISE

in turn

redirects the user to the configured external IdP." This confirms the different user experience involving redirection.

4. Micro Focus eDirectory 9.2.7 Administration Guide

"eDirectory and LDAP" Section: The official documentation for Novell eDirectory (now Micro Focus eDirectory) explicitly states

"eDirectory is a full-service

secure directory service that provides your network with centralized identity management... eDirectory supports LDAP." This confirms that eDirectory relies on the LDAP protocol

making it an invalid choice given the question's constraints.

To assess different client types directly on a Cisco Catalyst 9800 Series Wireless Controller without external servers, the administrator must use the device classification feature. This native capability allows the controller to identify connecting devices by examining specific protocol attributes, primarily from DHCP and HTTP traffic (such as DHCP options and HTTP User-Agent strings). The controller then matches this information against its built-in device profiles to classify the client type (e.g., Apple iPhone, Windows 10). This process is performed locally on the controller, fulfilling the stated requirement.

A. native profile: This is a generic term. "Device classification" is the specific and official name for the feature that performs this function on the Catalyst 9800.

B. MAC classification: This is only one technique (using the OUI) within the broader device classification feature and is not sufficient on its own for comprehensive client-type assessment.

C. local profile: This term is not used to describe the client-type identification feature on the Catalyst 9800. The feature is called "device classification," even though it runs locally.

1. Cisco Systems

"Security Configuration Guide

Cisco IOS XE Bengaluru 17.6.x (Catalyst 9800 Series Wireless Controllers)".

Reference: Chapter: "Device Profiling and Classification"

Section: "Information About Device Profiling and Classification".

Content: "Device profiling and classification enables the Cisco Catalyst 9800 Series Wireless Controller to identify the type of device that is connecting to the network... The controller uses protocols such as HTTP

DHCP

and so on

to identify the end devices. The controller has a default built-in device profile for most of the common device types." This confirms the feature is native and its name is "Device Classification".

2. Cisco Systems

"Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide

Cisco IOS XE Cupertino 17.9.x".

Reference: Chapter: "Device Profiling and Classification"

Section: "Device Profiling and Classification".

Content: "The device profiling and classification feature on the controller allows you to identify the end devices by using protocols

such as HTTP

DHCP

and so on... The controller uses the DHCP and HTTP protocols to classify a device." This reinforces that the feature is built-in and details the primary protocols used for local classification.

The "override global credentials" feature is specifically designed for this scenario. On a Cisco Wireless LAN Controller (WLC), an administrator can define global credentials that all associated Access Points (APs) use for administrative access by default. To meet the requirement of having unique credentials for specific APs, such as those in a secure area like a CEO's office, the administrator can navigate to the individual AP's configuration on the WLC and enable the "override global credentials" option. This allows setting a unique username and password for that specific AP, which takes precedence over the global settings.

A. local management users: These are user accounts created on the WLC for administrative access to the WLC itself, not for individual APs.

B. HTTPS access: This is a protocol to secure web-based management traffic to the WLC and does not relate to setting AP-specific credentials.

C. 802.1X supplicant credentials: These are used by the AP to authenticate itself to the wired network infrastructure (e.g., a switch), not for administrative login to the AP.

1. Cisco Catalyst 9800 Series Wireless Controller Software Configuration Guide

Cisco IOS XE Bengaluru 17.6.x: In the "Configuring Access Points" chapter

the section "Configuring AP Credentials" states

"By default

all the APs connected to the controller are configured with the global username and password. You can override the global credentials and configure a unique username and password for a specific AP." This directly describes the feature required by the question.

2. Cisco Wireless LAN Controller Configuration Guide

Release 8.5: In the chapter "Configuring Access Points

" the section "Configuring an Access Point (GUI)" details the process. On the configuration page for a specific AP

the Credentials tab contains the "Override Global Credentials" checkbox

which

when selected

allows the entry of AP-specific credentials.

The report names within Cisco Prime Infrastructure are descriptive and directly correspond to the data they present. Each report is designed to provide a specific summary related to wireless security events and device states.

• The Rogue AP Count Summary provides a straightforward count of all unauthorized access points detected.
• The Adhoc Rogue Count Summary specifically filters for ad-hoc type rogue devices.
• The Adaptive wIPS Alarm Summary focuses on alarms generated by the Wireless Intrusion Prevention System (wIPS).
• The Security Alarm Trending Summary is used for historical analysis, showing how the frequency and type of security alarms have changed over a specified period.

Cisco Systems, Inc. (2022). Cisco Prime Infrastructure 3.10 User Guide.

Reference: Chapter 35: "Running Reports," Section: "Security Reports," Table 35-23 "Security Reports".

Details: This table explicitly lists each report name and provides a description that matches the correct answer. For example, it defines "Rogue AP Count Summary" as a report that "Displays a summarized count of all rogue access points on your network." and "Security Alarm Trending Summary" as a report that "Displays a summary of security alarm trends over a period of time." This documentation directly validates each match.

The goal is to create a rule that automatically classifies known, non-threatening Access Points (APs) from neighboring businesses.

• Condition: The rule must identify APs whose SSIDs begin with "ATC". The option set substring-ssid to ATC correctly creates a condition that matches any SSID containing "ATC", which includes all the target APs (e.g., ATC302, ATC011). Using "set SSID value to ATC" would only match an SSID that is exactly "ATC".
• Type: The APs belong to coffee shops and are not part of a malicious attack. Therefore, their Type should be set to friendly. This classification acknowledges their presence while flagging them as non-hostile.
• State: The APs are not part of the shopping center's managed network infrastructure. Their correct administrative State is external.

Cisco Systems, Inc. (2024). Cisco Catalyst 9800 Series Wireless Controller Configuration Guide, Cisco IOS XE Cupertino 17.14.x - Rogue Management. In the context of rogue management, Cisco Wireless Controllers allow for the creation of rules to automatically classify rogue APs. A rule condition can be based on the SSID. The classification state for a rogue can be set to 'Friendly', and its status can be defined as 'External' if it is not on the local wired network.

Reference: Section "Configure Rogue Rules". This documentation details creating rules based on conditions like SSID match to set a rogue's classification to "Friendly" and state to "External".

Hucaby, D. (2014). CCNP Wireless IUWVN 642-732 Official Cert Guide. Cisco Press.

Reference: Chapter 14, "Implement Cisco Unified Wireless Security," section "Rogue APs." The text explains that rogue APs can be classified as friendly if they are known and determined not to be a threat. Rules can be configured on a Wireless LAN Controller (WLC) to match specific criteria, such as SSIDs of neighboring wireless networks, and automatically assign them a "Friendly" classification. It also distinguishes between internal rogues (connected to the enterprise network) and external rogues (not connected).

Gass, S., & Pellen, R. M. (2007). Implementing a Wireless Intrusion Prevention System. IEEE Security & Privacy, 5(3), 74-77.

Reference: Page 75, section "Rogue-AP Detection and Mitigation." The paper discusses that a key function of a Wireless Intrusion Prevention System (WIPS) is to classify detected APs. It states, "A WIPS should let administrators classify APs as authorized, rogue, or external (neighboring)." The rules for this classification can be based on various parameters, including the SSID. This aligns with setting the State to external and Type to friendly (a synonym for an acknowledged neighbor).

DOI: 10.1109/MSP.2007.64

The WLAN configuration exhibit shows the Quality of Service (QoS) profile set to Platinum (voice) and, most critically, the WMM Policy set to Required. The Required setting mandates that any client device attempting to associate with this WLAN must support and use Wi-Fi Multimedia (WMM). WMM is the Wi-Fi Alliance's interoperability certification for a subset of the features defined in the IEEE 802.11e standard, which provides QoS enhancements to the 802.11 MAC layer. Therefore, for a VoWLAN phone to connect to this network and have its voice traffic prioritized correctly, it must support both the 802.11e standard and its WMM implementation.

A. TSPEC: This admission control mechanism is not required by this configuration, as indicated by the 7920 AP-CAC setting being disabled.

B. SIFS: Short Interframe Space is a fundamental timing interval in the 802.11 protocol used by all devices; it is not a special feature for QoS.

E. APSD: Automatic Power Save Delivery is a power-saving feature within WMM. While beneficial for VoWLAN phones, it is not the core requirement for establishing a QoS-prioritized connection.

1. Cisco Wireless LAN Controller Configuration Guide

Release 8.5

"Configuring QoS" Chapter

"Configuring QoS per WLAN (GUI)" section. This document states

"From the WMM Policy drop-down list

choose... Required—Clients must support WMM. Clients that do not support WMM are not allowed to associate with the WLAN." This confirms the mandatory nature of WMM support.

2. Cisco Enterprise Mobility 8.5 Design Guide

"Voice over WLAN Design and Deployment Recommendations" Chapter

"QoS for VoWLAN" section. This guide clarifies the relationship between the standards: "WMM is a certification by the Wi-Fi Alliance of a subset of the IEEE 802.11e amendment... Cisco recommends that you configure the voice WLAN for Wi-Fi Multimedia (WMM) and configure the QoS profile to Platinum." This directly links the Platinum profile

WMM

and the underlying 802.11e standard as essential for VoWLAN.

3. IEEE Std 800-4302.11™-2020

"IEEE Standard for Information Technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications

" Clause 9.4.2.57 "WMM/WME Parameter Element". This section of the official standard defines the WMM Information Element that WMM-capable stations (clients) use to advertise their QoS capabilities

which is a requirement for associating with a WMM-enabled AP.

A single SSID model for a Bring Your Own Device (BYOD) deployment requires a centralized policy and access control engine to differentiate between various users and device types connecting to the same network name. The Cisco Identity Services Engine (ISE) is the required technology for this function. ISE acts as a RADIUS server and policy decision point, using context such as user identity, device type, and security posture to dynamically assign specific network access policies, such as VLANs or Access Control Lists (ACLs). This allows administrators to securely segment corporate, guest, and personal devices while maintaining a simplified user experience with a single SSID.

A. mobility service engine: The MSE is primarily used for location-based services (CMX) and wireless intrusion prevention (wIPS), not for core identity and policy enforcement for BYOD.

B. wireless control system: WCS is an obsolete network management platform that has been replaced by Cisco Prime Infrastructure and lacks the advanced policy capabilities of ISE.

D. Prime Infrastructure: This is a network management tool for configuration, monitoring, and troubleshooting. It does not perform the dynamic, context-aware policy enforcement, which is the role of ISE.

1. Cisco

"BYOD Design Guide (CVD)": In the chapter on BYOD Architecture

the guide states

"Cisco Identity Services Engine (ISE)—A context-aware security policy platform that enables an enterprise to enforce security policy for all users and devices that are seeking access to the network." It further explains that for a single-SSID design

ISE is used to differentiate devices and apply the appropriate policy. (Reference: BYOD Design Guide

Chapter 2

"BYOD Architecture

" section "Solution Components").

2. Cisco

"Identity Services Engine (ISE) Administrator Guide": The documentation details how ISE is the central component for creating and enforcing security and access policies for endpoints connecting to the organization's network. This is the fundamental requirement for a single-SSID BYOD model. (Reference: Cisco Identity Services Engine Administrator Guide

Release 3.0

Chapter: "Cisco ISE Overview

" section "Cisco ISE Functions").

3. Cisco

"Enterprise Mobility 4.1 Design Guide": This guide explicitly recommends the single-SSID design for BYOD and identifies ISE as the key component. It states

"The single SSID design is the recommended design for BYOD... The Cisco ISE is able to differentiate between a corporate-owned device and a personal device and apply the appropriate policy." (Reference: Enterprise Mobility 4.1 Design Guide

Chapter: "Solution Components

" section "Cisco Identity Services Engine").

The scenario describes a classic FlexConnect configuration issue. When an AP is in FlexConnect mode and a WLAN is configured for local switching, the AP must know which VLAN to place client traffic on at the remote site. This is accomplished by creating a FlexConnect group on the WLC, adding the APs to this group, and then defining a specific WLAN-to-VLAN mapping within the group's configuration. The failure of WLAN B in FlexConnect mode indicates it is configured for local switching but lacks this required VLAN mapping. Creating a FlexConnect group with the proper mapping will provide this information to the APs, allowing WLAN B to function correctly.

B. Disable local switching on the WLANs: This is a design change, not a configuration fix. It would force all traffic centrally, which may not meet the network requirements and doesn't correct the underlying local switching misconfiguration.

C. Map the AP group to the WLAN interface: This describes a non-existent configuration step. AP groups determine which WLANs are broadcast by APs, while WLANs are mapped to interfaces on the WLC for central switching.

D. Join the APs to a Cisco FlexConnect group: This action is incomplete. Simply joining a group is insufficient if the group has not been configured with the necessary WLAN-VLAN mappings, which is the crucial step described in option A.

1. Cisco Wireless Controller Configuration Guide

Release 8.5

"FlexConnect" Chapter

"Configuring FlexConnect Groups" section: "You can use FlexConnect groups to push the VLAN-specific configurations on the FlexConnect APs... You can create a FlexConnect group and assign a specific AP to the FlexConnect group. The APs in the group will inherit the VLAN and ACL configurations of the FlexConnect group." This document explicitly states that FlexConnect groups are used to configure VLANs for APs.

2. FlexConnect Configuration Guide

Cisco IOS XE Gibraltar 16.12.x

"Configuring FlexConnect Groups" section: "You can use FlexConnect groups to do the following: ... Efficiently configure WLAN-VLAN mapping for a group of FlexConnect APs." This confirms that the primary method for assigning VLANs to WLANs in a FlexConnect deployment is through FlexConnect groups.

3. Cisco Catalyst 9800 Series Wireless Controller Configuration Guide

IOS XE Dublin 17.12.x

"Configure FlexConnect" Chapter

"WLAN-VLAN Mapping" section: "For locally switched WLANs

traffic from the clients is switched to a local VLAN at the AP's location... To configure VLANs on FlexConnect APs

you must configure FlexConnect Groups." This directly links the requirement for VLANs in local switching to the configuration of FlexConnect Groups.