Cyber Security Quiz: Firewalls
10 questions · exam conditions
0:00
FirewallsQuestion 1 of 10

A perimeter firewall has no rule permitting new inbound connections from the internet. It does permit internal clients to initiate HTTPS connections to internet servers. An employee opens an HTTPS session to a public website, and the website sends response packets back to the employee.

Which firewall behavior best explains why the response packets can enter without a general inbound HTTPS allow rule?

A stateful firewall associates the packets with an internally initiated connection and permits the return traffic.
A stateless firewall automatically permits packets whose source port is commonly assigned to HTTPS services.
A stateful firewall treats all traffic using an encrypted application protocol as trusted return traffic.
A stateless firewall reverses every outbound allow rule to create a permanent inbound allow rule.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Firewalls

Practice Firewalls in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Firewalls, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A perimeter firewall has no rule permitting new inbound connections from the internet. It does permit internal clients to initiate HTTPS connections to internet servers. An employee opens an HTTPS session to a public website, and the website sends response packets back to the employee.

Which firewall behavior best explains why the response packets can enter without a general inbound HTTPS allow rule?

  1. A stateful firewall associates the packets with an internally initiated connection and permits the return traffic. (correct answer)
  2. A stateless firewall automatically permits packets whose source port is commonly assigned to HTTPS services.
  3. A stateful firewall treats all traffic using an encrypted application protocol as trusted return traffic.
  4. A stateless firewall reverses every outbound allow rule to create a permanent inbound allow rule.
Explanation: Whenever you see a question about firewall rules and return traffic, the key concept to identify is whether the firewall is stateful or stateless — this distinction determines everything about how return packets are handled. A stateful firewall maintains a session table that tracks active connections. When your internal employee initiates an HTTPS request outbound, the firewall logs that connection's details — source IP, destination IP, source port, destination port, and sequence numbers. When the web server sends response packets back, the firewall checks them against its session table, recognizes them as belonging to an already-approved outbound session, and permits them automatically. No explicit inbound rule is needed. This is exactly what answer A describes, making it correct. Answer B is wrong because it describes a stateless behavior, and the logic is flawed regardless — stateless firewalls evaluate each packet independently against static rules. A source port of 443 alone is not a trusted signal; attackers can spoof source ports trivially. Answer C is wrong because stateful firewalls do not blindly trust encrypted traffic. Encryption is irrelevant to the session-tracking mechanism — the firewall permits return traffic based on connection state, not the protocol's confidentiality properties. Answer D is wrong because stateless firewalls have no concept of "reversing" outbound rules. Each rule is a static, one-directional entry. Creating automatic mirrored inbound rules does not exist as a real firewall behavior. As a study tip, remember: stateful = session-aware, stateless = rule-per-packet. Exam questions often use return traffic scenarios specifically to test whether you understand this distinction.

Question 2

A stateful firewall permits employees to initiate outbound TCP sessions and allows matching return traffic. During maintenance, the firewall is restarted and loses its connection-state table, but its configured rules remain unchanged. An employee's already-open TCP session then receives another packet from the external server.

Assuming the firewall does not reconstruct prior state, how will it most likely treat that packet?

  1. It will allow the packet because configured outbound rules permanently authorize all reverse-direction traffic.
  2. It will deny the packet because the prior session is no longer represented in the state table. (correct answer)
  3. It will allow the packet because TCP endpoints, rather than firewalls, maintain all relevant connection state.
  4. It will deny the packet only if its source port differs from the client's original source port.
Explanation: Whenever you see a question about stateful firewalls, the central concept to keep in mind is that stateful inspection is session-aware — the firewall's permission decisions depend on entries in a live connection-state table, not just static rules alone. Here's the core logic: a stateful firewall allows return traffic by matching incoming packets against existing session entries. When the firewall restarts and loses its state table, those session records vanish entirely. The firewall now has no record that the employee initiated a session, so the incoming packet from the external server looks like an unsolicited inbound connection. Since there's no matching state entry to validate it, and the static rules only authorize outbound initiations, the packet is denied. That makes B the correct answer. A is wrong because configured rules don't "permanently authorize" reverse traffic. Stateful firewalls use rules together with state entries — the rule permits outbound sessions, but the return traffic is authorized only when a matching state entry exists. Without that entry, the rule alone grants nothing inbound. C reflects a common misconception: yes, TCP endpoints maintain connection state at the transport layer, but that's irrelevant to what the firewall does. The firewall makes its own independent decision based on its own state table — it doesn't defer to the endpoints. D is a distractor that introduces port-matching logic. While port numbers are part of state-table entries, the problem here is the absence of any state entry at all, not a port mismatch. A useful study tip: always distinguish session state (dynamic, lost on restart) from configured rules (static, persistent). Exam questions often test whether you conflate the two.

