CCNA 200-301 v2 (200-301) — Questions 1126–1200

Option A is incorrect because the subnet mask 255.255.254.0 corresponds to a prefix length of /23, not /22. A /22 prefix would indicate a subnet mask of 255.255.252.0.

The subnet mask 255.255.254.0 corresponds to a prefix length of /23, not /24. A /24 prefix length would indicate a subnet mask of 255.255.255.0, which allows for fewer hosts per subnet.

Option D is incorrect because a subnet mask of 255.255.254.0 corresponds to a prefix length of /23, not /25. A /25 subnet mask would allow for only 128 IP addresses, which is not applicable here.

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

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

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

This option permits TCP traffic from 10.10.10.0/24 to the web server on port 80, which is the exact traffic that must be blocked. Therefore, it contradicts the requirement and is incorrect.

This option denies all IP traffic from the source subnet to the destination host, which is too broad. It blocks all protocols and ports, not just HTTP, violating the requirement to allow other traffic.

This option denies UDP traffic on port 80, but HTTP uses TCP port 80. Denying UDP port 80 does not block HTTP traffic and therefore does not meet the requirement.

Option C is incorrect because YANG does not replace IP addressing on routed interfaces. IP addressing is a network-layer function, while YANG models the data representing such configurations but does not perform addressing itself.

Option D is wrong as YANG has no role in spanning-tree optimization or Layer 2 loop prevention. YANG is a data modeling language and does not influence protocol operations like STP.

The running-config shows 'no shutdown', so this is not the cause.

The IP address and subnet mask are correctly configured for the VLAN.

The SVI status is not affected by the presence or absence of a default gateway.

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

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

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

The specific factual error is that 802.1X should use RADIUS for authentication, not local, and the login default should have RADIUS as the primary method.

The specific factual error is that the login default should be 'group radius local' to meet the requirement of RADIUS first then local fallback.

The specific factual error is that the key must match exactly; changing it to 'cisco' would break communication with the RADIUS server.

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

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

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

Incorrect because STP priority is a Layer 2 switch parameter that does not affect host IP routing or the ability to reach remote networks. Hosts do not participate in STP decisions.

Incorrect because voice VLAN settings relate to Layer 2 segmentation for voice traffic and do not impact the host’s IP routing or default gateway configuration needed for remote communication.

Incorrect because hosts do not run routing protocols like OSPF and do not require an OSPF process ID. Routing protocols are configured on routers, not end hosts.

Candidates may think that a large number of untrusted hosts could overwhelm the binding table, but static hosts do not interact with DHCP and would not fill the table or be rejected.

Candidates often confuse DAI and IP Source Guard since both use DHCP snooping; however, DAI specifically validates ARP packets, which matches the symptom of connectivity loss due to ARP resolution failure.

Some candidates might associate ARP security features with port shutdown, but standard DAI operation does not disable ports, and the symptom does not indicate interface down events.

AI-driven operations can minimize downtime but cannot eliminate it entirely due to unpredictable hardware failures and external factors.

New network devices still require initial configuration and policy assignment; AI may assist but cannot achieve zero configuration.

Human engineers remain essential for strategic planning, complex troubleshooting, and overseeing AI-driven processes.

A northbound API does not replace authentication or authorization; it relies on those mechanisms to secure API access.

VLAN tagging is a data‑plane feature independent of the northbound API; the API does not make VLAN tagging unnecessary.

Incorrect timers (30/120) break adjacency, and 'passive-interface default' suppresses hellos on all interfaces, including the transit link.

Network type point-to-point on R1 does not match R2's default broadcast, causing a type mismatch that prevents OSPF adjacency.

Omits the required 'passive-interface GigabitEthernet0/1' command, leaving hellos sending on that interface.

10.20.30.32 is incorrect because the host IP 10.20.30.95 does not fall within the 32–63 subnet block. This address belongs to a different subnet block and cannot be the network address for the given host.

10.20.30.95 is incorrect because it is the host IP address itself, not the network address. The network address must be the first address in the subnet block, not a host address.

10.20.30.96 is incorrect because it is the first address of the next subnet block (96–127). The host IP 10.20.30.95 belongs to the previous block, so 10.20.30.96 cannot be its network address.

Option C applies the new ACL without explicitly removing the old one, which violates the explicit removal requirement.

Standard ACLs cannot match destination IP addresses or port numbers; they only match source IP addresses.

The ACL entry incorrectly specifies the web server as the source and the internal network as the destination, which is the opposite of the required direction.

