How many Access Control List (ACL) Scenarios questions are on this page?

This page has 15 Access Control List (ACL) Scenarios scenario questions for the 200-301 exam, each with detailed explanations and wrong-answer analysis.

How should I approach 200-301 scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to CCNA 200-301 v2 questions

Scenario-based practice

Access Control List (ACL) Scenarios

Practise 200-301 ACL questions covering standard vs extended ACLs, top-down processing, implicit deny, inbound vs outbound placement, and troubleshooting traffic that is unexpectedly blocked or permitted.

Start full practice test Read exam guide

scenario questions

200-301

exam code

Cisco

vendor

Scenario guide

How to approach access control list (acl) scenarios

ACL questions test your ability to read, write, and place access lists correctly. They appear as configuration tasks, troubleshooting scenarios, and exhibit-based questions showing ACL output. The CCNA covers standard and extended ACLs for both IPv4 and IPv6.

Quick answer

ACL questions usually test top-down rule processing, source and destination matching, protocol or port logic, and where the ACL should be applied.

Standard versus extended ACL behaviour.

Top-down processing and the implicit deny rule.

Source, destination, protocol and port matching.

Inbound versus outbound ACL placement.

Practice scenarios

Question 1hardScenario

Study the full ACL explanation →

You are connected to R1 in a small office network. Configure PAT (NAT overload) so that hosts on the 192.168.1.0/24 LAN can access the Internet via the public IP 203.0.113.1 (the IP assigned to interface G0/0). Also configure a static NAT for the internal web server at 192.168.1.10 to the public IP 203.0.113.6. The current configuration has errors: the inside/outside interface assignments are swapped, the ACL for PAT does not match the inside subnet, and the PAT rule points to the wrong ACL. Fix all issues so that both PAT and static NAT work correctly.

Exhibit

R1# show running-config | section ip nat
ip nat inside source list 1 interface GigabitEthernet0/1 overload
ip nat inside source static tcp 192.168.1.10 80 203.0.113.6 80
!
ip nat inside source list 2 interface GigabitEthernet0/0 overload
!
interface GigabitEthernet0/0
 ip address 203.0.113.1 255.255.255.248
 ip nat inside
!
interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 ip nat outside
!
access-list 1 permit 192.168.2.0 0.0.0.255
access-list 2 permit 192.168.1.0 0.0.0.255

A
Configure G0/0 as outside, G0/1 as inside; modify ACL 1 to permit 192.168.1.0 0.0.0.255; apply ip nat inside source list 1 interface G0/0 overload; keep ip nat inside source static 192.168.1.10 203.0.113.6
This correctly sets the outside interface (G0/0) and inside interface (G0/1), corrects the ACL to match the LAN subnet, and applies PAT using the correct ACL and outside interface. The static NAT is already correctly configured.
B
Configure G0/0 as inside, G0/1 as outside; modify ACL 1 to permit 192.168.1.0 0.0.0.255; apply ip nat inside source list 1 interface G0/1 overload; keep ip nat inside source static 192.168.1.10 203.0.113.6
Why wrong: This is incorrect because the interface assignments are swapped: G0/0 (public) should be outside, not inside. PAT must be applied to the outside interface (G0/0), not G0/1.
C
Configure G0/0 as outside, G0/1 as inside; modify ACL 1 to permit 192.168.2.0 0.0.0.255; apply ip nat inside source list 1 interface G0/0 overload; keep ip nat inside source static 192.168.1.10 203.0.113.6
Why wrong: This is incorrect because ACL 1 still permits the wrong subnet (192.168.2.0/24) instead of the correct inside subnet (192.168.1.0/24). PAT would not translate traffic from the LAN.
D
Configure G0/0 as outside, G0/1 as inside; modify ACL 1 to permit 192.168.1.0 0.0.0.255; apply ip nat inside source list 2 interface G0/0 overload; keep ip nat inside source static 192.168.1.10 203.0.113.6
Why wrong: This is incorrect because the PAT command references ACL 2, but ACL 2 is not defined or does not match the inside subnet. The correct ACL is ACL 1 after modification.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full NAT/PAT explanation →

