What Is a PBQ (Performance-Based Question)?

Worked PBQ Example: Evaluate a Firewall ACL

Suppose a web server at 10.0.0.10 must accept inbound HTTP and HTTPS from any source. A database at 10.0.0.20 may accept MySQL connections only from that web server. All other inbound traffic must be denied. One possible ruleset is below.

For this training example, rules are evaluated top-down and the first match wins. Stop evaluating a packet as soon as a rule matches; “ANY” matches every value in that field. These are the example’s stated semantics, not a claim about identical defaults on every firewall.

Trace Three Packets

1. 203.0.113.45 → 10.0.0.10, TCP port 443: ALLOW at rule 2. Rule 1 has the correct protocol and destination but the wrong destination port. Rule 2 matches the source, destination, protocol, and port, so the packet is allowed and evaluation stops before rules 3 and 4.
2. 198.51.100.8 → 10.0.0.20, TCP port 3306: DENY at rule 4. Rules 1 and 2 fail because their destination is the web server. Rule 3 has the right destination, protocol, and port, but its source must be 10.0.0.10; this external source does not match. The catch-all rule therefore denies the packet. Port 3306 alone does not determine the decision.
3. 10.0.0.10 → 10.0.0.20, TCP port 3306: ALLOW at rule 3. The first two rules again fail on destination. Rule 3 now matches every packet field, including the required web-server source, so this database connection is allowed and never reaches the final deny.

Order changes the outcome: moving rule 4 to the top would deny the first and third packets before their specific permits were considered. Conversely, making rule 3’s source “ANY” would incorrectly allow the second packet. In a configuration PBQ, check both each row’s fields and its position in the ruleset.

The Firewall ACL Rules lab in the linked Security+ library uses these web and database addresses. After you can explain each packet decision, use that lab to build the rules yourself.