Objective 3.1: Compare and contrast security implications of different architecture models

Cert: CompTIA Security+ (SY0-701) Domain: 3.0 Security Architecture Weight: ~18% of SY0-701 (Domain 3 total) Depth: Compare and contrast. Be able to name each architecture model, list the security trade-offs (confidentiality, integrity, availability), and choose the right model for a given scenario.

What this objective tests

You should be able to look at a one-paragraph scenario, name the architecture in play (cloud, on-prem, hybrid, IaC, serverless, microservices, virtualization, containerization, IoT, ICS/SCADA, RTOS/embedded), and explain the security implications in plain English. The exam loves "given a scenario" questions on this objective. You will see prompts about responsibility matrices, segmentation choices, availability requirements, and patching constraints. The skill is matching the architecture to the trade-off, not memorizing every vendor.

Key facts

Cloud architecture

Cloud is on-demand compute, storage, and network delivered over the internet by a provider like AWS, Azure, or Google Cloud. NIST SP 800-145 is the foundational definition. Three service models matter for the exam.

The shared responsibility model is the single most testable cloud concept. The line between customer and provider moves with the service model. IaaS leaves the customer responsible for almost everything above the hypervisor. SaaS leaves the customer responsible only for data and user identity. The misread that breaks real customers is assuming the provider patches the guest OS in IaaS. They do not. You do.

Hybrid cloud combines on-prem with one or more cloud providers, usually with a VPN or a dedicated circuit between them. The security trade-off is surface area. You now have two control planes to harden, two identity stores to keep in sync, and two patch programs to run. The win is flexibility and DR options. The cost is operational complexity.

Third-party vendor risk is a real exam topic. Every cloud and SaaS contract is a supply-chain decision. NIST SP 800-161 covers C-SCRM (Cybersecurity Supply Chain Risk Management). The minimum gates: SOC 2 Type II report, written shared-responsibility matrix, breach-notification clause, right-to-audit, and a data-deletion clause at contract end.

Infrastructure as Code (IaC)

IaC is the practice of describing infrastructure in version-controlled text files (Terraform, CloudFormation, Bicep, Pulumi, Ansible) and applying those files with a runner. Servers, networks, firewalls, and IAM roles all live as code in a Git repo. Apply the file, the cloud provider builds the matching resource. Delete the file, the resource goes away.

Security wins. Drift is detectable. Two reviewers can see every change. Rollback is a Git revert. Auditors can read the repo and know exactly what is deployed.

Security risks. A leaked Terraform state file can expose secrets. A typo in a Bicep template can drop a firewall rule and open the network. CI/CD pipeline credentials become high-value targets. CIS Controls v8 Control 16 (application software security) covers the IaC review gate. NIST SP 800-218 (Secure Software Development Framework, SSDF) gives the secure-coding scaffolding.

Serverless

Serverless removes the server from the developer's job. AWS Lambda, Azure Functions, and Google Cloud Functions run code in response to an event (an HTTP request, a queue message, a file upload). You pay for the milliseconds the code runs. The cloud provider runs the OS, the container, the runtime, and the autoscaling.

Security implications. The attack surface shrinks (no OS to patch, no long-running server to compromise) but new risks appear. Cold-start timing leaks side-channel data. Event-injection attacks come from any input source the function reads. The IAM role attached to the function becomes the new perimeter: over-privileged functions are the most common serverless finding in pen tests. Logging is harder because the function disappears when it finishes. CloudTrail, CloudWatch, and X-Ray (or the Azure or GCP equivalents) become non-negotiable.

Microservices

Microservices split a monolithic application into small, independently deployable services that talk over the network using HTTP or gRPC. Each service has its own database, its own deploy schedule, and its own team. Netflix and Amazon Prime are the textbook examples.

Security wins. A compromise of one service does not own the whole platform. Each service can have its own least-privilege IAM role. Blast radius is bounded.

Security risks. The east-west traffic between services becomes the new perimeter. Service-to-service authentication must be solved (mTLS, SPIFFE/SPIRE, signed JWTs). API gateways become high-value targets. Distributed tracing becomes mandatory for incident response. NIST SP 800-204 (security strategies for microservices) is the canonical reference.

Network infrastructure

Two big choices: physical isolation versus logical segmentation, and traditional versus software-defined.

Physical isolation (air-gapped). Two networks with no cable between them. The classified network is in one building, the corporate network is in another, and a human carries USB drives between them under chain of custody. Used for classified workloads, OT (operational technology) at high-impact ICS sites, and certain HIPAA boundaries. Pros: strongest possible isolation. Cons: expensive, hard to update, easy to undermine when humans get sloppy (Stuxnet jumped air gaps via USB).

Logical segmentation. VLANs, ACLs, and host firewalls split the network into zones even when they share cables. Cheaper than air-gap, easier to update, weaker isolation. The standard mid-market answer.

