AZ-900 Cloud Concepts Explained: Cloud Models, Service Models, and Azure Fundamentals

Introduction

If you’re preparing for AZ-900, cloud concepts are where Azure stops feeling like a glossary and starts feeling like a model for how modern IT works. That shift matters. Once those core ideas click, the rest of the exam gets a lot easier to reason through.

AZ-900 is a fundamentals exam, so Microsoft’s really checking whether you recognize the concepts and understand them at a high level, not whether you can build and configure everything from memory. Still, the easiest way to make these ideas stick is to tie them to real Azure examples. That’s what this guide does.

What Cloud Computing Means in AZ-900

Cloud computing is basically the delivery of compute, storage, networking, and other services on provider-managed infrastructure that you can provision quickly, scale when needed, and pay for based on actual usage. For AZ-900, there are five cloud characteristics you really want to know, and they line up with the standard cloud model used in Microsoft’s guidance:

• On-demand self-service - Resources can be created without long procurement cycles.
• Broad network access - Services are reachable over standard networks from different device types.
• Resource pooling - Provider infrastructure serves many customers while keeping tenants logically isolated.
• Rapid elasticity - Capacity can expand or shrink quickly.
• Measured service - Usage is metered and tracked for billing and reporting.

In Azure, these characteristics show up clearly. For example, a team might spin up an Azure virtual machine using the portal, Azure CLI, PowerShell, ARM templates, or Bicep, depending on which tool fits their working style and process best. At the end of the day, it’s still the same virtual machine underneath it all, no matter how you choose to deploy it. What changes is how you create and manage it, and that usually depends on which approach fits your team’s workflow and habits best. Autoscale in services such as App Service demonstrates elasticity. Azure Cost Management reflects measured service by showing what was consumed and what it cost.

The important thing to remember is that cloud isn’t just “someone else’s datacenter.” Honestly, cloud is really an operating model built around speed, automation, higher-level services, and usage-based tracking. And honestly, if you’ve spent years doing things the traditional on-premises way, this can be a pretty big mindset shift.

How Cloud Is Different from Traditional On-Premises Infrastructure

With on-premises infrastructure, your organization usually owns the hardware, handles the refresh cycle, takes care of the facility issues, and carries most of the day-to-day operational burden. If you’ve lived through server refresh projects, you already know how much effort that can take. That means dealing with server procurement, rack space, power, cooling, hardware replacement, firmware updates, and capacity planning. And yeah, all of that adds up fast, especially when capacity planning gets a little too optimistic. Cloud shifts a lot of the physical and platform burden to the provider, but that definitely doesn’t mean your responsibility disappears. You’re still accountable for how the service is configured, secured, and governed.

Financially, on-premises environments often lean toward CapEx, where you buy infrastructure upfront. Cloud usually leans toward OpEx, where you pay over time for what you use. That does not automatically make cloud cheaper. It makes cost more variable and more closely tied to usage.

A practical Azure example: moving a legacy application to an Azure VM is cloud adoption, but still close to the traditional server model. Moving that app to Azure App Service changes the operational model much more because Microsoft manages the operating system and platform runtime.

Shared Responsibility Model

The shared responsibility model explains who secures and operates which parts of the stack. Microsoft always manages the physical datacenter, physical hosts, storage hardware, networking fabric, and core platform layers. The customer still manages identities, access, data, configuration, and anything deployed into the service.

The rule to remember is simple: the more managed the service, the more responsibility shifts to Microsoft. But customers never stop being responsible for how they configure and use the service.

This is one of the spots where a lot of beginners tend to get tangled up, and that’s completely normal. Just because the provider can secure or manage a service doesn’t mean it’s already set up in a way that matches your environment. Azure gives you the security tools, but if you give out overly broad permissions, leave a VM unpatched, or expose data publicly, that part is still your responsibility. The platform can help quite a bit, but it can’t make those judgment calls on your behalf.

Quick scenarios:

• A VM is compromised because the guest OS was not patched. In IaaS, that is primarily the customer’s responsibility.
• An App Service app leaks secrets stored in bad application settings. Microsoft runs the platform, but the app configuration is the customer’s responsibility.
• A Microsoft 365 tenant exposes data because weak access policies were used. The SaaS platform itself is managed for you, but you’re still responsible for the tenant’s security settings. That’s an easy detail to miss, and honestly, it causes more trouble than people expect.

Cloud Deployment Models: Public, Private, Hybrid, and Multicloud

Public cloud uses provider-owned, multi-tenant infrastructure offered for public consumption. You can reach workloads over the internet or through private connectivity options like VPN, ExpressRoute, or private endpoints, depending on what the workload needs for security and performance. Which connection method you choose really comes down to the workload’s security, performance, and control requirements.

Private cloud is a cloud-like environment dedicated to one organization.

