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 300-410 exam, each with detailed explanations and wrong-answer analysis.

How should I approach 300-410 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 Cisco CCNP ENARSI 300-410 questions

Scenario-based practice

Access Control List (ACL) Scenarios

Practise 300-410 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

300-410

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 1mediumdrag order

Full question →

Drag and drop the steps to troubleshoot Device Access Control adjacency or connectivity failures into the correct order, from first to last.

Question 2mediumdrag order

Full question →

Drag and drop the steps to verify and validate Device Access Control operational state into the correct order, from first to last.

Question 3harddrag order

Study the full ACL explanation →

Drag and drop the steps to troubleshoot IPv4 ACL adjacency or connectivity failures into the correct order, from first to last.

Question 4mediumdrag order

Study the full ACL explanation →

Drag and drop the steps to apply and verify an extended IPv4 ACL on a router interface into the correct order, from first to last.

Question 5mediummultiple choice

Study the full ACL explanation →

A network engineer is troubleshooting a connectivity issue between two routers R1 and R2 connected via GigabitEthernet0/0. The engineer notices that R1 can ping its own IPv6 address 2001:db8:1::1/64, but cannot ping R2's interface address 2001:db8:1::2/64. The output of 'show ipv6 interface GigabitEthernet0/0' on R1 indicates that IPv6 is enabled and the interface is up/up. The engineer checks the access list applied to the interface and sees an inbound IPv6 ACL that permits only ICMPv6 echo requests from a specific source. What is the most likely cause of the ping failure?

A
The ACL is applied inbound on R1 and does not permit ICMPv6 echo replies from R2.
Correct because ICMPv6 echo replies are sourced from the destination address (R2) and must be permitted inbound on R1 for the ping to succeed.
B
The ACL is applied outbound on R1 and blocks the echo request.
Why wrong: Incorrect because the ACL is applied inbound, not outbound.
C
IPv6 unicast-routing is not enabled on R1.
Why wrong: Incorrect because R1 can ping its own address, indicating IPv6 is operational; unicast-routing is not required for direct link pings.
D
The ACL is missing a permit statement for IPv6 neighbor discovery (ND) messages.
Why wrong: Incorrect because ND messages are needed for address resolution, but the symptom is a ping failure after ND has likely succeeded (R1 can ping its own address, implying layer 2 is up).

Full breakdown with real-world context →

Question 6mediummultiple choice

Study the full IPv6 explanation →

Consider the following configuration:

ipv6 access-list FILTER

permit ipv6 2001:db8:3::/48 any
 deny ipv6 any any

interface GigabitEthernet0/5

ipv6 traffic-filter FILTER in ipv6 verify unicast source reachable-via rx

A packet arrives on GigabitEthernet0/5 with source 2001:db8:3::100 and destination 2001:db8:4::1. The route for 2001:db8:3::/48 points out interface GigabitEthernet0/6. What happens?

A
The packet is permitted because the ACL matches and uRPF is not applied.
Why wrong: uRPF is applied; both ACL and uRPF must pass.
B
The packet is dropped by uRPF because strict mode requires the source to be reachable via the receiving interface.
Strict uRPF (rx) fails because the return route uses a different interface.
C
The packet is dropped by the ACL because the deny statement blocks all traffic.
Why wrong: The permit statement matches the source prefix, so the ACL permits the packet.
D
The packet is permitted because uRPF only checks destination addresses.
Why wrong: uRPF checks the source address, not the destination.

Full breakdown with real-world context →

Question 7mediummultiple choice

Study the full IPv6 explanation →

Review this configuration:

route-map RMAP permit 10 match ipv6 address prefix-list PREFIX set interface null0 ! ipv6 prefix-list PREFIX seq 5 permit 2001:db8:5::/48 !

interface GigabitEthernet0/6

ipv6 verify unicast source reachable-via any allow-default

What is the purpose of the 'allow-default' keyword?

