Shared Responsibility Confusion — Azure Fundamentals (AZ-900)
You put responsibility on the wrong side of the shared responsibility model. Managed services shift the boundary.
Microsoft Manages the Platform. Not Your Identity.
Questions about shared responsibility use phrases like 'managed by Microsoft' and 'customer responsibility' as pivot points. Candidates over-focus on infrastructure — hypervisor, physical hosts, network fabric — and concede too much. Encryption keys, role assignments, MFA configuration, and guest OS patching remain on the customer side regardless of service model. The wording 'who is responsible for' is the exam's cue to apply the shared responsibility matrix precisely.
The Scenario
The question asks who manages identity and access for Azure SQL Database. You answer "Microsoft" because it is a PaaS service. But authentication and authorization are always the customer responsibility in every cloud model — IaaS, PaaS, even SaaS. Microsoft manages the physical infrastructure, operating system, and database engine patches. You configure Azure AD authentication, database users, firewall rules, and row-level security. The question tests whether you know identity management never transfers to the provider.
How to Spot It
- •In Azure, three things are always the customer responsibility regardless of service model: identity and access management, data classification, and client device management. Even in SaaS like Microsoft 365, you manage who can access what.
- •Azure SQL Database (PaaS) vs. SQL Server on Azure VMs (IaaS) shifts OS patching, backup infrastructure, and high availability to Microsoft. But firewall rules, TDE encryption key management, and Azure AD authentication remain yours in both models.
- •When the question mentions Entra ID (Azure AD), RBAC role assignments, or Conditional Access policies, the answer is always "customer responsibility." Microsoft provides the identity platform; you configure and manage access policies on it.
Decision Rules
At which shared-responsibility boundary does OS and runtime management transfer from the customer to Microsoft — IaaS (Azure VM, customer owns OS) versus PaaS (Azure App Service, Microsoft owns OS and runtime)?
Which Azure service type (IaaS vs PaaS) places OS and runtime management responsibility on Microsoft rather than the customer, satisfying the explicit no-OS-management constraint?
Whether 'managed Kubernetes' (AKS) transfers node-level and orchestration lifecycle duties to Microsoft or whether a serverless model (Azure Functions) is required to satisfy a constraint that eliminates all customer-side infrastructure management.
Whether the workload's 'no cluster management' constraint is fully satisfied by ACI (zero cluster surface owned by customer) or only partially satisfied by AKS (control plane managed by Microsoft, but node pools and upgrade schedules remain customer-owned).
Determine which service type moves OS and runtime lifecycle management to Microsoft versus keeping it with the customer, then match that shared-responsibility boundary to the scenario's explicit constraint to eliminate any option where the customer still owns the infrastructure management layer.
Does 'managed Kubernetes' (AKS) transfer worker-node OS management to Microsoft, or does the customer retain that layer — making Azure Container Instances the only option that satisfies a zero-infrastructure-management constraint?
Does the presence of automatic scaling in an IaaS service (Azure Virtual Machine Scale Sets) eliminate the customer's OS and VM-level management responsibilities, or must the team select a PaaS service (Azure App Service) to truly transfer those duties to Microsoft?
Whether to rely on an assumed Microsoft platform default for fault distribution or explicitly declare availability zone placement in the ARM deployment to achieve intra-region zone-level resilience without incurring cross-region data-movement costs.
Whether restricting resource deployment to a specific Azure region is a Microsoft platform default triggered by region selection, or a customer responsibility requiring an explicit Azure Policy assignment.
Choose availability zones (intra-region fault-isolation boundary, data remains in-region, customer-configured) over region pairs (inter-region DR boundary, cross-region replication, also customer-configured) when the stated failure scope is a single datacenter and the compliance constraint prohibits cross-region data movement.
Availability zones provide intra-region fault isolation sufficient for a single-datacenter-failure RTO without moving data across geography boundaries, whereas region pairs extend protection to region-wide outages but place the paired-region residency verification burden on the customer — not Microsoft — making AZs the correct and complete answer for the stated constraints.
Whether subscription-level ARM hierarchy boundaries — which provide both an independent RBAC scope and a distinct billing context — or tag-based labeling — which provides cost-grouping metadata only — satisfies the dual requirements of access isolation and billing separation.
Domain Coverage
Difficulty Breakdown
Related Patterns