1.1.1. The Cloud Services Model Behind M365
š” First Principle: Microsoft 365 is built on a Software-as-a-Service (SaaS) model ā Microsoft runs the infrastructure, you configure and govern the application layer. What you control is access, policy, and data; what Microsoft controls is uptime, patching, and hardware.
Think of it like renting furnished office space. The landlord (Microsoft) maintains the building, the plumbing, and the electrical. You decide who gets a key, which rooms they can enter, and what they're allowed to do inside. You don't fix the pipes ā but you are responsible for what happens in your space.
This has a direct exam implication: when a question asks "who is responsible for X," apply the shared responsibility model:
| Layer | Who's Responsible |
|---|---|
| Physical infrastructure, network, hypervisor | Microsoft |
| Operating system (for SaaS) | Microsoft |
| Application availability and security patches | Microsoft |
| Identity configuration (who gets access) | Your organization |
| Data classification and protection policies | Your organization |
| User licensing and feature enablement | Your organization |
Microsoft 365 services are grouped under a tenant ā a dedicated, isolated instance of M365 services that belongs to your organization. Every user, every policy, every piece of data lives within your tenant. When you configure something in an admin center, you're configuring it for your tenant.
ā ļø Exam Trap: The shared responsibility model shifts depending on service type. In SaaS (M365), you own identity and data. In IaaS (Azure VMs), you also own the OS and runtime. AB-900 is purely SaaS-focused ā don't apply IaaS thinking here.
Reflection Question: A user complains they can't access a newly assigned app. You check and the license is correctly assigned. What layer of the shared responsibility model do you investigate next, and why?
