Compare and contrast security implications of different architecture models
Cloud, IaC, serverless, microservices, on-prem, virtualization, IoT, ICS/SCADA, and embedded systems.
- Reading time
- 28 min read
- Flashcards
- 16 cards
- Practice questions
- 8 questions · 2 PBQs
A broad objective covering where systems can live and what each choice costs you in security terms. The exam asks you to weigh models against each other, so learn the trade-offs, not just the definitions.
Cloud
Shared responsibility matrix
Who secures what. The provider secures of the cloud — hardware, hypervisor, physical facility. You secure in the cloud — your data, access configuration, and application. The dividing line moves with the service model.
| Model | Provider secures | You secure |
|---|---|---|
| IaaS | Hardware, hypervisor, network | OS, runtime, application, data |
| PaaS | All of the above plus OS and runtime | Application and data |
| SaaS | Nearly everything | Your data and who can access it |
Hybrid combines on-premises and cloud, which means two environments to secure and a connection between them. Third-party vendors introduce the supply chain risk from 2.2 and 5.3.
Infrastructure as code
IaC defines infrastructure in version-controlled files rather than by clicking. The security benefits are real: consistent deployment, reviewable changes, and a rollback path. The risk is equally real — a mistake in the template is deployed everywhere at once, and secrets committed to the repository are exposed at scale.
Serverless
Code runs without you managing servers. The provider handles the OS entirely, which removes your patching burden and shrinks your attack surface. In exchange you get vendor lock-in and less visibility into what is happening underneath.
Virtualisation vs containerisation
Virtual machines
- Each VM has its own full OS
- Strong isolation via the hypervisor
- Heavier — minutes to start, gigabytes
Containers
- Share the host OS kernel
- Weaker isolation — shared kernel is the boundary
- Light — seconds to start, megabytes
The tellContainers share a kernel, VMs do not. That single fact explains both the speed advantage and the weaker isolation.
VM escape (2.3) breaks the hypervisor boundary; container escape breaks the shared-kernel boundary, and the latter is a smaller wall.
Network architecture
Air gap / physical isolation
No network connection at all. The strongest isolation available, and the reason it is used for classified and industrial systems — but data still moves by removable media, which is exactly the vector from 2.2.
Logical segmentation
Separation by VLANs and routing rather than physical wiring. Flexible and far cheaper, but a misconfiguration can silently remove the separation.
Software-defined networking (SDN)
Network control separated from the forwarding hardware and managed centrally. Enables rapid, policy-driven reconfiguration — and concentrates control, so the SDN controller becomes a very high-value target.
Check yourself
A defence facility keeps a classified network entirely disconnected from any other network. What is the main residual risk?
Constrained systems
These recur throughout the exam and share one property: you usually cannot patch them.
- IoT — often shipped with default credentials and no update mechanism
- ICS/SCADA — industrial control; availability outranks confidentiality
- RTOS — real-time operating systems with hard timing requirements
- Embedded — purpose-built, long-lived, rarely updated
The answer for all of them is the same as 4.1: isolate and monitor.
On-premises vs cloud, centralised vs decentralised
On-premises
- Full control and custody
- You carry all the cost and effort
- Capacity is what you bought
Cloud
- Scalable, someone else's hardware
- Risk transference to the provider
- Less visibility, vendor dependency
The tellCloud transfers some risk and effort to the provider. It never transfers accountability for your data.
Centralised architecture is consistent and easier to secure but is a single point of failure. Decentralised is resilient but harder to govern uniformly — the same trade-off as governance structures in 5.1.
The considerations CompTIA lists
When comparing models, weigh: availability, resilience, cost, responsiveness, scalability, ease of deployment, risk transference, ease of recovery, patch availability, inability to patch, power, and compute.