Cisco 200-301: Cisco Certified Network Associate (CCNA)

Incorrect. “Protected frame” is not one of the three 802.11 frame types. Protection refers to security mechanisms (e.g., encryption for data frames with WPA2/WPA3, and 802.11w PMF for certain management frames). An Association Response may be protected when PMF is enabled, but its type remains a management frame.

Incorrect. Action frames are a category within management frames used to carry specific management actions (e.g., spectrum management, QoS, block ack negotiation, radio measurement). While Action frames are management-related, “Association Response” is its own management subtype and is not classified as an Action frame.

Incorrect. Control frames support reliable delivery and medium access coordination, such as ACK, RTS, CTS, PS-Poll, and Block Ack. They do not establish association. Since Association Response is part of the join process and BSS membership establishment, it is not a control frame.

Adding both a spine and a leaf can increase capacity, but it is not the fundamental scaling method when you specifically need more access ports. Spine-and-leaf scales access by adding leaf switches; spines are added when you need more fabric bandwidth/paths. Also, “redundant connections between them” is vague and doesn’t capture the required full-mesh leaf-to-all-spines connectivity rule.

Adding a spine switch can improve overall fabric capacity and increase the number of ECMP paths, but it does not directly add access ports. The “at least 40 GB uplinks” detail is not a defining requirement of spine-and-leaf scalability; link speed is an implementation choice. Scalability is about adding nodes (leaf/spine) with consistent interconnections, not a specific uplink rate.

A single connection to a “core spine switch” contradicts the spine-and-leaf design principle. Spine-and-leaf avoids a single core dependency by having each leaf connect to all spines, providing multiple equal-cost paths and eliminating bottlenecks. Connecting a leaf to only one spine reduces redundancy, limits ECMP, and can create oversubscription and single points of failure.

"ipv6 address dhcp" tells the interface to obtain its IPv6 address via DHCPv6. The address is assigned by a DHCPv6 server, not generated locally from the interface MAC and a specified prefix. This is useful in managed environments requiring centralized address assignment, but it does not meet the requirement of deriving the address from a configured prefix plus MAC.

"ipv6 address autoconfig" enables SLAAC on the interface. The device learns the prefix from Router Advertisements (RA) and then forms an address (often using EUI-64 or privacy extensions). However, it does not use a specified prefix in the command itself; the prefix comes from the network’s RA, so it doesn’t match the question’s requirement.

"ipv6 address 2001:DB8:5:112::2/64 link-local" is incorrect because link-local addresses must use the FE80::/10 prefix, not a global unicast prefix like 2001:DB8:.... Also, this command is manually setting a specific address (::2) rather than generating an interface ID from the MAC. It neither uses EUI-64 nor correct link-local formatting.

2000::/3 is the IPv6 global unicast address range (publicly routable IPv6 space). It is not a multicast group (multicast is FF00::/8), and interfaces do not “join” unicast ranges. This option is a common distractor because it is a well-known IPv6 prefix, but it describes address allocation, not multicast membership behavior.

2002::/16 is historically associated with 6to4 transition addressing (not a multicast group). The specific value “2002::5” is not a standard IPv6 multicast group that an interface joins. Since it does not start with FF, it is not multicast. This option tries to mislead by presenting something that looks like a special IPv6 address.

FC00::/7 is the Unique Local Address (ULA) range, similar in concept to RFC1918 private IPv4 addressing. It is unicast, not multicast, and therefore not something an interface “joins.” ULAs can be configured on interfaces, but they do not represent multicast group memberships used for discovery/control-plane functions.

Incorrect. A switch does not add the destination MAC address to the MAC address table just because it appears as a destination in a received frame. MAC learning is based on the source MAC address (and VLAN/ingress port). If the destination is unknown, the switch cannot forward it to a single port; it floods it within the VLAN instead.

Incorrect. In normal operation, unknown unicast frames are handled in hardware (ASIC) and flooded within the VLAN; they are not typically sent to the CPU for “destination MAC learning.” The switch learns MAC addresses from the source field of frames it receives, not by punting frames to the CPU to discover destinations.

Incorrect. Dropping unknown unicast frames is not the default behavior of a Layer 2 switch. If switches dropped unknown destinations, initial communication would fail whenever MAC entries are missing (e.g., after aging or reboot). Flooding is the default mechanism to deliver the frame and enable subsequent MAC learning via the destination’s reply.

