CCNA Switching Network Access Questions

The specific factual error is that IP routing is not enabled by default; it requires the 'ip routing' global command.

The specific factual error is that the native VLAN must match on both sides; changing R1's native VLAN to 1 does not match the switch's native VLAN 99.

The specific factual error is that the subinterface G0/0.20 is associated with VLAN 20, so its encapsulation must be dot1Q 20, not 10.

Confusing DTP trunk negotiation with the operational consequences of a native VLAN mismatch.

Assuming that a crossover cable is mandatory for switch-to-switch connections, ignoring auto-MDIX.

Mistaking the ability to forward traffic for a specific VLAN with the ability to negotiate a trunk.

The native VLAN is used for untagged traffic on a trunk and does not affect the forwarding of tagged frames for other VLANs. Changing the native VLAN to 50 would not resolve the issue because VLAN 50 frames are still tagged and require inclusion in the allowed VLAN list.

An access port can only carry a single VLAN, so changing the trunk to an access port would prevent the link from carrying multiple VLANs, including VLAN 50. The link is intended to carry multiple VLANs, so a trunk is required.

PPP (Point-to-Point Protocol) is a WAN protocol used on serial links, not on Ethernet trunks. Ethernet trunks use 802.1Q or ISL encapsulation, and PPP has no relevance to VLAN trunking issues.

This action is too drastic and impacts all ports, whereas the issue is specific to access ports connected to end devices. PortFast is the standard, safe method for eliminating delay on edge ports.

Candidates might think that turning off STP on a single VLAN is a quick fix, but it removes the safety net against loops and is not a recommended network practice. PortFast provides the immediate-forwarding benefit while preserving STP loop protection.

Candidates often assume that Rapid PVST+ immediately forwards on all access ports, but the edge port behavior must be configured. The scenario explicitly mentions the port is an access port connected only to a PC; the immediate fix is to enable PortFast, not change the entire STP mode.

This statement is incorrect because the phone and PC can operate on different VLANs on the same port. The phone uses the voice VLAN, while the PC uses the access (data) VLAN. They are not required to use the same VLAN, and misconfiguration of the access VLAN can cause the PC to fail while the phone works.

BGP (Border Gateway Protocol) is a routing protocol used between autonomous systems, not related to VLAN configuration on a switchport. The issue described is about Layer 2 VLAN assignment, not Layer 3 routing. BGP has no role in this scenario.

The access VLAN remains relevant even when a voice VLAN is configured. The access VLAN is used for the PC's data traffic, while the voice VLAN is used for the phone's traffic. If the access VLAN is incorrect, the PC will not be able to communicate on the correct data network.

Rapid PVST+ uses RSTP's rapid handshake process, not timer-based convergence like standard 802.1D.

Rapid PVST+ is based on the 802.1w standard (RSTP), not 802.1D.

Rapid PVST+ runs a separate instance per VLAN and does not use 802.1Q to consolidate instances.

Changing the port type to trunk does not affect spanning-tree root bridge election or port roles. The blocking state is determined by spanning-tree topology, not by trunk configuration.

Portfast is intended for access ports connected to end devices to bypass listening/learning states; it is not used on uplinks and does not resolve a blocking state caused by spanning-tree topology.

BPDU guard is used on access ports to protect against rogue switches by disabling the port if a BPDU is received. It does not affect root bridge election or port roles on uplinks.

The command 'switchport trunk allowed vlan 10' is used on a trunk port to specify which VLANs are allowed to traverse the trunk link. It does not change the port mode to access; instead, it assumes the port is already a trunk. Therefore, it is incorrect for placing a switch port into access mode.

The command 'switchport mode dynamic desirable' enables Dynamic Trunking Protocol (DTP) to actively negotiate trunking with the connected device. This does not directly place the port into access mode; instead, it allows the port to become a trunk if the neighbor agrees. The port remains in a dynamic state until negotiation completes.

