VLAN practice questions

Change the port type of Gi0/3 to trunk to allow multiple VLANs.

Why wrong: Configuring Gi0/3 as a trunk only affects VLAN tagging and the set of VLANs carried, not the STP port role. The blocking state indicates an STP decision—likely that the current root bridge has a higher bridge priority than another switch for VLAN 10—so the port cannot forward even after trunk mode is set. Trunking would be relevant if VLANs were being pruned, but it cannot change the root bridge election or port cost calculations.

Configure spanning-tree portfast on Gi0/3 to speed up convergence.

Why wrong: Portfast is intended solely for access ports connected to end stations, allowing them to bypass the listening and learning states to converge quickly. Applying it to an inter-switch uplink like Gi0/3 is dangerous because it could create a temporary bridging loop during STP recalculation. Even if Portfast were enabled, the port would still block after the switch receives the superior BPDU that elected another switch as root; it only skips the forward-delay timers, not the STP decision itself.

Enable BPDU guard on Gi0/3 to prevent unauthorized switches from affecting the network.

Why wrong: BPDU guard is an STP protection feature typically enabled on PortFast-configured access ports; when it receives a BPDU, it disables the port to prevent rogue switches. On an uplink connecting two switches, BPDUs are expected and necessary for STP operation, so enabling BPDU guard would shut down Gi0/3 and disrupt the link entirely. It does nothing to influence root bridge selection or why Gi0/3 is in a blocking state, since that state is determined by root bridge priorities and path costs.

Check the DHCP server logs to see if it is receiving Discover messages.

Why wrong: Checking the DHCP server logs for Discover messages is premature in this scenario. Because the DHCP server resides on a different subnet than the clients, server-side logs will only show Discover packets if the router's VLAN 20 interface has an IP helper-address configured to forward broadcast DHCP requests. If the helper-address is missing, the router drops the broadcast at the VLAN boundary, and the server never sees any Discover traffic—so the absence of such messages in the logs would merely confirm the relay misconfiguration, not diagnose it. This step is valid only after confirming that the relay configuration is correct, and it wastes troubleshooting time by skipping the most fundamental cause.

Attempt to ping the DHCP server's IP address from the host's APIPA address.

Why wrong: The host's APIPA address (169.254.x.x) is a link-local address. Without a default gateway or a routable IP, pinging an address on a different subnet will not work, even if the DHCP server is reachable. This test does not confirm DHCP functionality and is not a standard troubleshooting step for DHCP failures.

Restart the DHCP service on the server and recheck the host.

Why wrong: Restarting the DHCP service is a disruptive action and should not be the first step, especially when the root cause likely lies in the network configuration (missing relay). It does not address the underlying issue and may cause unnecessary downtime.

The default gateway must be removed from the DHCP scope.

Why wrong: Removing the default gateway from the DHCP scope would eliminate the router as the next hop, breaking all off-subnet communication. The problem is isolated to hostname resolution while IP connectivity succeeds, so a missing gateway would cause total network failure, not just DNS failure. Therefore, the default gateway must remain in the scope and cannot be the cause.

The clients must use PPP before DNS works.

Why wrong: PPP (Point-to-Point Protocol) is a WAN data-link encapsulation used on serial or DSL links, not a service required for DNS on an Ethernet LAN. DNS resolution operates over IP and is independent of the data-link protocol; clients do not need PPP to send DNS queries. This option incorrectly conflates a WAN technology with local DHCP operation and is unrelated to the VLAN 70 issue.

The VLAN must be converted to the native VLAN on all trunks.

Why wrong: The native VLAN in 802.1Q trunks carries untagged frames; changing VLAN 70 to native would affect trunk tagging and could cause broadcast or misdelivery issues. However, the symptom is specifically that clients reach services by IP but not by hostname, indicating a DNS problem, not a Layer 2 forwarding issue. If the native VLAN were misconfigured, general connectivity would fail, not just name resolution.

The static route for 10.10.20.0/24 is missing from the routing table.

Why wrong: The routing table entry for 10.10.20.0/24 is visible in the output, showing 'via 10.10.10.2', so the static route is certainly not missing. This option misreads the table; the missing entry is actually the default route (0.0.0.0/0), not the static route to the 10.10.20.0 network. The presence of this specific static route does not affect the default route's reachability, which is the real issue.

