The CompTIA Security+ SY0-701 exam is a widely recognized certification that validates your foundational cybersecurity skills. One of the most challenging aspects of this exam is the Performance-Based Questions (PBQs). These questions simulate real-world tasks and require you to demonstrate your ability to apply security principles in dynamic environments.
In this comprehensive guide, we'll break down three of the most common types of Security+ PBQs with detailed examples, scenarios, and step-by-step walkthroughs: firewall configuration, Wi-Fi security setup, and log analysis. By understanding the logic behind each PBQ and how they reflect real-world scenarios, you'll be better prepared to pass the exam and apply these skills in a job role.
🔥 Firewall Rule PBQs
Firewall Rule PBQs test your ability to configure access control policies that align with business and security requirements. These questions simulate real-world scenarios, such as securing a public web server, protecting internal resources, or blocking malicious traffic. Understanding how firewalls process rules and applying the principle of least privilege are critical to success.
Core Firewall Principles
-
Allow HTTPS Traffic: Permit
HTTPStraffic (port 443) from external networks to a web server located in a DMZ (Demilitarized Zone). This ensures secure communication between users and the web server while isolating it from internal systems. -
Block Insecure Services: Deny traffic for insecure protocols
like
FTP(port 21) andTelnet(port 23) from untrusted zones. These protocols transmit data in plaintext, making them vulnerable to interception and attacks. - Restrict IP Ranges: Use specific IP ranges instead of "any" to minimize the attack surface. For example, allow access only from trusted corporate IPs or specific geographic regions.
- Deny by Default: Implement a "deny all" rule at the bottom of the rule set to block any traffic that does not explicitly match an allow rule. This ensures that only authorized traffic is permitted.
- Enable Stateful Inspection: Configure the firewall to track the state of active connections. This allows return traffic for legitimate sessions while blocking unsolicited packets.
🔎 Critical Tip: Firewalls process rules in a top-down order. Place specific allow or deny rules before general ones to ensure they are applied correctly. The first matching rule is applied, and processing stops.
📝 Example Scenario 1: Public Web Server in DMZ
Scenario: You are tasked with securing a public-facing web server (192.168.100.10) in the DMZ. The server must accept HTTPS connections from the internet, allow HTTP to HTTPS redirects, enable internal administrators to SSH from the corporate network (10.10.0.0/24), and the web server needs to query an internal database server (192.168.1.50) on port 3306. All other traffic should be blocked.
| Rule # | Source | Destination | Protocol/Port | Action | Purpose |
|---|---|---|---|---|---|
| 1 | Any | 192.168.100.10 | TCP/443 | Allow | Public HTTPS access |
| 2 | Any | 192.168.100.10 | TCP/80 | Allow | HTTP redirect |
| 3 | 10.10.0.0/24 | 192.168.100.10 | TCP/22 | Allow | Admin SSH |
| 4 | 192.168.100.10 | 192.168.1.50 | TCP/3306 | Allow | Database queries |
| 5 | Any | 192.168.100.10 | TCP/21 | Deny | Block insecure FTP |
| 6 | Any | 192.168.100.10 | TCP/23 | Deny | Block insecure Telnet |
| 7 | Any | Any | Any | Deny | Default deny all |
📝 Example Scenario 2: Database Server Protection
Scenario: Configure firewall rules to protect an internal database server (192.168.20.50) that should only accept connections from application servers in the 192.168.10.0/24 subnet on port 3306 (MySQL). Database administrators from 10.10.5.0/24 need SSH access. All other traffic should be blocked, including direct internet access.
| Rule # | Source | Destination | Protocol/Port | Action | Purpose |
|---|---|---|---|---|---|
| 1 | 192.168.10.0/24 | 192.168.20.50 | TCP/3306 | Allow | App server access |
| 2 | 10.10.5.0/24 | 192.168.20.50 | TCP/22 | Allow | DBA management |
| 3 | Any | 192.168.20.50 | Any | Deny | Block all other traffic |
🎯 Common PBQ Mistakes to Avoid
- Rule Order Errors: Placing a "deny all" rule before specific allow rules will block all traffic. Always put specific rules first, general rules last.
- Using "Any" Too Broadly: Avoid using "Any" for source IPs when you can specify trusted networks. This reduces your attack surface significantly.
- Forgetting Return Traffic: In some firewalls, you may need explicit rules for return traffic. Stateful firewalls handle this automatically, but understand which type you're configuring.
- Allowing Insecure Protocols: Never allow FTP (21), Telnet (23), or HTTP (80) to sensitive systems. Always prefer secure alternatives (SFTP, SSH, HTTPS).
- Not Considering Internal Threats: Don't only focus on external traffic. Internal zone-to-zone rules are equally important for defense in depth.
- Confusing TCP vs UDP: Make sure you know which protocols use TCP vs UDP (DNS uses UDP/53, HTTPS uses TCP/443, etc.)
💡 Pro Exam Tips for Firewall PBQs:
- Read the entire scenario carefully - identify which zones are involved (Internet, DMZ, Internal, Management)
- Look for keywords like "only," "except," and "must not" that define restrictions
- Check if stateful inspection is enabled - it affects how you handle return traffic
- Verify your rules don't conflict - a later deny rule can't override an earlier allow
- Use the principle of least privilege - only allow what's explicitly needed
- Draw a simple network diagram if one isn't provided - visualize the traffic flows
- Remember: First match wins! Once a rule matches, processing stops
For more details on firewall configurations, refer to the Cloudflare Firewall Rule Guide and NIST SP 800-41 Rev. 1 .
📶 Wi-Fi Security PBQs
Wi-Fi Security PBQs assess your ability to configure secure wireless networks in enterprise environments. These questions often simulate real-world scenarios where you must choose the most secure SSID configurations, authentication protocols, and encryption standards. Understanding the differences between authentication methods and knowing when to use each is crucial.
Core Wi-Fi Security Principles
- Always Choose Enterprise Over Personal: Select WPA3-Enterprise or WPA2-Enterprise over WPA2-Personal for corporate environments. Enterprise mode provides individual authentication, enhanced encryption, and better security against brute-force attacks. Learn more about Wi-Fi Alliance security standards.
- Disable WPS: Wi-Fi Protected Setup (WPS) is vulnerable to brute-force PIN attacks that can be completed in hours. Always disable WPS in enterprise and high-security environments.
- Hide SSID Broadcasting (When Appropriate): Disabling SSID broadcast provides minimal security through obscurity but can be used as one layer in a defense-in-depth strategy. However, this is not a substitute for strong authentication.
- Implement 802.1X Authentication: Use 802.1X authentication with RADIUS for centralized authentication. This provides per-user credentials and detailed logging.
- Choose the Right EAP Method: EAP-TLS (certificate-based) is the most secure. EAP-TTLS and PEAP (password-based with server certificates) are acceptable alternatives. Avoid LEAP (deprecated and insecure).
- Segment Networks with VLANs: Separate corporate, guest, IoT, and BYOD traffic using VLANs. This prevents lateral movement and contains potential breaches.
📝 Example Scenario 1: Corporate Wi-Fi Configuration
Scenario: Configure a secure corporate Wi-Fi network for 500 employees. The network must use the strongest available security, support individual user authentication, integrate with Active Directory, and ensure encrypted credentials. Which settings should you configure?
Correct Configuration:
| SSID: | CorpWiFi |
| Security Mode: | WPA3-Enterprise (or WPA2-Enterprise if WPA3 unavailable) |
| Authentication: | 802.1X with RADIUS |
| EAP Type: | EAP-TLS (certificate-based) or PEAP-MSCHAPv2 (password-based) |
| Encryption: | AES (CCMP for WPA2, GCMP for WPA3) |
| SSID Broadcast: | Enabled (users need to find it easily) |
| WPS: | Disabled |
| VLAN: | VLAN 10 (Corporate) |
Why this works: WPA3/WPA2-Enterprise with 802.1X provides individual authentication against AD, EAP-TLS/PEAP ensures encrypted credentials, AES provides strong encryption, and disabling WPS removes a major vulnerability.
📝 Example Scenario 2: Guest Wi-Fi Network
Scenario: Configure a guest Wi-Fi network that provides internet access but isolates guest devices from the corporate network. Guests should be able to connect easily without IT support.
Correct Configuration:
| SSID: | Guest-WiFi |
| Security Mode: | WPA2-Personal or WPA3-Personal (with simple passphrase) |
| Authentication: | Pre-Shared Key (PSK) or Captive Portal |
| Encryption: | AES |
| Client Isolation: | Enabled (prevents guest-to-guest communication) |
| VLAN: | VLAN 99 (Guest - isolated from corporate network) |
| Firewall Rules: | Allow internet access only, block corporate network access |
| Bandwidth Limit: | Enabled (to prevent abuse) |
Why this works: Guest network is segregated via VLAN, client isolation prevents lateral movement, and firewall rules ensure guests can only access the internet.
📝 Example Scenario 3: IoT Device Network
Scenario: Your organization has 200 IoT devices (security cameras, environmental sensors, smart locks) that need Wi-Fi connectivity. These devices don't support 802.1X and pose a security risk. How do you configure secure connectivity?
Correct Configuration:
| SSID: | IoT-Devices (hidden SSID) |
| Security Mode: | WPA2-Personal (or WPA3-Personal if devices support it) |
| Authentication: | Pre-Shared Key (PSK) - complex, rotated quarterly |
| MAC Filtering: | Enabled (whitelist known device MACs) |
| VLAN: | VLAN 50 (IoT - isolated from corporate and guest) |
| Firewall Rules: | Allow only necessary ports (HTTPS/443 to cloud services, deny inbound) |
| IDS/IPS: | Enabled to monitor for anomalous behavior |
Why this works: IoT VLAN segregates vulnerable devices, MAC filtering adds a layer of protection (though not foolproof), firewall rules limit attack surface, and IDS/IPS monitors for compromised devices.
Understanding EAP Methods
| EAP Method | Authentication Type | Security Level | Use Case |
|---|---|---|---|
| EAP-TLS | Certificate (client + server) | Highest | Corporate (best choice) |
| PEAP-MSCHAPv2 | Password + server cert | High | Corporate (easier deployment) |
| EAP-TTLS | Password + server cert | High | Similar to PEAP |
| EAP-FAST | PAC + password | Medium | Legacy Cisco (avoid if possible) |
| LEAP | Password only | Low (deprecated) | Never use (vulnerable) |
💡 Pro Exam Tips for Wi-Fi PBQs:
- Enterprise vs Personal: If the scenario mentions "corporate," "employees," or "Active Directory," choose Enterprise mode
- Certificate vs Password: EAP-TLS (certificates) is always more secure than PEAP (passwords), but PEAP is easier to deploy
- Never choose WPS: Even if it seems convenient, WPS is always the wrong answer for security
- WPA3 vs WPA2: Choose WPA3 when available, but WPA2-Enterprise is still acceptable in many scenarios
- VLAN segregation: Always segment different types of traffic (corporate, guest, IoT)
- Client isolation: Enable for guest networks to prevent lateral movement
For a deeper dive into wireless security best practices, refer to the NIST Wireless Network Security Guide and Wi-Fi Alliance Security Standards .
🧾 Log Analysis PBQs
Log analysis PBQs simulate security monitoring and incident detection. You'll be given raw log files or system outputs and asked to identify malicious behavior, outline an incident timeline, determine the attack type, or recommend remediation actions. These questions test your ability to think like a security analyst and recognize patterns of compromise.
Core Log Analysis Skills
- Brute-Force Attack Detection: Look for repeated failed login attempts from the same IP address or targeting the same user account, especially within a short time window.
- Privilege Escalation: Identify unauthorized changes to user permissions, sudden access to admin accounts, or execution of privilege escalation commands.
- Lateral Movement: Spot unusual connections between internal systems, especially from user workstations to servers, or use of administrative tools from unexpected locations.
- Data Exfiltration: Watch for large outbound data transfers, connections to unusual external IPs, or access to sensitive files followed by network activity.
- Time-Based Anomalies: Notice activity during unusual hours (2-4 AM), especially from accounts that normally only work business hours.
- Source IP Analysis: Investigate connections from foreign countries (when not expected), TOR exit nodes, known malicious IPs, or impossible travel scenarios.
📝 Example Scenario 1: Brute-Force Attack
Scenario: You're reviewing authentication logs and need to identify a potential security incident. Analyze the following logs:
2025-05-01 14:23:12 | auth.log | user: admin | source: 192.168.1.100 | event: LOGIN_SUCCESS 2025-05-01 18:45:23 | auth.log | user: jsmith | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:45:28 | auth.log | user: jsmith | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:45:33 | auth.log | user: jsmith | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:45:41 | auth.log | user: admin | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:45:47 | auth.log | user: admin | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:45:52 | auth.log | user: admin | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:46:01 | auth.log | user: root | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:46:08 | auth.log | user: root | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:46:14 | auth.log | user: administrator | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:46:22 | auth.log | user: testuser | source: 203.0.113.45 | event: LOGIN_FAILED 2025-05-01 18:46:29 | auth.log | user: guest | source: 203.0.113.45 | event: LOGIN_FAILED
🚨 Analysis:
- Attack Type: Brute-force password attack / Credential stuffing
- Attacker IP: 203.0.113.45 (external source)
- Target Accounts: Multiple common usernames (jsmith, admin, root, administrator, guest)
- Timeline: 12 failed attempts in 6 minutes (18:45:23 to 18:46:29)
- Pattern: Systematic attempt to guess credentials for multiple accounts
- Recommended Actions:
- Block IP 203.0.113.45 at the firewall immediately
- Implement account lockout policies (5 failed attempts = 30 min lockout)
- Enable MFA for all accounts, especially admin/root
- Alert affected users to reset passwords
- Review if any attempts were successful (check for LOGIN_SUCCESS after this timeframe)
📝 Example Scenario 2: Privilege Escalation
Scenario: Analyze this system log to identify suspicious privilege escalation activity:
2025-05-01 02:15:34 | system.log | user: jdoe | action: LOGIN | source: 10.0.5.42 2025-05-01 02:16:12 | system.log | user: jdoe | action: FILE_ACCESS | file: /etc/passwd 2025-05-01 02:16:23 | system.log | user: jdoe | action: FILE_ACCESS | file: /etc/shadow 2025-05-01 02:17:45 | system.log | user: jdoe | action: COMMAND_EXEC | command: whoami 2025-05-01 02:18:01 | system.log | user: jdoe | action: COMMAND_EXEC | command: sudo -l 2025-05-01 02:19:34 | system.log | user: jdoe | action: COMMAND_EXEC | command: sudo su - 2025-05-01 02:19:41 | system.log | user: root | action: PRIVILEGE_CHANGE | old: user | new: admin 2025-05-01 02:20:15 | system.log | user: root | action: USER_ADD | newuser: backdoor 2025-05-01 02:20:28 | system.log | user: root | action: GROUP_ADD | user: backdoor | group: sudo 2025-05-01 02:21:03 | system.log | user: root | action: FILE_MODIFY | file: /etc/ssh/sshd_config 2025-05-01 02:21:45 | system.log | user: root | action: SERVICE_RESTART | service: sshd 2025-05-01 02:22:10 | system.log | user: jdoe | action: LOGOUT
🚨 Analysis:
- Attack Type: Privilege escalation with persistence mechanism
- Compromised Account: jdoe (standard user account)
- Attack Timeline: 7 minutes (02:15 to 02:22) - suggests automation or experienced attacker
- Suspicious Indicators:
- Access at 2:15 AM (unusual hour)
- Attempted to read /etc/shadow (password hashes)
- Enumerated sudo privileges with
sudo -l - Successfully escalated to root with
sudo su - - Created backdoor user "backdoor" with sudo privileges
- Modified SSH configuration (possibly to allow root login or password auth)
- Restarted SSH to apply changes
- Immediate Actions:
- Disable jdoe account immediately and force password reset
- Remove backdoor user account:
userdel -r backdoor - Restore /etc/ssh/sshd_config from backup or verify configuration
- Review all user accounts for other unauthorized additions
- Check for additional persistence mechanisms (cron jobs, startup scripts)
- Investigate how jdoe's account was compromised (phishing? weak password?)
- Review sudo configuration - why did jdoe have sudo privileges?
📝 Example Scenario 3: Data Exfiltration
Scenario: Review this firewall log to identify potential data exfiltration:
2025-05-01 15:34:22 | firewall.log | src: 192.168.10.55 | dst: 8.8.8.8 | port: 53 | proto: UDP | bytes: 124 | action: ALLOW 2025-05-01 15:35:10 | firewall.log | src: 192.168.10.55 | dst: 172.217.14.206 | port: 443 | proto: TCP | bytes: 2847 | action: ALLOW 2025-05-01 22:15:45 | firewall.log | src: 192.168.10.55 | dst: 45.142.212.61 | port: 443 | proto: TCP | bytes: 524288000 | action: ALLOW 2025-05-01 22:16:12 | firewall.log | src: 192.168.10.55 | dst: 45.142.212.61 | port: 443 | proto: TCP | bytes: 524288000 | action: ALLOW 2025-05-01 22:16:39 | firewall.log | src: 192.168.10.55 | dst: 45.142.212.61 | port: 443 | proto: TCP | bytes: 524288000 | action: ALLOW 2025-05-01 22:17:05 | firewall.log | src: 192.168.10.55 | dst: 45.142.212.61 | port: 443 | proto: TCP | bytes: 524288000 | action: ALLOW 2025-05-01 22:17:32 | firewall.log | src: 192.168.10.55 | dst: 45.142.212.61 | port: 443 | proto: TCP | bytes: 524288000 | action: ALLOW 2025-05-01 22:17:58 | firewall.log | src: 192.168.10.55 | dst: 45.142.212.61 | port: 443 | proto: TCP | bytes: 314572800 | action: ALLOW
🚨 Analysis:
- Attack Type: Data exfiltration via HTTPS
- Source System: 192.168.10.55 (internal workstation)
- Destination: 45.142.212.61 (suspicious external IP)
- Total Data Transferred: ~2.9 GB (2,935,260,800 bytes) in 2 minutes
- Suspicious Indicators:
- Transfer occurred at 22:15 (10:15 PM) - after business hours
- Massive volume of data in short time period
- Consistent 500MB chunks suggest automated transfer
- HTTPS used to encrypt and hide the content
- IP 45.142.212.61 may be in a high-risk geographic region
- Investigation Steps:
- Identify who was using 192.168.10.55 at 22:15 (check authentication logs)
- Run threat intelligence check on IP 45.142.212.61
- Review file access logs on 192.168.10.55 around 22:00-22:15
- Check if data loss prevention (DLP) alerts were triggered
- Examine the workstation for malware (RAT, info stealer)
- Block 45.142.212.61 at firewall if determined malicious
- Review other systems for similar patterns
Common Log Analysis Patterns
| Attack Type | Log Indicators | What to Look For |
|---|---|---|
| Brute Force | Multiple LOGIN_FAILED from same IP | 10+ failures in <5 minutes, various usernames |
| SQL Injection | Web logs with SQL syntax in URLs | UNION, SELECT, OR 1=1, DROP TABLE in parameters |
| XSS Attack | Web logs with script tags in parameters | <script>, javascript:, onerror= in inputs |
| Malware C2 | Regular beaconing to external IPs | Connections every X seconds/minutes to same IP |
| Port Scan | Connections to many sequential ports | Same source trying ports 1-1000 in rapid succession |
| Insider Threat | Access to unusual files, bulk downloads | Employee accessing HR/financial data outside role |
🔍 Pro Exam Tips for Log Analysis PBQs:
- Read timestamps carefully: Look for patterns, unusual hours, or rapid sequences
- Correlate events: Connect related log entries to build an attack timeline
- Focus on anomalies: After-hours access, foreign IPs, unusual commands
- Identify the 4 W's: Who (user/IP), What (action), When (timestamp), Where (source/destination)
- Look for persistence: New user accounts, modified configs, scheduled tasks
- Check for cleanup: Attackers often delete logs - look for gaps in timestamps
- Remember common ports: 22=SSH, 23=Telnet, 80=HTTP, 443=HTTPS, 3389=RDP, 3306=MySQL
Familiarize yourself with SIEM tools like Splunk, ELK stack, and review the CISA Incident Management Guide.
🔑 Key Takeaways
- PBQs test application, not memorization. Focus on understanding the logic behind security decisions and how to apply concepts to real scenarios.
- Firewall rules are order-dependent. Always place specific rules before general ones, and end with a "deny all" rule.
- Enterprise Wi-Fi requires Enterprise security. Use WPA3/WPA2-Enterprise with 802.1X and EAP-TLS for corporate environments. Never use WPS.
- Segment your networks. Use VLANs to separate corporate, guest, and IoT traffic to limit the blast radius of attacks.
- Log analysis is about pattern recognition. Look for anomalies in time, source, volume, and behavior to identify attacks.
- Think like an attacker. Understanding attack methodologies (MITRE ATT&CK) helps you identify them in logs.
- Practice with labs. Hands-on experience with firewalls, wireless controllers, and SIEM tools is invaluable.
- Study NIST guidelines for firewall and network access control best practices.