Software-Defined Networking (SDN). The control plane is centralized in a controller. The data plane lives in switches. Network configuration becomes API calls instead of CLI changes. NIST SP 800-207 (Zero Trust) leans heavily on SDN to enforce policy at the packet level. The win is consistency. The risk is a single controller compromise affecting the whole fabric.

On-prem vs cloud

The exam scenario usually asks "which is the better fit for X." Match the requirement to the trait. Strict data residency law plus low-trust regulator equals on-prem or sovereign cloud. Bursty workload with thin IT team equals public cloud. Anything in between is hybrid.

Centralization vs decentralization

A centralized architecture funnels traffic, identity, and policy through one place (an SSO provider, a primary data center, a single Active Directory forest). A decentralized architecture spreads those across multiple sites or providers.

Centralization wins: consistent policy, simpler audit, easier incident response. Centralization risk: single point of failure, single juicy target.

Decentralization wins: blast radius is bounded, regional outages do not take the whole company down. Decentralization risk: policy drift, harder to audit, more identity stores to compromise.

Most enterprises run a hub-and-spoke compromise: centralized identity, decentralized compute. The exam will test whether you can name the trade-off without being asked which is "right."

Virtualization

Virtualization runs multiple guest operating systems on one physical host through a hypervisor. Type 1 hypervisors (ESXi, Hyper-V, KVM) sit on bare metal. Type 2 hypervisors (VirtualBox, VMware Workstation) sit on top of a host OS. VM (Virtual Machine) escape is the canonical attack: code running in a guest reaches the hypervisor and then other guests. Real but rare. Patching the hypervisor is the single most important mitigation. NIST SP 800-125 covers virtualization security.

Snapshot sprawl is a quieter risk. An old snapshot of a Windows 7 VM left for a year and powered back on can reintroduce vulnerabilities the rest of the fleet patched out long ago. Treat snapshot lifecycle as a security control.

Containerization

Containers package an app and its dependencies into one immutable image and run it on a shared OS kernel. Docker is the default tooling. Kubernetes is the orchestrator. Containers are lighter than VMs, start in seconds, and pack denser on a host.

NIST SP 800-190 (Application Container Security Guide) is the canonical reference. The five risks to know: image vulnerabilities, image misconfigurations (running as root, no resource limits), registry compromise, orchestrator weakness (Kubernetes API exposed without auth), and host OS hardening gaps. CIS Benchmarks for Docker and Kubernetes cover the technical baseline.

Containers share the kernel. A kernel vulnerability is a multi-tenant risk. This is why high-isolation workloads use sandbox runtimes like gVisor or Kata Containers that put a thin VM around each container.

IoT (Internet of Things)

IoT devices are general-purpose enough to run code but small enough that traditional endpoint protection does not fit. Smart thermostats, IP cameras, smart TVs, fitness trackers. Common security gaps: default credentials, unencrypted communication, no patch program, hardcoded keys in firmware, shared cloud accounts across an entire product line.

The standard mitigation is network segmentation. Put IoT on its own VLAN with no path to the user or server VLANs. Apply a deny-by-default firewall rule. Watch DNS for callbacks. NIST IR 8259 series covers IoT device security baselines.

Mirai is the classic case study. The botnet built from default-password IP cameras and DVRs, then ran the largest DDoS attack in history at the time. Every Sec+ student should know the name.

ICS/SCADA (Industrial Control Systems / Supervisory Control And Data Acquisition)

ICS runs the physical world: power plants, water treatment, oil refineries, manufacturing lines, building HVAC. PLCs (Programmable Logic Controllers), RTUs (Remote Terminal Units), HMIs (Human-Machine Interfaces), and SCADA servers make up the stack. The OT (operational technology) side prioritizes availability and safety above confidentiality. The IT side reverses that priority. The clash is a constant source of incidents.

NIST SP 800-82 (Guide to Operational Technology Security) is the canonical reference. Key facts:

• Patch windows are measured in months or years, not days. Bringing a plant down costs millions.
• Many ICS protocols (Modbus, DNP3, Profinet) were designed for trusted serial lines and have no authentication.
• Air gaps are a goal but rarely achieved. Engineering laptops, vendor jump hosts, and USB drives bridge the gap.
• The Purdue Model is the standard segmentation reference. Levels 0 through 5 separate the plant floor from corporate IT. Each boundary needs a firewall and unidirectional gateways where appropriate.

Stuxnet (Iran, 2010), Industroyer (Ukraine, 2016), and Triton/Trisis (Saudi Arabia, 2017) are the textbook ICS attacks. Each one breached an air gap and reached PLCs.

RTOS and embedded systems

An RTOS (Real-Time Operating System) is a small, deterministic OS used where missing a deadline is unacceptable. Avionics, medical devices, automotive control units, robotic arms. VxWorks, QNX, and FreeRTOS are common. Embedded systems are the broader category: any computer purpose-built into a larger product.