Question 3

A stateful firewall allows an internal monitoring host to send UDP queries to an external service. Because UDP has no TCP-style connection establishment or termination, the firewall records each permitted exchange for a limited time.

How should the firewall handle a UDP reply that arrives during that time and matches the recorded addresses and ports?

  1. Deny it because stateful inspection is possible only for protocols that use a TCP handshake.
  2. Allow it as matching return traffic based on temporary flow state maintained by the firewall. (correct answer)
  3. Allow it because every inbound UDP packet is considered a response to an outbound request.
  4. Deny it unless a permanent rule allows all UDP packets from the external service's network.
Explanation: When you see a question about stateful firewalls and connectionless protocols like UDP, the core concept being tested is how firewalls track traffic flows without relying on handshake signals. A stateful firewall doesn't just evaluate packets in isolation — it remembers recent exchanges and uses that context to make smarter decisions. For UDP specifically, the firewall can't rely on SYN/ACK flags the way it does with TCP. Instead, when an internal host sends an outbound UDP packet, the firewall creates a temporary flow entry recording the source IP, destination IP, source port, and destination port. If a reply arrives within the timeout window and its addresses and ports match that recorded state, the firewall treats it as legitimate return traffic and allows it through. That's exactly what B describes — the return packet is permitted because it matches the temporary flow state, not because of a permanent rule or a protocol handshake. A is wrong because stateful inspection is absolutely not limited to TCP. Modern firewalls handle UDP, ICMP, and other connectionless protocols by using time-limited flow records precisely to compensate for the lack of a handshake. C is dangerously misleading — it implies the firewall allows all inbound UDP, which would be a serious security flaw. The return packet is allowed only because it matches a specific recorded flow, not simply because it's UDP. D is wrong because stateful firewalls don't require permanent rules to handle return traffic; that's the whole advantage of maintaining flow state dynamically. Remember: stateful firewalls extend to any protocol — the mechanism just adapts. For connectionless protocols, temporary state entries replace handshake tracking.

Question 4

A first-match firewall uses these outbound rules: (1) allow TCP from the employee network to any internet destination; (2) deny TCP from the employee network to 203.0.113.40; (3) deny all unmatched outbound traffic. Testing shows that employees can still connect to 203.0.113.40.

Which change most directly enforces the intended block while preserving access to other TCP destinations?

  1. Place a second broad TCP allow rule immediately after the existing deny rule.
  2. Move the default-deny rule above both of the destination-specific rules.
  3. Replace the destination-specific deny rule with an allow rule for the same address.
  4. Move the destination-specific deny rule above the broad TCP allow rule. (correct answer)
Explanation: Whenever you see a firewall question involving a "first-match" (or top-down) rule engine, your instinct should be to trace packets through the ruleset in order and identify where the first match occurs — because that's the rule that wins, and everything below it becomes irrelevant for that traffic. Here, the problem is a classic rule-ordering mistake. The broad "allow TCP from employee network to any destination" sits at the top, so when an employee tries to connect to 203.0.113.40, that packet matches Rule 1 immediately and gets permitted. The firewall never even reaches Rule 2's deny. The intended block is completely bypassed — not because the deny rule is wrong, but because it's unreachable. The fix in D is straightforward: move the deny for 203.0.113.40 above the broad allow. Now packets destined for that address match the deny first, get dropped, and all other TCP traffic falls through to the allow rule and proceeds normally. Both goals — blocking one host, permitting everything else — are achieved. A is a trap; adding another broad allow after the deny doesn't help, because the first broad allow already prevents the deny from being reached. B is catastrophically wrong — placing a default-deny above everything blocks all outbound traffic, defeating the entire purpose of the ruleset. C is logically backwards; replacing the deny with an allow for that address makes the block permanent in the wrong direction, explicitly permitting the connection you're trying to stop. A useful habit: always mentally simulate a packet's path from top to bottom through firewall rules. Specific rules must come before general ones, or they'll never fire.