The command 'no switchport' converts a Layer 2 switch port into a Layer 3 routed port, which is used for routing between VLANs or connecting to routers. This removes all Layer 2 switching functionality, including VLAN assignment, and is the opposite of placing the port into access mode.

Spanning Tree Protocol (STP) operates at Layer 2 and has no mechanism to manage or allocate IP addresses; IP address exhaustion is addressed by protocols like DHCP or IPv6 transition technologies.

DNS lookups are application-layer processes that rely on IP connectivity and name resolution servers; STP does not influence DNS performance or resolution speed.

Wireless encryption is a security feature implemented at the data link layer (e.g., WPA2/3) and is unrelated to STP, which deals with physical topology loop prevention.

PortFast allows a port to transition to forwarding immediately upon link up, but it does not react to BPDU reception. BPDU Guard is a separate feature that disables the port upon receiving a BPDU, not accelerate forwarding.

Receiving a BPDU on a single edge port does not trigger a root bridge election. Root bridge election is based on bridge ID comparison across the entire spanning-tree domain, not on a single BPDU on a port.

BPDU Guard does not change the port mode; it only reacts to BPDU reception by disabling the port. Port mode (access or trunk) is configured separately and is not affected by STP protection features.

Channel width affects all clients on the AP, not just a single client.

Hiding the SSID only prevents the SSID from being broadcast; it does not impact network access after association.

WPA2 does not require NTP for client authentication; NTP is for time synchronization, not client access control.

The output shows individual port statuses (s) and (I), which indicate LACP negotiation states, not speed/duplex mismatches. While speed/duplex mismatches can cause EtherChannel issues, the specific flags in the exhibit point to a bundling problem, not a mismatch.

A Layer 3 port-channel can function correctly if configured properly. The output does not indicate any Layer 2 vs Layer 3 mismatch; the problem is that the member interfaces are not successfully bundling into the logical channel, as shown by the (s) and (I) status flags.

LACP does not require exactly four links; it can form bundles with 2 to 8 active links (and up to 16 total with standby). The exhibit shows only two member ports, which is perfectly valid for an EtherChannel.

The specific factual error is that changing G0/1 to access VLAN 10 would not resolve the mismatch if the intended configuration is trunking. It would only create a different mismatch if the other side expects trunking.

The specific factual error is that dynamic desirable mode does not ensure trunking; it relies on DTP negotiation, which may fail if the other side is set to trunk. Additionally, the VLAN mismatch (access vs trunk) would still prevent EtherChannel formation.

The specific factual error is that the protocol does not affect the requirement for consistent interface configurations. Both LACP and PAgP require identical VLAN and trunk settings on all member ports.

DHCP Discover is always broadcast (destination FF:FF:FF:FF:FF:FF), not unicast, because the client does not know the DHCP server's MAC address.

A TCP SYN-ACK indicates the server received the SYN and is willing to establish the connection; it is part of a successful three-way handshake, not a failure.

The TTL in a captured packet is the value after decrementing at each hop; the original TTL is set by the source but is not preserved in the packet header.

The specific factual error: 'spanning-tree guard root' is a root guard feature, not BPDU guard. Also, manually setting priority to 4096 may not guarantee root if another switch has lower priority.

The specific factual error: 'root secondary' is for backup root, not primary. It sets priority to 28672, which is higher than the default priority of 32768 but not low enough to become root if another switch has a lower priority.

The specific factual error: priority 32768 is default and does not change root status. BPDU filter is not a security feature against BPDU attacks; it suppresses BPDUs entirely.

BPDU guard is incorrect because it disables a port upon receiving any BPDU, which is suitable for edge ports but does not control root path roles or topology changes.

Port security is unrelated to STP root path control; it manages MAC address access on a port and does not affect BPDU processing or root bridge election.

DHCP snooping protects against rogue DHCP servers by filtering DHCP messages and does not interact with STP or root bridge election mechanisms.