This option uses 255.255.255.248, which is a /29 mask rather than a /30. A /29 creates blocks of 8 addresses and provides 6 usable host addresses, so it does not match the requirement for a /30 subnet between two routers. Even though 192.168.1.1 can be a valid host address in some /29 subnet, the subnet mask itself makes this option incorrect. The exam objective here is primarily to recognize the proper /30 mask.

This option also uses 255.255.255.248, which corresponds to /29 and not /30. In addition, with that mask, 172.16.1.4 is the network address of the 172.16.1.0/29 or 172.16.1.0-7 block depending on boundary interpretation from the given host, so it is not a usable host address. That means this choice fails both the mask requirement and the usable-address requirement. It is therefore clearly incorrect.

This option shows 225.255.255.252 as the subnet mask, which is not a valid IPv4 subnet mask. Valid subnet masks must have contiguous 1 bits from left to right, and valid octet values are limited to values such as 0, 128, 192, 224, 240, 248, 252, 254, and 255. Because 225 is not one of those valid contiguous-mask values, the mask is invalid regardless of the IP address. Therefore this option cannot represent a valid /30 subnet.

172.9.0.0/16 is NOT a private RFC 1918 network. The private 172 range is 172.16.0.0/12, which covers only 172.16.0.0 through 172.31.255.255. Since 172.9.x.x is outside that boundary, it is publicly routable in principle (assuming it is allocated/used publicly) and is not intended for internal-only addressing without Internet routing.

192.0.0.0/8 is not an RFC 1918 private range. The private range in the 192 space is specifically 192.168.0.0/16. The 192.0.0.0/8 block includes various special-use and publicly routable ranges (for example, 192.0.2.0/24 is TEST-NET-1 for documentation), but it is not the standard private addressing block used for internal networks.

209.165.201.0/24 is a public IPv4 network (not RFC 1918). In many Cisco CCNA labs and examples, 209.165.200.0/24 or similar ranges are used to represent an ISP/public Internet segment. Devices can certainly communicate within this subnet, but it is not an internal-only private range; it is intended to be globally routable rather than isolated from the Internet.

2000::/3 is the IPv6 Global Unicast range (publicly routable on the Internet, similar to public IPv4). It is used for one-to-one communication to a single interface address. While global unicast can be assigned to many hosts, each packet is still destined to one specific unicast address, not a multicast group.

FC00::/7 is Unique Local Addressing (ULA), often compared to RFC1918 private IPv4 space. It is still unicast (one-to-one) and intended for internal networks, VPNs, and environments that want stable internal addressing without Internet routability. It does not represent group addressing; multicast is a different prefix.

FE80::/10 is IPv6 link-local unicast. Every IPv6-enabled interface typically has a link-local address and uses it for neighbor discovery, router discovery, and some routing protocol adjacencies on the local segment. Despite being “local,” it is not a group address block; it is unicast and not routed beyond the local link.

CSMA/CD is the mechanism used on half-duplex Ethernet to detect and handle collisions, but it does not by itself cause late collisions. Late collisions indicate that collisions are happening outside the normal collision window, which typically points to a problem (duplex mismatch or excessive propagation delay). So CSMA/CD is related, but it’s not the root cause being tested.

Ethernet does not wait 15 seconds before retransmitting. After a collision, Ethernet uses a binary exponential backoff algorithm based on slot times (512 bit-times in classic Ethernet). The wait is a randomized short delay, increasing with repeated collisions, not a fixed multi-second timer. This option describes behavior that does not match Ethernet MAC operation.

A late collision is not defined as “after the 32nd byte.” Ethernet collision timing is based on slot time (512 bits = 64 bytes) and the collision window concept, not a 32-byte threshold. While late collisions do occur after the normal collision window, the specific byte count here is incorrect and is a common trap answer.

Incorrect. While a controller-based design introduces concepts like CAPWAP, AP join processes, and controller profiles, the goal is to simplify operations at scale. Centralized management typically reduces complexity overall because changes are made once on the WLC rather than repeatedly on each AP, and policies remain consistent.

