Cloud FoundationsAWS SAA-C03AZ-104Security+

Shared Responsibility Model Explained for AWS, Azure, and Security+

Moving to the cloud does not mean handing security to someone else. It means the responsibilities are divided, and misunderstanding that division is exactly what leads to breaches. The shared responsibility model defines what the cloud provider secures and what you secure. AWS calls this security of the cloud versus security in the cloud. Azure uses similar language. On every cloud certification, you will see scenarios that ask who is responsible for a specific control. The answer is almost always: it depends on which service model you are using.

6 min

3 sections · 5 exam key points

5 practice questions

What the cloud provider is always responsible for

The cloud provider is responsible for the physical infrastructure without exception. The data centers, the physical servers, the networking equipment, the power systems, the cooling, the physical security of the facilities. You will never patch a hypervisor or replace a failed hard drive in AWS. This is not configurable or optional. It is baked into every service you use.

The provider also manages the global network that connects their data centers, the hardware and software of the virtualization layer, and the managed services infrastructure. In AWS, S3's underlying storage hardware, the Lambda runtime environment, and the RDS database engine patching are all provider responsibilities.

What you are always responsible for

Your data is always your responsibility, regardless of service model. Encrypting it, classifying it, controlling who can access it, ensuring it complies with regulations. The cloud provider gives you tools to do this (encryption, access controls, compliance frameworks) but the decision to use them is yours.

Identity and access management is always your responsibility. The provider gives you IAM tools, but who you give access to, what permissions they receive, and whether you enforce MFA are all decisions you make. Credential compromise is the most common cause of cloud breaches, and it is never the provider's fault when it happens.

The responsibility for operating system configuration, network configuration, application code, and data classification shifts based on service model. In IaaS, you own all of it. In PaaS, you own the application and data. In SaaS, you own only the data and access controls. This sliding scale is the core of the shared responsibility model.

How to choose the correct answer

Provider is always responsible: physical hardware, data center facilities, hypervisor, global network infrastructure, managed service engines.

Customer is always responsible: data classification and encryption, IAM configuration and access controls, client-side encryption, regulatory compliance of data.

Depends on service model: OS patching = customer in IaaS, provider in PaaS/SaaS. Network configuration = customer in IaaS, varies in PaaS, provider in SaaS. Application code = customer in IaaS and PaaS, provider in SaaS.

Encryption: encryption at rest of customer data is a shared control. The provider offers the encryption capability (S3 SSE, Azure SSE). The customer decides whether to enable it, what key type to use, and who has access to the keys.

Key exam facts — AWS SAA-C03 / AZ-104 / Security+

Provider always responsible: physical hardware, data centers, hypervisor, managed service engines.
Customer always responsible: data, IAM configuration, client-side encryption, compliance decisions.
Shared controls: encryption at rest (provider offers it, customer enables and manages keys).
IaaS: customer manages OS and above. PaaS: customer manages app and data. SaaS: customer manages data and access.
Misapplying this model is the root cause of most cloud security misconfigurations.

Common exam traps

The cloud provider is responsible for securing customer data.

The provider secures the infrastructure and tools for data protection. The customer is responsible for classifying data, enabling encryption, configuring access controls, and ensuring compliance. A public S3 bucket exposing sensitive data is always the customer's misconfiguration.

In SaaS, the provider is responsible for all security.

Even in SaaS, the customer is responsible for managing who has access (user accounts, permissions), what data they put into the system, and compliance with regulations that apply to that data. A SaaS provider cannot control how you configure user permissions or what data you upload.

Shared responsibility is the same across all cloud providers.

The general framework is consistent, but specific boundaries vary by provider and by service. AWS, Azure, and GCP each publish their own detailed shared responsibility documentation. Always refer to the specific provider's model for the service in question.

Practice questions — Shared Responsibility

These questions are representative of what you will see on AWS SAA-C03, AZ-104, Security+ exams. The correct answer and explanation are shown immediately below each question.

Q1.A customer runs a web application on AWS EC2. A vulnerability is discovered in the Linux kernel on the EC2 instances. Who is responsible for patching the OS?

A.AWS, because they provide the EC2 service

B.The customer, because EC2 is IaaS and the customer manages the OS

C.Both AWS and the customer share equal responsibility

D.The customer's managed service provider, not AWS

Explanation: EC2 is IaaS. AWS is responsible for the physical host, hypervisor, and underlying infrastructure. The customer is responsible for everything from the guest OS upward — including OS patching, security hardening, application configuration, and data protection. Kernel vulnerabilities on EC2 instances must be patched by the customer.

Q2.A company uses Amazon S3 to store sensitive customer data. An employee misconfigures the bucket to be publicly accessible, exposing the data. Under the shared responsibility model, who is responsible?