A branch router is configured for NAT overload. The inside interface Gi0/0 is correctly marked ip nat inside, and the outside interface Gi0/1 is ip nat outside. The NAT statement uses access-list 1 permit 10.1.1.0 0.0.0.255 with ip nat inside source list 1 interface Gi0/1 overload. Inside hosts are in the 192.168.1.0/24 subnet and still reach the ISP with their private addresses. What is the most likely reason?

Exhibit

access-list 1 permit 10.10.20.0 0.0.0.255
ip nat inside source list 1 interface GigabitEthernet0/0 overload

interface GigabitEthernet0/0
 ip address 198.51.100.2 255.255.255.252
 ip nat outside

interface GigabitEthernet0/1
 ip address 10.10.10.1 255.255.255.0
 ip nat inside

Users are in 10.10.10.0/24.

A
The ACL used for NAT does not match the inside client subnet.
The overload statement references ACL 1, but ACL 1 permits 10.10.20.0/24 instead of 10.10.10.0/24.
B
GigabitEthernet0/0 should be configured as ip nat inside.
Why wrong: The ISP-facing interface is correctly marked outside.
C
PAT cannot use an interface address as the translated source.
Why wrong: That is exactly how NAT overload commonly works.
D
The router must run OSPF before NAT overload can function.
Why wrong: NAT does not require OSPF.

Full breakdown with real-world context →

Question 3mediummultiple choice

Read the full NAT/PAT explanation →

Refer to the exhibit. Users on the inside network can browse the web, but return traffic is failing for some sessions. A partial configuration shows:

interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.0
 ip nat outside

interface GigabitEthernet0/1
 ip address 203.0.113.10 255.255.255.0
 ip nat inside

ip nat inside source list 1 interface GigabitEthernet0/1 overload
access-list 1 permit 192.168.10.0 0.0.0.255

Based on this configuration, which change is required to make PAT work correctly?

Exhibit

interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.0
 ip nat outside
!
interface GigabitEthernet0/1
 ip address 203.0.113.10 255.255.255.252
 ip nat inside
!
access-list 1 permit 192.168.10.0 0.0.0.255
ip nat inside source list 1 interface GigabitEthernet0/1 overload

A
Apply ip nat enable on both interfaces.
Why wrong: `ip nat enable` is not the normal Cisco IOS syntax used for classic inside/outside NAT in this scenario. The directional role assignment is what needs correction.
B
Replace overload with pool.
Why wrong: Using a pool is another NAT design option, but it is not required for PAT to work. The current command already uses interface overload, which is valid. The failure is caused by reversed inside and outside roles.
C
Swap the inside and outside NAT roles on the two interfaces.
This is correct because NAT depends on the router knowing which side is private and which side is public. The current configuration labels them the wrong way round. PAT with overload on the WAN interface is fine, but the interface roles must match the traffic direction.
D
Change access-list 1 to a standard ACL numbered 100.
Why wrong: Standard ACL 1 is already valid for identifying inside local addresses. There is no requirement to use ACL 100 for this kind of NAT rule. The bigger issue is that the interfaces are assigned the wrong NAT roles.

Full breakdown with real-world context →

Question 4hardmultiple choice

Full question →

An administrator wants to permit SSH management access but block Telnet access to a device. Which statement best reflects that design goal?

A
SSH is preferred because it provides encrypted remote administration, unlike Telnet
This is correct because SSH protects management traffic with encryption, while Telnet sends it in clear text.
B
Telnet is preferred because it provides stronger confidentiality than SSH
Why wrong: This is wrong because Telnet does not provide stronger confidentiality. It is less secure because it is unencrypted.
C
SSH can be used only on Layer 2 switches and not routers
Why wrong: This is wrong because SSH is widely used on both routers and switches.
D
Blocking Telnet automatically disables all AAA functions
Why wrong: This is wrong because disabling Telnet does not automatically disable AAA mechanisms.

Full breakdown with real-world context →

Question 5hardmultiple choice

Study the full ACL explanation →

