Service and deployment models: the two axes people keep confusing

Why this matters

This is the first objective of the exam and it is the one most often answered from half-memory. Candidates learn "IaaS, PaaS, SaaS" as a list and "public, private, hybrid" as another list, and then meet a scenario that mixes them and have to guess which list is being asked about.

They are not two halves of one spectrum. They are two independent questions:

• How much of the stack do you still operate? That is the service model.
• Who owns the infrastructure and who else is on it? That is the deployment model.

Every real deployment answers both. A private SaaS exists. A public IaaS is the obvious case. A hybrid PaaS is ordinary. Once you hold the two axes apart, a large family of exam questions stops being ambiguous.

The lesson

IaaS, PaaS and SaaS as a line showing how much you still operate

Think of a stack running from the building at the bottom to the application at the top: facilities, hardware, virtualization, operating system, middleware and runtime, application, data. The service model is simply where the line is drawn between what the provider runs and what you run.

• Infrastructure as a Service. The provider gives you virtualized compute, storage and networking. You bring the operating system upwards — you patch it, harden it, and you are responsible for what runs on it. Most flexible, most work.
• Platform as a Service. The provider runs the operating system, runtime and middleware. You supply application code and configuration. You cannot usually log into the host, and that is the point: the trade is control for operational burden.
• Software as a Service. The provider runs the whole application. You supply data, users and settings. Your operational job is administration and identity, not infrastructure.

Two things to hold onto. First, your data is yours at every level. No service model makes the provider responsible for the contents of your records or for who you granted access to. Second, the models are a continuum rather than three boxes — managed database services, container services and functions sit between the named tiers, and a scenario describing one is asking you to reason about where the line falls, not to recite a definition.

A useful test when a question describes an unfamiliar service: ask what the customer is still obliged to patch. If the answer is "the guest OS", it is behaving like IaaS. If it is "only the code", it is behaving like PaaS. If it is "nothing, only configuration", it is behaving like SaaS.

Public, private, hybrid and community as a separate question about WHERE it runs

The deployment model answers who owns the underlying infrastructure and who shares it.

• Public. Infrastructure owned and operated by a provider, shared among unrelated tenants. You get elasticity and someone else's capital expenditure; you accept multi-tenancy and the provider's control plane.
• Private. Infrastructure dedicated to a single organisation. It may sit in your own data centre or be hosted by a third party — "private" means single tenancy, not on-premises, and that distinction is examinable. A hosted private cloud is still private.
• Hybrid. Two or more distinct environments — commonly a private and a public one — joined so that data and workloads can move between them. The word only means something if there is genuine integration; two unrelated environments owned by the same company are not a hybrid cloud.
• Community. Infrastructure shared by several organisations with a common concern — a regulatory regime, a sector, a compliance framework. Rare in practice, common in exam questions, and the giveaway is a scenario naming several organisations with a shared requirement rather than one.

Multi-cloud is a fifth term you will meet and it belongs to this axis too: using more than one public provider. It is not the same as hybrid. Hybrid is about mixing types; multi-cloud is about using several of the same type. The next lesson takes it further.

Why the two axes are independent, and the exam questions built on that

Because the axes are independent, any service model can appear under any deployment model:

Exam questions exploit the confusion in two directions.

The first shape names a service model and asks a deployment question, or the reverse. "A firm must keep data on hardware nobody else uses but wants the vendor to run the application." That is single tenancy plus the vendor operating the whole stack — a private SaaS deployment, which sounds like a contradiction only if you think one axis implies the other.

The second shape gives a driver and asks you to pick. Those are the harder ones and they are the subject of the next lesson, because the right answer comes from the business need rather than from the technology named.

Reading a scenario for the business need rather than the technology named in it

CompTIA's own wording for this objective is about supporting business needs, and the questions follow it. The technology mentioned in a scenario is usually context; the driver is the answer.

Train yourself to find the driver first. The common ones and what they usually select for:

• Regulatory or sovereignty requirement — data must stay in a jurisdiction or on dedicated hardware. Points to private, or to a public region chosen for its location.
• Unpredictable or spiky demand — points to public elasticity, and to hybrid if a steady baseline already runs somewhere.
• Capital already spent — an estate refreshed last year is an argument for hybrid rather than migration, regardless of what is technically nicer.
• Speed to market — points up the service-model axis. PaaS and SaaS remove work that would otherwise be on the critical path.
• Resilience to a provider failure — points to multi-cloud, and you should expect the question to make you weigh the operational cost of it.
• Shared compliance regime across several firms — the community-cloud cue.

When two options are both technically fine, the driver decides. If a scenario never states a driver, the answer is usually the simplest option that meets the stated constraint, not the most capable one.

The shared responsibility line moving as you go up the service-model axis

Shared responsibility is the single most tested idea in this objective, and it is best remembered as one sentence: the provider is responsible for the security of the cloud; the customer is responsible for security in the cloud — and where "of" ends moves with the service model.

Roughly:

• Always the provider's: physical facilities, hardware, the hypervisor, the provider's own control plane.
• Always the customer's: data, who has access to it, account and identity configuration, and how the service is configured.
• Moves with the model: guest operating system, patching, runtime, middleware, network controls. Yours under IaaS; increasingly the provider's as you move to PaaS and SaaS.

Three consequences worth carrying into the exam:

1. Misconfiguration is almost always the customer's fault, at every service model, because configuration never crosses the line. A public storage bucket is a customer failure under IaaS, PaaS and SaaS alike.
2. Compliance is shared and never delegated. A provider's attestation covers the provider's half. You still evidence yours. Objective 4.4 returns to this.
3. SaaS does not remove identity work. It concentrates it. The application is the vendor's; the accounts and permissions are yours, and they are where the incidents happen.

What to take into the exam

• Service model = how much you still operate. Deployment model = who owns it and who shares it. They are independent; any combination is possible.
• Private means single-tenant, not on-premises. A hosted private cloud is private.
• Hybrid requires integration between environments. Multi-cloud means several public providers and is not the same thing.
• Community cloud = several organisations, one shared concern.
• Shared responsibility: of the cloud vs in the cloud, with the boundary sliding up as you move IaaS → PaaS → SaaS. Data and configuration never cross it.
• Find the business driver in the scenario. It decides between two options that are both technically acceptable.