SC-900Chapter 18 of 103Objective 1.1

Shared Responsibility Model in Azure

This chapter covers the Shared Responsibility Model in Microsoft Azure, a fundamental concept for the SC-900 exam. Understanding who secures what—the cloud provider versus the customer—is critical because roughly 15-20% of exam questions test your ability to apply this model to different service types (IaaS, PaaS, SaaS). You will learn the exact division of responsibilities for each service model, how it changes with on-premises hybrid scenarios, and common misconceptions that lead to wrong answers. Master this, and you will confidently eliminate the trap answers on exam day.

25 min read
Intermediate
Updated May 31, 2026

Building Security: Landlord vs. Tenant

Imagine you rent an apartment in a high-rise building. The landlord owns the building structure—the foundation, roof, hallways, elevators, and the building's main entrance door. The landlord is responsible for ensuring the building's structural integrity, maintaining common areas, and installing a security camera at the main entrance. However, the landlord does not have keys to your apartment. You, as the tenant, are responsible for locking your apartment door, setting your own alarm system, and securing your personal belongings. If you leave your front door unlocked, the landlord is not liable for theft. This mirrors the shared responsibility model in cloud computing: the cloud provider (landlord) secures the physical infrastructure and the underlying platform, while the customer (tenant) secures their data, identities, and access configurations. The boundary of responsibility shifts depending on the service model—just as a tenant in a fully furnished serviced apartment has less to manage than one in an unfurnished unit. In IaaS, the customer manages more (like a tenant who paints walls and installs fixtures), while in SaaS, the provider manages almost everything (like a fully managed hotel room).

How It Actually Works

What is the Shared Responsibility Model?

The Shared Responsibility Model is a security and compliance framework that defines the division of security obligations between a cloud service provider (CSP) and the customer. It exists because moving to the cloud does not mean the provider is responsible for everything—the customer always retains some control and therefore some responsibility. The model is not static; it shifts based on the cloud service model (IaaS, PaaS, SaaS), the deployment model (public, private, hybrid), and the workload architecture.

Why It Exists

Before cloud computing, organizations owned the entire stack—physical hardware, network, operating systems, applications, and data. They bore 100% of the security responsibility. In the cloud, the provider takes on portions of that stack, but the customer remains accountable for elements they control. The model prevents the dangerous assumption that "the cloud provider secures everything." For example, if a customer misconfigures a database firewall, the provider's physical security does not protect the data. The model clarifies that security is a partnership.

How It Works Internally

Microsoft Azure uses a layered responsibility matrix. At the physical layer, Microsoft secures datacenters, hardware, and the network backbone. At the abstracted layers, responsibilities are split:

Physical hosts and network: Microsoft is always responsible. This includes datacenter access controls, hardware patching, and network infrastructure.

Virtualization platform: Microsoft manages the hypervisor (Azure Hyper-V) and virtual network fabric.

Guest OS and applications: Responsibility depends on the service model. In IaaS, the customer manages the guest OS, applications, and data. In PaaS, Microsoft manages the runtime and OS, but the customer manages application code and data. In SaaS, Microsoft manages almost everything except data, identities, and device compliance.

Key Components and Defaults

IaaS (Infrastructure as a Service): Customer manages guest OS, applications, data, network controls (NSGs, firewalls), and identity. Microsoft manages physical hardware, hypervisor, and physical network. Default: Customer has full control of the VM, but also full responsibility for securing it.

PaaS (Platform as a Service): Microsoft manages OS, runtime, middleware, and infrastructure. Customer manages application code, data, and identity. Example: Azure App Service—Microsoft patches the web server, but the customer writes secure code and manages database credentials.

SaaS (Software as a Service): Microsoft manages the entire application stack. Customer manages data, identities, and endpoint devices. Example: Microsoft 365—Microsoft secures Exchange Online, but the customer must enable MFA and manage user permissions.

Configuration and Verification

There is no single command to "configure" the shared responsibility model—it is a design principle. However, you can verify boundaries using:

Azure Security Center / Microsoft Defender for Cloud: Shows security posture and identifies misconfigurations that fall under customer responsibility.

Azure Policy: Enforces compliance rules on customer-managed resources.