The GigabitEthernet0/0 interface is administratively down.

Why wrong: The interface status in the exhibit is 'up/up' with IP address 10.10.10.1, and the connected route for 10.10.10.0/24 is present in the routing table. An administratively down interface would be 'shutdown' and would remove all connected routes, including the subnet that contains the next-hop. Since the next-hop is unreachable despite the interface being up, the problem lies with the remote router or Layer 2 connectivity, not the local interface state.

The default route is not configured; the gateway of last resort is missing.

Why wrong: The output includes the line 'Gateway of last resort is 10.10.10.2 to network 0.0.0.0', proving that a default route is configured and the router recognizes it as the gateway of last resort. However, the default route does not appear as an 'S*' entry in the routing table because the next-hop is unreachable. This option incorrectly assumes that the configuration is missing; in reality, the route is configured but not installed.

interface GigabitEthernet0/1 switchport mode trunk switchport trunk allowed vlan 10 interface GigabitEthernet0/2 switchport mode trunk switchport trunk allowed vlan 20 end show interfaces trunk

Why wrong: This is incorrect because trunk ports are used to carry multiple VLANs between switches, not to connect end devices like PCs and servers. Access ports should be used instead.

vlan 10 name PC_VLAN vlan 20 name Server_VLAN interface GigabitEthernet0/1 switchport mode access switchport access vlan 10 interface GigabitEthernet0/2 switchport mode access switchport access vlan 20 end show vlan brief

Why wrong: This is incorrect because it includes unnecessary VLAN creation and naming steps. While not harmful, the question only asks to assign ports to VLANs, not to create or name them. However, the main issue is that the configuration is valid but not minimal; the question expects only the required commands.

interface GigabitEthernet0/1 switchport access vlan 10 interface GigabitEthernet0/2 switchport access vlan 20 end show vlan brief

Why wrong: This is incorrect because it omits the 'switchport mode access' command. Without setting the port mode to access, the port may default to dynamic desirable or trunk mode, which could cause issues with VLAN assignment.

Increase the bridge priority on SW2 for VLAN 40.

Why wrong: Increasing the bridge priority on SW2 for VLAN 40 would assign a higher numeric priority value, making it less likely to become the root bridge for that VLAN. However, the root bridge election only determines the spanning-tree topology; it does not alter the fixed forward-delay timers of PVST+ that cause the 30-second reconvergence. Even if SW2 were the root, PVST+ still requires listening and learning delays, whereas Rapid PVST+ eliminates that delay via Proposal/Agreement. The correct fix is to switch the entire stack to Rapid PVST+, not to manipulate root priority.

Disable PortFast on all access ports.

Why wrong: Disabling PortFast on all access ports would force every host-facing port to spend 30 seconds in listening and learning states after any link event, making client connectivity worse. PortFast is designed only for edge ports and has no effect on the convergence of an inter-switch trunk when an uplink flaps. The 30-second outage on VLAN 40 stems from the root port transition on SW2's trunk, not from access port behavior, so this change would be counterproductive.

Convert the uplink to a routed port.

Why wrong: Converting the uplink to a routed port would eliminate Layer 2 spanning tree on that segment, but it would also terminate the VLAN 40 broadcast domain and require IP addressing on the links. This fundamentally changes the network design and does not address the STP reconvergence delay that occurs when the Layer 2 uplink flaps. The exhibit clearly indicates an STP mode mismatch, not a need for Layer 3 switching, so this is not a valid corrective action.

The trunk must be converted to an access port for VLAN 20 to work.

Why wrong: An access port is designed to carry a single untagged VLAN, so converting the trunk to an access port would force it to carry only the VLAN assigned as the access VLAN, such as VLAN 20. This would drop the tags for VLANs 10 and 30, making them unreachable across the link, which defeats the purpose of a trunk that must carry all three VLANs. Furthermore, trunk ports are the standard mechanism for inter-switch multi-VLAN traffic, and a misconfigured allowed list is a filtering problem, not a port-mode problem.

VLAN 20 must always be the native VLAN.

