Spanning Tree practice questions

A network engineer is troubleshooting an STP issue in a network that uses Rapid PVST+. The network has a root bridge (SW1) and a secondary root bridge (SW2). The engineer notices that after a link failure between SW1 and SW2, the network takes longer than expected to converge. The engineer checks the configuration and finds that SW2 has the 'spanning-tree uplinkfast' command enabled. The engineer also notices that SW2 has a lower priority than SW1. What is the most likely cause of the slow convergence?

Trap 1: SW2 has a lower priority than SW1, so it takes longer to become the…

Incorrect because the root bridge election is decided by bridge priority, but the priority value has no effect on convergence timing. Rapid PVST+ uses RSTP's proposal/agreement mechanism to rapidly transition ports to forwarding, and this occurs in milliseconds regardless of which switch is elected root. A lower priority on SW2 would only make it more likely to be root under normal operation; it would never cause it to 'take longer' to become root after a failure, since convergence speed is determined by protocol state machines and timers, not by priority.

Trap 2: BPDU Guard is enabled on the uplink ports, which prevents BPDU…

Incorrect because BPDU Guard is a PortFast security feature that error-disables a port the moment it receives any BPDU, to prevent unauthorized switches from participating in spanning tree. It does not filter, drop, or slow BPDU exchange while the link is up; rather, it shuts the port down completely, which would cause an immediate loss of connectivity, not a delay in convergence. On normal uplink ports BPDU Guard is not enabled, and even if it were, it would not alter the STP timers or slow down the root port failover process.

Trap 3: Loop Guard is enabled on the uplink ports, which delays port…

Incorrect because Loop Guard is designed to protect against unidirectional link failures by blocking a port that stops receiving BPDUs, placing it in a loop-inconsistent state. It does not add any artificial delay to the normal forwarding transition process; instead, it actively prevents a port from becoming designated when BPDUs are absent, which is a safety measure, not a timer-based delay. Loop Guard would only interfere after a BPDU loss and would block the port entirely, so it cannot explain the slower convergence caused by using legacy STP timers.

A
UplinkFast is enabled, which is incompatible with Rapid PVST+ and causes the switch to use legacy STP convergence.
Correct because UplinkFast is a proprietary Cisco feature designed for legacy 802.1D PVST+ to quickly fail over to a precomputed alternate root port when the primary uplink fails. However, UplinkFast is mutually exclusive with Rapid PVST+/RSTP, and when enabled it forces the switch to fall back to the classic Spanning Tree Protocol algorithm. That legacy mode relies on Max Age (20 seconds) and Forward Delay (15 seconds) timers, so after a root port failure the switch takes 30–50 seconds to converge instead of milliseconds, matching the behavior described.
B
SW2 has a lower priority than SW1, so it takes longer to become the root bridge after failure.
Why it fails: Incorrect because the root bridge election is decided by bridge priority, but the priority value has no effect on convergence timing. Rapid PVST+ uses RSTP's proposal/agreement mechanism to rapidly transition ports to forwarding, and this occurs in milliseconds regardless of which switch is elected root. A lower priority on SW2 would only make it more likely to be root under normal operation; it would never cause it to 'take longer' to become root after a failure, since convergence speed is determined by protocol state machines and timers, not by priority.
C
BPDU Guard is enabled on the uplink ports, which prevents BPDU exchange.
Why it fails: Incorrect because BPDU Guard is a PortFast security feature that error-disables a port the moment it receives any BPDU, to prevent unauthorized switches from participating in spanning tree. It does not filter, drop, or slow BPDU exchange while the link is up; rather, it shuts the port down completely, which would cause an immediate loss of connectivity, not a delay in convergence. On normal uplink ports BPDU Guard is not enabled, and even if it were, it would not alter the STP timers or slow down the root port failover process.
D
Loop Guard is enabled on the uplink ports, which delays port transition.
Why it fails: Incorrect because Loop Guard is designed to protect against unidirectional link failures by blocking a port that stops receiving BPDUs, placing it in a loop-inconsistent state. It does not add any artificial delay to the normal forwarding transition process; instead, it actively prevents a port from becoming designated when BPDUs are absent, which is a safety measure, not a timer-based delay. Loop Guard would only interfere after a BPDU loss and would block the port entirely, so it cannot explain the slower convergence caused by using legacy STP timers.

Question 2mediummultiple choice

interface GigabitEthernet0/2
 spanning-tree link-type point-to-point

end

What is the effect of this configuration?

Trap 1: The port will become a designated port immediately.

Port role selection in STP/RSTP is determined by the spanning-tree algorithm comparing bridge IDs, path costs, and received BPDUs; configuring link-type point-to-point changes none of those values. The port can become root, designated, alternate, or backup depending on the topology, but this configuration only influences how quickly a port transitions when it is already the correct role. Therefore the switchport will not immediately become designated simply because the link type was set.

Trap 2: The port will disable STP on that link.

The spanning-tree link-type command does not turn off Spanning Tree Protocol processing on the interface; BPDUs are still sent and received, and STP state machines remain active. It only tells RSTP which transition mechanism to use on that segment. To truly disable STP you would need a global or per-VLAN shutdown command, such as 'no spanning-tree vlan' — not a link-type setting.

Trap 3: The port will use shared medium behavior.

A point-to-point link is the opposite of a shared medium: shared behavior models a legacy hub segment, where RSTP cannot use the proposal/agreement fast handshake because there may be more than two bridges contending for the same collision domain. On shared or half-duplex links, RSTP must fall back to the classic 802.1D waiting periods (max age, forward delay). Since the user specified point-to-point, the switch assumes a direct two-bridge segment and will not degrade to shared-medium behavior.

A
The port will use RSTP fast transition mechanisms assuming a point-to-point link.
Setting the link type to point-to-point marks the switchport as a direct, full-duplex connection between exactly two switches, which lets Rapid Spanning Tree (RSTP/Rapid PVST+) invoke its proposal/agreement mechanism. Once the root port sends a proposal and receives agreement from the downstream designated port, the port can enter the forwarding state immediately instead of waiting through the default 15-second listening and 15-second learning timers. This fast transition is the key benefit of RSTP over classic 802.1D STP and is only used when the link is treated as point-to-point.
B
The port will become a designated port immediately.
Why it fails: Port role selection in STP/RSTP is determined by the spanning-tree algorithm comparing bridge IDs, path costs, and received BPDUs; configuring link-type point-to-point changes none of those values. The port can become root, designated, alternate, or backup depending on the topology, but this configuration only influences how quickly a port transitions when it is already the correct role. Therefore the switchport will not immediately become designated simply because the link type was set.
C
The port will disable STP on that link.
Why it fails: The spanning-tree link-type command does not turn off Spanning Tree Protocol processing on the interface; BPDUs are still sent and received, and STP state machines remain active. It only tells RSTP which transition mechanism to use on that segment. To truly disable STP you would need a global or per-VLAN shutdown command, such as 'no spanning-tree vlan' — not a link-type setting.
D
The port will use shared medium behavior.
Why it fails: A point-to-point link is the opposite of a shared medium: shared behavior models a legacy hub segment, where RSTP cannot use the proposal/agreement fast handshake because there may be more than two bridges contending for the same collision domain. On shared or half-duplex links, RSTP must fall back to the classic 802.1D waiting periods (max age, forward delay). Since the user specified point-to-point, the switch assumes a direct two-bridge segment and will not degrade to shared-medium behavior.