Incorrect. Multiple SSIDs can use the same authentication method (for example, several SSIDs can all use WPA2/WPA3-Enterprise with 802.1X, or multiple SSIDs can use PSK). SSIDs are separate logical WLANs, but they are not restricted to unique authentication methods per SSID.

Incorrect. WLCs manage lightweight APs (controller-based). Autonomous APs are independently managed and do not require or typically integrate with a WLC for centralized control. Some AP models can be converted between modes, but the WLC benefit is specifically tied to lightweight AP operation.

Incorrect. While PoE events (device detection, power granted/denied, overload) can generate syslog messages, generating a syslog message is not the key behavior of “power classification override.” The override feature is about enforcing an administratively set power allocation/limit, not about logging when a device begins drawing power.

Incorrect. PoE power monitoring and policing do not require pausing Ethernet data forwarding. Power negotiation occurs at the physical layer and through discovery/classification mechanisms, but normal data traffic is not temporarily halted simply because the switch checks power usage. A port may be shut down only if a fault/violation occurs, not paused for measurement.

Incorrect. PoE does not assume a device has failed just because it draws less than a configured minimum; many devices have variable power draw depending on load. PoE protection focuses on overload, short-circuit, or exceeding the allowed/allocated power. Underutilization is normal and does not trigger a disconnect behavior in standard PoE override/policing logic.

Incorrect. PortFast does not place the port into the listening state first; in fact, it is specifically designed to bypass the listening and learning states. The port transitions directly to forwarding when the interface comes up. Choosing listening would describe the normal STP progression rather than the PortFast behavior. This option contradicts the main purpose of the feature.

Incorrect. Although PortFast does cause a port to enter forwarding immediately when the port comes up, this option is misleading because it ties the behavior specifically to a switch reload. PortFast is not primarily about reload events; it applies whenever the interface transitions up, such as when a host is connected or a link is restored. The question asks for the primary effect, and the broader, more accurate effect is reduced STP delay on the port. Therefore this option is too narrowly worded to be the best answer.

Incorrect. PortFast does not enable BPDU messages; STP BPDUs are already part of normal switch operation. A PortFast-enabled port can still send and receive BPDUs, and receiving one may indicate that the port is no longer an edge port. For protection, PortFast is often combined with BPDU Guard so the port is shut down if unexpected BPDUs arrive. This option confuses PortFast with STP control-plane behavior.

Bronze is typically used for background or low-priority traffic (for example, bulk transfers or non-interactive applications). Selecting Bronze for voice would increase delay and jitter because voice frames would contend with other traffic without priority. This would commonly result in poor call quality, choppy audio, and dropped calls in busy RF conditions.

Gold is commonly associated with high-priority traffic and is often used for video. While video is important, it is generally prioritized below voice because voice is more sensitive to delay and jitter. Using Gold for voice may work in lightly loaded environments, but it is not the recommended or typical GUI selection for a voice WLAN deployment.

Silver generally corresponds to best-effort traffic. Best-effort does not provide the preferential queuing and contention parameters needed for real-time voice on Wi-Fi. If voice is left at Silver, it competes like normal data traffic, increasing the likelihood of latency spikes and jitter, especially as client count and airtime utilization rise.

Local mode is the standard unified AP mode where the AP depends on the WLC for control and typically tunnels client traffic to the controller using CAPWAP. If the AP loses connectivity to the WLC, it generally cannot continue providing normal WLAN service because it relies on the controller for configuration, security policies, and (often) data-plane tunneling.

Mesh mode enables APs to form a wireless backhaul (MAPs connecting through RAPs) when Ethernet cabling is unavailable. While mesh can help an AP reach the network, it does not specifically provide survivability for client service when the AP loses connectivity to the WLC. The controller is still required for management and operation.

Sniffer mode turns the AP into a dedicated RF capture device, forwarding 802.11 frames to a remote analyzer (for example, Wireshark) for troubleshooting. In this mode the AP does not provide normal client access. It is used for monitoring and packet analysis, not for continuing client service during controller failures.

"active" is an LACP mode. It actively sends LACP packets to negotiate and form an EtherChannel with a neighbor. Because it relies on the LACP negotiation protocol, it does not meet the requirement of “without using a negotiation protocol.” Use active/passive when you want standards-based negotiation and at least one side initiating.