Hybrid cloud combines on-premises or private infrastructure with public cloud services.

Multicloud means using more than one public cloud provider.

Hybrid is especially important in Azure. Common patterns include VPN Gateway or ExpressRoute for private connectivity, Microsoft Entra ID for identity integration, Azure Site Recovery for disaster recovery, and Azure Arc for managing resources across different environments, which is something I’ve seen come up a lot in real hybrid designs. You’ll see these show up a lot in real hybrid designs. Multicloud is usually as much of a business decision as it is a technical one.

Exam trap: hybrid is not “multiple clouds.” Hybrid means here plus cloud. Multicloud means more than one public cloud.

Cloud Service Models: IaaS, PaaS, SaaS, and Serverless

Service models basically describe how much of the stack you’re responsible for.

I usually find it easier to think of serverless as an execution model, not as a direct replacement for IaaS, PaaS, or SaaS. It changes how code runs, but it doesn’t erase the underlying service model. With Azure Functions, you write code that runs when something happens, like an HTTP request, a queue message, or a file upload. It’s a very natural fit for event-driven work. Azure Functions can run on different hosting plans, including Consumption, Premium, and Dedicated, so don’t assume every Functions workload is billed the same way. The billing model depends on the hosting plan behind it.

One business scenario: if a company needs to move a legacy Windows app with OS dependencies, IaaS is a fit. If it is building a modern web app and wants less patching overhead, PaaS fits better. If it just needs email and collaboration, SaaS is usually the simplest answer. There’s no reason to manage a server when the service already does the job. If it needs code to run only when an event occurs, serverless is often the best fit. That’s usually where serverless really shines.

Migration language also matters: rehost usually maps to IaaS, replatform often maps to PaaS, and refactor usually means redesigning to use more cloud-native patterns.

Azure Global Infrastructure, Regions, and Resiliency Basics

Azure’s global footprint has a real effect on latency, compliance, service availability, and disaster recovery planning. Where you place workloads really does matter.

Geographies are broad market areas that help with data residency and compliance planning. Regions are sets of datacenters deployed within a latency-defined perimeter. Not every Azure service or SKU is available in every region, so it’s always worth checking what’s supported before you settle on a region. That small detail can save you a lot of headaches later.

Availability zones are separate physical locations within a region with independent power, cooling, and networking. They improve resilience, but only if the workload is actually built to use multiple zones or zone-redundant services. Just having zones in the region isn’t enough by itself. A zone by itself does not make an application resilient.

Region pairs are part of Azure resiliency planning for many public regions, but you should not assume every service automatically fails over across paired regions. Disaster recovery is still a design decision.

Azure also has edge presence used by services such as Azure Front Door and content delivery services to improve content delivery and user experience closer to end users.

Resiliency terms to keep straight:

• Availability set - spreads VMs across fault and update domains within a datacenter context.
• Availability zone - separate physical location within a region.
• Region pair - cross-region resiliency relationship for many Azure regions.
• SLA - contractual uptime commitment from Microsoft for a service.

High availability is a design goal. An SLA is the provider’s service commitment. Resiliency is your architecture’s ability to continue or recover during failure.

Core Benefits of Cloud Computing

The core benefits are usually pretty easy to memorize, but AZ-900 does like testing the differences between terms that sound similar. That’s where people tend to lose points.

Vertical scaling means making one instance larger. Horizontal scaling means adding more instances. Elasticity usually implies automatic or rapid adjustment, not just growth.

A good exam mental model is a failure ladder: if one VM fails, high availability features matter. If one datacenter location fails, zone-aware design matters. If a whole region fails, disaster recovery matters. If data is deleted accidentally, backups matter. Different problem, different control.

Cloud Economics and Cost Control

Azure commonly uses pay-as-you-go pricing, but your total cost still depends on architecture, utilization, licensing, storage tier, redundancy choices, transactions, and network usage. So no, cloud isn’t automatically cheap just because it’s cloud. One useful beginner-friendly detail to remember is that inbound data transfer is often free for many services, while outbound data transfer, often called egress, usually costs money. That surprises people more often than it should.

Azure pricing options can include standard pay-as-you-go, Azure Reservations for predictable workloads, savings-oriented commitment models, and spot pricing for interruptible capacity in some scenarios. The tradeoff is usually flexibility versus discount.

Basic cost controls:

• Set budgets and cost alerts
• Use tags such as owner, environment, and cost center
• Right-size compute and storage
• Stop or deallocate nonproduction VMs when not needed
• Review Azure Advisor and Cost Management reports

A workload that runs 24/7 and stays fairly predictable may benefit from reservations. That’s one of the main ways to keep ongoing cloud spending under control. A bursty, event-driven workload may be a better fit for Azure Functions or for PaaS services that can autoscale as demand changes, instead of sitting there with fixed capacity all the time. That kind of workload doesn’t always need constant capacity sitting around. Cloud can save money, but unmanaged cloud can also get expensive very quickly. I’ve seen that happen more than once.

