8 exercises — match firewall and ACL terms to their definitions, and evaluate whether firewall rule descriptions correctly implement a stated security policy.
0 / 18 completed
1 / 18
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 / 18
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 / 18
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 / 18
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 / 18
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 / 18
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 / 18
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 / 18
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?
9 / 18
Sarah from the security team sent this Slack message to the DevOps team: 'We're seeing a lot of failed login attempts on our web server. I suspect someone's trying to bypass the firewall ACL. Can anyone double-check that rule 123 – allowing SSH from 192.168.1.0/24 – is still needed? It seems overly permissive.' What does 'overly permissive' likely mean in this context?
'Overly permissive' describes a firewall rule that grants access to more resources or connections than are strictly necessary. In this case, allowing SSH from the 192.168.1.0/24 range could be a vulnerability if it's not essential for legitimate operations, making the server susceptible to unauthorized access.
10 / 18
David is writing a PR description for a change that updates the firewall rules. He writes: 'Implemented rule 501 which drops all inbound traffic to port 8080 except when originating from our staging environment (192.168.20.0/24).' What is David most likely trying to achieve with this rule?
David's rule is designed to restrict inbound traffic to port 8080 – typically used by web servers – specifically excluding connections originating from the staging environment. This demonstrates a common security practice of isolating testing environments to prevent accidental exposure or exploitation of production systems.
11 / 18
David is reviewing a PR that modifies the firewall rules. He sees this proposed change: 'Rule: Allow all outbound TCP traffic on port 80 from the application servers to external APIs. This rule doesn't explicitly block return traffic.' Considering standard firewall practices, which statement best describes the potential risk?
This rule lacks stateful inspection, meaning the firewall won't automatically allow return traffic for connections initiated from the application servers. This creates a potential 'open-door' scenario where attackers could potentially send data back to the server without being explicitly permitted. While monitoring *could* mitigate this risk, it's not a robust solution and doesn't address the fundamental flaw.
12 / 18
Maria, a network engineer, is troubleshooting an issue where users are unable to access a specific internal application. She examines the firewall logs and finds numerous dropped packets on TCP port 3306. The firewall's default policy is to drop all traffic not explicitly permitted. What is the MOST likely root cause of this issue?
Given the default policy of dropping unpermitted traffic and the observed dropped packets on TCP port 3306 (commonly used by MySQL), the most probable cause is a misconfigured ACL rule. The other options represent alternative issues, but don't directly explain why packets are being dropped based on firewall rules.
13 / 18
John is documenting a change to the firewall configuration for a new deployment. He writes: 'Rule 702: Permit TCP traffic from any source IP address to port 80 on the web server.' Which of the following best describes the potential security implication of this rule?
Allowing TCP traffic from *any* source IP address to port 80 on the web server creates a massive vulnerability. This rule does not consider any restrictions and exposes the webserver directly to potentially malicious actors. It's highly susceptible to DDoS attacks and other exploits.
14 / 18
Emily is receiving an alert from the security monitoring system indicating increased traffic on port 22 (SSH) originating from a previously unknown IP address. Reviewing the firewall rules, she finds one that allows SSH access to specific development servers. What action should Emily take FIRST?
The immediate priority is to understand the source of the suspicious traffic. Blocking all SSH access without investigation could disrupt legitimate development activities. Determining if the IP address is authorized and part of a known process is crucial before taking any corrective action.
15 / 18
Mark from the infrastructure team sent this Slack message: 'We've been experiencing intermittent connectivity issues with our staging environment. I suspect a misconfiguration in the firewall ACL might be blocking outbound traffic on port 8080. Could someone review the rules related to the staging network?' Considering Mark's statement, which action should be taken first?
This scenario requires a focused investigation. The correct action is to review the existing firewall rules targeting the staging network (192.168.1.0/24) – this is the most logical first step. Blocking blanket rules or disabling all rules without understanding the problem could exacerbate the issue and prevent effective troubleshooting. Option 3 is not immediately helpful; options are best addressed through targeted investigation.
16 / 18
During a standup meeting, Alex, a developer, mentions: 'We've just deployed the new microservice and it's crucial that it can communicate with our external API. I've added a rule to allow outbound TCP traffic on port 443 from this service to the API endpoint.' Which of the following best describes Alex's action regarding firewall configuration?
Alex's action directly addresses a critical requirement – allowing outbound traffic to external APIs. Implementing a rule permitting TCP traffic on port 443 is appropriate for secure communication. Options 2 and 3 are less desirable because they introduce potential vulnerabilities or unnecessary restrictions. Option 4 is incorrect as it removes the firewall's protective layer.
17 / 18
You're reviewing a PR that adds a new firewall rule for a production server: 'Rule 8001: Allow inbound TCP traffic on port 22 from known administrator IPs only.' The PR contains a comment stating that this rule is intended to improve security. Which of the following statements BEST describes a potential risk associated with this configuration?
The primary risk here is that allowing inbound SSH connections based on *known* IP addresses creates a maintenance burden. If an administrator's IP changes (e.g., due to a VPN or mobile connection), access will be blocked unless the rule is manually updated. This can lead to downtime and operational inefficiencies.
18 / 18
Maria, a network engineer, is analyzing firewall logs and finds numerous dropped packets on TCP port 3306. The firewall's configuration allows traffic from the database subnet (10.1.2.0/24) to any destination on this port. Considering this information, what could be the MOST likely cause of these dropped packets?
Given that the firewall allows traffic on port 3306 *from* the database subnet, the most likely cause is an error in the rule configuration. A typo or incorrect subnet definition would result in the firewall incorrectly blocking legitimate connections originating from within the allowed range. The other options are possible but less probable based on the stated information.
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 18 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.