Security implications. The OS is often stripped down with no MMU (memory management unit) protection, no user separation, and limited logging. Patching usually requires a vendor-signed firmware image and a maintenance window measured in months. Many embedded devices ship with credentials in the binary itself. CIS Controls v8 and ISA/IEC 62443 (industrial automation and control systems security) are the operating references.

High availability (HA) considerations

HA is the design discipline that keeps the service up when individual parts fail. The CIA letter at stake is Availability. HA shows up across every architecture in the objective.

Mean Time Between Failures (MTBF), Mean Time To Repair (MTTR), Recovery Time Objective (RTO), and Recovery Point Objective (RPO) are the numbers on every HA design review. NIST SP 800-34 (Contingency Planning Guide) covers the planning side.

Common gotchas

• Confusing shared responsibility across service models. IaaS leaves you the guest OS, the network stack inside the VM, and the apps. SaaS leaves you the data and the user identity. Mixing those up loses easy exam points.
• Calling hybrid cloud a synonym for multi-cloud. Hybrid is on-prem plus cloud. Multi-cloud is two or more public clouds. They overlap but are not the same.
• Treating serverless as inherently more secure. Less OS to patch is real. But the IAM role on the function is the new perimeter, and over-privileged function roles are the most common finding in serverless audits.
• Thinking microservices are automatically segmented. The services share a network. Without mTLS or a service mesh, east-west traffic is a flat plane.
• Calling air gap "perfect isolation." Stuxnet jumped one. So did Industroyer. USB drives, engineering laptops, and vendor jump hosts undo air gaps every quarter.
• Mixing virtualization with containerization. Virtualization runs a full guest OS per VM. Containers share the host kernel. The boundary is different, the patch obligation is different, the multi-tenant blast radius is different.
• Treating ICS like IT. Patching during the day, deploying agents that need internet access, and assuming default usernames have been changed will all break things in OT. Treat OT as its own discipline with availability as the top CIA letter.
• Skipping the RTOS depth. The exam asks scenario questions about devices that "must respond within strict timing." That is the RTOS keyword. Match it.
• Mixing centralization with single-points-of-failure. Centralization is a design choice. Single-points-of-failure are a consequence to mitigate (active-passive pairs, geographic redundancy, anycast IPs).
• Skipping HA on the architecture question. Every architecture has an availability trade-off. The exam will ask you to pick the design that meets a specific RTO. Read the RTO before picking the design.

Real-world context

In a SOC Tier 1 analyst seat, this objective shows up the moment an alert names the wrong layer. A "high CPU on web-01" ticket in a microservices stack is rarely about web-01 by itself. The analyst pivots: is the upstream API gateway under attack, is a downstream service slow and back-pressuring the front end, is the autoscaler asleep. The architecture model decides where the investigation goes next.

A cloud account-compromise ticket is the other common one. IAM role enumeration in CloudTrail, console sign-in from an unusual IP, a new access key created and used within 60 seconds. The analyst's playbook depends on whether the workload is IaaS (rotate keys, snapshot the VM, look at the guest OS), PaaS (rotate keys, review the app config, check the data plane), or SaaS (rotate keys, run admin audit logs, force MFA reset). Three different responses for one alert pattern. The architecture model picks which one runs.

ICS/SCADA tickets are rare for a Tier 1 SOC but career-defining when they show up. The standard call is to the OT engineer on call before any containment action. Pulling a PLC offline at the wrong time can stop a production line and cost six figures. The Sec+ student who knows this from day one will not be the analyst who shuts down a turbine while trying to be helpful.

Sample alert walkthrough. SIEM fires "Anomalous outbound DNS from VLAN 60 (IoT) to a domain registered 48 hours ago." Tier 1 reads the ticket and immediately knows three things: VLAN 60 is the segmented IoT zone (architecture rule held), the freshly registered domain is the standard indicator of C2 callbacks (Mirai-family behavior fits), and the response is to block the domain at the resolver, snapshot the VLAN traffic for 24 hours, and put the device on the next replacement list (no patching pipeline exists for that camera model). Three minutes of analysis, all rooted in knowing the architecture.

Sources

• CompTIA Security+ SY0-701 Exam Objectives, Section 3.1
• NIST SP 800-145, The NIST Definition of Cloud Computing
• NIST SP 800-207, Zero Trust Architecture
• NIST SP 800-190, Application Container Security Guide
• NIST SP 800-82r3, Guide to Operational Technology (OT) Security
• NIST SP 800-125, Guide to Security for Full Virtualization Technologies
• NIST SP 800-204, Security Strategies for Microservices-based Application Systems
• NIST SP 800-161r1, Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-218, Secure Software Development Framework (SSDF)
• NIST SP 800-34, Contingency Planning Guide for Federal Information Systems
• NIST IR 8259 series, IoT Device Cybersecurity Baseline
• CIS Controls v8 (especially Controls 4, 12, and 16)
• ISA/IEC 62443, Industrial Automation and Control Systems Security
• CISA Cloud Security Technical Reference Architecture