An administrator wants to prevent users from browsing to one specific web server while still allowing them to reach other web destinations. Which ACL design principle is most important here?

A
Use the narrowest possible match so only the intended traffic is denied.
This is correct because precise ACL design reduces unintended side effects.
B
Always deny all IP traffic to the destination subnet first.
Why wrong: This is wrong because it may overblock beyond the requirement.
C
Use a standard ACL because destination details never matter.
Why wrong: This is wrong because destination detail matters greatly in this scenario.
D
Place the ACL only where no routing exists.
Why wrong: This is wrong because the key issue here is match precision, not that rule.

Full breakdown with real-world context →

Question 6mediummulti select

Study the full ACL explanation →

A network team wants an ACL that permits HTTPS from 10.1.50.0/24 to a web server at 203.0.113.10 and denies all Telnet traffic from that subnet to any destination. Which two ACEs are required?

A
permit tcp 10.1.50.0 0.0.0.255 host 203.0.113.10 eq 443
This permits HTTPS from that subnet to the specific web server.
B
deny tcp 10.1.50.0 0.0.0.255 any eq 23
This blocks Telnet from that subnet to any destination.
C
permit udp 10.1.50.0 0.0.0.255 host 203.0.113.10 eq 443
Why wrong: HTTPS uses TCP, not UDP.
D
deny tcp any 10.1.50.0 0.0.0.255 eq 23
Why wrong: That blocks inbound Telnet toward the subnet, not outbound sessions from it.
E
permit ip any any
Why wrong: That would be too broad as part of the stated requirement.

Full breakdown with real-world context →

Question 7hardmultiple choice

Study the full ACL explanation →

A standard ACL and an extended ACL are both available for a design. Which requirement most strongly indicates that an extended ACL is needed?

A
The policy must distinguish traffic by destination, protocol, or port.
This is correct because those requirements need extended ACL granularity.
B
The policy needs to match only one source subnet.
Why wrong: This is wrong because source-only matching is exactly where a standard ACL may be enough.
C
The ACL must be placed near the destination.
Why wrong: This is wrong because placement guidance does not by itself determine the ACL type.
D
The network uses IPv6 instead of IPv4.
Why wrong: This is wrong because the underlying need here is still about match detail, not that distinction.

Full breakdown with real-world context →

Question 8mediummultiple choice

Study the full ACL explanation →

An ACL entry reads:

access-list 25 permit 192.168.8.0 0.0.0.15

Which address range does this statement match?

A
192.168.8.0 through 192.168.8.15
That is the correct range for a wildcard of 0.0.0.15.
B
192.168.8.0 through 192.168.8.31
Why wrong: That would match a wildcard of 0.0.0.31.
C
192.168.8.0 through 192.168.8.7
Why wrong: The range starts at .0, not .8.
D
Only host 192.168.8.15
Why wrong: A host match would use a wildcard of 0.0.0.0.

Full breakdown with real-world context →

Question 9hardmultiple choice

Study the full ACL explanation →

An ACL is intended to block Telnet from 10.1.1.0/24 to router VTY access while still allowing SSH from the same subnet. Which statement best explains why an extended ACL is appropriate here?

A
Because the ACL must distinguish traffic by protocol or destination port, not just by source address.
This is correct because Telnet-versus-SSH filtering requires extended matching capability.
B
Because standard ACLs can match destination TCP ports just as well.
Why wrong: This is wrong because standard ACLs do not provide that level of granularity.
C
Because extended ACLs are required for every router login policy regardless of criteria.
Why wrong: This is wrong because the need depends on the matching requirement.
D
Because SSH and Telnet always use the same port number.
Why wrong: This is wrong because they use different TCP ports.

Full breakdown with real-world context →

Question 10easymultiple choice

Study the full ACL explanation →

An ACL on R1 contains only these entries:

access-list 101 permit tcp 10.10.10.0 0.0.0.255 any eq 443
access-list 
101 permit icmp any any

What happens to an HTTP packet sourced from 10.10.10.25 and destined for 198.51.100.10 if ACL 101 is applied in the traffic path?

