Cloud concepts for Microsoft AZ-900 Azure Fundamentals: Concepts, Scenarios, and Study Priorities

 

Cloud concepts account for roughly a quarter of the current AZ-900 blueprint, but their importance is larger than the percentage suggests. The same ideas shape questions about Azure architecture, services, security, governance, cost, and management. If you misunderstand shared responsibility, consumption-based pricing, service models, availability, or scalability, you can choose the wrong answer even when you recognize every Azure product in the scenario.

Microsoft’s current study guide, with skills measured as of July 20, 2026, groups the cloud-concepts domain into three areas: describing cloud computing, describing the benefits of using cloud services, and describing cloud service types. That means your preparation should not be a tour of Azure products. It should build a decision model for what cloud computing changes, what benefits it can provide, what responsibilities remain with the customer, and how different service models trade control for abstraction.

Start with a precise definition of cloud computing

Cloud computing is the delivery of computing resources and services through a provider-operated environment that can be provisioned and consumed on demand. The practical point is not that “the servers are somewhere else.” The important shift is that capacity, platform capabilities, and managed services can be obtained through service interfaces without the customer first building and operating all underlying physical infrastructure.

That shift changes both economics and operations. Instead of buying enough hardware for a projected peak and waiting through procurement cycles, an organization can provision supported services when needed and change capacity as demand changes. Instead of operating every layer of the stack, a team can choose managed services that transfer some operational work to the cloud provider. Those advantages are not automatic. Poor architecture, weak identity controls, uncontrolled consumption, or unsuitable service choices can still create outages, security exposure, and unnecessary cost.

For AZ-900, keep the definition tied to decisions. Ask what is being abstracted, how capacity is obtained, who operates which layers, how usage is charged, and how quickly the organization can change the environment.

Shared responsibility is the boundary underneath every cloud model

The shared responsibility model explains why moving to cloud does not mean outsourcing all security or operations. Microsoft operates the physical facilities and the core cloud platform. Customers still make decisions about identities, data, access, configurations, workloads, and the services they choose. The exact boundary changes with the service model.

In infrastructure as a service, the provider operates physical infrastructure and foundational virtualization, while the customer generally manages more of the guest operating system, applications, workload configuration, and data. In platform as a service, the provider manages more of the operating platform, allowing the customer to concentrate on application code, configuration, identities, and data. In software as a service, the provider manages the application stack itself, but the customer still controls how the service is configured, which users have access, what information is stored, and how organizational policies are applied.

A useful scenario is a leaked document from a SaaS collaboration service. The provider may have securely operated the physical hosts and application platform, but an organization can still expose the document by granting the wrong user access. Shared responsibility is about control boundaries, not blame. Ask which party controls the failed layer and what responsibility remains even when more infrastructure is managed for you.

Public, private, and hybrid cloud describe deployment models

A public cloud provides services on provider-operated shared infrastructure, with logical separation between customers. It is attractive when organizations want broad service choice, rapid provisioning, elasticity, global reach, and reduced need to own datacenter infrastructure. A private cloud is dedicated to one organization and can provide greater control over the environment, but that control usually comes with greater operational responsibility and less access to hyperscale economics.

Hybrid cloud combines private or on-premises environments with public cloud services in an integrated operating model. Hybrid is not simply “we have some old servers and also an Azure account.” The important idea is coordinated use of environments so workloads, identities, management, data, or networking span boundaries according to business requirements.

Choose the deployment model from constraints. A startup with no existing datacenter and unpredictable traffic may fit public cloud well. A regulated organization that must retain a specific system on premises but wants cloud analytics can use a hybrid approach. A business that requires a dedicated environment for a particular legacy workload may consider private infrastructure. None of these labels determines IaaS, PaaS, or SaaS; deployment model and service type are separate dimensions.

Use cases matter more than slogans

Public cloud is not always the correct answer merely because it can scale. Private cloud is not automatically more secure merely because it is dedicated. Hybrid cloud is not automatically the most flexible choice if the organization has no reason to operate two environments. Every model creates tradeoffs in control, skills, connectivity, governance, latency, cost, and operational complexity.

Imagine a manufacturer with a plant-control application that requires extremely low latency to local equipment and cannot tolerate WAN dependency. Keeping that workload near the plant may be sensible, while analytics or backup data can use public cloud services. Now change the requirement: the application is a new internet storefront with highly variable demand and no dependency on local machinery. Public cloud becomes more attractive because elasticity and managed services have more value than local infrastructure control.