Question 5

A firewall rule allows inbound TCP connections from one approved partner address to an application server on port 443. A security review confirms that the rule is working exactly as configured.

Which statement most accurately describes what the allow decision establishes?

  1. It establishes that encrypted traffic is inspected and validated before the firewall permits the connection.
  2. It establishes that all matching traffic is harmless because both the source address and port are approved.
  3. It establishes that the partner cannot exploit the server because the firewall is maintaining connection state.
  4. It establishes that matching packets may pass, but not that their application content is safe or authorized. (correct answer)
Explanation: When you see a question about firewall rules and what they "establish," anchor your thinking to the OSI model layers. Firewalls operate at the network and transport layers — they match packets against rules based on IP addresses, ports, and protocol. They make no judgments about what's inside the payload. That's exactly why D is correct. An allow rule does one thing: it permits matching packets to pass. A packet from the approved source IP destined for port 443 clears the gate — full stop. The firewall has no knowledge of whether the application-layer content is malicious, unauthorized, or malformed. A legitimate partner address could still send a crafted payload exploiting a vulnerability in the application. The firewall wouldn't know or care. A is wrong because a standard firewall rule doesn't perform deep packet inspection or decrypt TLS traffic to validate content. Unless you've explicitly deployed a next-generation firewall with TLS inspection, the firewall sees an encrypted stream, not validated application data. B is wrong because it confuses rule matching with threat assessment. Approving a source and port means those attributes satisfy the rule's conditions — it says nothing about the harmlessness of the traffic itself. Attackers frequently exploit trusted channels. C is wrong because stateful inspection tracks connection state (SYN, established, FIN), which helps prevent spoofed packets — but it absolutely does not prevent a legitimate, state-compliant connection from carrying a malicious payload. Study tip: On security exams, watch for answers that conflate access control decisions with content safety guarantees. A firewall grants or denies passage; it does not certify intent.

Question 6

A firewall processes rules from top to bottom and stops at the first match. Its inbound rules are: (1) allow TCP from any source to server 10.0.0.8 on port 22; (2) deny TCP from 198.51.100.0/24 to server 10.0.0.8 on port 22; (3) deny all other inbound traffic.

What happens when host 198.51.100.25 starts an SSH connection to 10.0.0.8?

  1. The connection is allowed because the broad allow rule matches before the source-specific deny rule. (correct answer)
  2. The connection is denied because the most specific matching rule always overrides broader rules.
  3. The connection is denied because any matching deny rule takes precedence over an allow rule.
  4. The connection is allowed only after the firewall evaluates all three rules and compares them.
Explanation: When a firewall uses first-match processing, rule order is everything — the firewall doesn't weigh rules against each other or search for the "best" match. It reads from top to bottom and enforces the very first rule whose conditions are satisfied, then stops immediately. Here, Rule 1 says "allow TCP from any source to 10.0.0.8 on port 22." When host 198.51.100.25 attempts an SSH connection, the firewall checks Rule 1 first. Because "any source" includes 198.51.100.25, Rule 1 matches — the connection is allowed, and the firewall never even looks at Rule 2. The intent to block the 198.51.100.0/24 subnet is completely bypassed because the broad permit rule was placed above the specific deny rule. Answer A is correct. Answer B is wrong because first-match firewalls don't operate on specificity — they don't rank rules by how narrowly they define the source. Specificity-based evaluation exists in some access-control systems, but not in standard top-down firewall rule processing. Answer C reflects a common misconception that deny rules carry inherent priority over allow rules; in a first-match model, precedence is determined purely by position, not rule type. Answer D is wrong because the firewall does not evaluate all rules and then compare them — it stops the moment it finds a match. Evaluating every rule before deciding is characteristic of a different model entirely. The key study tip: always trace firewall rules in order from top to bottom and stop at the first match. This is the most common trap in firewall questions — a deny rule placed below a broader allow rule is effectively dead code.