Question 3hardmultiple choice

A global enterprise is transitioning from a traditional three-tier campus architecture to a software-defined access (SD-Access) fabric. Which architectural consideration is most critical for the underlay network?

Trap 1: Implement PIM-SM for multicast routing in the underlay.

PIM-SM is unnecessary and even harmful in an SD-Access underlay because multicast traffic is handled in the overlay via VXLAN encapsulation, typically with head-end replication. The underlay is intentionally an IP-only fabric that must not maintain multicast group state, since doing so adds control-plane complexity and introduces a dependency on a multicast Rendezvous Point. In a properly designed fabric, the overlay control plane (LISP) maps multicast receivers and sources, and the underlay simply forwards the encapsulated unicast copies, so enabling PIM-SM in the underlay would violate the architecture's scalability principles.

Trap 2: Preserve existing VLANs across the fabric to minimize changes.

Preserving existing VLANs across the fabric is a misunderstanding of the underlay/overlay boundary in SD-Access. The underlay is a routed L3 fabric where no L2 broadcast domain exists; VLANs are only locally relevant at each Fabric Edge node. Attempting to stretch VLANs across the fabric would force spanning-tree into the path, reintroduce L2 loops, and cap the fabric's scale at the size of a broadcast domain. In SD-Access, VLANs are mapped to overlay VNIs, and Layer 2 extension happens only where explicitly required, not as a default mode.

Trap 3: Deploy VRF-lite on all edge nodes to isolate tenants.

Deploying VRF-lite on all edge nodes is a throwback to a manual, device-centric segmentation model that does not align with SD-Access intent. The overlay uses LISP to maintain VRFs centrally and VXLAN VNIs to segregate tenants, providing end-to-end segmentation without requiring per-device VRF provisioning. VRF-lite would also be unable to span sites or enforce network-wide policy consistently, and it adds operational overhead precisely where SD-Access aims to eliminate it. Thus, VRF-lite should not be substituted for the fabric's overlay segmentation.

A
Configure a routed access layer with a link-state routing protocol (IS-IS or OSPF).
A routed access layer with IS-IS or OSPF is the required foundation for an SD-Access underlay. Link-state protocols offer rapid convergence, loop-free topology, and hierarchical scalability, which are essential when building a large leaf-and-spine fabric. The underlay is a pure L3 network, and all devices carry only unique loopback/p2p addresses, allowing the overlay (LISP/VXLAN) to run independently of L2 constraints. Without this routed design, the fabric cannot propagate reachability efficiently and may revert to spanning-tree, which is explicitly contrary to SD-Access best practices.
B
Implement PIM-SM for multicast routing in the underlay.
Why it fails: PIM-SM is unnecessary and even harmful in an SD-Access underlay because multicast traffic is handled in the overlay via VXLAN encapsulation, typically with head-end replication. The underlay is intentionally an IP-only fabric that must not maintain multicast group state, since doing so adds control-plane complexity and introduces a dependency on a multicast Rendezvous Point. In a properly designed fabric, the overlay control plane (LISP) maps multicast receivers and sources, and the underlay simply forwards the encapsulated unicast copies, so enabling PIM-SM in the underlay would violate the architecture's scalability principles.
C
Preserve existing VLANs across the fabric to minimize changes.
Why it fails: Preserving existing VLANs across the fabric is a misunderstanding of the underlay/overlay boundary in SD-Access. The underlay is a routed L3 fabric where no L2 broadcast domain exists; VLANs are only locally relevant at each Fabric Edge node. Attempting to stretch VLANs across the fabric would force spanning-tree into the path, reintroduce L2 loops, and cap the fabric's scale at the size of a broadcast domain. In SD-Access, VLANs are mapped to overlay VNIs, and Layer 2 extension happens only where explicitly required, not as a default mode.
D
Deploy VRF-lite on all edge nodes to isolate tenants.
Why it fails: Deploying VRF-lite on all edge nodes is a throwback to a manual, device-centric segmentation model that does not align with SD-Access intent. The overlay uses LISP to maintain VRFs centrally and VXLAN VNIs to segregate tenants, providing end-to-end segmentation without requiring per-device VRF provisioning. VRF-lite would also be unable to span sites or enforce network-wide policy consistently, and it adds operational overhead precisely where SD-Access aims to eliminate it. Thus, VRF-lite should not be substituted for the fabric's overlay segmentation.

Question 4easymultiple choice

A network engineer is configuring a new switch that will be used as an access layer switch. The switch connects to two distribution switches via trunk links. The engineer wants to ensure that the access switch does not become the root bridge for any VLAN. The engineer also wants to provide redundancy so that if one uplink fails, the other uplink takes over quickly. The engineer is using Rapid PVST+. What configuration should the engineer apply on the access switch?

Trap 1: Configure 'spanning-tree vlan vlan-list priority 0' on the access…

A priority of 0 is the lowest possible numeric bridge priority and therefore carries the highest election precedence, meaning the access switch would immediately be selected as root for the listed VLANs. This reverses the desired design, forcing traffic to traverse the access layer and creating an inefficient and potentially unstable forwarding path. In a network where multiple switches hold priority 0, the lowest MAC address decides the root, making the outcome unpredictable. Thus, while 0 is a legal value, using it here directly contradicts the goal of keeping the distribution layer as root.

Trap 2: Enable UplinkFast on the access switch to provide fast failover.

UplinkFast is a legacy proprietary mechanism that only accelerates failover for blocked root ports on access switches, not for general link outages in a Rapid PVST+ domain. Because 802.1w already performs fast convergence through synchronizing handshakes, enabling UplinkFast is redundant and can force the switch to behave inconsistently when both mechanisms are present. It also does not participate in root bridge election, so it would not prevent the access switch from becoming root. In modern Catalyst environments, UplinkFast is effectively obsolete and is automatically disabled when Rapid PVST is configured.

Trap 3: Enable PortFast on the trunk ports to speed up convergence.

PortFast is intended strictly for ports that connect to end hosts, immediately moving them to the forwarding state and bypassing listening and learning; applying it to a trunk that links to another switch suppresses STP on that segment entirely. This creates a serious loop risk because the trunk can forward BPDUs that the switch will ignore, leading to broadcast storms and MAC address flapping. Cisco does offer a 'spanning-tree portfast trunk' option, but that is for authenticated host connections (e.g., a host that requires a trunk), never for a normal switch-to-switch uplink. Since the access switch's trunk to the distribution switch is a switch-to-switch link, PortFast would be an unsafe and incorrect convergence shortcut.

