2.1 Shared Responsibility Model

Why shared responsibility exists

The shared responsibility model describes which security tasks the cloud provider handles and which tasks remain with you, the customer. Microsoft Learn states it plainly: as you evaluate public cloud services, it is critical to understand which security work transfers to Microsoft and which stays with you. In an on-premises datacenter you own the entire stack — the building, physical network, physical hosts, the operating system, applications, identities, and data. As workloads move to the cloud, some of that work transfers to Microsoft, but the transfer is partial and depends on the service model.

The model matters for SC-900 because it underlies almost every later decision: which Microsoft Entra, Defender, and Purview capability you must configure yourself versus what Microsoft operates for you. A candidate who internalizes the direction of the responsibility shift can answer a large family of 'who is responsible for X?' questions without memorizing every control.

The three cloud service models

Microsoft Learn defines the three models by what you manage:

• IaaS (Infrastructure as a Service): You manage virtual machines, operating systems, and applications. Examples: Azure Virtual Machines, Azure Disk Storage, virtual networks.
• PaaS (Platform as a Service): You deploy applications without managing VMs or operating systems. Examples: Azure App Service, Azure Functions, Azure SQL Database, Azure Storage.
• SaaS (Software as a Service): You use ready-made applications. Examples: Microsoft 365, Dynamics 365.

Many real Azure solutions combine models, but the exam tests the clean cases.

The responsibility matrix

Microsoft publishes a responsibility matrix showing who owns each layer per deployment type. Memorizing the pattern is exam gold:

Read the table top-down: the top three rows are always Customer, the bottom three (physical layers) flip to Microsoft the moment you leave on-premises, and the middle rows transition as the service becomes more managed. Note the precise cells the exam loves: the operating system becomes Microsoft's at PaaS, network controls become Microsoft's only at SaaS, and client devices become Shared (not fully Microsoft) at SaaS.

Responsibilities you ALWAYS retain

Regardless of deployment type, Microsoft Learn says you always keep four responsibilities:

1. Data — classification, protection, encryption decisions, and data-governance compliance.
2. Endpoints — protecting client devices (mobiles, laptops, desktops) that access cloud services.
3. Accounts — creating, managing, and removing user accounts.
4. Access management — RBAC, multifactor authentication, and Conditional Access policies.

A shorter mnemonic many use is 'you always own your data and identities.' These are the highest-value SC-900 cues: if a scenario asks who classifies sensitive data, manages permissions, secures laptops, or enforces MFA, the answer is the customer.

Selection scenarios and traps

Which side is responsible? Use this reasoning pattern:

• Physical datacenter security for a SaaS service? -> Microsoft. The provider owns facilities, physical hosts, and physical network in every cloud model.
• Who decides who can read sensitive records in a SaaS app? -> Customer (access management never transfers).
• Who patches the guest operating system on an Azure VM (IaaS)? -> Customer — at IaaS the OS row is still yours; at PaaS it would be Microsoft.
• Who manages network firewalls in PaaS? -> Shared — Microsoft provides baseline network security, you configure application-level controls.

The big trap

The classic wrong answer is that 'moving to the cloud means Microsoft handles all security.' It does not. Cloud adoption changes the split of tasks; it does not remove customer accountability. A misconfigured tenant, an over-permissive role assignment, or a compromised identity can expose resources even when Microsoft's underlying platform is perfectly secure. Microsoft Learn frames the cloud advantage as shifting day-to-day infrastructure burden to the provider so you can reallocate effort to data protection, identity governance, and monitoring — not as eliminating your duties.

Why the cloud still helps

The doc notes that on-premises organizations often have unmet responsibilities due to limited resources: delayed patching, weak physical security, incomplete monitoring, outdated hardware, and untested backups. By shifting infrastructure work to Microsoft, you reduce these gaps and can use cloud-scale intelligence to improve detection and response. For SC-900, hold two ideas at once: the cloud meaningfully reduces infrastructure risk, yet you still own data, identities, endpoints, and configuration choices everywhere.

A note on AI workloads

Microsoft Learn now extends the model to AI services. For AI workloads, Microsoft secures the AI infrastructure and model hosting, while you remain accountable for how AI is applied: protecting sensitive data, managing prompt security, and meeting regulatory requirements. The pattern matches the traditional model — Microsoft owns the platform, you own your data and how you use it. Remember too that the model describes security tasks, not legal ownership: you always own your data and identities, and the matrix simply tells you which protective work is yours versus Microsoft's at each layer.