Lesson 5 of 12 — Secure Architecture
On-premises and cloud design, virtualization, IoT, ICS, Infrastructure as Code, data classification, redundancy, and high availability — how security is built into systems from the ground up, not bolted on afterward.
In the previous lessons, you identified threats (Lesson 3) and vulnerabilities (Lesson 4). This lesson addresses the foundational question those lessons implied: how do you design systems so they are inherently harder to attack? Secure architecture is the discipline of building security into systems from the beginning — not as an afterthought. A well-architected environment contains an attacker, limits the blast radius of any breach, and recovers automatically from failures before users are impacted.
The Security Architecture domain carries 18% of the Security+ exam and spans an unusually broad range — from the specific security controls of a cloud VPC to the existential safety risks of a compromised water treatment ICS. The thread connecting all of it is a set of principles: separation, segmentation, least privilege, redundancy, and verification at every layer. By the end of this lesson, you will be able to look at an architectural scenario and identify both the risks and the design decisions that mitigate them.
Secure design principles across physical data centers, cloud environments, and virtualized infrastructure — including hypervisor security and container isolation.
On-premises relies on physical perimeter controls + network segmentation. Cloud requires the Shared Responsibility Model: customer owns configuration. Virtualization introduces hypervisor attack surface and VM escape risk. Containers share the host kernel — isolation is lighter than VMs.
The unique security challenges of always-on embedded devices, safety-critical industrial systems, and the transformative role of IaC in automating secure configuration.
IoT devices have weak security, long lifecycles, and no patch cadence — segment and monitor. ICS prioritizes Availability over CIA; Stuxnet proved physical damage is achievable through cyber means. IaC enforces consistent, version-controlled, auditable infrastructure configuration — eliminating "snowflake" servers.
Classifying data to drive appropriate protection levels — plus redundancy, high availability, fault tolerance, and recovery concepts that keep businesses running through failures.
Data classification determines what protection an asset needs. HA and resilience ensure it stays accessible — achieved through redundant power, failover clustering, geo-distributed backups, load balancing, and documented RTO/RPO targets. The architecture must survive component failures without human intervention.
Secure design principles across physical and virtual infrastructure — and where responsibility lies
The first architectural decision — where does this infrastructure live? — determines the entire security model. On-premises environments put you in full control; cloud environments shift some responsibility to the provider. Both models demand deliberate security design, but the attack surface, controls, and ownership differ significantly.
On-premises security begins at the building perimeter and works inward. Defense in depth layers physical controls (badge readers, mantraps, CCTV) with network controls (firewalls, VLANs, IDS/IPS) and logical controls (ACLs, encryption, MFA).
Flat networks are a security anti-pattern — a single compromised endpoint can reach every other system. Segmented architectures contain lateral movement and enforce access control between zones.
Cloud security is a partnership. The provider (AWS, Azure, GCP) is responsible for securing the cloud — physical hardware, hypervisors, global network infrastructure. The customer is responsible for securing what is in the cloud — OS configuration, application code, IAM policies, data encryption, and network controls.
Cloud-native architectures require security controls that match their dynamic, ephemeral nature:
Type 1 (Bare-metal): Runs directly on hardware (VMware ESXi, Hyper-V, Xen). More secure — no host OS attack surface. Used in production data centers and cloud providers.
Type 2 (Hosted): Runs as an application on a host OS (VirtualBox, VMware Workstation). Less secure — host OS vulnerabilities affect all VMs. Used for development and testing.
VM Escape: An attacker who has compromised a guest VM exploits a hypervisor vulnerability to break out and access the host or other VMs. Extremely serious — escaping the VM boundary compromises the entire host's workload.
VM Sprawl: Uncontrolled proliferation of VMs — including forgotten, unpatched VMs that become persistent attack surfaces. Requires inventory management and lifecycle policies.
Containers (Docker, Kubernetes) share the host OS kernel — lighter than VMs but with a smaller isolation boundary. A container escape is less dramatic than a VM escape but still gives access to the host filesystem.
Securing embedded devices, industrial systems, and configuration at machine speed
These three topics represent the expanding frontiers of what "infrastructure" means. IoT brought the internet to every light bulb and thermostat. ICS connects digital controls to physical processes. IaC turned infrastructure configuration into software — with all of software's security implications. Security+ tests all three.
IoT devices are designed for functionality and cost, not security. They are shipped with minimal security features, rarely updated, and typically deployed in large numbers across environments that were not designed to accommodate them.
Standard IT security controls cannot always be applied to IoT devices — you cannot install an EDR agent on a smart thermostat. Security must be implemented at the network and architectural level instead.
Industrial Control Systems manage physical processes — power generation, water treatment, oil pipelines, manufacturing lines, building management. In ICS, a security failure is not just a data breach — it can cause physical harm, environmental damage, or loss of life.
Security in OT/ICS environments must be adapted to the operational constraints — controls that would be standard in IT can cause outages in ICS.
Before IaC, infrastructure was configured manually — leading to "snowflake servers" (unique configurations that no one fully understood), configuration drift (servers that slowly diverge from their intended state), and undocumented changes that created vulnerabilities.
Common IaC platforms tested on Security+:
Example IaC security pattern — S3 bucket with encryption enforced:
Protecting the right data the right way — and building systems that stay up when components fail
Not all data deserves the same protection. Applying top-secret-level controls to a public press release wastes resources; applying public-level controls to financial records invites breach. Data classification aligns protection cost with data value. Resilience architecture ensures classified data remains available to authorized users even when individual components fail.
Government/Military Classification — used by federal agencies and defense contractors (DoD 5200.01):
Unauthorized disclosure could cause exceptionally grave damage to national security. Access requires TS clearance + Special Access Program (SAP) authorization. Examples: nuclear weapon designs, intelligence collection methods.
Unauthorized disclosure could cause serious damage to national security. Requires Secret clearance. Examples: military operational plans, diplomatic cables, foreign intelligence reports.
Unauthorized disclosure could cause damage to national security. Requires Confidential clearance. Examples: personnel records, unclassified intelligence with sensitive source information.
No classification required. Safe for public release. Examples: press releases, published research, public-facing websites.
Commercial/Corporate Classification — used in private sector organizations:
Highest sensitivity. Disclosure would cause severe competitive or legal harm. Examples: trade secrets, M&A plans, source code, cryptographic keys, cardholder data (PCI), PHI (HIPAA), SSNs.
For use by employees only. Disclosure would be inappropriate but not catastrophic. Examples: internal policies, project plans, salary data, employee performance reviews, internal IP addresses.
Requires protection but is shared with partners, contractors, or approved third parties. Examples: contracts, financial statements shared with auditors, partner integration credentials.
Safe for unrestricted distribution. No access control required. Examples: marketing materials, job postings, published documentation, public APIs.
High availability is measured and contractually specified as a percentage of annual uptime. Understanding the nines is essential for architecture decisions:
Five nines (99.999%) is the gold standard for telecom and critical infrastructure — it allows only ~5 minutes of downtime per year. Each additional nine requires exponentially more redundancy and typically costs an order of magnitude more to achieve.
Redundancy eliminates single points of failure by duplicating critical components:
Load balancers distribute traffic across multiple backend servers — providing both performance and resilience:
Two critical metrics define what an organization can tolerate in a disaster:
The industry-standard backup rule that ensures recoverability even in worst-case scenarios:
Modern extension: 3-2-1-1-0 — adds 1 immutable/offline copy (air-gapped, ransomware-proof) and 0 errors verified through regular restore testing. Backups that have not been tested are not backups — they are assumptions.
Classify each security concept or control into its correct architecture environment
Select a business scenario and answer architecture questions to build the right resilience solution
Select the best answer for each question, then submit for graded feedback
variables.tf file and committed to the public GitHub repository. What is the MOST immediate security action required?