On-Prem to Serverless: Architecture Models, the Line That Moves, and the Twelve Considerations Security+ Scores Them By
Chris Rees
25+ years in IT · Pluralsight author, 4.6/5 across 2,000+ ratings
Objective 3.1 looks like a vocabulary list: cloud, hybrid, serverless, microservices, SDN, containers, ICS, RTOS. Candidates memorize the definitions and then meet a stem that describes a workload, names a constraint, and asks which model fits or which risk you just took on. The trick is that every architecture on the list is a decision about a single thing: how much of the stack you control, and therefore how much of it you must secure, can fail, and are able to fix. Hold that line in your head and the twelve considerations at the end of the objective stop being a list and become a scoring rubric.
The line that moves
Cloud computing buys compute, storage and services on demand from a provider, and its defining security concept is the responsibility matrix: stack layers down the side, service models across the top, and in each cell the party that secures that layer. The matrix has its own post on the shared responsibility model, so here is only the part 3.1 tests. The line moves with the service model, and two rows never move at all: your data and your identities are yours in every model, including SaaS.
The exam's favorite discriminator is operating system patching: the customer's job in IaaS, the provider's in PaaS and SaaS. An unpatched hypervisor is the provider's problem in every cloud model, because nobody rents a hypervisor.
On-premises is the left end of the spectrum: you own the full stack in your own building, with maximum control and complete responsibility for every patch, disk and generator, at high capital cost and slow scaling. Hybrid joins on-premises to one or more clouds, and its security implication is the seam: two stacks whose identity, logging and encryption policies must stay consistent, with data crossing trust zones and sometimes jurisdictions. Misaligned controls across the seam are the classic hybrid failure.
Third-party vendors ride along with every cloud decision, and each is a dependency you cannot audit day to day, so you manage it contractually: questionnaires, audit reports, certifications, SLAs, incident notification terms. Outsourcing operations does not outsource accountability.
Code that builds the infrastructure
Three models on the list are about how workloads are built rather than where they run.
Infrastructure as code replaces hand-built servers with templates: consistent, repeatable, auditable builds with drift detected automatically. The downside is the same property in reverse: a misconfiguration in the template is replicated everywhere at once, and a secret committed to the repository is a breach waiting to be cloned. Treat IaC as application code, with peer review, scanning, and credentials in a vault rather than in the file.
Serverless goes further: the provider runs your functions on demand and you never see a server, OS or runtime. Infrastructure risk transfers to the provider; your code, its dependencies, its permissions and its event triggers stay yours, so over-permissioned functions, injection through event data and vulnerable libraries are the failure modes. It is the purest risk transference on the objective, paired with the reminder that responsibility for the code never moves.
Microservices decompose one application into many small services talking over APIs. Each can be scaled, patched and contained on its own, so a compromised service can be isolated. The cost is that the attack surface moves onto the network: every inter-service call needs authentication, authorization and encryption, usually through an API gateway and mutual TLS.
Three ways to keep networks apart
The network infrastructure bullet is a ladder of three separation strategies, each weaker and more flexible than the one before.
| Strategy | What separates the networks | Strength | Characteristic risk |
|---|---|---|---|
| Physical isolation (air gap) | no connection at all: separate cabling, separate switches, no wireless | strongest | removable media crosses the gap; staff build unofficial bridges |
| Logical segmentation | VLANs, subnets and firewall rules on shared hardware | practical default | one misconfigured rule bridges segments |
| Software-defined networking | a central controller programs the data plane through APIs | most flexible | the controller becomes the crown jewel |
The exam's cue for air gap is the phrase "no possibility of network-based attack." One wrong rule bridges a VLAN; an air gap can only be bridged physically, which is why the malware that crosses one arrives on a USB drive. Software-defined networking separates the control plane from the data plane and makes segmentation programmable: a compromised host can be quarantined in seconds by pushing new flow rules, and the same centralization makes the controller a single high-value target. Where the enforcing devices go belongs to objective 3.2; 3.1 only asks which kind of separation a scenario needs.
Centralized or decentralized
Independent of where things run is where they are decided. A centralized architecture concentrates computing and administration: one data center, one security team, one policy engine. It gives consistent enforcement and one place to defend, and also a single point of failure and a concentrated blast radius. A decentralized architecture spreads systems and authority across sites or business units, which survives a single-site outage at the price of policy drift, uneven patching and visibility gaps. The blend most enterprises use is centralized identity and logging with decentralized execution.
Hypervisor or kernel
Virtualization and containerization sit together on the list because they are not the same boundary.
| Virtualization | Containerization | |
|---|---|---|
| What is shared | the hypervisor and hardware | the host operating system kernel |
| What each workload carries | a full guest OS with its own kernel | the application and its libraries only |
| Isolation | strong, enforced at the hypervisor | weaker, enforced by the kernel |
| Headline attack | VM escape from guest to host or neighbor | kernel compromise reaching every container |
| Quiet exposures | VM sprawl, data remnants on reused storage | malicious registry images, secrets baked into images |
| Operational win | snapshots and rollback | seconds to start, effortless scaling |
The devices you cannot patch
Four categories share one theme: purpose-built, long-lived, increasingly networked, and hard or impossible to patch.
- IoT: sensors, cameras, wearables, building automation. Default credentials, rare firmware updates, no security headroom. A compromised device is a pivot point or a botnet node.
- ICS/SCADA: systems that run physical processes, with SCADA as the supervisory layer over distributed controllers. Availability and safety outrank confidentiality, components run for decades, and downtime for patching may be unacceptable.
- RTOS: an operating system that guarantees deterministic timing, in vehicles, medical devices and avionics. A security agent that adds latency can itself cause a dangerous malfunction.
- Embedded systems: a computer inside a larger product, from printers to ATMs. Constrained hardware, vendor-controlled firmware, and patches that may void a certification.
The pattern for all four is compensation: segment the device onto its own network, restrict and monitor access, and put the controls around it rather than on it. That is objective 1.1's compensating control applied to a class of hardware, and it is the answer whenever the stem says the patch cannot be applied.
High availability is on the list as an architecture property: surviving component failure through redundancy, clustering and replicated data. It protects availability and nothing else, and every redundant copy is more infrastructure to secure. The mechanics are objective 3.4.
Twelve considerations, one rubric
The objective closes with twelve considerations, and most 3.1 stems hinge on exactly one.
Two rows are routinely confused. Patch availability asks whether updates exist at all; inability to patch asks whether you can apply the ones that do. And risk transference carries a standing footnote: accountability never transfers with it.
When a stem names a constraint, find its row and the model answers itself. "Cannot tolerate downtime for updates" is inability to patch, and the answer is a compensating architecture, not a better patch schedule. "Needs capacity for a seasonal peak without buying hardware" is scalability, and the answer is elastic cloud. "Must respond within milliseconds" is responsiveness, and the answer is an RTOS, never a serverless function.
Four stems, decoded
- A company moves a web application to a PaaS offering and asks who now patches the operating system. The provider. In PaaS the customer keeps code, configuration and data; the OS and runtime crossed the line.
- A template used to build cloud environments contains an access key, and every environment built from it exposes the same key. Infrastructure as code replicating a committed secret. Vault the credential and review templates as code.
- A medical imaging device runs certified firmware the vendor forbids altering, and it must remain reachable by radiology workstations. Inability to patch on an embedded system. Segment it, restrict and monitor access, and compensate around it.
- A regulator requires that a classified network have no possibility of network-based compromise. Physical isolation, an air gap. Logical segmentation is bridgeable by misconfiguration; only the air gap satisfies "no possibility."
Key takeaways
- Every model is a position on one line: how much of the stack you control. Data and identity are always yours; OS patching is yours in IaaS and the provider's in PaaS and SaaS.
- IaC replicates whatever you commit, serverless transfers infrastructure risk but not code risk, microservices move the attack surface to APIs. Three models about how, not where.
- Air gap is physical, VLANs are logical, SDN is programmable. Isolation strength falls and flexibility rises in that order; protect the SDN controller like the crown jewel it is.
- VMs isolate at the hypervisor; containers share the kernel. Name the boundary that failed: VM escape or kernel compromise.
- IoT, ICS/SCADA, RTOS and embedded systems cannot be patched on schedule, so compensate around them. Segment, restrict, monitor. Then score the stem on the twelve considerations and the model picks itself.
Architecture models are objective 3.1 of Security+ Domain 3, Security Architecture, 18% of the exam, and the considerations grid is the thinking behind every placement, data-protection and resilience decision in 3.2 through 3.4. Work all 26 Domain 3 topics with our free Security+ Domain 3 study guide.
#SecurityPlus #SY0701 #SecurityArchitecture #CloudSecurity #InfrastructureAsCode #Containers #ICS #ExamPrep #InfoSec #CyberSecurity
Master Security Architecture
Data protection is one module of four in Security+ Domain 3. Study all 26 topics (architecture models, enterprise infrastructure, data protection, and resilience) with our objective-mapped guide.
Get the Domain 3 guideKeep reading
SPF, DKIM, DMARC, and Friends: The Enterprise Security Capabilities Security+ Expects You to Configure
Objective 4.5 is where Security+ stops asking what a control is and starts asking where it goes. Email authentication drawn as one flow (SPF checks the sender, DKIM signs the message, DMARC decides what happens), web and DNS filtering, DLP and what it can actually see, EDR versus XDR, NAC posture checks, file integrity monitoring, and the placement map that answers every scenario in the objective.
Read Security+ deep divesBuilt to Survive: High Availability, Backups, and Power, the Half of Security+ Domain 3 Nobody Studies
Availability is the third letter of the triad and the objective candidates skim. Security+ 3.4 in full: load balancing and clustering, active-active versus active-passive, platform and geographic diversity, the full, incremental and differential trade-off drawn as a chart, snapshots, replication and journaling, UPS versus generator, and the capacity planning question the exam hides in a story about a hiring freeze.
Read Security+ deep divesRansomware, Rootkits, and Logic Bombs: Malware Types and the Indicators Security+ Expects You to Spot
Objective 2.4 is the longest list in Security+ and the one that turns into the most scenario questions. Malware classified by how it spreads and what it does, the attack families beyond malware, and the nine indicators of malicious activity, from impossible travel to missing logs, that tell you which attack a stem is describing before you read the answers.
ReadEnjoyed this? Get the AI security news that matters.
Join The AI Security Brief for the top AI security news, plus what's important to the C-suite. Free, straight to your inbox.
No spam. Unsubscribe anytime.