Service Trust Portal: Provides audited documentation of Microsoft's responsibilities (SOC 2, ISO 27001).

Interaction with Related Technologies

Azure Active Directory (Azure AD): Customer responsibility for identity management—configuring MFA, conditional access, and user permissions. Microsoft provides the service, but the customer secures it.

Azure Key Vault: Customer manages keys and secrets; Microsoft secures the hardware security modules (HSMs).

Network Security Groups (NSGs): Customer defines rules; Azure enforces them at the virtual network layer.

Azure Policy and RBAC: Customer defines policies and roles; Azure enforces them.

On-Premises Hybrid Scenarios

In hybrid deployments (e.g., Azure Stack, Azure Arc), the model splits by location. The customer is responsible for the on-premises physical hardware and software; Microsoft is responsible for the cloud side. The boundary is the network connection—typically a VPN or ExpressRoute.

Common Exam Traps

Trap 1: "Microsoft is responsible for all security in SaaS." Reality: The customer still secures data, identities, and device compliance.

Trap 2: "In IaaS, Microsoft secures the guest OS." Reality: The customer secures the guest OS; Microsoft secures the hypervisor.

Trap 3: "The model is the same for all cloud services." Reality: It varies by service model, deployment model, and workload.

Specific Values and Terms

Always Microsoft: Physical datacenters, hardware, network infrastructure, hypervisor.

Always Customer: Data, identities, endpoints (devices), and configuration of customer-managed resources.

Variable: Guest OS, applications, network controls—depends on service model.

Edge Cases

Containers: In Azure Kubernetes Service (AKS), Microsoft manages the control plane; the customer manages worker nodes and container security.

Serverless: In Azure Functions, Microsoft manages the runtime; the customer manages code and data.

Azure VMware Solution: Customer manages the VMware environment; Microsoft manages the underlying Azure infrastructure.

Walk-Through

1

Identify the Service Model

Determine whether the workload uses IaaS, PaaS, or SaaS. This is the first and most critical step because it defines the baseline split. For example, an Azure VM is IaaS, Azure App Service is PaaS, and Microsoft 365 is SaaS. The exam often provides a scenario and asks you to identify the correct responsibility boundary. Look for keywords: 'virtual machine' (IaaS), 'web app' (PaaS), 'Office 365' (SaaS).

2

Determine the Deployment Model

Identify if the deployment is public cloud, private cloud, hybrid, or multi-cloud. Hybrid models add complexity because on-premises components are fully customer-managed. For example, an Azure Arc-connected server means the customer secures the on-premises OS and applications, while Azure secures the cloud management plane. The exam may test that the customer retains responsibility for on-premises hardware even when using Azure services.

3

Map the Responsibility Layers

List the layers from physical infrastructure to data. For each layer, decide if Microsoft, the customer, or both share responsibility. Use the standard matrix: Physical security (Microsoft), Hypervisor (Microsoft), Guest OS (customer for IaaS, Microsoft for PaaS), Application (customer for IaaS/PaaS, Microsoft for SaaS), Data (customer always), Identity (customer always). This mapping is the core of the model.

4

Identify Customer-Managed Controls

For layers where the customer has responsibility, identify the specific security controls available. In IaaS, this includes configuring NSGs, firewalls, OS hardening, anti-malware, and access controls. In PaaS, it includes application code security, data encryption at rest (customer-managed keys), and identity management. The exam will ask which controls the customer must configure in a given scenario.

5

Verify with Compliance Frameworks

Use the Service Trust Portal or Azure Policy to confirm that the customer's responsibilities align with regulatory requirements (e.g., GDPR, HIPAA). Microsoft provides documentation of their controls, but the customer must implement complementary controls. The exam may test that the customer is responsible for achieving compliance for their data, even if Microsoft provides a compliant platform.

What This Looks Like on the Job

Enterprise Scenario 1: Financial Services Migration to IaaS