Why wrong: The native VLAN on an 802.1Q trunk is the VLAN that is transmitted without an 802.1Q tag; it is an untagged path used for control traffic and for devices that do not support VLAN tagging. VLAN 20 can be carried either as a tagged VLAN or as the native VLAN, but setting it as native would simply change the tagging behavior, not the allowed list. If VLAN 20 is missing from the allowed list, even untagged frames for the native VLAN will not be forwarded. Thus, native VLAN assignment is independent from the VLAN membership filtering issue.

The switches must both use ISL instead of 802.1Q.

Why wrong: ISL and 802.1Q are different trunking encapsulations; both use their own tagging format and both are capable of carrying VLAN 20 across a trunk. The problem described is that VLAN 20 is not in the allowed list on one side, which is a VLAN filter applied at the interface level regardless of the encapsulation protocol. Even if both switches were configured for ISL, the missing VLAN would still be omitted from the allowed list, so the traffic would still be blocked. Additionally, most Cisco switches today default to 802.1Q, and mixing encapsulations would break the trunk entirely.

All tagged VLAN traffic is automatically converted to routed traffic

Why wrong: A native VLAN mismatch does not alter the fundamental operation of a trunk link, which remains a Layer 2 forwarding path. The 802.1Q tag is still applied to frames from all non-native VLANs, and those frames are switched based on MAC addresses exactly as they would be with a correctly configured trunk. There is no mechanism that converts tagged VLAN traffic into routed traffic; routing would only occur if the frames are sent to a Layer 3 interface, which is a separate configuration unrelated to trunk native VLAN settings.

The mismatch forces OSPF adjacency reset on all routers

Why wrong: A native VLAN mismatch is a Layer 2 trunking misconfiguration; it directly affects only how untagged frames are interpreted on the trunk. OSPF adjacency is a Layer 3 routing process that relies on IP reachability and multicast hello packets, not on the native VLAN assignment of a trunk. While an IP connectivity issue could indirectly cause OSPF neighbors to go down, the mismatch itself does not force an OSPF adjacency reset on any router, and OSPF has no mechanism that reacts specifically to trunk native VLAN mismatches.

The trunk can carry only one VLAN until the mismatch is cleared

Why wrong: An 802.1Q trunk is designed to carry multiple VLANs simultaneously by adding a 4-byte tag to frames from all VLANs except the native VLAN. When a native VLAN mismatch exists, the untagged frames on the native VLAN are mishandled, but frames from other VLANs remain correctly tagged and continue to traverse the trunk normally. Therefore the trunk does not become limited to a single VLAN; it continues to transport all configured tagged VLANs, and only the untagged native VLAN traffic is subject to misassociation.

The interface received a superior BPDU and became the root port.

Why wrong: STP role changes like becoming a root port occur when a superior BPDU is received, but that event would be reflected in spanning-tree state transitions and forwarding behavior, not in a security intrusion log. A hub does not originate BPDUs, and the error message clearly identifies a port-security violation rather than an STP topology change. Therefore, the interface's down state is due to security enforcement, not a spanning-tree decision.

The hub forced the interface to become a routed port.

Why wrong: A hub is a Layer 1 device that simply forwards electrical signals, so it cannot change the logical mode of a switch interface. A routed port is created only by explicitly removing Layer 2 switching with the "no switchport" command, which is not shown here. The log message references a port-security violation, not a change in interface mode.

DHCP snooping always shuts a port when a hub is attached.

Why wrong: DHCP snooping filters DHCP messages based on whether a port is trusted or untrusted; it does not count MAC addresses or react to the simple attachment of a hub. A hub only extends the collision domain, and it does not generate DHCP traffic or cause a DHCP snooping violation by itself. The exhibit shows a port-security restriction on secure MAC addresses, not any DHCP-related action.

Replace the faulty Ethernet cable between the switch and the workstation.

Why wrong: Replacing the Ethernet cable is unlikely to resolve the issue because physical-layer faults such as a damaged cable typically produce observable error counters on the interface—for example, CRC errors, runts, giants, or interface resets. The described output does not report any of these increments, and the interface remains up/up; instead, the symptoms align with a logical Layer 1/2 configuration problem. A duplex mismatch does not generate CRC errors but causes late collisions and excessive deferrals, which are not corrected by swapping the cable.

