November 10, 2026

Security+ Firewall Rule PBQ: A Step-by-Step Walkthrough

A firewall rule PBQ gives you a rule table and a set of requirements, then asks you to make the table enforce them. It's one of the most practical tasks on Security+, and it maps directly to SY0-701 objective 4.5, "Given a scenario, modify enterprise capabilities to enhance security," which lists firewall rules, access lists, ports/protocols and screened subnets. You can read the full list in the official SY0-701 exam objectives.

The good news: firewall rules follow a small number of fixed ideas. Once you can trace a connection through a table by hand, these questions get much easier. This walkthrough covers those ideas, then works through an original example. It isn't a real exam question; it's built to practice the same reasoning.

How a rule table is read

Every rule has the same parts:

• Action: allow or deny (some interfaces say permit/block).
• Protocol: TCP, UDP, ICMP or Any.
• Source: a single host (10.20.5.5/32), a subnet (10.20.0.0/16) or Any.
• Destination: same format as the source.
• Port: the destination port of the service, such as 443 for HTTPS.

The firewall checks a connection against the rules from top to bottom and applies the first rule that matches. It does not keep looking for a better match. Once a rule matches, the decision is made.

If no rule matches, the connection hits the implicit deny: traffic that isn't explicitly allowed is blocked. Many firewalls do this automatically at the end of the list. Some PBQ interfaces show it as a fixed last row; others expect you to add an explicit "deny any any" as the final rule. Read the interface and the instructions to see which one you're dealing with.

Those two ideas, first match and implicit deny, explain almost every trap in these questions.

Ports and protocols you should know cold

A rule with the right hosts and the wrong port fails just as badly as no rule at all. Know these, including whether they use TCP or UDP:

When a scenario says "securely," expect the encrypted option: SSH instead of Telnet, HTTPS instead of HTTP, LDAPS instead of LDAP. To drill these, try the free Ports for the new jump host question.

Stateful vs stateless firewalls

This matters when you decide whether to write rules for return traffic.

A stateful firewall tracks each connection. When it allows a client's request out to a server, it remembers that session and lets the server's replies back in automatically. You only write the rule for the side that starts the connection.

A stateless firewall, such as a basic router access list, judges every packet on its own. It has no memory of the request, so replies need their own rule, usually allowing traffic back to the client's high, temporary (ephemeral) port.

Most Security+ rule tables only ask about the connections that start the conversation, and they behave like a stateful firewall. If a scenario says the device is stateless, or asks you to allow return traffic, add the reply rules. If it doesn't, don't invent them; extra rules can open holes the checker will catch.

The worked example

Here's the scenario. A small clinic runs a mail server in its screened subnet (DMZ). The networks are:

• Mail server: 172.16.10.25
• Staff LAN: 10.20.0.0/16
• IT jump host: 10.20.5.5 (inside the staff LAN)
• DNS resolver in a services segment: 10.30.0.53

The requirements:

1. Anyone on the internet can deliver mail to the mail server.
2. Staff can read mail over IMAPS and send it through the submission port.
3. Only the jump host can manage the mail server over SSH.
4. The mail server can look up names on the DNS resolver.
5. Nothing else is allowed.

Step 1: turn requirements into flows

Write each requirement as source, destination, protocol and port:

1. Any → 172.16.10.25, TCP 25
2. 10.20.0.0/16 → 172.16.10.25, TCP 993 and TCP 587
3. 10.20.5.5 → 172.16.10.25, TCP 22
4. 172.16.10.25 → 10.30.0.53, UDP 53 and TCP 53
5. Everything else: implicit deny

Step 2: spot what's wrong with a first draft

Here's a draft that looks reasonable at a glance:

It has four problems:

• Rule 1 is too broad. The destination is Any, so the internet can reach port 25 on every host, not just the mail server.
• Rule 2 uses the wrong source. The whole LAN can SSH to the server, not only the jump host.
• Rule 3 shadows rule 4. Staff traffic to the server on 993 matches rule 3 first and is denied. Rule 4 never gets a chance. This is the classic first-match trap.
• DNS is half done. UDP 53 is allowed, but DNS falls back to TCP 53 when a response is too large for UDP.

Step 3: the corrected table

The stray deny rule is gone. It wasn't needed: the implicit deny already blocks anything not listed.

Step 4: trace test connections

Don't trust a table until you've walked traffic through it. Check a few connections that should pass and a few that shouldn't:

Every requirement holds, and the connections that should fail do fail.

Step 5: when order really matters

Now add one more requirement: "Block all traffic from 203.0.113.66, a known malicious address." If you add that deny at the bottom, it does nothing for mail. A connection from 203.0.113.66 to port 25 matches rule 1 first and is allowed. The deny has to go at the top, above every allow rule it should override.

The general rule: specific denies that must override broader allows go first, and broad rules go last.

Common mistakes to avoid

• Using Any where the scenario names a host or subnet. Least privilege applies to sources, destinations and ports.
• Putting a broad deny above the allows it was meant to sit behind.
• Choosing the insecure protocol when the scenario says "secure."
• Forgetting that a service can need both TCP and UDP, as DNS can.
• Adding rules nobody asked for. If the requirements don't mention it, the implicit deny should handle it.

Practice it

Rule tables click once you've traced a few by hand. Try the free Publish the web server question, where your rules are tested against hidden connections, so any correct rule set passes. For where firewalls sit on a network, try Place the security devices, which covers objective 3.2.

For the rest of your PBQ plan, read how to approach Security+ PBQs, and when you're ready for a different kind of task, the log analysis PBQ walkthrough. Or browse all the free practice questions.

All articles