A
Configure 'spanning-tree vlan vlan-list priority 61440' on the access switch.
Setting the switch's spanning-tree priority to 61440 (the highest numerical value) ensures its bridge ID will never be preferred over a legitimate root, because the root election down-selects the lowest bridge priority. Since Rapid PVST+ (802.1w) is already active, link failures are recovered through explicit proposal/agreement handshakes, eliminating the need for any extra convergence mechanism. This is the recommended way to pin the root on a distribution switch while making access switches incapable of becoming root even after a topology change.
B
Configure 'spanning-tree vlan vlan-list priority 0' on the access switch.
Why it fails: A priority of 0 is the lowest possible numeric bridge priority and therefore carries the highest election precedence, meaning the access switch would immediately be selected as root for the listed VLANs. This reverses the desired design, forcing traffic to traverse the access layer and creating an inefficient and potentially unstable forwarding path. In a network where multiple switches hold priority 0, the lowest MAC address decides the root, making the outcome unpredictable. Thus, while 0 is a legal value, using it here directly contradicts the goal of keeping the distribution layer as root.
C
Enable UplinkFast on the access switch to provide fast failover.
Why it fails: UplinkFast is a legacy proprietary mechanism that only accelerates failover for blocked root ports on access switches, not for general link outages in a Rapid PVST+ domain. Because 802.1w already performs fast convergence through synchronizing handshakes, enabling UplinkFast is redundant and can force the switch to behave inconsistently when both mechanisms are present. It also does not participate in root bridge election, so it would not prevent the access switch from becoming root. In modern Catalyst environments, UplinkFast is effectively obsolete and is automatically disabled when Rapid PVST is configured.
D
Enable PortFast on the trunk ports to speed up convergence.
Why it fails: PortFast is intended strictly for ports that connect to end hosts, immediately moving them to the forwarding state and bypassing listening and learning; applying it to a trunk that links to another switch suppresses STP on that segment entirely. This creates a serious loop risk because the trunk can forward BPDUs that the switch will ignore, leading to broadcast storms and MAC address flapping. Cisco does offer a 'spanning-tree portfast trunk' option, but that is for authenticated host connections (e.g., a host that requires a trunk), never for a normal switch-to-switch uplink. Since the access switch's trunk to the distribution switch is a switch-to-switch link, PortFast would be an unsafe and incorrect convergence shortcut.

Question 5mediummultiple choice

spanning-tree mode rapid-pvst

What is the effect of this global configuration command?

Trap 1: The switch will use MSTP for all VLANs.

Rapid PVST+ provides per-VLAN 802.1w instances; MSTP is a distinct mode configured with the spanning-tree mode mst command and region parameters. MSTP tempts because it also converges rapidly, and would be correct where many VLANs must map onto a few shared topologies to reduce switch overhead.

Trap 2: The switch will use classic STP for all VLANs.

The command enables Rapid PVST+, which runs a separate 802.1w instance per VLAN; classic 802.1D STP is not selected. Classic STP tempts because it is the historical default on older switches, and would be the correct mode where legacy bridges require slow-converging 802.1D compatibility.

Trap 3: The switch will disable STP on all ports.

The command changes the spanning-tree protocol variant; it never disables STP, which would require no spanning-tree vlan commands. Disabling STP tempts because it removes blocking ports and speeds convergence, and would be chosen only on edge ports where loops are impossible by design.

A
The switch will use Rapid PVST+ for all VLANs, providing faster convergence than classic STP.
Rapid PVST+ runs a separate 802.1w instance per VLAN, so each VLAN's topology converges independently using rapid handshake proposals and agreements rather than timers. This satisfies the stem's requirement of faster convergence than classic 802.1D STP while retaining per-VLAN load balancing.
B
The switch will use MSTP for all VLANs.
Why it fails: Rapid PVST+ provides per-VLAN 802.1w instances; MSTP is a distinct mode configured with the spanning-tree mode mst command and region parameters. MSTP tempts because it also converges rapidly, and would be correct where many VLANs must map onto a few shared topologies to reduce switch overhead.
C
The switch will use classic STP for all VLANs.
Why it fails: The command enables Rapid PVST+, which runs a separate 802.1w instance per VLAN; classic 802.1D STP is not selected. Classic STP tempts because it is the historical default on older switches, and would be the correct mode where legacy bridges require slow-converging 802.1D compatibility.
D
The switch will disable STP on all ports.
Why it fails: The command changes the spanning-tree protocol variant; it never disables STP, which would require no spanning-tree vlan commands. Disabling STP tempts because it removes blocking ports and speeds convergence, and would be chosen only on edge ports where loops are impossible by design.

Question 6mediummultiple choice

A company has a campus network with two distribution switches (DSW1 and DSW2) connected via a Layer 2 trunk. Each distribution switch connects to two access switches. Spanning Tree Protocol (STP) is running with default settings. Recently, a network administrator added a new access switch (ASW3) and connected it to both distribution switches. After the connection, network performance degraded significantly, and users in VLAN 10 reported intermittent connectivity. The administrator checked the logs and saw multiple TCN notifications. What is the most likely cause of the issue?

Trap 1: The new switch is not configured with the same VLANs as the…

A lack of identical VLAN configurations does not create loops; instead, it causes per-VLAN connectivity failures because traffic for missing VLANs is simply not forwarded. The switch can still run STP and maintain a loop-free topology for the VLANs it does carry. The described symptoms of broadcast storms and severe degradation are not consistent with a simple VLAN mismatch, which would affect only specific VLAN traffic.

Trap 2: The new switch has a lower bridge priority than the current root…

Setting a lower bridge priority makes the new switch more eligible to become the root bridge, but STP still ensures a loop-free environment regardless of which switch is root. The root bridge is a legitimate role, and changing it merely alters the topology paths, causing some traffic to take different routes. It would not by itself generate the broadcast storms or MAC flapping indicative of a Layer 2 loop, so this is not the cause.

Trap 3: The new switch has become the root bridge and is sending inferior…

The root bridge does not send inferior BPDUs; it sends superior BPDUs with a higher priority that other switches accept as the best. Becoming the root bridge is a normal condition and does not inherently create loops. This option is incorrect because it both mischaracterizes BPDU behavior and confuses a topology change with a loop, which is the actual cause.

