Cloud Service Models and Deployment

Compare IaaS, PaaS, and SaaS, shared responsibility, and deployment models against real business requirements.

Certification: CompTIA Cloud+
Recommended study time: 5h 35m
Status: Not started

Recommended study time

About 5h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 8 sittings.

Read the lesson22 min
About 2,886 words at a careful technical reading pace.
Second pass with notes13 min
Re-read the harder parts and write your own notes.
Recall from memory12 min
2 written recall questions.
Practice decision12 min
One applied decision with feedback.
Teach it back20 min
Write the topic in your own words.
Real-world scenario15 min
Read the situation and justify your decision in writing.
Hands-on practice2h 40m
Labs, commands and configuration until you can do it unaided.
Spaced review1h 20m
4 short review sessions spread over the following weeks.

Learning objectives

Distinguish IaaS, PaaS, and SaaS by what the provider and customer operate.
Apply the shared responsibility model to a specific workload.
Compare public, private, hybrid, and multicloud deployment trade-offs.

Start here

About 8 minutes of reading, in 10 short parts.

Moving to the cloud does not remove operational responsibility, it redistributes it, and exactly where that line falls depends entirely on which service model and deployment model you choose. Getting this wrong is one of the most common causes of real cloud security incidents.

Where you meet it: A security review finds a publicly exposed storage bucket, and the team responsible assumed the cloud provider was handling that configuration for them.

The lesson, part by part

Open one part at a time. Each part stands on its own, so you can stop and come back.

Think about renting a car compared to owning one, compared to hiring a taxi. If you own the car, you handle everything: fuel, servicing, insurance, repairs. If you rent a car, the rental company still handles major maintenance and the vehicle itself, but you are responsible for driving it safely and putting fuel in it. If you take a taxi, you are responsible for almost nothing except telling the driver where to go and paying the fare. Cloud service models work the same way: the more of the underlying 'vehicle' the provider manages, the less you have to worry about, but also the less control and customisation you have.

Deployment models are a separate question about where the whole arrangement physically or logically lives: entirely with a public provider shared by many customers, entirely on infrastructure your own organisation controls, or some deliberate mixture of the two connected together. Neither question — service model or deployment model — has one universally correct answer; the right choice depends on cost, control, compliance, and how much operational effort your team can realistically take on.

Key ideas

If you remember nothing else from this topic, remember these.

IaaS, PaaS, and SaaS differ primarily in where the line of customer responsibility falls, with IaaS giving the most control and responsibility and SaaS giving the least of both.
The shared responsibility model means the cloud provider secures the infrastructure while the customer remains responsible for what they configure within it, and that boundary shifts by service model.
Public, private, hybrid, and community cloud describe who owns and can access the underlying infrastructure, not what service model is used on top of it.
Choosing a deployment model is a business and compliance decision as much as a technical one, driven by factors like data sensitivity, cost, and control requirements.
Misunderstanding the shared responsibility boundary is one of the most common causes of real cloud security incidents, particularly around IaaS storage misconfiguration.
Hybrid cloud architectures deliberately connect private and public environments, which introduces its own networking and identity complexity beyond either model alone.

Clarifying who is responsible after a cloud storage exposure incident

A worked example, step by step.

A company using an IaaS cloud provider discovers a storage bucket containing customer records was publicly accessible for several weeks.

01Establish the factsThe security team confirms the storage bucket's access control list was configured to allow public read access, rather than any flaw in the provider's platform.
02Apply the shared responsibility modelUnder IaaS, the provider is responsible for the physical infrastructure and hypervisor security, while the customer is responsible for configuring access controls on the resources they create, including this bucket.
03Confirm this was a customer-side misconfigurationReview of the account's infrastructure-as-code templates shows the bucket policy was set to public during initial testing and never reverted before go-live.
04Remediate immediatelyThe bucket's access policy is corrected to private, and access logs are pulled to determine what, if anything, was accessed externally during the exposure window.
05Compare against PaaS and SaaS for contextThe team notes that had this been a SaaS application, the vendor would typically have preconfigured secure defaults, shifting more of this specific risk to the provider.
06Update deployment practicesA policy is introduced requiring all storage resources to default to private access, enforced automatically through the infrastructure-as-code templates going forward.
07Add automated scanningA cloud security posture tool is enabled to continuously scan for publicly accessible storage resources and alert immediately if one is found.
08OutcomeThe exposure is closed, the root cause is correctly attributed to customer-side configuration under the IaaS shared responsibility boundary, and automated guardrails prevent recurrence.

Outcome: Understanding exactly where the shared responsibility line falls under IaaS directed remediation to the customer's own configuration practices rather than the provider.

Cloud service model and deployment reference

Worth keeping at hand while you work.