Question 7

An administrator replaces a firewall's default-allow policy with a default-deny policy. Explicit rules permit DNS queries to approved resolvers and HTTPS connections to approved websites. No rule addresses network time synchronization traffic.

After the change, clients can browse approved websites but cannot synchronize their clocks. Which conclusion is best supported?

  1. The firewall is stateful, so it blocks every application protocol that does not establish a TCP session.
  2. The clock service must be using an unapproved website because HTTPS is the only permitted application.
  3. The unmatched time-synchronization traffic reaches the default-deny action and requires an explicit allow rule. (correct answer)
  4. The explicit DNS allow rule implicitly permits other UDP-based services to the same destinations.
Explanation: Whenever you see a question about firewall policies, anchor your thinking to one core principle: default-deny means everything not explicitly permitted is blocked. No exceptions, no implicit allowances — if there's no matching rule, traffic hits the wall. That's exactly what's happening here. Network Time Protocol (NTP) uses UDP port 123. The administrator wrote rules for DNS and HTTPS but wrote nothing for NTP. When clock-synchronization packets arrive at the firewall, they don't match any explicit permit rule, so they fall through to the default-deny action and are silently dropped. The fix is straightforward: add an explicit allow rule for NTP traffic. Answer C correctly captures this logic — unmatched traffic hits the default action, and the solution is an explicit permit. Answer A is wrong because default-deny doesn't care whether a protocol uses TCP or UDP — it blocks all unmatched traffic regardless of transport layer. Stateful inspection tracks connection state, but that's irrelevant here; the problem is simply that no rule permits NTP at all. Answer B is wrong because it confuses application protocol with destination. Clock synchronization uses NTP, not HTTPS. The issue isn't which website is being contacted — it's that NTP traffic itself has no permit rule, regardless of destination. Answer D is wrong and represents a dangerous misconception. Permit rules are specific; an explicit DNS allow rule permits DNS traffic to those resolvers and nothing else. UDP-based services are not "implicitly" covered by other UDP rules — each protocol requires its own explicit entry. Study tip: On firewall questions, always trace the traffic flow: Does a rule match? If yes, what action? If no, what's the default? Default-deny means deny everything unnamed — keep that as your mental checklist.

Question 8

A firewall applies separate rules to traffic entering and leaving a protected network. An administrator adds an inbound rule allowing TCP traffic from a vendor address to an internal server on port 8443. The firewall's outbound policy still denies all traffic not explicitly allowed, and there is no applicable outbound rule.

What is the most likely outcome when the vendor initiates the permitted connection?

  1. The session works because an inbound allow rule automatically creates a matching outbound rule that permits every packet from the server.
  2. The initial packet is blocked because the firewall requires a corresponding outbound allow rule before it will accept any inbound connection.
  3. The initial packet enters, but server responses are blocked unless state handling or an explicit outbound rule permits the return traffic. (correct answer)
  4. The session works only because destination port 8443 causes the firewall to treat all related traffic as exempt from the outbound policy.
