Study guide
Secure Design Review Scenarios
CompTIA Security+ SY0-701
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook
2 Domain 1: General Security Concepts (12%)
CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact
3 Domain 1: Identity, Trust, and Cryptography Basics
AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules
4 Domain 2: Threat Actors, Vectors, and Social Engineering
Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios
5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks
Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping
6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities
Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions
7 Domain 3: Security Architecture - Secure Architecture Models
Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios
8 Domain 3: Security Architecture - Network Security Architecture
Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design
9 Domain 3 Part C: Data Protection and Resilience
Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience
10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT
Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security
11 IAM Operations and Access Control
Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring
12 Logging, Monitoring, and Detection
Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling
13 Incident Response
IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics
14 Digital Forensics and Investigation
Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps
15 Vulnerability, Patch, Asset, and Automation Operations
Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling
16 Governance, Policies, and Risk Management
Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting
17 Third-Party Risk, Compliance, and Privacy
Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences
18 Audits, Penetration Testing, and Awareness
Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls
19 Final Review and PBQ Labs
PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation
Secure Design Review Scenarios
Key Takeaways Explain This Topic AI
A secure design review identifies assets, data flows, trust boundaries, assumptions, control gaps, and residual risk before deployment.
Threat modeling with STRIDE structures reasoning about spoofing, tampering, repudiation, disclosure, denial of service, and elevation of privilege.
Reviews must produce specific changes such as narrowed ACLs, stronger identity, logging, encryption, or segmentation.
The best exam answer addresses the most direct risk with the least disruptive yet effective control.
Secure architecture is iterative: validate assumptions, test controls, document exceptions, and keep monitoring after release.
Last updated: June 2026
What a Design Review Decides
A secure design review asks whether a proposed system can meet its security requirements before it goes live. For SY0-701 the skill being tested is judgment: find the highest-risk gap and pick the control that fits the scenario with the least disruption. The exam rewards specific, actionable, risk-mapped answers and punishes vague ones like "be more secure."
Review Inputs
- Input Why it matters
- Data-flow diagram Shows where data moves and where trust changes
- Asset inventory Identifies what must be protected
- Data classification Determines the required handling controls
- Identity model Shows users, admins, service accounts, federation
- Network design Shows segmentation, exposure, and allowed paths
- Logging plan Shows whether events can later be investigated
- Resilience plan Shows backup, failover, and recovery expectations
- STRIDE Threat Modeling
STRIDE is the threat-modeling mnemonic CompTIA leans on. Each letter maps a threat category to a control class.
- STRIDE item Question to ask Example control
- Spoofing Can someone impersonate an identity? MFA, certificates, strong service identity
- Tampering Can data or code be altered? Integrity checks, code signing, access control
- Repudiation Can an action be denied later? Logging, time sync, non-repudiation signatures
- Information disclosure Can sensitive data leak? Encryption, DLP, least privilege
- Denial of service Can availability be disrupted? Rate limiting, redundancy, DDoS protection
- Elevation of privilege Can a user gain more access? Least privilege, patching, PAM
- Scenario 1: Partner API
An insurance company exposes a claims API to a partner. The partner must submit claims but must not read all customer records.
- Finding Better design
- Single shared API key for all partner users Per-partner identity, scoped tokens, rotation
- API can read and write every claim Restrict scopes plus object-level authorization
- No rate limiting Add rate limits and anomaly alerts
- Logs omit partner identity Log subject, action, object, source, and result
- Unvalidated payloads accepted Validate the schema and reject unexpected fields
Best exam answer: scoped authorization with a strong partner identity, never one shared secret carrying broad access.
Scenario 2: New Admin Portal
A team proposes an internet-reachable admin portal for remote production support.
Require SSO and phishing-resistant MFA (FIDO2/WebAuthn) where supported.
Gate access by device posture and session risk.
Front the portal with ZTNA or VPN rather than raw internet exposure.
Use PAM for high-risk actions and separate approval for destructive operations.
Record admin sessions and sensitive changes.
Trap: "Use HTTPS" is necessary but incomplete. TLS protects data in transit; it does not prove the user is authorized to administer production.
Scenario 3: Production Data Copy for Analytics
A product team wants a copy of production customer data in a development environment.
- Requirement Control
- Developers need trends, not identities Mask, tokenize, or anonymize direct identifiers
- Data is copied between environments Encrypt transfer and restrict the destination
- Dev has weaker controls Do not place regulated raw data there
- Query activity must be auditable Enable logging and review privileged access
- Retention must be limited Set expiration and a deletion process
Best exam answer: minimize and de-identify the data. Do not simply grant developers production database access.
PBQ-Style Walkthrough
Review a diagram and choose the three most important fixes. Facts:
A public web app accepts payments.
The database with cardholder data is reachable from both the web subnet and the workstation subnet.
Admins share one local administrator account.
Logs stay only on each server.
Backups exist but have never been restored.
Priority fixes:
Restrict database access to only the required application source.
Replace the shared admin account with named privileged accounts, MFA, and session logging.
Centralize logs and test backup restoration.
Why not "change the logo" or "buy faster servers"? Neither touches confidentiality, integrity, accountability, or recoverability.
Anatomy of a Useful Finding
A strong review output is concrete:
Risk: the database accepts connections from the workstation subnet.
Impact: customer data could be queried after any workstation is compromised.
Recommendation: deny the workstation subnet, allow only the app security group on the database port, and alert on denied attempts.
Owner: infrastructure team.
Due date: before production release.
Residual risk: an app-tier compromise could still reach the database, so harden and monitor the app tier.
On the exam, always favor answers that are actionable, mapped to a named risk, and aligned with least privilege.
Secure-by-Design Through the Lifecycle
A design review is one checkpoint in a longer discipline SY0-701 calls secure by design : security requirements are defined before code is written, validated at design, tested before release, and monitored afterward. Map the recurring review themes to lifecycle stages:
Requirements: classify data and set the controls each classification demands so nothing is retrofitted later.
Design: run STRIDE threat modeling, draw the data-flow diagram, and confirm secure defaults and least privilege.
Build and test: scan IaC templates and container images, validate input handling, and verify that logging is actually emitted.
Deploy: enforce change control and separation of duties so no single person ships an unreviewed production change.
Operate: monitor, re-review after major changes, and track every accepted exception with an owner and expiry date.
Two trade-offs appear repeatedly in scenarios. First, risk versus cost : the cheapest control that effectively reduces the dominant risk usually wins, so do not over-engineer a low-impact path. Second, residual risk acceptance : after controls are applied, some risk remains, and a mature review documents who formally accepts it rather than pretending it is gone. The strongest exam answers reduce the most direct risk, stay proportional to the threat, and leave a clear, owned record of what was decided.