A
It is permitted because the source subnet is allowed.
Why wrong: The ACL is not permitting the source subnet broadly; it is permitting only TCP 443 from that subnet.
B
It is denied by the implicit deny.
The packet does not match either permit entry, so the implicit deny drops it.
C
It is translated by NAT before the ACL is checked.
Why wrong: NAT behavior depends on placement and is not the point of this ACL question.
D
It is converted to HTTPS automatically.
Why wrong: Routers do not rewrite application protocols in that way.

Full breakdown with real-world context →

Question 11hardmultiple choice

Study the full ACL explanation →

A named standard ACL is configured to permit only the 192.168.30.0/24 subnet, but users from 192.168.31.0/24 are still passing traffic. What is the most likely reason?

Exhibit

ip access-list standard USERS_ONLY
 permit 192.168.30.0 0.0.0.255
 deny any

interface g0/1
 ip access-group USERS_ONLY out

A
Standard ACLs cannot match source addresses
Why wrong: That is exactly what they match.
B
The ACL is probably applied in the wrong place or direction for the traffic flow
ACL placement matters a lot with standard ACLs.
C
Named ACLs ignore wildcard masks
Why wrong: They do not.
D
The deny any line must appear before the permit
Why wrong: That would block everything.

Full breakdown with real-world context →

Question 12mediumdrag order

Study the full ACL explanation →

Drag and drop the following steps into the correct order to configure and apply an extended IPv4 ACL on a Cisco router to block Telnet traffic from subnet 192.168.1.0/24 to host 10.0.0.1 and permit all other IP traffic.

Question 13hardScenario

Study the full ACL explanation →

You are connected to R1. The network has a web server at 203.0.113.10 and a DNS server at 203.0.113.20. Hosts in the 192.168.1.0/24 subnet should be able to access HTTP to the web server and DNS queries to the DNS server, but all other traffic from that subnet to the servers must be blocked. Configure an extended ACL on R1 to achieve this, and apply it inbound on the correct interface. The current configuration is shown below.

Exhibit

hostname R1
!
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 no shutdown
!
interface GigabitEthernet0/1
 ip address 203.0.113.1 255.255.255.0
 no shutdown
!
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1
!

A
access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 access-list 100 permit udp 192.168.1.0 0.0.0.255 host 203.0.113.20 eq 53 access-list 100 deny ip 192.168.1.0 0.0.0.255 203.0.113.0 0.0.0.255 interface GigabitEthernet0/0 ip access-group 100 in
This ACL permits HTTP to the web server and DNS to the DNS server, then denies all other IP traffic from the 192.168.1.0/24 subnet to the 203.0.113.0/24 network. It is applied inbound on GigabitEthernet0/0, which is the interface facing the 192.168.1.0/24 subnet, ensuring traffic is filtered as it enters R1.
B
access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 access-list 100 permit udp 192.168.1.0 0.0.0.255 host 203.0.113.20 eq 53 access-list 100 deny ip any any interface GigabitEthernet0/1 ip access-group 100 in
Why wrong: This ACL denies all IP traffic from any source, which would block the permitted traffic as well. Additionally, it is applied inbound on GigabitEthernet0/1, which is likely the interface facing the servers, not the subnet. The deny ip any any at the end would block everything, making the permit statements ineffective.
C
access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 access-list 100 permit udp 192.168.1.0 0.0.0.255 host 203.0.113.20 eq 53 access-list 100 deny ip 192.168.1.0 0.0.0.255 203.0.113.0 0.0.0.255 interface GigabitEthernet0/0 ip access-group 100 out
Why wrong: This ACL is applied outbound on GigabitEthernet0/0, which means it filters traffic leaving R1 through that interface. However, the traffic from the 192.168.1.0/24 subnet destined to the servers would exit via GigabitEthernet0/1 (or another interface), not GigabitEthernet0/0. Applying it outbound on the wrong interface would not filter the traffic as intended.
D
access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 203.0.113.10 eq 80 access-list 100 permit udp 192.168.1.0 0.0.0.255 host 203.0.113.20 eq 53 access-list 100 deny ip 192.168.1.0 0.0.0.255 203.0.113.0 0.0.0.255 interface GigabitEthernet0/1 ip access-group 100 in
Why wrong: This ACL is applied inbound on GigabitEthernet0/1, which is the interface facing the servers. Inbound ACLs filter traffic entering the router through that interface. Traffic from the 192.168.1.0/24 subnet arrives via GigabitEthernet0/0, not GigabitEthernet0/1, so this ACL would not filter that traffic.