The 'protect' mode does not disable the port when the secure MAC address limit is exceeded; instead, it drops packets from unknown MAC addresses without generating a notification. This behavior does not match the requirement of the question.

The 'restrict' mode allows traffic to pass but drops packets from unknown MAC addresses, without disabling the port. This does not meet the requirement of automatically disabling the port when the MAC address limit is exceeded.

The 'dynamic' option is incorrect because it does not refer to a specific port-security violation mode that disables the port when the MAC address limit is exceeded. Instead, it implies the dynamic learning of MAC addresses without enforcing a security limit.

The SSID broadcast setting does not directly impact the ability of users to connect to an internal application once they are authenticated and assigned an IP address. Since wired users can access the application, the issue is likely related to WLAN-specific configurations rather than SSID visibility.

The access point's hostname does not directly impact application access; it primarily affects network identification and management. Since the issue is specific to WLAN access and not present for wired users, the hostname is unlikely to be the cause.

This option is wrong because the issue pertains to application access over a specific WLAN, not the type of connection (PPP vs. Ethernet). The problem likely lies in WLAN configuration rather than the protocol used by the client device.

The phone works but the PC cannot reach the data network, indicating the PC is not in the correct VLAN. 'switchport mode dynamic auto' sets the port to negotiate trunking via DTP, which does not assign a data VLAN to the PC.

The PC cannot reach the data network because the switchport is likely configured as a voice VLAN only, but the data VLAN (access VLAN) is missing. Option B configures the voice VLAN, which is correct for the phone, but does not set the access VLAN for the PC.

The issue is that the PC cannot reach the data network, which is typically configured via the access VLAN. Spanning-tree guard root is unrelated to VLAN assignment; it prevents a switch from becoming the root bridge, not connectivity issues on a specific VLAN.

This option is incorrect because both sides do not need to be active. One side active and the other passive is sufficient for LACP negotiation and channel formation.

This option is incorrect because PAgP is a different, Cisco proprietary protocol and does not work alongside LACP. Enabling PAgP does not affect LACP negotiation.

This option is incorrect because configuring one side as active and the other as passive uses LACP negotiation, not a static Port-Channel. Static Port-Channels require manual configuration on both ends without negotiation.

The exhibit shows the ports as suspended, not err-disabled. Spanning-tree loops typically cause err-disable, not suspension.

The port-channel is up (U), so it is not shutdown.

The scenario explicitly states that all interfaces are configured with the same VLAN, so this is not the cause.

Option B uses 'root secondary', which sets the priority to 28672, making SW1 a backup root, not the primary root bridge.

Option C uses a static priority assignment of 4096, which would also make SW1 root, but the question expects the Cisco-recommended macro command 'root primary'.

Option D uses incomplete syntax 'spanning-tree vlan 10 root' without 'primary' or 'secondary', which is invalid.

UplinkFast is not designed to detect or prevent unidirectional links; it only accelerates failover.

The protections are applied to the wrong ports: BPDU Guard should be on access ports, Root Guard on ports facing potential rogue switches, and Loop Guard on uplinks.

PortFast does not prevent BPDU reception; it only skips the listening and learning states. Without BPDU Guard, the port would still process BPDUs and could become a root port.

The violation mode 'protect' silently drops frames from unknown MACs without disabling the port, which contradicts the requirement to shut down the port.

The 'mac-address' command with a specific address statically assigns that MAC, which is not dynamic. Sticky learning uses the 'mac-address sticky' command to dynamically learn and save the first MAC.

The 'restrict' mode does not disable the port; it only drops offending frames and logs the violation. The requirement explicitly states to shut down the port, which requires the 'shutdown' violation mode.

The specific factual error: passive mode on both sides will not form an LACP EtherChannel because neither side initiates negotiation; at least one side must be active.

The specific factual error: 'desirable' is a PAgP mode; LACP uses 'active' or 'passive'. Using 'desirable' would not form an LACP EtherChannel.

