Study guide
Architecture Models and Trust Boundaries
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
Architecture Models and Trust Boundaries
Key Takeaways Explain This Topic AI
A secure architecture model describes where assets live, how data moves, and which control protects each trust boundary.
Trust boundaries mark places where identity, ownership, data sensitivity, or administrative control changes hands.
Domain 3 is the largest SY0-701 domain at 18 percent of scored content, so diagram-reasoning questions are heavily weighted.
Secure design rests on defense in depth, least privilege, secure defaults, fail-secure behavior, and separation of duties.
On the exam, place the control at the boundary where risk is introduced, not just anywhere that looks plausible on the diagram.
Last updated: June 2026
How Domain 3 Is Tested
The CompTIA Security+ SY0-701 exam delivers a maximum of 90 questions in 90 minutes and requires a scaled score of 750 on a 100-900 band to pass. Domain 3, Security Architecture, carries 18 percent of the scored weight, the single largest of the five domains. Many of its items are performance-based questions (PBQs) that drop you into a network diagram and ask you to reason about it. The goal is never to memorize one perfect topology. The goal is to identify assets, trace data flows, locate where trust changes, and place the right control at that point.
A secure architecture model is simply a description of where data lives, how it moves, who owns each segment, and which controls protect each transition. Strong models are built on a small set of repeating principles.
Core Architecture Principles
Principle Exam meaning Concrete example
Defense in depth Multiple independent layers so no single failure exposes the asset MFA, WAF, segmentation, EDR, and logging stacked together
Least privilege Access limited to the minimum needed to perform a task App server can query only its own database schema
Secure defaults The initial, out-of-box state is restrictive A new storage bucket is private and encrypted by default
Fail-secure A failure does not create open access An electronic door lock stays locked if the controller dies
Separation of duties Sensitive actions split across distinct roles A developer cannot both approve and deploy a production change
Resilience Service continues or recovers during disruption Redundant zones, tested backups, documented restore runbook
Note the contrast between fail-secure and fail-open : a fail-open firewall that passes all traffic when it crashes favors availability over confidentiality, which is usually the wrong answer for data protection but the right answer for life-safety egress doors.
Spotting Trust Boundaries
A trust boundary exists wherever traffic or data crosses from one security context into another. Memorize these recurring clues:
Internet to a public-facing service.
A user workstation reaching a privileged admin plane.
The web tier talking to the database tier.
The corporate network connecting to a vendor or partner network.
A cloud tenant invoking a provider-managed service.
Production crossing into a development or test environment.
A low-sensitivity store touching a regulated, classified store.
A human user versus an automated service account.
At every boundary, ask five questions in order: which control proves identity, which restricts authorization, which protects the data, which records the activity, and which limits blast radius if the layer is breached.
Boundary-to-Control Mapping
Boundary Primary risk Stronger controls
Internet to web app Exploitation, scanning, DDoS, credential stuffing CDN/DDoS scrubbing, WAF, TLS, rate limiting, secure headers
Web app to API Broken authorization, token abuse OAuth scopes, mTLS, schema validation, API gateway
App to database Data theft, SQL injection, excess privilege Parameterized queries, least-privilege DB account, encryption
User to admin console Account takeover, privilege misuse MFA, PAM, conditional access, jump host, session recording
On-prem to cloud Exposed services, weak identity Private connectivity, IAM federation, routing controls, logging
Worked PBQ Walkthrough
A company hosts a customer portal. Zones on the diagram: a public subnet (reverse proxy, web server), a private subnet (application server), a data subnet (database with regulated customer records), a corporate subnet (workstations), and a management subnet (admin jump host). Task: place controls to protect the regulated data.
Put the database in the data subnet with no public IP and no internet route.
Permit only the application server to reach the database on the exact required port (for example PostgreSQL TCP 5432) via a tight source security group.
Force the web server to reach only the app server, never the database directly.
Route administrators through the jump host with MFA, PAM approval, and session logging.
Forward security logs from web, app, database, and identity systems to centralized logging.
Encrypt data in transit (TLS) and at rest.
Common trap: selecting a WAF alone. A WAF helps at the internet edge but does nothing for least-privilege database access, segmentation, privileged access, or logging. When a question asks for the best architecture control, find the boundary first, then choose the control that directly reduces that boundary's risk, never a generic answer like awareness training.
Centralized Versus Decentralized Design
SY0-701 also contrasts architecture topologies, and each carries a trust-boundary trade-off you may be asked to weigh:
Centralized designs concentrate control and data in one place. They are easier to monitor and patch but create a high-value single point of failure and a single large blast radius.
Decentralized designs spread control and data across nodes. They are more resilient to a single failure but multiply the number of trust boundaries you must secure and monitor.
High availability (HA) clustering adds redundant nodes so a failure does not cause an outage; pair it with load balancing to distribute traffic and absorb volume.
Air-gapped segments have no network path to less-trusted zones at all, the strongest boundary but operationally costly.
A final exam habit: distinguish logical segmentation (VLANs, security groups, software policy) from physical segmentation (separate cabling and hardware). Both create boundaries, but physical separation is harder to bypass and is the right answer when a scenario demands that two zones never share an electronic path, such as operational technology isolated from corporate IT.