On-premises, cloud and virtualisation, compared by where the risk lands

Objective 3.1 in this course covers architecture models — CompTIA's scope note for it compares on-premises, cloud, virtualization, Internet of Things (IoT), industrial control systems (ICS) and infrastructure as code (IaC). This lesson takes the first three; IoT, ICS, embedded systems and IaC are the next lesson.

Why this matters

Domain 3 is 18% of the exam and it is the domain people find hardest to revise, because it is not a list of terms — it is a set of trade-offs. The questions give you a requirement and four architectures, and the right answer depends on which property the requirement cares about.

The single most useful habit for this whole domain is to ask where the risk lands: who owns it, who can see it, and who is accountable when it fails. That one question resolves most of the objective.

The lesson

Responsibility matrix, and the line a shared responsibility model draws

The shared responsibility model states which security tasks belong to the cloud provider and which to the customer. The provider secures of the cloud — the physical facilities, the hardware, the hypervisor, the provider's own services. The customer secures in the cloud — their data, their access configuration, and everything above the line for their service model.

The line moves with the model, and the exam tests where it sits:

Two rows never move: your data and your access configuration are always yours, in every model. That is why the overwhelming majority of cloud incidents are customer-side — an open storage bucket, an over-permissive role, a leaked key — and why "the provider will handle it" is never the right answer to a data exposure question.

A responsibility matrix is the document that records this for a specific provider and service, including the parts that are shared rather than owned outright — logging, for instance, where the provider offers the capability and the customer has to enable, retain and read it.

Hybrid, third-party vendors, and the seam between two providers

Hybrid means some workloads on-premises and some in cloud, with connectivity between them. It is the commonest real architecture and its security problems are almost all at the seam:

• the connection itself — a VPN or dedicated circuit that now makes the cloud estate reachable from the corporate network and vice versa, which means a compromise on either side crosses;
• identity, where on-premises directories are synchronised to cloud identity providers, and the synchronisation account becomes one of the most privileged objects in the organisation;
• inconsistent controls, where the on-premises estate has one set of logging, patching and access standards and the cloud estate has another, so the effective security posture is the weaker of the two;
• monitoring gaps, where each side is monitored by a different tool and nothing correlates an event that crosses.

Multi-cloud adds the same seam again between providers, plus the problem that each provider's identity model, logging format and terminology differ, so skills and tooling do not transfer cleanly.

The exam's framing: hybrid and multi-cloud buy resilience and flexibility and cost complexity, and complexity is itself a security risk because it produces misconfiguration.

Virtualisation, containerisation and what each isolates

Both run multiple workloads on one host. They isolate at different levels and that is the whole distinction.

Virtualisation gives each guest its own operating system on virtual hardware, with the hypervisor as the boundary. Isolation is strong because the guests share nothing above the hardware abstraction. The costs are resource overhead and an OS per guest to patch and manage.

A type 1 hypervisor runs directly on hardware and is what data centres use; a type 2 runs as an application on a host OS and inherits that OS's vulnerabilities, which is why type 2 is for workstations and labs rather than production.

Containerisation shares the host's kernel and isolates at the process level using namespaces and control groups. Containers start in milliseconds, are far denser, and package the application with its dependencies — which is a genuine security benefit, because the runtime is defined and reproducible.

The security trade-off, which is the exam point: a shared kernel is a shared failure domain. A kernel vulnerability can be a container escape. So containers are excellent for isolating workloads of similar trust level and are not, on their own, the right boundary between workloads of very different sensitivity — that wants separate hosts, or separate clusters.

Container-specific concerns: image provenance (containers are built from base images pulled from registries, which is a supply chain), image vulnerability scanning, secrets management because credentials baked into an image are in every copy of it, and registry access control.

Serverless, microservices, and the architecture that has no host to harden

Serverless runs your code in response to events, with the provider managing everything beneath it. There is no server for you to patch, harden, or log into.

That is a real security gain — a large class of vulnerabilities simply stops being yours — and it relocates the risk rather than removing it:

• the attack surface becomes the function's permissions and its event triggers. An over-permissive execution role is the serverless equivalent of an over-privileged server, and it is the single most common finding;
• dependencies inside the function package are still yours to keep patched;
• monitoring must be built in deliberately, because there is no host agent to install;
• cost becomes an availability concern in a way it is not elsewhere: a function triggered in a loop bills continuously, which is sometimes called denial of wallet.

Microservices decompose an application into many small services communicating over APIs. Security consequences: many more network interactions, each needing authentication and authorisation (service-to-service identity, not just user identity); a much larger API surface; and far harder tracing of a single transaction, which is why distributed tracing matters for investigation. The benefit is blast radius — one compromised service is not the whole application, provided the services do not all trust each other implicitly.

Centralised versus decentralised, and the trade the exam wants named

This axis runs through the whole domain.

Centralised means one place makes decisions and holds data — a single identity provider, one SIEM, one firewall policy, one data store. Advantages: consistent policy, one place to audit, economies of scale, simpler compliance. Disadvantages: it is a single point of failure, and it is a high-value target — compromise the central identity provider and everything downstream falls.

Decentralised spreads decisions and data across many points. Advantages: no single point of failure, local autonomy, blast radius limited by design. Disadvantages: inconsistent policy, difficult auditing, duplicated effort, and drift — which is exactly the inconsistency problem described under hybrid.

The exam wants you to name the trade rather than declare a winner: centralised buys consistency and control at the price of a single point of failure; decentralised buys resilience and autonomy at the price of consistency. Which is right depends on whether the scenario's stated priority is uniform policy and auditability, or survival of a component failure.

In practice most mature designs centralise policy and decentralise enforcement — one place decides, many places enforce. That is the zero trust control plane and data plane split from Domain 1, and recognising it as the same idea is worth doing.

What to take into the exam

• Data and access configuration are the customer's responsibility in every cloud model. The OS is the customer's in IaaS only.
• Hybrid and multi-cloud problems live at the seam: connectivity, identity sync, inconsistent controls and monitoring gaps.
• Hypervisor isolates whole operating systems; containers share a kernel and isolate processes — so a shared kernel is a shared failure domain.
• Type 1 runs on hardware, type 2 runs on a host OS and inherits its vulnerabilities.
• Serverless removes host hardening and relocates risk to function permissions and event triggers.
• Centralised = consistency plus a single point of failure; decentralised = resilience plus drift.