The specific factual error: the requirement explicitly states 'active mode on both sides', so setting one side to passive violates the requirement, even though the channel might still form.

This option is incorrect because LACP (Link Aggregation Control Protocol) does not require PAgP (Port Aggregation Protocol) as a backup; they are separate protocols. LACP can operate independently without needing PAgP on either side of the EtherChannel.

This option is incorrect because EtherChannel can indeed operate on switch trunks, allowing multiple VLANs to be carried over a single logical link. The issue in the question pertains to LACP configuration mismatches, not trunking capabilities.

This option is incorrect because Spanning Tree Protocol (STP) does not need to be disabled for EtherChannel to form; EtherChannel can operate alongside STP. Disabling STP can lead to network loops and is not a requirement for EtherChannel functionality.

This option is wrong because the selection of the root port is based on the lowest root path cost, not the local interface MAC address. The MAC address is not a factor in determining the root port in the Spanning Tree Protocol (STP) process.

This option is wrong because the selection of the root port in Spanning Tree Protocol (STP) is based on the lowest root path cost, not the duplex settings of the interfaces. Duplex settings do not influence the port selection process in STP.

The lowest configured VLAN number is not a factor in determining the root port in Spanning Tree Protocol (STP). The selection process prioritizes path cost, not VLAN configuration.

The designated port is responsible for forwarding traffic to and from a network segment and does not receive the best BPDU toward the root bridge; instead, it sends BPDUs to other ports. Therefore, it cannot be the correct answer for identifying the port role that receives the best BPDU on a nonroot switch.

The alternate port does not receive the best BPDU toward the root bridge; instead, it serves as a backup path to the root bridge when the primary path fails. It is in a blocking state and does not forward traffic.

A Disabled port does not participate in the Spanning Tree Protocol (STP) and does not receive any BPDUs, making it incapable of receiving the best BPDU toward the root bridge.

Access mode carries only a single VLAN, so it would stop inter-VLAN routing entirely.

The native VLAN is for untagged frames; changing it does not add VLAN 20 to the allowed list.

The 'except' keyword excludes the specified VLAN, so it would prevent VLAN 20 from being carried.

Access ports cannot carry multiple VLANs; they are assigned to a single VLAN. The concept of secondary VLAN does not exist for access ports.

ISL encapsulation is deprecated in favor of 802.1Q, which is the industry standard. Allowing all VLANs violates the principle of least privilege.

Including VLAN 1 is unnecessary and can be a security concern. The allowed VLAN list should be restricted to only the VLANs that need to be routed.

Root Guard does not shut down the port; it places the port in a root-inconsistent state, which effectively blocks traffic but does not disable the port. BPDU Guard, on the other hand, errdisables the port.

Loop Guard does not disable the port; it places the port into a loop-inconsistent state, blocking traffic on that port until BPDUs are received again. The port remains administratively up.

BPDU Guard errdisables the port, not just blocks it. Loop Guard uses a loop-inconsistent state, which is different from errdisable. BPDU Guard is a more severe reaction.

This option is incorrect because the question specifies that LACP is being used, which is incompatible with PAgP. EtherChannel can operate with either LACP or PAgP, but not both simultaneously.

This option is wrong because EtherChannel can form with access ports or trunk ports, and there is no requirement for the interfaces to be routed ports for EtherChannel to function.

EtherChannel can function with as few as two member links; therefore, requiring three or more member links is not a valid reason for the bundle not forming in this scenario.

Using 'root secondary' for VLAN 20 sets priority to 28672, leaving MLS1 as backup root, not the primary root.

Manually setting priority to 4096 is valid but not the recommended method; 'root primary' is simpler and ensures proper value.

Global portfast and bpduguard are not required because the interface is already configured with those features; this adds unnecessary commands.

This option is incorrect because an access port does not automatically convert to a routed port when connected to a trunk port; it remains an access port and will not participate in Layer 3 routing.

