Architecture Models

One question decides almost every item in this objective: after you pick this model, which security controls must you still implement, and which did you inherit? On-prem, IaaS, SaaS are just names for different answers to it. SY0-701 Objective 3.1 asks you to "compare and contrast security implications of different architecture models"^[1]. The verb is compare, not configure.

On-premises: you own everything

In a traditional on-premises data center your organization owns and must secure the entire stack: the building and its physical access controls, the power and HVAC, the network hardware, the hypervisor, every guest operating system, the applications, and the data. Nothing is inherited. This gives maximum control and visibility (you can run any agent, capture any log, and inspect any packet) at the cost of maximum burden: every CVE is your patch to apply and every locked door is your expense. On-premises is the right answer when a scenario stresses data sovereignty, regulatory custody, full forensic visibility, or air-gapped isolation that a public cloud cannot offer.

Cloud: the shared-responsibility matrix

Moving to cloud does not delete those responsibilities. It splits them along a documented shared-responsibility model. A useful framing is "security of the cloud" (the provider's job: the physical facilities, the host hardware, and the virtualization layer) versus "security in the cloud" (the customer's job: data, identity and access management, and configuration). AWS states the customer is always responsible for "customer data" and for "identity and access management," while AWS operates and controls "the components from the host operating system and virtualization layer down to the physical security of the facilities" (AWS Shared Responsibility Model^[2]). Microsoft frames the same split: in all cloud models the customer always retains responsibility for data, devices, accounts, and identities (Microsoft shared responsibility in the cloud^[3]). Two facts survive every model: the provider always secures the physical layer, and you always own your data and your access management.

Where the line sits depends on the service model

The cloud service models (defined in NIST SP 800-145, The NIST Definition of Cloud Computing^[4]) decide how far up the stack the provider's responsibility reaches. The layered stack below is the canonical shared-responsibility matrix that both AWS and Microsoft publish: read each column as one model and watch the boundary line climb the stack as the provider takes on more.

Service model	Provider secures	Customer secures
IaaS (infrastructure)	Facility, host, hypervisor, network fabric	Guest OS and patching, runtime, app, data, IAM, config
PaaS (platform)	Everything up to and including the runtime/OS	Application code, data, and access management
SaaS (software)	Nearly the entire stack	Data, identities/accounts, and sharing/config settings

The rule of thumb: the more the provider manages, the smaller your patchable surface, and the smaller your visibility into it. With SaaS you cannot install an endpoint agent on the provider's servers; your dominant control becomes identity and configuration hygiene. Hybrid clouds and third-party vendors add a third dimension: each interconnection between estates is a trust boundary you must secure, and outsourcing operations never outsources accountability. The data owner remains legally and contractually responsible for the data even when a vendor processes it.

Beyond on-prem-vs-cloud, Objective 3.1 enumerates specific runtime and topology models, each with a signature trade-off. The runtime models form an isolation spectrum, from virtualization down to serverless, where stronger isolation trades off against a smaller, less visible host surface; the figure above lays out each model's isolation boundary and its signature attack surface.

Virtualization vs. containerization

Virtualization runs multiple guest VMs on one physical host via a hypervisor; each guest carries its own full OS, giving strong isolation. The new attack surface is the hypervisor itself: a VM escape (breaking out of a guest into the host or a sibling VM) can compromise every co-resident workload, and VM sprawl plus dormant/snapshotted VMs create unpatched, unmonitored assets.

Containerization isolates at the OS level: containers share the host kernel and package only the app plus its dependencies. They are far lighter and start in milliseconds, but because the kernel is shared, isolation is weaker than a VM. A kernel exploit or container escape has a larger blast radius, and pulling untrusted or unscanned images introduces supply-chain risk. The exam contrast: choose virtualization when you need stronger isolation between tenants; choose containers when you need density, portability, and fast scaling and can manage image and kernel hygiene.

Serverless

Serverless (function-as-a-service) removes the server from your view entirely: the provider patches and scales the host and runtime, and you supply only function code plus its permissions. Your patchable surface shrinks to your code and its dependencies, but you lose host-level visibility: no agent, no host logs. The dominant risks become over-permissive execution roles (a function granted far more than it needs), insecure dependencies, and event-source injection.

Microservices

Decomposing a monolith into independently deployable microservices improves fault isolation and lets teams deploy and scale services separately, which contains blast radius. The security cost is an explosion of east-west (service-to-service) traffic: many more network connections, API endpoints, and authentication boundaries to defend. Each service-to-service call must be authenticated and authorized, pushing you toward mutual TLS and zero-trust segmentation internally.

Network infrastructure, SDN, and IaC

Network infrastructure spans the physical (cabling, switches, the data center) and the software-defined (SDN), which separates the control plane from the data plane so policy is programmed centrally. SDN enables rapid, consistent, centralized policy but makes the SDN controller a single high-value target: compromise it and you reprogram the whole network. Infrastructure as Code (IaC) defines servers, networks, and policy in version-controlled templates so environments are reproducible and auditable. The flip side: a single mistake (an over-permissive rule, a hardcoded secret in a template, or unreviewed drift) propagates to every environment the template builds, so IaC must be paired with template scanning and secrets management.

Centralized vs. decentralized

