Which Cisco IOS extended access list command will correctly stop host 172.16.10.1 from initiating Telnet sessions to host 172.16.30.5 while leaving other traffic between these hosts unaffected?

Introduction / Context:
Extended access lists on Cisco routers allow precise control over which conversations are permitted or denied by matching protocol, source, destination and port. In this scenario, the goal is to block only Telnet traffic from one specific internal host to another, without affecting other protocols such as ping or HTTP between the same addresses. This level of granularity is exactly what extended ACLs are designed to provide.

Given Data / Assumptions:

Source host to block: 172.16.10.1.
Destination host to protect: 172.16.30.5.
Protocol to deny: Telnet, which uses TCP port 23.
You are creating an extended ACL, so the list number should be in the 100 to 199 range, for example 101.

Concept / Approach:
An extended ACL entry that achieves this should specify tcp, the source as host 172.16.10.1, the destination as host 172.16.30.5 and a destination port of 23 or keyword telnet. The host keyword is a clean way to indicate a single IP address without writing a wildcard mask. Other traffic between these hosts should be allowed by subsequent permit statements, so this deny entry should target only the Telnet protocol.

Step-by-Step Solution:
Start with the extended ACL number and action: access-list 101 deny. Specify the protocol as tcp because Telnet runs over TCP. Use host 172.16.10.1 to match exactly the sending host. Use host 172.16.30.5 to match exactly the receiving host. Finish with eq 23 to match only Telnet traffic rather than all TCP ports. Putting these together yields access-list 101 deny tcp host 172.16.10.1 host 172.16.30.5 eq 23, which is option a.

Verification / Alternative check:
If you configure this ACL and apply it appropriately on a router interface in the path, Telnet sessions from 172.16.10.1 to 172.16.30.5 should fail, while pings and web access between the same hosts can succeed, assuming other permits are present. This behaviour shows that only the Telnet port is being filtered, confirming that the ACL line is properly specific.

Why Other Options Are Wrong:
Option b uses ip instead of tcp for the protocol but then incorrectly appends eq 23. Access lists using ip as the protocol do not specify ports, so this syntax is invalid and would not selectively block Telnet.

Common Pitfalls:
Option c uses list number 1, which corresponds to a standard ACL that should not include port information, and its syntax attempts to combine wildcards and ports in a way that does not match IOS conventions.
Option d blocks Telnet from any source to host 172.16.30.5, which is broader than required and would also block Telnet from other hosts that should perhaps be permitted.
Option e actually permits Telnet between the two hosts, which is the opposite of the stated requirement.

Common Pitfalls:
It is easy to mix up the order of source and destination fields or to forget to narrow the rule using host or proper wildcard masks. Another frequent error is to use a standard ACL for tasks that clearly require protocol and port awareness, which only extended ACLs can provide. Remember that port numbers are only valid in ACL entries when you specify a transport layer protocol like tcp or udp.

Final Answer:
The correct command is access-list 101 deny tcp host 172.16.10.1 host 172.16.30.5 eq 23, which blocks only Telnet between those two hosts.