This chapter covers the Shared Responsibility Model, a foundational concept in cloud computing that defines which security tasks are handled by the cloud provider and which are handled by the customer. For the CompTIA A+ 220-1101 exam, this topic appears under Domain 4.0 (Virtualization and Cloud Computing), Objective 4.2 (Compare and contrast cloud computing concepts). While not a heavy percentage of the exam (typically 1-2 questions), understanding this model is critical for answering questions about cloud deployment models, security, and operational responsibilities. The exam expects you to know the division of responsibilities for IaaS, PaaS, and SaaS, and how the model varies between public, private, and hybrid clouds.
Jump to a section
Imagine you rent an apartment in a building. The landlord is responsible for the building's structure, roof, elevators, plumbing, electrical wiring, and security of common areas. As the tenant, you are responsible for your personal belongings, locking your door, changing lightbulbs, and any damage you cause. If a pipe bursts in the wall, the landlord fixes it. If your laptop is stolen because you left the door unlocked, that's on you. In cloud computing, the cloud provider (landlord) secures the physical infrastructure, network, and hypervisor. The customer (tenant) secures their data, operating system, applications, and access. If the provider's hypervisor has a flaw, the provider fixes it. If the customer misconfigures a security group, that's their responsibility. This division is not fuzzy—it's a contractual line. For Infrastructure as a Service (IaaS), the tenant manages more (OS, apps, data). For Software as a Service (SaaS), the provider manages almost everything except user data and devices. The shared responsibility model explicitly defines who does what, preventing gaps where both assume the other is handling security.
What is the Shared Responsibility Model?
The Shared Responsibility Model (SRM) is a security and operational framework used in cloud computing to delineate the responsibilities of the cloud provider and the cloud customer. It ensures that all aspects of security, compliance, and management are covered by one party or the other, with no gaps. The model is not a single standard but is defined by each cloud provider in their service agreements (e.g., AWS, Microsoft Azure, Google Cloud). CompTIA A+ 220-1101 tests your understanding of the general principles as they apply to different cloud service models.
Why Does It Exist?
In traditional on-premises IT, an organization owns and manages everything: physical security, hardware, networking, operating systems, applications, and data. In cloud computing, the provider takes on some of these responsibilities. Without a clear model, customers might assume the provider secures everything, while the provider only secures up to a certain point. The SRM eliminates that ambiguity. For example, if a data breach occurs due to a misconfigured database, the provider is not liable—the customer is responsible for configuration. The model also helps organizations meet compliance requirements (e.g., HIPAA, GDPR) by mapping controls to responsible parties.
How It Works Internally
The SRM is often visualized as a layered stack. The cloud provider is responsible for the security OF the cloud, meaning the physical infrastructure, data centers, networking, and hypervisors. The customer is responsible for security IN the cloud, meaning their data, applications, identity management, and access policies. The exact split depends on the service model:
Infrastructure as a Service (IaaS): The provider handles physical security, hardware, storage, networking, and virtualization. The customer manages the operating system, middleware, runtime, applications, data, and access. Example: Amazon EC2—you choose the OS and patch it; AWS secures the hypervisor.
Platform as a Service (PaaS): The provider manages the runtime, middleware, and operating system. The customer only manages applications and data. Example: Google App Engine—you deploy code; Google patches the underlying OS and runtime.
Software as a Service (SaaS): The provider manages everything except user data, devices, and user access. Example: Microsoft 365—Microsoft secures the application; you manage user accounts and data.
Key Components and Defaults
There are no universal defaults, but common responsibilities include:
Provider responsibilities:
- Physical security of data centers (guards, cameras, biometrics) - Hardware maintenance and redundancy - Network infrastructure and DDoS protection - Hypervisor security and isolation - Environmental controls (power, cooling) - Customer responsibilities:
- Data classification and encryption - Identity and access management (IAM) - OS patching (in IaaS) - Application security - Network traffic encryption (TLS/SSL) - Compliance with regulations
Configuration and Verification
In practice, responsibility is configured via cloud provider tools. For example:
AWS: The AWS Shared Responsibility Model is documented. You configure security groups (firewall rules) for EC2 instances. AWS provides a "Responsibility Matrix" in the AWS Artifact portal.
Azure: Microsoft provides a shared responsibility matrix. You configure Azure Policy to enforce compliance. Azure Security Center shows a Secure Score based on your responsibilities.
Google Cloud: Google provides a shared responsibility model document. You use Cloud IAM to manage access.
There is no single command to verify the model—you verify by checking that each responsibility is assigned and implemented. For example, if you have an EC2 instance, you must verify that the OS is patched (customer) and that the instance is in a secure VPC (provider provides the network, but you configure rules).
Interaction with Related Technologies
The SRM interacts with:
Virtualization: The hypervisor is a provider responsibility. The customer's VMs are isolated by the hypervisor.
Cloud Deployment Models: In a public cloud, the provider handles physical security. In a private cloud, the organization may handle everything (or outsource). In hybrid cloud, responsibilities may split across environments.
Security Technologies: Encryption at rest and in transit is often a customer responsibility, but providers offer tools (e.g., AWS KMS, Azure Key Vault).
Compliance: Auditors check that responsibilities are properly assigned. For example, in a PCI DSS audit, the customer must show they control access to cardholder data.
Exam-Relevant Details
The 220-1101 exam focuses on:
Knowing which model (IaaS, PaaS, SaaS) has which responsibilities.
Understanding that the customer is always responsible for their data and user access.
Recognizing that in a public cloud, the provider is responsible for the physical data center.
Identifying that the model is contractual and varies by provider.
Common Misconception: "The Provider Secures Everything"
Many candidates think the cloud provider is responsible for all security. In reality, the customer retains significant responsibility, especially in IaaS. The exam may present a scenario where a company moves to the cloud and assumes the provider handles everything—that is wrong. The customer must still secure their OS, apps, and data.
Step-by-Step: Assigning Responsibility for a New Cloud Workload
Choose a service model: Determine if you are using IaaS, PaaS, or SaaS. This sets the baseline split.
Review the provider's shared responsibility matrix: Each provider publishes a document. Identify which controls are provider-managed and which are customer-managed.
Map compliance requirements: For regulations like HIPAA, list required controls and assign them to the responsible party.
Implement customer responsibilities: Configure IAM, encryption, network security groups, and OS hardening.
Verify with provider tools: Use security score tools (e.g., AWS Trusted Advisor, Azure Security Center) to check that customer responsibilities are met.
Document and audit: Maintain records of who is responsible for what. This is critical for compliance audits.
Edge Cases
Container services (e.g., Amazon ECS): The provider manages the orchestration layer; the customer manages the container images and application security.
Serverless (e.g., AWS Lambda): The provider manages the runtime and infrastructure; the customer manages the function code and data.
Multi-cloud: Each provider has its own SRM. The customer must manage responsibilities across different providers.
Exam Tips
Remember: The customer is ALWAYS responsible for data and user access.
In IaaS, the customer patches the OS. In PaaS, the provider patches the OS.
The provider is responsible for physical security of data centers.
The model is not absolute—it is defined by contract. Read the provider's documentation.
Choose Cloud Service Model
First, determine whether you are using IaaS, PaaS, or SaaS. This decision sets the baseline for responsibility division. In IaaS, the customer manages the operating system, applications, and data. In PaaS, the provider manages the OS and runtime, leaving the customer with applications and data. In SaaS, the provider manages almost everything except user data and access. The exam expects you to know these distinctions. For example, if a company uses Amazon EC2 (IaaS), they must patch the OS; if they use Amazon RDS (PaaS), AWS patches the database engine.
Review Provider's Responsibility Matrix
Each cloud provider publishes a shared responsibility matrix. For AWS, this is in the AWS Shared Responsibility Model document. For Azure, it's the Microsoft Shared Responsibility Model. This matrix lists specific controls (e.g., physical security, network security, data encryption) and indicates who is responsible. The customer must read this document to understand where their obligations begin. The exam may test that the provider is responsible for the hypervisor, while the customer is responsible for guest OS patches.
Map Compliance Requirements
If the workload must comply with regulations like HIPAA, GDPR, or PCI DSS, the customer must map each compliance control to the responsible party. For example, under HIPAA, the customer must ensure that ePHI is encrypted at rest and in transit. The provider may offer encryption tools, but the customer must enable them. This step ensures no control is left unassigned. The exam may ask which party is responsible for data encryption in a given scenario.
Implement Customer Responsibilities
The customer must configure identity and access management (IAM), enable encryption, set up network security groups, and harden operating systems (in IaaS). For example, in AWS, the customer creates IAM users with least privilege, enables S3 bucket encryption, and configures security groups to restrict inbound traffic. The provider does not perform these actions. The exam may present a scenario where a company fails to configure a security group, leading to a breach—the customer is at fault.
Verify with Provider Tools
Cloud providers offer tools to verify that customer responsibilities are met. AWS Trusted Advisor checks for security misconfigurations like open security groups. Azure Security Center provides a Secure Score and recommendations. Google Cloud Security Command Center identifies vulnerabilities. The customer should regularly use these tools to ensure compliance. The exam may ask which tool to use for checking security posture.
Document and Audit
Maintain a responsibility assignment matrix (RACI chart) that documents who is responsible for each control. This is crucial for compliance audits. For example, during a SOC 2 audit, the auditor will ask for evidence that the customer has implemented access controls. The provider can provide a SOC 2 report for their portion, but the customer must show their own controls. The exam may test that the customer retains responsibility for audit evidence related to their actions.
Enterprise Scenario 1: Healthcare Company Moving to AWS
A healthcare company needs to host a patient records application that must comply with HIPAA. They choose AWS IaaS (EC2) to have full control over the OS and database. The shared responsibility model dictates that AWS is responsible for the physical security of data centers, network infrastructure, and hypervisor security. The company is responsible for securing the EC2 instances (patching the OS), configuring security groups to restrict access, encrypting data at rest (using AWS KMS), and encrypting data in transit (TLS). They must also sign a Business Associate Addendum (BAA) with AWS. In production, they use AWS Config to monitor configuration changes and AWS CloudTrail for audit logs. A common misconfiguration is leaving an S3 bucket public—this is the customer's fault. The company learned this the hard way when a misconfigured S3 bucket exposed patient data. They now use S3 Block Public Access and automated policies. Performance considerations include ensuring that encryption does not introduce latency; they use instance types with hardware acceleration for encryption.
Enterprise Scenario 2: Retail Company Using SaaS for Email
A retail company uses Microsoft 365 (SaaS) for email and collaboration. Under the shared responsibility model, Microsoft handles the application, operating system, physical infrastructure, and most security controls (e.g., anti-malware, spam filtering). The company is responsible for managing user accounts, enforcing multi-factor authentication (MFA), classifying data, and ensuring that their devices are secure. They also control data retention policies. In production, they configure Conditional Access policies to require MFA for remote users. A common problem is that employees use weak passwords, leading to account compromise. The company implements Azure AD Password Protection to block common passwords. They also use Microsoft Defender for Office 365 to protect against phishing. The shared responsibility model clarifies that if a user's device is infected and credentials are stolen, the company is responsible, not Microsoft. Scale considerations include the number of users and licensing tiers—some security features require higher-tier licenses.
Scenario 3: Financial Services Using PaaS for Application Development
A financial services firm develops a trading application using Google App Engine (PaaS). Google manages the runtime, operating system, and scaling. The firm is responsible for the application code, data, and access management. They use Cloud IAM to control who can deploy code and access logs. They must also encrypt sensitive data using Cloud KMS. In production, they use Cloud Security Scanner to find application vulnerabilities. A common issue is that developers hardcode API keys in the source code—this is a customer responsibility to avoid. The firm uses Secret Manager to store keys. Performance considerations include automatic scaling; the firm sets max instances to control costs. The shared responsibility model ensures they know that Google patches the underlying platform, but they must update their own dependencies. A misconfiguration could expose the app to SQL injection—the firm must use parameterized queries in their code.
What 220-1101 Tests on the Shared Responsibility Model
The CompTIA A+ 220-1101 exam covers the Shared Responsibility Model under Objective 4.2: "Compare and contrast cloud computing concepts." Specifically, you need to know:
The division of responsibilities for IaaS, PaaS, and SaaS.
That the customer is always responsible for their data and user access.
That the provider is responsible for physical security of data centers.
How the model applies to public, private, and hybrid clouds.
Top Wrong Answers and Why Candidates Choose Them
"The cloud provider is responsible for all security." This is the most common wrong answer. Candidates assume that moving to the cloud offloads all security. In reality, the customer retains responsibility for data, access, and (in IaaS) OS and apps. The exam will present a scenario where a company has a breach due to weak passwords—the customer is liable.
"In IaaS, the provider patches the operating system." This is false. In IaaS, the customer manages the OS, including patching. Only in PaaS and SaaS does the provider patch the OS. The exam may ask who is responsible for patching an EC2 instance—the answer is the customer.
"In SaaS, the provider is responsible for user data." Incorrect. Even in SaaS, the customer owns and is responsible for their data. The provider secures the application, but the customer must classify and encrypt data. A scenario where a user uploads sensitive data without encryption—the customer is responsible.
"The shared responsibility model is the same for all providers." False. While principles are similar, each provider defines their model contractually. The exam may test that you need to read the provider's documentation. However, for the exam, the general CompTIA model is used.
Specific Numbers, Values, and Terms
Three service models: IaaS, PaaS, SaaS.
Customer responsibilities: Data, access, OS (IaaS), applications (IaaS/PaaS).
Provider responsibilities: Physical security, network, hypervisor.
Key term: "Security OF the cloud" vs. "security IN the cloud."
Deployment models: Public, private, hybrid, community.
Edge Cases and Exceptions
Containers: In container services like Amazon ECS, the provider manages the orchestration; the customer manages the container image and application security.
Serverless: In AWS Lambda, the provider manages the runtime; the customer manages the function code and data.
Hybrid cloud: Responsibilities may split across on-premises and cloud. For example, a company may own the hardware on-premises but use cloud services for backup. The provider is responsible for their infrastructure; the company is responsible for theirs.
How to Eliminate Wrong Answers
If the question involves physical security, the provider is always responsible.
If the question involves data or user access, the customer is always responsible.
If the question involves patching an OS, determine the service model: IaaS = customer, PaaS/SaaS = provider.
If the question asks who is responsible for a misconfiguration (e.g., open security group), the customer is responsible.
Use the mnemonic: "Customer owns data and access; provider owns the stack up to a point."
The customer is ALWAYS responsible for their data and user access, regardless of service model.
In IaaS, the customer patches the OS; in PaaS and SaaS, the provider patches the OS.
The provider is responsible for physical security of data centers, network infrastructure, and hypervisor security.
The shared responsibility model is contractual and varies by provider; always read the provider's documentation.
In SaaS, the provider manages the application, but the customer manages data, user accounts, and device security.
Misconfigurations (e.g., open security groups, public S3 buckets) are the customer's responsibility.
Compliance requirements (HIPAA, GDPR) require mapping controls to the responsible party.
The model applies to all cloud deployment models: public, private, hybrid, and community.
These come up on the exam all the time. Here's how to tell them apart.
IaaS (e.g., AWS EC2)
Customer manages OS, including patches and updates.
Customer manages middleware and runtime.
Customer manages applications and data.
Provider manages hypervisor, physical servers, and network.
More flexibility but more responsibility.
PaaS (e.g., Google App Engine)
Provider manages OS, including patches and updates.
Provider manages middleware and runtime.
Customer manages applications and data.
Provider manages the platform stack.
Less flexibility but less responsibility.
Public Cloud
Provider owns and manages physical infrastructure.
Provider responsible for physical security.
Customer responsible for data and access.
Multi-tenant environment.
Shared responsibility model clearly defined by provider.
Private Cloud
Organization owns and manages physical infrastructure (or colocation).
Organization responsible for physical security (or colocation provider).
Customer responsible for data and access.
Single-tenant environment.
Shared responsibility model may be more complex if using colocation.
Mistake
The cloud provider is responsible for all security in the cloud.
Correct
The provider secures the physical infrastructure, hypervisor, and network. The customer is responsible for their data, user access, and (in IaaS) OS and applications. For example, if a customer leaves an S3 bucket public, that is the customer's misconfiguration, not AWS's.
Mistake
In IaaS, the provider patches the operating system.
Correct
In IaaS, the customer manages the guest OS, including patching. The provider only patches the hypervisor. The exam may ask: 'Who is responsible for patching an EC2 instance?' Answer: the customer.
Mistake
In SaaS, the provider is responsible for user data.
Correct
The customer always owns and is responsible for their data. In SaaS, the provider secures the application, but the customer must classify data, apply encryption, and manage access. For example, in Office 365, Microsoft does not control who accesses your data—you do via Azure AD.
Mistake
The shared responsibility model is standardized across all cloud providers.
Correct
Each provider defines its own model in their service agreements. While the general principles are similar (provider secures infrastructure, customer secures data), specific controls may differ. For example, AWS and Azure have slightly different responsibility for container services.
Mistake
In a private cloud, the organization has no responsibilities.
Correct
In a private cloud, the organization typically manages everything, including physical infrastructure, unless they outsource. The shared responsibility model still applies: if the organization owns the data center, they are responsible for physical security. If they use a colocation provider, the provider handles physical security of the facility.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
In IaaS, the customer is responsible for patching the operating system. The cloud provider patches the hypervisor and underlying infrastructure. For example, if you run an EC2 instance with Windows Server, you must install Windows updates. The exam may test this by asking who is responsible for a vulnerability that results from an unpatched OS—the answer is the customer.
The provider offers encryption tools (e.g., AWS KMS, Azure Key Vault), but the customer is responsible for enabling and managing encryption. The provider may encrypt data at rest by default in some services (e.g., S3 server-side encryption), but the customer controls the keys. The customer must also encrypt data in transit using TLS. The exam may ask: 'Who is responsible for ensuring data is encrypted?' Answer: the customer.
Security OF the cloud refers to the provider's responsibility to secure the cloud infrastructure—physical data centers, hardware, software, and networking. Security IN the cloud refers to the customer's responsibility to secure their data, applications, and access within that infrastructure. This distinction is central to the shared responsibility model. The exam may use this phrasing to differentiate responsibilities.
In a hybrid cloud, the responsibilities are split between the on-premises environment and the cloud provider. The organization is responsible for their on-premises infrastructure, including physical security, hardware, and networking. The cloud provider is responsible for their cloud infrastructure. The customer remains responsible for data and access across both environments. For example, if data is stored on-premises and in the cloud, the customer must secure both locations.
Compliance is a shared responsibility. The provider is responsible for the security of the cloud, which may be certified (e.g., SOC 2, ISO 27001). The customer is responsible for using the cloud in a compliant manner, such as configuring access controls and encryption. For example, under HIPAA, the customer must sign a BAA with the provider and implement controls for ePHI. The exam may test that the customer retains compliance responsibility for their actions.
If the hypervisor is compromised, the provider is responsible because hypervisor security is part of security OF the cloud. The provider must patch the vulnerability and notify customers. The customer is not responsible for fixing the hypervisor. However, the customer should still follow best practices like encrypting data to mitigate impact. The exam may ask: 'Who is liable if a hypervisor vulnerability is exploited?' Answer: the provider.
Yes. In serverless computing (e.g., AWS Lambda), the provider manages the runtime, operating system, and infrastructure. The customer is responsible for the function code, data, and access management. The provider patches the underlying platform, but the customer must ensure their code is secure (e.g., no SQL injection). The exam may ask who is responsible for a vulnerability in the code—the customer.
You've just covered Shared Responsibility Model — now see how well it sticks with free 220-1101 practice questions. Full explanations included, no account needed.
Done with this chapter?