A
It allows uRPF to use the default route as a valid path for source reachability.
Normally, loose uRPF ignores default routes; 'allow-default' includes them.
B
It allows the router to accept packets with source addresses from the default prefix.
Why wrong: The default route is ::/0, not a specific prefix; the keyword affects how uRPF treats default routes.
C
It disables uRPF for packets matching the default route.
Why wrong: It does the opposite: it enables uRPF to consider the default route as valid.
D
It is used to allow multicast traffic through uRPF.
Why wrong: The 'allow-default' keyword is specific to default route handling, not multicast.

Full breakdown with real-world context →

Question 8easymultiple choice

Study the full IPv6 explanation →

In IPv6, what is the default action for an access-list entry that does not specify a protocol?

A
The ACE defaults to 'permit ipv6'.
Why wrong: There is no default protocol; the ACE must explicitly specify a protocol.
B
The ACE is invalid and ignored.
Cisco IOS requires a protocol in each IPv6 ACL entry; without it, the entry is invalid.
C
The ACE defaults to 'deny ipv6'.
Why wrong: No default protocol is assumed; the entry is simply invalid.
D
The ACE matches all IPv6 traffic.
Why wrong: Only the 'ipv6' keyword matches all IPv6 traffic; omitting the protocol makes the entry invalid.

Full breakdown with real-world context →

Question 9mediummulti select

Study the full ACL explanation →

Which TWO configuration steps are required to implement IPv6 traffic filtering using a named ACL on a Cisco router? (Choose TWO.)

A
Create the ACL using the ipv6 access-list command.
Correct: 'ipv6 access-list NAME' enters IPv6 ACL configuration mode.
B
Apply the ACL to the interface using the ipv6 traffic-filter command.
Correct: 'ipv6 traffic-filter NAME in' or 'out' applies the ACL.
C
Create the ACL using the access-list command.
Why wrong: The 'access-list' command is for IPv4, not IPv6.
D
Apply the ACL to the interface using the ip access-group command.
Why wrong: The 'ip access-group' command is for IPv4 ACLs.
E
Apply the ACL to the interface using the ipv6 access-group command.
Why wrong: There is no 'ipv6 access-group' command; the correct command is 'ipv6 traffic-filter'.

Full breakdown with real-world context →

Question 10hardmultiple choice

Review the full OSPF breakdown →

A large enterprise network uses OSPFv3 for IPv6 routing. Router R1 and R2 are connected via a multi-access Ethernet link. R1 is configured with 'ipv6 ospf network point-to-point' while R2 uses the default broadcast network type. R1 has an IPv6 ACL applied inbound on its interface that permits only OSPF (89) and denies all other traffic. R2 is unable to form a full OSPF adjacency with R1. R2 shows 'OSPFv3 adjacency state is EXSTART/EXCHANGE' and logs 'Bad LSReq'. What is the root cause?

A
R1's ACL blocks OSPFv3 multicast hello packets (FF02::5), preventing adjacency formation on the broadcast link.
On a broadcast network, OSPFv3 sends hellos to FF02::5. R1's ACL permits only OSPF protocol, but the destination address is filtered because the ACL does not explicitly permit multicast. The network type mismatch exacerbates the issue as R1 expects unicast hellos.
B
R2's OSPFv3 process is configured with a different router-id, causing a DR election conflict.
Why wrong: Router-id mismatch would not cause 'Bad LSReq' specifically; it would affect neighbor state earlier.
C
The MTU mismatch between R1 and R2 causes OSPFv3 packet fragmentation, leading to LSReq errors.
Why wrong: MTU mismatch typically causes 'Bad LSA' or adjacency stuck in EXSTART, not specifically 'Bad LSReq'.
D
R2 has a passive interface configured, preventing it from sending OSPFv3 hellos.
Why wrong: A passive interface would prevent neighbor discovery entirely, not cause EXSTART/EXCHANGE state.

Full breakdown with real-world context →

Question 11hardmultiple choice

Study the full EIGRP explanation →

