Security Architecture carries 18% of the current Security+ SY0-701 blueprint. CompTIA expects candidates to compare architecture models, apply security principles to enterprise infrastructure, protect data, and explain resilience and recovery. The domain spans cloud and on-premises systems, infrastructure as code, serverless computing, microservices, segmentation, virtualization, containers, IoT and industrial systems, firewalls, IDS/IPS, 802.1X, VPNs, TLS, IPsec, high availability, backups, and recovery planning. The SY0-701 exam therefore tests architecture as a set of trade-offs rather than a diagram filled with security products.
A secure design starts with assets, trust boundaries, failure modes, and required communication. Only then should you select controls. The strongest answers usually reduce attack surface, limit implicit trust, preserve required availability, and protect data throughout its lifecycle without making the environment impossible to operate.
Compare architecture models by their security implications
Cloud, on-premises, hybrid, centralized, decentralized, serverless, microservices, containerized, virtualized, IoT, and industrial environments do not share the same operational constraints. Cloud designs involve a responsibility model and third-party dependencies. IoT and embedded systems may have limited patching options. Industrial control systems can prioritize availability and safety in ways that change maintenance windows and security controls.
Infrastructure as code can improve consistency because configuration is versioned and repeatable, but insecure templates can also reproduce the same weakness at scale. Serverless architectures reduce some infrastructure management while increasing dependence on identity, service configuration, and event-driven permissions. Microservices can improve isolation but also create many service-to-service trust relationships.
The exam asks you to reason about those implications. Avoid declaring one architecture “more secure” without context.
Use segmentation to create meaningful trust boundaries
Segmentation limits which systems can communicate and reduces lateral movement after compromise. It can be physical, logical, or software-defined. A DMZ or perimeter network is a classic example of separating public-facing systems from trusted internal resources; the DMZ concept illustrates why placement matters as much as the firewall rule itself.
Logical segmentation can use VLANs, subnets, virtual networks, security groups, ACLs, or software-defined controls depending on the platform. The goal is not to create the maximum possible number of segments. Each boundary should reflect a real difference in trust, sensitivity, administration, or communication requirements.
A flat network is simple but can make lateral movement easy. An excessively fragmented design can be hard to troubleshoot and may encourage administrators to add broad exceptions. Secure architecture balances isolation with operability.
Select network controls by placement and behavior
SY0-701 names jump servers, proxy servers, IDS/IPS, load balancers, sensors, port security, 802.1X, web application firewalls, UTM devices, next-generation firewalls, and Layer 4 versus Layer 7 behavior. The key is knowing what traffic the control can see and whether it is inline, passive, preventive, or detective.
An IDS can monitor and alert without necessarily blocking traffic. An IPS is placed to prevent or stop matching activity. A web application firewall focuses on web-layer requests. A next-generation firewall can combine stateful inspection with additional application and threat-awareness features. The broader comparison of firewall deployment approaches is useful, but the exam question should drive the control choice.
Placement changes effectiveness. A sensor that cannot observe the relevant traffic cannot detect the attack, and a firewall rule applied after an untrusted path may not protect the intended boundary.
Control access at the edge of the network
Port security, 802.1X, and Extensible Authentication Protocol appear in the infrastructure objective because network access should not depend only on physical connection. 802.1X can require authentication before a device receives normal network access, using a supplicant, authenticator, and authentication service in a typical design.
The 802.1X access-control model is helpful because it shows how identity can be enforced at the connection boundary. This complements, rather than replaces, later authorization and segmentation controls.
Exam scenarios may contrast open switch-port access with authenticated access or ask how to reduce unauthorized device connectivity. Focus on the control point named in the requirement.
Protect remote communication with the right tunnel
Secure communication concepts in the blueprint include VPNs, remote access, TLS, IPsec, SD-WAN, and SASE. These technologies operate at different layers and solve different problems. TLS protects application sessions such as HTTPS. IPsec can protect IP traffic and is commonly used for network-to-network or remote-access VPN designs. SASE combines networking and security functions through a cloud-delivered model.
Understanding how IPsec site-to-site tunnels work helps explain why authentication, key exchange, encryption, and routing all matter to a secure tunnel. A VPN does not automatically make the remote endpoint trustworthy; endpoint posture and authorization still matter.
Choose the secure-access mechanism from the communication requirement rather than from familiarity with a product name.
Protect data according to state and classification
Security architecture is also about data. SY0-701 includes regulated, financial, legal, intellectual-property, sensitive, confidential, restricted, private, public, and critical data classifications. It expects candidates to think about data at rest, in transit, and in use, along with sovereignty and location requirements.
Encryption, hashing, masking, tokenization, obfuscation, segmentation, geographic restrictions, and permission controls protect different properties. Encryption provides confidentiality when keys are protected. Hashing can support integrity verification. Masking and tokenization reduce exposure in applications and non-production environments. Permissions restrict who can access the data in the first place.
The architecture should follow data sensitivity. Applying the same control to public marketing content and regulated customer records is rarely a good risk-based design.
Design for failure, not only prevention
CompTIA includes high availability, load balancing, clustering, hot/warm/cold sites, geographic dispersion, platform diversity, multi-cloud systems, continuity planning, capacity planning, testing, failover exercises, and backups. This makes resilience a security topic because prolonged outage can be as damaging as data theft.
Redundancy must address the failure mode. Two servers in one location do not protect against a regional disaster. A backup stored next to the production system may not protect against the same physical event. A failover plan that is never tested may fail when dependencies, identities, or network routes are missing.
Security architecture therefore includes recovery assumptions from the beginning. Availability is not something to bolt on after the defensive controls are chosen.
Use software-defined controls carefully
Software-defined networking can centralize policy and make network changes programmable, which can improve consistency and automation. It also creates high-value control-plane components whose compromise can affect large portions of the network. The software-defined networking model is useful background for understanding that central control can be both an operational advantage and a concentrated security dependency.
Infrastructure as code has a similar trade-off. Version-controlled templates improve repeatability, but insecure defaults propagate quickly. Secure architecture needs code review, controlled deployment, least-privileged automation identities, and validation after changes.
Automation changes the speed and scale of architecture; it does not eliminate the need for security judgment.
Build designs from trust boundaries and failure modes
For exam practice, start every architecture scenario by drawing three mental maps: where trust changes, where sensitive data moves, and what failures the system must survive. Then choose controls that enforce those boundaries. A firewall belongs where it can filter the relevant path. 802.1X belongs where device access is established. A VPN protects remote communication. Segmentation limits lateral movement. Backups and recovery plans address destructive failure.
The temptation in broad architecture questions is to select the most advanced technology listed. Resist that. The best answer is usually the one that directly satisfies the stated security and availability requirement with the fewest unsupported assumptions.
Secure architecture is successful when prevention, detection, access control, data protection, and resilience reinforce one another. That systems view is exactly what Domain 3 is designed to test.
Design failure behavior as carefully as normal operation
The blueprint explicitly includes fail-open and fail-closed behavior because security controls can fail too. A fail-open control preserves traffic flow when the control is unavailable, which may protect availability but reduce security. A fail-closed design blocks traffic when the control fails, which protects the boundary but can create an outage. The correct choice depends on the system’s safety, availability, and threat requirements.
Device placement has a similar trade-off. An inline IPS can actively block traffic but becomes part of the production path. A passive sensor is less likely to interrupt service but cannot directly stop the packet it observes. Architects should understand whether a control is active or passive, inline or monitoring, and what happens if that device loses power or connectivity.
These choices are especially important in industrial, medical, or other high-availability environments where an outage can have physical consequences. Secure architecture is not simply “block more.” It is choosing failure behavior intentionally so the system remains within acceptable security and operational risk during both normal conditions and faults.
Reduce single points of trust
A secure architecture should avoid giving one identity, network segment, appliance, or management plane unchecked authority over the entire environment. Centralized control can improve consistency, but it must be protected because compromise of that control point can affect many systems at once. Strong authentication, least privilege, logging, segmentation, and resilient management paths reduce that concentration of risk.
This principle applies equally to cloud consoles, directory services, automation platforms, and network controllers. Architecture is safer when the organization understands which components can change policy or reach sensitive assets and gives those components additional protection and monitoring.
Continue exploring the technologies and certification concepts that matter most to you.