The AZ-900 skill is to identify the requirement that changes the answer. Do not memorize “hybrid for large enterprises.” Ask what must remain local, what can move, which dependencies cross environments, and whether the added integration burden is justified.

Consumption-based pricing changes the cost model, not the need for cost discipline

Cloud services often use consumption-based pricing: spending follows the resources or services consumed rather than requiring the same upfront capital purchase as a traditional hardware acquisition. This can convert some capital expenditure into operational expenditure and make experimentation or variable workloads easier to fund. It also gives teams the ability to scale resources down when they are not needed.

The mistake is turning this into “cloud is always cheaper.” Cost depends on service choice, capacity, usage duration, data transfer, storage tier, support, licensing, geographic design, and operational behavior. An oversized virtual machine running continuously can be expensive. A poorly governed test environment can accumulate idle resources. A design that transfers large data volumes across regions can create charges that were not obvious during a simple compute comparison.

At fundamentals level, understand why pricing estimates and ongoing cost-management tools are different. Estimation supports planning before deployment. Budgets, cost analysis, tags, and scope-based reporting help manage actual consumption afterward. The consumption model is valuable because spending can align more closely with demand, but it requires visibility and governance to remain predictable.

Compare cloud pricing models through workload behavior

Pricing decisions become clearer when you describe the workload first. A short-lived development environment has different economics from a steady production database. A bursty API has a different pattern from a batch-processing job that runs every night. Storage that is accessed every hour has a different cost profile from a long-term archive.

For a variable workload, elastic or serverless services can reduce the need to pay for fixed peak capacity, provided the execution model fits. For steady workloads, commitment or reserved-capacity models may improve economics where supported, but they trade some flexibility for predictable usage. Storage tiers can reduce ongoing storage cost for infrequently accessed data, but retrieval characteristics and charges matter. The point is not to memorize every Azure price. AZ-900 expects you to understand that cloud pricing is a set of tradeoffs rather than one universal rate.

When a scenario asks for the lowest-cost answer, do not ignore non-cost requirements. A cheaper architecture that violates availability, performance, security, or compliance constraints is not a valid solution. Cost optimization begins after mandatory requirements are satisfied.

Serverless is about an execution and management model

Serverless does not mean that servers do not exist. It means the customer does not provision or manage the underlying servers in the traditional way for the supported service. The provider handles infrastructure allocation and scaling mechanics, while the customer focuses more directly on code, events, data, or workflow logic.

A simple example is code that should run when a message arrives or a file is uploaded. An event-driven function can be a better fit than keeping a full virtual machine running only to wait for occasional work. The provider allocates execution resources according to the platform model, and billing commonly aligns more closely with executions or consumption than with a permanently provisioned server.

But serverless is not automatically appropriate for every application. Runtime limits, supported languages, state handling, networking, startup characteristics, integration requirements, and predictable long-running workloads can change the decision. For AZ-900, you do not need to master function-host internals. You do need to understand why serverless can reduce infrastructure management and fit event-driven, variable-demand workloads.

High availability addresses service continuity through failure

High availability is the ability of a system to remain accessible and useful despite component failures. Cloud platforms provide building blocks for availability, but application design still matters. Deploying a workload in Azure does not automatically make it highly available.

Think in failure domains. If one virtual machine fails, multiple instances can reduce dependence on a single host. If one datacenter location inside a region fails, availability zones can help when the selected services and architecture support zonal deployment. If an entire region becomes unavailable, a multi-region design may be required. Each step addresses a larger failure scope and usually adds cost and complexity.

AZ-900 questions often test whether you can match the resilience mechanism to the failure. Do not answer “availability zone” when the requirement explicitly describes a region-wide outage, and do not propose a second region when the requirement is only to survive a single server failure. Start by naming the failure domain, then choose an architecture that removes that single point of failure.

Scalability and elasticity are related but not identical ideas

Scalability is the ability to change capacity to support demand. Vertical scaling changes the capacity of an individual resource, such as using a larger machine. Horizontal scaling changes the number of resource instances. Elasticity emphasizes the ability to adjust capacity dynamically as demand rises and falls.

A retail website that experiences a predictable holiday spike illustrates the distinction. The system may scale out by adding application instances. If autoscaling policies add and remove those instances as demand changes, the environment is behaving elastically. A database that is resized to a larger tier before a planned event is scalable even if the change is manual rather than automatic.