"auto" is a PAgP mode that passively waits for PAgP negotiation messages from the other side. It will not initiate the EtherChannel; it requires the neighbor to be set to "desirable" to form. Since it uses PAgP (a negotiation protocol), it is not correct for a “no negotiation” requirement.

"desirable" is a PAgP mode that actively negotiates EtherChannel by sending PAgP packets. It can form an EtherChannel with a neighbor in "auto" or "desirable". Because it depends on PAgP negotiation, it does not satisfy the condition of configuring EtherChannel without a negotiation protocol.

Bridge mode refers to an AP operating as a wireless bridge (for example, connecting two wired networks over a wireless link, or certain mesh/bridging scenarios). While some bridge/mesh deployments can be controller-based, “bridge” is not the defining mode for WLC management. The question is asking for the AP mode that is specifically intended to be managed by a WLC, which is lightweight.

Mobility Express is a solution where one AP runs an embedded wireless controller function and manages other APs. It can look like “controller-managed,” but it is not the classic model of APs being managed by a dedicated Cisco WLC appliance/VM. On CCNA-style questions, “managed by Cisco WLC” typically maps to lightweight mode, not Mobility Express.

Autonomous mode means the AP operates independently without a WLC. Configuration and control functions reside on the AP itself (often configured via CLI/GUI per device). Autonomous APs can provide WLAN services, but they are not managed by a Cisco Wireless LAN Controller, which is exactly what the question is asking about.

QoS settings are commonly configured per WLAN (e.g., Platinum/Gold/Silver/Bronze on AireOS, or QoS profiles/policy on Catalyst 9800), but they are not mandatory fields to create a new WLAN object in the WLC GUI. QoS is typically adjusted after the WLAN is created, based on application requirements like voice, video, or best-effort data.

You do not enter the IP address of one or more access points when creating a WLAN. APs discover and join the controller using CAPWAP and are managed separately from WLAN definitions. Once APs are joined, WLANs are advertised based on controller configuration (and possibly AP groups/policy tags), not by manually listing AP IPs during WLAN creation.

Management interface settings are part of controller system configuration (management IP, default gateway, DHCP server settings, etc.), not a required input when creating a new WLAN. A WLAN is typically mapped to a dynamic interface/VLAN (or policy profile) for client traffic, but the controller’s management interface settings are not entered as part of the WLAN creation step.

Incorrect. An access port results when trunk negotiation does not succeed (for example, dynamic auto to dynamic auto, or when one side is forced to access). In this scenario, SW2 is dynamic desirable and actively requests trunking, and SW1 (dynamic auto) will accept that request, so the port does not remain access.

Incorrect. DTP mismatches do not normally place a port into err-disabled. Error-disable is triggered by specific protection mechanisms (for example BPDU Guard, Port Security violations, UDLD, or link-flap detection). With auto/desirable, DTP negotiation succeeds and the interface transitions normally, so err-disable is not expected.

Incorrect. The physical link state (up/down) depends on Layer 1/2 connectivity (cabling, speed/duplex negotiation, admin shutdown, etc.), not on whether DTP negotiates trunking. With dynamic auto and dynamic desirable, the link can come up and then negotiate trunking; it should not be down due to these DTP settings.

This is incorrect because Cisco IP phones are specifically designed to let an attached PC share the same physical switch connection. In normal operation, the phone does not discard ordinary untagged PC data traffic. Dropping the traffic would prevent the integrated phone-plus-PC deployment model commonly used in enterprise networks. Only separate security or policy features could cause drops, not the phone's default forwarding behavior.

This is incorrect because the phone does not tag attached PC traffic with the native VLAN. Native VLAN is an 802.1Q trunk concept describing which VLAN is carried untagged across a trunk link. In the phone deployment model, the PC sends untagged traffic and the phone forwards it untagged, while only voice traffic is tagged. Therefore, no native-VLAN tag is added by the phone.

This is incorrect because the phone does not tag PC traffic with a default VLAN either. Although the switch will place incoming untagged frames into its configured access VLAN, that classification happens on the switchport and is not a tagging action performed by the phone. The question asks what action the phone takes, and the phone simply forwards the traffic unchanged. Confusing switch VLAN assignment with phone tagging leads to the wrong answer.