TL;DR
Firewall simulations reward one method: read the goal first, assume deny, pin direction and ports, write rules top-down from most specific to general, then verify each requirement against the finished set. The walkthrough below applies that method to an original practice scenario (ours, not exam content) so you can reuse the steps on any form.
By SecLern Editorial. Published 2026-10-18. The scenario is original SecLern practice content, clearly labeled throughout. It is not CompTIA content and predicts nothing about your form. Method checked against the firewall lab behavior in our own study labs.
How firewall sims present the task
A typical item shows a topology or zone diagram, a requirements list (who must reach what, who must never reach what), and an editable rule table with order, source, destination, port or service, and action. Some form of implicit deny sits at the bottom whether printed or not. Your job is translating requirements into ordered rules that permit exactly the required flows and nothing else. The exam scores the resulting policy, so a rule that is right but misordered can still fail, and a rule that is generous (permits extra flows) fails the security half of the task. Before touching anything, confirm the current interface behavior in the tutorial: know how to add, reorder, and delete rules, because fumbling the controls under time is the most common unforced error. Our exam-day checklist covers the sim-first exam layout this item type arrives in.
Step 1: read the goal before the diagram
Read the requirements list first and restate the goal in one sentence: which flows must work, which must fail. Circle every direction word (inbound, outbound, to, from) and every secure-variant cue (securely, encrypted, management). Only then study the diagram, labeling each host with its zone and role. This order matters because diagrams seduce you into wiring what you see instead of permitting what is asked. In our practice scenario, the goal reads: the web server in the DMZ must serve public HTTPS, the internal database must accept queries only from the app server, and remote administration must work only from the jump host over secure shell. One sentence, three flows, two explicit denies implied. Write that sentence on the scratch area before you click anything.
Step 2: assume deny, then pin each flow
Start from deny-all in your head: nothing passes until a rule permits it. For each required flow, pin four facts: source, destination, port with protocol, and direction relative to the firewall. Our scenario resolves to: public source to DMZ web server on TCP 443 inbound; app server to internal database on the database port the scenario names (use the given number, never your memorized default, when they differ); jump host to all servers on TCP 22 for administration. Direction errors are the top miss here: traffic to the web server is inbound from outside, database traffic stays internal, and admin access originates from the jump host outward. Drill the ports sheet until 22, 80, 443, 389, and 636 map to jobs instantly, but always let the scenario's numbers win over memory. If the scenario encrypts a flow, pick the secure variant even when the plaintext cousin looks familiar.
Step 3: order rules specific-first
Firewalls evaluate top-down and stop at the first match, so order is policy. Place explicit permits for the required flows first, most specific at top: admin access from the single jump host before broader server rules, database access from the single app server before any internal permit, public HTTPS to the single web server as its own line. Then place explicit denies for the named threats (direct public access to the database, admin access from anywhere but the jump host), and let the implicit deny catch the rest. The classic failure is a broad permit above a specific deny: allowing internal-to-DMZ traffic generally, then wondering why the database deny never fires. Another is mirroring every rule bidirectionally out of habit; return traffic is handled by state, and mirrored rules widen the policy beyond the requirement. Write three to six tight rules rather than a dozen loose ones.
Step 4: the verification pass
Before submitting, test each requirement against the finished table as an imaginary packet. Public client to web server on 443: which rule matches first, and is the action permit. Attacker to database from outside: confirm no rule matches before the deny, and the action is deny. App server to database: permit via the specific rule. Random host attempting SSH to a server: deny, because only the jump host matches a permit. Then test the negatives the requirements imply: HTTP on port 80 to the web server when only HTTPS was asked (should fail), database access from the web server itself (should fail unless required). This pass takes about ninety seconds and catches most ordering slips. If a check fails, fix the order or the scope, never add a broad exception to paper over it. Broad exceptions are how generous policies (and failed items) happen.
The five traps, named
First, direction blindness: answering with the right port and the wrong arrow. Second, secure-variant splits: the scenario says securely and the options offer both 80 and 443 or both 23 and 22. Third, memorized ports over given ports: the scenario names a nonstandard database port and memory overrides it. Fourth, order inversion: correct rules, wrong sequence. Fifth, over-permitting under time pressure: a final any-any rule added to make things work that also makes everything fail. Each trap has a tell: direction words in the stem, the word securely, a port number printed in the scenario, a deny that never fires in verification, and a rule with any in two columns. Learn the tells, not just the rules, and firewall sims become routine. Rehearse the full method weekly in study labs until the verification pass feels automatic.
Second worked example: database tier lockdown
Same method, tighter scenario. Requirements: the app server (internal zone) must query the database on the named port; the backup server must reach the database on the backup port nightly; no other host may reach the database; administration from the jump host only. Pin the flows: app to database on the given query port, backup to database on the given backup port, jump host to database on TCP 22. Order specific-first: jump-host SSH permit, app-server query permit, backup-server backup permit, explicit deny for the web server to the database (the exam names this temptation because the web tier sits adjacent), then implicit deny. Verification walk: app query hits rule two as permit; web server query falls through to the explicit deny; a random internal host falls to implicit deny; backup traffic at night matches rule three regardless of hour, since time windows apply only if the scenario states them. The teaching point: backup flows are the forgotten permit. Candidates who wire the application path and stop leave the backup requirement red, and the generous fix (permit the whole internal zone to the database) fails the security half. Enumerate every named host before writing rule one, and the backup server stops being invisible.
Sources
- CompTIA Security+ V7 page (exam format and objectives home)
- SecLern firewall lab behavior, verified in-app 2026-10-18 (rule ordering and verification method)
Read next
Pair this with PBQ log triage for the other common sim family, PBQ time management for the sim-section budget, and the ports method for instant service mapping. Drill daily in study.