This option is wrong because switchport settings do not automatically synchronize between devices; each port retains its configuration independently, leading to a mismatch in link roles.

This option is incorrect because the configuration mismatch between a trunk and an access port does not directly affect OSPF router IDs, which are determined by the OSPF process itself and not by switchport configurations.

Access ports do not automatically become routed ports; they remain Layer 2 switchports unless explicitly configured with 'no switchport'.

Switches do not automatically synchronize configurations; this is not a feature supported on Cisco switches to resolve mismatches.

OSPF router ID is determined by the highest loopback or IP address, not by Layer 2 port configuration mismatches.

The native VLAN is specifically the VLAN that does not get a tag; all other VLANs are tagged.

802.1Q is an open standard, whereas ISL was Cisco proprietary.

Mismatched native VLANs can lead to security vulnerabilities and misrouting, but the trunk itself may still come up.

Root Guard is intended for ports that should not become root; applying it on the uplink would block legitimate superior BPDUs from the core. Loop Guard on the designated port would not protect against unidirectional links on the uplink.

Root Guard on an access port is unnecessary and would not prevent the switch from becoming root via other ports. BPDU Guard on the designated port would disable it instead of blocking the BPDU.

Loop Guard on an access port does not protect against unidirectional links on the uplink. BPDU Guard on the uplink would err-disable the core connection if a BPDU is received, which is undesirable.

This would cause a complete trunk failure, not a failure limited to a single VLAN.

STP would not randomly block one VLAN on a point-to-point trunk while the rest are forwarding; this is not a typical behavior.

Layer 2 switching within the same VLAN does not require an SVI; an SVI is only needed for routing between VLANs or management.

This option is incorrect because the question specifies an access port configuration, which does not require trunk encapsulation. Access ports do not use trunking protocols like dot1q, as they are meant for single VLAN traffic only.

This option is wrong because the channel-group command is used for configuring EtherChannel, which is not relevant to the issue of the IP phone not registering on an access port. The problem lies in the VLAN configuration for voice traffic, not in link aggregation.

The 'ip helper-address' command is used to forward DHCP requests from clients to a DHCP server, but it does not address the registration issue of the IP phone in this scenario, which is related to VLAN configuration.

This is a drastic action that does not address a VLAN mismatch; the same symptom would recur.

Jumping to STP before confirming basic Layer 2 VLAN membership is not the most efficient next step.

This option confuses Layer 2 MAC learning with Layer 3 ARP resolution, and does not help locate the MAC entry in the address table.

A DHCP server is not required for communication between VLANs; it only assigns IP addresses to devices within a network. VLAN communication requires routing, which a DHCP server does not provide.

A DNS server is not required for VLAN communication, as DNS resolves domain names to IP addresses, which does not facilitate inter-VLAN routing. Communication between VLANs requires Layer 3 routing, not name resolution.

A second access switch is not required for VLAN communication; VLANs can communicate through a Layer 3 device such as a router or a Layer 3 switch. The existing switch infrastructure can handle VLANs without needing additional switches.

This option is wrong because configuring all ports as trunks does not facilitate inter-VLAN routing; SVIs and Layer 3 routing are necessary for that functionality.

This option is wrong because OSPF is a routing protocol used for dynamic routing, and access ports do not participate in routing processes. Routing between VLANs requires SVIs and Layer 3 capabilities, not OSPF on access ports.

Port security being disabled on every edge port is not a requirement for routing traffic between VLANs; it pertains to security configurations rather than routing functionality. VLAN routing can occur regardless of port security settings.

The priority 4096 is too low and would still result in SW1 being the root bridge.

The 'root secondary' command does not prevent the switch from becoming root; it only makes it the backup root.

Using 'cause all' is not the best practice; the requirement is to recover from bpduguard specifically.

Confusion about how dynamic trunking protocol (DTP) modes interact with VLAN membership display.

Misconception that only operational interfaces are shown in VLAN membership tables.

