Azure Shared Responsibility Across IaaS, PaaS and SaaS

What shared responsibility means

In cloud computing, a provider operates parts of the technology stack while a customer configures and uses services. Shared responsibility describes who is expected to configure, operate, and monitor each control. Moving a workload to Azure transfers some infrastructure tasks to Microsoft; it does not transfer every security, access, or data decision.

Microsoft's Azure guidance says customers always own their data and identities. Customers remain responsible for managing user accounts and access controls, protecting client devices, and configuring the cloud components they control. Microsoft manages underlying physical infrastructure, such as datacenters, hosts, and physical networks. The division for applications, operating systems, and network controls shifts by service model.

Think in layers. Physical facilities and hardware are below the operating system. Above the operating system are applications, configuration, users, and information. A more managed service moves more lower layers to Microsoft. The customer still determines how people access the system, what data is stored, and which settings fit the organization's requirements.

This model is a general guide. Individual Azure services expose different controls and configurations, and a real agreement or service description determines specific obligations. For AZ-900, the candidate should understand the broad shift in responsibility and avoid treating every service as if it were a virtual machine.

IaaS: more customer control and work

Infrastructure as a service provides virtualized computing resources. Azure Virtual Machines are an example. Microsoft operates the physical datacenter, physical network, and physical hosts. The customer manages the virtual machine, guest operating system, deployed applications, data, configurations, identities, and much of the workload's network security.

A company that runs an application on a virtual machine must plan operating-system updates, application patches, backup, access, and network controls. Microsoft keeps the host hardware running, but the customer still has to secure the guest operating system and application. A cloud virtual machine is not a fully managed application simply because Microsoft owns the physical server.

IaaS fits when a team needs operating-system control, wants to migrate a workload with few changes, or must install components not supported by a managed platform. That control carries more operational responsibility. If a team chooses IaaS to preserve legacy settings, it should understand who will patch and monitor the guest environment.

For example, a company moves an internal scheduling application from its datacenter to an Azure VM. Microsoft secures the physical host and datacenter. The company configures the VM, applies operating-system updates, secures the application, manages user accounts, and protects the data. If the application becomes unavailable because the guest OS is not patched or configured, the customer controls the relevant layer.

PaaS: managed platform, customer application

Platform as a service lets a customer deploy an application without managing virtual machines or operating systems. Azure App Service, Azure Functions, Azure SQL Database, and Azure Storage are examples in Microsoft's guidance. Microsoft operates more of the platform stack, while the customer remains responsible for its data, identities, application code, configuration, and access.

PaaS can reduce routine infrastructure work. The customer does not normally patch the underlying operating system as it would for a VM. But the team still needs to secure its code, configure the service, protect data, assign permissions, and monitor the application. A managed runtime does not mean every security or availability decision is made for the customer.

Consider a web application deployed to Azure App Service. Microsoft manages the underlying operating system and platform. The developer chooses code, authentication, data handling, configuration, and network exposure. A misconfigured public endpoint or overprivileged application identity remains a customer-controlled risk even when the hosting platform is managed.

PaaS is useful when a team wants to focus on application behavior and data rather than server maintenance. It can also reduce control over the underlying environment. If the workload requires an operating-system feature not exposed by the platform, IaaS may fit better. The service model is a trade-off between control and operational responsibility.

SaaS: ready-made application, customer data and users

Software as a service is a ready-made application consumed by the customer. Microsoft 365 and Dynamics 365 are examples. Microsoft manages the application infrastructure and more of the service stack. The customer still manages users, data, permissions, configuration, client devices, and appropriate use.

A company using a SaaS collaboration tool does not patch Microsoft's physical hosts or application operating system. It still decides who has accounts, what information may be shared, how access is granted, and how devices are protected. A departing employee whose account remains active is a customer-side access-management problem even though the application itself is Microsoft's service.

SaaS can reduce infrastructure effort because the customer uses a complete application. It offers less control over the underlying stack than PaaS or IaaS. The customer must still review configuration, access, data classification, and retention practices. A subscription to a SaaS product does not automatically establish that its settings match company policy.

How responsibility shifts

This simplified comparison captures the broad pattern: Microsoft operates more of the platform as the service becomes more managed. Customer responsibility for data, users, and configuration persists. Some areas are shared or depend on the exact service. Read the service documentation when designing a real workload; do not treat a table as a complete security contract.

A useful memory aid is to ask who configures the part in question. Who patches the operating system? Who sets the user's role? Who chooses which data is stored? Who protects the physical server? The answers vary by layer. Avoid the shortcut ‘cloud provider handles security’ because security tasks exist at every layer.

Original scenario: choose a service model

A small company has a legacy scheduling application that requires a specific operating-system setting. The team wants to move it quickly and keep control of the guest operating system. IaaS may fit because a VM gives the team that control, but the company must plan updates, access, backups, and network security. A managed platform could reduce OS maintenance, but only if the application can run within the platform's supported environment.

A different company is building a new web application and wants developers to deploy code without maintaining servers. PaaS may fit. Microsoft manages more of the host and operating-system layers, while the development team still secures code, configures identity and network access, and protects data. Choosing PaaS does not remove the need for a security review.

A small organization needs an email and calendar service and does not want to host the application. SaaS may fit. The provider runs the service, but the organization must provision accounts, apply appropriate access controls, protect endpoints, and decide how sensitive information is handled. If a shared mailbox is left accessible after a staff change, the customer must correct the access configuration.

Common shared-responsibility mistakes

Mistake one is assuming that Microsoft manages customer identities. The provider offers identity services, but the customer manages who has accounts, which authentication methods are used, and what permissions are granted. Multifactor authentication and least privilege are customer configuration choices within available services.

Mistake two is assuming PaaS and SaaS mean that customers have no application or data responsibilities. Microsoft may manage components of the application stack, but customer code, configuration, data, and access remain relevant. A storage account can be a managed service and still be exposed through a customer-selected configuration.

Mistake three is treating responsibility as fixed across every Azure service. Azure services can combine service models and expose different controls. Some network or application tasks are shared. Check the service documentation and design assumptions when making an operational decision.

Mistake four is confusing Microsoft responsibility for the cloud infrastructure with a guarantee that every workload is secure or available. The customer chooses and configures services, identity, network, data, and resilience features. Microsoft provides capabilities; the customer selects and operates the parts under its control.

How the model relates to AZ-900

The shared responsibility model appears under cloud concepts in the AZ-900 skills outline. Candidates should compare IaaS, PaaS, and SaaS and identify appropriate use cases. The exam expects descriptive understanding, not legal interpretation of a cloud contract.

When answering a question, identify the service model and the layer being discussed. Physical datacenter security points to Microsoft. Customer identities and data remain customer responsibilities. Operating-system patching generally remains with the customer in IaaS and shifts to Microsoft in PaaS and SaaS. Application security may be shared or customer-controlled depending on the deployment.

The question may ask which model gives more control, which reduces server administration, or who manages a specific task. Answer that direct comparison. Do not choose SaaS merely because it is ‘more secure’ or IaaS because it is ‘more flexible.’ The scenario's control and operation requirements determine the fit.

For preparation, draw the stack for each model and label the owner. Then create a new workload example and explain what changes when it moves from IaaS to PaaS or SaaS. This method develops transfer and prevents memorizing a responsibility chart without understanding why the division shifts.