200-301 Access Control List (ACL) Scenarios

Explanation: The main issues: (1) Interfaces were swapped — G0/0 (public) was inside and G0/1 (private) was outside. They should be reversed: G0/0 outside, G0/1 inside. (2) ACL 1 (used in the PAT command) permitted 192.168.2.0/24 instead of 192.168.1.0/24. (3) The PAT command for G0/0 used ACL 2, which was correct for the subnet but the interface was wrong. After fixing interface assignments and correcting ACL 1 to permit the inside subnet, the PAT command must use ACL 1 and the correct outside interface. The static NAT was correctly configured but needed the correct inside interface. The PAT translation uses the IP address of the outside interface (interface overload), so after fixing the configuration, inside hosts will be translated to 203.0.113.1, the primary IP of G0/0, not 203.0.113.5.

Explanation: The ACL matches the wrong inside subnet. NAT overload will only translate traffic that matches the source list or route map tied to the NAT statement. The interfaces are marked inside and outside correctly, so the bad match criteria is the most likely failure point.

Explanation: The problem is that the router has the NAT directions backwards. In simple terms, the interface facing the private LAN should be marked as inside, and the interface facing the public or WAN side should be marked as outside. Here, GigabitEthernet0/0 uses the private address 192.168.10.1, but it is configured as outside. GigabitEthernet0/1 uses the public address 203.0.113.10, but it is configured as inside. That reverses the translation logic and breaks normal PAT behavior. Technically, the command `ip nat inside source list 1 interface GigabitEthernet0/1 overload` is otherwise reasonable for dynamic PAT using the WAN interface address. The ACL also correctly identifies the inside local subnet. The essential fix is to mark G0/0 as `ip nat inside` and G0/1 as `ip nat outside`. Once the directions are corrected, PAT can create and track translations properly for outbound traffic and returning sessions.

Explanation: Permitting SSH while blocking Telnet is a hardening decision because SSH encrypts management traffic and Telnet does not. The administrator wants remote access to remain available with credentials and session data protected. Option A is correct: SSH provides encrypted remote administration. Option B is wrong: Telnet offers no confidentiality. Option C is wrong: SSH works on routers and Layer 3 switches, not only Layer 2 switches. Option D is wrong: blocking Telnet does not disable AAA; AAA can still function over SSH or local authentication.

Explanation: The most important principle is to write the ACL as narrowly as possible so it matches only the unwanted traffic and does not overblock unrelated traffic. In practical terms, the rule should target the specific destination and service being denied rather than using a broader deny that unintentionally blocks other communication. This is a precision-and-scope question. Good ACL design is as much about what you avoid blocking as what you intend to block.