A parks department permits outbound HTTPS to a permits portal but forgets return or established considerations and wonders why related traffic dies. What ACL behavior should they remember?
Select an answer to reveal the explanation.
Short Explanation
ACLs are silent bouncers: if you didn't put a name on the guest list, you're not getting in. That invisible deny at the end is why forgotten return or permit lines feel like a mysterious black hole.
Full Explanation
A parks department that permits outbound HTTPS to a permits portal but forgets return or established considerations must remember that every ACL ends with an implicit deny any. Traffic not explicitly permitted—including needed return packets or complementary flows that traverse the same filtered direction—is dropped. The correct behavior awareness works because operators often permit the forward initiate and assume the network "knows" to allow related return traffic; on a stateless interface ACL without reflected/established design, that assumption fails silently at the implicit deny. Believing every ACL ends with an implicit permit ip any any fails because the opposite is true—the invisible terminal deny is foundational IOS ACL behavior. Claiming implicit deny applies only to numbered ACLs 100–199 and never to named lists fails conceptually: named and numbered ACLs both terminate with implicit deny. Asserting implicit deny is removed automatically when uRPF loose mode is configured fails because uRPF does not rewrite ACL terminal semantics. Exam caveat: depending on where the ACL is applied, you may need explicit permits for return traffic, use established/reflexive patterns where appropriate, or filter only in the direction that sees the unwanted initiate. Operational check: review the ACL for missing return/related permits, check for hits on unexpected later denies or symptoms of black-holing after the first SYN, and test the permits portal flow while watching counters before and after adding the missing permits.