Assign the switch port to the correct VLAN.

Why wrong: Assigning the switch port to the correct VLAN is not a valid fix because VLAN misconfiguration typically produces a total loss of connectivity rather than a gradual performance degradation—the workstation would fail to reach its default gateway or other subnets, and DHCP would likely fail. The interface in question is up/up and passing traffic, which indicates the port is already in an operational VLAN and layer 2 forwarding is working. Without evidence of unreachable peers or a VLAN membership mismatch in the output, this option does not address the observed symptom.

Disable spanning-tree on the port to prevent frequent topology changes.

Why wrong: Disabling spanning-tree on the port is incorrect because Spanning Tree Protocol (STP) itself does not cause slow throughput when the port is stable in the forwarding state. STP issues manifest as port flapping, listening/learning transitions, or err-disabled states, none of which appear in a show interface output that reports up/up. Frequent topology changes would be reflected in incrementing Topology Change Notification (TCN) counters, not in a persistent slow performance, so disabling STP would be both unnecessary and potentially harmful by enabling forwarding loops.

Because allowing a VLAN on a trunk automatically disables it

Why wrong: The command 'switchport trunk allowed vlan add 99' merely adds VLAN 99 to the list of VLANs whose tagged frames may traverse the trunk. This does not disable the VLAN; in fact, it explicitly permits it. A VLAN is disabled by using the 'no vlan 99' to remove it or 'shutdown vlan 99' to administratively bring it down. Thus, allowing a VLAN on a trunk never automatically disables it; the two operations are completely independent.

Because VLANs can cross trunks only when PAT is enabled

Why wrong: PAT (Port Address Translation) is a Network Address Translation technique that maps multiple private IP addresses to a single public IP address for outbound Internet traffic. Trunk operation is a Layer 2 function where 802.1Q tags in Ethernet frames identify different VLANs as they traverse a trunk link. PAT has no relationship to Layer 2 VLAN tagging or carriage across a trunk. VLANs cross trunks purely via 802.1Q or ISL encapsulation, not through PAT or any other Layer 3 translation mechanism.

Because VLAN 99 must always be the native VLAN

Why wrong: The native VLAN is a special VLAN on an 802.1Q trunk that carries its frames untagged, typically configured with 'switchport trunk native vlan <vlan-id>'. There is no requirement that VLAN 99 be the native VLAN; any VLAN can be configured as native, and any VLAN can be carried across a trunk as a tagged VLAN. If VLAN 99 is not the native VLAN, it simply sends and receives 802.1Q-tagged frames. Therefore, needing VLAN 99 to be the native VLAN is a misconception; its operability depends on it being defined and active, not on its native status.

A NAT rule translating IPv6 to IPv4

Why wrong: IPv6 was designed to restore end-to-end connectivity without relying on NAT; in normal native IPv6 environments, routing uses global unicast addresses directly. A NAT rule that translates IPv6 to IPv4 would be an unnecessary and complex workaround, and it would not help the host reach off-link IPv6 destinations unless that IPv4 path itself is routed. Since the host already reaches neighbors using IPv6, the missing element is not address translation but a route to a default gateway.

A VLAN trunk on the host NIC

Why wrong: VLAN trunking is a Layer 2 feature used to carry multiple VLANs over a single switch link, typically between switches or to a router-on-a-stick. An end host NIC rarely requires trunking, and the symptom described is unrelated to VLAN tagging because it concerns Layer 3 reachability. Even if the NIC were configured with a trunk, that would not provide a default route or next hop for off-link IPv6 packets.

A second global unicast address on the same interface

Why wrong: Adding a second global unicast address to the same interface only provides an additional source or destination identifier for that interface; it does not install any route or gateway information into the host's IPv6 routing table. The host still lacks a default route for off-link traffic, and the existing address already satisfies the requirement of having a valid IPv6 source address. Therefore, a duplicate address does not solve the described reachability problem.

The SSID broadcast setting, because the client must not be joined correctly.