Applying the ACL inbound on the external interface filters traffic entering from the internet, not traffic from the internal network. The correct placement is inbound on the internal interface.

'show access-lists' displays the configured ACLs and their hit counts but does not show active NAT translation entries. It cannot confirm whether PAT translations are being created or maintained.

'show ip route' shows the routing table with network paths and next hops but does not provide any information about NAT translation sessions or port mappings, making it unsuitable for verifying PAT.

'debug ip packet detail' provides detailed packet-level debugging information, which is more intrusive and verbose than necessary for basic NAT verification, and can impact device performance.

This is a distractor term that does not exist in the DHCP snooping configuration. The correct states are trusted and untrusted.

This term is borrowed from other security contexts and is not applicable to DHCP snooping trust states.

This confuses the DHCP relay agent feature with DHCP snooping trust states. They are different mechanisms.

This option is incorrect because static routes do not inherently get overridden by default routes; rather, the routing table prioritizes routes based on their specificity and administrative distance.

This option is incorrect because the subnet mask of the destination IP does not affect the functionality of static routes in this context; static routes can operate with various subnet masks without being limited to /16 or /24.

This option is incorrect because static routes can coexist with dynamic routing protocols like OSPF; they do not require OSPF to be disabled to function properly.

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

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

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

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

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

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

The network statement is syntactically correct and covers the interface IP address, so it does enable OSPF process on that interface (subject to the passive-interface setting).

The configuration shows 'no shutdown', indicating the interface is enabled. Administrative down would require the 'shutdown' command or lack of 'no shutdown'.

The output clearly shows 'area 0' in both routers' OSPF configurations, so area mismatch is not the cause.

Duplex mismatch would cause CRC errors and late collisions, which are not present in the exhibit.

VLAN mismatch does not cause runts or giants; it causes Layer 2 issues like no connectivity.

Speed mismatch would prevent the link from coming up or cause CRC errors, but the link is up at 1000 Mb/s.

The native VLAN must match on both ends; SW1 uses VLAN 99 as native, so R1 must use VLAN 99 as native, not VLAN 10.

Router-on-a-stick uses subinterfaces, not the physical interface IP. The physical interface only needs to be up and trunking.

The native VLAN must be consistent across the trunk; SW1 uses VLAN 99, so R1 must use VLAN 99 as native.

NTP (Network Time Protocol) synchronizes clocks across devices but does not affect the ability to resolve domain names or browse websites. Since the client can ping an IP address, time synchronization issues are unlikely to cause the browsing failure.

DHCP snooping is a security feature that prevents rogue DHCP servers but does not directly impact DNS resolution or hostname-based browsing. The client already has IP connectivity, so DHCP snooping is not the issue.

HSRP provides gateway redundancy and failover but does not influence DNS or hostname resolution. Since the client can reach an external IP, the default gateway is functioning, so HSRP failure is unlikely.

Option B is incorrect because the client can already reach the server by IP address, proving the default gateway is functioning properly and not the cause of hostname resolution failure.

Option C is wrong since a switch trunk native VLAN mismatch would cause broader connectivity issues, not just hostname resolution failures. The symptom is specific to name-based access, not total path failure.

Option D is incorrect because PPP is unrelated to DNS or hostname resolution in this context. PPP is a WAN protocol and does not affect LAN-based DNS name resolution.

Only one public IP is available, so a pool cannot be created.

Inbound access to the web server would not be possible without a static mapping.

Internal hosts would not be able to access the internet because they lack public IP assignments.

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

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

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

Candidates may confuse adjacency failures with DBD exchange problems, but network type mismatch leads to a different state (2-WAY).

Candidates think duplicate Router IDs might cause DBD exchange failure, but duplicate IDs prevent neighbor discovery entirely.

Many associate EXSTART with any adjacency issue, but authentication errors prevent the neighbor from being listed at all.

HTTP status code 401 specifically indicates unauthorized access due to missing or invalid authentication. A 'resource not found' is indicated by 404, not 401.

HTTP 401 indicates authentication failure, not successful completion. A 200-level code would indicate success.

HTTP 401 indicates authentication failure, not a request entity too large. The '413 Payload Too Large' status code is used when the request body exceeds the server's limit.

The network address is wrong; the summary must start at 192.168.0.0, not 192.168.1.0.

The subnet mask /24 is too small; it does not summarize the three subnets.

The subnet mask /23 is too specific; it only covers two of the three subnets.

