Cloud Concepts

Coming in you need no cloud background; by the end of this domain you will be able to answer the four idea-checks below on sight. AZ-900's first domain defines cloud computing as renting metered IT resources over the internet instead of buying and running your own hardware. Three threads cut across everything else in this domain: the shared responsibility model decides who secures what (Microsoft always owns the physical layer, you always own your data, your endpoints, your accounts and identities, and your access management), the deployment model decides who owns and shares the infrastructure (three models, public, private, or hybrid, plus multicloud as an awareness item), and the consumption-based model decides how you pay (pay-as-you-go OpEx rather than up-front CapEx). Serverless, such as Azure Functions, is that consumption model taken to its extreme: you supply only code and pay per execution. Get these four ideas straight and the rest of the exam's cloud-concepts questions resolve quickly.

The 'benefits of using cloud services' objective tests whether you can name the right benefit, and several pairs are deliberately offered as competing answers. High availability is staying up through a failure (redundancy across availability zones); scalability is having enough capacity (scale up = vertical, scale out = horizontal); elasticity is scalability done automatically by autoscale. Reliability is recovering from a failure and continuing to run, and is a pillar of the Microsoft Azure Well-Architected Framework, while predictability splits into performance predictability (consistent experience under load) and cost predictability (forecastable, trackable spend). Security is about protecting resources through defense in depth and Microsoft Defender for Cloud; governance is about standardizing and enforcing rules at scale through Azure Policy (which audits and enforces resource configuration with policies and initiatives). Manageability completes the same list of benefit names, and it splits in two: management "of" the cloud (autoscale, self-healing, and health monitoring the platform runs for you) and management "in" the cloud (the portal, CLI, PowerShell, and templates you drive yourself).

The cloud service types form a single stack distinguished by how much the provider manages for you, which is what "provider abstraction" in the title above means. With IaaS (for example Azure Virtual Machines) you rent raw compute, storage, and networking and manage the operating system upward. With PaaS (for example Azure App Service or Azure SQL Database) Microsoft also manages the OS and runtime, so you supply only code and data. With SaaS (for example Microsoft 365) you consume finished software and manage nothing beyond your data, your accounts and identities, and access management. The service type is the same coin as the shared responsibility model: choosing a higher-level service moves the responsibility line up the stack toward Microsoft, but your data, your endpoints, your accounts and identities, and access management always stay with you. Endpoints are the one item with a wrinkle, and it explains why the comparison table's SaaS cell lists three of these four rather than all four: you never stop owning endpoint protection and compliance, but because Microsoft supplies some device-management capability in SaaS, its own responsibility matrix marks client devices shared under SaaS instead of customer-only. The always-four set is what never transfers outright; the per-service-type cell is who does the work.