A
The new switch is causing a Layer 2 loop due to redundant links without proper STP configuration.
A Layer 2 loop occurs when redundant paths exist without Spanning Tree Protocol actively blocking one of them. The new switch, if connected with multiple links to the distribution switches and STP disabled or misconfigured, will forward broadcast frames out all ports, causing a broadcast storm. This leads to severe symptoms such as high CPU utilization on all switches, MAC address table flapping, and complete network unavailability.
B
The new switch is not configured with the same VLANs as the distribution switches.
Why it fails: A lack of identical VLAN configurations does not create loops; instead, it causes per-VLAN connectivity failures because traffic for missing VLANs is simply not forwarded. The switch can still run STP and maintain a loop-free topology for the VLANs it does carry. The described symptoms of broadcast storms and severe degradation are not consistent with a simple VLAN mismatch, which would affect only specific VLAN traffic.
C
The new switch has a lower bridge priority than the current root bridge.
Why it fails: Setting a lower bridge priority makes the new switch more eligible to become the root bridge, but STP still ensures a loop-free environment regardless of which switch is root. The root bridge is a legitimate role, and changing it merely alters the topology paths, causing some traffic to take different routes. It would not by itself generate the broadcast storms or MAC flapping indicative of a Layer 2 loop, so this is not the cause.
D
The new switch has become the root bridge and is sending inferior BPDUs.
Why it fails: The root bridge does not send inferior BPDUs; it sends superior BPDUs with a higher priority that other switches accept as the best. Becoming the root bridge is a normal condition and does not inherently create loops. This option is incorrect because it both mischaracterizes BPDU behavior and confuses a topology change with a loop, which is the actual cause.

Question 7hardmultiple choice

A network engineer runs the following command on Switch SW3:

SW3# show spanning-tree vlan 30

VLAN0030 Spanning tree enabled protocol ieee Root ID Priority 24606 Address aabb.cc00.0400 Cost 12 Port 2 (GigabitEthernet0/2) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32798 (priority 32768 sys-id-ext 30) Address aabb.cc00.0500 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- ------------------------------ Gi0/1 Desg FWD 4 128.1 P2p Gi0/2 Root FWD 12 128.2 P2p Gi0/3 Desg FWD 4 128.3 P2p

Based on this output, what is the root path cost from SW3 to the root bridge for VLAN 30?

Trap 1: 4

The value 4 appears in the output as the individual cost assigned to interfaces Gi0/1 and Gi0/3, typically for 1 Gbps links. However, the question asks for the root path cost—the accumulated cost from this switch to the root bridge—which is listed in the Root ID section as 12. Confusing a per-port cost with the root path cost is a common error. The per-port cost only affects the calculation; it is not the final sum.

Trap 2: 16

The output contains no field with the value 16; it is not a port cost, a timer, or the root path cost. A test-taker might incorrectly guess 16 as a mid-range value, but STP costs are typically power-of-two-related (2, 4, 8, 16, 32, 64, etc.) depending on link speed, so 16 could theoretically be a port cost for a slower link, yet the output explicitly shows a root path cost of 12. Since the question asks for the value shown in the output, 16 is a distractor with no basis in the provided data.

Trap 3: 20

The spanning-tree output includes timers such as Max Age, Hello Time, and Forward Delay, which are expressed in seconds. In many Cisco outputs, Max Age has a default value of 20, and a candidate might mistake it for a cost metric. However, the root path cost is a dimensionless accumulated cost, not a timer. The correct cost is found in the Root ID section, not in the timer fields. Thus, 20 is a timer value, not the root path cost.

A
4
Why it fails: The value 4 appears in the output as the individual cost assigned to interfaces Gi0/1 and Gi0/3, typically for 1 Gbps links. However, the question asks for the root path cost—the accumulated cost from this switch to the root bridge—which is listed in the Root ID section as 12. Confusing a per-port cost with the root path cost is a common error. The per-port cost only affects the calculation; it is not the final sum.
B
12
The show spanning-tree command displays the Root ID section, which includes the bridge's own root path cost. In this output, the Cost field under Root ID is 12, indicating the total accumulated path cost from this switch to the root bridge. This metric is used for root port selection and is the correct answer. It is not a per-interface value but the sum of all outgoing port costs along the best path.
C
16
Why it fails: The output contains no field with the value 16; it is not a port cost, a timer, or the root path cost. A test-taker might incorrectly guess 16 as a mid-range value, but STP costs are typically power-of-two-related (2, 4, 8, 16, 32, 64, etc.) depending on link speed, so 16 could theoretically be a port cost for a slower link, yet the output explicitly shows a root path cost of 12. Since the question asks for the value shown in the output, 16 is a distractor with no basis in the provided data.
D
20
Why it fails: The spanning-tree output includes timers such as Max Age, Hello Time, and Forward Delay, which are expressed in seconds. In many Cisco outputs, Max Age has a default value of 20, and a candidate might mistake it for a cost metric. However, the root path cost is a dimensionless accumulated cost, not a timer. The correct cost is found in the Root ID section, not in the timer fields. Thus, 20 is a timer value, not the root path cost.

Question 8easymultiple choice

A network engineer runs the following command on Switch SW5:

SW5# show spanning-tree vlan 50

VLAN0050 Spanning tree enabled protocol ieee Root ID Priority 24626 Address aabb.cc00.0800 Cost 4 Port 1 (GigabitEthernet0/1) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32768 (priority 32768 sys-id-ext 50) Address aabb.cc00.0900 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- ------------------------------ Gi0/1 Root FWD 4 128.1 P2p Gi0/2 Desg FWD 4 128.2 P2p Gi0/3 Desg FWD 4 128.3 P2p Gi0/4 Altn BLK 4 128.4 P2p

Based on this output, how many ports are in the Forwarding state?

Trap 1: 1

Option 1 is incorrect because the spanning-tree output shows more than one port in the Forwarding state. Specifically, Gi0/1, Gi0/2, and Gi0/3 all report state FWD, so counting only a single forwarding port ignores two additional active interfaces. A single forwarding port would only be true if the other two were in Listening, Learning, or Blocking, which is not the case here.

Trap 2: 2

Option 2 is incorrect because the output reveals three interfaces, not two, are in the Forwarding state. While Gi0/1 and Gi0/2 might be easily noticed as forwarding, Gi0/3 is also in FWD state, and omitting it undercounts the forwarding ports on this switch. The actual count must include every non-blocking interface that is fully converged and passing traffic, which totals three.

Trap 3: 4

Option 4 is incorrect because Gi0/4 is not in the Forwarding state; the spanning-tree output clearly marks it as BLK (Blocking). A Blocking port does not forward user frames and only listens for BPDUs to maintain STP participation. Since Gi0/4 is blocked, counting it as a forwarding port would overstate the number of active forwarding interfaces, which remains three.

