Cisco Certified Network Associate (CCNA) 200-301 Practice Test 59
Question 580
Packets enter Gi0/0 inbound from 192.0.2.0/24. An administrator applies a correct deny ACL OUTBOUND on Gi0/0, and the unwanted inbound packets are still admitted. What configuration choice is mismatched?
- A smaller source wildcard is needed even though the current ACL rule already matches the unwanted source.
- The implicit deny must be removed because ACLs never filter inbound packets.
- The ACL is applied in the wrong direction for this traffic; move or attach it to the actual ingress filtering point.
- The source must be converted to IPv6 to use an ACL on Ethernet.
Explanation
Correct Answer
C:ACLs are evaluated on a particular interface and packet direction. An outbound ACL on the same interface does not intercept packets arriving inbound; the policy must be applied where packets traverse it.
Incorrect Answers
A:The rule itself is stated to be correct, so narrowing the wildcard would not repair its placement on the wrong traffic direction.
B:The implicit deny rule is not why inbound traffic bypasses an ACL that only applies to egress; direction is the missing condition.
D:Extended IPv4 ACLs can filter IPv4 packets on Ethernet. IPv6 conversion is unrelated to the direction mismatch.
Question 581
An ACL processes entries top-down. On Gi0/0, `permit ip 192.0.2.0 0.0.0.255 any` appears before a newly appended `deny tcp host 192.0.2.55 any eq 23`. Telnet from that host remains permitted. What is the immediate cause?
- The standard ACL implicit deny rejects all Telnet regardless of preceding entries.
- A TCP destination-port match cannot be written in an extended IPv4 ACL.
- The broad earlier permit is the first matching entry, so the later TCP/23 deny is shadowed and never evaluated for those packets.
- The source MAC address is not learned, causing the L3 ACL to invert its sequence.
Explanation
Correct Answer
C:An ACL stops processing at the first matching entry. Since the broad IP permit matches the Telnet source and destination before the deny, the later rule never takes effect; re-order or narrow the permit.
Incorrect Answers
A:The implicit deny applies only when no earlier explicit rule matches. These Telnet packets hit the broad permit first.
B:Extended ACLs support protocol and destination-port matching, including `eq 23`; the problem is ordering rather than syntax.
D:Ethernet CAM learning does not reverse the ordered evaluation of an interface IPv4 ACL.
Question 582
A campus WLAN bridge applies an explicit Layer 2 IPv6 filter on the path from the router to wireless hosts. The filter allows Neighbor Solicitation and Neighbor Advertisement but drops ICMPv6 Router Advertisements. Clients have only FE80:: link-local addresses and never learn the advertised /64. What is the direct cause?
- The local DHCPv4 relay helper is missing, and IPv6 SLAAC requires DHCPv4 relay to carry RAs.
- The router must enable IPv4 NAT overload before it can send IPv6 Router Advertisements.
- The bridge is blocking TCP/443, which is the standard transport for Router Advertisements.
- The filter blocks the ICMPv6 Router Advertisements that supply prefix information needed for SLAAC on the link.
Explanation
Correct Answer
D:IPv6 SLAAC relies on Router Advertisements to learn advertised prefixes and associated autonomous-address-configuration information. On this link, wireless hosts can create FE80:: link-local addresses without receiving an RA, and the filter explicitly blocks the RAs from the router. Permitting Neighbor Solicitation and Neighbor Advertisement alone does not supply the missing prefix. Adjust the bridge filter to allow the intended authenticated/authorized router's ICMPv6 RA messages and validate a capture at the client, then verify a proper /64 address and router reachability. The policy must be scoped carefully to avoid accepting rogue RAs. This test is separate from IPv6 ACL syntax at a routed interface; its decisive evidence is dropped RA packets on the Layer 2 client path.
Incorrect Answers
A:DHCPv4 relay helps IPv4 clients obtain addresses from DHCP servers on other subnets. IPv6 SLAAC derives addresses using ICMPv6 Router Advertisements and local interface identifiers; it does not carry those messages through a DHCPv4 helper. DHCPv6 can supply other configuration in some environments, but it cannot make a dropped RA reappear on this WLAN link.
B:IPv4 NAT overload translates IPv4 source addresses or ports for shared external connectivity. It is not required for IPv6 Neighbor Discovery or SLAAC prefix dissemination on a local VLAN. The hosts already have IPv6 link-local addresses, so the immediate missing stage is their receipt of the router's advertised prefix, not an IPv4 translation capacity problem.
C:Router Advertisements are ICMPv6 control messages, not TCP application traffic on port 443. A web ACL permit or deny for HTTPS does not, by itself, identify whether SLAAC prefix information can reach hosts. Blocking TCP/443 may affect web applications after addressing, but the observed lack of global IPv6 addresses arises before such sessions are attempted.
Question 583
The original requirement is to deny TCP destination port 23 from source 192.0.2.5 while allowing SSH and HTTPS from that same source. The team replaced an inadequate standard ACL with an extended one. Which verification actually proves the port-specific policy?
- Check only whether a standard ACL source-host statement has a hit counter.
- Verify the router has a default route, without testing transport ports.
- Check the extended ACL protocol/host/`eq 23` term and packet tests showing Telnet denied while SSH and HTTPS from that source remain allowed.
- Verify a hostname resolves to an IPv4 address but do not send management traffic.
Explanation
Correct Answer
C:The requested rule must distinguish TCP/23 from other TCP ports for the same source. The extended match syntax and both negative and positive test flows establish correct selectivity and rule placement.
Incorrect Answers
A:A standard ACL counter can show that a source matched but cannot prove that Telnet alone is denied while other TCP ports are permitted.
B:Default routing enables generic reachability and does not validate Layer 4 ACL selectivity.
D:DNS resolution does not validate which TCP destination ports are permitted or denied by the extended ACL.
Question 584
A network security analyst is validating a repair. Earlier, a rule meant to block TCP/443 mistakenly names UDP/443, so the HTTPS TCP session still matches a later permit. Which postchange check most directly establishes the specific problem is resolved?
- Keep `deny udp ... eq 443` and expect it to reject an otherwise permitted TCP/443 handshake.
- `show ip access-lists` now shows `deny tcp ... eq 443` before the relevant permit and hit counters increase for test HTTPS sessions.
- Place `deny tcp ... eq 443` after a broad first matching permit and expect the later deny to run.
- Check only switch access VLAN membership while leaving protocol and port ACE unchanged.
Explanation
Correct Answer
B:HTTPS generally uses TCP port 443; a UDP/443-only rule would not block ordinary TCP HTTPS. Validate protocol, destination port, ACE order and an actual packet match.
Incorrect Answers
A:TCP and UDP have separate protocol matches, so UDP-only ACE does not block TCP HTTPS.
C:ACLs evaluate top to bottom with first match and stop; earlier permit makes later deny unreachable.
D:VLAN state does not prove the ACL denies the intended transport.
Question 585
An extended IPv4 ACL contains a specific permit for a management host to reach TCP destination port 443, followed by a broad deny. After editing the ACL, the operator must prove BOTH that the permit precedes the deny AND that an authorized HTTPS test packet matches the intended permit. Which verification method satisfies both requirements?
- Generate the authorized HTTPS test flow and inspect show ip access-lists for the permit-before-deny sequence and the incrementing permit match counter
- Check that the switch interface is administratively up and a default route exists, without viewing ACL entries
- Read the ACL configuration sequence once but do not send matching test packets or check live counters
- Observe total ACL hit counts without identifying which ACE matched or whether the permit precedes the deny
Explanation
Correct Answer
A:Cisco IOS access lists process matching statements in order, and an early broad deny can shadow a later specific permit. A complete acceptance test therefore includes generating traffic from the authorized management source to TCP port 443 and inspecting the ordered ACL with show ip access-lists or show access-lists. The permit should appear before the broad deny, and its own match counter should increase for the tested traffic while the deny counter does not absorb that flow. Confirm the ACL is applied in the intended interface direction if the counters remain unchanged. This checks both configuration precedence and real packet behavior instead of inferring success from a saved rule.
Incorrect Answers
B:Link and route state are relevant when troubleshooting basic packet forwarding, but the stated acceptance criteria are about ACL processing and observed packet matches. An interface can be up and a default route installed while a first-match deny still blocks the authorized HTTPS flow. This check neither verifies ordered access-control entries nor demonstrates a packet incrementing the intended permit entry. It misses both required facts.
C:Reading the static ACL configuration can confirm which line appears before another, but it cannot alone establish that the intended live HTTPS test traffic actually matches the permit. An incorrect source address, TCP destination port or interface direction could still cause the packet to match a different line. The audit asks for ordered configuration and a live matching-flow observation together. A configuration-only readout supplies only one half of the evidence.
D:A total count aggregated across different access-list entries is insufficient to prove that the correct permit matched the authorized flow. A broad deny or another earlier rule could be responsible for the change. The verification must attribute packet matches to the intended permit and confirm that the permit appears above the broad deny in first-match processing order. Without line-specific evidence, traffic may be flowing or failing for an unintended reason.
Question 586
A network security analyst has repaired a network problem. A deny rule is correct but attached outbound on an interface where the unwanted packets enter inbound, so they are never filtered there. Which device or protocol check is the strongest evidence that this particular failure is gone?
- The rule remains outbound on an interface that only sees the tested unwanted flow inbound.
- The ACL text contains the desired deny but is not applied to any relevant L3 interface.
- `show ip interface <ingress>` shows the intended ACL applied inbound, and a controlled packet test increments the deny ACE while blocked traffic stops.
- A different interface has a deny hit, while the originally targeted ingress still permits the unwanted flow.
Explanation
Correct Answer
C:The initial deny rule was correct but bound outbound where the unwanted frames arrived inbound. Correct direction and match counters demonstrate the policy actually runs.
Incorrect Answers
A:The ACL does not inspect those packets in the bound direction.
B:An unattached ACL does not filter the traffic.
D:Unrelated interface counters cannot validate this repaired attachment.
Question 587
A network acceptance test follows this reported failure: A new deny statement is appended after a broad matching permit, making it unreachable for affected packets. Which verification most specifically demonstrates the repaired function rather than checking an unrelated feature?
- The broad permit still precedes the new deny and the denied test flow increments the permit hit counter.
- The ACL is attached to the correct interface but only the list’s last ACE is checked for matches.
- Change the ACL name while retaining identical shadowed sequence order.
- `show ip access-lists` lists the specific deny before the broad overlapping permit, and test packets increment the deny ACE instead of the permit.
Explanation
Correct Answer
D:Cisco ACLs use first-match ordering. A later deny cannot override an earlier permit that already matches the same traffic; moving the deny ahead is the required repair.
Incorrect Answers
A:The same traffic never reaches the later deny in top-down first-match evaluation.
B:Placement on an interface does not correct shadowing by an earlier permit.
C:A cosmetic rename does not change first-match behavior.
Question 588
DHCP snooping is enabled for VLAN 10. The legitimate DHCP server is upstream through trunk Gi1/0/48; all ordinary user ports are untrusted. Clients send DISCOVER but receive no valid OFFER because the upstream port is also configured untrusted. Which trust-boundary change is appropriate?
- Trust every client access port so any attached device may send DHCP offers.
- Disable DHCP snooping on VLAN 10 because all OFFER messages must be untrusted.
- Configure Gi1/0/48 as DHCP-snooping trusted after verifying that it really leads to the authorized DHCP server, while keeping client access ports untrusted.
- Enable port-security protect mode on the DHCP server to replace the snooping trust designation.
Explanation
Correct Answer
C:DHCP snooping distinguishes ports allowed to forward DHCP server-type messages from ports that should only carry client-originated requests. The uplink actually leading to the approved server must be trusted for legitimate OFFER/ACK responses to reach the access clients; otherwise the switch may discard those server packets as arriving from an untrusted source. Confirm the topology and DHCP server identity before applying `ip dhcp snooping trust` on that infrastructure interface. Keep edge user ports untrusted to block rogue DHCP servers and verify client leases plus the snooping binding table afterward. Do not trust a port simply because it is a trunk without confirming where it leads.
Incorrect Answers
A:Trusting every user-facing access port allows a rogue device to introduce DHCP server responses and undermines the protection offered by DHCP snooping. The network needs the authorized server-facing path trusted, not a blanket exemption for all edges. Use the trust boundary that reflects the actual physical server topology.
B:Disabling DHCP snooping would remove the filtering that is intended to stop unauthorized DHCP server messages. The symptom is a misidentified legitimate server uplink, not proof that all DHCP snooping is incompatible with valid leases. Correct the trust configuration and retain edge protection.
D:Port security restrict mode or protect mode controls the handling of unauthorized source MAC addresses on a switchport. It does not mark an interface as a trusted source of DHCP server responses for the snooping feature. The necessary setting is DHCP snooping trust on the authenticated server-facing path.
Question 589
On a VLAN with DHCP snooping and Dynamic ARP Inspection, an access host has lease 10.20.30.44 from MAC 00:11:22:33:44:55 recorded in the snooping binding database. A different MAC sends an ARP claiming to own 10.20.30.44 on an untrusted port. What should DAI do?
- Accept the new ARP because it is more recent than the existing DHCP binding.
- Treat the ARP as an OSPF Hello and form a routing adjacency with the sender.
- Validate the ARP sender IP/MAC against the binding database and drop or log the inconsistent claim as configured.
- Change the host's DHCP lease to the attacker's MAC without involving the DHCP server.
Explanation
Correct Answer
C:Dynamic ARP Inspection helps prevent local ARP spoofing by checking ARP packets arriving on untrusted ports against trusted IP/MAC bindings, often learned from DHCP snooping. The valid binding associates 10.20.30.44 with 00:11:22:33:44:55. An ARP claiming that IP from a different MAC fails the expected match and should be discarded or logged according to the DAI policy, protecting peers from an unauthorized change in address resolution. Verify configured trusted interfaces and binding availability, inspection statistics and any static ARP ACL requirements for non-DHCP hosts. Misconfigured trust or missing bindings can also block legitimate traffic.
Incorrect Answers
A:ARP recency alone is not a trust decision when DAI is enforcing a valid DHCP snooping binding. A spoofed gratuitous ARP can be sent after the legitimate lease exists, which is exactly why validating source claims matters. Accepting the newest statement would defeat the protection against poisoning neighbor caches.
B:ARP is a Layer 2/IPv4 address-resolution protocol, not OSPF's IP protocol 89 Hello exchange. A spoofed ARP sender claim does not establish an OSPF neighbor or carry routing topology information. DAI applies local IP/MAC consistency checks, independently of routing-protocol adjacency formation.
D:DHCP binding information is derived from authorized address assignment and may be maintained through configured static bindings. An unsolicited ARP cannot legitimately rewrite the DHCP server's lease ownership merely by claiming an address. DAI should validate and block the inconsistent ARP rather than treat it as a server-approved lease transfer.
Question 590
An access port for an authorized workstation and one IP phone should learn no more than two secure source MAC addresses. Port security is enabled in the correct access/voice VLAN design. Which additional interface command sets that two-address limit?
- `switchport port-security violation restrict 2` to express a two-address limit.
- `switchport mode trunk 2` to tell the switch two MAC addresses may connect.
- `switchport port-security maximum 2` on the protected access interface.
- `ip dhcp snooping trust 2` to authorize exactly two users by MAC address.
Explanation
Correct Answer
C:Port security can restrict how many secure source MAC addresses may be learned or configured on an access switchport. On IOS platforms supporting the syntax, `switchport port-security maximum 2` sets an overall maximum of two learned secure addresses, subject to the platform's per-VLAN options. Ensure the authorized phone and workstation match the intended voice/data topology and validate actual secure MAC learning with `show port-security interface` and address displays. Also decide a violation mode appropriate to operations. A maximum of two does not identify which two addresses are authorized unless static or sticky learning and access procedures provide that control.
Incorrect Answers
A:`switchport port-security violation restrict` controls the action on frames from unauthorized addresses—typically dropping them while maintaining the port and recording violations—not the secure-MAC count. The token `2` is not the usual argument to that violation mode. Set maximum separately and configure the desired violation response.
B:`switchport mode trunk` changes a switchport's Layer 2 operational VLAN tagging mode; it does not specify a count of allowed secure MAC addresses. A workstation-and-phone design can use an access port with voice VLAN behavior. The appropriate quantity limit comes from the port-security maximum setting.
D:DHCP snooping trust is a Boolean port trust designation for forwarding authorized server-originated DHCP messages. It is not a count of users or secure MAC addresses, and trusting a host-facing port could introduce rogue DHCP risk. Keep trust rules separate from the port-security secure-MAC maximum.
