CompTIA Security+ SY0-801 Security Architecture Models: Cloud, On-Premises, OT and Segmentation

Objective 3.1 covers the places and shapes a system can take — cloud (serverless, multicloud, the four deployment models and Infrastructure as Code), on-premises infrastructure, operational technology (OT), air-gapped networks, microservices and logical versus physical segmentation — and asks you to compare what each one changes about security. No model is secure or insecure on its own: each moves control, responsibility, cost and attack surface to a different place, and the right choice is the one whose trade-offs fit the stated requirements.

The objective then lists two sets of criteria for making that choice:

• Technical considerations: availability, resilience, proprietary versus open source, usability, responsibility, compute, power requirements and ease of recovery.
• Business considerations: data sovereignty, data classification, cost, ownership, environmental requirements, scalability and risk.

Securing the infrastructure you have chosen (device placement, security zones, firewalls, secure communication) is objective 3.2; protecting the data itself is 3.3; backups, high availability and recovery sites are 3.4.

A cloud deployment model answers one question: who shares the infrastructure? Public cloud is shared with any paying customer, private cloud is used by one organization, community cloud is shared by a closed group of organizations with common requirements, and hybrid cloud combines two or more of these (often with on-premises systems) into one connected environment.

Private is about tenancy, not location

A private cloud can sit in your own data center or be hosted by a provider who runs single-tenant infrastructure for you alone. Hosting moves the facility work to the provider while keeping other customers off the servers — but the provider then owns the hardware and controls the building. Separation comes in degrees, and only tenancy decides whether something is private:

• Logical boundaries inside a public cloud (separate accounts, virtual network boundaries) separate management and traffic, but the workloads remain multitenant.
• Dedicated hosts in a public cloud give single-tenant hardware, but the provider still owns it and its staff have physical access.
• Owned servers in a colocation facility are your hardware in someone else's building, whose staff control entry to the room.
• A community cloud is not private: other member organizations share it. If a rule says data may not share hardware with any other organization, only private (hosted or self-run) or on-premises meets it.

Hybrid cloud: the link is the new risk

Whenever a workload in one environment depends on systems in another, the interconnection (a VPN or dedicated circuit) is what hybrid adds: it needs encryption, authentication, narrow firewall rules and monitoring, like any other route into the internal network. Duties that applied to each environment on its own still apply, but they are not new — the link and consistent policy on both sides of it are.

The responsibility consideration asks which security tasks you keep under each model: the more the provider runs, the less you patch — but you always keep your data, your users and their access. The provider always owns the physical facility and the hypervisor in public cloud; the customer never patches those.

• Moving from on-premises to IaaS removes the facility, hardware and physical security from your list; the guest OS, its patches and your virtual firewall rules stay with you. Responsibility follows control: only the party who can change a layer can maintain it, and on rented VMs only the customer can apply guest OS patches. Publishing a patch and watching for attacks are different jobs from applying it.
• PaaS hands the operating system and the platform software (runtimes, middleware, managed engines) to the provider; you keep your application code, its configuration and your data.
• SaaS leaves the whole application stack to the provider. What stays yours is identity and data: who gets an account, how users authenticate, what permissions they hold and what data they put in. An account takeover through weak customer-side authentication is the customer's failure, so enforce MFA and review accounts.
• Running your own private cloud means inheriting the provider's job: you now patch the virtualization hosts and hypervisor, on top of the guest OS duties you already had.

Choosing a model is also a way to manage risk: each step from IaaS to PaaS to SaaS moves more operational work to the provider, so the model can be chosen to take work away from whatever the organization's weakest point is — skills, staffing or facilities.

Serverless is a cloud model in which code runs on demand in response to events and the provider provisions, scales and patches everything underneath — hosts, operating system and runtime. The customer still secures the function code, the events and inputs that trigger it, and the permissions each function's identity holds. Capacity is not a customer task either: the platform runs more instances as events arrive, and the customer only sets limits such as concurrency.