Full breakdown with real-world context →

Question 14hardScenario

Study the full ACL explanation →

You are connected to R1. The network has two routers (R1 and R2) connected via a serial link (S0/0/0). R1's GigabitEthernet0/0 connects to the 192.168.1.0/24 LAN. An extended ACL must be configured on R1 to permit only HTTPS traffic (TCP port 443) from host 192.168.1.10 to server 203.0.113.5 (reachable via R2), and deny all other traffic from the LAN to the server. Currently, the ACL is applied inbound on G0/0 but valid HTTPS traffic is being blocked. Troubleshoot and fix the configuration.

Exhibit

R1# show running-config | section interface GigabitEthernet0/0
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip access-group BLOCK_SERVER in
 duplex auto
 speed auto
!
R1# show running-config | section ip access-list
ip access-list extended BLOCK_SERVER
 deny tcp any host 203.0.113.5 eq 80
 permit ip any any
!

A
The ACL is missing an explicit permit statement for HTTPS traffic from host 192.168.1.10 to server 203.0.113.5, and the current permit ip any any allows all traffic, including HTTP, which violates the requirement to deny HTTP.
The correct fix is to add a permit statement for HTTPS (TCP port 443) from the specific host to the server, and then deny HTTP (port 80) from that host to the server, while still allowing other traffic with permit ip any any. The current ACL permits everything, so HTTPS is allowed, but HTTP is also allowed, which should be denied. The problem described says HTTPS is blocked, which suggests the ACL might be misapplied or the implicit deny is blocking HTTPS if the permit ip any any is removed. However, the most likely issue is that the ACL is too permissive and does not meet the requirement to deny HTTP. To fix, the ACL should explicitly permit HTTPS and deny HTTP from that host.
B
The ACL is applied inbound on G0/0, but it should be applied outbound on G0/0 to filter traffic leaving the LAN.
Why wrong: This is incorrect because applying the ACL inbound on G0/0 is appropriate for filtering traffic entering the router from the LAN. The traffic from the LAN to the server enters R1 via G0/0, so inbound application is correct.
C
The ACL should be applied to the serial interface S0/0/0 instead of G0/0 to filter traffic going to R2.
Why wrong: This is incorrect because applying the ACL on S0/0/0 would filter traffic after it has already been routed, but the requirement is to filter traffic from the LAN before it leaves the router. Applying on G0/0 inbound is more efficient and standard.
D
The ACL is missing a deny statement for all other traffic from the LAN to the server, and the permit ip any any allows everything, including unwanted traffic.
Why wrong: This is incorrect because the requirement is to permit only HTTPS and deny all other traffic from the LAN to the server. The current ACL permits all traffic (including HTTPS) but also permits HTTP and other traffic to the server. However, the problem states that HTTPS is blocked, not that HTTP is allowed. So the issue is not that other traffic is allowed, but that HTTPS is blocked. The missing deny statement for other traffic is not the cause of HTTPS being blocked.

Full breakdown with real-world context →

Question 15hardScenario

Study the full ACL explanation →

You are connected to R1. The network has two routers (R1, R2) and a switch (SW1) in between. R1's G0/0 connects to SW1 (192.168.1.1/24), SW1 connects to R2's G0/0 (192.168.1.2/24). R2 has a loopback (Lo0: 203.0.113.1/32) used as a management address. Configure an extended ACL on R1 so that only SSH (TCP/22) traffic from the 10.0.0.0/24 network is permitted to reach R2's loopback; all other traffic to that loopback must be denied. Then apply the ACL in the correct direction on the correct interface.

Exhibit

