Cloud Concepts
This chapter establishes the vocabulary and mental models behind public cloud computing. You will learn the three core service models (IaaS, PaaS, SaaS), the deployment models (public, private, hybrid), the economic and operational benefits that drive cloud adoption, and the shared responsibility model that divides security duties between provider and customer. These fundamentals underpin every Azure service you encounter later, so a firm grasp here makes the rest of the material far easier to absorb.
Cloud Service Models: IaaS, PaaS, and SaaS
When you buy a cloud service, you are really deciding how much of the technology stack you want to manage yourself and how much you want the provider to run for you. That stack runs from the physical datacenter, servers, and network at the bottom, up through virtualization, the operating system, the runtime and middleware, and finally the application and its data at the top. The industry divides the possibilities into three service models, and the AZ-900 exam expects you to place a given service into the right one. Infrastructure as a Service (IaaS) hands you raw building blocks: virtual machines, virtual disks, and virtual networks. Azure runs the physical hardware, but you install and patch the operating system, configure the runtime, and manage the application. IaaS gives you the most control and the most responsibility; it is the natural landing spot when you lift and shift an existing server into the cloud. Platform as a Service (PaaS) removes the operating system and runtime from your plate. You hand the provider your code or your database schema, and services such as Azure App Service, Azure SQL Database, or Azure Functions run it on infrastructure you never see or patch. Developers favor PaaS because they can ship features instead of maintaining servers. Software as a Service (SaaS) is the finished product: a complete application delivered over the internet, such as Microsoft 365 or Dynamics 365. You do not manage servers, runtimes, or application code at all; you sign in, configure settings, and manage only your own users and data. The mental model the exam rewards is a sliding scale: as you move from IaaS to PaaS to SaaS, the provider assumes more of the work and you manage less. There is no single best model. The right choice trades control against convenience for the specific workload in front of you.
Cloud Deployment Models
A deployment model answers a different question from the service model: not how much of the stack the provider runs, but where the resources physically live and who is allowed to use them. The AZ-900 exam recognizes three deployment models, and each strikes its own balance among cost, control, and compliance. The public cloud is the model most people mean when they say cloud computing. A provider such as Microsoft owns and operates massive multi-tenant datacenters and rents capacity to anyone on demand over the internet. Because the hardware is shared across many customers and the provider buys at enormous scale, the public cloud offers the lowest upfront cost, near-instant provisioning, and essentially unlimited capacity, at the price of giving up direct ownership of the underlying hardware. The private cloud dedicates infrastructure to a single organization. It may sit in the company's own datacenter or be hosted for it, but either way the resources are not shared with other tenants. Organizations choose private cloud when strict security, regulatory, or data-residency rules demand isolation and fine-grained control, accepting higher cost and the burden of capacity planning in return. The hybrid cloud connects the two, linking on-premises or private environments with public cloud resources so that workloads and data can move or span across both. Hybrid is powerful for gradual migration, for keeping sensitive data on-premises while bursting compute into the public cloud during demand spikes, and for meeting compliance rules that require certain systems to stay in a controlled location. Azure supports hybrid scenarios directly through services such as Azure Arc, which extends Azure management to servers running anywhere, and Azure VPN Gateway and ExpressRoute, which create the network links. There is no universally correct model. Regulatory obligations, cost targets, latency needs, and how much control a team wants over the hardware together determine which deployment model, or which blend of them, fits a given workload best.
Benefits of Cloud Computing and the CapEx-to-OpEx Shift
The cloud's appeal comes from a bundle of economic and operational advantages that traditional on-premises IT struggles to match, and the exam tests each one by name. The most fundamental is the shift from capital expenditure to operational expenditure. In the on-premises world you spend capital expenditure (CapEx): a large, upfront purchase of servers, storage arrays, and networking gear that you depreciate over years and that sits idle whenever demand is low. The cloud replaces that with operational expenditure (OpEx): a variable, ongoing charge for exactly the resources you consume, billed by the hour, second, gigabyte, or transaction. This consumption-based, pay-as-you-go pricing means a startup can launch without buying a datacenter, and a business can turn resources off when they are not needed and stop paying for them. Scalability and elasticity are the next benefits. Scalability is the ability to add capacity as demand grows, either vertically (a bigger machine) or horizontally (more machines). Elasticity goes further: the platform automatically adds capacity during spikes and removes it when demand falls, so you neither overpay for idle hardware nor run out of headroom during a rush. High availability and reliability come from the provider's redundancy: replicated hardware, multiple datacenters, load balancing, and automatic failover keep applications running and recoverable even when components fail. Agility means resources provision in minutes rather than the weeks a hardware purchase would take, so teams can experiment and innovate quickly. Global reach lets you deploy close to users anywhere in the world, cutting latency and helping meet data-residency rules. Finally, the cloud improves security and manageability by centralizing patching, monitoring, and governance tools. Taken together these benefits explain why organizations of every size migrate: they trade fixed cost and long lead times for flexible spending, elastic capacity, and speed. Understanding each one lets you justify and design cloud solutions, which is exactly what the exam asks you to do.
Scaling, Availability, and Resilience
Cloud platforms offer several distinct techniques to keep applications fast and available as conditions change and as components inevitably fail. The exam expects you to tell these concepts apart, because each addresses a different aspect of performance or continuity and the distractors deliberately swap them. Start with scaling, which comes in two directions. Vertical scaling (scaling up or down) means changing the size of a single resource, for example moving a virtual machine to a SKU with more CPU and memory. It is simple but bounded by the largest machine available and usually requires a restart. Horizontal scaling (scaling out or in) means adding or removing instances that share the load behind a load balancer. It is the cloud-native pattern because it can grow almost without limit and can happen without downtime. Autoscaling builds on horizontal scaling by automatically adding instances when a metric such as CPU or queue length rises and removing them when demand falls, so the system tracks real demand and you pay only for what you use. High availability is about keeping a service running despite failures, and it is achieved through redundancy: distributing resources across independent fault domains so that a single hardware, rack, or datacenter failure takes down only a portion of the system. In Azure, availability sets, availability zones, and load balancing all serve this goal. Fault tolerance is the stronger property of continuing to operate with no interruption when a component fails. Disaster recovery (DR) addresses large-scale outages, such as the loss of an entire region, by replicating data and systems to another location so operations can be restored; the plan is measured by how much data you can afford to lose (recovery point objective) and how quickly you must be back (recovery time objective). Finally, a service-level agreement (SLA) is the provider's formal, published commitment to a level of uptime or performance, often expressed as a percentage such as 99.9%, with service credits owed to the customer if the target is missed. Together these mechanisms let you design dependable systems and reason about exactly how dependable they are.
The Shared Responsibility Model
Security in the cloud is a partnership, not a handoff, and the shared responsibility model is the framework that divides the duties between the provider and the customer. Misunderstanding this division is one of the most common causes of real-world security gaps, and the AZ-900 exam tests it directly. The core idea is that some layers of the stack are always the provider's job, some are always the customer's job, and a middle band shifts depending on the service model you chose. Microsoft, as the provider, is always responsible for the physical layer: the security of the datacenters, the physical hosts, and the physical network. No customer ever patches an Azure server rack. The customer, in turn, is always responsible for their own data, for their accounts and identities, and for how they manage access, regardless of service model. Your users, your passwords, your access policies, and the classification and protection of your information never become Microsoft's responsibility. Between those fixed poles, responsibility slides with the service model. With Infrastructure as a Service you take on the most: you manage the guest operating system, its patches, the network and firewall configuration inside your virtual network, applications, and runtime, while Microsoft handles the hardware and virtualization. With Platform as a Service the provider takes over the operating system, its patching, and the runtime, leaving you responsible mainly for your application configuration, your data, and your identities. With Software as a Service the provider manages almost everything up to the application itself, and your responsibility narrows to managing your data, your users, and their access and devices. A useful way to remember the pattern: as you move from IaaS toward SaaS, more responsibility transfers to the provider, but data, identity, and account management always stay with you. Getting the split right for each service is fundamental to using Azure safely, because a control that you assume the provider owns, but in fact you own, is exactly where breaches happen.
Last updated: September 2026
La práctica sigue gratis. La guía completa de Microsoft Azure Fundamentals (AZ-900) es el material en sí, explicado de principio a fin — un PDF + EPUB descargable que conservas.