Refer to the Exhibit Practice Questions

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.

Change the AP from Ethernet to PPP encapsulation.

Why wrong: PPP (Point-to-Point Protocol) is a WAN encapsulation used on serial or dial-up links, not on Ethernet LAN segments where access points typically connect. Changing the AP's encapsulation to PPP would not affect CAPWAP, which runs over UDP/IP and expects Ethernet framing on the local LAN. The exhibit gives no indication of a serial link or PPP requirement, so this action is unrelated to the AP's inability to join the controller.

Remove the AP IP address so it can obtain an IP address automatically via DHCP.

Why wrong: Removing the static IP and switching to DHCP does not address the root cause because the problem is a layer 3 reachability misconfiguration, not the method of address assignment. If the DHCP scope also provides the same incorrect default gateway, the AP will obtain a valid address but still be unable to reach the controller. Even a dynamically assigned address requires a correct gateway to forward CAPWAP traffic; the static IP itself is not preventing the AP from joining.

Disable DHCP on the controller for all APs.

Why wrong: Disabling DHCP on the controller globally is incorrect because the exhibit indicates that the problem is specific to this AP's default gateway, and other APs are already joining successfully. Such a global change would disrupt DHCP-based provisioning for all access points, including the healthy ones, without correcting the faulty gateway on the problematic AP. The issue lies in the AP's local IP routing configuration, not in the controller's DHCP service.

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.

Because OSPF always overrides static routing, regardless of prefix length.

Why wrong: The premise that OSPF automatically overrides static routing is false; routing decisions prioritize longest prefix match first, and only when prefix lengths are equal does administrative distance break the tie. A static route has an administrative distance of 1, which is far lower than OSPF's 110, so a static /24 would be preferred for that prefix. The real reason the OSPF route wins here is that the /26 route has a longer prefix length than the static /24, not because of the protocol type.

Because the static route must have an administrative distance of 255 to be considered.

Why wrong: The static route does not need to have an administrative distance of 255 to be considered; in fact, an AD of 255 is treated as unreachable and would not be installed in the routing table. The static route is indeed valid and present, but its /24 prefix is less specific than the OSPF /26 route. Cisco IOS selects routes based on the longest prefix match first, so the more specific /26 route wins regardless of the static route's administrative distance.

Because the destination 198.51.100.70 is outside both listed routes.

Why wrong: The destination 198.51.100.70 is not outside both routes—it lies within the static /24 range of 198.51.100.0 through 198.51.100.255 and also within the OSPF /26 range of 198.51.100.64 through 198.51.100.127. Since .70 is between .64 and .127, it is covered by the more specific OSPF route. Therefore, the claim that it is outside either network is incorrect.

Default routes always override static routes.

Why wrong: Default routes (0.0.0.0/0) have the shortest prefix length (0 bits) and only match when no more specific route exists. A static route to 192.168.40.0/24 is more specific and, when valid, is always preferred over a default route because routers select the longest prefix match. Thus, default routes do not override static routes; they only act as a fallback, making this option wrong.

The destination must be configured as a /16, not a /24.

Why wrong: The /24 mask in the static route correctly identifies the 192.168.40.0/24 subnet that contains 192.168.40.200; changing it to a /16 would broaden the matched range to 192.168.0.0/16 but would not fix next-hop reachability. The prefix length affects which destinations match the route, not whether the next hop is reachable. Since the problem is an unreachable next hop, not an incorrect mask, this option is incorrect.

Static routes can be used only if OSPF is disabled.

Why wrong: Static routes are independent of the routing protocol in use; OSPF can run concurrently with static routes and does not inhibit their installation. A static route is installed when it satisfies administrative distance and next-hop reachability criteria, regardless of whether OSPF is enabled or disabled. Disabling OSPF would not make an otherwise valid static route usable, so this statement is incorrect.

An OSPF area mismatch

