Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5
CCNA Network Services and Security Practice Question
Drag and drop the following steps into the correct order to plan, configure, and apply an extended ACL that permits only HTTP traffic from the 192.168.1.0/24 network to the server at 10.0.0.100, and then verify the configuration.
⚠ Common exam trap
Remember that ACLs are created in global configuration mode, not interface mode. Also, apply ACLs inbound on the interface closest to the source for efficiency. Pay attention to whether the requirement is to permit or deny traffic.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enter global configuration mode, create the ACL with a permit statement for HTTP from 192.168.1.0/24 to 10.0.0.100, apply it inbound on the interface facing the 192.168.1.0/24 network, save the configuration, and verify with show access-lists.
First, enter config mode. Then create the ACL allowing HTTP from the source network to the destination host. Apply it inbound on the appropriate interface. Save and verify the configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enter global configuration mode, create the ACL with a permit statement for HTTP from 192.168.1.0/24 to 10.0.0.100, apply it inbound on the interface facing the 192.168.1.0/24 network, save the configuration, and verify with show access-lists.
Why this is correct
This sequence is correct because extended ACLs are defined in global configuration mode before being attached to an interface. Applying the ACL inbound on the interface that receives traffic from 192.168.1.0/24 ensures HTTP requests are evaluated at the first network hop, preventing unwanted traffic from consuming bandwidth and router resources beyond that point. Saving with 'copy running-config startup-config' and verifying with 'show access-lists'—which reveals ACE match counters and confirms the permit rule is actively matching—completes a proper implementation workflow.
- ✗
Enter global configuration mode, create the ACL with a permit statement for HTTP from 192.168.1.0/24 to 10.0.0.100, apply it outbound on the interface facing the server, save the configuration, and verify with show ip interface.
Why it's wrong here
This option incorrectly places the ACL outbound on the server-facing interface. While an outbound ACL on that interface could technically filter the same HTTP flow, it does so only after the traffic has already crossed the network from the clients, wasting bandwidth and CPU that inbound filtering would have saved. Additionally, 'show ip interface' merely confirms which ACL is assigned to the interface; it does not display per-ACE hit counters, so 'show access-lists' is the correct verification tool. This workflow is operationally usable but suboptimal and not the recommended best-practice placement.
- ✗
Enter interface configuration mode, create the ACL with a permit statement for HTTP from 192.168.1.0/24 to 10.0.0.100, apply it inbound on the same interface, save the configuration, and verify with show running-config.
Why it's wrong here
Access control lists are always created in global configuration mode using commands like 'ip access-list extended NAME' or 'access-list NUMBER permit tcp ...', not while in interface configuration mode. Even if the ACL already existed, applying it inbound on the same interface—presumably the source-facing interface—would require returning to global config to define it, which this option omits. 'show running-config' only displays the ACL reference on the interface, not traffic match statistics, so it fails to verify that HTTP packets are actually being permitted and counted.
- ✗
Enter global configuration mode, create the ACL with a deny statement for HTTP from 192.168.1.0/24 to 10.0.0.100, apply it inbound on the interface facing the server, save the configuration, and verify with show access-lists.
Why it's wrong here
This option specifies a deny statement, which would explicitly block the HTTP traffic the engineer intends to allow, making the ACL action semantically wrong. Applying the ACL inbound on the server-facing interface is also incorrect: inbound on that interface filters traffic sourced from the server side, not from 192.168.1.0/24, so client HTTP requests would never be evaluated against the rule. A correct inbound ACL must be placed on the client-facing interface, and verification should show permit match counts rather than merely confirming the ACL exists.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.
✓Enter global configuration mode, create the ACL with a permit statement for HTTP from 192.168.1.0/24 to 10.0.0.100, apply it inbound on the interface facing the 192.168.1.0/24 network, save the configuration, and verify with show access-lists.Correct answer▾
Why this is correct
This sequence is correct because extended ACLs are defined in global configuration mode before being attached to an interface. Applying the ACL inbound on the interface that receives traffic from 192.168.1.0/24 ensures HTTP requests are evaluated at the first network hop, preventing unwanted traffic from consuming bandwidth and router resources beyond that point. Saving with 'copy running-config startup-config' and verifying with 'show access-lists'—which reveals ACE match counters and confirms the permit rule is actively matching—completes a proper implementation workflow.
✗Enter global configuration mode, create the ACL with a permit statement for HTTP from 192.168.1.0/24 to 10.0.0.100, apply it outbound on the interface facing the server, save the configuration, and verify with show ip interface.Wrong answer — click to see why▾
Why this is wrong here
The ACL should be applied inbound on the interface closest to the source, not outbound on the destination interface.
Why candidates choose this
Candidates may think outbound application is equivalent, but it wastes router resources by processing unwanted traffic through the router.
✗Enter interface configuration mode, create the ACL with a permit statement for HTTP from 192.168.1.0/24 to 10.0.0.100, apply it inbound on the same interface, save the configuration, and verify with show running-config.Wrong answer — click to see why▾
Why this is wrong here
ACLs are defined globally and then applied to an interface; they cannot be created directly in interface configuration mode.
Why candidates choose this
Candidates might confuse the creation step with the application step, thinking both happen in interface mode.
✗Enter global configuration mode, create the ACL with a deny statement for HTTP from 192.168.1.0/24 to 10.0.0.100, apply it inbound on the interface facing the server, save the configuration, and verify with show access-lists.Wrong answer — click to see why▾
Why this is wrong here
The requirement is to permit HTTP traffic; a deny statement would block it. Also, the ACL should be applied inbound on the interface closest to the source.
Why candidates choose this
Candidates may misread the requirement or think deny is needed to block other traffic, but the ACL must explicitly permit the desired traffic.
Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
Go deeper
Related to this question
Learn chapter
RA Guard — IPv6 First-Hop Security
Key term
Extended ACL
An extended access control list (ACL) is a set of rules that filters network traffic based on source and destination IP addresses, protocol type, and port numbers, providing more granular control than a standard ACL.
Key term
Interface
An interface is a point of connection or interaction between two systems, devices, or software components that allows them to exchange information or signals.
About these practice questions
One of 1,389 original 200-301 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-301 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-301 exam.