Cloud services make scaling easier because capacity can often be changed without purchasing new physical hardware, but scaling still needs limits, monitoring, and design. A badly written application may not scale simply because more compute is added. A database bottleneck, external dependency, or licensing constraint can become the new limit. The exam concept is capability, not a promise of infinite performance.

Reliability is broader than keeping one component online

Reliability is confidence that a system performs its intended function over time, including during failures and recovery. High availability contributes to reliability, but reliability also includes redundancy, recovery processes, data protection, monitoring, testing, and operational response.

Consider an application with two front-end instances but a single database that has no recovery plan. The web tier may be highly available while the overall system remains fragile. Or imagine a service deployed across zones with no monitoring; it may survive some infrastructure failures, but operators may not notice data errors or degraded dependencies quickly. Reliability is an end-to-end property.

For fundamentals questions, avoid turning reliability into a single Azure feature. Cloud platforms provide resilient services and architectural options, but the customer still chooses service tiers, redundancy, region strategy, identity controls, and recovery procedures. Shared responsibility applies to reliability decisions just as it applies to security.

Predictability is about reducing uncertainty in performance and cost

Predictability is useful because cloud environments are dynamic. Teams need confidence that services will perform within expected ranges and that spending can be understood well enough to plan. Cloud platforms provide mechanisms such as defined service characteristics, monitoring, autoscaling, pricing information, and cost-management tools that support this goal.

Performance predictability depends on choosing suitable service tiers and architectures, testing realistic load, and monitoring behavior. Cost predictability depends on understanding pricing dimensions, forecasting usage, setting budgets or alerts, and removing waste. A consumption model can improve economic flexibility while still creating variable invoices; predictability comes from measurement and control, not from the billing model alone.

When a scenario uses the word “predictable,” identify whether it is talking about performance, cost, or both. The answer may involve service selection for consistent capacity, cost estimates and budgets, or monitoring to detect deviation. Avoid the generic response that “cloud is predictable” without explaining what evidence supports the prediction.

Security benefits do not remove customer security decisions

Cloud providers invest heavily in physical security, platform security, threat detection, and service hardening. Customers can also use centralized identity, policy, monitoring, encryption, and security services rather than building every control from scratch. These are real benefits, but they should not be interpreted as “the cloud provider secures everything.”

The customer still controls identities, permissions, data classification, network exposure, workload configuration, and many security settings. A secure cloud service can be deployed insecurely. A storage account can contain sensitive data that is shared too broadly. A powerful administrator account can lack appropriate authentication protection. An application can expose a public endpoint even when a private design was intended.

The correct fundamentals model combines provider capabilities with customer configuration. Use shared responsibility to ask who owns the control, defense in depth to think about layers, Zero Trust to avoid implicit trust, and RBAC or Conditional Access to reason about authorization and access conditions. Security is a system of controls, not a single service.

Governance helps cloud scale without losing organizational control

Rapid provisioning is valuable, but it can create inconsistency if every team names, configures, secures, and funds resources differently. Governance applies organizational rules so cloud adoption remains aligned with technical, financial, and compliance requirements.

At Azure fundamentals level, understand the role of scopes and controls. Management groups can organize subscriptions. Subscriptions form important billing and management boundaries. Resource groups organize resources. Azure Policy can evaluate and enforce configuration rules at appropriate scopes. Tags add metadata that can support ownership, automation, and cost reporting. Resource locks reduce the risk of accidental deletion or modification. Microsoft Purview addresses broader data-governance and compliance needs.

Governance is not the opposite of agility. Good governance makes safe choices repeatable so teams do not have to reinvent controls for every deployment. The study priority is to connect each control to the problem it solves instead of memorizing a list of “governance tools.”

Manageability appears in both deployment and ongoing operations

Cloud manageability includes the ability to deploy, configure, observe, and control resources through standardized interfaces. Azure offers a portal for graphical management, Cloud Shell for browser-based command-line access, Azure CLI and PowerShell for scripting, Resource Manager as a management layer, and infrastructure-as-code approaches such as ARM templates for repeatable deployment. Azure Arc extends management and governance concepts to resources outside the normal Azure environment.