Overlooking the explicit 'active' status and port list for VLAN 10 in the output.

Dynamic desirable mode can still form a trunk if the other side is willing; the trunk is already up/up, so the port mode is not the issue.

A native VLAN mismatch or missing native subinterface only affects untagged frames; the hosts in VLAN 10 and VLAN 20 send tagged traffic, so this would not break their routing.

The hosts' access port configurations would prevent intra-VLAN communication if misassigned, but the question describes an inter-VLAN routing failure through the trunk, not a problem with the access ports themselves.

The SSID broadcast name is not relevant in this scenario because the user has already associated successfully and obtained an IP address, indicating that the SSID is correct and functioning.

The AP radio antenna type does not directly impact a user's ability to obtain an IP address or reach the Internet after successful association. This option is irrelevant since the user is already connected to the network.

OSPFv3 area configuration is related to routing protocols and is not directly relevant to a user's inability to access the Internet on a guest network after successfully associating. The issue is likely related to network policies or forwarding paths rather than routing configurations on the user's device.

VLAN 10 is not the default untagged VLAN on Cisco switches; instead, VLAN 1 is typically used for this purpose unless configured otherwise. Therefore, selecting VLAN 10 would be incorrect in the context of the question.

VLAN 20 is not the default untagged VLAN on Cisco switches; instead, VLAN 1 is typically sent untagged on 802.1Q trunks unless configured otherwise. Therefore, selecting VLAN 20 does not align with the standard behavior of Cisco switch configurations.

This option is incorrect because the default untagged VLAN on many Cisco switches is VLAN 1, not the highest configured VLAN. The highest configured VLAN can vary based on the network setup and does not have a default status in this context.

Different VLANs must use different IP subnets for routing; using the same subnet would break Layer 3 separation.

Access ports remain as access ports; inter-VLAN routing requires SVIs with routing enabled, not trunk conversion of access ports.

The default gateway for each VLAN is the SVI IP address; a wireless controller is irrelevant to Layer 3 forwarding between wired VLANs.

The AP using the wrong channel width would not cause immediate authentication failures; it typically affects connectivity or performance rather than authentication processes. Since the guest wireless works, the channel width is likely not the issue.

A mismatched RADIUS shared secret would cause authentication failures, but guest wireless works on the same access point, indicating the AP itself is functional; the more likely cause is that the RADIUS server is completely unreachable, not just a shared secret mismatch.

Configuring the SSID as hidden would not cause immediate authentication failures; users would simply not see the SSID unless they manually entered it. The issue described involves users seeing the SSID but failing authentication, indicating a problem beyond SSID visibility.

Resetting OSPF process IDs does not address VLAN traffic issues over a trunk link, as OSPF is a routing protocol and unrelated to Layer 2 VLAN configurations.

Adding an ip helper-address is irrelevant to VLAN traffic issues across a trunk link, as this command is used for forwarding DHCP requests, not for resolving VLAN connectivity problems.

Disabling the MAC address table would not resolve VLAN traffic issues across a trunk link, as it pertains to Layer 2 forwarding and would disrupt normal switch operations, leading to further connectivity problems.

The SVI is operational, so this cannot be the root cause.

The router receives the ICMP requests, so an inbound ACL would have dropped them before they reached the capture buffer.

ICMP redirects do not prevent the router from responding to pings; they only send redirect messages when appropriate.

The specific factual error is that LACP requires all member ports to have identical configurations, and this option does not align with the existing Port-channel configuration.

The specific factual error is that the VLAN allowed list must match across all member ports and the Port-channel interface; omitting VLAN 30 will cause inconsistency.

The specific factual error is that LACP requires consistent switchport mode (access or trunk) across all member ports and the Port-channel interface.

A hidden SSID would prevent the SSID from appearing, but the user reports the SSID is visible, so this does not match the symptom.

PPP encapsulation on an AP uplink concerns Layer 2 framing, not the post-authentication VLAN or policy assignment that causes quarantine.

