Attack-to-Mitigation PBQ Tables
Key Takeaways
- PBQs map symptom to attack to control; identify the attack path first, then pick the least-disruptive fix.
- Layer 2 attacks: port security, DHCP snooping, dynamic ARP inspection, access-mode ports, 802.1X.
- Wireless attacks: WPA3 or WPA2-Enterprise with 802.1X, certificate validation, wireless IDS, user training.
- Volumetric DDoS needs upstream/cloud scrubbing because local firewalls sit behind the saturated link.
- Choose the control that breaks the specific path, and always preserve logging and validation.
Attack-to-Mitigation Tables
Performance-based questions (PBQs) on the N10-009 ask you to drag controls onto a topology, toggle device settings, or complete a policy table. With a 90-minute clock and up to 90 items, do not over-think them. The reliable method: identify the attack path first, then pick the control that breaks that path with the least side effect.
Layer 2 and Access Edge
| Symptom or evidence | Likely attack | Best mitigation direction |
|---|---|---|
| A user port negotiates as a trunk and reaches other VLANs | VLAN hopping / trunk misconfig | Force access mode, disable DTP, restrict allowed VLANs, harden native VLAN |
| CAM table fills with many source MACs | MAC flooding | Port security with MAC limits, storm control, 802.1X |
| Clients get a wrong gateway and DNS | Rogue DHCP | DHCP snooping, trust only the uplink port, hunt the rogue server |
| ARP cache maps the gateway IP to an attacker MAC | ARP poisoning | Dynamic ARP inspection bound to DHCP snooping; static entries for critical hosts |
| Unknown device plugged into an office jack | Unauthorized access | 802.1X / NAC, disable unused ports, port security |
DNS, Wireless, and User-Focused Attacks
| Symptom or evidence | Likely attack | Best mitigation direction |
|---|---|---|
| Known hostname resolves to an unexpected IP | DNS / rogue DNS poisoning | Harden DNS infra, restrict resolver assignment, monitor changes, DNSSEC where supported |
| Familiar SSID with a weak signal near the lobby | Evil twin | WPA3 or WPA2-Enterprise, certificate validation, wireless IDS, user training |
| Clients repeatedly drop, then join a fake portal | Deauth abuse + evil twin | Wireless monitoring, strong enterprise auth, no auto-join to open networks |
| Help desk resets a VPN password after a suspicious call | Social engineering | Identity-verification procedure, MFA reset controls, training, ticket evidence |
| User enters credentials into a fake VPN page | Phishing | MFA / phishing-resistant auth, domain monitoring, reporting workflow |
Availability and Perimeter
| Symptom or evidence | Likely attack | Best mitigation direction |
|---|---|---|
| Internet circuit saturated from many sources | Volumetric DDoS | ISP coordination, scrubbing provider, CDN/anycast, upstream rate limiting |
| Firewall session table exhausted | State-exhaustion DoS | Tune limits, rate limit, upstream filtering, capacity planning |
| Web app overwhelmed by expensive requests | Application-layer DoS | WAF, rate limiting, caching, application tuning |
| Public DNS receives amplified response floods | Reflection / amplification | Provider mitigation, source validation, rate limiting, close open resolvers |
Management Plane and Credential Abuse
| Symptom or evidence | Likely problem | Best mitigation direction |
|---|---|---|
| Admin logins from unusual countries | Compromised credential | MFA, geofencing, conditional access, account review |
| Router changed via a shared admin account | Weak accountability | Named accounts, TACACS+, command authorization, accounting logs |
| SNMP community string seen in a packet capture | Insecure management protocol | Use SNMPv3 with authentication and privacy |
| Management interface reachable from the guest VLAN | Excessive exposure | ACLs, dedicated management VLAN, jump host, firewall rules |
The PBQ Method
- Identify the affected layer: physical, wireless, Layer 2, IP, DNS, application, identity, or provider edge.
- Identify the asset and trust boundary: guest, user, server, management, cloud, or OT.
- Match the evidence to a specific attack, not a vague fear.
- Select the control that blocks that exact path.
- Preserve visibility: logs, alerts, and a validation test from the source network.
Worked Example: Completing a Switch-Hardening PBQ
A PBQ presents an access switch with these requirements: prevent VLAN hopping, stop rogue DHCP, and block ARP spoofing, while leaving the uplink to the distribution switch fully functional. The defensible drag-and-drop answer is layered. On every user-facing port: set switchport mode access, assign the user VLAN, disable DTP, and enable port security with a low MAC limit. On the single uplink port: leave it as the trunk, restrict allowed VLANs, and mark it as the DHCP-snooping trusted port so legitimate offers from the real server pass while rogue offers on user ports are dropped.
Globally enable DHCP snooping and dynamic ARP inspection for the user VLANs. Notice the uplink is trusted and the user ports are untrusted; reversing that breaks legitimate DHCP, which is the trap option the exam plants.
Why Order of Operations Matters
Many candidates lose PBQ points by choosing a control that is correct in isolation but applied at the wrong place. DAI depends on the DHCP-snooping binding table, so snooping must be enabled first or DAI has no valid bindings to check and may drop everything. Likewise, IP source guard relies on the same binding table. For availability, a WAF in front of a web application stops application-layer floods but does nothing for a volumetric flood that saturates the circuit upstream of the WAF. The exam consistently rewards placing the control at the point in the path where it can actually see and act on the malicious traffic.
Common Traps
- A firewall rule will not solve a rogue DHCP problem on the same access VLAN, because DHCP discovery is local broadcast traffic the firewall never sees.
- Encryption does not stop a user from joining a fake SSID if certificate validation is ignored.
- DDoS filtering must happen before the bottleneck link when bandwidth is already saturated.
- Enable DHCP snooping before dynamic ARP inspection; DAI needs the snooping binding table to validate ARP.
- A good mitigation answer includes validation, such as testing from the guest VLAN or reading switch security counters.
- More controls are not better if they do not address the observed path; match the fix to the evidence.
A PBQ shows user switch ports dynamically negotiating into trunks, granting unauthorized VLAN access. Which configuration should be applied to those user ports?
A company's Internet link is saturated by traffic from thousands of sources before packets ever reach the firewall. Which mitigation is most relevant?
Which attack-to-mitigation pairs are appropriate? Select three.
Select all that apply