Domain 3 accounts for 18 percent of the SY0-701 exam. Its questions usually begin with a design choice: where a system runs, how traffic reaches it, what data it handles, or how the organization plans to continue after a failure.
Security architecture is built around tradeoffs. A control may improve isolation while adding latency. A highly available service may cost more and expose more components. A legacy industrial system may be essential to production even when it cannot accept ordinary patches. Read the requirement first, then judge the design.
Domain 3 map
The official objectives divide Security Architecture into four areas:
| Objective | Main focus | Questions to ask |
|---|---|---|
| 3.1 | Architecture models | Where does responsibility sit, what assumptions change, and which tradeoffs follow from the model? |
| 3.2 | Enterprise infrastructure | Where should controls be placed, which connections are allowed, and how should failure be handled? |
| 3.3 | Data protection | What data is being protected, where is it, and which method addresses the required security property? |
| 3.4 | Resilience and recovery | How much disruption and data loss can the business accept, and which design can meet those limits? |
Architecture questions become easier when you identify the asset, trust boundary, required outcome, and operating constraint. Those four details often eliminate answers that sound secure in the abstract but do not fit the environment.
Architecture models and their security implications
An architecture model changes who operates each layer, where controls can be placed, and which failures the organization must prepare to handle. Moving a workload does not remove responsibility. It redistributes it.
Cloud deployment and service models
Cloud deployment models describe who uses the environment and how it is made available:
| Model | Typical use | Security considerations |
|---|---|---|
| Public cloud | Services are offered from a provider's shared infrastructure to many customers. | Tenant isolation, provider dependency, identity configuration, exposed services, data location, and contractual controls. |
| Private cloud | Cloud capabilities are dedicated to one organization. | Greater control can bring greater operational responsibility, including staffing, patching, capacity, and recovery. |
| Hybrid cloud | Private or on-premises resources are connected with public cloud services. | Consistent identity, encryption, logging, data movement, network paths, and policy across environments. |
| Community cloud | Organizations with shared requirements use a common environment. | Governance, participant boundaries, shared standards, and agreement on responsibility. |
Cloud service models describe how much of the technology stack the provider operates:
| Service model | Provider typically manages | Customer still manages |
|---|---|---|
| IaaS | Facilities, physical hardware, core networking, storage, and the virtualization layer. | Guest operating systems, applications, identities, workload configuration, and data. |
| PaaS | Infrastructure plus the managed runtime, platform components, and much of the operating environment. | Application code, identities, secrets, data, and service configuration. |
| SaaS | The application and the underlying platform and infrastructure. | Accounts, roles, data handling, tenant settings, integrations, endpoints, and acceptable use. |
A responsibility matrix should identify which party owns each control and task. The provider may secure the physical host while the customer remains responsible for an overly broad administrator role or a public storage container. Outsourcing the service does not outsource the need to verify the agreement and configuration.
Hybrid environments and third-party services
Hybrid designs introduce boundaries between environments with different tools, administrators, logging formats, and failure modes. Review:
- Identity federation and account lifecycle across systems
- Encryption and key ownership as data moves
- Routing, filtering, and inspection between locations
- Centralized logging and time synchronization
- Backup and recovery responsibilities
- Provider outages and loss of network connectivity
- Contractual requirements for notification, retention, deletion, and audit evidence
A third party can transfer some operational work and some financial risk. Accountability for protecting the organization's mission and data remains with the organization. The exam may describe a provider control and ask which customer-side responsibility is still missing.
Infrastructure as code, serverless, microservices, and software-defined networking
Modern architecture often moves configuration into code and divides systems into smaller managed components.
- Infrastructure as code (IaC) defines infrastructure through versioned templates or scripts. It supports repeatable deployment and review. A mistake in the template can also spread quickly, so protect repositories, approve changes, scan templates, and detect configuration drift.
- Serverless computing runs functions or services without requiring the customer to administer the underlying servers. Secure the code, triggers, identities, secrets, dependencies, data flows, and service configuration.
- Microservices divide an application into smaller services that communicate through APIs or messaging. Each service identity, interface, dependency, and network path becomes part of the attack surface.
- Software-defined networking (SDN) separates centralized control decisions from traffic forwarding. Protect controllers, administrative interfaces, policy changes, and communication between the control and data planes.
Automation improves consistency when the source configuration is trustworthy. It also makes a bad setting remarkably efficient. Review and testing belong before broad deployment.
Centralized and decentralized architectures
Centralization can simplify policy, visibility, identity, and administration. It can also create a high-value target or single point of failure. Decentralization may improve local autonomy and reduce dependency on one component, while making consistent control and monitoring harder.
| Approach | Potential strengths | Potential concerns |
|---|---|---|
| Centralized | Consistent policy, consolidated logs, simpler administration, and clear control points. | Concentrated privilege, attractive targets, dependency on central services, and wider impact from failure. |
| Decentralized | Local resilience, autonomy, reduced dependency on one controller, and distribution of workload. | Policy drift, fragmented visibility, uneven patching, duplicated effort, and difficult coordination. |
The exam is unlikely to reward a blanket preference. Match the model to the stated requirement and account for its failure modes.
Virtualization and containers
A virtual machine includes a guest operating system and runs through a hypervisor. Containers commonly share the host operating system kernel while isolating applications and their dependencies.
| Technology | Isolation boundary | Security focus |
|---|---|---|
| Virtual machine | Guest operating system separated through a hypervisor. | Hypervisor security, guest patching, image control, management interfaces, virtual networking, and VM escape risk. |
| Container | Application processes isolated while commonly sharing the host kernel. | Trusted images, minimal privileges, runtime policy, secrets, orchestration security, registry protection, and host-kernel exposure. |
Snapshots and reusable images accelerate deployment. They can also preserve vulnerable software, embedded secrets, or insecure defaults. Build from approved images, scan them, sign or verify trusted artifacts, and remove unnecessary packages and privileges.
IoT, embedded, real-time, and operational technology
Specialized systems often prioritize safety, reliability, timing, power use, or long service life. Standard enterprise assumptions may not apply.
- Internet of Things (IoT) devices include connected sensors, cameras, appliances, controllers, and other purpose-built devices. Common concerns include default credentials, weak update mechanisms, exposed management services, and poor inventory visibility.
- Embedded systems perform dedicated functions inside larger products or equipment. They may have limited storage, processing power, and security features.
- Real-time operating systems (RTOS) must complete tasks within defined timing constraints. Security controls that introduce unpredictable delay may interfere with the required function.
- Operational technology (OT) monitors or changes physical processes. Industrial control systems and SCADA environments may include controllers, sensors, actuators, engineering workstations, and human-machine interfaces.
Safety and availability can dominate OT decisions. A restart that is routine on an office workstation may interrupt production or create a physical hazard on a control system. Use segmentation, tightly controlled remote access, asset inventory, passive monitoring where appropriate, tested maintenance windows, and compensating controls for systems that cannot be patched promptly.
Exam clue: When a specialized system cannot support the preferred control, choose a control that respects its operating limits while reducing exposure. Isolation and strict access may be more realistic than forcing an incompatible agent onto the device.
Architecture tradeoffs
Architecture questions often include one or more constraints. Translate each constraint into a design concern:
| Constraint | What to evaluate |
|---|---|
| Availability | Redundancy, failover, maintenance impact, dependencies, and recovery time. |
| Resilience | Ability to absorb failure, continue essential functions, and restore normal service. |
| Cost | Capital expense, operating expense, staffing, licensing, data transfer, and duplicated capacity. |
| Responsiveness | Latency, processing delay, geographic distance, and control overhead. |
| Scalability | Ability to add capacity without redesigning the entire service or weakening controls. |
| Ease of deployment | Automation, standard images, repeatable configuration, and change approval. |
| Risk transference | Which duties move to a provider or insurer, which remain internal, and whether the contract is adequate. |
| Ease of recovery | Backup compatibility, documented procedures, replacement resources, and tested restoration. |
| Patch availability | Vendor support, maintenance windows, validation, rollback, and compensating controls. |
| Power and compute | Device capacity, battery life, heat, timing, and the resource cost of security controls. |
Applying security principles to enterprise infrastructure
Secure infrastructure begins with placement and allowed communication. Put systems into zones based on trust, function, and data sensitivity. Then permit only the traffic required between those zones.
Security zones and device placement
Common zones include:
- Internet or untrusted zone: External networks with no assumed trust.
- Screened subnet or DMZ: Public-facing services separated from internal systems.
- Internal user zone: Workstations and ordinary business services.
- Server or application zone: Internal services with narrower access requirements.
- Management zone: Administrative interfaces and tools restricted to authorized administrators and management paths.
- Guest zone: Visitor or unmanaged-device access separated from business resources.
- Restricted data zone: Systems handling regulated, sensitive, or mission-critical data.
- OT zone: Industrial or physical-process systems isolated from ordinary enterprise traffic.
Segmentation limits routine reachability and reduces lateral movement. Isolation removes communication more completely. An air gap uses physical separation, although removable media, maintenance connections, and human processes can still move data across the boundary.
Infrastructure controls and their placement
| Control | Primary purpose | Typical placement or use |
|---|---|---|
| Firewall | Allows or blocks network traffic according to policy and connection context. | Between trust zones, at network boundaries, or on individual hosts. |
| Web application firewall | Inspects HTTP and HTTPS traffic for web-application attacks and policy violations. | In front of public or sensitive web applications. |
| IDS or IPS | Detects suspicious activity; an IPS can also block or disrupt matching traffic. | At important network boundaries or near critical assets, with visibility into relevant traffic. |
| Proxy | Mediates requests, applies policy, filters content, and can hide internal clients or servers. | Forward proxy for outbound client access; reverse proxy in front of services. |
| VPN gateway | Creates an encrypted tunnel for site-to-site or remote access. | At the network edge or cloud boundary, followed by authentication and authorization controls. |
| Load balancer | Distributes requests across service instances and can perform health checks. | In front of a server pool or application tier. |
| Jump server | Provides a controlled administrative path into restricted systems. | Between administrator access and management interfaces, with strong authentication and logging. |
| Network sensor | Collects traffic or telemetry for monitoring and analysis. | Where it can observe the desired segment, boundary, or mirrored traffic. |
Placement determines usefulness. A sensor cannot analyze traffic it never sees. A WAF protects web requests, while a network firewall handles broader traffic policy. A jump server narrows administrative entry, but it must be hardened because its access makes it valuable.
Firewall types and traffic decisions
- Packet filtering evaluates fields such as source, destination, protocol, and port.
- Stateful inspection tracks connection state and permits return traffic associated with an approved session.
- Next-generation firewalls can add application awareness, user context, intrusion prevention, threat intelligence, and deeper inspection.
- Web application firewalls focus on application-layer web traffic.
- Host-based firewalls enforce policy directly on an endpoint or server.
Select the control that sees the information needed for the decision. A port-based rule cannot distinguish two applications using the same encrypted channel. A WAF will not replace segmentation between database and management networks.
Connectivity, attack surface, and secure access
Every enabled service, administrative interface, wireless connection, remote-access path, and third-party link expands the attack surface. Reduce that surface through:
- Default-deny rules followed by explicit business allowances
- Separate management interfaces or management networks
- Strong authentication and least-privilege authorization
- Secure protocols such as SSH, TLS, and IPsec where appropriate
- Network access control and switch port controls
- Removal of unused services, routes, accounts, and interfaces
- Encryption for untrusted or shared networks
- Logging at boundaries and on high-value systems
Port security can limit which devices connect to a switch port. Network access control can evaluate identity or device posture before granting access. Neither control removes the need for segmentation and endpoint security after admission.
Failure modes
A security device can fail open or fail closed:
- Fail open preserves traffic flow when the control fails. Availability remains higher, while enforcement may be lost.
- Fail closed blocks traffic when the control fails. Security policy remains enforced, while availability may suffer.
The correct mode depends on the system. A payment service, emergency system, safety controller, and restricted management network may reach different decisions. Identify which outcome the scenario treats as less acceptable.
Example: a public three-tier application
A defensible design might place:
- A reverse proxy or WAF in front of the public web tier.
- Web servers in a screened subnet with no direct administrative access from the internet.
- Application servers in an internal application zone reachable only from the web tier on required ports.
- Database servers in a restricted data zone reachable only from the application tier.
- Administrative access through a jump server on a separate management path.
- Central logging, monitoring, vulnerability management, and protected backups across the design.
The exact products may vary. The important reasoning is the direction and purpose of each permitted connection.
Exam clue: When a diagram question asks where to place a control, ask which traffic it must observe or block. Place the control on that path without granting it unnecessary access to unrelated zones.
Protecting data by type, state, and location
Data protection starts with knowing what the data is and how the organization uses it. A public brochure and a payroll file should not receive the same access rules, retention, monitoring, or recovery priority.
Data types and classifications
Common data types include regulated records, financial information, legal material, intellectual property, trade secrets, customer data, employee data, and operational records. Data may be human-readable, such as a document, or non-human-readable, such as an encoded database or machine format.
Classification labels vary by organization. The following pattern is common:
| Classification | Typical meaning | Protection expectations |
|---|---|---|
| Public | Approved for release outside the organization. | Integrity and availability still matter even when confidentiality is low. |
| Private | Personal or internal information intended for limited use. | Access control, privacy handling, approved sharing, and retention rules. |
| Confidential | Business information whose disclosure could cause harm. | Need-to-know access, encryption, monitoring, and controlled distribution. |
| Restricted | Highly sensitive information with strict access or legal requirements. | Strong access controls, detailed logging, encryption, segmentation, and formal handling procedures. |
| Critical | Information required for essential operations or recovery. | Integrity, availability, protected backups, tested recovery, and tight change control. |
The label alone does not choose every control. A critical public service may need strong integrity and availability with little confidentiality. A restricted research file may require strong confidentiality even when short downtime is tolerable.
Data states
- Data at rest is stored on disks, databases, backups, removable media, or other persistent storage.
- Data in transit is moving across a network or between systems.
- Data in use is being processed in memory or actively handled by an application or user.
Controls must match the state. Full-disk encryption protects a powered-off stolen drive. Transport encryption protects data moving across an untrusted network. Access control, process isolation, memory protections, and secure enclaves can help while data is in use.
Data sovereignty and geolocation
Data sovereignty concerns the laws and requirements that apply based on where data is stored or processed. Geolocation identifies where systems, users, or data reside. Cloud replication, backups, content delivery, and support access can move data across regions even when the application appears to run in one place.
Architecture decisions should verify:
- Approved countries or regions
- Provider replication and backup locations
- Cross-border transfer restrictions
- Administrative access from other locations
- Retention and deletion obligations
- Contractual evidence that the provider follows the required placement
A geographic restriction can support sovereignty requirements, latency, or disaster recovery. It should be enforced through service configuration and verified through provider documentation and monitoring.
Methods for protecting data
| Method | What it provides | Appropriate use |
|---|---|---|
| Encryption | Transforms readable data into ciphertext using a key. | Protecting confidentiality at rest or in transit, with key management that matches the design. |
| Hashing | Produces a fixed-length digest used to detect change or support verification. | Integrity checks, password-verification schemes with salts and key stretching, and signed data workflows. |
| Masking | Hides part or all of a value from a viewer or lower-trust environment. | Displaying only the last digits of an account number or preparing safer test data. |
| Tokenization | Replaces sensitive data with a surrogate token linked through a protected system. | Reducing exposure of payment, identity, or other sensitive values in ordinary application flows. |
| Obfuscation | Makes data or code harder to understand. | Discouraging casual inspection; it should not be treated as strong confidentiality by itself. |
| Segmentation | Limits which systems and users can reach the data environment. | Separating regulated, restricted, or critical systems from general traffic. |
| Permission restrictions | Limits access and actions according to identity and role. | Enforcing least privilege and need-to-know access. |
| Geographic restrictions | Limits storage, processing, or access to approved locations. | Supporting sovereignty, contractual, latency, or risk requirements. |
Several methods can work together. Tokenized values may still travel over encrypted connections. A restricted database may also sit in a segmented zone with narrow permissions and monitored access.
Choosing the right method
Start with the required outcome:
- Need confidentiality if storage is stolen: use encryption at rest and protect the keys.
- Need confidentiality over an untrusted network: use authenticated transport encryption.
- Need to detect modification: use a suitable integrity mechanism such as a hash within a trusted verification process or a digital signature.
- Need realistic test data without exposing production values: use masking, tokenization, or synthetic data according to the use case.
- Need to limit who can reach a sensitive system: use segmentation and permission restrictions.
- Need to keep data inside an approved region: configure and verify geographic restrictions.
The method must cover the actual path. Encrypting a database does not protect a report after an authorized user exports it to an unmanaged device.
Resilience and recovery in security architecture
Resilience is the ability to continue essential functions, withstand disruption, and recover. Recovery design translates business impact into technical targets and tested procedures.
Availability, redundancy, and fault tolerance
These terms overlap but answer different questions:
| Concept | Purpose | Example |
|---|---|---|
| High availability | Reduces service interruption through redundant components and rapid failover. | Multiple application instances across separate failure domains. |
| Redundancy | Provides additional components, paths, or copies. | Dual network links, redundant power supplies, or multiple DNS servers. |
| Fault tolerance | Allows a service to continue operating despite a component failure. | A storage array continuing after a drive failure. |
| Load balancing | Distributes work across available service instances. | Requests sent among several healthy web servers. |
| Clustering | Coordinates systems to provide a shared service or failover capability. | A database cluster moving service to another node after failure. |
Redundancy only helps when the redundant components do not share the same failure. Two servers on one power circuit and one switch may still fail together. Separate failure domains can include power, network, hardware, location, provider region, account, and administrative control.
Recovery measurements
| Measurement | Question it answers | Example |
|---|---|---|
| RTO | How long may the service remain unavailable after disruption? | An ordering system must return within four hours. |
| RPO | How much recent data can the organization afford to lose? | A one-hour RPO requires recoverable data no more than one hour old. |
| MTTR | How long does repair or restoration usually take? | A failed device is normally restored in 45 minutes. |
| MTBF | How long does a repairable component typically operate between failures? | A device averages three years of operation between failures. |
RTO is a business recovery target. MTTR is an observed or estimated repair measure. A four-hour RTO may require an architecture that fails over in minutes even when replacement hardware takes a day to repair.
RPO drives backup or replication frequency. A daily backup cannot support a one-hour RPO by itself.
Recovery sites and geographic resilience
| Site type | Readiness | Tradeoff |
|---|---|---|
| Hot site | Equipped, connected, and maintained for rapid activation, often with current or near-current data. | Fast recovery with high ongoing cost and operational complexity. |
| Warm site | Has key infrastructure and connectivity but requires configuration, data restoration, or additional preparation. | Moderate cost and recovery time. |
| Cold site | Provides space and basic facilities with little ready-to-run technology. | Lower standing cost with slower recovery. |
Geographic dispersion protects against regional events. Distance should reduce shared risk from power, weather, telecommunications, or physical disruption while still meeting latency, sovereignty, staffing, and recovery requirements.
Platform diversity can reduce dependence on one operating system, technology stack, or failure mechanism. It also raises training, integration, and maintenance costs. Multi-cloud designs may reduce provider concentration, but they do not automatically provide failover. Applications, identities, data, networking, monitoring, and procedures must be designed and tested across providers.
Backups, snapshots, replication, and journaling
| Method | Strength | Important limitation |
|---|---|---|
| Backup | Creates a recoverable copy according to a schedule and retention policy. | Restore time, backup age, integrity, and access to the backup determine usefulness. |
| Snapshot | Captures a point-in-time state quickly, often within the same storage platform. | It may share hardware, credentials, or failure domains with the source. |
| Replication | Copies data or service state to another system or location with low delay. | Deletion, corruption, and ransomware can replicate too unless protected versions or recovery controls exist. |
| Journaling | Records changes or transactions that can support point-in-time recovery. | Recovery still depends on a valid base copy, protected logs, and tested procedures. |
A sound backup design considers:
- On-site copies for speed and off-site copies for site loss
- Offline or logically isolated copies that ordinary production credentials cannot alter
- Frequency and retention based on RPO and business requirements
- Encryption in storage and transit
- Separate protection for encryption keys
- Integrity checks and monitoring for failed jobs
- Documented restoration steps
- Regular recovery tests using representative systems and data
A successful backup job proves that data was written somewhere. A successful restore test proves much more.
Continuity, capacity, and testing
Continuity of operations identifies essential functions, responsible people, alternate processes, communication paths, and the resources required during disruption.
Capacity planning should address:
- People: Trained staff, alternates, contact methods, and authority to act.
- Technology: Compute, storage, licenses, network capacity, replacement equipment, and recovery tooling.
- Infrastructure: Facilities, power, cooling, telecommunications, transportation, and physical access.
Plans should be tested at increasing levels of realism:
| Test method | How it works | What it reveals |
|---|---|---|
| Tabletop | Participants discuss roles and decisions using a scenario. | Missing contacts, unclear authority, procedure gaps, and conflicting assumptions. |
| Simulation | Teams perform selected actions in a controlled scenario without causing a full production outage. | Operational coordination, tool access, timing, and procedural weaknesses. |
| Failover test | Service moves to an alternate component, site, or environment. | Whether dependencies, data, routing, identity, and monitoring support actual transition. |
| Parallel processing | Primary and alternate systems operate together while results are compared. | Whether the alternate environment can process real work correctly before cutover. |
Test plans should define scope, safety controls, success criteria, rollback, evidence, and follow-up work. A test that discovers a gap has done its job. The gap should become an assigned remediation item rather than a footnote that waits for the next emergency.
Power resilience
An uninterruptible power supply provides immediate short-duration power and helps bridge brief outages or the time required to start another source. A generator supports longer operation when fuel, maintenance, transfer equipment, and load capacity are adequate.
UPS capacity should cover the intended equipment and runtime. Generator plans should include fuel availability, testing, safe operation, and the systems that must remain powered, including cooling and network equipment. A powered server without cooling or connectivity is an expensive status light.
Exam clue: Choose recovery controls from the stated RTO and RPO. Faster recovery and lower data loss usually require more current copies, more ready capacity, and more frequent testing.
Common Domain 3 exam traps
Assuming the cloud provider secures every layer
Identify the service model and the misconfigured component. Customer identities, data, application settings, and tenant configuration frequently remain customer responsibilities.
Choosing a control without considering placement
A control must sit where it can observe or enforce the relevant traffic. Trace the path between the source and destination before selecting the device or zone.
Treating segmentation, isolation, and air gaps as synonyms
Segmentation permits controlled communication. Isolation removes or sharply restricts communication. An air gap uses physical separation. The scenario's required connectivity determines the right choice.
Using encryption for every data problem
Encryption addresses confidentiality. Integrity, availability, minimization, regional placement, and access limitation may require other controls.
Confusing a snapshot or replica with an independent backup
Snapshots and replicas may share credentials, platforms, or corruption with production. Check whether the copy survives the failure described in the question.
Mixing RTO and RPO
RTO measures acceptable downtime. RPO measures acceptable data loss. Look for time-to-service language versus age-of-recoverable-data language.
Calling redundant components resilient without checking shared failures
Redundancy inside one rack, building, region, account, or administrative domain may still fail together. Identify the failure the design must survive.
Ignoring safety and timing in specialized systems
OT, embedded, and real-time systems may not tolerate ordinary scanning, restarts, agents, or delayed processing. Choose controls that respect the physical process and operating limits.
Domain 3 review checklist
Before leaving Security Architecture, confirm that you can:
- Explain public, private, hybrid, and community cloud models.
- Separate customer and provider responsibilities across IaaS, PaaS, and SaaS.
- Describe the security effects of IaC, serverless computing, microservices, SDN, virtualization, and containers.
- Compare centralized and decentralized designs without assuming one is always stronger.
- Identify security constraints for IoT, embedded, real-time, and OT systems.
- Place firewalls, WAFs, IDS or IPS sensors, proxies, VPN gateways, load balancers, and jump servers on a diagram.
- Explain segmentation, isolation, air gaps, management networks, and security zones.
- Choose between fail-open and fail-closed behavior from the business requirement.
- Classify data and select controls for its type, state, and location.
- Compare encryption, hashing, masking, tokenization, obfuscation, permissions, and geographic restrictions.
- Distinguish high availability, redundancy, fault tolerance, load balancing, and clustering.
- Explain RTO, RPO, MTTR, and MTBF with examples.
- Compare hot, warm, and cold recovery sites.
- Separate backups, snapshots, replication, and journaling.
- Match tabletop, simulation, failover, and parallel tests to their purpose.
- Account for people, technology, infrastructure, power, and shared failure domains in a recovery design.
Use the randomized SY0-701 practice test to find which architecture comparisons still need another pass.
Official references
Domain coverage and weighting are based on CompTIA's published SY0-701 objectives. The supporting architecture and recovery references below come from NIST guidance.