A DMVPN network uses IPv6 with EIGRP as the routing protocol. Spoke routers R2 and R3 are behind NAT and use mGRE tunnels. The hub R1 has an IPv6 ACL applied inbound on the tunnel interface that permits only EIGRP and denies all other IPv6 traffic. Spoke-to-spoke traffic fails even though direct tunnels are established. R2 shows 'ping 2001:db8:3::1 source loopback0' fails, but 'ping 2001:db8:1::1' (hub) succeeds. What is the root cause?

A
R1's inbound ACL on the tunnel interface permits only EIGRP, dropping all other traffic including spoke-to-spoke data packets.
Spoke-to-spoke traffic is forwarded through the hub if the routing table points to the hub. The ACL on the hub's tunnel interface filters this traffic.
B
NAT traversal is broken for spoke-to-spoke traffic due to IPsec encryption issues.
Why wrong: The ping to the hub works, indicating NAT traversal is functional.
C
EIGRP is not advertising spoke loopbacks to other spokes, causing no route.
Why wrong: If EIGRP were not advertising, the ping would fail with 'no route', but the issue is filtering.
D
The mGRE tunnel on R2 does not have a destination for R3, preventing direct communication.
Why wrong: DMVPN dynamically creates spoke-to-spoke tunnels; the mGRE configuration is correct.

Full breakdown with real-world context →

Question 12hardmultiple choice

Read the full MPLS explanation →

An MPLS network uses LDP for label distribution with IPv6. Router R1 and R2 are LDP peers. R1 has an IPv6 ACL applied inbound on the interface facing R2 that permits only TCP port 646 (LDP) and denies all other traffic. R2 shows 'show mpls ldp neighbor' indicates the neighbor is up, but 'show mpls forwarding-table' shows no labels for IPv6 prefixes. R1's 'show mpls ldp bindings' shows labels for all prefixes. What is the root cause?

A
The ACL blocks UDP port 646, which is used for LDP label advertisement messages, preventing label distribution.
LDP uses TCP for session but UDP for initial discovery and some label advertisements. Blocking UDP 646 stops label exchange.
B
LDP session is established but the routers have mismatched label ranges, causing no label bindings.
Why wrong: Label range mismatch would cause session failure, not just missing forwarding entries.
C
IPv6 CEF is not enabled on R1, preventing label imposition.
Why wrong: CEF is required for MPLS forwarding, but the issue is label distribution.
D
R2 has an outbound ACL blocking LDP packets, causing asymmetric filtering.
Why wrong: The neighbor is up, so outbound filtering is not the issue.

Full breakdown with real-world context →

Question 13hardmultiple choice

Open the full BGP breakdown →

A dual-stack network uses BGP for IPv6 between AS 100 and AS 200. Router R1 (AS 100) has an inbound route-map that sets local preference to 200 for routes from R2 (AS 200). R1 also has an IPv6 ACL applied inbound that permits only BGP (TCP 179) and denies ICMPv6. R2 advertises a prefix 2001:db8:1::/48. R1's BGP table shows the prefix with local preference 200, but 'show ipv6 route' does not install it. R1 has uRPF strict mode on the interface facing R2. What is the root cause?

A
The ACL blocks ICMPv6, which is required for IPv6 neighbor discovery. Without ND, the next-hop address of the BGP route is unresolved, preventing route installation.
BGP uses TCP, but the next-hop must be reachable via ND. Blocking ICMPv6 prevents ND, so the route is not installed.
B
uRPF strict mode drops the BGP updates because the source address is not in the FIB.
Why wrong: uRPF checks source of data packets, not BGP updates. BGP uses TCP, and uRPF is applied to transit traffic.
C
The route-map sets local preference incorrectly, causing the route to be suppressed.
Why wrong: Local preference 200 is valid and should prefer the route.
D
R1's BGP process has 'soft-reconfiguration inbound' enabled, causing the route to be hidden.
Why wrong: Soft-reconfiguration does not prevent route installation; it stores updates.

Full breakdown with real-world context →

Question 14hardmultiple choice