A bank migrates its trading application to Azure VMs (IaaS). The bank's security team must harden the Windows Server guest OS, apply security patches, configure NSGs to restrict inbound traffic to only the trading front-end, and enable BitLocker for data encryption. Microsoft secures the physical datacenter and hypervisor. A common mistake: the bank assumes Microsoft will patch the OS, leading to unpatched vulnerabilities. In production, the bank uses Azure Update Management to schedule patching. Scale: 500 VMs. Performance consideration: NSG rules are evaluated for every packet; too many rules can add latency. Misconfiguration: leaving RDP open to the internet (port 3389) leads to brute-force attacks—this is the customer's fault, not Microsoft's.

Enterprise Scenario 2: Healthcare SaaS with Microsoft 365

A hospital uses Microsoft 365 for email and collaboration. Microsoft secures the Exchange Online and SharePoint services, including physical security, server patching, and DLP policies. The hospital must manage user identities (Azure AD), enable MFA, configure conditional access policies to block access from untrusted locations, and classify sensitive patient data. The hospital also manages its own devices (endpoints) by enrolling them in Intune. A common issue: a doctor uses a personal device that is not compliant, leading to data leakage. The hospital must enforce device compliance policies—Microsoft does not do this automatically. Scale: 10,000 users. Misconfiguration: not enabling MFA leads to credential theft.

Enterprise Scenario 3: Hybrid Retail with Azure Arc

A retail chain runs its inventory management system on-premises but uses Azure Arc to manage and secure it from the cloud. The customer is responsible for the on-premises server hardware, OS, and application. Microsoft provides the management plane and security updates via Arc. A challenge: the customer must maintain physical security of their datacenter, which is not trivial. Misconfiguration: failing to apply security updates to the on-premises servers, thinking Azure Arc will do it automatically. Azure Arc does not patch the OS—it only provides visibility and policy enforcement.

How SC-900 Actually Tests This

What SC-900 Tests

The SC-900 exam objective 1.1 Describe the shared responsibility model is tested in approximately 15-20% of questions. You must be able to:

Identify which party (Microsoft or customer) is responsible for specific security layers (physical, infrastructure, OS, application, data, identity).

Apply the model to different service types (IaaS, PaaS, SaaS).

Recognize that the customer is always responsible for data, identities, and endpoints.

Understand that the model varies by deployment model (public, hybrid, on-premises).

Common Wrong Answers and Why Candidates Choose Them

1.

"In SaaS, Microsoft is responsible for everything." Candidates assume that since the application is managed, the customer has no security duties. Reality: The customer secures data, identities, and device compliance. For example, in Microsoft 365, the customer must enable MFA and classify data.

2.

"In IaaS, Microsoft secures the guest operating system." Candidates confuse the hypervisor with the guest OS. Microsoft secures the hypervisor; the customer secures the guest OS.

3.

"The shared responsibility model applies only to public cloud." Candidates think on-premises or hybrid means no sharing. Reality: Hybrid models still share—Microsoft secures the cloud side; the customer secures the on-premises side.

4.

"The customer is responsible for physical security in IaaS." Candidates overestimate customer control. Physical security is always the provider's responsibility.

Specific Exam Terms and Numbers

Always customer: Data, identities, endpoints.

Always Microsoft: Physical datacenters, hardware, network infrastructure, hypervisor.

Variable: Guest OS (customer in IaaS, Microsoft in PaaS), application (customer in IaaS/PaaS, Microsoft in SaaS), network controls (customer in IaaS, shared in PaaS).

Edge Cases and Exceptions

Azure VMware Solution: Customer is responsible for the VMware environment (guest OS, applications, data). Microsoft manages the underlying Azure infrastructure.

Azure Kubernetes Service (AKS): Microsoft manages the control plane; the customer manages worker nodes and container security.

Serverless (Azure Functions): Microsoft manages the runtime; the customer manages code and data.

How to Eliminate Wrong Answers

When you see a question about responsibility, ask: "Who controls the layer?" If the customer configures it, they are responsible. For example, if the question mentions 'configuring a firewall rule' on a VM, that is customer responsibility. If it mentions 'patching the hypervisor,' that is Microsoft's. Use the matrix: data, identity, endpoints → customer; physical, hypervisor → Microsoft; OS, app, network → it depends.

Key Takeaways

The shared responsibility model defines who secures what: Microsoft secures the cloud infrastructure; the customer secures their data, identities, and endpoints.

In IaaS, the customer manages the guest OS, applications, and network controls; Microsoft manages the hypervisor and physical hardware.

