200-301 ACL Practice Questions

Explanation: Extended IPv4 ACLs filter on source and destination IP addresses, ports, and protocols, so placing them as close to the source as possible prevents unwanted traffic from traversing the network, reducing bandwidth waste and security risks. This is a best practice for extended ACLs, unlike standard ACLs which should be placed close to the destination.

Explanation: Standard ACLs filter traffic based solely on the source IP address, using numbers 1–99 or 1300–1999 in classic Cisco IOS. They do not consider destination IP, protocol, or port numbers. Because they lack granularity, placing them close to the destination (option D) prevents them from inadvertently blocking traffic that should be permitted, as they cannot distinguish between traffic destined for different services on the same destination host.

Explanation: A VLAN can still fail across a trunk even when it is allowed because the allowed list is only one part of the overall design. In plain language, a switch may permit the VLAN on the link, but if the VLAN does not actually exist locally, is not active, or if some other trunk characteristic is inconsistent, traffic can still fail. This is an important CCNA troubleshooting principle: one correct line of configuration does not guarantee the full end-to-end condition is correct. Candidates often stop at the allowed VLAN list because it is visible in common show commands. However, VLAN presence, local status, and other trunk parameters still matter. The best answer is the one recognizing that permission on the trunk does not automatically prove the entire VLAN path is healthy.

Explanation: The strongest first target is the application path or policy specific to that application because the client already has general connectivity: it joined the correct SSID, authenticated, and obtained an IP address in the employee subnet. A failure limited to one internal application indicates that basic WLAN join, DHCP, and overall routing are working; therefore, ACLs, firewall rules, DNS resolution for that service, or application-specific policies are the likely cause. Option B (SSID broadcast setting) is irrelevant because the client successfully joined the SSID and has connectivity. Option C (voice VLAN on the wired access port) is not a first target because the symptom involves a single data application, not voice, and the client is on the employee subnet, not a voice VLAN. Option D (OSPF router ID on the client) is invalid because client devices do not typically run OSPF; OSPF runs on routers, not wireless clients.

Explanation: An extended ACL is most strongly indicated when the policy must match not just on source address, but also on destination, protocol, or port information. In practical terms, if the requirement is something like “block HTTP but allow SSH” or “deny traffic to one server but not another,” a standard ACL is too limited because it mainly matches only the source. Option B (matching only one source subnet) can be done with a standard ACL, so it does not demand an extended ACL. Option C (placement near destination) is a guideline for standard ACLs, not a reason to choose an extended ACL. Option D (IPv6) is irrelevant because the scenario explicitly states both ACL types are available and standard ACLs do not exist for IPv6—this question is about IPv4 ACLs.