A
1
Why it fails: Option 1 is incorrect because the spanning-tree output shows more than one port in the Forwarding state. Specifically, Gi0/1, Gi0/2, and Gi0/3 all report state FWD, so counting only a single forwarding port ignores two additional active interfaces. A single forwarding port would only be true if the other two were in Listening, Learning, or Blocking, which is not the case here.
B
2
Why it fails: Option 2 is incorrect because the output reveals three interfaces, not two, are in the Forwarding state. While Gi0/1 and Gi0/2 might be easily noticed as forwarding, Gi0/3 is also in FWD state, and omitting it undercounts the forwarding ports on this switch. The actual count must include every non-blocking interface that is fully converged and passing traffic, which totals three.
C
3
Option 3 is correct. The `show spanning-tree` output for this VLAN/instance lists Gi0/1, Gi0/2, and Gi0/3 in the Forwarding (FWD) state, meaning these three ports are actively forwarding Ethernet frames. Gi0/4 is shown in the Blocking (BLK) state, so it is not forwarding user traffic. Therefore, exactly three ports are in the forwarding state, making answer 3 the correct choice.
D
4
Why it fails: Option 4 is incorrect because Gi0/4 is not in the Forwarding state; the spanning-tree output clearly marks it as BLK (Blocking). A Blocking port does not forward user frames and only listens for BPDUs to maintain STP participation. Since Gi0/4 is blocked, counting it as a forwarding port would overstate the number of active forwarding interfaces, which remains three.

Question 9easymultiple choice

A network engineer runs the following command on Switch SW4:

SW4# show spanning-tree vlan 40

VLAN0040 Spanning tree enabled protocol ieee Root ID Priority 24616 Address aabb.cc00.0600 Cost 8 Port 1 (GigabitEthernet0/1) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32768 (priority 32768 sys-id-ext 40) Address aabb.cc00.0700 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- ------------------------------ Gi0/1 Root FWD 8 128.1 P2p Gi0/2 Desg FWD 4 128.2 P2p Gi0/3 Desg FWD 4 128.3 P2p

Based on this output, which port is the root port?

Trap 1: GigabitEthernet0/2

GigabitEthernet0/2 is incorrect because its role is designated ('Desg'), not root. A designated port is the port on a segment that has the best path to the root bridge and is responsible for sending BPDUs to that segment; it is not the port that receives the root bridge's superior BPDUs. Thus, Gi0/2 cannot be SW4's root port.

Trap 2: GigabitEthernet0/3

GigabitEthernet0/3 is also incorrect because its role is designated ('Desg'). Like Gi0/2, it is the forwarding port for its attached segment, but it does not receive the best BPDU from the root bridge. The root port selection is based on lowest root path cost from received BPDUs, and Gi0/1 must have a lower cost than Gi0/3, making Gi0/3 a non-root designated port.

Trap 3: There is no root port because SW4 is the root bridge.

The statement that there is no root port because SW4 is the root bridge is false. The root bridge is identified by the lowest Bridge ID (priority + MAC address), and the spanning-tree output would show SW4 as the root only if its Bridge ID matched the root ID. Since Gi0/1 has a Root role, SW4 must be a non-root switch; the root bridge has no root ports, but all non-root bridges have exactly one.

A
GigabitEthernet0/1
GigabitEthernet0/1 is the root port on SW4. In STP, a non-root bridge selects the single port that receives the best (lowest-cost) BPDU from the root bridge, and that port is assigned the Root role. Because the output shows Gi0/1 with role 'Root', it is the path toward the root bridge, even though SW4 itself is not the root bridge.
B
GigabitEthernet0/2
Why it fails: GigabitEthernet0/2 is incorrect because its role is designated ('Desg'), not root. A designated port is the port on a segment that has the best path to the root bridge and is responsible for sending BPDUs to that segment; it is not the port that receives the root bridge's superior BPDUs. Thus, Gi0/2 cannot be SW4's root port.
C
GigabitEthernet0/3
Why it fails: GigabitEthernet0/3 is also incorrect because its role is designated ('Desg'). Like Gi0/2, it is the forwarding port for its attached segment, but it does not receive the best BPDU from the root bridge. The root port selection is based on lowest root path cost from received BPDUs, and Gi0/1 must have a lower cost than Gi0/3, making Gi0/3 a non-root designated port.
D
There is no root port because SW4 is the root bridge.
Why it fails: The statement that there is no root port because SW4 is the root bridge is false. The root bridge is identified by the lowest Bridge ID (priority + MAC address), and the spanning-tree output would show SW4 as the root only if its Bridge ID matched the root ID. Since Gi0/1 has a Root role, SW4 must be a non-root switch; the root bridge has no root ports, but all non-root bridges have exactly one.

Question 10mediummultiple choice

A network engineer is troubleshooting an STP issue in a switched network. The network has two distribution switches connected via a trunk, and each distribution switch connects to the same access switch. The engineer notices that the root bridge is not the intended distribution switch. Upon checking, the engineer sees that the access switch has a higher priority than the distribution switches. The engineer needs to ensure that the intended distribution switch becomes the root bridge without causing a temporary loop. What should the engineer do?

Trap 1: Set the priority of the access switch to 0 using the 'spanning-tree…

Setting the access switch's priority to 0 using `spanning-tree vlan vlan-id priority 0` would make it the root bridge because 0 is the lowest possible bridge priority, giving it precedence over all other switches in the VLAN. This is incorrect because the engineer wants the distribution switch to be the root, not the access switch. Additionally, forcing an access-layer switch to be root can cause suboptimal traffic forwarding, as all inter-VLAN traffic would need to traverse the access layer, which is not designed for such a role.

Trap 2: Increase the priority of the distribution switch to 61440 using the…

Increasing the distribution switch's priority to 61440 via `spanning-tree vlan vlan-id priority 61440` would make it less likely to become the root bridge, because a higher numeric priority value indicates a lower priority in STP. Since the root bridge is elected as the switch with the lowest priority (and bridge ID), setting the distribution switch to 61440 would actually push it toward the edge of the spanning tree topology. The engineer's goal is to make the distribution switch the root, so this command directly contradicts the intent and could result in an unexpected access switch becoming root.

Trap 3: Disable STP on the distribution switch and manually configure it as…

Disabling STP on the distribution switch removes its ability to participate in the dynamic root bridge election, but it does not manually configure it as the root bridge; a root bridge must still be elected through BPDUs, and without STP running, the switch will not advertise its bridge ID. Furthermore, disabling STP creates a serious risk of Layer 2 loops, which can cause broadcast storms, MAC address flapping, and network outages. Even if you could manually 'force' a root, this approach is unsafe and violates best practices; the correct way is to use STP commands that adjust the bridge priority or use the root primary macro.