Why wrong: An OSPF area mismatch on the shared link would prevent R2 from even establishing a stable two-way relationship with R1, because the Area ID field in Hello packets would not match the configured area on the interface. The routers would typically become stuck in the INIT or DOWN state, or the Hello packets would be ignored entirely, rather than advancing to the EXSTART state. Since EXSTART is a state reached only after the routers have exchanged Hello packets and formed a neighbor relationship, an area mismatch would block the process earlier in the neighbor state machine.

A duplicate router ID on R1 and R2

Why wrong: A duplicate Router ID would cause each router to mistakenly interpret the other's Hello as coming from itself, triggering an immediate rejection of the adjacency and potential routing table flapping. While this could cause the neighbor state to oscillate, it would not normally leave the session permanently in EXSTART, as the duplicate ID is typically detected and the adjacency is torn down before the Database Descriptor exchange completes. The fact that R1 and R2 are specifically stuck in EXSTART on a single link points to a packet-level size or delivery issue, not a Router ID conflict.

A missing default route on R2

Why wrong: A missing default route on R2 is a routing information condition that has no bearing on the OSPF adjacency state machine, which governs only the exchange of Hello, Database Descriptor, and Link-State Request/Update packets. OSPF neighbors form adjacencies regardless of whether a default route exists in the routing table, as adjacency establishment is a prerequisite for exchanging routes in the first place. Therefore, the absence of a default route would not cause R2 to halt at EXSTART with R1.

PAT requires OSPF to be enabled on the WAN link.

Why wrong: PAT operates at Layer 3/4 and only needs the inside and outside interfaces to be correctly identified and the ACL to match traffic. Routing protocols like OSPF are used to exchange routes, not to enable NAT. As long as the router has a route to the destination (e.g., a default static route), PAT will work independently of whether OSPF is running.

The ACL must be numbered 100 instead of 1.

Why wrong: Standard ACLs (1-99) and extended ACLs (100-199) are both valid for NAT. The `access-list 1 permit` command simply defines which source addresses are eligible for translation; it does not require a specific number range. In fact, many PAT configurations use a standard ACL numbered 1, so changing to 100 would have no effect on whether PAT is working.

The router must use GRE before PAT can overload.

Why wrong: PAT is a form of NAT that multiplexes many private addresses to one public IP using unique port numbers. GRE is a tunneling protocol used to encapsulate packets (e.g., for VPNs) and is not a prerequisite for NAT/PAT. The router can perform PAT directly on the physical WAN interface without any tunnel.

PPP requires CAPWAP on both routers.

Why wrong: CAPWAP (Control and Provisioning of Wireless Access Points) is a protocol used for wireless LAN controller management, not for serial PPP. PPP uses LCP (Link Control Protocol) and NCP (Network Control Protocol) for establishment and configuration. CAPWAP has no role in PPP link establishment or operation.

The routers must run BGP before PPP can establish.

Why wrong: PPP is a Layer 2 protocol that operates independently of any routing protocol. BGP is a Layer 3 path-vector protocol for exchanging routing information between autonomous systems. PPP can establish over serial links without any BGP configuration; in fact, routing protocols like OSPF or static routes can run over a PPP link.

Serial links can use only OSPF, not PPP.

Why wrong: This confusion conflates the routing protocol OSPF with the data-link encapsulation PPP. PPP is a Layer 2 encapsulation that can carry any Layer 3 protocol, including IP, and any routing protocol such as OSPF, EIGRP, or BGP. Serial links support multiple encapsulations (HDLC, PPP, Frame Relay), and OSPF is not an encapsulation at all.

The interfaces must use HDLC instead of PPP before authentication can work.

Why wrong: HDLC is a Cisco-proprietary (or standard) encapsulation that does not include a built-in authentication mechanism, whereas PPP uses a Link Control Protocol to negotiate authentication methods such as PAP or CHAP. Replacing PPP with HDLC would eliminate the possibility of CHAP entirely, so it cannot be the fix for a credential mismatch. The problem shown in the exhibit is a difference in the CHAP password, not an encapsulation incompatibility.