Review the full OSPF breakdown →

An enterprise uses VRF-lite with IPv6. VRF A on R1 leaks routes to VRF B using route-target import/export. R1 has an IPv6 ACL applied inbound on the interface in VRF A that permits only OSPFv3 and denies all other traffic. R1's VRF B has a static default route pointing to a next-hop in VRF A. Traffic from VRF B to the internet fails. R1 shows 'ping vrf B 2001:db8:2::1' fails, but 'ping vrf A 2001:db8:2::1' succeeds. What is the root cause?

A
The ACL on the VRF A interface blocks data traffic from VRF B, which is forwarded via the leaked route.
Traffic from VRF B is forwarded into VRF A and hits the inbound ACL, which permits only OSPFv3.
B
Route leaking is not configured correctly; the route-target import/export is missing.
Why wrong: If leaking were broken, the ping from VRF A would also fail.
C
The static default route in VRF B has an incorrect next-hop address.
Why wrong: If the next-hop were wrong, the ping from VRF A would also fail.
D
uRPF is enabled on the VRF A interface and drops traffic from VRF B due to source address mismatch.
Why wrong: uRPF is not mentioned in the configuration; the ACL is the issue.

Full breakdown with real-world context →

Question 15hardmultiple choice

Review the full OSPF breakdown →

An OSPFv3 network has multiple areas. Area 0 includes R1 and R2. Area 1 includes R2 and R3. R2 is an ABR. R1 has an IPv6 ACL applied inbound on the interface to R2 that permits only OSPFv3 and denies all other traffic. R3 advertises a prefix 2001:db8:3::/48 into Area 1. R1's routing table shows the prefix but with a next-hop of R2. R1's uRPF is configured in strict mode on the interface to R2. Traffic from R1 to 2001:db8:3::1 is dropped. R1 shows 'show ipv6 cef 2001:db8:3::/48' points to R2's link-local address. What is the root cause?

A
The source address of the traffic from R1 is not in the FIB as reachable via the interface facing R2, causing uRPF strict mode to drop the packet.
uRPF strict requires the source address to be reachable via the incoming interface. If the source is a directly connected subnet that is not in the FIB (e.g., due to filtering), the check fails.
B
The ACL on R1 blocks the return traffic from the destination, causing asymmetric routing.
Why wrong: The ACL permits OSPFv3, but data traffic is blocked. However, uRPF is the mechanism dropping the traffic.
C
R2's link-local address is not reachable due to OSPFv3 network type mismatch.
Why wrong: The prefix is installed with a next-hop, so reachability is fine.
D
The prefix 2001:db8:3::/48 is not in the OSPFv3 database on R1 due to area filtering.
Why wrong: The prefix is in the routing table, so it is in the database.

Full breakdown with real-world context →

These 300-410 practice questions are part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style 300-410 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 300-410 topic practice pages

Layer 3 Technologies practice questions

EIGRP Troubleshooting practice questions

OSPF Troubleshooting (v2/v3) practice questions

BGP Troubleshooting practice questions

Route Redistribution practice questions

Policy-Based Routing (PBR) practice questions

VRF-Lite practice questions

Route Maps and Route Filtering practice questions

Administrative Distance practice questions

Route Summarization practice questions

Bidirectional Forwarding Detection (BFD) practice questions

VPN Technologies practice questions

Practice scenarios

Drag and drop the steps to troubleshoot Device Access Control adjacency or connectivity failures into the correct order, from first to last.

Drag and drop the steps to verify and validate Device Access Control operational state into the correct order, from first to last.

Drag and drop the steps to troubleshoot IPv4 ACL adjacency or connectivity failures into the correct order, from first to last.

Drag and drop the steps to apply and verify an extended IPv4 ACL on a router interface into the correct order, from first to last.

In IPv6, what is the default action for an access-list entry that does not specify a protocol?

Which TWO configuration steps are required to implement IPv6 traffic filtering using a named ACL on a Cisco router? (Choose TWO.)