Ongoing management also depends on visibility. Azure Monitor collects and analyzes telemetry. Log Analytics supports log querying. Alerts can notify or trigger action when conditions are met. Application Insights provides application-performance and usage telemetry. Service Health communicates Azure service issues and planned maintenance relevant to your environment. Advisor provides recommendations that can improve areas such as reliability, security, performance, operational excellence, and cost.

The practical distinction is deployment versus observation. A template creates or configures resources; a monitoring service helps you understand behavior after deployment. A recommendation engine is not the same as an outage notification. AZ-900 scenarios often become easy once you classify the operational task.

IaaS trades more control for more customer management

Infrastructure as a service exposes fundamental computing resources such as virtual machines, networking, and storage. It is useful when an organization needs control over the operating system, application stack, or infrastructure configuration and is prepared to manage those layers.

Suppose a vendor application requires a specific Windows Server configuration and cannot run on a managed application platform. An Azure virtual machine may be appropriate because the customer controls the guest OS and software environment. That control also creates responsibility for patching, hardening, monitoring, backup design, and application maintenance. The provider still owns physical datacenter and underlying platform responsibilities.

IaaS is not “better” because it offers control. More control can mean more operational burden and more opportunities for misconfiguration. Choose IaaS when the requirement actually needs that control. If the application can use a managed platform, PaaS may reduce undifferentiated infrastructure work.

PaaS shifts attention toward applications and data

Platform as a service provides a managed application or data platform where the provider operates more of the runtime and infrastructure stack. The customer focuses on application code, data, identity, configuration, and business logic rather than maintaining every server layer.

A team building a standard web application may prefer a managed app-hosting service because it does not want to patch guest operating systems or manage a fleet of web servers. A database team may choose a managed database service to reduce infrastructure administration. These choices can improve delivery speed and consistency, but they may reduce low-level control or require the application to fit platform constraints.

A PaaS decision therefore has two sides: operational simplification and platform fit. Fundamentals questions often present a requirement to “minimize management overhead.” That phrase should make you evaluate whether a managed platform can meet the workload requirements before defaulting to virtual machines.

SaaS delivers a finished application experience

Software as a service provides a complete application that users consume rather than build and host themselves. Examples include productivity, collaboration, customer-management, and business applications delivered as cloud services. The provider manages the application and underlying platform; the customer manages users, data, configuration, and business use.

The strongest way to distinguish SaaS is to ask whether the customer is primarily consuming the application rather than deploying code onto a platform. If a company needs email and collaboration capabilities, consuming a SaaS suite can be more appropriate than building and maintaining those services on virtual machines. The tradeoff is reduced low-level control and dependence on the provider’s application capabilities, configuration model, and service terms.

SaaS still requires governance. User lifecycle, external sharing, data retention, access controls, and compliance settings remain important. A managed application removes infrastructure administration, not organizational accountability.

Use a three-step service-model decision

When a scenario asks you to choose among IaaS, PaaS, and SaaS, use three steps. First, identify what the organization is trying to consume: infrastructure, an application platform, or a finished application. Second, identify the control it truly requires. Third, identify which operational work it wants to avoid.

If the organization needs a specific guest OS and custom middleware, IaaS fits the control requirement. If developers want to deploy code while the provider manages the runtime and infrastructure, PaaS is a better category. If users simply need a complete business application, SaaS is the natural model. The more managed the service becomes, the more infrastructure responsibility shifts to the provider, but customer responsibility for identity, data, and correct use does not disappear.

This framework is more reliable than product memorization because it works even when the scenario uses unfamiliar service names.

Scenario: a retailer with unpredictable demand

A retailer launches flash sales that can produce ten times normal traffic for a few hours. The business wants to avoid buying datacenter capacity that sits idle most of the year. Cloud elasticity is the first benefit to recognize. A scalable architecture can add capacity for the event and reduce it afterward. A consumption-based model can align more of the cost with actual use instead of fixed peak hardware.

Now add a requirement: the company does not want to patch web servers. That pushes the design toward a managed application platform rather than IaaS, assuming the application is compatible. Add another requirement: a small function should resize images whenever a product photo is uploaded. That event-driven component may fit serverless execution even if the main application uses PaaS.

The lesson is that one solution can use multiple cloud concepts at once. Start with workload and management requirements; then apply elasticity, service model, and cost reasoning independently.

Scenario: a regulated organization with an existing datacenter