Azure Governance and Resource Organization

Azure organization follows a hierarchy: management group → subscription → resource group → resource.

Management groups help apply governance across multiple subscriptions. Subscriptions are billing, access, governance, and quota boundaries. Resource groups are logical containers for resources within a subscription. A resource belongs to one resource group at a time, but resource groups are not strict security or network boundaries.

For AZ-900, you should know these governance controls:

• Azure RBAC - controls who can do what.
• Azure Policy - controls what is allowed or denied.
• Tags - add metadata for reporting and cost tracking.
• Resource locks - help prevent accidental deletion or modification.
• Budgets - help monitor and control spending.

Microsoft Entra ID is the identity and access service used across Azure and Microsoft cloud services. Azure RBAC uses Microsoft Entra identities for authorization, so identity is still the foundation of access control in Azure.

A simple governance pattern is to separate production and nonproduction into different subscriptions, group app components into resource groups, apply tags for chargeback, assign least-privilege RBAC roles, and use Policy to restrict approved regions or SKUs. It’s not fancy, but it works.

Security Basics for Cloud Concepts

Security shows up everywhere in AZ-900, even when the question looks like it’s really about architecture or governance. That’s one of those things you start noticing once you’ve taught the topic a few times. The basics are straightforward: use strong identity controls, least privilege, secure configuration, and proper data protection. Nothing glamorous, but absolutely essential.

Must-know ideas:

• Identity is foundational, and Microsoft Entra ID sits at the center of Azure access.
• Use least privilege through Azure RBAC.
• Use multifactor authentication and strong access policies.
• Protect secrets and connection strings properly.
• Use network controls such as NSGs, firewalls, and private endpoints where they make sense. The right control depends on the workload, but the principle is the same.
• Encrypt data both in transit and at rest. That should be a default expectation, not an afterthought.

A lot of cloud incidents come down to misconfiguration, not provider failure. That’s a hard lesson, but it’s a very real one. An open storage account, an overly broad contributor role, or a forgotten test VM can create risk even in a secure platform.

Troubleshooting and Operations Basics

Even at the fundamentals level, it helps to know where to look when something goes wrong. You don’t need deep admin skills for AZ-900, but you do need good instincts.

• If a service seems down, check Azure Service Health and the service’s regional status.
• If access fails, verify the user or service principal in Microsoft Entra ID, the RBAC assignment scope, and whether Azure Policy blocked the action.
• If costs spike, look for always-on resources, oversized SKUs, unattached disks, high egress, or missing shutdown schedules.
• If a deployment fails, confirm the service and SKU are available in that region and that subscription quotas haven’t been reached.
• If an app is slow, review region placement, scaling behavior, storage tier, and whether caching or content delivery would help.

Azure Monitor is the broad monitoring platform to remember, even if AZ-900 does not expect deep configuration knowledge.

AZ-900 Exam Traps and Rapid Review

Microsoft likes to test terms that sound similar. Keep these boundaries clean:

• Scalability vs elasticity - growth capacity vs rapid grow-and-shrink behavior
• High availability vs disaster recovery - staying up vs recovering after major outage
• Hybrid vs multicloud - on-prem plus cloud vs multiple public clouds
• RBAC vs Policy - who can act vs what is allowed
• IaaS vs PaaS - you manage the OS vs provider manages the OS
• CapEx vs OpEx - upfront investment vs ongoing operating spend

Memory aids:

• Hybrid = here + cloud
• Elastic = expands and snaps back
• RBAC = who can act
• Policy = what is allowed
• SaaS = software you consume

Mini practice checks:

• Developers deploy code without managing the OS: PaaS
• Company keeps some workloads on-premises and extends others to Azure: Hybrid
• Company uses Azure and another public cloud provider: Multicloud
• Need OS-level control for a legacy app: IaaS
• Need a finished collaboration platform: SaaS
• Need code to run only when a queue message arrives: Serverless

Conclusion

Cloud concepts are the foundation of AZ-900. If you understand what cloud computing is, how shared responsibility changes across service models, how deployment models differ, how Azure regions and availability options affect design, and how governance and cost control work, you will be in a strong position for both the exam and real Azure discussions.

The simplest way to study from here is to keep mapping concepts to Azure examples: Azure Virtual Machines for IaaS, Azure App Service for PaaS, Microsoft 365 for SaaS, Azure Functions for serverless, ExpressRoute for hybrid connectivity, Entra ID for identity, RBAC for authorization, Policy for guardrails, and Cost Management for spending visibility. Once those anchors are clear, the exam questions become much less slippery.