This option is incorrect because metric values are only compared among routes learned from the same routing protocol. The OSPF metric of 30 is irrelevant when compared to a static route, which is a different routing source with a lower administrative distance.

This option is incorrect because routers do not install multiple routes to the same prefix from different routing protocols unless they have equal administrative distance and are configured for load balancing. Here, the static route’s lower AD prevents the OSPF route from being installed.

This option is incorrect because the router does not delay route installation until a full SPF recalculation. Route selection is immediate based on administrative distance and metric rules. SPF recalculation only affects OSPF route selection, not cross-protocol comparisons.

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

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

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

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

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

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

The transceiver diagnostics show no fault flags, and the module is reporting nominal bit rate and other values within range.

The distance itself is within spec; the issue is the receive power being too low, not the distance exceeding the limit.

This is a configuration mismatch, but it does not directly cause CRC errors. The CRC errors are due to low receive power.

IPv6 unicast-routing is already enabled; the problem is at the interface level.

The requirement specifies EUI-64; omitting it results in a static address that does not match the intended configuration.

The VLAN configuration is correct; no change is needed.

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

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

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

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

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

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

Uses a /24 mask, which does not match the /32 loopback address, potentially leading to incorrect routing.

Uses next-hop 192.168.1.1, which is not directly reachable over the serial link to R2.

Creates a default route, which is not a host-specific static route as required.

DHCP is incorrect because it only leases IP addressing information and other network parameters to clients; it does not translate hostnames to IP addresses, which is the core function of DNS.

NTP is incorrect as it is used solely for synchronizing clocks across network devices and does not handle any form of hostname or IP address resolution.

SNMP is incorrect because it is a protocol for monitoring and managing network devices, not for resolving hostnames or IP addresses.

Option C is incorrect because DNS does not assign IP addresses; this is the role of DHCP. Confusing these two services is a common error, but they serve distinct purposes in IP networking.

Option D is wrong because DNS does not replace default gateways. Default gateways are necessary for routing traffic between different networks, a function unrelated to DNS name resolution.

Option E is incorrect as DNS is unrelated to the Spanning Tree Protocol (STP), which manages Layer 2 loop prevention on VLAN trunks. DNS operates at higher layers for name resolution.

Incorrect. Layer 3 route loops are routing protocol issues and are not addressed by DHCP snooping, which operates at Layer 2 for DHCP message validation.

Incorrect. Trunk encapsulation mismatches relate to VLAN tagging and trunk negotiation, which DHCP snooping does not influence or prevent.

Incorrect. Weak SSH ciphers pertain to encryption security and have no connection to DHCP snooping, which focuses solely on DHCP message filtering.

The specific factual error is that subinterfaces do not have an independent line protocol state; they depend on the physical interface. The problem is likely a physical layer issue like duplex mismatch.

The specific factual error is that the SVI is not involved in this scenario; the router's subinterface handles routing for VLAN 10. The link between R1 and SW1 is the bottleneck.

The specific factual error is that native VLAN mismatch causes different symptoms (e.g., CDP/STP issues) and does not cause line protocol down or CRC errors.

Option B is incorrect because using PAT alone cannot guarantee a fixed public IP and port for the internal server. PAT dynamically assigns ports for outbound sessions, which prevents predictable inbound access to the server from outside.

Option C is incorrect because private IPv4 addresses are not routable on the public Internet. Disabling NAT would make the internal server unreachable externally, violating the requirement for consistent outside access.

Option D is incorrect because DHCP relay only forwards DHCP requests between clients and servers and does not affect NAT or the server's public reachability. It does not solve the problem of making the internal web server accessible from outside.

This option is wrong because 203.0.113.10 is the inside global address, not the inside local address. The inside local address is 192.168.10.25, which is correctly identified in option A.

This option is incorrect because 198.51.100.20 is the outside local address, not a translated private address. The inside local address is specifically 192.168.10.25, as indicated in the NAT translation entry.

This option is incorrect because the entry shows that 203.0.113.10 is the inside global address, not the inside local address. The inside local address is 192.168.10.25, which is correctly identified in option A.

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

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

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

Option B, 10.20.0.0/23, is incorrect because it only encompasses two of the four specified networks (10.20.0.0/24 and 10.20.1.0/24), failing to include the other two networks (10.20.2.0/24 and 10.20.3.0/24).

Option C is incorrect because it only summarizes a single network (10.20.0.0/24) and does not encompass the other three networks (10.20.1.0/24, 10.20.2.0/24, 10.20.3.0/24) that need to be included in the summary route.

