Performance-Based Question Workshop
Performance-based questions (PBQs) are the part of the Security+ exam that candidates worry about most. Instead of choosing one option from four, you are dropped into a small simulation: a firewall rule table to reorder, a network diagram to populate, a set of log excerpts to interpret, or a list of controls to drag into categories. The concepts are the same ones you studied in Chapters 1 through 27. What changes is the format: you must apply several ideas at once, in a specific environment, without the help of answer choices that hint at the right direction.
This workshop gives you twelve realistic PBQs that span all five exam domains. Each one presents a scenario, the exhibits you would see on screen (tables, logs, or configuration fragments), and the task. Then a Walkthrough section reasons through the problem step by step, the way an experienced analyst would, and arrives at the solution. Work each problem on paper before reading the walkthrough. The value of this workshop comes from struggling with the exhibits yourself first.
How PBQs Work
PBQs usually appear at the start of the exam, typically somewhere between two and five of them. They come in a handful of recurring formats:
Format What you do Examples
Drag-and-drop matching
Drag items into categories or onto descriptions
Controls to categories, attacks to indicators, data to classification levels
Ordering Arrange steps into the correct sequence Incident response phases, order of volatility, firewall rule order
Configurati
on
Choose settings from drop-down menus or fill in fields
Wireless security settings, firewall rules, email DNS records
Diagram placement
Place devices or controls onto a network diagram
Firewalls, WAF, IDS sensor, jump server, VPN concentrator
Analysis Review logs, scan output, or a dashboard and draw conclusions
SIEM events, authentication logs, certificate errors, vulnerability scans
Most PBQs combine formats. A log-analysis PBQ might ask you to identify the attack and then drag the correct mitigation onto the affected host. A placement PBQ might ask you to place devices and then configure one of them.
A Strategy for PBQs
The single most useful habit is time management. PBQs can consume ten minutes or more each, and the exam gives you 90 minutes for up to 90 questions. A widely recommended approach is:
- 1. Read each PBQ when it appears, but if it looks long, flag it and move on.
- 2. Answer all multiple-choice questions first, banking the points you can earn quickly.
- 3. Return to the flagged PBQs with your remaining time, starting with the one that looked easiest. When you do work a PBQ, follow a consistent method:
- 1. Read the entire task statement first. Note exactly what is being asked: "Select all that apply," "Each item may be used once, more than once, or not at all," or "Not all fields are required." These phrases change the answer.
- 2. Inventory the exhibits. Scroll every panel, click every device, open every tab. Many PBQ mistakes come from missing a second log file or a pop-up that contains the key detail.
- 3. Write down the requirements. Translate the scenario into a short checklist (for example: "HTTPS only to web server; SSH only from admin subnet; block known-bad range; deny everything else").
- 4. Solve the easy pieces first. Drag the items you are certain of, then use elimination for the rest. Matching questions often have one answer per slot, so each certain placement narrows the remaining choices.
- 5. Check against the requirements. Before you submit, walk your checklist one more time.
Exam tip
Partial credit is widely believed to be available on PBQs, so never leave one blank. Even if you are unsure of some placements, completing the parts you know is worth more than skipping the item entirely.
Common trap
Some PBQs include a reset button that clears all of your work in that question. Click it only when you truly want to start over. Also be careful with the exam's navigation: make sure you have finished a PBQ before moving away from it if you are not sure whether you can return.
Memory aid
The PBQ method in five words: Read, Inventory, List, Solve, Check. Requirements first, exhibits second, answers third.
PBQ 1: Firewall Rule Ordering
Domains covered: 3.2 (device placement, security zones) and 4.1 (rule-based firewalls). See Chapters 11 and 14.
Scenario
You are a network security administrator for a mid-sized engineering firm. A contractor recently left a "temporary" troubleshooting rule on the perimeter firewall, and an audit found several other problems with the rule set. Management has given you the following requirements for the firewall that sits between the internet, the DMZ, and the internal network:
- Internet users must be able to reach the public web server only over HTTPS.
- The web server may connect to the database server only on the Microsoft SQL Server port.
- Administrators on the management subnet, and only that subnet, may use SSH to manage the web server.
- Internal users must reach the web only through the forward proxy; direct outbound web access is not permitted.
- The internal DNS server may resolve names using external DNS servers.
- All traffic from a known-malicious network identified by threat intelligence must be blocked.
- All other traffic must be denied.
Exhibits
Exhibit 1: Network addressing
- Asset Address
- Public web server (DMZ, after NAT) 10.10.10.10
- Database server (internal data zone) 10.20.0.5
- Internal user network 10.1.0.0/16
- Management subnet 10.1.50.0/24
- Forward proxy 10.1.1.20
- Internal DNS server 10.1.1.53
- Malicious network (threat feed) 198.51.100.0/24
Exhibit 2: Current rule set (processed top-down, first match wins)
Rule Action Source Destination Protocol Port
1 allow any any any any
2 allow any 10.10.10.10 tcp 443
Rule Action Source Destination Protocol Port
3 deny 198.51.100.0/24 any any any
4 allow 10.10.10.10 10.20.0.5 tcp 1433
5 allow any 10.10.10.10 tcp 22
6 ALLOW 10.1.1.20 ANY TCP 80, 443
7 allow 10.1.1.53 any udp 53
8 ALLOW 10.1.0.0/16 ANY TCP 80, 443
9 deny any any any any
Task
Modify, delete, add, and reorder rules so that the rule set meets every requirement. The firewall is stateful, so return traffic for permitted sessions is allowed automatically.
Walkthrough
Step 1: Remember how the firewall processes rules. A rule-based firewall evaluates rules from top to bottom and stops at the first match. That single fact explains most of what is wrong here. Any rule placed below a broader rule that matches the same traffic will never be evaluated; it is shadowed. Step 2: Find the rule that breaks everything. Rule 1 allows any source to any destination on any protocol. Because it is first, every packet matches it, and rules 2 through 9 are never reached. The block of the malicious network, the SSH restriction, and the final deny are all meaningless. Rule 1 is the contractor's leftover troubleshooting rule. Delete rule 1. In a real organization, removing it should go through change management (Chapter 2), but the audit has already identified it as unauthorized. Step 3: Put the block list first. The requirement says all traffic from 198.51.100.0/24 must be blocked. If the deny rule sits below rule 2, a host in that network can still reach the web server on 443, because rule 2 matches first. Deny rules for known-bad sources belong at the top so that no later allow rule can override them. Move rule 3 to the top.
Step 4: Check each allow rule against least privilege.
- Rule 2 (any to web server on TCP 443) matches the HTTPS-only requirement. Keep it.
- Rule 4 (web server to database on TCP 1433) matches the requirement exactly: one source, one destination, one port. Keep it.
- Rule 5 allows SSH to the web server from ANY source, which exposes SSH to the entire internet. The requirement limits SSH to the management subnet. Change the source of rule 5 to 10.1.50.0/24.
- Rule 6 lets the proxy reach the web on 80 and 443. Keep it.
- Rule 7 lets the internal DNS server send queries on UDP 53. DNS also uses TCP 53 for large responses (including many DNSSEC responses) and zone transfers. Because the requirement is that the DNS server be able to resolve names, add TCP 53 for 10.1.1.53. Some exam versions accept UDP only; if the drop-down offers "TCP/UDP," choose it.
- Rule 8 lets every internal host browse directly, which violates "web only through the proxy." Delete rule 8.
Step 5: Keep the explicit deny last. Rule 9 is the explicit deny-all. Most firewalls have an implicit deny at the end anyway, but an explicit rule makes the intent clear and, on many products, allows you to log denied traffic. It must be the last rule; anything placed after it can never match.
Step 6: Order specific before general. Among the allow rules, order matters less here because none of them overlap, but a good habit is to place the most specific rules (single host to single host) before broader ones. That habit prevents future shadowing when someone adds a rule later.
Solution:
Rule Action Source Destination Protocol Port
1 deny 198.51.100.0/24 any any any
2 allow 10.10.10.10 10.20.0.5 tcp 1433
3 allow 10.1.50.0/24 10.10.10.10 tcp 22
4 allow any 10.10.10.10 tcp 443
5 ALLOW 10.1.1.20 ANY TCP 80, 443
6 allow 10.1.1.53 any tcp/udp 53
7 deny any any any any
Exam tip
On firewall PBQs, scan for three classic errors before anything else: an "any/any allow" near the top, a deny rule placed below an allow that matches the same traffic, and a deny-all that is not at the bottom. Fixing those three usually earns most of the credit.
Note
Notice that no rule permits port 80 to the web server. If a scenario requires automatic HTTP-to-HTTPS redirects, you would add TCP 80 to the web server, but this scenario said HTTPS only. Follow the stated requirements, not what you would do at work.
PBQ 2: Classify Security Controls
Domains covered: 1.1 (control categories and types). See Chapter 1.
Scenario
A hospital's compliance team is building a control inventory for an upcoming assessment. They have listed twelve controls and need each one tagged with its category (technical, managerial, operational, or physical) and its primary type (preventive, deterring, detective, corrective, compensating, or directive).
- Exhibit
- Item Control description
- A Concrete bollards in front of the emergency department entrance
B A login banner stating that access is monitored and misuse will be prosecuted C An intrusion detection system that alerts on suspicious network traffic D A written acceptable use policy that every employee must sign
E Restoring a ransomware-encrypted file server from last night's backup F A security officer who reviews badge-access reports every morning for anomalies G A legacy imaging system that cannot be patched is placed on an isolated VLAN with strict ACLs H A sign on the server room door reading "Authorized Personnel Only"
I Multifactor authentication on the electronic health record system
J Fire suppression system that activates in the data center
K Instructor-led sessions in which the security team teaches staff the required steps for handling patient records
L Motion sensors in the pharmacy storeroom after hours
Task
Drag a category and a primary type onto each control. Categories and types may be used more than once.
Walkthrough
Step 1: Separate the two questions. Category answers how the control is implemented: technology (technical), management decision or document (managerial), people doing tasks (operational), or tangible barriers and environment (physical). Type answers what the control does relative to an incident: stop it (preventive), discourage it (deterring), discover it (detective), fix it (corrective), substitute for a control that cannot be used (compensating), or instruct behavior (directive).
Step 2: Work through each item.
- A. Bollards are tangible barriers that physically stop a vehicle. Physical, preventive.
- B. Login banner is displayed by a system (technical) and works by discouraging misuse through the threat of consequences. Technical, deterring. Some candidates call it directive; the key word is "prosecuted," which signals deterrence.
- C. IDS is technology that discovers attacks but does not block them (an IPS would be preventive). Technical, detective.
- D. Acceptable use policy is a management document that tells people what to do. Managerial, directive.
- E. Restoring from backup fixes damage after an incident. Technical, corrective.
- F. Reviewing badge reports is an activity a person performs daily, looking for problems after the fact. Operational, detective.
- G. Isolating an unpatchable system is a technical control (VLAN and ACLs) used because the preferred control (patching) is not possible. Technical, compensating.
- H. "Authorized Personnel Only" sign is a physical item that instructs behavior. Physical, directive. A sign that says "Trespassers will be prosecuted" would lean deterring; this one simply tells people the rule.
- I. MFA is technology that stops unauthorized logins. Technical, preventive.
- J. Fire suppression limits and corrects damage once a fire starts. Physical, corrective.
- K. Instructor-led handling training is an activity people perform (delivering training), so it is operational. Its purpose is to tell staff what they must do. Operational, directive. A policy requiring the training would be managerial; delivering it is operational.
- L. Motion sensors are physical devices that detect presence. Physical, detective.
Memory aid
Signs are the trickiest items. "Authorized personnel only" directs. "Under video surveillance" or "Violators will be prosecuted" deters. Read the exact wording on the sign.
Common trap
Do not confuse compensating with corrective. Corrective acts after an incident to restore normal operations. Compensating is chosen in advance because the primary control is unavailable, too expensive, or technically impossible.
PBQ 3: Match Attacks to Indicators
Domains covered: 2.5 (indicators of malicious activity). See Chapter 8.
Scenario
You are a SOC analyst reviewing five alerts escalated overnight. For each log excerpt, identify the attack that the indicators most strongly suggest.
Exhibits
Exhibit A: Identity provider sign-in log
2026-09-14 02:11:04 user=a.nguyen src=203.0.113.44 result=FAIL reason=bad_password 2026-09-14 02:11:05 user=b.ortiz src=203.0.113.44 result=FAIL reason=bad_password 2026-09-14 02:11:05 user=c.patel src=203.0.113.44 result=FAIL reason=bad_password 2026-09-14 02:11:06 user=d.kowalski src=203.0.113.44 result=FAIL reason=bad_password ... (418 more accounts, one attempt each, same source) ...
2026-09-14 02:19:52 user=r.hughes src=203.0.113.44 result=SUCCESS
Exhibit B: Web server access log
198.51.100.23 - - [14/Sep/2026:03:02:11] "GET /download.php?file=report.pdf HTTP/1.1" 200
198.51.100.23 - - [14/Sep/2026:03:02:19] "GET /download.php?file=../../../../etc/passwd
Http/1.1" 200
198.51.100.23 - - [14/Sep/2026:03:02:27] "GET /download.php?file=..%2f..%2f..%2fetc %2fshadow HTTP/1.1" 403
Exhibit C: Application log
2026-09-14 03:40:02 login attempt user="admin' OR '1'='1' -- " pw="x"
2026-09-14 03:40:02 query: SELECT * FROM users WHERE name='admin' OR '1'='1' -- ' AND pw='x'
2026-09-14 03:40:02 login SUCCESS user=admin
Exhibit D: Cloud identity sign-in log for one user
2026-09-14 08:02:15 user=k.lindqvist result=SUCCESS geo=Toronto, CA device=managed
2026-09-14 08:31:47 user=k.lindqvist result=SUCCESS geo=Bucharest, RO device=unknown
2026-09-14 08:31:47 sessions active for k.lindqvist: 2
Exhibit E: Endpoint telemetry
parent=WINWORD.EXE child=powershell.exe
cmdline: powershell -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoA...
- network: powershell.exe -> 192.0.2.77:443
- file writes: none
- Task
Match each exhibit to one attack: password spraying, brute force, directory traversal, SQL injection, impossible travel with credential compromise, fileless malware, buffer overflow, replay attack. Not all attacks are used.
Walkthrough
Exhibit A. One source address tries one password against hundreds of different accounts, then finally
succeeds on one. This is the signature of password spraying: few attempts per account (staying below lockout thresholds) across many accounts. Brute force, by contrast, would show many attempts against the same account. The success at the end means at least one account has a weak, commonly guessed password and is now compromised; the response should include resetting that account and checking its activity.
Exhibit B. The ../ sequences ask the server to climb out of the web directory into the operating
system's file system. The second request returned 200 OK for /etc/passwd, which means the attack likely succeeded. The third request uses URL encoding (%2f is /) to try to evade filters, and was blocked with 403. This is directory traversal.
Exhibit C. The single quote closes the string literal, OR '1'='1' makes the condition always true, and --
comments out the rest of the query, including the password check. The query log shows the injected text being executed directly. This is SQL injection. The fix is parameterized queries and input validation (Chapter 14).
Exhibit D. The same user signed in from Toronto and then, 29 minutes later, from Bucharest on an
unknown device, with two concurrent sessions. No one can travel that distance in half an hour. This is impossible travel, with concurrent sessions as a second indicator, and it suggests the credentials (or a session token) have been compromised.
Exhibit E. Microsoft Word spawning PowerShell is abnormal and typically means a malicious macro
executed. The -nop -w hidden -enc flags run PowerShell with no profile, a hidden window, and a Base64-encoded command. The process connects out to an external address on 443, and nothing is written to disk. This is fileless malware, a living-off-the-land technique that runs in memory using built-in tools. Solution:
Brute force, buffer overflow, and replay attack are unused distractors.
Exam tip
For credential attacks, count two things: how many accounts and how many attempts per account. Many accounts with few attempts each is spraying. One account with many attempts is brute force. A valid credential or token reused from captured traffic is replay.
PBQ 4: Place Devices in Network Zones
Domains covered: 3.2 (device placement, security zones, attack surface) and 4.1 (WAF, IDS/IPS, NAC). See Chapters 11 and 14.
Scenario
An online retailer is redesigning its data center network. The diagram has four zones separated by firewalls: the Internet edge, a screened subnet (DMZ), an internal user zone, and a restricted data zone that contains the customer database and payment systems. A separate management network connects to the management interfaces of all infrastructure. You must place the following devices. Exhibit: Devices to place
Device Purpose
Web application firewall (WAF) Inspect HTTP/HTTPS requests to the e-commerce site Reverse proxy / load balancer Terminate TLS and distribute requests across web servers Web servers (2) Host the public storefront
- Database server Store customer and order data
- NIPS Block malicious traffic inline
- NIDS sensor Passively monitor traffic to the restricted data zone
- Jump server Single, hardened entry point for administrators
- SIEM collector Aggregate logs from all zones
- VPN concentrator Terminate remote-access VPN connections for employees
802.1X-capable switch with NAC Authenticate wired devices before granting access Task
Drag each device to the most appropriate zone or position on the diagram (Internet edge, DMZ, internal user zone, restricted data zone, or management network).
Walkthrough
Step 1: Identify the trust levels. The internet is untrusted. The DMZ is semi-trusted: it holds systems that must accept connections from the internet, isolated so that a compromise does not lead directly to the internal network. The internal user zone is trusted for employees but contains endpoints that browse the web and open email, so it is a common foothold for attackers. The restricted data zone holds the crown jewels and should be the hardest to reach. The management network should be reachable only by administrators through a controlled path.
Step 2: Place the public-facing stack. Requests from customers arrive from the internet. The NIPS sits inline at the Internet edge, behind the perimeter firewall, where it can drop known attack traffic before it reaches anything else. The reverse proxy/load balancer and the WAF go in the DMZ in front of the web servers. The WAF needs to see decrypted HTTP to inspect it for injection and cross-site scripting, so it is placed where TLS has been terminated (on the load balancer or the WAF itself). The web servers go in the DMZ.
Step 3: Protect the data. The database server goes in the restricted data zone. Web servers reach it only through the internal firewall on the database port, exactly as in PBQ 1. Never place a database in the DMZ: if a web server is compromised, the attacker would be one hop from the data with no filtering in between.
Step 4: Add visibility. The NIDS sensor is placed on the link into the restricted data zone, fed by a SPAN (port mirror) or network TAP. Because it is passive, a failure does not interrupt traffic, and it watches the most sensitive segment for anomalies that slipped past the perimeter.
Step 5: Handle administrators and remote users. The jump server goes in the management network (some diagrams show it in its own small admin zone). Administrators connect to it with MFA, and only the jump server may connect to device management interfaces. The SIEM collector also belongs on the management network, where it can receive logs from every zone without being exposed to the internet. The VPN concentrator sits at the Internet edge / DMZ boundary, because remote users must reach it from the internet; after authentication their traffic is filtered by the internal firewall like any other.
Step 6: Control access at the edge of the user network. The 802.1X switch with NAC belongs in the internal user zone, where employees plug in laptops. It authenticates devices and checks posture before placing them on a VLAN.
- Solution:
- Device Placement
- NIPS Internet edge, inline behind the perimeter firewall
- VPN concentrator Internet edge or DMZ
- Reverse proxy / load balancer DMZ
- WAF DMZ, in front of the web servers
- Web servers DMZ
- Database server Restricted data zone
- NIDS sensor Link into the restricted data zone (via SPAN or TAP)
- Jump server Management network
- SIEM collector Management network
- 802.1X switch with NAC Internal user zone
Real-world scenario
During a real breach investigation at a retailer, analysts found that the attacker pivoted from a compromised web server directly to the payment database because both sat on the same flat network. The redesign in this PBQ is exactly what remediation looks like: a screened subnet for public servers, a separately firewalled data zone, and an inline control at the edge.
Inline devices (IPS, WAF, firewall) can block traffic but can also become a point of failure, so think about fail-open versus fail-closed (Chapter 11). Passive devices (IDS sensors, packet analyzers) only see copies of traffic and cannot block.
PBQ 5: Configure Secure Wireless Networks
Domains covered: 3.2 (secure communication and access), 4.1 (NAC, 802.1X), and 2.4 (wireless vulnerabilities). See Chapters 7, 11, and 14.
Scenario
A law firm is replacing its wireless network. The new controller supports three SSIDs, and the managing partner has given you these requirements:
- CORP: for firm-owned laptops. Each user must authenticate individually, credentials must not be shareable, and the firm already runs an internal PKI and a RADIUS server. Access should be revoked automatically when an employee leaves.
- GUEST: for clients in the lobby and conference rooms. Guests must accept the firm's terms of use, must not be able to reach internal systems or each other, and should have internet access only.
- IOT: for conference-room displays and building sensors that support only a pre-shared key. Exhibit: Controller configuration options (drop-downs for each SSID)
Setting Available choices
Security mode Open; WEP; WPA2-Personal; WPA2-Enterprise; WPA3-Personal; WPA3-Enterprise Encryption TKIP; CCMP (AES); GCMP-256 (AES)
Authentication None; PSK; SAE; 802.1X with PEAP-MSCHAPv2; 802.1X with EAP-TLS Protected Management Frames (802.11w)
- Disabled; Optional; Required
- WPS Enabled; Disabled
- Captive portal Off; On
- Client isolation Off; On
VLAN 10 (Corporate); 20 (Guest, internet only); 30 (IoT, restricted ACL)
Task
Select the most secure appropriate setting for each field on each SSID.
Walkthrough
Step 1: Eliminate the broken options. WEP is cryptographically broken and can be cracked in minutes; it is never correct. TKIP was a stopgap for WEP-era hardware and is deprecated. WPS (Wi-Fi Protected Setup) has a well-known PIN brute-force weakness, so it should be disabled on every SSID. These eliminations apply everywhere.
Step 2: Configure CORP. The requirements say individual authentication, non-shareable credentials, an existing PKI, and a RADIUS server. That combination points directly to WPA3-Enterprise with 802.1X using EAP-TLS. EAP-TLS uses a certificate on each device (and on the RADIUS server), so there is no password to share or phish, and revoking the user's account or certificate ends access. PEAP-MSCHAPv2 also uses 802.1X, but it relies on passwords and is vulnerable if clients do not validate the server certificate. Choose GCMP-256 (WPA3-Enterprise 192-bit mode) or CCMP if GCMP is unavailable; both are AES. Set PMF to Required (WPA3 mandates it), which prevents forged deauthentication frames from knocking users offline. Assign VLAN 10.
Step 3: Configure GUEST. Guests must accept terms of use, which is the job of a captive portal. They must not reach each other, which is client isolation. They must reach only the internet, which is VLAN
- 20. For encryption, the best choice here is WPA3-Personal with SAE using a passphrase displayed in the conference rooms and rotated regularly; SAE resists offline dictionary attacks and provides per-session keys, so guests cannot decrypt each other's traffic even though they share the passphrase. (If the controller offered "Enhanced Open" or OWE, that would also be acceptable for an open guest network, because it encrypts each client's traffic without a password.) Set PMF to Required.
Step 4: Configure IOT. The devices support only a pre-shared key. Choose WPA3-Personal (SAE) if the devices support it; otherwise WPA2-Personal with CCMP (AES) and a long, random PSK unique to this SSID. Because a PSK is shared and difficult to rotate, compensate with network controls: VLAN 30 with an ACL that lets the displays and sensors reach only their management servers. Client isolation should be On unless the devices need to talk to each other. Set PMF to Optional or Required depending on device support.
Solution:
Setting CORP GUEST IOT
Security mode WPA3-Enterprise WPA3-Personal (or OWE)
WPA3-Personal, else WPA2-Personal
Encryption GCMP-256 or CCMP (AES)
- CCMP (AES) CCMP (AES)
- Authentication 802.1X with EAP-TLS SAE SAE, else PSK (long, random)
- PMF Required Required Required if supported, else Optional
- WPS Disabled Disabled Disabled
- Captive portal Off On Off
- Setting CORP GUEST IOT
- Client isolation Off On On
Vlan 10 20 30
Common trap
Hiding the SSID (disabling broadcast) and MAC filtering are not security controls you should rely on. SSIDs appear in probe traffic and MAC addresses are trivially spoofed. If a PBQ offers them, they are rarely the "most secure" answer.
Memory aid
Enterprise = 802.1X + RADIUS + individual credentials. Personal = shared passphrase (PSK in WPA2, SAE in WPA3). EAP-TLS = certificates on both sides, the strongest EAP method.
PBQ 6: Certificate Troubleshooting
Domains covered: 1.3 (PKI, certificates, CRLs, OCSP, wildcards, root of trust). See Chapter 3.
Scenario
The help desk has received complaints about browser warnings on four internal and external websites. You have collected certificate details and the browser error for each.
- Exhibits
- Site 1: shop.example.com
- Subject: CN=www.example.com
- SAN: DNS:www.example.com, DNS:example.com
- Issuer: CN=Example Issuing CA 2
- Valid: 2026-02-01 to 2027-02-01
- Browser: NET::ERR_CERT_COMMON_NAME_INVALID
- Site 2: portal.example.com
- Subject: CN=portal.example.com
- SAN: DNS:portal.example.com
- Issuer: CN=Example Issuing CA 2
- Valid: 2025-08-15 to 2026-08-15
- Today: 2026-09-20
- Browser: NET::ERR_CERT_DATE_INVALID
- Site 3: api.example.com
- Subject: CN=api.example.com
- Issuer: CN=Example Issuing CA 2
- Chain sent by server: api.example.com (1 certificate)
- Desktop browsers: OK (intermediate cached)
- Mobile app / curl: unable to get local issuer certificate
- Site 4: vpn.example.com
- Subject: CN=vpn.example.com
- Issuer: CN=Example Issuing CA 2
- Valid: 2026-03-01 to 2027-03-01
OCSP response: certStatus=revoked reason=keyCompromise revoked=2026-09-18 Browser: NET::ERR_CERT_REVOKED
For each site, identify the root cause and select the correct fix from this list: renew the certificate; reissue with correct SAN entries; install the intermediate certificate in the server's chain; generate a new key pair, submit a new CSR, and replace the certificate; obtain a certificate covering the additional subdomain level; add the site to the browser's exceptions list.
Walkthrough
Site 1. Users browse to shop.example.com, but the certificate's Subject Alternative Name (SAN) list contains only www.example.com and example.com. Browsers validate the hostname against the SAN, not the CN, so the names do not match. Root cause: name mismatch. Fix: reissue the certificate with `shop.example.com` in the SAN (or move the shop to a hostname the certificate already covers). Site 2. The certificate expired on 2026-08-15, and today is 2026-09-20. Root cause: expired certificate. Fix: renew it. Then address the process failure that let it lapse: certificate inventory, expiration monitoring, and automated renewal (for example, ACME) prevent recurrence. This is a classic example of an availability problem caused by poor asset management (Chapter 15).
Site 3. The server sends only its leaf certificate. Desktop browsers often succeed because they cached the intermediate CA certificate from another site, but clients without that cache (mobile apps, curl) cannot build a path to the trusted root. Root cause: incomplete chain (missing intermediate). Fix: configure the server to send the intermediate certificate along with its own. The chain of trust runs leaf to intermediate to root; the root is already in the client's trust store, but the intermediate must be supplied.
Site 4. The OCSP responder says the certificate is revoked with reason keyCompromise. Renewing the same certificate is not enough, because the private key itself is no longer secret. Root cause: revoked certificate due to key compromise. Fix: generate a new key pair, create a new CSR, and install the new certificate, then investigate how the key was exposed. Never simply bypass the warning. Site 5. A wildcard certificate for *.example.com covers exactly one label in place of the asterisk: app.example.com and dev.example.com match, but dev.app.example.com (two labels) does not. Root cause: wildcard does not cover multiple subdomain levels. Fix: obtain a certificate that covers the additional level (for example, *.app.example.com or an explicit SAN entry for dev.app.example.com).
- Solution:
- Site Root cause Fix
- 1 Hostname not in SAN Reissue with correct SAN entries
- 2 Expired Renew the certificate
3 Missing intermediate in chain Install the intermediate in the server's chain 4 Revoked, key compromised New key pair, new CSR, replace the certificate 5 Wildcard covers one level only Obtain a certificate covering the additional subdomain level "Add the site to the browser's exceptions list" is never the right answer; it trains users to ignore warnings and leaves the underlying problem in place.
Exam tip
Match the error to the cause: COMMON_NAME_INVALID means a name problem, DATE_INVALID means expired or not yet valid (also check the client's clock), REVOKED means CRL or OCSP says the certificate is no longer trusted, and unable to get issuer or unknown authority means a chain or trust-store problem, including self-signed certificates.
Note
OCSP stapling lets the web server attach a recent, CA-signed OCSP response to the TLS handshake, so clients do not have to contact the CA themselves. It improves performance and privacy, and it is a common correct answer when a question asks how to reduce OCSP lookup delays.
PBQ 7: Incident Response and Evidence Ordering
Domains covered: 4.7 (incident response activities) and 4.8 (investigation data sources, system images). See Chapters 20 and 21.
Scenario
At 9:14 a.m., an EDR alert reports that an accounting workstation is encrypting files on a shared drive. The security team activates its ransomware playbook. Later, the team must also collect evidence from the workstation for a possible insurance claim and law enforcement referral.
Exhibit 1: Activities to order
Item Activity
A Conduct a lessons-learned meeting and complete a post-incident report with root cause analysis B Disconnect the workstation from the network using the EDR's isolation feature C Confirm the EDR alert is a true positive by reviewing file activity and process tree D Remove the malware, reset compromised credentials, and patch the exploited vulnerability E Restore encrypted files from immutable backups and monitor for reinfection F Maintain the playbook, train the team, and run tabletop exercises
G Determine scope: which accounts, hosts, and shares were affected and how the attacker got in
Exhibit 2: Evidence sources on the workstation
- Item Evidence source
- 1 Contents of RAM, including running processes and network connections
- 2 Local hard drive contents
- 3 CPU registers and cache
- 4 Firewall logs already shipped to the SIEM
- 5 Swap/page file and temporary files
- 6 Last year's archived backup tapes
- Task
Part 1: Place activities A through G in the order they should occur. Part 2: Order evidence sources 1 through 6 from most volatile to least volatile. Part 3: Identify the document that must accompany each piece of evidence.
Walkthrough
Part 1: Response order. The SY0-801 incident response activities flow as preparation, identification, investigation, containment, eradication and recovery, and post-incident activities, with notification and external reporting occurring when required along the way.
- F (preparation) happens before any incident. Without a playbook and trained staff, nothing else goes smoothly.
- C (identification) comes next: confirm that the alert is real. A false positive should not trigger isolation of a production system.
- G (investigation / scoping) determines how far the incident extends. In practice, quick scoping happens in parallel with containment during ransomware, but conceptually you must understand the scope to contain it completely.
- B (containment) stops the spread. EDR network isolation keeps the host powered on, which preserves volatile memory for forensics. Pulling the power cord would destroy that evidence.
- D (eradication) removes the cause: malware, attacker persistence, compromised credentials, and the vulnerability that allowed entry.
- E (recovery) restores normal operations from clean, immutable backups and watches for signs of reinfection.
- A (post-incident) captures lessons learned, the root cause, and the post-incident report so that preparation improves next time.
Order: F, C, G, B, D, E, A.
Note
Some exam versions combine identification and investigation, or list "detection and analysis." If you see fewer slots than activities, merge the steps that belong to the same phase rather than forcing an unusual order. Containment always comes before eradication, and eradication before recovery.
Part 2: Order of volatility. Collect the evidence that disappears fastest first. CPU registers and cache change in nanoseconds; RAM is lost at power-off; swap and temp files are overwritten during normal operation; disk contents persist; logs on a remote system persist longer and are outside the attacker's immediate reach; archival media is the least volatile.
Order: 3, 1, 5, 2, 4, 6.
Part 3: Documentation. Every item requires a chain of custody record showing who collected it, when, where it was stored, and every transfer of possession. Disk images should be bit-level copies verified with a hash (such as SHA-256) taken at acquisition and again before analysis, proving integrity. Because legal action is possible, the legal team may also issue a legal hold so that relevant data is not deleted. A manufacturer's IT staff once responded to ransomware by immediately shutting down every affected server. The encryption stopped, but so did any chance of recovering the encryption keys that were briefly resident in memory, and investigators lost the process and network-connection data that would have identified the initial access path. Network isolation, followed by a memory dump, would have contained the spread while preserving evidence.
PBQ 8: SIEM Log Analysis
Domains covered: 4.4 (SIEM, alerting), 4.8 (log types, log parsing), and 2.5 (indicators of compromise). See Chapters 8, 17, and 21.
Scenario
A SIEM correlation rule fired at 02:47 for "large outbound transfer to cloud storage." You pull the related events from several sources into a single timeline for the past 24 hours. The organization's domain is corp.example, and workstation WS-0142 belongs to a sales employee.
Exhibit: Correlated SIEM timeline
Time source host/user event
09:58 EmailGateway j.mercer@corp.example Delivered: "Q3 commission dispute.docm"
from billing@corp-example.co (SPF none)
10:03 EDR WS-0142 / j.mercer WINWORD.EXE spawned powershell.exe (-enc)
10:03 Proxy WS-0142 GET hxxp://update-cdn.example.net/a.ps1 200
- 10:04 EDR WS-0142 New scheduled task "OneDriveSync2" created
- 10:05 DNS WS-0142 Query beacon.update-cdn.example.net
- 10:10 DNS WS-0142 Query beacon.update-cdn.example.net
- 10:15 DNS WS-0142 Query beacon.update-cdn.example.net
- ... (repeats every 5 minutes)
- 13:22 EDR WS-0142 lsass.exe memory accessed by rundll32.exe
- 13:40 DC01 svc_backup 4624 Logon Type 3 from WS-0142
- 13:40 DC01 svc_backup 4672 Special privileges assigned
- 13:41 FS02 svc_backup 7045 Service installed: PSEXESVC
- 13:43 FS02 svc_backup 4720 User account created: helpdesk_tmp
- 13:44 FS02 svc_backup 4732 helpdesk_tmp added to Administrators
01:15 FS02 helpdesk_tmp 7-Zip created D:\Finance\archive.7z (4.1 GB)
- 02:31 Firewall FS02 -> 192.0.2.140 TCP 443 bytes_out=4,398,112,004
- 02:47 SIEM FS02 ALERT large outbound transfer
- 02:52 FS02 helpdesk_tmp 1102 The audit log was cleared
- Task
- Answer the following:
- 1. What was the initial attack vector, and which host is patient zero?
- 2. What persistence mechanism did the attacker establish?
- 3. What indicator shows command-and-control activity?
- 4. How did the attacker obtain privileged access and move laterally?
- 5. What evidence shows anti-forensic activity?
- 6. Which TWO hosts should be isolated first, and which TWO indicators should be blocked at the perimeter?
Walkthrough
- 1. Initial vector and patient zero. At 09:58 a macro-enabled Word document (.docm) arrived from a look-alike domain (corp-example.co instead of corp.example) with no SPF record. Five minutes later Word spawned an encoded PowerShell command on WS-0142. The vector is a phishing email with a malicious macro attachment; patient zero is WS-0142. The look-alike domain is typosquatting; better email authentication checks (PBQ 11) and macro blocking would have helped.
- 2. Persistence. At 10:04 a scheduled task named "OneDriveSync2" was created. The name imitates a legitimate service to blend in. Persistence: a malicious scheduled task.
- 3. Command and control. DNS queries to beacon.update-cdn.example.net occur at precise five-minute intervals. Humans do not browse on a fixed schedule; regular, periodic callbacks are beaconing, the hallmark of C2. The same domain served the PowerShell payload at 10:03.
- 4. Privilege and lateral movement. At 13:22 rundll32.exe accessed the memory of lsass.exe, the Windows process that holds credential material. That is credential dumping. Eighteen minutes later, the service account svc_backup logged on to the domain controller over the network (Event 4624, logon type 3) from WS-0142, a sales workstation, and received special privileges (4672). A backup service account has no reason to log on from a sales laptop. The attacker then used PsExec (Event 7045 installing PSEXESVC) to execute on FS02, created a new account (4720), and added it to Administrators (4732). Privilege was obtained by dumping credentials of an over-privileged service account; lateral movement used PsExec with those credentials. A group managed service account (gMSA) with least privilege and no interactive logon rights would have limited this (Chapter 11).
- 5. Anti-forensics. Event 1102 at 02:52 shows the security audit log was cleared, a form of log manipulation. Because the events were already forwarded to the SIEM, the evidence survived. This is why centralized log aggregation matters.
- 6. Containment priorities. Isolate WS-0142 (patient zero, still beaconing) and FS02 (where the attacker has an admin account and staged data). Block update-cdn.example.net (payload and C2 domain) and 192.0.2.140 (the exfiltration destination). Also disable helpdesk_tmp, reset svc_backup and j.mercer's credentials, and review DC01 for further activity, since the attacker authenticated to it with privileged credentials.
Solution summary:
Question Answer
Initial vector / patient zero Phishing email with macro-enabled document; WS-0142 Persistence Scheduled task "OneDriveSync2"
C2 indicator DNS beaconing every five minutes to update-cdn.example.net Privilege / lateral movement LSASS credential dumping, svc_backup reuse, PsExec to FS02, rogue admin account Anti-forensics Event 1102, audit log cleared
Isolate WS-0142 and FS02
Block update-cdn.example.net and 192.0.2.140
Exam tip
Learn a handful of Windows Security event IDs; they make log PBQs far easier: 4624 (successful logon), 4625 (failed logon), 4672 (special privileges assigned), 4720 (account created), 4732 (added to a security-enabled local group), 1102 (audit log cleared), and System event 7045 (service installed).
Memory aid
Read SIEM timelines as a story: delivery, execution, persistence, C2, credential access, lateral movement, collection, exfiltration, cover-up. This roughly follows the Cyber Kill Chain and MITRE ATT&CK tactics (Chapter 26).
PBQ 9: Select Access Control Models and IAM Solutions
Domains covered: 4.5 (access control models, SSO, federation, account types, MFA) and 3.2 (identity management). See Chapters 11 and 18.
Scenario
A regional healthcare network is consolidating identity management. The IAM team has documented nine requirements and needs to assign the best access control model or identity solution to each. Exhibit: Requirements
Item Requirement
1 Nurses, physicians, and billing clerks receive permissions based on their job function; when someone transfers departments, their permissions change automatically with their new position 2 A research file share lets each principal investigator decide which colleagues may read or modify the files they create
3 A defense-contract subsidiary labels documents Confidential, Secret, and Top Secret; users receive clearances, and the system, not the file owner, decides access
Item Requirement
4 Contractors may access the scheduling system only Monday through Friday, 7 a.m. to 6 p.m. 5 Administrators receive domain admin rights only after a ticketed request is approved, and the rights expire automatically after two hours
6 The perimeter firewall permits or denies traffic based on a configured list of conditions that apply to everyone equally
7 Staff should sign in once and access the EHR, a SaaS HR platform, and a SaaS learning platform without re-entering credentials
8 A third-party scheduling app needs to read users' calendars through an API without ever receiving their passwords
9 A Windows service that runs on several servers needs a domain identity whose password is rotated automatically and is never known to an administrator
Task
Match each requirement to one of: role-based access control (RBAC), discretionary access control (DAC), mandatory access control (MAC), rule-based access control, time-based access control, just-in-time (JIT) access, SAML-based SSO/federation, OAuth, group managed service account (gMSA).
Walkthrough
Item 1 ties permissions to job functions, and permissions follow the person's position. That is RBAC. Administrators manage a manageable number of roles rather than thousands of individual permission sets, and transfers become a role change rather than a manual permission cleanup, which also reduces privilege creep.
Item 2 lets the owner of each file decide who has access. Owner discretion is the defining trait of DAC, the model used by default in Windows NTFS and Unix file permissions. It is flexible but relies on users making good decisions.
Item 3 uses labels and clearances, and the system enforces access regardless of what the owner wants. That is MAC. SELinux in enforcing mode and military classification systems are classic examples. Item 4 restricts access to specific days and hours. That is time-based access control (sometimes listed as time-of-day restrictions).
Item 5 grants elevated rights only when needed, after approval, for a limited time. That is just-in-time access, typically delivered by a privileged access management (PAM) solution. It eliminates standing administrative privileges that attackers could steal.
Item 6 applies global rules (such as firewall ACLs) to all subjects equally, independent of identity or role. That is rule-based access control. Do not confuse the two "RBACs": role-based depends on who you are; rule-based depends on conditions defined by an administrator.
Item 7 requires single sign-on across an internal application and SaaS platforms. SAML federation is the standard choice for browser-based enterprise SSO: the identity provider authenticates the user and sends signed assertions to each service provider. (OpenID Connect, built on OAuth 2.0, is a modern alternative if offered.)
Item 8 is delegated authorization: a third-party app acts on the user's behalf with limited scope and never sees the password. That is OAuth, which issues access tokens with specific scopes (for example, read-only calendar access).
Item 9 describes a gMSA. Active Directory manages and rotates the password automatically, it can be used by multiple servers, and no human knows it. This addresses the "stale credentials" and hardcoded password problems common with traditional service accounts.
Memory aid
DAC = the Data owner Decides. MAC = Military-style labels, Mandatory for everyone. Role-based = job Role. Rule-based = ACL Rules. OAuth = authorization (delegation); SAML = authentication assertions for
Sso.
Exam tip
LDAP is a directory access protocol, not an SSO protocol in itself. If a question asks how applications query the directory for user and group information, think LDAP (TCP 389, or LDAPS on 636). If it asks how users sign in once across many web applications, think SAML or OpenID Connect.
PBQ 10: Risk Calculation and Treatment
Domains covered: 5.2 (risk analysis, SLE, ALE, ARO, treatment, risk register, residual risk). See Chapter
Scenario
You are preparing the quarterly risk register update for a logistics company. The risk committee wants quantitative figures for four risks, a recommendation for each, and justification for any control spending. The company's stated risk appetite is to mitigate any risk where a control costs less than the annual loss it prevents, and to avoid risks that provide no business value.
Exhibit: Risk data
Risk Asset value (AV)
Exposure factor (EF)
Annualize
d rate of occurrenc
e (ARO)
Proposed control and annual cost
Effect of control
R1: Ransomware on file servers
$500,000 60% 0.5 EDR plus immutable backups, $60,000
EF drops to 10%
R2: Laptop theft $2,500 per laptop
100% 12 Cable locks and tracking, $3,000
ARO drops to
- R3: Flood at warehouse data
- room
- $2,000,00
40% 0.05 Flood insurance policy, $50,000
Insurer pays the full loss
R4: Legacy anonymous FTP server no longer used by any
business process
$40,000 50% 0.4 Decommission, one-time $1,000
Risk removed
Task
- 1. Calculate the single loss expectancy (SLE) and annualized loss expectancy (ALE) for each risk before controls.
- 2. Calculate the ALE after the proposed control for R1 and R2, and determine whether each control is cost-justified.
- 3. Recommend a risk treatment (mitigate, transfer, accept, or avoid) for each risk.
Walkthrough
Step 1: Recall the formulas.
- SLE = AV x EF (the expected loss from one occurrence)
- ALE = SLE x ARO (the expected loss per year)
- Value of a control = ALE before - ALE after - annual cost of the control. If the result is positive, the control is cost-justified.
Step 2: Calculate baseline figures.
- Risk SLE (AV x EF) ALE (SLE x ARO)
- R1 $500,000 x 0.60 = $300,000 $300,000 x 0.5 = $150,000
- R2 $2,500 x 1.00 = $2,500 $2,500 x 12 = $30,000
- R3 $2,000,000 x 0.40 = $800,000 $800,000 x 0.05 = $40,000
- R4 $40,000 x 0.50 = $20,000 $20,000 x 0.4 = $8,000
An ARO of 0.5 means the event is expected once every two years; 0.05 means once every twenty years; 12 means once a month.
Step 3: Evaluate R1. After the control, EF is 10%, so SLE = $500,000 x 0.10 = $50,000 and ALE = $50,000 x 0.5 = $25,000. The control reduces annual loss by $150,000 - $25,000 = $125,000 and costs $60,000, for a net value of $65,000 per year. Mitigate. Residual risk is the remaining $25,000 ALE, which the committee should formally accept and record in the register.
Step 4: Evaluate R2. After the control, ARO is 6, so ALE = $2,500 x 6 = $15,000. The reduction is $30,000 - $15,000 = $15,000 against a cost of $3,000, a net value of $12,000. Mitigate. Note that this calculation covers hardware only. If laptops hold sensitive data, full-disk encryption reduces the far larger cost of a breach notification, which is why encryption is mandatory regardless of the hardware math. Step 5: Evaluate R3. Insurance shifts the financial loss to the insurer, which is transfer. But the policy costs $50,000 per year to cover an ALE of $40,000, so on pure numbers it costs more than it saves. Under the stated appetite, the better recommendation is to accept the risk (or look for a cheaper mitigation, such as relocating equipment above the flood line). Many organizations still buy insurance for low-likelihood, high-impact events because a single $800,000 loss could be unaffordable in a given year; that is a business judgment the committee would record. For the exam, recognize that insurance is transfer and that a control costing more than the ALE is not cost-justified.
Step 6: Evaluate R4. The FTP server supports no business process, so the right choice is to eliminate the activity that creates the risk: avoid by decommissioning it. That also reduces the attack surface. Follow the asset disposal process (Chapter 15) and remove its DNS records and firewall rules. Solution:
- Risk SLE ALE before ALE after Control value Treatment
- R1 $300,000 $150,000 $25,000 +$65,000 Mitigate
- R2 $2,500 $30,000 $15,000 +$12,000 Mitigate
- Risk SLE ALE before ALE after Control value Treatment
R3 $800,000 $40,000 n/a -$10,000 if insured Accept (transfer not cost-justified)
R4 $20,000 $8,000 $0 Avoids $8,000 per year Avoid
Common trap
Watch units. If a question gives ARO as "once every four years," convert it to 0.25 before multiplying. If EF is given as a percentage, convert it to a decimal. Most wrong answers on risk-math PBQs come from unit errors, not formula errors.
Note
A risk register entry typically records the risk description, owner, likelihood, impact, score or ALE, current mitigations, the chosen treatment, residual risk, and the review date. If a PBQ asks you to complete a register row, every one of those fields may appear.
PBQ 11: Fix Email Authentication Records
Domains covered: 4.1 (email security: SPF, DKIM, DMARC, BIMI) and 2.5 (phishing, impersonation). See Chapters 8 and 14.
Scenario
Attackers have been spoofing the From address of example.com in invoice-fraud emails sent to customers. At the same time, legitimate newsletters sent through the company's marketing platform are landing in recipients' spam folders. You have been asked to review the domain's DNS records and a message header.
Exhibit 1: Current DNS TXT records
example.com. TXT "v=spf1 ip4:203.0.113.25 include:_spf.mailhost.example +all"
example.com. TXT "v=spf1 include:spf.marketing.example ~all"
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB..."
example.com. TXT "v=DMARC1; p=none"
Exhibit 2: Header from a legitimate marketing newsletter
From: Example News <news@example.com>
Return-Path: <bounce@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mk2; ...
- Authentication-Results: mx.recipient.example;
- spf=permerror (multiple SPF records) smtp.mailfrom=example.com;
- dkim=fail (no key for signature) header.d=example.com header.s=mk2;
- dmarc=fail (p=none) header.from=example.com
- Task
Identify every problem in the records and select the corrected configuration. The organization's goals are to authorize its two legitimate sending services, enable DKIM for the marketing platform, receive aggregate DMARC reports at dmarc-reports@example.com, and ultimately have receivers reject spoofed mail.
Walkthrough
Problem 1: SPF ends in `+all`. The all mechanism at the end of an SPF record says what to do with senders that did not match. +all means "pass everyone," which authorizes every server on the internet to send as example.com and explains why the spoofed invoices pass SPF. Use -all (hard fail) or, during a transition, ~all (soft fail).
Problem 2: Two SPF records. A domain must publish exactly one SPF record. Two records cause a permerror, as the header shows, and receivers treat SPF as failed. Merge all authorized senders into a single record. (Also keep the total number of DNS lookups from include and similar mechanisms at ten or fewer, which is an SPF limit.)
Problem 3: DKIM selector mismatch. The newsletter is signed with selector s=mk2, so receivers look for the public key at mk2._domainkey.example.com. Only s1 is published. Publish the marketing platform's public key as a TXT record at mk2._domainkey.example.com. The private key stays with the platform; only the public key goes in DNS.
Problem 4: DMARC record in the wrong place and too permissive. DMARC policies must be published at _dmarc.example.com, not at the domain apex, so receivers currently find no DMARC policy at all. The record also lacks a reporting address. p=none is appropriate for an initial monitoring period, but the stated goal is rejection. The safe path is: publish with p=none and rua= reports, review the reports until all legitimate sources pass, then move to p=quarantine and finally p=reject.
Corrected records:
example.com. TXT "v=spf1 ip4:203.0.113.25 include:_spf.mailhost.example include:spf.marketing.example -all"
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB..."
mk2._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=<marketing platform public key>"
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
(The SPF record is shown on two lines for readability; it is a single TXT record. In practice, deploy DMARC at p=none first and step up to p=reject after reviewing reports.)
Why this fixes both problems. Spoofed invoices from unauthorized servers now fail SPF (-all) and carry no valid example.com DKIM signature, so they fail DMARC alignment, and the p=reject policy tells receivers to refuse them. Legitimate newsletters now pass SPF (single valid record including the marketing platform) and DKIM (key published for mk2), and both identifiers align with the From domain, so DMARC passes.
Memory aid
SPF = which servers may send for the domain. DKIM = a signature proving the message was not altered and came from the domain's key. DMARC = the policy (none, quarantine, reject) and reporting that ties SPF and DKIM to the visible From address. BIMI = displays a verified brand logo, and requires DMARC enforcement (quarantine or reject) first.
Exam tip
If a PBQ asks you to add BIMI, the record lives at default._bimi.example.com and points to an SVG logo (and often a Verified Mark Certificate). It does nothing without a DMARC policy of quarantine or reject.
PBQ 12: Data Classification and Handling
Domains covered: 3.3 (data types, classifications, protection methods, roles, handling, life cycle) and 5.4 (privacy). See Chapters 12 and 25.
Scenario
An online retailer is implementing a data governance program. Its classification policy defines three levels: Public (approved for release), Confidential (internal business data whose disclosure would cause moderate harm), and Restricted (regulated or highly sensitive data whose disclosure would cause severe harm or legal penalties). You must classify data sets, choose a protection method, and assign data roles.
Exhibit 1: Data sets
- Item Data set
- A Published product catalog and press releases
- B Customer payment card numbers used for recurring billing
- Item Data set
- C User account passwords for the customer website
- D Employee salary spreadsheet maintained by HR
E Customer support transcripts copied to a test environment for developers F Call-center agent screen that must show enough of a card number to verify the customer G Purchase history shared with a university research partner for trend analysis H Proprietary pricing algorithm source code
Exhibit 2: Protection methods
Tokenization; salted hashing; masking; deidentification (anonymization); encryption with access controls; no special protection required.
Exhibit 3: Role statements
Item Statement
R1 The VP of Sales is accountable for customer data and approves its classification and who may access it R2 The database administration team implements backups, encryption, and access controls as directed R3 A data quality analyst ensures customer records are accurate and that the data dictionary is maintained R4 The retailer decides why and how EU customers' personal data is processed R5 A cloud payroll provider processes employee data on the retailer's behalf R6 The payroll provider's hosting company stores that data under contract with the payroll provider Task
Classify items A through H and choose the best protection method for each. Then match R1 through R6 to: data owner, data custodian, data steward, data controller, data processor, subprocessor.
Walkthrough
Step 1: Classify by harm. Ask "What happens if this leaks?" Product catalogs and press releases are meant to be public (A). Payment card numbers (B), passwords (C), and customer data in support transcripts, agent screens, and purchase histories (E, F, G) are regulated or highly sensitive, so they are Restricted. Salaries (D) and proprietary source code (H) are internal and damaging if leaked; salaries are personal data, and many organizations would treat them as Restricted, but under this three-level policy Confidential is the most defensible choice unless the policy names HR data explicitly. Source code is intellectual property; Confidential.
Step 2: Match the protection method to the use case.
- A. Public data needs integrity protection (only authorized people can change the website) but no confidentiality controls. No special protection required for confidentiality.
- B. Recurring billing needs to charge the same card repeatedly without the retailer's systems holding real card numbers. Tokenization replaces the card number with a token that has no mathematical relationship to it; the real number lives only in the payment processor's secure vault. This greatly reduces PCI DSS scope.
- C. The website never needs to recover a password, only verify it. Salted hashing with a slow algorithm designed for passwords (such as bcrypt, scrypt, Argon2, or PBKDF2) is correct. Encryption is wrong because encrypted passwords can be decrypted if the key is stolen.
- D. HR needs to read and update the real values. Encryption with access controls (restricting the file to HR and encrypting it at rest).
- E. Developers need realistic text but not real identities. Deidentification (removing or replacing names, addresses, and other identifiers) or data masking for test environments. Deidentification is the best fit for wholesale copies.
- F. The agent needs to see part of the value. Masking displays only the last four digits (for example, XXXX-XXXX-XXXX-4417) while hiding the rest.
- G. The researchers need trends, not identities. Deidentification (anonymization), possibly combined with aggregation, so records cannot be tied back to individuals.
- H. Developers must read and modify the code. Encryption with access controls, along with repository permissions and secrets scanning.
Step 3: Assign roles. The owner is accountable and decides classification (R1). The custodian implements the technical protections (R2). The steward manages data quality and metadata (R3). Under privacy law, the controller determines the purposes and means of processing (R4), the processor processes on the controller's behalf (R5), and a subprocessor is engaged by the processor (R6).
Exam tip
Distinguish the "hide the data" methods by whether the original must be recoverable. Hashing: never recoverable, used to verify. Tokenization: recoverable only through the token vault. Encryption: recoverable with the key. Masking: hides part of the value from viewers. Deidentification: removes the link to the person.
Real-world scenario
A retailer copied its production customer database to a developer test server to reproduce a bug. The test server had weak access controls and was exposed to the internet, and the "test data" turned out to include real names, addresses, and order histories. Because the data was real, the incident was reportable under privacy law. Masking or deidentifying data before it leaves production would have made the exposure a non-event.
Workshop Wrap-Up
Every PBQ in this workshop tested ideas you already met in the chapters. What made them harder was the need to read exhibits carefully, combine several concepts, and commit to a complete answer. Before exam day:
- Re-work each PBQ from memory without looking at the walkthrough.
- Practice the classic sequences until they are automatic: firewall rule order (specific allows and block lists first, deny-all last), incident response phases, order of volatility, and the SLE/ALE formulas.
- Memorize the indicators that identify common attacks in logs: ../ for traversal, ' OR '1'='1 for SQL injection, many accounts with one attempt each for spraying, regular-interval callbacks for beaconing, and Office applications spawning shells for macro malware.
- Remember the time strategy: flag long PBQs, answer the multiple-choice questions, and return with the time you have left. Never leave a PBQ blank.