CHAP requires the routers to be in different IPv4 subnets.

Why wrong: CHAP operates at the link layer and is completely independent of IP addressing or subnet topology; it authenticates the peer using a challenge and a one-way hash of the shared secret. Routers on the same or different subnets can successfully run CHAP, and there is no requirement that they be in different subnets. A subnet mismatch would affect IP connectivity after the link is up, but it would not cause the PPP authentication failure described here.

PPP authentication works only over GRE tunnels.

Why wrong: PPP authentication is a feature of the PPP encapsulation itself and functions over any supported physical or logical interface, including point-to-point serial links, SONET, and PPPoE. GRE tunnels are merely one possible transport that can carry PPP frames, but they are not a prerequisite for CHAP or PAP. If GRE were required, standard serial PPP links would never authenticate, which is clearly not the case.

The native VLAN is missing

Why wrong: An incorrect or missing native VLAN on a trunk creates a spanning-tree VLAN mismatch that can disrupt traffic and cause spanning-tree errors, but it does not generate a port-security violation. Port security counts MAC addresses learned on the interface and would not shut the port down simply because the native VLAN is absent. Thus, a missing native VLAN alone cannot explain the err-disabled condition.

BPDU Guard blocked the port because a workstation was attached

Why wrong: BPDU Guard is designed to protect PortFast-enabled ports that should never receive BPDUs; if a BPDU arrives, the port is err-disabled. A normal workstation does not transmit BPDUs, because BPDUs are generated by switches (or spanning-tree-capable bridges). Therefore, attaching a workstation would not cause BPDU Guard to trigger; only an unauthorized switch sending BPDUs could produce that result.

DHCP snooping denied the voice VLAN

Why wrong: DHCP snooping filters DHCP messages based on trusted and untrusted ports and can drop DHCPOFFER packets from untrusted ports, but it does not place the switch interface into an err-disabled state. The err-disabled condition shown is caused by a security violation, not by DHCP packet filtering. Even if the voice VLAN IP phone failed to obtain an address, the port would remain operationally up, so this option is inconsistent with the symptom.

Whether the switch should disable IP routing

Why wrong: Disabling IP routing on the switch would completely break the path between VLAN 10 and VLAN 20, because the switch's SVI would no longer forward packets between those subnets. The fact that the host can already ping its local SVI indicates that the switch's layer 3 interface is up and addressed correctly; the problem lies beyond the local subnet. To route between VLANs, IP routing must remain enabled—either on the switch (inter-VLAN routing) or on an external router—so disabling it is not a viable fix and would only worsen the situation.

Whether VLAN 10 should be the native VLAN

Why wrong: VLAN 10 being the native VLAN is irrelevant to this symptom. Native VLAN configuration only affects how frames are tagged on 802.1Q trunk links; frames on the native VLAN are sent untagged. The host's ability to ping its local SVI and then fail to reach a server in another VLAN points to layer 3 forwarding issues, not to the layer 2 trunk encapsulation or native VLAN mismatch. Checking native VLAN settings would be appropriate only if there were complete L2 connectivity failures, not selective inter-VLAN reachability.

Whether the host should use a /8 mask instead of /24

Why wrong: Changing the host's subnet mask from /24 to /8 would make the host assume the entire 10.0.0.0/8 address space is directly connected on its own VLAN. It would then attempt to ARP for the server's IP address instead of sending the packet to its default gateway, breaking communication even more. The given symptom—host can ping the local SVI—shows the host is already using a proper /24 mask and routing locally through its gateway; a /8 mask would create a completely different ARP-based failure, not resolve the current one.

Create a brand-new resource

