Security Implications of Architecture Models
Compare and contrast cloud, on-prem, serverless, microservices, IoT, ICS/SCADA — and the considerations (cost, resilience, patchability, power) that drive the choice.
Architecture is where you decide what gets protected, by whom, and how — before a single attack lands. Every Domain 3.1 question boils down to matching an architecture model (cloud IaaS/PaaS/SaaS, on-prem, serverless, microservices, ICS/SCADA, IoT) to a real-world constraint: availability, patchability, cost, sovereignty, or latency.
Three mental hooks carry most questions: (1) the shared-responsibility matrix — who patches what — shifts sharply between IaaS, PaaS, and SaaS. (2) What you cannot patch you must isolate — the organizing principle for IoT, embedded, ICS/SCADA, and legacy systems. (3) Complexity grows the attack surface — microservices, hybrid cloud, and multi-cloud buy resilience but add identity, network, and supply-chain exposure you must manage. Architecture is a tradeoff exercise, not a right-answer exercise.
Cloud service models (IaaS / PaaS / SaaS). The responsibility matrix is the central idea. The provider is responsible for security of the cloud (physical, hypervisor, service runtime); the customer is responsible for security in the cloud (their data, identities, and configuration). The split moves with the service model. IaaS: customer owns OS patching, apps, and data. PaaS: provider handles OS and runtime; customer owns code, config, and data. SaaS: provider handles almost everything except identity, config, and data. Hybrid cloud mixes on-prem and cloud — federation, data gravity, latency, and egress cost become primary concerns. Third-party vendors introduce supply-chain and vendor-risk considerations regardless of service model.
Infrastructure as Code (IaC). Infrastructure defined in version-controlled code (Terraform, CloudFormation, Bicep, Pulumi). The security upside: consistent baselines, peer review, drift detection, rapid rollback. The security downside: secrets leak in repos, and a misconfigured template replicates bad configuration at cloud scale in seconds. Treat IaC repos like production: secret scanning, SAST on templates, and tight branch protection.
Serverless (Functions as a Service). The provider runs the compute runtime — Lambda, Azure Functions, Cloud Functions. No OS to patch; no servers to harden. The customer still owns code quality, IAM, dependency security, secrets, and input validation. The short-lived execution model makes persistent footholds harder for attackers but also makes traditional host-based monitoring impractical — you rely on provider logs and distributed tracing.
Microservices. Many small services communicating over APIs. Security shifts from a single app boundary to a mesh: per-service identity, mutual TLS (mTLS), API gateways, and least privilege on service-to-service calls. The attack surface expands because every endpoint is reachable.
Network infrastructure. Physical isolation / air-gap is the strongest control — no network path at all. Used in classified, nuclear, and some OT environments. Logical segmentation (VLANs, subnets, microsegmentation) separates traffic without physical isolation. Software-defined networking (SDN) decouples the control plane from the data plane, letting networks be programmed centrally — powerful, but the controller becomes a high-value target.
On-premises. Full control, full cost. You patch, power, cool, and monitor every layer. Common for ultra-low-latency (trading) and strict-residency workloads.
Centralized vs. decentralized. Centralized security (one team owns the stack, one policy) trades agility for consistency. Decentralized (business units own their own security) trades consistency for speed. Most enterprises land on a hybrid: a central policy/control-plane with federated execution.
Containerization. Docker/Kubernetes. Containers share the host kernel, which makes their isolation boundary weaker than a VM. Required practices: image scanning, signed images, pod security standards, runtime monitoring, and least-privileged service accounts.
Virtualization. Hypervisor-based isolation. Type 1 hypervisors run on bare metal (ESXi, Hyper-V); Type 2 hypervisors run on a host OS (VirtualBox). Stronger isolation than containers; VM escape is rare but catastrophic.
IoT. Constrained devices — sensors, cameras, thermostats. Often no patching path, long lifecycles, default credentials, weak or no TLS. Security story is segmentation and monitoring because you cannot fix the device.
Industrial Control Systems / SCADA. Operational-technology environments running physical processes (power, water, manufacturing). Characterized by legacy protocols, no encryption, 10-20 year lifecycles, and patching windows measured in years. Controls: air gaps, unidirectional gateways (data diodes), strict network segmentation, compensating monitoring.
Real-time operating system (RTOS). Deterministic scheduling for safety-critical systems — medical devices, automotive, aerospace, industrial controllers. Minimal attack surface by design, but bugs here can kill people, so patching often requires certification cycles.
Embedded systems. Firmware-driven devices — the update cadence (or lack of it) is the security story. Without a reliable update path, a vulnerability is permanent.
High availability (HA). Redundant components and automatic failover, so a single failure does not take the service down. HA addresses failure within a datacenter; disaster recovery (see 3.4) addresses loss of the datacenter.
| Layer | On-prem | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Physical / Facility | Customer | Provider | Provider | Provider |
| Network / Virtualization | Customer | Provider | Provider | Provider |
| OS / Patching | Customer | Customer | Provider | Provider |
| Runtime / Middleware | Customer | Customer | Provider | Provider |
| Application code | Customer | Customer | Customer | Provider |
| Identity / Access | Customer | Customer | Customer | Customer |
| Data / Config | Customer | Customer | Customer | Customer |
| Consideration | What it means | Exam cue |
|---|---|---|
| Availability | Uptime, failover, MTTR | “24/7 trading” → HA + active/active |
| Resilience | Absorb and recover from disruption | “Survive a regional outage” → multi-region |
| Cost | Capex vs. opex, egress fees | “Unpredictable workload, minimal ops” → serverless |
| Responsiveness | Latency, throughput | “Sub-millisecond latency” → on-prem or edge |
| Scalability | Horizontal/vertical, auto-scale | “Unknown traffic spikes” → cloud autoscaling |
| Ease of deployment | IaC, immutable images | “Consistent provisioning” → IaC |
| Risk transference | Shift some risk to provider/insurer | “Reduce operational burden” → managed services |
| Ease of recovery | Snapshots, region failover | “Short RTO, cross-region” → cloud DR |
| Patch availability | Vendor cadence | Needs consistent update path |
| Inability to patch | OT/IoT/legacy cannot be patched | → Isolate + monitor (compensating) |
| Power | UPS, generator, dual feed | On-prem / colo considerations |
| Compute | CPU/GPU planning | AI/HPC = dedicated capacity |
Two levers drive most 3.1 answers: (1) the responsibility split (who patches what), and (2) patchability (if you cannot patch it, isolate it). Everything else — cost, latency, resilience — is a tiebreaker between otherwise-valid architectures.
A 320-bed hospital runs a 2008-era MRI scanner whose control console is a Windows 7 workstation the vendor no longer patches. The console sits on the clinical VLAN and shares a broadcast domain with workstations, infusion pumps, and a segment of radiology servers. The vendor’s official answer: “We do not support patching the console. Replacement cost is $1.9M and we are five years out from end-of-support on the scanner itself.” The CIO wants to move fast; the Cloud Architect pushes back.
Unpatchable Medical Device on a Flat Network
Hospital · unsupported OS · $1.9M to replaceWhen you cannot patch, you isolate and monitor. The exam calls this a compensating control. On medical, OT, and embedded systems, the three-step pattern is: (1) put the device on its own segment, (2) allow only the minimum protocols to/from the minimum peers, (3) monitor for any deviation from baseline. If you must keep the system running, that is the architecture answer.
Most of your architecture battles will be budget battles. “Inability to patch” is rarely a technical issue — it is a vendor-support, regulatory, or capex issue. The Security+ exam tests whether you recognize the pattern and propose the right compensation, not whether you can magically replace every legacy system.
On the exam: “cannot patch” → segmentation + compensating monitoring. Do not pick “replace the system” if the scenario says the replacement budget is not available.
A four-person startup is launching a consumer app with unpredictable traffic. They have no ops team. Compliance is light (no HIPAA, no PCI). Leadership wants to minimize what the team has to patch or monitor. Which architecture is the better fit?
IaaS virtual machines with auto-scaling
Classic cloud IaaS — customer manages the OS, the runtime, the app, and auto-scaling groups.
Serverless functions + managed database
FaaS for compute, a managed DB service, and managed identity. Provider owns OS, runtime, and scaling.
Option B fits better — serverless shifts the ops burden to the provider
Option B: With no ops team and unpredictable traffic, serverless wins on two dimensions: (1) the provider handles OS patching, runtime upgrades, and scaling — the customer only owns code, IAM, and data; (2) FaaS is billed per-invocation, which matches unpredictable traffic without idle compute cost. The team still has real security work — secret management, IAM least privilege, dependency hygiene — but the operational patching treadmill is gone.
Option A’s kernel of truth: IaaS gives you more control and is the right answer for workloads that cannot run in ephemeral FaaS (long-running, specialized compute, deep OS customization). But a four-person startup with no ops team buying themselves an OS-patching job is exactly the anti-pattern 3.1 tests.
On the exam: “no ops team” or “minimal operational burden” is the serverless/SaaS cue. “Ultra-low latency,” “specialized OS,” or “must control the runtime” flips the answer back to IaaS or on-prem.
3.1 questions test two things: (1) which architecture fits the scenario’s constraints (latency, cost, ops burden, compliance), and (2) where the responsibility line falls in that architecture. The trap answer is usually the one that tries to solve an architectural problem with a technical control the architecture does not support (e.g., “patch the unpatchable device” or “secure the SaaS runtime”).
- A The customer, because customers always patch their own SaaS
- B The provider, because storage and platform layers are provider-owned in SaaS
- C Neither — SaaS breaches are unowned shared risk
- D The customer, because customers own data at rest encryption
Correct: B. In SaaS, the provider owns the platform, runtime, and storage layers. Customers own identity, configuration, and data — but not the underlying platform infrastructure.
A wrong: Customers do not patch SaaS. They patch on-prem, and patch the OS in IaaS.
C wrong: The matrix assigns responsibility; nothing is unowned.
D wrong: Customer-managed keys for data at rest can exist, but the storage-layer breach described is a platform failure.
Source: CompTIA SY0-701 Objectives v5.0 — 3.1 Architecture Models
- A Deploy signature-based AV on every PLC
- B Place PLCs on a segmented OT network with a unidirectional gateway and continuous monitoring
- C Expose PLCs to the internet over a VPN for vendor remote management
- D Move the PLCs to a public cloud IaaS environment
Correct: B. Isolation (segmented OT zone), one-way data flow (diode), and compensating monitoring are the textbook approach for unpatchable ICS/SCADA.
A wrong: PLCs typically cannot host AV agents; even if they could, signature AV does not address the architectural issue.
C wrong: Exposing unpatchable systems to the internet is the opposite of isolation.
D wrong: PLCs control physical processes and typically cannot be virtualized to cloud without loss of real-time guarantees.
Source: CompTIA SY0-701 Objectives v5.0 — 3.1 Architecture Models
- A Hypervisor escape attacks on the cloud provider
- B Physical tampering with datacenter hardware
- C A misconfigured template rapidly deploys bad configuration at scale; secrets can leak in the repo
- D Insider theft of backup tapes
Correct: C. IaC’s strength (repeatability, scale) is also its risk profile: one bad template replicates bad config; secrets committed to a repo leak credentials at scale. Mitigations: secret scanning, SAST on templates, peer review, branch protection.
A, B, D wrong: These risks exist but are not specific to IaC — they apply across most architectures.
Source: CompTIA SY0-701 Objectives v5.0 — 3.1 Architecture Models