Option D (10.20.0.0/21) is incorrect because it encompasses a larger range of addresses than required, including networks that are not part of the specified four networks, which are only within the /24 range of 10.20.0.0 to 10.20.3.0.

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

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

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

The ip directed-broadcast command enables forwarding of directed broadcasts but does not relay DHCP requests. It is unrelated to DHCP relay and will not solve the problem of clients not receiving addresses from a remote DHCP server.

service dhcp-server is not a valid Cisco IOS interface command for DHCP relay. It does not configure the router to forward DHCP broadcasts and thus will not resolve the issue.

default-router is a DHCP pool parameter used to assign the default gateway IP address to clients. It does not configure the interface to relay DHCP broadcasts and is not relevant to the relay configuration.

Retrieval is performed by the GET method, not PUT.

JSON is popular but not exclusive; XML is widely used, and many REST implementations support both.

DELETE is used to remove a resource, which maps to the Delete operation, not Update.

Option B, 172.16.32.0/23, is incorrect because it only summarizes two of the four provided routes (172.16.32.0/24 and 172.16.33.0/24), failing to include the other two routes (172.16.34.0/24 and 172.16.35.0/24).

Option C (172.16.32.0/21) includes a broader range of addresses than necessary, covering 172.16.32.0 to 172.16.39.255, which exceeds the specified routes and could lead to incorrect routing information being advertised.

Option D is incorrect because the summary route 172.16.34.0/22 would only cover the addresses from 172.16.34.0 to 172.16.35.255, missing the routes 172.16.32.0/24 and 172.16.33.0/24.

Incorrect because DHCP relay only forwards DHCP requests and does not provide any mechanism for publishing an internal server to the Internet or managing NAT translations.

Incorrect because disabling NAT leaves the internal server with a private IP address that is not routable on the Internet, making it unreachable from outside networks.

Incorrect because moving the server into the native VLAN affects only Layer 2 segmentation and does not provide a public IP address or NAT translation necessary for Internet access.

Metric is a routing concept representing route cost and does not relate to API access or authorization credentials, so it is incorrect.

Lease refers to DHCP IP address assignment duration and is unrelated to API credentials or authorization, making it incorrect.

Tuple is a data structure term and does not describe any form of authorization credential for API access, so it is incorrect.

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

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

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

The statement incorrectly claims that link-local addresses are always assigned using EUI-64.

The statement confuses the role of EUI-64; it creates the interface ID, not the network prefix.

The statement is too restrictive; multiple default gateways can be configured, especially in multi-homed hosts.

Uses `ntp master` without a stratum number, defaulting to stratum 8 instead of the required stratum 5.

Sets the wrong time zone (EST) instead of UTC.

Points to the ISP IP 10.0.0.2 instead of the actual NTP server at 192.168.1.200.

The number range 100–199 is used for extended ACLs, not standard ones.

The placement advice is reversed: standard ACLs belong near the destination, not the source.

This is a common misconception; the ability to delete individual ACEs is a feature of named ACLs, not numbered.

PAT overload is incorrect because it is designed for many internal clients sharing a single public IP for outbound traffic, not for providing a fixed public IP to a server.

No NAT is incorrect since private IPv4 addresses are not routable on the Internet and require NAT to be accessible externally.

DHCP relay is unrelated to NAT or public reachability; it only forwards DHCP requests and does not affect how internal servers are accessed from outside.

Option A incorrectly states that 'O IA' is an external route redistributed from another routing protocol. In reality, 'O IA' stands for inter-area routes within OSPF, not external routes. External routes use 'O E1' or 'O E2' codes.

Option C incorrectly claims that 'O' means the route was learned through EIGRP. The 'O' code is exclusive to OSPF intra-area routes. EIGRP routes use the code 'D' in Cisco routing tables.

Option D is incorrect because the three routes represent different OSPF route types: intra-area (O), inter-area (O IA), and external (O E2). They do not all come from the same OSPF area type.

Loop Guard is incorrect because it protects against unidirectional link failures by preventing a port from transitioning to forwarding when BPDUs stop, but it does not disable a port upon BPDU receipt.

Root Guard is incorrect because it prevents a port from becoming a root port by blocking superior BPDUs but does not disable the port immediately when a BPDU is received on an edge port.

UDLD is incorrect because it detects unidirectional physical link failures and does not interact with BPDU processing or disable ports based on BPDU reception.