Why wrong: The SSID broadcast setting only controls whether the network name appears in probe responses, not whether an already-associated client can send or receive traffic. Because the client successfully joined and pulled an address from the correct subnet, it is not a join failure. If broadcast were disabled, the client would still be able to connect if it manually knew the SSID, and would not explain an application-specific issue.

The voice VLAN on the wired access port connected to the AP uplink.

Why wrong: The voice VLAN on the wired access port is used to separate VoIP traffic from data traffic on the wired infrastructure, and it does not affect how a wireless client forwards traffic after joining a WLAN. A client that has already received an address from the correct subnet is clearly operating on the data VLAN, not the voice VLAN, and general employee access works correctly. Since the problem is restricted to one application, changing the voice VLAN setting on the AP uplink would have no bearing on this scenario.

The OSPF router ID on the client device.

Why wrong: OSPF router IDs are used by routers participating in OSPF to identify themselves in link-state advertisements; end-client devices such as laptops or phones do not run OSPF and never exchange routing protocol information with the network. A client's network stack obtains an address via DHCP and uses a default gateway for off-subnet traffic, so OSPF router ID is irrelevant. The application-specific failure cannot be caused by a parameter that does not exist on the client device.

The root bridge election failed, causing a loop.

Why wrong: The root bridge did not fail; SwitchC is the correctly elected root for VLAN 10 based on the lowest bridge priority and MAC address. A failed root election would cause all switches to claim root status and generate BPDU storms, not a single port being placed into err-disabled state. The actual cause is BPDU Guard, which administratively disables the port upon receiving an unexpected BPDU.

Rapid PVST+ is not compatible with PortFast.

Why wrong: Rapid PVST+ fully supports PortFast as a per-port enhancement. PortFast bypasses the listening and learning states but does not disable spanning-tree operation; it is designed for access ports that connect end hosts. Therefore, claiming that Rapid PVST+ and PortFast are incompatible is incorrect; they are commonly used together in enterprise campus networks.

The port is configured as a trunk but should be an access port.

Why wrong: The interface is configured as an access port using 'switchport mode access', so the premise of this option is false. BPDU Guard is independent of trunk or access mode; it is tied to PortFast, and it will shut down the port regardless of the port mode if a BPDU is received. Therefore, the problem is not a misconfigured trunk but the intentional BPDU Guard protection triggered by an unexpected BPDU.

STP manages VLANs, VTP prevents loops, EtherChannel restricts MAC addresses, Port Security aggregates links, DTP provides fast per-VLAN convergence, and Rapid PVST+ negotiates trunks.