IaaS: Provider manages physical hardware and virtualization; customer manages OS, runtime, applications, and data.
PaaS: Provider manages infrastructure and runtime environment; customer manages applications and data only.
SaaS: Provider manages nearly everything; customer manages user access and data entered into the application.
Shared responsibility model: Defines which security and management tasks fall to the provider versus the customer for a given service model.
Public cloud: Infrastructure owned by a third-party provider and shared among multiple customers.
Private cloud: Infrastructure dedicated to a single organization, either on-premises or hosted.
Hybrid cloud: A deliberate combination of private and public cloud environments connected together.
Community cloud: Infrastructure shared among organizations with common requirements, such as regulatory needs.
Multi-tenancy: Multiple customers sharing the same underlying infrastructure while remaining logically isolated.
Elasticity: The ability of a cloud environment to automatically scale resources up or down based on demand.
Vendor lock-in: Difficulty migrating away from a provider due to proprietary services or data formats.
Cloud security posture management: Tooling that continuously scans cloud configurations for misconfigurations and policy violations.

Common misunderstandings

What most beginners get wrong here.

A public storage bucket exposure is always the cloud provider's fault.
Under IaaS and most PaaS models, access control configuration of resources the customer creates is the customer's responsibility, not the provider's.
IaaS, PaaS, and SaaS differ mainly in price, not responsibility.
They primarily differ in where the line of management and security responsibility falls between provider and customer.
Private cloud means the same thing as on-premises infrastructure.
Private cloud can be hosted by a third party as long as the infrastructure is dedicated to a single organization; it is not defined by physical location.
Hybrid cloud just means using more than one cloud provider.
Hybrid cloud specifically means a deliberate, connected combination of private and public environments, not simply using multiple vendors independently.
SaaS removes all security responsibility from the customer.
The customer still manages user access, authentication practices, and the data they put into the application.

Exam traps

How the question writers try to catch you out.

Shared responsibility questions expect precise knowledge of which layer, physical, virtualization, OS, runtime, application, or data, the customer owns under each service model.
A scenario describing a misconfigured storage bucket is almost always testing recognition of customer-side responsibility under IaaS, not a provider failure.
Public, private, hybrid, and community cloud are tested as deployment models, distinct from and often confused with service models like IaaS, PaaS, and SaaS.
Hybrid cloud questions expect recognition that it requires deliberate connectivity between environments, not just parallel use of two clouds.
Multi-tenancy questions test understanding that isolation is logical, not physical, and that this has security implications.

Check yourself

Answer in your head first, then reveal. This is not scored.

Under IaaS, who is responsible for configuring access controls on a storage resource?
What is the key difference between private cloud and on-premises infrastructure?
What distinguishes hybrid cloud from simply using two different cloud providers?
In SaaS, what security responsibilities remain with the customer?
What does multi-tenancy mean in a public cloud context?

Quick reference

A condensed summary of the lesson above, for revision.

What It Is

Infrastructure as a service provides compute, storage, and networking that the customer configures and patches. Platform as a service provides a managed runtime where the customer supplies code and configuration. Software as a service provides a finished application where the customer manages data, identity, and settings. Under shared responsibility, the provider secures the cloud while the customer secures what they put in it.

Why It Matters

Public data exposures are frequently customer misconfiguration of storage or identity, not provider failure. Cost and lock-in decisions also follow directly from the service model chosen.

How It Works

Providers expose resources through APIs, with regions and zones controlling placement and fault isolation.
Managed services abstract the operating layer but constrain configuration.
Billing follows consumption, including compute time, storage, requests, and data egress.

Where You See It

Migration projects, SaaS adoption, disaster recovery targets, development environments, and cost reviews.

Key Terms

Shared responsibility: The split of security duties between provider and customer.
Elasticity: Automatic scaling of resources with demand.
Region and availability zone: Geographic and fault-isolated placement of resources.
Managed service: A service where the provider operates the underlying platform.
Egress cost: Charges for data leaving the provider network.

Examples

In IaaS you patch the guest OS; in PaaS the provider patches the runtime beneath your code.
SaaS still requires you to configure sharing, retention, and access reviews.

Common Problems

Misconfigured public storage
Unbudgeted egress costs
Single-zone deployments
Unmanaged SaaS sprawl

How It Fails

A storage bucket made public for convenience exposes data indefinitely.
A single-zone deployment fails entirely during a zone incident.
Shadow SaaS adoption puts company data outside monitoring and retention.

How to Troubleshoot

Check the responsibility boundary before escalating to the provider.
Review configuration and identity before assuming a platform fault.
Validate placement across zones when availability expectations are not met.

Practical Knowledge

Treat cloud configuration as code so it is reviewable and repeatable.
Model costs including egress and storage growth, not just instance price.

Exam Coverage

Service and deployment models
Shared responsibility
Cloud characteristics and cost concepts

Interview Questions

Who patches the OS in PaaS versus IaaS?
Why is multi-zone design necessary for availability?

Watch and read

Verified official and reputable sources for this topic. Links open in a new tab.

Video training

Professor Messer video channel — general CompTIA training (no dedicated CompTIA Cloud+ course)
Professor Messer
Video
Free
Watch

Lesson notes and bookmark

Notes and bookmarks for this lesson, saved with everything else you have marked.

Add a note

No notes on this item yet.

Learning progress

0% across six evidence areas. Reading alone does not change progress.

Understanding0%

Recall0%

Application0%

Practical ability0%

Troubleshooting0%

Retention0%

Prerequisites

Next steps

01Write the responsibility split for one workload you would move to cloud.
02Compare the cost drivers of one IaaS and one equivalent managed service.