OSPF designated router election occurs at Layer 3 within routing, while the issue is about client VLAN placement after authentication, which is a Layer 2 access-control function.

This option is wrong because the STP root bridge ID does not directly affect the formation of an EtherChannel; EtherChannel requires matching port configurations, not spanning tree parameters.

The interface description does not affect the formation of an EtherChannel, as it is merely a label for identification purposes and does not influence Layer 2 connectivity or protocol negotiation.

The ARP timeout value does not affect the formation of a Layer 2 EtherChannel, as EtherChannel operates at Layer 2 and is concerned with port configurations, not Layer 3 settings like ARP.

The voice VLAN and access VLAN are typically different; matching them would defeat the purpose of separating voice and data traffic, and it would not cause the PC to lose network access.

In the described scenario, the phone works but the PC does not, indicating a VLAN mismatch for the PC's access VLAN, not a trunk mode issue. Trunk mode is not required for a phone; instead, the switch port typically uses a voice VLAN and an access VLAN, with the phone tagging voice traffic and passing PC traffic untagged.

Option B is incorrect because an alternate port does not forward traffic while the root port is active; it serves as a backup path and only becomes active if the root port fails.

This option is wrong because the alternate port does not participate in the election process for the root bridge; it only serves as a backup path to the root bridge once it is established.

Option D is incorrect because an alternate port is not a routed port; it operates at Layer 2 and is part of the Spanning Tree Protocol, which does not involve routing functionalities for inter-VLAN communication.

This option is wrong because the question specifically addresses VLAN communication issues over a trunk link, which are unrelated to OSPF router ID configuration. OSPF router ID affects routing protocols, not VLAN traffic directly.

NTP source interface is unrelated to VLAN communication issues over a trunk link; it primarily affects time synchronization across devices. Since the question focuses on VLAN connectivity, this option does not address the core problem.

Lack of PAT overload on the WAN router is unrelated to VLAN communication issues between switches. This option pertains to address translation for outbound traffic, not VLAN trunking problems.

The specific factual error: Setting MLS1 priority to 0 makes it root, opposite of the requirement. Removing BPDU Guard does not recover the port; 'no shutdown' is needed.

The specific factual error: Reloading the switch is not the standard recovery for an err-disabled port; 'no shutdown' is the proper command.

The specific factual error: MLS1 should have a higher priority (e.g., 4096) and SW2 a lower priority (e.g., 0) to make SW2 root. The option does the opposite.

This option is incorrect because the native VLAN being set to 1 does not prevent VLAN 30 traffic from being transmitted across the trunk link. The issue lies in VLAN 30 not being allowed on the trunk, which is not addressed by the native VLAN setting.

This option is incorrect because VTP server mode is not required for VLANs to communicate across switches; VLAN configuration can be done independently on each switch. The issue in the question is related to trunking and VLAN allowance, not VTP mode.

Spanning Tree Protocol (STP) does not block all user VLANs by default; it only blocks specific ports to prevent loops. In this case, the issue is related to VLAN 30 not being allowed on the trunk, not STP blocking the VLAN.

CAPWAP tunnels require the AP to have an IP address; the statement is false.

CAPWAP operates over IP using UDP ports, not PPP.

The controller may have an AP capacity limit, but with only one AP failing and no evidence that the limit is 14, this is not the strongest explanation.

A common misconception is that any down state is an admin shutdown, but Cisco IOS distinguishes 'Secure-shutdown' for port-security errdisable from 'administratively down'.

Some candidates misread the output and assume sticky is off, but the presence of a sticky MAC count proves it is active.

It is tempting to assume any violation with maximum 1 is due to exceeding the limit, but in this case the secure MAC is the original sticky address, and the violation is from a different unauthorized MAC, which still respects the limit count but fails the authorization check.