Explanation: Whenever you see a question mixing inbound and outbound firewall rules, the core concept being tested is stateful versus stateless packet filtering — and how return traffic is handled. In a stateless firewall (or one where stateful inspection isn't enabled or configured), each packet is evaluated independently. An inbound rule allowing the vendor's TCP packet to reach port 8443 only governs that incoming direction. When the internal server sends a response back, that response packet travels outbound — and the outbound policy evaluates it fresh, with no memory of the original inbound session. Since the outbound policy denies everything not explicitly allowed, those response packets are dropped. The vendor's SYN reaches the server, but the SYN-ACK never makes it back, and the TCP handshake never completes. This makes C correct: the initial packet enters, but responses are blocked without state handling or an explicit outbound rule. A is wrong because firewalls do not automatically mirror inbound rules as outbound rules — that's a dangerous misconception. Rules are unidirectional unless stateful session tracking creates dynamic temporary exceptions, which is distinct from auto-generating permanent rules. B is wrong because the inbound rule is sufficient to admit the initial inbound packet. The problem arises on the return path, not the entry path. D is wrong because port numbers carry no special firewall privilege. Port 8443 is simply HTTPS-alternate; the firewall has no built-in reason to exempt its traffic from outbound policy. Study tip: Always trace both directions of a connection — inbound and outbound — when analyzing firewall rules. Stateful inspection solves the return-traffic problem automatically; when it's absent, you need explicit rules for each direction.

Question 9

Two firewalls protect identical servers. Firewall S is stateless and allows inbound TCP packets with the ACK flag set, on the assumption that they are responses. Firewall T is stateful and allows inbound packets only when they match an established connection in its state table. An attacker sends an unsolicited inbound TCP packet with the ACK flag set.

Which result best illustrates the security distinction between the two designs?

  1. Firewall S may allow the packet based on its header flag, while Firewall T rejects it for lacking matching state. (correct answer)
  2. Firewall S rejects the packet because ACK always identifies a new connection, while Firewall T permits it.
  3. Both firewalls permit the packet because the ACK flag conclusively proves that a valid session exists.
  4. Both firewalls reject the packet because neither type can create rules that inspect TCP header flags.
Explanation: When a question compares stateless and stateful firewalls, your focus should be on what information each type uses to make its allow/drop decision. A stateless firewall inspects individual packet headers in isolation, while a stateful firewall tracks the full context of a connection over time using a state table. Here's the key insight: an ACK flag in a TCP packet simply means "I am acknowledging data." A stateless firewall like Firewall S sees that flag and assumes the packet must belong to an ongoing session — but it has no memory to verify this. An attacker can trivially craft a packet with ACK set and send it unsolicited. Firewall S, judging only the header, may let it through. Firewall T, however, checks its state table first. If no prior SYN/SYN-ACK handshake established a matching connection, the packet has no legitimate entry — so Firewall T drops it. This is exactly what answer A describes, making it correct. Answer B reverses the behavior of both firewalls entirely — ACK does not identify a new connection, and Firewall S does not reject ACK packets; that's precisely its vulnerability. Answer C is wrong because an ACK flag proves nothing on its own; it is trivially spoofable, and a stateful firewall would never treat a flag alone as proof of a valid session. Answer D is factually false — both firewall types are absolutely capable of inspecting TCP header flags; the distinction is whether flag inspection alone is sufficient. Your study tip: remember that "stateful" means the firewall has memory — it tracks what it has seen before. Whenever you see a question about firewall types, ask yourself: does this firewall know the history of the connection, or only the current packet?

Question 10

A stateless firewall protects a client network. One rule allows internal clients to send TCP traffic from ephemeral source ports to external servers on destination port 443. The firewall has a default-deny policy in both directions.

What additional rule is most directly required for HTTPS response packets to return through this stateless firewall?

  1. Allow inbound TCP traffic from any external source port to internal destination port 443.
  2. Allow inbound TCP traffic from source port 443 to the permitted internal ephemeral destination ports. (correct answer)
  3. Allow outbound TCP traffic from source port 443 to any external ephemeral destination port.
  4. Allow inbound UDP traffic from source port 443 to the permitted internal ephemeral destination ports.
Explanation: Whenever you see a question about stateless firewalls, remember the core limitation: unlike stateful firewalls, they have no memory of established connections. Every packet — including response packets — must be explicitly permitted by a rule. This means you have to think symmetrically: what does the outbound traffic look like, and what does the return traffic look like? Here's the flow: your internal client picks an ephemeral source port (say, 54321) and sends TCP traffic to an external server's port 443. The server's response packet travels in reverse — it originates from source port 443 on the external server and is destined for port 54321 on your internal client. For that return packet to pass a stateless firewall with default-deny, you need a rule that explicitly matches those characteristics. That's exactly what B describes: allow inbound TCP from source port 443 to the internal ephemeral destination ports. It mirrors the return traffic precisely. A is wrong because it allows inbound traffic destined for internal port 443, which describes incoming connection requests to an internal HTTPS server — not response packets coming back to clients. C describes outbound traffic from port 443, which would be relevant if your internal host were running an HTTPS server, not a client. D is wrong for two reasons: HTTPS runs over TCP, not UDP, and even if the ports were right, the protocol mismatch would block the traffic. As a study tip, always trace the packet's headers in both directions — source IP/port and destination IP/port swap on the return trip, and stateless firewalls require you to account for that explicitly.