The key serverless risk is permissions. A function usually runs with a cloud identity, so a single code flaw lets an attacker do whatever that identity is allowed to do. A function that only needs to write to one queue but holds broad account permissions turns one injection bug into account-wide access. Least privilege per function — a separate identity granting only the resources that function needs — limits the blast radius. Because the customer manages no host, the customer-side levers are code quality, input validation and identity scoping.

Serverless is not the same as microservices (a way to split an application, which may or may not run serverless) or Infrastructure as Code (a way to define infrastructure you still run).

Multicloud

Multicloud means using two or more cloud providers. It removes dependence on any single provider, so the service can survive a provider-wide outage or account problem; several regions of one provider protect only against a regional failure. (A hybrid design that can fail over between one provider and on-premises infrastructure also survives the loss of a single provider.) The cost is complexity: each provider has its own identity system, logging, security settings and responsibility model, so keeping equivalent policies and visibility across all of them is harder and controls drift apart. Each provider's isolation between its own tenants is unchanged; the new problem is consistency. Multicloud can be combined with on-premises or private infrastructure, so a single design can address provider dependence for one workload and an ownership or tenancy requirement for another.

Infrastructure as Code (IaC) defines networks, servers, firewall rules and other resources in machine-readable template files, kept in version control and deployed automatically by a pipeline. Its main security benefit is consistency: every environment built from the same reviewed template gets the same settings, which removes manual console errors and configuration drift, makes changes reviewable and auditable, and lets a lost environment be rebuilt quickly to a known configuration.

IaC does not add security on its own: encryption, segmentation or least privilege exist only if the template specifies them, and templates are often specific to one provider, so IaC does not reduce provider dependence. The flip side of consistency is that a flaw in a template is replicated everywhere it is deployed.

The same idea secures elastic scaling: if automatically added servers are launched from a preconfigured hardened image or template, each one starts with the standard security settings, however many are added. Hardening that is applied after launch leaves each new instance exposed until it happens.

On-premises infrastructure is hardware the organization owns in a facility it controls. It gives the most control — over the servers, the room they sit in, who enters it and when patches happen — and therefore the most responsibility: physical security, power, cooling, hardware replacement and every layer of patching fall on the organization. Capital spending on hardware sized for the peak, and the staff to run it, are the main costs. Owning the server is not the same as controlling the room:

Air-gapped networks

An air-gapped network has no wired or wireless connection to the internet or to any other network, so data can cross only on physically carried media. Because every network path is closed, any attack that has to arrive over a network cannot reach it. That moves the risk to removable media: an infected USB drive carrying updates or data is the usual way malware crosses the gap, and the need to carry every update by hand slows patching.

• Any network connection, however restricted or short-lived, means the network is no longer air-gapped. A one-way data diode is a strong control for a segmented network, but it is still a connection.
• The media path is controlled instead: everything that crosses is checked on a dedicated, controlled transfer station (malware scanning, approved media only, logging) before it is carried in. Controls that vouch for one file do not vet the medium as a whole.
• Every other isolation technique in this lesson — segmentation, dedicated tenancy, zones between firewalls (objective 3.2) — reduces exposure but keeps some network path. An air gap is the only one that removes them all.

Operational technology (OT) is the hardware and software that monitors and controls physical processes — manufacturing lines, water treatment, power distribution — through industrial control systems, SCADA and controllers. Its first priority is the availability and safety of the process, because an outage or malfunction can halt production or injure people. Confidentiality, which often leads in IT systems that hold sensitive data, comes later.

That priority shapes every security decision:

• Long lifespans and slow patching: controllers run for many years, patches often need vendor approval, testing and planned downtime, and a line that cannot stop cannot be patched on demand. Installing unapproved firmware risks the process itself.
• Constrained, fragile devices: controllers have minimal processing capacity, cannot run endpoint agents, may lose vendor support if unapproved software is installed, and some reset under heavy network probing.
• Compensating controls: when a vulnerable device cannot be patched, reduce who can reach it — isolate it in a restricted segment so only required systems can talk to it.
• Detection without touching the devices: passive network monitoring of a copy of control traffic detects threats without installing software on controllers or sending them traffic. Active vulnerability scanning and endpoint agents are the wrong fit.

