Domain 3 accounts for 19 percent of SY0-801. Architecture questions are constraint questions. A technically strong control can still be the wrong answer if it violates availability, latency, safety, data-location, management, or recovery requirements.
1. Domain 3 map
| Objective | Focus |
|---|---|
| 3.1 | Architecture models and their security implications |
| 3.2 | Managing infrastructure security architecture |
| 3.3 | Protecting data |
| 3.4 | Resilience and recovery |
2. Architecture models
Cloud, multicloud, and deployment models
Cloud security depends on service model, deployment model, provider responsibilities, tenant responsibilities, identity design, network exposure, logging, and data handling.
A multicloud design uses services from more than one cloud provider. It can reduce dependence on one provider and meet business or regional needs, but it also increases:
- identity and policy complexity
- logging and monitoring integration work
- network and data-flow complexity
- configuration drift
- duplicated controls
- skill and tooling requirements
Do not assume multicloud automatically provides resilience. Workloads, identity, data, and dependencies must actually be designed to fail over.
Serverless and microservices
Serverless platforms reduce direct server management, but application code, permissions, dependencies, secrets, data, and event triggers still need protection.
Microservices divide an application into smaller services. This can improve isolation and deployment flexibility, but it increases service-to-service identity, application programming interface (API) security, certificate management, network policy, and observability needs.
Infrastructure as code
Infrastructure as code (IaC) makes infrastructure repeatable and reviewable. It also means a flawed template can reproduce the same exposure at scale.
Protect:
- repositories
- pipeline credentials
- modules and dependencies
- state files
- secrets
- approval paths
- deployment permissions
Static checks and policy-as-code controls can catch risky settings before deployment.
On-premises, operational technology (OT), and air-gapped environments
Operational technology (OT) often prioritizes safety and availability. Patching or scanning methods that are routine on office systems may need maintenance windows, vendor approval, passive monitoring, segmentation, or compensating controls in industrial environments.
An air gap removes ordinary network connectivity between environments. It reduces some remote paths, but removable media, maintenance devices, portable computers, supply-chain software, and physical access can still cross the boundary.
Proprietary and open-source components
Licensing model does not determine security by itself. Evaluate:
- maintenance and patch history
- transparency
- dependency management
- support
- code review
- community or vendor responsiveness
- ability to validate artifacts
3. Managing infrastructure security
Placement, zones, and segmentation
Place controls where they can see or enforce the required traffic.
Common zones include:
- user networks
- server or application zones
- management networks
- guest networks
- OT segments
- public-facing service zones
- restricted data environments
Segmentation limits movement and reduces blast radius. It does not replace endpoint or identity security.
Zero Trust user, device, and application decisions
A strong access decision can consider:
- user identity
- device identity
- device health
- managed status
- application
- resource sensitivity
- location and network context
- risk signals
- time
- recent authentication
Inventory matters because an organization cannot evaluate the health or ownership of a device it does not recognize.
Remote access and secure communications
Virtual private networks (VPNs) can protect traffic and provide controlled remote access, but broad network access may exceed what a user needs. Application-specific access or Zero Trust Network Access (ZTNA) can narrow the reachable resource set.
Use secure protocols and verify identity, certificate validity, and authorization. Encryption protects content in transit, but endpoint compromise can still expose plaintext before encryption or after decryption.
End-to-end encrypted messaging
End-to-end encryption protects message content between participating endpoints so intermediaries do not need access to plaintext. Metadata such as participants, timing, or delivery information may still exist.
Do not confuse transport encryption to a server with end-to-end protection between users.
Out-of-band management
Out-of-band management uses a management path that is separate from the normal production data path. It is valuable when the production network is unavailable or misconfigured.
Protect the management path strongly. A recovery mechanism with weak authentication can become an attacker’s preferred path.
Security Service Edge
Security Service Edge (SSE) brings controls such as secure web gateway, cloud access security broker (CASB), Zero Trust Network Access, and data protection into a distributed service model.
The scenario clue is usually distributed users and cloud applications that need policy enforcement without forcing all traffic through one traditional perimeter.
Service accounts and privilege creep
A group Managed Service Account (gMSA) can automate service password management for authorized Windows hosts. It reduces manual password handling but does not grant least privilege automatically.
Review group membership, service permissions, host authorization, and account use.
Privilege creep occurs when access accumulates through role changes, project assignments, and temporary permissions that are never removed. Periodic access review and lifecycle automation help control it.
4. Protecting data
Data states
- At rest: stored on media.
- In transit: moving across a network or communication channel.
- In use: actively processed in memory or by an application.
Choose controls based on the state and threat.
Classification and roles
Classification expresses sensitivity or handling requirements. Roles assign accountability.
Depending on context, roles can include:
- owner
- custodian
- steward
- controller
- processor
- data subject
Do not assume the security team owns all data. Business owners commonly decide use and classification, while custodians operate technical controls.
Data lifecycle
Think through:
- collection or creation
- storage
- use
- sharing
- archival
- retention
- disposal
Controls should follow the data through each stage.
Masking, tokenization, encryption, and deidentification
- Masking hides part or all of a value for display or testing.
- Tokenization replaces a sensitive value with a surrogate that maps back through a protected system.
- Encryption transforms data using a key.
- Deidentification reduces the ability to associate data with a person.
- Data transpose changes representation or arrangement to reduce direct exposure in a particular use.
Use the method that satisfies the actual business need. Encryption is not always necessary when the application only needs a non-sensitive surrogate.
Sovereignty and regulated data
Data location can affect legal, privacy, contractual, and operational requirements. Identify where data is stored, processed, backed up, and transferred.
Health, child/minor, financial, identity, and other regulated data may have additional handling restrictions.
5. Resilience and recovery
Availability designs
Common approaches include:
- load balancing
- clustering
- redundancy
- alternate sites
- geographic diversity
- platform diversity
- replication
- redundant power
- backup connectivity
Redundancy is useful only when failures are sufficiently independent. Two systems in the same failure domain can fail together.
Backups, immutability, and restoration testing
A backup strategy should consider:
- what is backed up
- frequency
- retention
- access controls
- encryption
- isolation
- immutability
- geographic separation
- restoration procedures
- recovery dependencies
An immutable backup prevents ordinary modification or deletion during a defined retention period. It improves resistance to ransomware and destructive administrator or attacker actions.
A backup that has never been restored is an assumption. Restoration testing verifies that the data, process, credentials, dependencies, and timing actually work.
Recovery metrics
| Metric | Question answered |
|---|---|
| Recovery time objective (RTO) | How quickly must the service be restored after disruption? |
| Recovery point objective (RPO) | How much data loss, expressed as time, can the organization tolerate? |
| Mean time to repair (MTTR) | How long does repair or recovery usually take? |
| Mean time between failures (MTBF) | How long does a repairable system usually operate between failures? |
RTO and RPO are targets. MTTR and MTBF describe observed or expected reliability performance.
Business continuity and disaster recovery
Business continuity keeps critical activities operating. Disaster recovery restores technology and supporting services after major disruption.
Dependencies matter. A restored application can still be unavailable if identity, Domain Name System (DNS), certificates, network paths, secrets, or data are missing.
6. Common Domain 3 traps
Assuming encrypted means inaccessible to the endpoint
Endpoints need plaintext to use data. Encryption in transit does not protect against a compromised endpoint after decryption.
Assuming multicloud equals automatic failover
Two providers do not create resilience unless data, identity, routing, dependencies, and operations support recovery.
Choosing RPO for a downtime question
RPO concerns tolerated data loss. RTO concerns restoration time.
7. Domain 3 review checklist
Confirm that you can:
- compare cloud, multicloud, serverless, microservices, IaC, on-premises, OT, and air-gapped designs
- explain segmentation, zones, device health, inventory, Zero Trust access, VPN, SSE, end-to-end encryption, and out-of-band management
- explain gMSA benefits and remaining privilege risks
- match data roles, states, classifications, lifecycle stages, masking, tokenization, encryption, and deidentification to scenarios
- compare redundancy, load balancing, clustering, replication, immutable backups, restoration testing, RTO, RPO, MTTR, and MTBF
8. Official and primary references
- CompTIA Security+ certification page
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
- NIST SP 800-34 Rev. 1: Contingency Planning Guide
- NIST SP 800-188: De-Identifying Government Datasets
- Cloud Security Alliance: Security Service Edge
- Microsoft: Manage group Managed Service Accounts