A centralized architecture (one management plane, one identity provider, one chokepoint firewall) makes consistent policy, patching, and monitoring easy but concentrates risk into a single point of failure and a prize target. A decentralized architecture spreads control out, improving resilience and limiting blast radius, but makes uniform policy enforcement and complete visibility much harder. Neither is "more secure." The exam wants you to map the choice to the scenario's stated priority (consistency and simplicity vs. resilience and autonomy).

This cluster of models inverts the normal IT instinct to patch fast and encrypt everything, and it is heavily tested. The figure above groups the constrained or unpatchable systems (IoT/embedded/RTOS, ICS/SCADA, and air-gapped networks) that share one controlling strategy, compensating isolation rather than hardening the device, and shows high availability as a separate model addressing the availability leg instead.

IoT and embedded systems / RTOS

Internet-of-Things devices, embedded systems, and real-time operating systems (RTOS) are resource-constrained: limited CPU, memory, and power mean weak or no on-device cryptography, no room for an endpoint agent, and frequently no update mechanism at all. They commonly ship with default or hardcoded credentials, expose insecure management protocols, and run vendor-locked firmware that may never receive a patch. An RTOS additionally guarantees deterministic timing, so a security feature that adds latency can break the device's core function. Because you usually cannot harden the device itself, the controlling strategy is compensating isolation: put these devices on dedicated, segmented network segments or VLANs, restrict their reachability, and monitor their traffic from the network rather than the host.

ICS / SCADA

Industrial control systems and SCADA run physical processes: power grids, water treatment, manufacturing lines. Two facts dominate every ICS question:

1. The CIA priority is reversed. In operational technology, availability and safety outrank confidentiality. A controller that stops a turbine or opens a valve must run reliably above all; leaking a sensor reading matters far less than an unplanned shutdown. NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security^[5] is the authoritative reference for these differences.
2. You often cannot patch or scan normally. ICS devices run legacy or vendor-validated firmware, may have multi-decade service lives, and taking them offline for a patch can mean halting a physical process; aggressive antivirus or active scanning can disrupt real-time control loops. The accepted approach is defense-in-depth via network segmentation: separating the OT network from corporate IT, organizing the plant into zones connected by tightly controlled conduits, and patching only after vendor validation during planned maintenance windows.

Air-gapped networks

An air gap physically isolates a network so it has no connection to untrusted networks, the strongest form of segmentation, common around the most critical ICS. Its security implication is two-edged: it removes network-borne attack surface, but it does not stop an insider, a malicious or infected removable USB drive (the classic Stuxnet vector), or a supply-chain compromise. Treat air-gapping as removing reachability, not as a complete defense.

High availability (HA)

High availability is an architectural property: redundancy, clustering, load balancing, and failover so a service survives component failure. Its security relevance is the availability leg of the CIA triad: HA design defends against denial-of-service impact and hardware failure, and it is the architectural answer when a scenario demands minimal downtime or fault tolerance. The trade-off to remember is that added redundancy also adds components and configuration that themselves must be secured and kept consistent.

SY0-701 architecture questions are scenario-driven and reward matching a signal phrase to the right model or control. Train on the patterns below.

"Who is responsible for..." questions

If a stem asks who must patch the guest OS, encrypt the data, or secure the building, immediately identify the model:

• "...in an IaaS deployment, who patches the operating system?" → the customer. The provider's responsibility in IaaS stops at the hypervisor.
• "...who is responsible for physical security of the data center in the cloud?" → the provider, in every cloud model.
• "...who is accountable for the confidentiality of the data stored in a SaaS app?" → the customer / data owner, always. The provider operates the software, but accountability for the data never transfers. Distractors that say "the provider assumes all responsibility" are wrong.

"We cannot patch / cannot take it offline" questions

When the asset is an ICS controller, SCADA system, legacy IoT, embedded device, or medical device that cannot be patched, the right answer is almost always a compensating control of isolation: network segmentation, a dedicated VLAN, or air-gapping. Wrong answers push agent-based EDR, frequent reboots for patches, or aggressive active scanning, all of which the device cannot tolerate. If the stem emphasizes uptime, safety, or a real-time process, you are in OT: prioritize availability and integrity over confidentiality.

"Isolation vs. density" questions

A stem contrasting two workload-hosting choices is testing virtualization vs. containers: need the strongest isolation between tenants → VMs/hypervisor; need lightweight density, fast scaling, portability → containers (shared kernel = weaker isolation). Serverless is the answer when the stem stresses no servers to manage and pay-per-execution, and the matching risk is an over-permissive function role.

"Reproducible / consistent / version-controlled environment" questions

Keywords like repeatable, auditable, drift, or deploy identical environments point to Infrastructure as Code, and the associated risk the exam likes is a secret hardcoded in a template or a single bad definition propagating everywhere. Centralized control plane clues (one SDN controller, one management console) signal the single-point-of-failure / high-value-target trade-off.

The air-gap trap

If a question describes an air-gapped network being compromised, the vector is never the network: look for removable media (USB), an insider, or supply chain. Choosing "add a firewall" or "the attacker came over the internet" misreads the model. The standing reminder across all of Objective 3.1: choosing a model moves and re-divides security responsibility; it never eliminates it.