The command 'show ip ospf neighbor' is used to display OSPF neighbor relationships, which is not directly related to verifying the operational status of a port-channel. This command would not provide information about the port-channel configuration or status.

The command 'show ip route' is used to display the routing table of a device, which does not provide information about the operational status of a port-channel after configuration changes.

The command 'show access-lists' is not relevant for verifying the operational status of a port-channel; it focuses on access control lists rather than link aggregation status.

The specific factual error is that LACP modes must be compatible (active-active or active-passive), but the question states both sides are active, so mode is not the issue.

The specific factual error is that VLAN settings are irrelevant to the physical bundling of ports in an EtherChannel.

The specific factual error is that interface mode is a Layer 2 property unrelated to the physical bundling process.

An SSID misspelling would prevent all clients from seeing the SSID, but since clients on other floors connect successfully, this cannot be the issue.

BGP autonomous system mismatch is a routing protocol concept unrelated to wireless LAN performance issues and would not cause performance problems on a single floor.

IPv6 loopback addressing is a configuration detail that does not impact wireless client performance or connectivity in a local-area network context.

This option is wrong because the router ID is relevant for routing protocols, not for VLAN traffic issues on a trunk link. The problem specifically pertains to VLAN 40 traffic, which is not influenced by router IDs.

NetFlow is a network protocol used for collecting IP traffic information, but it does not directly affect VLAN traffic flow on a trunk link. Therefore, checking if NetFlow is enabled does not address the issue of VLAN 40 traffic failure.

NTP synchronization is not directly related to VLAN traffic issues on a trunk link; it primarily affects time-sensitive protocols. Therefore, checking NTP synchronization would not help diagnose why VLAN 40 traffic is failing.

This option is wrong because `switchport mode dynamic auto` does not force immediate trunking; it relies on negotiation, and if neither side actively negotiates, the link remains non-trunking.

This option is wrong because a switchport configured with `switchport mode dynamic auto` does not automatically convert to a routed Layer 3 link unless explicitly configured to do so. The default behavior is to remain in access mode unless trunking is negotiated.

Option D is incorrect because configuring `switchport mode dynamic auto` does not delete VLANs; it merely affects trunk negotiation. VLANs remain configured on the switches regardless of trunking status.

The higher-cost uplink becomes an alternate (blocked) port, not the lower-cost one.

A designated port exists on the upstream switch toward this switch, not on the non-root switch.

A disabled port is administratively shut down, not a port with a lower STP cost.

This option is wrong because enabling DHCP snooping trust on VLAN 30 does not facilitate communication with the DHCP server in VLAN 99; it only protects against rogue DHCP servers.

Adding 'switchport mode trunk' under interface Vlan30 is incorrect because VLAN 30 is already configured as a Layer 3 interface, and trunking is not applicable to Layer 3 interfaces. This command is used for Layer 2 interfaces to allow multiple VLANs over a single link.

This option is wrong because the command 'ip default-gateway' is used to set a default gateway for a Layer 2 device, not for enabling DHCP relay on a Layer 3 interface. Clients in VLAN 30 need a helper address to reach the DHCP server in VLAN 99.

The assumption that a native VLAN mismatch can drop tagged VLAN traffic is a common misunderstanding.

Misreading the output may lead to believing the trunk is not in trunking mode.

Confusing spanning tree blocking with allowed VLAN filtering; the output shows no block state, only absence of the VLAN.

This option is wrong because a port configured with PortFast and BPDU Guard will not automatically become the root port when it receives BPDUs; instead, it will be error-disabled due to BPDU Guard's protective mechanism.

This option is incorrect because a port configured with PortFast and BPDU Guard does not convert to a trunk when receiving BPDUs; instead, BPDU Guard will disable the port to prevent potential loops.

This option is incorrect because PortFast does not disable Spanning Tree Protocol (STP) entirely; it only allows the port to transition to the forwarding state immediately without waiting for STP convergence. BPDU Guard will still take effect if BPDUs are received on a PortFast-enabled port.