Any change that adds connectivity or latency to a control loop works against the safety priority, and none of them fixes a vulnerable device.

Microservices split an application into small, independently deployable services, each owning one business function and communicating with the others through APIs. Compared with a monolithic application (built and deployed as one unit), they isolate faults — one service can fail while the rest keep running — and let teams patch and scale services separately. The security cost is a larger attack surface: many more components to patch and monitor, many more APIs that must authenticate and authorize requests, and more internal traffic to govern.

The classic microservices failure is trusting network position: if internal traffic is trusted by default, one compromised service can reach all the others. The fix is authentication and authorization on every service-to-service call (for example mutual TLS and scoped service tokens) — the zero-trust principle applied inside the application, where perimeter controls do not see the traffic.

Logical versus physical segmentation

Logical segmentation separates networks with VLANs, subnets and ACLs on shared hardware; physical segmentation gives each network its own switches and cabling.

Physical segmentation can still include deliberate, controlled connections between networks, such as a gateway or firewall; an air gap has none. Software-defined networking (SDN) separates network control from forwarding hardware so networks are managed by software controllers; it is a way of running logical segmentation, not physical isolation.

The technical considerations are the engineering criteria for comparing architectures. The three easiest to confuse describe different moments around a failure:

Requirements often need both: redundancy to survive a single server failure, and version-controlled templates to rebuild a whole lost environment quickly to a reviewed configuration. Recovery that depends on manual steps or stale copies is slower and less predictable than rebuilding from code, and a bigger single machine is still a single point of failure. Scalability (adding capacity) is a different property again.

Proprietary versus open source

Accountability comes from a contract: informal community help carries no obligation to respond or patch.

Usability

A control that makes work too hard gets bypassed, and the workaround is usually worse than a lighter control: users write down passwords that must change too often, or prop open a door whose badge reader is slow. Security must be balanced with usability.

Compute and power requirements

Constrained devices — controllers, embedded sensors, battery or solar-powered edge sites — cannot spare the processing or power for agents, frequent scans or on-site analytics. The pattern is to collect lightly at the edge and analyze elsewhere: a low-power sensor forwarding logs to a central system, or network-based detection that watches a device's traffic without loading the device. Collection should still be continuous: occasional checks leave long blind spots.

The business considerations decide which architecture an organization is allowed and willing to use.

• Data sovereignty: data is subject to the laws of the country where it is stored, so storing records in another country's cloud region can break home-country rules. Protections applied to a copy change how it is guarded, not where it sits, so only the storage location answers a sovereignty rule — and redundant copies must stay within permitted jurisdictions too.
• Data classification: sensitivity labels (for example public, internal, confidential, restricted) decide which systems and deployment models may hold each data set. Matching isolation to each label, rather than giving everything the strictest treatment, meets policy while keeping cost proportional.
• Cost: on-premises is capital expense (buying peak-sized hardware up front); cloud is operating expense (pay-per-use). Pay-per-use has its own risk: a leaked access key can be used to launch large numbers of resources that you are billed for, so set launch quotas (service limits) and spending alerts. A quota caps how many resources any credential can create, and a budget alert flags abnormal spend within a day, well before the invoice. Periodic key rotation and invoice review do not bound spend: a leaked key keeps launching resources until its next scheduled rotation, and an invoice shows the charges only after they have accrued.
• Ownership: whoever owns the infrastructure controls it. You cannot physically inspect a provider's infrastructure or set its maintenance schedule; your influence there comes through the contract and audit reports. (Under IaaS you still decide when your own guest OS is patched.)
• Environmental requirements: the physical conditions a site must meet — natural hazards at the site, climate control, power supply — decide whether a location can host infrastructure safely.
• Scalability: elastic cloud capacity adds resources for a peak and releases them afterwards, so spiky demand favors cloud over owned hardware sized for the peak. Secure every scaled-out instance by launching it from a hardened image.
• Risk: the organization's risk register and appetite steer the choice; pick the model that moves work away from the weakest point, such as limited staff.

Data sovereignty and classification are revisited from the data-protection side in objective 3.3.