A financial organization must keep one legacy transaction system on premises for regulatory and technical reasons, but it wants cloud-based analytics and backup capabilities. This is a hybrid-cloud scenario because workloads and data remain across environments. The design must consider connectivity, identity, data movement, security, governance, and operational ownership across the boundary.

The cloud portion may use managed analytics services to reduce platform administration. The on-premises system may remain privately operated because the requirement demands it. Secure connectivity does not remove the need for authorization, and centralized management does not eliminate local operational responsibility. Cost benefits should be evaluated for the actual workload rather than assumed.

If the regulation changes and the transaction system can later move, the architecture can be revisited. Cloud design is a response to current constraints, not a permanent label attached to the organization.

Scenario: a team wants “maximum security”

A scenario that says “maximum security” without specifics is incomplete. Security choices depend on threat model, data sensitivity, identity risk, exposure, compliance, and operational capability. A private cloud is not automatically more secure than public cloud. A public cloud service with strong identity, private connectivity, encryption, policy, logging, and managed security features may be more secure than a poorly maintained private environment.

For AZ-900, translate vague security language into concrete controls. Is the requirement to reduce public exposure? Consider private connectivity. Is it to require stronger sign-in? Think about MFA or Conditional Access. Is it to restrict what an identity can do? Think about RBAC. Is it to prevent accidental resource deletion? Think about locks. Is it to enforce configuration? Think about Policy.

Security questions become manageable when you stop choosing the “most secure sounding” product and instead map the stated risk to the control layer.

Scenario: management wants predictable spending

Predictable spending does not mean choosing a fixed-size server and never scaling. Start by estimating expected usage with current pricing information. Separate fixed or committed elements from variable consumption. Define budgets and ownership. Use tags or scopes so spending can be attributed. Monitor actual cost and investigate deviations. Remove idle resources and use appropriate service tiers.

If demand is variable, elasticity may actually improve predictability because the architecture can scale with workload rather than relying on repeated emergency capacity purchases. But autoscaling without guardrails can also create a large bill. The answer is measurement plus control.

A good fundamentals response distinguishes estimation from management: calculate likely cost before deployment, then use cost-management capabilities to observe and govern actual consumption after deployment.

Study priority 1: master comparisons before memorizing examples

Build comparison tables for public/private/hybrid, IaaS/PaaS/SaaS, CapEx/OpEx tendencies, vertical/horizontal scaling, availability/reliability, and provider/customer responsibility. For every row, include “best when,” “tradeoff,” and “what would change the answer.” This forces your notes to contain decisions rather than definitions.

Do not overload the table with product details. The cloud-concepts domain is about general principles. Azure examples are useful because they make the concept concrete, but the principle should still make sense if the product name disappears.

A good self-test is to explain each comparison without using the words “better,” “cheaper,” “secure,” or “flexible” unless you immediately state why and under which conditions. Precise qualifiers are a sign that the concept is becoming stable.

Study priority 2: connect cloud concepts to Azure architecture

After the comparison layer is stable, connect it to the rest of AZ-900. Shared responsibility links to identity, RBAC, security, policy, and workload configuration. Availability links to regions, availability zones, redundant architectures, and service choices. Scalability links to compute options and managed services. Manageability links to portal, command-line tools, Resource Manager, IaC, Arc, Advisor, Service Health, and Azure Monitor.

This prevents siloed study. The exam can describe a cloud benefit and ask about an Azure feature that enables it, or describe an Azure architecture and test whether you understand the underlying cloud principle. If the connection is weak, use one practical exercise from the AZ-900 practical preparation guide to make the concept visible rather than memorizing another paragraph.

Study priority 3: diagnose readiness with scenario explanations

A useful readiness check is not “Can I define this?” but “Can I explain why this answer fits and what requirement would make another option better?” Take ten scenarios and answer aloud. For each, name the decisive requirement, the chosen concept, the closest distractor, and the reason the distractor fails.

The AZ-900 readiness matrix can help organize this diagnostic across cloud concepts and the other domains. Treat a topic as ready only when you can retrieve and apply it without relying on recognition from a multiple-choice option.

Cloud concepts are the grammar of AZ-900. Once you can reason about responsibility, deployment models, pricing, serverless, availability, scalability, reliability, predictability, security, governance, manageability, and service types, many Azure-specific questions become easier. The product name may change, but the decision structure remains stable.

Study priority 4: reason about tradeoffs instead of treating cloud benefits as guarantees