Why wrong: This option assigns each feature another feature's job: STP is given VLAN management (VTP's role), VTP is given loop prevention (STP's role), EtherChannel is given MAC address restriction (Port Security's role), Port Security is given link aggregation (EtherChannel's role), DTP is given fast per-VLAN convergence (Rapid PVST+), and Rapid PVST+ is given trunk negotiation (DTP). Since none of the features are matched with their actual purpose, the mapping is completely invalid.

STP aggregates links, VTP prevents loops, EtherChannel manages VLANs, Port Security negotiates trunks, DTP restricts MAC addresses, and Rapid PVST+ provides fast per-VLAN convergence.

Why wrong: This option mixes up five of the six features: STP is incorrectly said to aggregate links (EtherChannel's role), VTP is incorrectly said to prevent loops (STP's role), EtherChannel is incorrectly said to manage VLANs (VTP's role), Port Security is incorrectly said to negotiate trunks (DTP's role), and DTP is incorrectly said to restrict MAC addresses (Port Security's role). Only Rapid PVST+ is correctly matched with providing fast per-VLAN convergence, but the five wrong pairings make the overall option incorrect.

STP provides fast per-VLAN convergence, VTP aggregates links, EtherChannel prevents loops, Port Security manages VLANs, DTP restricts MAC addresses, and Rapid PVST+ negotiates trunks.

Why wrong: Every pairing in this option is mismatched: STP does not provide fast convergence, that is the role of Rapid PVST+; VTP does not aggregate links, EtherChannel does; EtherChannel does not prevent loops, STP does; Port Security does not manage VLANs, VTP does; DTP does not restrict MAC addresses, Port Security does; and Rapid PVST+ does not negotiate trunks, DTP does. Because all six features are assigned to the wrong function, the entire answer is incorrect.

OSPF authentication

Why wrong: OSPF authentication is a Layer 3 routing protocol feature that validates neighbor relationships by encrypting or hashing OSPF packets between routers. It does not inspect or control traffic from end hosts on a switchport, nor does it regulate MAC addresses. Since OSPF is concerned with route exchange in the control plane, it cannot enforce any policy on the data plane of an access port.

NetFlow

Why wrong: NetFlow is a traffic monitoring technology that samples and exports metadata about IP flows, such as source and destination addresses, ports, and byte counts. It provides visibility into traffic patterns but lacks any enforcement capability to block or limit which MAC addresses can use an access port. Therefore, while NetFlow could observe activity on a VLAN 10 port, it cannot directly control endpoint access or enforce security limits.

NTP

Why wrong: NTP is a protocol designed to synchronize clocks across network devices, ensuring consistent timestamps for logging and authentication. It has no mechanism to filter, block, or limit endpoints on a Layer 2 access port. Even if NTP were enabled on the switch, it would not prevent a host in VLAN 10 from sending traffic, making it wholly unrelated to port-level access control.

The channel fails because both sides must be passive.

Why wrong: If both sides are configured with LACP passive mode, the channel will fail to form because passive interfaces only respond to received LACP PDUs and never initiate negotiation. With no active device to start the handshake, neither switch will recognize the peer's capability for aggregation, leaving the member links in a standalone state. Thus, passive/passive is the pairing that prevents LACP from establishing the bundle.

The channel becomes a routed interface automatically.

Why wrong: LACP is a link aggregation control protocol that operates independently of the Layer 2 or Layer 3 configuration of the ports; it does not automatically convert an EtherChannel into a routed interface. Whether the resulting port-channel is a Layer 2 switchport or a Layer 3 routed port is determined by the 'switchport' or 'no switchport' configuration, not by LACP itself. Therefore, the channel remains in its configured mode unless the administrator explicitly changes the interface type.

All VLAN tags are removed from the bundle by default.

Why wrong: Forming an EtherChannel does not strip or alter VLAN tags on the aggregated link. When operating as a Layer 2 trunk, each member interface carries the same VLAN tags as any standard trunk port, and the EtherChannel bundle simply aggregates bandwidth while preserving 802.1Q tagging. The statement confuses logical bundling with VLAN manipulation; VLAN tags remain intact for all traffic traversing the channel.

All ports in both VLANs configured as trunks

Why wrong: Configuring all ports in both VLANs as trunk ports is a Layer 2 operation that allows multiple VLANs to traverse a single link using 802.1Q tagging, which is designed for links between switches or between a switch and a router, not for connecting end hosts. Trunking does not perform any Layer 3 routing; it simply preserves VLAN tags so that traffic remains isolated at Layer 2. Even if every port is a trunk, the switch still lacks the Layer 3 interfaces and routing table entries necessary to forward packets between VLAN 10 and the other VLAN, so no inter-VLAN routing would occur.

A separate OSPF process on every access port

Why wrong: OSPF is a dynamic routing protocol that operates at Layer 3 to exchange route information between routers or multilayer switches, not between individual access ports. Access ports are Layer 2 interfaces that carry untagged traffic for a single VLAN and cannot run OSPF because they lack an IP address and are not routed interfaces. Even if you could enable OSPF, it would not create a routing path between VLANs; you would still need SVIs with IP addresses and a routing table. For simple inter-VLAN routing, OSPF is unnecessary and adds complexity without providing any benefit.

Port security disabled on every edge port

Why wrong: Port security is a Layer 2 security feature that restricts the MAC addresses allowed on a port to prevent unauthorized devices or MAC flooding attacks; it has absolutely no effect on the switch's ability to route at Layer 3. Disabling port security on edge ports only affects MAC address table learning and security policy enforcement, not the presence of SVIs or the IP routing configuration. Inter-VLAN routing is determined by whether the switch has routed interfaces for each VLAN and has IP routing enabled, so disabling port security cannot enable or disable routing between VLAN 10 and the other VLAN.