Secure Design Review Scenarios
Key Takeaways
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.
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.
A design review finds that developers want raw production customer data in a test environment. Which recommendation is best?
Provide masked or anonymized data that supports testing without exposing direct identifiers
Give every developer read-only access to production
Disable test-environment logging to protect privacy
Copy the data to personal laptops for faster analysis
Which findings from a secure design review should be prioritized? Choose two.
Select all that apply
A database holding regulated data accepts connections from all workstation subnets
A public marketing page uses a slightly outdated image
Administrators share one privileged account
A dashboard has a cosmetic spacing issue
Which review output is the most useful to an engineering team?
Security should be better across the board
The application is risky because applications are risky
Deny database access from workstation subnets and allow only the application security group on the required database port
Users should generally be more careful
Sections you finish are checked off in the contents.