In PaaS, Microsoft manages the OS and runtime; the customer manages application code and data.

In SaaS, Microsoft manages the entire application stack; the customer manages data, identities, and device compliance.

The customer is ALWAYS responsible for their own data, identities, and endpoints, regardless of service model.

Microsoft is ALWAYS responsible for physical datacenters, hardware, and the hypervisor.

The model varies by service type, deployment model, and workload architecture—it is not one-size-fits-all.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

IaaS (Infrastructure as a Service)

Customer manages guest OS, applications, and data.

Customer configures network controls like NSGs and firewalls.

Microsoft manages physical hardware, hypervisor, and physical network.

Example: Azure Virtual Machines.

Higher customer responsibility for security.

PaaS (Platform as a Service)

Microsoft manages OS, runtime, and middleware.

Customer manages application code and data.

Microsoft manages underlying infrastructure and platform.

Example: Azure App Service.

Lower customer responsibility for infrastructure, but still responsible for app security.

Watch Out for These

Mistake

In SaaS, Microsoft is responsible for all security, including data protection.

Correct

The customer is always responsible for their data. Microsoft secures the service, but the customer must manage data classification, access controls, and encryption keys. For example, in Microsoft 365, the customer must enable MFA and configure DLP policies.

Mistake

In IaaS, Microsoft patches the guest operating system.

Correct

The customer is responsible for patching the guest OS. Microsoft patches the hypervisor and physical hardware. The customer must configure update management for their VMs.

Mistake

The shared responsibility model is the same for all cloud services.

Correct

The model varies by service model (IaaS, PaaS, SaaS) and deployment model (public, hybrid, on-premises). In IaaS, the customer has more responsibility; in SaaS, Microsoft has more.

Mistake

If the datacenter is physically secure, the customer's data is automatically secure.

Correct

Physical security is only one layer. The customer must also secure network access, identity, and data. A misconfigured database firewall can expose data even in a physically secure datacenter.

Mistake

Hybrid deployments mean the customer is responsible for everything on-premises, and Microsoft for everything in the cloud.

Correct

That is essentially correct, but the boundary is the network connection. The customer secures on-premises hardware and software; Microsoft secures the cloud side. However, Azure Arc extends some management, but not security responsibility.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

Who is responsible for patching the guest OS in an Azure VM?

The customer is responsible for patching the guest OS in an Azure VM (IaaS). Microsoft patches the hypervisor and physical hosts. The customer can use Azure Update Management or manual patching. The exam tests that the customer must manage OS security updates.

The customer is responsible for enabling MFA in Microsoft 365. Microsoft provides the MFA service, but the customer must configure it for users. The exam emphasizes that identity security is a customer responsibility even in SaaS.

What is the shared responsibility model for Azure SQL Database (PaaS)?

For Azure SQL Database (PaaS), Microsoft manages the server OS, database engine, and infrastructure. The customer manages the data, schema, access controls (logins, users), and encryption keys (if using customer-managed keys). The exam tests that the customer secures the data and access.

Does the shared responsibility model apply to on-premises workloads connected via Azure Arc?

Yes. For on-premises workloads managed by Azure Arc, the customer is responsible for the on-premises hardware, OS, and applications. Microsoft provides the management plane and security monitoring. The exam may test that the customer retains full responsibility for their on-premises environment.

Who is responsible for physical security in Azure datacenters?

Microsoft is fully responsible for physical security of Azure datacenters, including access controls, surveillance, and environmental controls. The customer never has physical access. The exam tests that physical security is always Microsoft's responsibility.

Can the customer be responsible for network security in PaaS?

Yes, partially. In PaaS, Microsoft manages the underlying network, but the customer can configure network controls like Azure Firewall, NSGs (if using VNet integration), and service endpoints. The exam tests that the customer can implement network security for their PaaS resources.

What is the most common exam trap regarding shared responsibility?

The most common trap is assuming that in SaaS, the customer has no security responsibilities. The exam will present a scenario where a SaaS application is compromised due to weak customer passwords, and ask who is at fault. The answer is the customer, because identity management is always customer responsibility.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Shared Responsibility Model in Azure — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.

Done with this chapter?