A
Configure the 'spanning-tree vlan vlan-id root primary' command on the intended distribution switch.
The `spanning-tree vlan vlan-id root primary` command is a Cisco macro that forces the switch to become the root bridge by automatically setting its bridge priority to 24576, or to 4096 less than the current lowest priority if another switch already has a priority below 24576. This adjusts the priority dynamically without manual calculation, ensuring the intended distribution switch wins the root election. The command also configures the switch to be the primary root for that VLAN, which is exactly the desired outcome.
B
Set the priority of the access switch to 0 using the 'spanning-tree vlan vlan-id priority 0' command.
Why it fails: Setting the access switch's priority to 0 using `spanning-tree vlan vlan-id priority 0` would make it the root bridge because 0 is the lowest possible bridge priority, giving it precedence over all other switches in the VLAN. This is incorrect because the engineer wants the distribution switch to be the root, not the access switch. Additionally, forcing an access-layer switch to be root can cause suboptimal traffic forwarding, as all inter-VLAN traffic would need to traverse the access layer, which is not designed for such a role.
C
Increase the priority of the distribution switch to 61440 using the 'spanning-tree vlan vlan-id priority 61440' command.
Why it fails: Increasing the distribution switch's priority to 61440 via `spanning-tree vlan vlan-id priority 61440` would make it less likely to become the root bridge, because a higher numeric priority value indicates a lower priority in STP. Since the root bridge is elected as the switch with the lowest priority (and bridge ID), setting the distribution switch to 61440 would actually push it toward the edge of the spanning tree topology. The engineer's goal is to make the distribution switch the root, so this command directly contradicts the intent and could result in an unexpected access switch becoming root.
D
Disable STP on the distribution switch and manually configure it as the root bridge.
Why it fails: Disabling STP on the distribution switch removes its ability to participate in the dynamic root bridge election, but it does not manually configure it as the root bridge; a root bridge must still be elected through BPDUs, and without STP running, the switch will not advertise its bridge ID. Furthermore, disabling STP creates a serious risk of Layer 2 loops, which can cause broadcast storms, MAC address flapping, and network outages. Even if you could manually 'force' a root, this approach is unsafe and violates best practices; the correct way is to use STP commands that adjust the bridge priority or use the root primary macro.

Question 11mediummultiple choice

Consider the following configuration on a Cisco IOS-XE switch:

interface GigabitEthernet1/0/1
 switchport mode access

authentication port-control auto dot1x pae authenticator dot1x timeout tx-period 5

spanning-tree portfast

What is the effect of this configuration?

Trap 1: The port will immediately transition to forwarding state and then…

PortFast accelerates Spanning Tree Protocol convergence by moving the port into the forwarding state, but it does not bypass 802.1X authentication. With 'authentication port-control auto', the controlled port remains in the unauthorized state, blocking all user traffic until the supplicant completes EAP authentication. The port may be STP-forwarding, but the 802.1X controlled port will not forward data frames until successful authentication, so this statement conflates two independent mechanisms.

Trap 2: The port will be placed in a VLAN assigned by the RADIUS server…

Dynamic VLAN assignment by the RADIUS server requires a configured RADIUS server, a AAA method list, and the RADIUS server to return vendor-specific attributes such as Tunnel-Private-Group-ID to change the port VLAN. The given configuration fragment shows none of these elements, so there is no basis to conclude that a RADIUS-assigned VLAN will be used. Without such attributes or server configuration, the port would remain in its locally configured access VLAN after authentication, making this option unsupported by the evidence shown.

Trap 3: The switch will act as a supplicant and respond to EAP requests…

The switch configured with 'dot1x pae authenticator' is explicitly assigned the authenticator role, not the supplicant role. A supplicant would require 'dot1x pae supplicant', and would send EAPOL-Start and respond to EAP-Request/Identity from an upstream authenticator, such as when a switch is connected to a larger network and must prove itself. Since the configuration clearly sets the switch as the authenticator, it is responsible for authenticating downstream devices rather than responding to authentication requests from upstream devices, so this option contradicts the command's purpose.

A
The port will immediately transition to forwarding state and then wait for authentication.
Why it fails: PortFast accelerates Spanning Tree Protocol convergence by moving the port into the forwarding state, but it does not bypass 802.1X authentication. With 'authentication port-control auto', the controlled port remains in the unauthorized state, blocking all user traffic until the supplicant completes EAP authentication. The port may be STP-forwarding, but the 802.1X controlled port will not forward data frames until successful authentication, so this statement conflates two independent mechanisms.
B
The switch will act as an 802.1X authenticator and the port will be unauthorized until a successful authentication.
The 'dot1x pae authenticator' command configures the switch port to operate as the 802.1X authenticator, meaning it initiates and manages EAP exchanges with the connected client (supplicant). The 'authentication port-control auto' setting explicitly places the port in the unauthorized state initially, allowing only EAPOL traffic to flow. Only after the client successfully authenticates against the configured authentication method (e.g., RADIUS) does the controlled port transition to the authorized state and forward normal data traffic.
C
The port will be placed in a VLAN assigned by the RADIUS server after authentication.
Why it fails: Dynamic VLAN assignment by the RADIUS server requires a configured RADIUS server, a AAA method list, and the RADIUS server to return vendor-specific attributes such as Tunnel-Private-Group-ID to change the port VLAN. The given configuration fragment shows none of these elements, so there is no basis to conclude that a RADIUS-assigned VLAN will be used. Without such attributes or server configuration, the port would remain in its locally configured access VLAN after authentication, making this option unsupported by the evidence shown.
D
The switch will act as a supplicant and respond to EAP requests from an upstream authenticator.
Why it fails: The switch configured with 'dot1x pae authenticator' is explicitly assigned the authenticator role, not the supplicant role. A supplicant would require 'dot1x pae supplicant', and would send EAPOL-Start and respond to EAP-Request/Identity from an upstream authenticator, such as when a switch is connected to a larger network and must prove itself. Since the configuration clearly sets the switch as the authenticator, it is responsible for authenticating downstream devices rather than responding to authentication requests from upstream devices, so this option contradicts the command's purpose.

Question 12mediummultiple choice

A network engineer runs the following command on Switch SW1:

SW1# show spanning-tree vlan 10

VLAN0010 Spanning tree enabled protocol ieee Root ID Priority 32778 Address 0011.2233.4455 Cost 19 Port 1 (GigabitEthernet0/1) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32778 (priority 32768 sys-id-ext 10) Address 0011.2233.4466 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- -------------------------------- Gi0/1 Root FWD 19 128.1 P2p Gi0/2 Altn BLK 19 128.2 P2p

Based on this output, what can be concluded?

Trap 1: The local switch is the root bridge for VLAN 10

The output clearly distinguishes the Root ID from the local switch's Bridge ID. The Root ID lists the MAC address 0011.2233.4455, while the Bridge ID for the local switch is 0011.2233.4466, which is a higher MAC address. Since STP elects the root bridge by the lowest bridge ID, a different MAC address confirms the local switch is not that root.

Trap 2: Interface Gi0/2 is in a forwarding state

The interface status in the show spanning-tree output lists Gi0/2 as BLK, which stands for blocking. A blocking port does not forward user traffic; it only listens for BPDUs and is prevented from causing loops. This is distinct from the forwarding state, where the port sends and receives frames. Thus, claiming Gi0/2 is in a forwarding state directly contradicts the output.

