Which Command Should the Administrator Use Practice Questions

The access list 'NAT' is incorrect; it should permit only specific hosts, not the entire subnet.

Why wrong: The access list 'NAT' is not the problem. In dynamic NAT, the ACL is used solely to identify which inside addresses are eligible for translation, and permitting the entire internal subnet is standard and correct when all internal hosts should have Internet access. Even if the ACL were narrowed to specific hosts, the router would still fail to translate return packets because the outside interface has not been designated with 'ip nat outside'. The ACL only controls which source addresses are translated, not whether NAT is applied on an interface.

The NAT configuration lacks the 'overload' keyword, so the pool is exhausted quickly.

Why wrong: The lack of the 'overload' keyword is a red herring here. Without overload, the router performs standard dynamic NAT, which still works correctly as long as the number of active inside addresses does not exceed the number of addresses in the pool. In the scenario, there are only 2 active translations and 11 addresses in the pool, so the pool is not exhausted and overload would not change the immediate outcome. The real issue is that the outside interface is not configured for NAT, and adding overload cannot compensate for that missing interface-level command.

The NAT pool 'POOL' has too few addresses; it should be expanded to a /24 subnet.

Why wrong: The NAT pool 'POOL' has 11 addresses, which is more than enough for the two active translations, so pool size is not causing the problem. Expanding the pool to a /24 subnet would only increase the maximum number of concurrent translations; it would not make the router process return traffic on the outside interface. Even with 254 public addresses available, the router would still not translate reply packets because the outside interface is not marked with 'ip nat outside'. The symptom of no replies is a direct result of missing interface NAT designation, not address exhaustion.

Enable DFS channels to avoid radar interference.

Why wrong: DFS (Dynamic Frequency Selection) channels are specifically intended for radar interference avoidance, not for mitigating co-channel interference between APs. The exhibit shows no radar events; enabling DFS would introduce unnecessary radar-detect downtime and channel unavailability without changing the fact that multiple APs share the same non-DFS channel. The root cause is poor channel planning, not radar coexistence.

Increase the channel width to 160 MHz to improve throughput.

Why wrong: Increasing the channel width to 160 MHz would enlarge the RF footprint and consume most of the available 5 GHz spectrum, but it would not address the existing co-channel contention between APs. In fact, wider channels reduce the number of non-overlapping channels available (often to just one 160 MHz block per regulatory domain), which would increase CCI and make the problem worse. The exhibit's issue is channel reuse, not insufficient channel bandwidth.

Disable the 2.4 GHz radios to force all clients to 5 GHz.

Why wrong: Disabling the 2.4 GHz radios only removes the legacy band and does nothing to alter the channel assignments on the 5 GHz band where the contention is occurring. This would also force clients that depend on 2.4 GHz (such as IoT or older devices) onto 5 GHz, potentially causing connectivity issues while leaving the 5 GHz co-channel interference completely unsolved. The exhibit's problem is AP-to-AP channel overlap on 5 GHz, not the presence of the 2.4 GHz band.

The interface is administratively down.

Why wrong: The interface status in the output reads 'up, line protocol is up', indicating that the interface is fully operational at both Layer 1 and Layer 2. An administratively down interface would instead show 'administratively down, line protocol is down' and would not generate any IPv6 traffic, including Router Advertisements. Since the router is actively advertising and the link-local address is present, the interface is clearly not shut down or disabled.

The MAC address of the interface is invalid, preventing EUI-64 from generating a proper address.

Why wrong: The link-local address FE80::21A:2BFF:FE3C:4D5E shown in the output is derived from the interface MAC address using EUI-64, which inserts FFFE in the middle and flips the U/L bit. The presence of this valid link-local address proves the MAC address is not invalid and EUI-64 generation succeeded. An invalid or all-zero MAC would prevent IPv6 from generating any link-local address, but the output clearly displays a properly formed one, so this option cannot be the cause.

The router is not sending Router Advertisements, so hosts cannot autoconfigure.

Why wrong: The output explicitly states 'ND router advertisements are sent every 200 seconds', which confirms the router is actively sending ICMPv6 Router Advertisements on this interface. Hosts would therefore be able to perform stateless address autoconfiguration (SLAAC) and learn the default router. However, the problem is that hosts cannot reach the router's own link-local address, which points to a missing or incorrectly configured IPv6 address on the router itself, not to a lack of RA messages.

Configure only a DNS server of 10.10.10.5.

