This chapter covers the Shared Responsibility Model — how security and management responsibilities are divided between Azure and the customer. AZ-900 tests this under objective 1.1, and it's a concept that recurs throughout the exam whenever security or compliance comes up.
Jump to a section
A simple way to picture The Shared Responsibility Model
In an apartment building, the landlord is responsible for the building's structure, roof, and shared utilities — things a tenant can't control. The tenant, meanwhile, is responsible for locking their own door, not leaving valuables in plain sight, and how they use the space inside their unit. Both parties share responsibility for the building's overall security, but for different parts of it. The Shared Responsibility Model works the same way in the cloud: Azure is responsible for securing the underlying physical infrastructure (the "building"), while the customer remains responsible for securing what they put inside it (their "apartment") — their data, access controls, and how they configure their own resources.
What the Shared Responsibility Model is
The Shared Responsibility Model describes how security and operational responsibilities are divided between the cloud provider (Azure) and the customer. Some responsibilities always belong to Azure (physical security of data centers, for example), some always belong to the customer (their own data and access management), and some shift depending on which service model is used.
How responsibility shifts by service model
With on-premises infrastructure, the customer is responsible for everything — physical hardware, operating system, applications, and data.
With Infrastructure as a Service (IaaS), Azure takes on responsibility for the physical infrastructure, while the customer remains responsible for the operating system, applications, and data.
With Platform as a Service (PaaS), Azure additionally manages the operating system and runtime, leaving the customer responsible mainly for their application and data.
With Software as a Service (SaaS), Azure (or the software vendor) manages nearly everything except the customer's own data and access configuration.
What's always the customer's responsibility
Regardless of service model, the customer is always responsible for their own data, endpoint devices, account and identity management, and access permissions. Physical security of the data center, by contrast, is always Azure's responsibility, never the customer's.
Why this matters
Understanding where responsibility shifts helps organizations know what they still need to actively manage — a common real-world security gap is assuming the cloud provider is transparently handling something (like access control configuration) that actually remains the customer's job.
Identify the service model in use
IaaS, PaaS, and SaaS each shift the responsibility line differently — knowing which model applies is the first step in understanding who's responsible for what.
Confirm what's always the provider's responsibility
Physical security of the data center and the underlying infrastructure are always Azure's responsibility, regardless of service model.
Confirm what's always the customer's responsibility
Data classification, access management, and endpoint security remain the customer's responsibility in every service model.
Configure what falls in between
Depending on the service model, the customer may also be responsible for the operating system, network controls, or application-level configuration — this is the part that varies and requires the most attention.
A company using Azure virtual machines (IaaS) is responsible for patching the operating system on those VMs — Azure doesn't automatically do this for them, since the OS layer is the customer's responsibility under IaaS. A company that assumes Azure handles OS patching for IaaS resources can end up running vulnerable, unpatched systems without realizing it.
By contrast, a company using a fully managed PaaS database service doesn't need to patch the underlying database engine — Azure manages that layer — but they're still responsible for who has access to that database and how their application uses it. A common real-world incident pattern is a misconfigured access setting (the customer's responsibility) being mistaken for a provider-side failure.
Objective 1.1 expects candidates to know how responsibility shifts across on-premises, IaaS, PaaS, and SaaS, and which specific responsibilities never shift.
A common wrong answer is assuming Azure is responsible for the customer's data or access management in any service model — that responsibility never shifts to Azure. Another common trap is assuming the customer is responsible for physical data center security — that's always Azure's job, never the customer's, in any model.
Stable terms: Shared Responsibility Model, IaaS, PaaS, SaaS. The pattern of "responsibility moves toward the provider as you go from IaaS to PaaS to SaaS, but data and access always stay with the customer" is the core exam-relevant idea.
Memory trick: no matter which service model, the customer always keeps responsibility for their own data and who can access it; the provider always keeps responsibility for physical security. Everything in between shifts by model.
The Shared Responsibility Model divides security and management responsibilities between Azure and the customer.
Physical data center security is always Azure's responsibility, never the customer's.
The customer's own data, identities, and access management are always the customer's responsibility, regardless of service model.
Responsibility for the operating system and runtime shifts toward Azure as you move from IaaS to PaaS to SaaS.
These come up on the exam all the time. Here's how to tell them apart.
IaaS Responsibility
Customer manages the operating system
Customer manages applications and data
Azure manages physical infrastructure and virtualization
More customer control, more customer responsibility
PaaS Responsibility
Azure manages the operating system and runtime
Customer manages applications and data
Azure manages physical infrastructure, virtualization, and OS
Less customer control, less customer responsibility
Mistake
In the cloud, security is entirely the provider's responsibility.
Correct
Security is shared — the customer always retains responsibility for their own data, identities, and access management, regardless of which service model is used.
Mistake
With PaaS or SaaS, the customer has no security responsibilities at all.
Correct
The customer's responsibilities shrink as more is managed by the provider, but data and access management remain the customer's job in every service model.
Mistake
IaaS means Azure manages the operating system.
Correct
Under IaaS, the customer manages the operating system, applications, and data — Azure manages only the underlying physical infrastructure and virtualization layer.
It's the framework describing how security and management responsibilities are divided between Azure and the customer. Some responsibilities (like physical data center security) always belong to Azure; others (like the customer's own data and access control) always belong to the customer; and some shift depending on whether you're using IaaS, PaaS, or SaaS.
No — data and access management are always the customer's responsibility, in every service model. Azure secures the infrastructure the data runs on, but classifying, protecting, and controlling access to that data remains with the customer.
Under IaaS (which is what a standard Azure VM is), the customer is responsible for patching the operating system — Azure manages only the underlying physical infrastructure and virtualization layer, not the guest OS running inside the VM.
You've just covered The Shared Responsibility Model — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?