Why wrong: Creating a brand-new resource requires an HTTP POST method (or PUT if the client specifies the URI). GET is never used for creation because it is defined as safe and must not cause side effects on the server. Sending a GET request to a controller API to create a resource would violate HTTP semantics and would typically return a 405 Method Not Allowed or simply retrieve existing data.

Replace the entire resource configuration

Why wrong: Replacing an entire resource configuration is performed with the HTTP PUT method, which replaces the complete representation of the targeted resource. GET, however, is defined as a read-only operation and cannot replace or update any part of the resource. In a controller API, making a GET request to replace configuration would not trigger a PUT handler, and the server would return a response indicating the operation is unsupported for that method.

Delete the resource

Why wrong: The HTTP DELETE method is the only standard method intended to remove the resource identified by the request URI. A GET request, by contrast, must not modify or delete any server-side resource; it is strictly for reading. Assuming the controller API follows RESTful conventions, using GET to delete would be ignored or rejected, as it lacks the destructive semantics of DELETE.

logging trap debugging

Why wrong: Debugging is severity level 7, the lowest on the syslog scale, so 'logging trap debugging' causes every syslog message generated by the device to be sent, from level 0 emergencies through level 7 debugging. This is maximally inclusive and obviously exceeds the engineer's goal of only warning messages, because it forwards all debug output and every other severity class.

logging trap notifications

Why wrong: Notifications sit at severity level 5, which is one step less severe than warnings. When you configure 'logging trap notifications', the device sends levels 0 through 5—so it includes all warning and more severe messages plus the lower-severity notification messages. That adds an extra level of messages beyond the engineer's stated requirement, making the filter too broad rather than limiting the output to warnings only.

logging trap informational

Why wrong: The 'logging trap informational' command sets the trap filter to severity 6, which means the device will transmit all messages from level 0 through 6—including informational and all less severe messages. Because informational is two steps below warnings, this would forward far more messages than requested, including notifications and routine informational notices that the engineer does not want.

Static NAT

Why wrong: Static NAT creates a one-to-one mapping between a private inside address and a public outside address. For the 192.168.10.0/24 network, this would require a unique public IP for each host, which is neither scalable nor practical when only a single interface address is available. The overload keyword, used for PAT, is specifically absent in static NAT configurations.

Policy-based routing

Why wrong: Policy-based routing (PBR) intercepts packets and forces them to follow a configured next hop or interface based on match criteria like source IP or protocol, overriding the routing table. It does not modify the IP header's source or destination address, so it cannot translate a private source address to a public one. NAT configuration uses ip nat inside/outside statements, not route-maps to alter forwarding decisions.

Port security

Why wrong: Port security is a Layer 2 switchport feature that restricts ingress traffic by limiting MAC addresses, not a router-based NAT function. It operates on access or trunk ports to mitigate MAC flooding and unauthorized devices, but it does not perform any IP address translation. The scenario involves translating private source addresses for internet access, which is entirely outside the scope of port security.

The static route because static routes always win over dynamic routes

Why wrong: A static route does not automatically override a dynamic route. The router compares administrative distance, and the default static route AD is 1, but a floating static route is deliberately set with a higher AD (e.g., 130) so that it yields to a more preferred dynamic route like OSPF (AD 110). Static routes only win when their AD is lower than the competing route's AD.

Both routes because the prefix length matches

Why wrong: Even when two routes share the same prefix length, the router installs only the single best route in the routing table. Route selection depends primarily on administrative distance, not just the subnet mask. Since the OSPF route has a lower AD than the floating static route, the router ignores the static route for this prefix and does not install both; both routes would be installed only if they had the same AD and metric.

Neither route until equal-cost load balancing is configured

Why wrong: Equal-cost load balancing requires two or more routes to the same destination with identical administrative distance and identical metric. Here the OSPF route and the floating static route have different ADs (110 vs. 130), so they are not equal-cost candidates. The router does not wait for load balancing to be configured; it immediately selects the OSPF route as the best path.