Know what you are walking into
Performance questions open the exam (simulations, not multiple choice) and they grade partially: each correct element earns credit even in an imperfect answer. That changes strategy completely. A half-finished PBQ you attempted beats a perfect one you never reached, and flagging-and-returning beats freezing.
The time budget
Assume up to 6 simulations in 90 minutes. Give the PBQ section 20-25 minutes TOTAL on first pass: 3-4 minutes each, flag anything stuck, move on. Multiple-choice is faster per point. Bank those points, then return with remaining time. Never spend 15 minutes perfecting one firewall while 20 multiple-choice wait.
By simulation type
- Firewall/ACL sims. Read the GOAL first (which flows must pass, which must drop), then write rules top-down: specific allows, then denies, remembering implicit deny-all cleans up. Test with the scenario's own tools (ping, port checks) before submitting.
- Terminal sims. Run the read-only commands first (status, lists, logs) before changing anything. One change, one verification. Stacked untested changes are how sims break.
- Log-analysis sims. Sort by time, find the first anomaly, then follow that thread, earliest evil first. Answer what the logs PROVE, not what you suspect.
- Matching/ordering sims. Eliminate the certain pairs first (attack→indicator you know cold), then reason the rest. Order questions follow process order you already memorized (IR phases, malware removal steps).
Partial-credit thinking
Graders award per-element credit: every correct rule, log line, and match counts. So attempt EVERYTHING, even uncertain. A reasoned partial answer outscores a blank, and blanks are the only unforgivable PBQ sin. When time runs short, dump certain elements first (the allow rule you know, the log line you spotted, the two matches you're sure of), then gamble the rest: secured points before speculative ones.
A firewall sim, walked through
Goal: 'The DB server (10.0.2.15) must accept SQL from the app server (10.0.1.8) only; nothing else reaches it.' Your rules, top-down: 1) allow TCP 1433 from 10.0.1.8 to 10.0.2.15, 2) deny all to 10.0.2.15, 3) let implicit deny handle the rest. Then verify with a port scan from a third host (should fail) and from the app server (should succeed). Write specific-before-general, verify both directions, submit. That rhythm passes every firewall sim on every exam.
Practice like exam day
Simulate with the same constraints: no hints, no pausing the clock, sims first. The app's PBQ labs run an exam skin with deferred grading for exactly this: study skin for learning, exam skin for proving.
This guide is the tactical version. The full PBQ method is the long one: what each shape is really testing, how to read a graded breakdown, and a two-week drill plan with the mistakes that cost points written out.
What partial credit really means
A PBQ is not one question. It is a set of scored elements: each rule, each match, each filled field. You are graded on how many elements are right, not on whether the whole answer is perfect. That single fact changes how you should behave. A blank is zero elements. A partial attempt with the easy elements done is already points.
It also changes how you rehearse. In practice, do not restart a lab because one step went wrong. Submit it, read the graded breakdown, and notice which elements you got. The exam will not offer a restart.
The first five minutes
Read every PBQ title before starting any of them. You are looking for the one you can finish fast. Do that one first. It banks points, settles your nerves, and tells you how the interface behaves. Then take the next easiest. Leave the longest scenario for after the multiple-choice, when you know how much time is actually left.
Do not read every exhibit in full on the first pass. Read the goal line, then decide. Exhibits are where time disappears.
A terminal PBQ, walked through
The goal says a service must answer on a port, and the scenario gives you a host and a credential. Do not start typing commands. First run the read-only checks: address, route, listening ports, service status. That tells you whether the problem is the service, the firewall, or the address. Make one change. Verify it with the same check you used before. If it worked, move to the next requirement. If it did not, revert before trying something else.
Stacked changes are the classic terminal failure. Three untested edits turn one problem into three, and the clock does not care why.
A log PBQ, walked through
Sort by time. Find the first event that does not belong, not the loudest one. Follow that thread forward: what did the same source do next, what did the same account do next, what changed on the destination. Answer only what the logs prove. If the question asks for the compromised account, give the account the evidence supports, not the one that feels likely.
When two sources disagree, trust the one closer to the event. A firewall log knows a connection was allowed. A proxy log knows what was requested. An endpoint log knows what ran. Say what each proves before you conclude.
Five traps that cost easy points
- Perfecting one PBQ. A beautiful firewall configuration that costs 15 minutes fails the next three questions for you.
- Ignoring the goal line. The scenario text is flavor; the goal line is the grading rubric.
- Changing several things at once. One change, one verification, every time.
- Leaving fields blank. An unsure guess is worth a chance at credit. A blank is worth nothing.
- Forgetting to submit. Flagged work still needs a final submit. Check the review screen for unanswered items before you end the section.
A timing plan you can actually follow
First pass: 3-4 minutes per PBQ, flag anything stuck. Multiple-choice: about 45 seconds each, faster when the answer is obvious. Return: spend the remaining time on flagged PBQs in the order you are most likely to earn elements. Last two minutes: confirm no blanks and submit.
If you finish with ten minutes left, do not reopen a PBQ you already completed unless you have a specific correction in mind. Vague second-guessing changes right answers to wrong ones more often than the reverse.