Why wrong: Configuring only a DNS server of 10.10.10.5 gives the workstation the ability to resolve hostnames into IP addresses, but name resolution does not provide any forwarding path for traffic destined outside the local subnet. The workstation's routing table has no default route, so any packet with a destination IP outside 10.10.10.0/24 is dropped as unreachable. Even though the DNS server is reachable on the same subnet, the host still cannot reach the server at 10.10.20.x because there is no gateway to route that traffic. Thus, DNS alone is insufficient for inter-subnet communication.

Change the subnet mask to 255.255.0.0 to allow communication across subnets.

Why wrong: Altering the workstation's subnet mask to 255.255.0.0 (/16) would make it assume that all 10.10.x.x addresses are within the same local broadcast domain. As a result, it would attempt to resolve destinations like 10.10.20.5 via ARP rather than forwarding them to a router, but ARP is a Layer 2 broadcast that cannot cross a router. This not only fails to provide a path to other subnets but also breaks routing from the router's perspective, since the router's interface is still configured with a /24 mask and will treat the host's /16 view as a conflicting route. The proper solution requires a Layer 3 gateway, not an expanded subnet mask.

Configure a default gateway of 10.10.20.1 and a DNS server of 10.10.10.5.

Why wrong: This configuration fails because a default gateway must be directly reachable on the same IP subnet as the host. The gateway 10.10.20.1 is on the 10.10.20.0/24 network, while the workstation is on 10.10.10.0/24, so the host cannot ARP for it and will not be able to send any frames to that gateway. Even if the DNS server 10.10.10.5 is correct, the workstation will still be unable to communicate with any remote subnet because its default route points to an unreachable next hop. The host essentially has no valid gateway, so all non-local traffic is discarded.

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.

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.

ifconfig

Why wrong: ifconfig is a legacy Unix tool for configuring and displaying network interfaces; it may be absent on modern Linux distributions that rely on iproute2. It shows local address and link status, but it never sends packets to a remote destination. Deprecated and often not installed by default, its interface display role is now superseded by 'ip addr'.

tracert

Why wrong: tracert is a Windows command that traces the path to a destination by sending ICMP packets with incrementally increasing TTL values and reporting intermediate routers. Linux uses 'traceroute' instead, typically with UDP or ICMP; the name and default behavior differ. It diagnoses routing paths, not basic connectivity, and may still show replies even if the final host rejects/doesn't respond to pings.

nslookup

Why wrong: nslookup queries DNS servers to resolve domain names to IP addresses or to retrieve DNS records like A, AAAA, MX, or NS. It tests the DNS resolution service, not IP connectivity; a successful query only proves the DNS server is reachable, not the target host. It is the wrong tool for checking whether a host is up, since it does not send any packets to the target host's IP address.

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 OSPF route, because dynamic routes always beat static routes

Why wrong: Dynamic routes do not automatically outrank static routes; that belief ignores how administrative distance works. Route preference is determined solely by the numeric administrative distance, not by whether the route was learned dynamically or configured manually. In this scenario, the static route's distance of 90 is lower than OSPF's 110, so the static route is more trusted. Therefore, OSPF is not installed because dynamic learning does not confer an inherent advantage.

Both routes equally, because the prefix is identical

Why wrong: Having the same prefix length does not mean both routes are equally preferred, because routes from different protocols are compared using administrative distance. OSPF's default administrative distance is 110, while this static route has a distance of 90. The router does not aggregate or load-balance across protocols; it installs only the route with the lower administrative distance. Thus the identical prefix length has no bearing on equality when the administrative distances differ.

Neither route, because duplicate information is dropped

Why wrong: Routers do not simply drop duplicate routing information; they perform a route-selection process. For the same destination prefix, the router compares administrative distances across different sources and installs the winning route in the forwarding table. The losing route remains in the originating protocol's database, not in the routing table. Therefore, duplicate information is not dropped; it is evaluated and only the best route is chosen.

192.168.50.127

Why wrong: The address .127 is the broadcast address of the lower /25 subnet, 192.168.50.0/25, which spans from .0 to .127. However, the configured IP .130 belongs to the upper subnet (.128/25), so the lower subnet's broadcast is not applicable. For the subnet containing .130, the broadcast is .255, not .127.

192.168.50.128

Why wrong: The address .128 is the network address of the upper /25 subnet, not its broadcast. In 192.168.50.128/25, the network address has all host bits set to 0, yielding .128 as the identifier for the subnet itself. The broadcast address is the last address, .255, while .128 merely marks the starting boundary of that subnet.

192.168.50.254

Why wrong: The address .254 is the last usable host address in the 192.168.50.128/25 subnet. Usable host addresses are those between the network address (.128) and the broadcast address (.255), specifically .129 through .254. Since .255 is reserved as the broadcast, .254 cannot be the broadcast address; it is a valid host assignment.

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.

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.