An independently written fictional workflow shows why service choice and control ownership must be traced separately. Distinguish provider platform maintenance from customer application, identity and data decisions, then reinforce the boundary in two checks; prior example exposure applies.
Direct answer: assign a specific duty, not the whole cloud
Start a responsibility discussion by naming the particular service and the particular decision. “It runs in Azure” is not enough to tell you who patches a guest operating system, changes an application’s business logic, or decides which person may see a record. Different service models move different parts of the maintenance burden. Even one workflow can consume several models at once. A useful explanation therefore names a boundary and a retained duty rather than declaring the entire workflow to be either Microsoft’s or the customer’s responsibility.
This article uses a fictional community research exchange, separate from the lesson and formal practice cases. The exchange collects submitted field notes, processes them with its own application, and discusses the results using finished hosted collaboration software. Its coordinator asks, “We moved processing to a managed platform; can we close our responsibility checklist?” The answer requires separating infrastructure maintenance from the controls and decisions the exchange still owns. No deployment steps or production security certification are implied.
Trace the workflow before choosing the label
The first part of the exchange’s workflow is an older analysis component on an Azure virtual machine. The group deliberately retains administration of the guest operating system because that component depends on its chosen host configuration. Azure Virtual Machines is an IaaS example: the cloud provider maintains underlying infrastructure, while the customer manages its guest OS and application. Do not confuse the physical server that hosts the VM with the guest operating system inside the VM. Those are different layers, even though an everyday description might call both a server.
The second part is a separately written submission application on Azure App Service. Here the exchange deploys application code onto a provider-maintained platform. This PaaS relationship changes which party maintains the underlying OS/runtime; it does not mean that Microsoft wrote or approved the exchange’s rules for accepting a field note. The third part is Microsoft 365 collaboration software, consumed as a finished SaaS application. The coordinator can configure users and settings without turning that application into a platform for deploying the exchange’s own submission code.
Work the disputed handoff step by step
Suppose the dispute concerns an update to the operating system beneath the App Service platform. First identify the service in the dispute: the PaaS submission application, not the older IaaS analysis VM. Second identify the layer: maintenance of the platform beneath the application. Microsoft’s current shared-responsibility guidance places OS/runtime maintenance with the provider in PaaS. The group should therefore avoid copying the IaaS guest-OS duty onto this different service relationship merely because both components execute the group’s code.
Now change the disputed task to reviewing a new business rule that releases a submitted note to partner organizations. The layer has changed. The exchange controls its application code and its decisions about customer data and access. Provider platform maintenance does not decide whether that release is authorized by the exchange’s business rules. A sound explanation names both conclusions: the provider maintains the managed platform beneath the submission application, while the exchange remains responsible for its controlled application, identity and data decisions. These conclusions can coexist; they do not cancel each other.
Use the strongest counterexample
The tempting counterargument is that a managed service already supplies security features, so no customer decision should remain. Security capabilities and responsibility for configuring or using a controlled component are different questions. A platform can be maintained correctly while a customer gives an inappropriate person access to its application. The provider’s successful maintenance would not make that customer permission decision appropriate. Equally, finding a customer access mistake does not prove that the customer should physically maintain the provider’s servers.
A second shortcut is to transfer one answer across every component in a hybrid workflow. The older VM and the managed application both support the same project, but their OS-management boundaries differ. Repeat the service-and-control question for each disputed component. If a task description says only “update the system,” ask which system layer and which service are meant. Where shared duties or service-specific settings matter, consult the applicable official service guidance rather than forcing an oversimplified universal rule.
Keep the reasoning useful and bounded
The original diagram is a question path, not a reproduction of Microsoft’s responsibility matrix and not a complete checklist. Read it from the task to the service boundary, then record the duty that remains with the customer. For study, try explaining a changed condition without reading the answer. If moving from a VM to a managed platform changes one maintenance duty, state exactly that change; do not silently move unrelated business-data or identity decisions along with it.
Use the two application checks below to reinforce this reasoning; prior example exposure applies. Then return to the linked lesson or its independent service-layer practice. A correct explanation should cite the controlling fact and defeat a plausible alternative, rather than relying on a remembered product label alone. The retained official source is current reference evidence for these service boundaries; this independently written guide is not Microsoft training material, legal advice, a contract amendment, a full security assessment or a complete AZ-900 study course. Qualified educator review and learner trial remain separate pending work.
Apply the guide
Turn the idea into practice.
Apply the rule to a new case, then explain your choice.
Practice this skillSources & authorship
Factual service/control boundaries use the retained current Microsoft shared-responsibility reference. All workflow cases, explanations, checks and artwork are original; no official matrix, question or answer is copied.
Original independent guide and fictional mixed-workflow case, not a duplicated lesson or video companion.
Independent educator review is pending. This guide is not an official exam paper or a video transcript.
Shared responsibility in the cloud