A.AWS, because S3 is a managed service

B.The customer, because access control configuration is always the customer's responsibility

C.Both equally, because S3 storage is provider responsibility

D.Neither, because public buckets are an AWS design choice

Explanation: Under the shared responsibility model, the customer is always responsible for data classification, access controls, and configuration of customer-managed resources. AWS provides S3 Block Public Access settings as a safeguard, but enabling or disabling those settings is a customer decision. A misconfigured bucket is always a customer-side failure.

Q3.A company uses Azure SQL Database (a fully managed PaaS database). Who is responsible for patching the SQL Server database engine?

A.The customer, because they manage the database

B.Microsoft, because Azure SQL Database is PaaS and Microsoft manages the platform

C.Both share responsibility for database engine patching

D.A third-party managed service provider

Explanation: Azure SQL Database is PaaS. Microsoft manages the underlying OS, SQL Server engine, patching, backups, and high availability infrastructure. The customer manages the database schema, data, application queries, and access controls. Engine patching moves to the provider in PaaS.

Q4.Which security responsibility remains with the customer regardless of whether they use IaaS, PaaS, or SaaS?

A.Operating system patching

B.Identity and access management configuration

C.Application runtime patching

D.Database engine management

Explanation: Identity and access management (IAM) configuration is always the customer's responsibility. Who gets access, what permissions they receive, whether MFA is enforced, and how credentials are managed are always customer decisions — the cloud provider cannot make these choices for you. OS patching, application runtime, and database management shift to the provider as you move from IaaS to PaaS to SaaS.

Q5.A company enables encryption at rest for their S3 data using AWS-managed keys (SSE-S3). Under the shared responsibility model, how is encryption classified?

A.Fully provider responsibility because AWS manages the keys

B.Fully customer responsibility because the customer's data is being encrypted

C.A shared control: AWS provides the capability, the customer decides to enable it and chooses the key management approach

D.Neither party's responsibility since encryption is automatic

Explanation: Encryption at rest is a shared control. AWS provides multiple encryption options (SSE-S3, SSE-KMS, SSE-C) and the infrastructure to implement them. The customer decides which encryption method to use, whether to enable it, and who controls the encryption keys. The customer's choice of AWS-managed vs customer-managed keys determines the level of customer control over the keys.

Frequently asked questions — Shared Responsibility

What is the AWS shared responsibility model?

AWS describes it as 'security of the cloud' (AWS responsibility) vs 'security in the cloud' (customer responsibility). AWS is responsible for the physical hardware, data centers, hypervisors, and managed service infrastructure. Customers are responsible for their data, identity configuration, OS configuration (in IaaS), application security, and network configuration. The boundary shifts based on the service model: IaaS customers manage more; SaaS customers manage less.

Who is responsible for patching in the cloud?

It depends on the service model. In IaaS (EC2, Azure VM): the customer patches the guest OS and applications. In PaaS (RDS, App Service, Lambda): the provider patches the OS and runtime; the customer patches application code. In SaaS (Microsoft 365, Gmail): the provider patches everything; the customer manages only access and data. OS-level vulnerabilities on EC2 are always the customer's problem.

Is a public S3 bucket AWS's fault or the customer's fault?

A publicly accessible S3 bucket is always the customer's responsibility. AWS provides S3 Block Public Access as a safeguard and enables it by default at the account level. If a customer overrides that setting and makes a bucket public, exposing sensitive data, the shared responsibility model places that configuration decision entirely on the customer. AWS cannot enforce how customers configure their own resources.

How does the shared responsibility model apply to compliance?

The cloud provider maintains compliance certifications (SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP) for their infrastructure. This compliance inheritance means customers deploying on compliant infrastructure can inherit some controls. However, customers are still responsible for their own compliance scope: data classification, access controls, audit logging configuration, data retention, and ensuring their applications meet regulatory requirements.

How is the shared responsibility model tested on AWS SAA-C03 and Security+?

Both exams present scenarios and ask who is responsible for a specific security control. The pattern: physical infrastructure = provider always. Data and IAM = customer always. OS patching = customer (IaaS) or provider (PaaS/SaaS). Application security = customer (IaaS/PaaS) or provider (SaaS). Encryption = shared control (provider offers it, customer enables and manages keys). Knowing these boundaries for specific services (EC2 vs RDS vs Lambda vs S3) is essential.

Practice this topic

AWS SAA-C03practice questions AZ-104practice questions Security+practice questions

Test yourself on Shared Responsibility

JT Exams routes you to questions in your exact weak areas — automatically, after every session.

Free practice test Start 7-Day Free Trial

No credit card · Cancel anytime