Part 4 of 6 | Domain 3.0 | 19% of the Examination
Introduction
Security architecture defines how organizations design, organize, connect, and protect their technology infrastructure, applications, and information.
An organization may use strong encryption, multifactor authentication, and firewalls yet remain vulnerable because its systems are poorly organized, sensitive information is stored in inappropriate locations, or essential services depend on a single point of failure.
Security architecture addresses these challenges by establishing appropriate infrastructure models, separating resources, controlling access, protecting information, and planning for failures.
This lesson covers the four objectives in Domain 3.0 of the CompTIA Security+ SY0-801 examination:
- 3.1: Compare and contrast security implications of different architecture models.
- 3.2: Given a scenario, manage the security architecture to best protect the infrastructure.
- 3.3: Summarize concepts and strategies used to protect data.
- 3.4: Explain the importance of resilience and recovery in security architecture.
The goal is to understand how architecture decisions influence security and to recognize the most appropriate solutions in scenario-based examination questions.
3.1 — Compare and Contrast Security Implications of Different Architecture Models
Organizations use different infrastructure architectures depending on business needs, regulatory requirements, performance expectations, security considerations, and cost.
No single architecture model is automatically the most secure.
Each introduces different responsibilities, benefits, and risks.
Architecture and Infrastructure Concepts
Cloud Computing
Cloud computing provides access to computing services such as servers, storage, networking, databases, and applications through a service provider.
Organizations can obtain resources without purchasing and operating all the underlying physical infrastructure.
Cloud environments can provide rapid deployment, elasticity, and access to geographically distributed infrastructure.
However, cloud adoption also introduces security considerations involving identity management, configuration, data protection, provider dependency, and shared security responsibilities.
A cloud provider may secure its physical facilities while customers remain responsible for application configurations, user permissions, and information stored in the service.
The division of responsibility depends on the cloud service model.
Serverless Computing
Serverless computing allows applications or functions to execute without customers directly managing the underlying servers.
The provider manages much of the infrastructure required to run the application.
For example, an online retailer may use a serverless function to process an event when a customer submits an order.
Benefits include reduced infrastructure administration, resource elasticity, and usage-based billing.
Security concerns include insecure application code, excessive permissions, vulnerable dependencies, secrets exposure, and insecure application interfaces.
Serverless does not mean that servers do not exist. It means the customer does not directly manage much of the underlying server infrastructure.
Exam scenario: An organization wants applications to execute automatically when events occur while minimizing operating system administration.
Most appropriate architecture: Serverless computing.
Multicloud
Multicloud describes an environment that uses services from more than one cloud provider.
An organization might host applications with one provider, use another for analytics, and use a third for backup storage.
Potential advantages include provider flexibility, access to specialized services, and reduced dependence on a single vendor.
Security challenges include inconsistent access controls, fragmented monitoring, increased operational complexity, and different configuration requirements.
Multicloud is not automatically resilient. Services must be designed so that the failure of one provider does not disable shared dependencies required by the entire application.
Cloud Deployment Models
Cloud deployment models describe how cloud infrastructure is made available and who uses it.
| Model | Description | Security consideration |
|---|---|---|
| Public cloud | Infrastructure offered by a provider for use by multiple customers | Tenant isolation, secure configuration, and customer identity controls |
| Private cloud | Cloud infrastructure dedicated to one organization | Dedicated control but continuing operational and security responsibilities |
| Hybrid cloud | Integration of distinct cloud environments, commonly including public and private resources | Secure connectivity, identity integration, and consistent policies |
| Community cloud | Infrastructure shared by organizations with common needs or requirements | Shared governance, agreed responsibilities, and separation of organizational resources |
Public cloud versus private cloud
Public cloud environments provide shared provider-operated infrastructure with logical separation between customers.
Private cloud infrastructure is dedicated to one organization.
Private cloud does not automatically mean better security. Security depends on architecture, management, configuration, and operational controls.
Hybrid cloud versus multicloud
Hybrid cloud concerns the combination of different deployment environments.
Multicloud concerns the use of multiple cloud providers.
An organization may operate both a hybrid and multicloud architecture.
Infrastructure as Code (IaC)
Infrastructure as Code manages infrastructure using machine-readable configuration definitions.
Rather than relying entirely on manual configuration, organizations represent resources and their intended settings as managed configuration artifacts.
Examples of IaC-managed infrastructure include cloud networks, virtual machines, storage, firewall policies, and access permissions.
Security benefits include repeatable deployment, consistent configurations, reviewable changes, and reduced configuration drift.
Security risks include exposed secrets, excessive deployment permissions, insecure templates, and the repeated deployment of incorrect settings.
For example, if an infrastructure definition contains an overly permissive storage policy, that weakness may be reproduced across numerous deployed resources.
Exam distinction: IaC improves consistency but does not guarantee that the configuration being deployed is secure.
Operational Technology (OT)
Operational Technology includes systems that monitor or control physical equipment and industrial processes.
Examples include manufacturing control systems, electric utility equipment, industrial sensors, and programmable logic controllers.
OT security has distinctive requirements because technology failures can affect physical operations and human safety.
Traditional IT environments commonly emphasize information security, while OT environments often place particularly strong emphasis on safety, availability, reliability, and predictable operation.
An industrial control system may not tolerate frequent reboots, software changes, or service interruptions.
This makes security maintenance and architecture decisions more complex.
On-Premises Infrastructure
On-premises infrastructure consists of technology operated within facilities controlled or arranged by an organization.
Examples include corporate data centers, server rooms, networking equipment, and locally managed storage.
Advantages include direct control over hardware placement, physical access, and infrastructure configuration.
Challenges include equipment maintenance, physical protection, environmental controls, staffing, replacement costs, and disaster recovery responsibilities.
Organizations operating on-premises infrastructure are generally responsible for securing and maintaining the components they control.
Air-Gapped Networks
An air-gapped network is intentionally isolated from other networks through physical separation or sufficiently strong isolation arrangements.
Air gaps are associated with highly sensitive environments and some industrial systems.
The objective is to reduce network-based paths through which unauthorized parties could communicate with protected systems.
An air gap can significantly reduce certain attack opportunities.
However, air-gapped environments may still face threats involving insiders, removable media, compromised maintenance equipment, and supply chain activity.
Exam distinction: A firewall restricting internet traffic does not necessarily create a true air gap.
Microservices
Microservices architecture divides an application into smaller services that perform defined functions.
For example, an e-commerce platform may use separate services for authentication, inventory, payment processing, and customer orders.
Each service communicates with other services through defined interfaces.
Potential benefits include independent development, scaling, and fault isolation.
Security considerations include authentication between services, secure APIs, authorization, secrets management, and monitoring.
Microservices increase the number of communication paths that may require protection.
Logical Segmentation
Logical segmentation divides infrastructure into separate security or network areas using software-defined or configured boundaries.
Examples include VLANs, virtual network segments, and controlled subnets.
A company may logically separate employee workstations, guest devices, and database systems while sharing physical networking infrastructure.
Logical separation can limit unnecessary communication and reduce opportunities for lateral movement.
However, VLAN membership alone does not guarantee traffic isolation if routing and security policies permit unrestricted connections.
Physical Segmentation
Physical segmentation separates systems using distinct physical infrastructure.
Examples include dedicated switches, cabling, interfaces, or physically isolated networks.
Physical segmentation reduces certain shared infrastructure dependencies.
However, it generally requires more hardware, operational effort, and expense.
Logical Versus Physical Segmentation
| Characteristic | Logical segmentation | Physical segmentation |
|---|---|---|
| Separation method | Software or network configuration | Distinct physical infrastructure |
| Flexibility | Generally greater | Generally lower |
| Cost | Often lower | Often higher |
| Dependence on configuration | Significant | Still important, but physical boundaries provide separation |
| Example | Separate VLANs with restricted routing | Independent physical networks |
Technical Architecture Considerations
Availability
Availability is the ability of authorized users and systems to access required services and information when needed.
Redundancy, failover capabilities, reliable infrastructure, and appropriate capacity help support availability.
Resilience
Resilience is the ability of an environment to withstand disruption, maintain essential functions, and recover from adverse events.
A resilient application may continue serving customers when one server fails.
Availability versus resilience: Availability describes whether a service is accessible. Resilience concerns the ability to endure and recover from disruption.
Proprietary Versus Open-Source Software
Proprietary software is distributed under licensing arrangements that commonly restrict access to or modification of source code.
Open-source software is distributed under licenses that permit specified forms of inspection, modification, and redistribution.
Neither model guarantees better security.
Important considerations include vulnerability management, support quality, development practices, transparency, patch availability, and organizational expertise.
Usability
Usability concerns how effectively people can interact with systems and security controls.
Security measures that are unnecessarily complex may encourage mistakes and unauthorized workarounds.
A well-designed architecture balances security requirements with legitimate operational needs.
Responsibility
Responsibility identifies who must manage, maintain, monitor, or secure particular architecture components.
In cloud environments, responsibilities are divided between providers and customers according to the applicable service model.
For example, under Infrastructure as a Service (IaaS), a customer commonly manages guest operating systems and applications, while the provider manages the underlying physical infrastructure.
Responsibility assignments must be clearly understood to avoid security gaps.
Compute
Compute refers to processing resources such as CPUs, memory, and supporting execution infrastructure.
Compute requirements affect performance, scalability, availability, and cost.
Insufficient processing capacity can reduce service availability, while uncontrolled resource allocation can increase cost or exposure.
Power Requirements
Technology infrastructure requires sufficient and reliable electrical power.
Power planning influences equipment placement, redundancy, facility design, and continuity during electrical interruptions.
Ease of Recovery
Ease of recovery concerns how readily systems can be restored following failure or compromise.
Documented configurations, manageable dependencies, recoverable backups, and replaceable infrastructure can simplify restoration.
Architectures with poorly understood dependencies may take considerably longer to recover.
Business Architecture Considerations
Data Sovereignty
Data sovereignty concerns the legal and regulatory requirements governing information because of applicable jurisdictions.
Organizations may face requirements related to where information is stored, processed, accessed, or transferred.
Data sovereignty is related to, but distinct from, data residency, which describes where information is geographically located.
Data Classification
Data classification categorizes information according to sensitivity, importance, or protection requirements.
An architecture handling confidential financial records may require stronger access restrictions than one hosting public product information.
Cost
Cost includes initial acquisition, licensing, staffing, maintenance, power, connectivity, security capabilities, and long-term operating expenses.
The lowest-cost deployment is not necessarily the most secure or economical over its full life cycle.
Ownership
Ownership establishes who is accountable for infrastructure, information, services, or associated business decisions.
An organization might own its information while a provider owns the physical storage hardware.
Ownership and operational responsibility must not be confused.
Environmental Requirements
Environmental requirements include temperature, humidity, ventilation, fire protection, power quality, and physical conditions.
Inadequate environmental controls can cause hardware damage and service disruption.
Scalability
Scalability is the ability to accommodate changes in workload or demand.
Vertical scaling: Adding resources to an existing system, such as more memory or processing capacity.
Horizontal scaling: Adding additional systems or service instances.
Both approaches have different cost, availability, and management implications.
Risk
Architecture decisions must consider potential harm from failures, attacks, unauthorized access, legal violations, and dependencies.
Risk assessment evaluates the likelihood and impact of adverse events, along with the effectiveness of existing safeguards.
Objective 3.1 Scenario Review
Scenario A: A company uses public cloud infrastructure alongside private infrastructure.
Relevant concept: Hybrid cloud.
Scenario B: An application consists of independently deployable services communicating through APIs.
Relevant concept: Microservices.
Scenario C: A highly sensitive industrial network is physically isolated from normal corporate and internet connectivity.
Relevant concept: Air-gapped network.
Scenario D: Infrastructure configurations are maintained as controlled, reviewable definitions.
Relevant concept: Infrastructure as Code.
Scenario E: A company separates departments using configured network boundaries on shared switches.
Relevant concept: Logical segmentation.
Objective 3.1 Summary
Candidates should understand architectural models and their associated technical and business trade-offs.
The exam may describe a requirement involving scalability, ownership, cost, data location, availability, or operational constraints and ask which architecture is most appropriate.
3.2 — Given a Scenario, Manage the Security Architecture to Best Protect the Infrastructure
Secure infrastructure architecture controls where resources are placed, how systems communicate, which identities can access them, and what happens when protective components fail.
The objective is to limit unnecessary exposure while supporting legitimate business operations.
Infrastructure Considerations
Device Placement
Device placement concerns where infrastructure components are located within a network or architecture.
Public-facing systems may be placed in security zones separate from sensitive internal databases.
For example, an organization's web application might be reachable from the internet while its database is accessible only through authorized application connections.
Proper placement limits unnecessary exposure.
Security Zones
Security zones group systems with similar access and protection requirements.
Examples include public-facing services, internal employee networks, management networks, and restricted database environments.
Communication between zones can be restricted according to security policy.
Attack Surface
An attack surface includes all interfaces, services, access paths, identities, and other points through which a system may be targeted.
Examples include public applications, remote administration interfaces, open network services, and cloud APIs.
Reducing unnecessary exposure decreases the number of potential entry points.
A necessary exposed service is not automatically insecure, but its configuration and protection remain important.
Diversity
Diversity reduces reliance on identical systems, technologies, or infrastructure components.
An organization may use independent network providers or different infrastructure implementations to reduce correlated failures.
Diversity can improve resilience but may increase complexity, maintenance effort, and configuration requirements.
Zero Trust Architecture
Zero Trust architecture minimizes implicit trust and emphasizes verification and authorization for access decisions.
Access should not be granted solely because a user or device is inside a corporate network.
User Authentication
Authentication verifies a claimed identity.
Zero Trust architectures commonly use strong authentication, including multifactor authentication, combined with contextual access evaluation.
Device Management: Health
Device health describes the condition of an endpoint relative to organizational requirements.
Relevant factors may include supported software, security configuration, device protection, and compliance status.
An unhealthy or noncompliant endpoint may receive restricted access even when the user is properly authenticated.
Device Management: Inventory
Device inventory identifies and records organizational equipment.
An effective inventory may include device identity, type, ownership, software, configuration, and management status.
Device inventory helps distinguish known managed endpoints from unfamiliar or unauthorized equipment.
Application Access Control
Application access control determines which users, services, or devices may access specific application functions.
A user might be permitted to read reports but prohibited from changing financial records.
Zero Trust access decisions are often granular rather than granting unrestricted access to a broad network.
Secure Communication and Access
Virtual Private Network (VPN)
A VPN creates a logical connection across another network and, when configured with appropriate security protocols, protects communications.
VPNs commonly support remote workers and connections between organizational sites.
VPN connectivity does not automatically establish that the connected identity should receive unrestricted network access.
Remote Access
Remote access enables users or administrators to interact with systems from another location.
Security considerations include authentication, authorization, session monitoring, communication protection, and device condition.
Tunneling
Tunneling encapsulates traffic within another protocol or communication path.
Tunneling may support virtual networking, secure connectivity, or transport across intermediate infrastructure.
Not all tunneling provides encryption.
A tunnel must use appropriate security mechanisms to provide confidentiality and integrity protection.
User Management
User management concerns the creation, maintenance, review, disabling, and removal of identities.
Accounts should remain associated with legitimate purposes and appropriate access.
Poor user management can leave unused or unauthorized accounts active.
User Access
User access determines which resources and functions an identity is permitted to use.
Least privilege limits permissions to those required for authorized responsibilities.
For example, a reporting employee who needs read-only access should not automatically receive database administration rights.
End-to-End Encrypted Messaging
End-to-end encryption protects message content so only the intended endpoints possess the necessary decryption capability, assuming the system operates correctly and endpoints remain secure.
An intermediate service provider generally cannot read properly protected message content merely by transporting it.
However, end-to-end encryption may not conceal metadata and cannot prevent disclosure from a compromised endpoint.
Out-of-Band Management
Out-of-band management uses a management communication path separate from ordinary production traffic.
It may allow administrators to reach infrastructure when the main network is unavailable.
Because OOB interfaces can provide privileged control, they require strong authentication, access restrictions, and monitoring.
File Transfer
Secure file transfer protects information while it moves between systems.
Examples include SFTP, which operates over SSH, and appropriate TLS-protected transfer services.
Protection also depends on endpoint security, authentication, permissions, and handling after transfer.
Security Service Edge (SSE)
Security Service Edge provides cloud-delivered security services used to protect access to internet resources, cloud applications, and private applications.
Common components include:
| Component | Purpose |
|---|---|
| Secure Web Gateway (SWG) | Applies security policies to web access |
| Cloud Access Security Broker (CASB) | Provides visibility and controls for cloud application usage |
| Zero Trust Network Access (ZTNA) | Controls application access using identity and policy |
| Data Loss Prevention (DLP) | Detects or restricts inappropriate disclosure of sensitive information |
SSE focuses on security services.
Secure Access Service Edge (SASE) combines network connectivity capabilities with these types of security services.
Exam distinction: SSE and SASE are related but are not identical architectural concepts.
Identity Management
Group Managed Service Accounts (gMSAs)
Group Managed Service Accounts are Windows domain service identities that support automated password management for compatible services.
They reduce dependence on manually maintained service-account passwords.
The account must still receive appropriate permissions.
Least Privilege Access Accounts
Least-privilege access accounts contain only the rights necessary for their assigned functions.
Service accounts and administrative identities are particularly important because excess privileges can increase the damage caused by compromise.
Privilege Creep
Privilege creep occurs when identities accumulate unnecessary permissions over time.
For example, an employee moving between departments might retain access to systems associated with previous job responsibilities.
The resulting excess permissions increase exposure.
Exam scenario: An employee has permissions from three previous departments even though their current position requires access to only one.
Relevant concept: Privilege creep.
Failure Modes
Failure modes describe how systems or security controls behave when a component stops operating correctly.
Fail-Open
A fail-open system permits continued access or operation when a security control fails.
This may preserve availability but reduce security.
For example, a security control that stops inspecting traffic and permits traffic to continue may be operating in a fail-open manner.
Fail-Closed
A fail-closed system denies access or prevents the protected operation when security verification cannot be completed.
This may preserve protection but interrupt legitimate business activity.
| Failure mode | Behavior | Primary trade-off |
|---|---|---|
| Fail-open | Permits access or continued operation following certain failures | Availability may be prioritized over enforcement |
| Fail-closed | Denies access when security validation fails | Security enforcement may be prioritized over availability |
The correct failure behavior depends on the system's purpose.
A facility emergency-exit mechanism may have life-safety requirements that differ from those of a financial application's authorization system.
Objective 3.2 Scenario Review
Scenario A: A public web server and confidential database must be separated.
Relevant concept: Device placement and security zones.
Scenario B: A security architecture evaluates both a user's identity and the security condition of their device.
Relevant concept: Zero Trust architecture.
Scenario C: Administrators require infrastructure access through a separate management path when production connectivity fails.
Relevant concept: Out-of-band management.
Scenario D: Access-control services fail, and the system denies new requests rather than allowing unverified users.
Relevant concept: Fail-closed.
Scenario E: A service identity requires automatic password management in a compatible Windows domain environment.
Relevant concept: Group Managed Service Account.
Objective 3.2 Summary
Candidates should understand how infrastructure placement, identity controls, secure communications, device posture, and failure behavior contribute to security.
The examination may describe an infrastructure requirement and ask which architectural safeguard best addresses the associated risk.
3.3 — Summarize Concepts and Strategies Used to Protect Data
Information protection involves more than encryption.
Organizations must understand the kinds of information they possess, where it exists, how it is used, who is responsible for it, and which protections are appropriate throughout its life cycle.
Data Types
Structured Data
Structured data follows a defined organization or schema.
Examples include relational database records, inventory tables, and financial transactions stored in predefined fields.
Structured data is generally easier to query and evaluate against standardized rules.
Unstructured Data
Unstructured data does not follow a fixed tabular schema.
Examples include emails, documents, images, videos, audio recordings, and presentations.
Unstructured information may contain sensitive details that are harder to identify through simple field-based rules.
Exam distinction: Structured and unstructured describe organization, not sensitivity.
Data States
Information exists in different states during storage, communication, and processing.
Data at Rest
Data at rest is information stored on devices or storage services.
Examples include database files, stored documents, and backups.
Relevant protections include encryption, access controls, and physical safeguards.
Data in Use
Data in use is actively processed by an application or computing system.
For example, customer records loaded into application memory for processing are data in use.
Protection may involve application isolation, memory security, access controls, and specialized confidential-computing technologies.
Data in Transit
Data in transit moves between systems or communication endpoints.
Examples include web traffic, application API communications, and file transfers.
Transport encryption can protect information against interception and modification while it travels.
| Data state | Example | Relevant protection |
|---|---|---|
| At rest | Documents stored on a laptop | Storage encryption |
| In use | Information being processed in memory | Isolation and controlled processing |
| In transit | Information transmitted between applications | Secure communication protocols |
Data Classifications
Data classification assigns information to categories reflecting its sensitivity, importance, or handling requirements.
Classification schemes vary between organizations and regulatory environments.
| Classification | General meaning |
|---|---|
| Public | Approved for unrestricted public disclosure |
| Sensitive | Requires additional care because disclosure or misuse could cause harm |
| Confidential | Restricted to authorized individuals or purposes |
| Restricted | Subject to particularly strict access or handling controls |
| Secret | Highly sensitive information requiring strong protection |
| Top secret | Information requiring the highest protection within certain formal government classification systems |
| Critical | Essential to important business or operational functions |
Important distinction: Critical often describes operational importance rather than a level of confidentiality.
For example, a public emergency communication system may contain publicly available information but still be critical to business or public operations.
Methods Used to Secure Data
Masking
Data masking conceals selected information from view.
For example, a customer service application may display only the final four digits of a payment-card number.
Masking limits exposure in a particular presentation or dataset.
It does not necessarily protect the underlying original information from someone who has sufficient access to retrieve it.
Hashing
Hashing transforms information into a fixed-length digest using a hash function.
Cryptographic hashes can support integrity verification and other security processes.
Hashing is not reversible encryption.
A hash by itself does not establish the identity of the source.
Filtering
Filtering selects or excludes information according to defined rules.
For example, a report intended for general employees may omit restricted personnel fields.
Filtering helps limit unnecessary information exposure.
Tokenization
Tokenization replaces sensitive values with substitutes called tokens.
The original information may be retained in a protected system or accessible through an authorized mapping process.
For example, payment applications may use tokens instead of exposing actual account numbers across every system.
Encryption
Encryption converts readable information into ciphertext using cryptographic algorithms and keys.
Appropriate encryption protects confidentiality.
The effectiveness of encryption also depends on key management, algorithm selection, implementation, and endpoint security.
Data Transpose
Data transposition changes the ordering or arrangement of information.
A simple transposition may make information less readable, but rearrangement alone does not provide the security guarantees of modern authenticated encryption.
The exam may distinguish transposition and obfuscation from strong cryptographic protection.
Deidentification
Deidentification removes or transforms identifying information to reduce the ability to associate data with an individual.
For example, a research dataset may remove names and direct identifiers.
Deidentification does not always eliminate reidentification risk, particularly when multiple datasets can be combined.
Obfuscation
Obfuscation makes information harder to understand.
Examples include disguising application logic or altering recognizable data representations.
Obfuscation is not equivalent to encryption.
Comparing Data Security Methods
| Method | Primary purpose |
|---|---|
| Masking | Hide selected information |
| Hashing | Create a digest for integrity-related functions |
| Filtering | Include or exclude information according to rules |
| Tokenization | Substitute controlled tokens for sensitive values |
| Encryption | Protect confidentiality cryptographically |
| Transposition | Rearrange information |
| Deidentification | Reduce association with identifiable individuals |
| Obfuscation | Make information more difficult to understand |
Exam scenario: A payment company wants internal applications to reference transactions without exposing actual payment-card numbers.
Most relevant solution: Tokenization.
Data Protection Roles
Different roles are responsible for governing, administering, processing, and protecting information.
Data Owner
The data owner is accountable for a dataset and commonly establishes its classification and access requirements.
Ownership concerns governance responsibility and does not necessarily mean legal ownership of every underlying record.
Data Custodian
The data custodian implements and maintains the protections required for information.
A database administrator responsible for storage permissions, backup administration, and system maintenance may act as a data custodian.
Data Steward
The data steward helps maintain data quality, consistency, meaning, and adherence to governance standards.
A steward may oversee definitions, accuracy, and appropriate organizational use.
Data Operator
A data operator performs authorized operational activities involving data or the systems that process it.
Responsibilities vary between organizations and may include routine processing, maintenance, or administration.
Data Controller
A data controller determines the purposes and means of processing personal information under applicable privacy frameworks.
The controller determines why and how personal information is processed.
Data Subprocessor
A subprocessor handles personal information on behalf of another processor under an applicable authorized arrangement.
Subprocessors commonly appear in service-provider relationships involving personal data.
Data Role Comparison
| Role | Primary responsibility |
|---|---|
| Data owner | Accountability, classification, and access requirements |
| Data custodian | Technical or operational protection and maintenance |
| Data steward | Quality, consistency, and governance |
| Data operator | Authorized operational processing |
| Data controller | Purposes and means of personal-data processing |
| Data subprocessor | Processing personal information on behalf of another processor |
Exam distinction: A data owner establishes requirements; a custodian commonly implements them.
A data controller and subprocessor belong to a different regulatory and processing-relationship context.
Data Handling
Endpoints
Endpoints are devices through which users or applications access, process, or store information.
Examples include computers, tablets, and mobile devices.
Endpoint security directly influences the protection of data handled on those devices.
Marking and Labeling
Marking and labeling identify information classifications or handling requirements.
For example, a document marked Confidential communicates that it requires restricted distribution.
Labels may support organizational processes and automated policy enforcement.
Geofencing
Geofencing uses geographic boundaries to apply location-related controls.
An organization may restrict access to a particular application based on an approved geographic area.
Geofencing depends on the accuracy and trustworthiness of location information.
Data Location
Data location describes where information resides.
The location may influence access, performance, regulatory obligations, and disaster recovery.
Data Placement
Data placement concerns selecting the systems, services, regions, or storage environments appropriate for particular information.
For example, highly regulated information may require a specified region or environment with additional controls.
Data Management Life Cycle
Information requires protection throughout its existence.
Creation
Data is generated, acquired, or collected.
Relevant concerns include accuracy, legitimate purpose, classification, and initial handling requirements.
Management
Data is organized, maintained, updated, and protected.
This stage includes ensuring integrity, appropriate access, and consistent governance.
Distribution
Data is shared or transmitted between authorized parties.
Security concerns include recipient authorization, transmission protection, and restrictions on further disclosure.
Retention
Retention determines how long information remains stored.
Requirements may reflect business, legal, regulatory, or contractual obligations.
Keeping information longer than necessary can increase exposure.
Deleting it prematurely may violate applicable requirements.
Disposal
Disposal removes information from use when retention is no longer required.
Appropriate disposal may involve secure deletion, cryptographic erasure, or physical destruction, depending on the storage medium and requirements.
Ordinary file deletion does not necessarily make previously stored information unrecoverable.
Data Compliance
Data compliance concerns meeting applicable requirements for collecting, storing, processing, protecting, retaining, and disposing of information.
Standards
Standards establish requirements or recommended practices for managing particular information.
For example, payment-card environments may be subject to PCI DSS requirements.
Standards, contractual obligations, and laws are distinct sources of requirements.
Health Data
Health information may require additional confidentiality and privacy protections.
In the United States, HIPAA applies to defined covered entities and business associates under applicable circumstances.
The presence of health-related information does not automatically mean every HIPAA provision applies to every organization.
Personal Information
Personal information relates to identifiable individuals.
Depending on applicable law, organizations may have obligations regarding collection, disclosure, security, retention, and individual rights.
Financial Information
Financial information may include banking records, payment details, and financial transactions.
It may require protections under laws, industry requirements, and contractual obligations.
Child or Minor Data
Information concerning children or minors may be subject to additional privacy requirements.
Applicable restrictions depend on jurisdiction, the child's age, and the type of service or processing activity.
Intellectual Property
Intellectual property includes legally protected or proprietary creations, such as software, inventions, product designs, and trade secrets.
Unauthorized disclosure may create financial, competitive, and legal consequences.
Legal Data
Legal data may include contracts, litigation records, privileged communications, and preserved evidence.
Security considerations include confidentiality, integrity, access restrictions, retention, and legal preservation obligations.
Objective 3.3 Scenario Review
Scenario A: A company encrypts stored documents but needs to protect information transmitted between systems.
Relevant concept: Data in transit.
Scenario B: A payment application replaces original card numbers with substitute identifiers.
Relevant concept: Tokenization.
Scenario C: A dataset is stripped of identifying fields to reduce the ability to associate records with individuals.
Relevant concept: Deidentification.
Scenario D: An employee responsible for database backups maintains controls established by another business owner.
Relevant role: Data custodian.
Scenario E: A company determines that certain information must remain in a specified geographic region because of legal requirements.
Relevant concepts: Data sovereignty and data placement.
Objective 3.3 Summary
Candidates should recognize different data types, states, classifications, protection techniques, organizational responsibilities, and handling requirements.
The examination may ask for a protection technique that meets a specific business purpose or a role responsible for a particular information-governance activity.
3.4 — Explain the Importance of Resilience and Recovery in Security Architecture
Resilience and recovery help organizations continue essential operations and restore systems following failures.
Disruptions may involve malicious attacks, infrastructure failures, software defects, environmental events, or human mistakes.
A secure architecture considers both how failures can be prevented and how their consequences can be limited.
Site Considerations
Alternative recovery sites provide locations where essential systems or business functions may be restored.
Hot Site
A hot site is an alternative location equipped with operational resources intended to support rapid recovery.
Systems, infrastructure, and relevant data may already be available or maintained in a recovery-ready condition.
Hot sites generally require higher ongoing expenditure.
Their main benefit is comparatively rapid recovery.
Cold Site
A cold site provides an alternative facility with limited immediately operational infrastructure.
Additional equipment, configuration, connectivity, and data restoration may be required.
Cold sites generally cost less to maintain but require more recovery time.
Warm Site
A warm site provides an intermediate level of readiness.
It includes some prepared infrastructure but typically requires additional configuration, restoration, or activation.
Warm sites balance cost and recovery speed.
Hot, Warm, and Cold Compared
| Site type | Infrastructure readiness | Relative ongoing cost | Expected recovery potential |
|---|---|---|---|
| Hot | High | Higher | Fast |
| Warm | Moderate | Moderate | Intermediate |
| Cold | Low | Lower | Slower |
Actual recovery times depend on the environment's implementation and readiness.
Exam scenario: A company needs to restore critical systems rapidly at an alternative location with minimal additional preparation.
Most appropriate option: Hot site.
Environmental Site Considerations
Alternative sites must account for environmental risks such as flooding, fire, extreme weather, temperature, power outages, and geographic hazards.
Two facilities in the same disaster-prone area may fail simultaneously.
Geographic and infrastructure independence can therefore be important.
Platform Diversity
Platform diversity reduces dependence on components that may share identical vulnerabilities or failure characteristics.
Vendor Platform Diversity
Vendor diversity involves using different suppliers or technology platforms.
It may reduce certain common vendor-specific risks.
However, supporting multiple platforms may increase complexity.
Hardware Diversity
Hardware diversity uses different hardware implementations or configurations.
This can reduce dependence on a single component model or common defect.
Virtualization
Virtualization allows multiple isolated computing environments to operate on shared underlying hardware.
It can support workload portability, infrastructure consolidation, and recovery flexibility.
However, shared hypervisors, storage, networking, and management services may create common failure points.
Redundancy Strategies and Solutions
Redundancy provides additional capabilities that can continue supporting operations when a component fails.
Load Balancing
Load balancing distributes workloads among multiple resources.
For example, a web application may use several servers to handle customer requests.
If one server becomes unhealthy, an appropriately designed load-balancing system may redirect traffic to available servers.
Load balancing can improve availability and resource utilization.
Clustering
Clustering connects multiple systems so that they operate as a coordinated service.
Cluster members may share workloads or provide standby capacity.
The design may support continued operation when a member fails.
Autoscaling
Autoscaling adjusts the number or capacity of computing resources in response to demand or policies.
For example, an application may gain additional instances during periods of high customer activity.
Autoscaling supports capacity management but does not automatically resolve every application failure.
High Availability
High availability aims to minimize service interruption through redundancy, failover, and elimination of important single points of failure.
A highly available system may continue operating even when an individual component becomes unavailable.
Multicloud Systems
Multicloud architectures can provide resilience when workloads and dependencies are designed to operate across providers.
Simply purchasing services from multiple cloud companies does not guarantee continuity.
Applications may still depend on a shared identity service, database, or network connection.
Power Redundancy
Electrical power failures can interrupt essential systems even when their software and network configurations are secure.
Uninterruptible Power Supply (UPS)
A UPS supplies temporary electrical power when normal power is interrupted.
It can keep equipment operational during short outages, support a transition to generator power, or allow controlled shutdown.
Redundant Power Supply (RPS)
Redundant power supplies provide alternative power capability for equipment.
Some infrastructure components contain multiple independent power-supply units.
Redundancy may be ineffective if all supplies depend on the same failed upstream circuit.
Power Generator
A generator supplies electrical power during utility outages.
Generators may support longer outages when adequate fuel, maintenance, and capacity are available.
They may require startup time before delivering power.
Surge Protector
A surge protector reduces exposure to certain transient voltage spikes.
It does not supply replacement electrical power during an outage.
Power Technology Comparison
| Technology | Primary purpose |
|---|---|
| UPS | Temporary power during interruption |
| RPS | Redundant equipment power capability |
| Generator | Longer-duration alternative electricity generation |
| Surge protector | Protection against certain voltage transients |
Exam scenario: A data center must keep servers operating during the period between a utility outage and generator startup.
Most appropriate technology: UPS.
Storage
Storage resilience protects information availability against equipment failures and other disruptions.
Technologies may include replicated storage, redundant disks, storage clustering, and geographically separated copies.
RAID
Redundant Array of Independent Disks (RAID) combines multiple drives to achieve particular performance or fault-tolerance characteristics.
Common RAID levels include:
| RAID level | Description | General fault-tolerance characteristic |
|---|---|---|
| RAID 0 | Striping across disks | No disk-failure tolerance |
| RAID 1 | Mirroring | Can generally tolerate failure of a mirrored member |
| RAID 5 | Striping with distributed parity | Generally tolerates one drive failure |
| RAID 6 | Striping with dual parity | Generally tolerates two drive failures |
| RAID 10 | Striping across mirrored sets | Tolerates certain multiple-drive failure combinations |
RAID improves resilience against specified drive failures.
It is not a backup.
Deletion, ransomware, corruption, and some infrastructure failures can affect all drives or replicas within an array.
Backups
Backups provide recoverable copies of information, configurations, or systems.
A backup strategy should address what information is protected, how long copies remain available, how backups are secured, and whether restoration is possible.
Retention
Retention specifies how long backup copies remain stored.
Requirements may result from business objectives, regulatory obligations, or recovery needs.
Insufficient retention can prevent recovery from a compromise discovered long after it occurred.
Immutability
Immutable backups resist modification or deletion during a defined protection period.
Immutability can reduce the ability of ransomware or compromised administrative accounts to destroy recovery copies.
It does not guarantee that backup information is free from corruption or compromise.
Scope
Backup scope defines the systems, files, records, configurations, and dependencies included.
For example, recovering an application may require its database, configuration, secrets, certificates, and supporting services.
A backup missing critical dependencies may be insufficient for complete restoration.
Restoration Testing
Restoration testing determines whether backup information can actually be recovered.
It can reveal missing files, corrupted data, incompatible dependencies, or excessive recovery duration.
Exam distinction: A successful backup operation does not prove successful recovery.
Common Backup Methods
Full backup
A full backup copies all information within the defined scope.
It generally simplifies recovery but requires more backup storage and processing time.
Incremental backup
An incremental backup stores information changed since the previous relevant backup.
Incremental strategies can reduce routine backup volume but may require several backup sets for restoration.
Differential backup
A differential backup stores information changed since the last full backup.
Differential backups generally grow between full backups but can require fewer sets for restoration than incremental chains.
Backup Method Comparison
| Method | What is copied | Typical restoration requirement |
|---|---|---|
| Full | All data within scope | Relevant full backup |
| Incremental | Changes since the previous backup | Full backup plus required incremental chain |
| Differential | Changes since the last full backup | Full backup plus the relevant differential backup |
Resilience Testing
Resilience measures must be evaluated to establish whether they perform as expected.
Failover Testing
Failover testing evaluates whether services can transition from a failed or unavailable component to an alternative.
It can reveal problems involving routing, synchronization, authentication, capacity, or dependencies.
Simulation
Simulation evaluates anticipated incidents or failures using controlled scenarios.
It may test procedures, communications, technical dependencies, or organizational decisions.
Simulation does not necessarily reproduce every consequence of a real-world disaster.
Parallel Processing
Parallel processing, in a recovery-testing context, may involve running primary and alternative systems simultaneously to compare operation or confirm readiness.
This approach can provide evidence that a recovery environment functions before a full transition.
It is distinct from parallel computing for routine performance improvements.
Disaster Recovery
Disaster recovery focuses on restoring technology systems, information, infrastructure, and related services after disruption.
Examples include recovering servers following ransomware, restoring a failed database, or activating an alternative data center.
Disaster recovery is a component of broader organizational resilience.
Business Continuity
Business continuity focuses on maintaining essential business functions during and following disruption.
It considers people, facilities, business processes, communications, suppliers, and technology.
Business Continuity Versus Disaster Recovery
| Business continuity | Disaster recovery |
|---|---|
| Maintains essential business operations | Restores disrupted technology capabilities |
| Includes staffing, facilities, suppliers, and processes | Emphasizes systems, applications, infrastructure, and data |
| Broad organizational scope | Primarily technology restoration scope |
Exam scenario: Employees continue customer service using an approved alternative process while the IT department restores the primary application.
The alternative operational arrangement supports business continuity.
Restoring the application is part of disaster recovery.
Capacity Planning
Capacity planning evaluates whether sufficient resources exist to support expected demand and failure conditions.
Relevant resources include processing power, memory, storage, network bandwidth, electrical capacity, facilities, and personnel.
Capacity planning supports performance, availability, scalability, and recovery readiness.
An organization may operate two servers successfully under normal conditions, but if either server cannot handle the workload alone, the system may still be vulnerable to a single-server failure.
Recovery Metrics
Recovery metrics establish acceptable targets and describe repair or reliability performance.
Recovery Time Objective (RTO)
RTO defines the targeted maximum time within which a service or business function should be restored after disruption.
For example, an RTO of two hours means restoration is expected within the defined two-hour window.
Recovery Point Objective (RPO)
RPO defines the maximum acceptable period of data loss measured backward from the disruption.
For example, an RPO of 15 minutes means the recovery solution is designed to limit lost recent changes to no more than approximately 15 minutes under the specified conditions.
Mean Time to Repair (MTTR)
MTTR describes the average amount of time required to repair a failed component or restore it to an operational condition.
A lower MTTR generally indicates faster repair.
Mean Time Between Failures (MTBF)
MTBF measures the average operating time between failures of a repairable system or component.
A higher MTBF generally indicates greater reliability when measurements are comparable.
Recovery Metric Comparison
| Metric | Meaning | Example |
|---|---|---|
| RTO | Maximum targeted restoration time | Restore within 2 hours |
| RPO | Maximum acceptable data-loss interval | Lose no more than 15 minutes of changes |
| MTTR | Average repair time | 45-minute average repair |
| MTBF | Average operating time between failures | 1,000 operating hours |
RTO Versus RPO Example
A financial application has these requirements:
- RTO: 4 hours.
- RPO: 30 minutes.
Following a disruption, the service becomes available again after two hours, but the recovered database is missing three hours of recent transactions.
The recovery meets the RTO because restoration occurred within four hours.
It fails the RPO because the amount of data lost exceeds the permitted 30-minute interval.
Exam distinction: RTO concerns restoration time; RPO concerns acceptable data loss. MTTR and MTBF describe repair and reliability characteristics.
Objective 3.4 Scenario Review
Scenario A: A company needs a fully prepared alternative location for rapid restoration.
Relevant concept: Hot site.
Scenario B: A service uses multiple servers so that traffic can continue when an individual server fails.
Relevant concepts: Load balancing and high availability.
Scenario C: A company protects recovery copies against alteration during a specified retention period.
Relevant concept: Immutable backups.
Scenario D: A system must be restored within three hours following disruption.
Relevant metric: RTO.
Scenario E: An organization can tolerate no more than 20 minutes of recent data loss.
Relevant metric: RPO.
Objective 3.4 Summary
Candidates should understand recovery-site differences, redundancy, power protection, storage resilience, backup characteristics, continuity planning, testing, and recovery metrics.
The examination emphasizes selecting solutions that match an organization's requirements for availability, acceptable downtime, data loss, and recovery readiness.
Domain 3.0 — Examination Practice
The following questions are original practice questions based on the concepts covered in this lesson. They are not actual CompTIA examination questions.
Questions
1. An organization operates a private cloud for sensitive applications and uses a public cloud provider for other workloads. Which deployment model best describes the environment?
A. Community cloud
B. Hybrid cloud
C. Air-gapped network
D. Physical segmentation
2. An application consists of independently deployable services that communicate through APIs. Which architecture is being used?
A. Microservices
B. Cold-site architecture
C. Physical segmentation
D. Full-disk encryption
3. A company manages cloud resources using reusable configuration definitions. What concept best describes this approach?
A. Tokenization
B. Infrastructure as Code
C. Data sovereignty
D. Out-of-band management
4. Two departments use the same physical networking equipment but operate on separate VLANs with access restrictions. What architecture is illustrated?
A. Physical segmentation
B. Air-gapped networking
C. Logical segmentation
D. Multicloud
5. A company wants application-access decisions to consider identity, device condition, and authorization rather than automatically trusting internal-network users. Which architecture best matches the requirement?
A. Unrestricted VPN access
B. Cold-site recovery
C. Zero Trust
D. Public object storage
6. An employee changes departments but retains permissions from every previous role. What security issue is present?
A. Privilege creep
B. Fail-closed
C. Data masking
D. Autoscaling
7. A Windows domain service requires an account whose password can be automatically managed by the domain. Which identity type is most appropriate?
A. Shared administrator account
B. Anonymous account
C. Group Managed Service Account
D. Local guest account
8. A security control stops responding, and the protected system denies new access requests rather than allowing unverified access. Which failure mode is demonstrated?
A. Fail-open
B. Fail-closed
C. Load balancing
D. Fail-forward
9. A network administrator needs a separate communication path for infrastructure management when normal production connectivity is unavailable. Which solution is most relevant?
A. Tokenization
B. File masking
C. Out-of-band management
D. Differential backup
10. A business needs cloud-delivered web protection, cloud application security, and identity-based access to private applications. Which architecture most directly addresses these needs?
A. RAID
B. Security Service Edge
C. Cold site
D. Power redundancy
11. A financial application displays only the final four digits of payment-card numbers. Which data protection technique is illustrated?
A. Hashing
B. Tokenization
C. Masking
D. Transposition
12. An organization replaces original payment-card numbers with substitute identifiers used by internal applications. Which method is being used?
A. Tokenization
B. Obfuscation
C. Data filtering
D. Hashing
13. A database administrator maintains storage permissions and backups according to requirements established by the responsible business unit. Which role is most applicable?
A. Data controller
B. Data custodian
C. Data subprocessor
D. Data subject
14. A company must ensure certain information is stored and processed in a specified jurisdiction due to applicable legal requirements. Which architectural consideration is most relevant?
A. Data sovereignty
B. Horizontal scaling
C. Load balancing
D. Serverless computing
15. A company wants an alternative location that can support critical systems with minimal additional recovery preparation. Which site is generally most appropriate?
A. Cold site
B. Warm site
C. Hot site
D. Unprepared office
16. A data center needs equipment to remain powered during the interval between a utility outage and generator startup. Which technology is most appropriate?
A. Surge protector
B. UPS
C. Data steward
D. Cold site
17. An organization wants backup copies that cannot be modified or deleted during a defined protection period. Which characteristic is most relevant?
A. Autoscaling
B. Immutability
C. Physical segmentation
D. Load balancing
18. An application must be restored within four hours after disruption. Which metric describes this requirement?
A. RPO
B. MTBF
C. RTO
D. MTTR
19. A database recovery strategy must limit lost transactions to no more than 15 minutes of recent activity. Which metric describes this requirement?
A. MTTR
B. RPO
C. MTBF
D. RTO
20. Following a major outage, employees continue critical business operations using alternative procedures while technology teams restore the primary systems. Which statement best describes these activities?
A. Both activities are exclusively data masking.
B. Business continuity maintains essential operations, while disaster recovery focuses on restoring technology.
C. Disaster recovery replaces the need for business continuity.
D. Business continuity concerns only electrical power systems.
Answers and Explanations
| Question | Answer | Explanation |
|---|---|---|
| 1 | B | Hybrid cloud combines distinct cloud deployment environments, commonly including private and public infrastructure. |
| 2 | A | Microservices divide an application into smaller, independently managed services. |
| 3 | B | Infrastructure as Code represents and manages infrastructure through controlled configuration definitions. |
| 4 | C | Logical segmentation creates configured network separation using shared infrastructure. |
| 5 | C | Zero Trust evaluates access using identity, permissions, device condition, and relevant context. |
| 6 | A | Privilege creep is the accumulation of unnecessary access permissions over time. |
| 7 | C | gMSAs provide automated password management for compatible Windows domain services. |
| 8 | B | Fail-closed denies access when a required security control cannot complete verification. |
| 9 | C | Out-of-band management provides a management path separate from normal production communications. |
| 10 | B | SSE delivers integrated cloud-based security services such as SWG, CASB, and ZTNA. |
| 11 | C | Masking hides selected information from view. |
| 12 | A | Tokenization substitutes controlled tokens for original sensitive values. |
| 13 | B | A data custodian maintains and protects information according to established requirements. |
| 14 | A | Data sovereignty concerns jurisdictional legal requirements governing information. |
| 15 | C | Hot sites are prepared to support comparatively rapid recovery. |
| 16 | B | A UPS supplies temporary power during an electrical interruption. |
| 17 | B | Immutability prevents alteration or deletion during the defined protected period, subject to the system's guarantees. |
| 18 | C | RTO defines the targeted maximum service restoration time. |
| 19 | B | RPO defines the maximum acceptable interval of recent data loss. |
| 20 | B | Business continuity addresses broader business operations; disaster recovery focuses on restoring technology capabilities. |
Final Domain 3.0 Review
| Official objective | Core knowledge |
|---|---|
| 3.1 | Cloud, serverless, multicloud, deployment models, IaC, OT, on-premises infrastructure, air gaps, microservices, logical and physical segmentation, technical considerations, and business considerations |
| 3.2 | Device placement, security zones, attack surface, diversity, Zero Trust, user authentication, device health and inventory, application access, VPNs, remote access, tunneling, user management, least privilege, encrypted messaging, OOB management, file transfer, SSE, gMSAs, privilege creep, and failure modes |
| 3.3 | Structured and unstructured data, data states, classifications, masking, hashing, filtering, tokenization, encryption, transposition, deidentification, obfuscation, data roles, handling, life cycle, and compliance |
| 3.4 | Hot/warm/cold sites, environmental considerations, platform diversity, redundancy, load balancing, clustering, autoscaling, high availability, multicloud, power technologies, storage, backups, testing, disaster recovery, business continuity, capacity planning, RTO, RPO, MTTR, and MTBF |
Preparing for the Examination
Security Architecture accounts for 19% of the CompTIA Security+ SY0-801 examination.
Candidates should be able to distinguish between architectures that may appear similar, identify infrastructure protection requirements, recognize appropriate data protection methods, and interpret recovery objectives.
When analyzing a scenario, consider four questions:
- What is the architectural requirement? Determine whether the question concerns infrastructure placement, access, scalability, privacy, availability, or another objective.
- What risk is being addressed? Identify the potential exposure, operational consequence, or failure condition.
- Which technology or process solves the stated problem? Distinguish controls that serve different purposes.
- What trade-off does the solution introduce? Consider cost, complexity, security, performance, and recovery requirements.
For example, an RPO question concerns acceptable data loss, while an RTO question concerns restoration time. A question about replacing confidential values with controlled substitutes points toward tokenization, not ordinary masking. A scenario requiring independent management access during a network outage points toward out-of-band management.
Selecting the correct examination answer requires matching the stated requirement to the actual purpose of the architecture or security control.
Next Lesson: Part 5 — Security Operations
Domain 4.0 accounts for 27% of the Security+ SY0-801 examination.
Part Five covers operational security controls, asset management, vulnerability management, monitoring, enterprise security management, automation, incident response, and digital investigations.
Official reference: CompTIA Security+ SY0-801 V8 Certification Exam Objectives, Document Version 2.0, Domain 3.0, pages 11–14.
https://lecbyo.files.cmp.optimizely.com/download/77f3bd3223ac11f180820e495f189928
*Tech Little Brawta is an independent educational resource and is not affiliated with or endorsed by CompTIA. Security+ and CompTIA are trademarks of CompTIA, Inc.*
Tech Little Brawta | Learning | CompTIA Security+ SY0-801 | Part 4 of 6
