Cloud service models, and who patches what

Why this matters

The service models are among the most reliably examined items in Core 1, and they are also among the most commonly learned as three definitions to be recited rather than as a distinction that decides something.

The distinction that decides something is responsibility. Each model draws a line between what the provider operates and what the customer operates, and where that line sits determines who patches the operating system, who configures the access controls, and who is accountable when data is exposed. Most real cloud security failures are a customer assuming the provider was handling something on the customer's side of the line.

The exam asks you to place a described service into a model. That is answerable in one question — which this lesson gives you — and the question works on services nobody has named to you before.

The lesson

Infrastructure, platform and software as a service, defined by responsibility

Think of a stack: facilities, hardware, virtualisation, operating system, runtime, application, data, access. The models differ in how far up the provider goes.

Infrastructure as a service. The provider supplies compute, storage and networking. You receive something that behaves like a virtual machine.

• The provider handles: the building, the hardware, the hypervisor, the physical network.
• You handle: the operating system and everything above it. Patching, hardening, the firewall rules, the applications, the data, the accounts.
• Most control, most work.

Platform as a service. The provider supplies a place to run code.

• The provider handles everything up to and including the runtime, and patches the operating system beneath it.
• You handle: your application, its configuration, and your data.
• Less control, much less operational work.

Software as a service. The provider supplies a finished application.

• The provider handles essentially the whole stack.
• You handle: your data, your users, and your configuration of the application — which is a much bigger responsibility than it sounds.
• Least control, least work.

A worked example of one capability across the models: running a database. Infrastructure as a service means you install and patch the database yourself on a virtual machine. Platform as a service means you are handed a managed database and never see the operating system. Software as a service means you are handed an application that happens to have a database inside it and you never see the database at all.

The shared responsibility model, and the question that identifies any service

The shared responsibility model is the formal statement of the above: the provider is responsible for security of the cloud, and the customer for security in the cloud. What "in" covers moves with the model.

The identifying question, which works on any service you have never heard of:

What is the customer still obliged to patch?

• Obliged to patch the guest operating system → infrastructure as a service.
• Obliged to patch only their own code → platform as a service.
• Obliged to patch nothing, only to configure → software as a service.

Two more questions that disambiguate the edges:

Who is responsible when it is misconfigured? Always the customer, in every model. Misconfiguration is the customer's side of the line by definition, which is why publicly readable storage is the archetypal cloud incident and why no provider is at fault for it.

Who is responsible if the data is deleted? The customer, unless a backup service was purchased. Providers protect against their hardware failing, not against the customer's mistakes — the same distinction lesson 21 made about RAID, in a different place.

What the customer still owns in every model, including identity and data

Some responsibilities never transfer, whatever the model, and naming them is a reliable way to answer a scenario question.

• Data. Its accuracy, its classification, its retention, its legality.
• Identity and access. Who has accounts, what they may do, whether they use multi-factor authentication, and whether departing staff are removed. This is the customer's job in every model without exception.
• Configuration. Sharing settings, public access, permissions, encryption options. The provider gives controls; using them is the customer's.
• Client devices. The laptop accessing the service is outside the provider's scope entirely.
• Compliance obligations. A provider can be compliant and still be used in a way that is not.

The realistic failure that follows: an organisation moves to a software service, concludes that security is now the provider's problem, leaves the default sharing settings, and publishes a folder to the internet. Every layer the provider is responsible for worked perfectly.

Recognising which model a described service behaves like

Exam scenarios describe a service without naming its model. The identification is mechanical once the question above is in hand.

• "A virtual server you can install anything on" → infrastructure. You patch the operating system.
• "A managed database where you never see the machine" → platform.
• "A web-based mail and document suite" → software.
• "A place to deploy a web application by pushing code" → platform.
• "Managed storage buckets" → infrastructure-adjacent storage, and the customer owns the access configuration.
• "A serverless function that runs your code on demand" → platform, at its furthest extent.
• "A virtual desktop delivered by a provider" → software from the customer's point of view, since the provider runs the broker and the infrastructure.
• "A managed network appliance run by a vendor" → software, and the exam may describe it that way.

The trap to watch: a service can be described by what it is used for rather than by who operates it. Ask about operation, not purpose.

Where this exam stops and a cloud certification begins, stated plainly

Core 1 asks for the models, the characteristics in lesson 33, and enough reasoning to place a service and identify who is responsible. It is a support technician's working knowledge, and that is a deliberate scope.

What it does not ask for, and where a dedicated cloud certification starts:

• Designing a virtual network, subnetting a cloud environment, or configuring peering and transit.
• Identity federation, single sign-on integration, and role design.
• Automation, infrastructure as code, and deployment pipelines.
• Container orchestration.
• Cost management and architectural trade-offs at scale.
• Provider-specific service names and their configuration.

Saying so matters for two reasons. It stops a candidate over-preparing an eleven-per-cent domain when the twenty-eight-per-cent troubleshooting domain is waiting — the arithmetic this course keeps returning to. And it is honest about what the certification claims: an A+ holder can explain the models and identify responsibility, which is genuinely useful and is not the same as being able to build the environment.