8 exercises — match firewall and ACL terms to their definitions, and evaluate whether firewall rule descriptions correctly implement a stated security policy.
0 / 8 completed
1 / 8
Match the term to its definition: "A firewall that tracks the state of active connections and automatically allows return traffic for a connection that was initiated from inside the network."
Stateful firewall — tracks the state of each connection (e.g., "this TCP session was initiated outbound by an internal host") and automatically permits the matching return traffic, without needing an explicit inbound rule for it.
Stateful vs. stateless: • Stateful: remembers connection state; "the firewall automatically allows the response because it recognises this as part of an established outbound connection" • Stateless: evaluates every packet independently against the rule set, with no memory of prior packets; requires explicit rules for both directions of traffic — simpler and faster, but less flexible
Most modern firewalls (including cloud security groups) are stateful by default, which is why you typically only need to write an outbound-allow rule and the return traffic is handled automatically.
2 / 8
Match the term to its definition: "The default behaviour of a firewall or ACL when no rule matches a given packet — the traffic is dropped."
Implicit deny — the security principle (and typical default configuration) that any traffic not explicitly permitted by a rule is automatically denied. It is "implicit" because there is no visible rule saying "deny everything else" — it's simply the default outcome at the end of the rule list.
This is a foundational security concept, often phrased as "default deny" or "deny by default, allow by exception" — the opposite (and much riskier) posture is "default allow", where anything not explicitly blocked is permitted.
Cisco ACLs, for example, always have an implicit "deny any" at the very end of the list, even if it's not written — which is why forgetting a "permit" rule for legitimate traffic can silently break connectivity.
3 / 8
Match the term to its definition: "The difference between 'drop' and 'reject' as a firewall action for denied traffic."
Drop = silent discard, no response. Reject = discard + send back a rejection notice (ICMP "destination unreachable" or a TCP RST).
Why the distinction matters: • Drop is often preferred for security — it gives an attacker no information, and a port scan against a "drop" rule looks the same as a genuinely non-existent host (slower to enumerate) • Reject gives faster, cleaner feedback to legitimate clients ("connection refused" appears immediately, instead of the client waiting for a timeout) — useful in trusted internal environments where responsiveness matters more than obscurity
Interview-relevant phrasing: "we drop unsolicited inbound traffic at the perimeter firewall for security, but reject internally so misconfigured clients fail fast instead of timing out."
4 / 8
Read this rule description and evaluate: "Rule: The firewall drops all inbound traffic except port 443 from any source." Is this statement true or false: "This rule allows HTTPS traffic from anywhere, while blocking everything else inbound"?
True. Port 443 is the standard port for HTTPS. "Except port 443 from any source" means TCP/443 is permitted from any source IP address, while every other inbound port/protocol combination is dropped by the implicit-deny (or explicit deny-all) rule at the end.
Reading firewall rules precisely means identifying four elements every time: action (allow/drop/reject), direction (inbound/outbound), source (who the traffic is from), and destination/port (what it's going to). Missing any one of these when describing a rule leads to ambiguity — "the firewall blocks port 22" is incomplete; "the firewall drops inbound TCP/22 from any source except the jump-box subnet" is precise and unambiguous.
5 / 8
Read this ACL description and evaluate: "ACL rule: permit traffic from 10.0.0.0/8 to any destination on TCP port 80." Is this statement true or false: "This rule permits web (HTTP) traffic sourced from the entire 10.x.x.x private address range, going to any destination"?
True. "10.0.0.0/8" is the private address block covering all addresses from 10.0.0.0 to 10.255.255.255 (the entire "10.x.x.x" range). "To any" means the destination is unrestricted. "TCP port 80" is HTTP.
Key ACL vocabulary: • permit / deny — the action • source / destination — where traffic is from and going to (can be a specific host, subnet, or "any") • protocol — TCP, UDP, ICMP, or "ip" for all IP traffic • wildcard mask — the inverse of a subnet mask, used in Cisco ACLs to specify a range (e.g., "0.0.0.255" matches any host in a /24) • any — a keyword meaning "any address" (equivalent to 0.0.0.0/0)
6 / 8
Evaluate this rule against the stated policy. Policy: "Only the database subnet (10.1.2.0/24) should be able to reach the database server on port 5432; everything else should be blocked." Rule implemented: "permit tcp any 10.1.5.10 eq 5432". Is this statement true or false: "This rule correctly implements the stated policy"?
False. The rule permits "any" source, not just the database subnet 10.1.2.0/24 — it opens port 5432 to the entire network (or the entire internet, depending on where the ACL is applied), which is far broader than the policy requires. The correct rule should read: permit tcp 10.1.2.0 0.0.0.255 host 10.1.5.10 eq 5432 (using the wildcard mask 0.0.0.255 to match the specific /24 subnet, not "any").
This is a classic and dangerous real-world mistake: writing "any" as the source when a specific subnet was intended, accidentally exposing a sensitive service to a much wider audience than the security policy allows. Always cross-check the source/destination in a rule against the stated intent — precision in ACL vocabulary directly prevents security incidents.
7 / 8
Match the term to its definition: "A logical grouping of network interfaces on a firewall (e.g., 'inside', 'outside', 'DMZ') used to apply security policy between groups rather than per individual interface."
Zone — many enterprise firewalls (zone-based firewalls) organise interfaces into named zones (e.g., "inside", "outside", "dmz", "guest-wifi") and then define policy as "zone-to-zone" rules ("traffic from inside to outside is allowed by default; traffic from outside to inside is denied by default; traffic from dmz to inside is denied except for specific database ports").
This is more scalable than writing rules per physical interface, especially in networks with many VLANs or interfaces that share the same trust level.
Related vocabulary: • Trust level: the relative sensitivity/trustworthiness assigned to a zone (e.g., "inside" is most trusted, "outside"/internet is least trusted) • Security policy: the overall set of rules governing what traffic is allowed between zones • Policy-based routing: a related but distinct concept — routing decisions based on policy criteria, not just destination address
8 / 8
Evaluate this description against the policy. Policy: "Deny all inbound traffic from the internet to internal servers, except explicitly permitted HTTPS traffic to the web server." Rule set implemented: "1) permit tcp any host 203.0.113.10 eq 443; 2) deny ip any any". Is this statement true or false: "This two-line rule set correctly and completely implements the stated policy"?
True. Line 1 explicitly permits HTTPS (TCP/443) to the specific web server (203.0.113.10) from any source. Line 2 explicitly denies everything else. Order matters in ACLs — rules are evaluated top-to-bottom, and the first match wins, so the specific permit must come before the broad deny.
This demonstrates the standard, safe ACL-writing pattern: most specific rules first, broadest deny last. Even though most firewalls apply an implicit deny automatically, writing an explicit final "deny ip any any" is good practice because it makes the intended default behaviour visible in logs and documentation, rather than relying on an invisible default.
When evaluating whether a rule set matches a policy, always check: (1) is the permitted traffic scoped as narrowly as the policy states (not broader), and (2) is there a final catch-all that matches the stated default action?
What does the "Firewall & ACL Vocabulary — Networking Language Exercises" exercise cover?
Practise firewall and ACL vocabulary in English: stateful vs. stateless, implicit deny, drop vs. reject, zones, and reading permit/deny rules against a stated security policy.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Firewall & ACL Vocabulary — Networking Language Exercises"?
This exercise has 8 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Networking Language exercises?
Browse the full Networking Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.