Trap 3: The spanning-tree mode is Rapid PVST+

The command output displays 'protocol ieee', which denotes the original IEEE 802.1D STP, not Rapid PVST+. Rapid PVST+ would still show 'protocol ieee' but with additional RSTP-specific port roles such as Alternate and Backup, and it might include timing characteristics like Uptime and Port State based on RSTP. In this output, the only states shown are BLK and FWD, which match 802.1D STP, not the RSTP-based states or roles. Therefore, the spanning-tree mode cannot be Rapid PVST+.

A
The local switch is the root bridge for VLAN 10
Why it fails: The output clearly distinguishes the Root ID from the local switch's Bridge ID. The Root ID lists the MAC address 0011.2233.4455, while the Bridge ID for the local switch is 0011.2233.4466, which is a higher MAC address. Since STP elects the root bridge by the lowest bridge ID, a different MAC address confirms the local switch is not that root.
B
The local switch is not the root bridge for VLAN 10
This is the correct inference from the spanning-tree output. The Root ID field shows a MAC address of 0011.2233.4455, whereas the local switch's Bridge ID uses 0011.2233.4466, so they are different. In STP, a switch knows it is not the root when its own bridge ID does not match the Root ID. Therefore, the local switch must be a non-root switch, and it will have a root port selected toward the root bridge.
C
Interface Gi0/2 is in a forwarding state
Why it fails: The interface status in the show spanning-tree output lists Gi0/2 as BLK, which stands for blocking. A blocking port does not forward user traffic; it only listens for BPDUs and is prevented from causing loops. This is distinct from the forwarding state, where the port sends and receives frames. Thus, claiming Gi0/2 is in a forwarding state directly contradicts the output.
D
The spanning-tree mode is Rapid PVST+
Why it fails: The command output displays 'protocol ieee', which denotes the original IEEE 802.1D STP, not Rapid PVST+. Rapid PVST+ would still show 'protocol ieee' but with additional RSTP-specific port roles such as Alternate and Backup, and it might include timing characteristics like Uptime and Port State based on RSTP. In this output, the only states shown are BLK and FWD, which match 802.1D STP, not the RSTP-based states or roles. Therefore, the spanning-tree mode cannot be Rapid PVST+.

Question 13hardmultiple choice

A network engineer runs the following command on Switch SW2:

SW2# show spanning-tree vlan 10

VLAN0010 Spanning tree enabled protocol ieee Root ID Priority 32778 Address aabb.cc00.0100 Cost 19 Port 1 (GigabitEthernet0/1) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32778 (priority 32768 sys-id-ext 10) Address aabb.cc00.0200 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- -------------------------------- Gi0/1 Root FWD 19 128.1 P2p Gi0/2 Altn BLK 19 128.2 P2p Gi0/3 Desg FWD 19 128.3 P2p

Based on this output, what can be concluded?

Trap 1: SW2 is the root bridge for VLAN 10.

SW2 cannot be the root bridge for VLAN 10 because it has a root port (Gi0/1); a root bridge has no root port and all of its ports are designated. The Root ID in the output shows a specific MAC address (aabb.cc00.0100) as the root, which would be SW2's own MAC if SW2 were root. Since the Bridge ID for SW2 would differ, SW2 is a non-root switch forwarding toward that root.

Trap 2: Port Gi0/2 is in forwarding state.

Port Gi0/2 is labeled 'Altn BLK' in the output, meaning it is an alternate port in the blocking state. Alternate ports are backups to the root port and are deliberately placed in blocking to prevent L2 loops, receiving more-superior BPDUs from another neighbor. They do not forward traffic unless the root port fails, so Gi0/2 is not currently forwarding.

Trap 3: The STP priority for VLAN 10 is 32768.

The STP priority for VLAN 10 is displayed as 32778, not 32768, because the bridge ID priority field carries both the configurable base priority (32768) and the extended system ID of 10 for VLAN 10. On PVST+ switches, the 12-bit extended system ID is appended to the 4-bit priority, so the effective numeric priority becomes base + VLAN number. Saying 32768 ignores that VLAN component and misreads the bridge ID that STP uses for root election.

A
SW2 is the root bridge for VLAN 10.
Why it fails: SW2 cannot be the root bridge for VLAN 10 because it has a root port (Gi0/1); a root bridge has no root port and all of its ports are designated. The Root ID in the output shows a specific MAC address (aabb.cc00.0100) as the root, which would be SW2's own MAC if SW2 were root. Since the Bridge ID for SW2 would differ, SW2 is a non-root switch forwarding toward that root.
B
The root bridge for VLAN 10 has MAC address aabb.cc00.0100.
The Root ID field in the spanning-tree output announces the root bridge's identifier, and it lists aabb.cc00.0100 as the root MAC for VLAN 10. STP elects the root based on the lowest bridge ID, and this MAC belongs to whichever switch has won that election for this VLAN. Therefore the root bridge for VLAN 10 is the switch with that MAC address, not the local switch.
C
Port Gi0/2 is in forwarding state.
Why it fails: Port Gi0/2 is labeled 'Altn BLK' in the output, meaning it is an alternate port in the blocking state. Alternate ports are backups to the root port and are deliberately placed in blocking to prevent L2 loops, receiving more-superior BPDUs from another neighbor. They do not forward traffic unless the root port fails, so Gi0/2 is not currently forwarding.
D
The STP priority for VLAN 10 is 32768.
Why it fails: The STP priority for VLAN 10 is displayed as 32778, not 32768, because the bridge ID priority field carries both the configurable base priority (32768) and the extended system ID of 10 for VLAN 10. On PVST+ switches, the 12-bit extended system ID is appended to the 4-bit priority, so the effective numeric priority becomes base + VLAN number. Saying 32768 ignores that VLAN component and misreads the bridge ID that STP uses for root election.

Question 14mediummultiple choice

A network engineer runs the following command on Switch SW1:

SW1# show spanning-tree vlan 10

VLAN0010 Spanning tree enabled protocol ieee Root ID Priority 32778 Address 0011.2233.4455 Cost 19 Port 1 (GigabitEthernet0/1) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32778 (priority 32768 sys-id-ext 10) Address 0011.2233.4466 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec

Interface           Role Sts Cost      Prio.Nbr Type

------------------- ---- --- --------- -------- -------------------------------- Gi0/1 Root FWD 19 128.1 P2p Gi0/2 Altn BLK 19 128.2 P2p Gi0/3 Desg FWD 19 128.3 P2p

Based on this output, what can be concluded?

Trap 1: SW1 is the root bridge for VLAN 10.