R1# show running-config | section interface
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 no shutdown
!
interface GigabitEthernet0/1
 ip address 10.0.0.1 255.255.255.0
 no shutdown
!
R1# show ip route
Codes: L - local, C - connected, S - static
      10.0.0.0/24 is subnetted, 1 subnets
C        10.0.0.0/24 is directly connected, GigabitEthernet0/1
      192.168.1.0/24 is subnetted, 1 subnets
C        192.168.1.0/24 is directly connected, GigabitEthernet0/0
      203.0.113.1/32 [1/0] via 192.168.1.2

A
access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 access-list 100 deny ip any host 203.0.113.1 interface GigabitEthernet0/1 ip access-group 100 in
This ACL permits SSH (TCP/22) from the 10.0.0.0/24 network to the loopback address 203.0.113.1, then denies all other IP traffic to that host. Applying it inbound on G0/1 (facing the 10.0.0.0/24 network) filters traffic before it enters R1, which is efficient and standard practice.
B
access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 access-list 100 deny ip any host 203.0.113.1 interface GigabitEthernet0/0 ip access-group 100 out
Why wrong: This is incorrect because applying the ACL outbound on G0/0 (facing SW1) would filter traffic leaving R1 toward R2. While it could work, it is less efficient because the traffic has already been routed through R1. Additionally, the implicit deny at the end of the ACL would block all other traffic to the loopback, but the outbound application is not the recommended direction.
C
access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 interface GigabitEthernet0/1 ip access-group 100 in
Why wrong: This is incorrect because it lacks the explicit deny statement for all other IP traffic to the loopback. Without the deny, the implicit deny at the end of the ACL will block all other traffic, but the explicit deny is necessary to clearly show the requirement is met. More importantly, the ACL does not deny traffic from other sources to the loopback; the implicit deny only applies to the ACL itself, but the question requires explicit denial.
D
access-list 100 permit tcp 10.0.0.0 0.0.0.255 host 203.0.113.1 eq 22 access-list 100 deny ip any any interface GigabitEthernet0/1 ip access-group 100 in
Why wrong: This is incorrect because the deny statement 'deny ip any any' blocks all IP traffic, including traffic to other destinations, not just the loopback. The requirement is to deny only traffic to the loopback, not all traffic. This would break connectivity for other traffic.

Full breakdown with real-world context →

These 200-301 practice questions are part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style 200-301 questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Access Control List (ACL) Scenarios

How to approach access control list (acl) scenarios

Quick answer

Related 200-301 topic practice pages

Network Infrastructure and Connectivity practice questions

Switching and Network Access practice questions

IP Routing practice questions

Network Services and Security practice questions

AI and Network Operations practice questions

CCNA subnetting practice questions

CCNA OSPF practice questions

CCNA VLAN practice questions

CCNA STP practice questions

CCNA EtherChannel practice questions

CCNA ACL practice questions

CCNA NAT practice questions

Practice scenarios

Exhibit

Exhibit

Exhibit

An administrator wants to permit SSH management access but block Telnet access to a device. Which statement best reflects that design goal?

An administrator wants to prevent users from browsing to one specific web server while still allowing them to reach other web destinations. Which ACL design principle is most important here?

A network team wants an ACL that permits HTTPS from 10.1.50.0/24 to a web server at 203.0.113.10 and denies all Telnet traffic from that subnet to any destination. Which two ACEs are required?

A standard ACL and an extended ACL are both available for a design. Which requirement most strongly indicates that an extended ACL is needed?

An ACL is intended to block Telnet from 10.1.1.0/24 to router VTY access while still allowing SSH from the same subnet. Which statement best explains why an extended ACL is appropriate here?

A named standard ACL is configured to permit only the 192.168.30.0/24 subnet, but users from 192.168.31.0/24 are still passing traffic. What is the most likely reason?

Exhibit

Drag and drop the following steps into the correct order to configure and apply an extended IPv4 ACL on a Cisco router to block Telnet traffic from subnet 192.168.1.0/24 to host 10.0.0.1 and permit all other IP traffic.

Exhibit

Exhibit

Exhibit