The phrase “benefits of cloud” can encourage overly positive memorization. In practice, every benefit depends on design and operating discipline. Scalability helps only when the workload can use the added capacity. High availability requires an architecture that avoids a single failure point. Consumption pricing can reduce idle-capacity waste, but variable usage without budgets, rightsizing, or monitoring can make spending harder to predict. Managed services can reduce infrastructure administration while increasing dependence on the provider’s supported configuration model.

Turn each benefit into a tradeoff statement. “Elasticity can align capacity with changing demand, but scaling policies and downstream limits still need control.” “PaaS can reduce operating-system administration, but the team accepts a more opinionated runtime and service boundary.” “Public cloud can provide rapid access to shared infrastructure, but identity, data governance, network exposure, and service configuration remain customer responsibilities.” These statements are more useful than slogans because they show what the scenario must prove before the benefit applies.

This is also a strong distractor filter. If an option promises a universal outcome—always cheaper, automatically secure, no administration, unlimited scale—look for the responsibility or constraint it ignores. AZ-900 is a fundamentals exam, but foundational understanding includes knowing where the abstraction stops. The provider can supply resilient infrastructure while the customer still creates a single-instance application. A platform can encrypt stored data while an organization still grants excessive permissions. A cost-management service can show spending while the team still has to act on the signal.

Study priority 5: practice explaining responsibility when the service model changes

Shared responsibility becomes much easier when you compare the same application across service models. Imagine an organization needs a web application and database. Under IaaS, it may manage guest operating systems, installed software, configuration, identities, data, and much of the workload security while the provider operates the physical datacenter and underlying cloud infrastructure. Moving to PaaS can shift more platform maintenance to the provider, but application configuration, identities, data, and access decisions remain important. With SaaS, the provider operates far more of the application stack, yet the customer still controls users, permissions, data usage, and business configuration within the service.

Now add a requirement change. If the team must install a specialized operating-system driver, the extra control of IaaS may matter. If it wants to deploy application code without patching servers, PaaS may fit better. If the business simply needs a complete productivity capability, SaaS may remove unnecessary platform ownership. The right answer follows the level of control the workload requires and the operational responsibility the organization is prepared to keep.

Do not memorize a rigid checklist as though every service exposes identical controls. The exact division varies by service, but the direction is stable: as the provider manages more of the stack, the customer generally gives up some low-level control while retaining responsibility for its identities, information, permitted use, and configuration choices. Being able to explain that movement is more valuable than reciting a diagram from memory.

Integrated scenario drill: combine the cloud concepts without collapsing them

Use one scenario to practice keeping the concepts separate. A regional distributor runs an ordering application on aging on-premises servers. Normal traffic is stable, but quarterly promotions can triple demand. The operations team spends significant time patching the web tier, the database must remain highly available, finance wants clearer cost ownership, and a warehouse integration must continue reaching a local system that cannot yet move to Azure.

Start with deployment model. Because part of the environment must remain on premises while other components can move, a hybrid approach is plausible. That does not determine the service model for the cloud components. The web application may fit PaaS if it can run on a supported managed platform and the team wants to stop managing guest operating systems. If a legacy component requires a specific OS or middleware configuration, IaaS may remain appropriate for that component. The local warehouse dependency is a connectivity and integration constraint, not proof that the entire solution must stay private.

Now separate scale from availability. Promotion traffic creates a scalability and elasticity requirement: capacity should grow when demand rises and shrink afterward. The database availability requirement is different. It asks what failures the design must tolerate and how service continuity and recovery are achieved. Adding web instances does not automatically protect the database, and adding a second failure domain does not by itself solve demand spikes. Each requirement needs its own mechanism.

Next apply economics and governance. Consumption-based services may align spending more closely with promotional demand, but finance still needs estimates, budgets, ownership metadata, and ongoing cost analysis. Tags can help with allocation, while Azure Policy addresses enforceable resource rules and locks address accidental modification or deletion. These controls are complementary rather than interchangeable. Finally, shared responsibility remains: moving the web tier to a managed platform can reduce patching work, but the customer still owns application behavior, identities, data use, access decisions, and business configuration.

If you can explain that scenario without jumping straight to a product list, your cloud-concepts foundation is becoming useful. Repeat the exercise by changing one constraint at a time: remove the on-premises dependency, require a specialized OS driver, introduce a region-wide recovery requirement, or make demand completely steady. The best answer should change only where the new requirement changes the decision.