SW1 cannot be the root bridge for VLAN 10 because the root bridge election is decided by the lowest bridge ID, and bridge IDs are compared first by priority and then by MAC address. In this topology, both SW1 and the actual root bridge have the same priority of 32778, so the switch with the lower MAC address, 0011.2233.4455, wins that election. Since SW1's MAC address is 0011.2233.4466, which is higher, SW1 is not the root bridge; instead, SW1 has a root port toward the true root and a blocking alternate port, neither of which would exist on the root bridge.

Trap 2: Gi0/3 is a root port.

Gi0/3 is not a root port because its role in the spanning tree is designated, meaning SW1 is the designated bridge for the segment connected to that interface and is responsible for forwarding BPDUs to that segment. A root port, by contrast, is the single port on a switch that provides the shortest path to the root bridge, and it always remains in forwarding state. Since Gi0/3 has a designated role, it does not satisfy the requirement of being the port with the lowest root path cost, and the actual root port on SW1 is a different interface.

Trap 3: The root bridge has a higher priority than SW1.

The claim that the root bridge has a higher priority than SW1 is incorrect because both switches use the same bridge priority value of 32768 plus the VLAN 10 extended system ID, resulting in 32778. In STP, a numerically lower priority is considered better, so a higher numeric priority would actually make a switch less likely to become the root bridge. Since the priorities are equal, the root bridge is determined by the lower MAC address, and the root bridge's MAC address (0011.2233.4455) is lower than SW1's, not its priority.

A
SW1 is the root bridge for VLAN 10.
Why it fails: SW1 cannot be the root bridge for VLAN 10 because the root bridge election is decided by the lowest bridge ID, and bridge IDs are compared first by priority and then by MAC address. In this topology, both SW1 and the actual root bridge have the same priority of 32778, so the switch with the lower MAC address, 0011.2233.4455, wins that election. Since SW1's MAC address is 0011.2233.4466, which is higher, SW1 is not the root bridge; instead, SW1 has a root port toward the true root and a blocking alternate port, neither of which would exist on the root bridge.
B
Gi0/2 is in blocking state due to loop prevention.
Gi0/2 is correctly placed in blocking state because Spanning Tree Protocol designates it as an alternate port, which functions as a redundant path to the root bridge that is less optimal than the root port. This blocking state is intentional loop prevention; if Gi0/2 were allowed to forward, it would create a Layer 2 forwarding loop in the switched topology. The alternate port role is typical in networks with redundant links and does not indicate a failure or misconfiguration.
C
Gi0/3 is a root port.
Why it fails: Gi0/3 is not a root port because its role in the spanning tree is designated, meaning SW1 is the designated bridge for the segment connected to that interface and is responsible for forwarding BPDUs to that segment. A root port, by contrast, is the single port on a switch that provides the shortest path to the root bridge, and it always remains in forwarding state. Since Gi0/3 has a designated role, it does not satisfy the requirement of being the port with the lowest root path cost, and the actual root port on SW1 is a different interface.
D
The root bridge has a higher priority than SW1.
Why it fails: The claim that the root bridge has a higher priority than SW1 is incorrect because both switches use the same bridge priority value of 32768 plus the VLAN 10 extended system ID, resulting in 32778. In STP, a numerically lower priority is considered better, so a higher numeric priority would actually make a switch less likely to become the root bridge. Since the priorities are equal, the root bridge is determined by the lower MAC address, and the root bridge's MAC address (0011.2233.4455) is lower than SW1's, not its priority.

Question 15mediummultiple choice

A network engineer runs the following command on Switch SW5:

SW5# show running-config | section interface port-channel
interface Port-channel1
 switchport mode trunk
 switchport trunk allowed vlan 1-100,200-300

interface Port-channel2
 switchport mode access
 switchport access vlan 10

SW5# show interfaces trunk

Port Mode Encapsulation Status Native vlan Po1 on 802.1q trunking 1

Port Vlans allowed on trunk Po1 1-100,200-300

Port Vlans allowed and active in management domain Po1 1-100,200-300

Port Vlans in spanning tree forwarding state and not pruned Po1 1-100,200-300

Based on this output, what can be concluded?

Trap 1: Port-channel2 is also trunking but not displayed due to a software…

Port-channel2 is configured as an access port, not a trunk, so it is intentionally omitted from the 'show interfaces trunk' output. The command only displays interfaces operating in trunking mode, and there is no software bug that would hide a trunk. Therefore, the absence of Port-channel2 from the output is accurate and does not indicate a hidden trunking interface.

Trap 2: Port-channel1 is trunking and allowed VLANs include VLANs 101-199.

The allowed VLAN list for Port-channel1 explicitly includes VLANs 1 through 100 and VLANs 200 through 300, which means VLANs 101 through 199 are pruned and not forwarded across the trunk. Claiming that VLANs 101-199 are included is factually incorrect. The output unambiguously shows that these VLANs are excluded from the trunk's allowed VLAN list, so this answer misreads the displayed range.

Trap 3: The native VLAN on Po1 is VLAN 10.

The native VLAN displayed for Port-channel1 is VLAN 1, which is the default native VLAN on Cisco switches, not VLAN 10. The 'show interfaces trunk' output clearly lists 'Native VLAN: 1' for Port-channel1, so any assertion that it is VLAN 10 is incorrect. This option likely confuses the native VLAN with the access VLAN of a different interface or a misremembered configuration value.

A
Port-channel2 is also trunking but not displayed due to a software bug.
Why it fails: Port-channel2 is configured as an access port, not a trunk, so it is intentionally omitted from the 'show interfaces trunk' output. The command only displays interfaces operating in trunking mode, and there is no software bug that would hide a trunk. Therefore, the absence of Port-channel2 from the output is accurate and does not indicate a hidden trunking interface.
B
Port-channel1 is trunking and allowed VLANs include VLANs 101-199.
Why it fails: The allowed VLAN list for Port-channel1 explicitly includes VLANs 1 through 100 and VLANs 200 through 300, which means VLANs 101 through 199 are pruned and not forwarded across the trunk. Claiming that VLANs 101-199 are included is factually incorrect. The output unambiguously shows that these VLANs are excluded from the trunk's allowed VLAN list, so this answer misreads the displayed range.
C
Port-channel1 is operational as a trunk with the configured allowed VLANs.
The output confirms Port-channel1 is in trunking mode, is operationally up, and its allowed VLAN list matches the configured VLANs of 1-100 and 200-300. The 'show interfaces trunk' command verifies that the port-channel is carrying traffic for the exact set of VLANs that were configured, with no unexpected additions or removals. This matches the correct operational state expected for a properly configured EtherChannel trunk.
D
The native VLAN on Po1 is VLAN 10.
Why it fails: The native VLAN displayed for Port-channel1 is VLAN 1, which is the default native VLAN on Cisco switches, not VLAN 10. The 'show interfaces trunk' output clearly lists 'Native VLAN: 1' for Port-channel1, so any assertion that it is VLAN 10 is incorrect. This option likely confuses the native VLAN with the access VLAN of a different interface or a misremembered configuration value.