AZ-900 Cloud Concepts Explained: Cloud Models, Service Types, Benefits, and Pricing in Azure

1. Why Cloud Concepts Matter in AZ-900

Cloud Concepts is really the bedrock of AZ-900. Once you’ve got a proper handle on what cloud computing is, why organisations move to it, how the service models differ, and what cloud actually brings to the table, the rest of Azure starts to click into place. If you skip that foundation, Azure can honestly feel like a massive pile of service names with no clear mental model holding the whole thing together.

AZ-900 really focuses on four big ideas here: what cloud computing is, how the deployment models work, what the service types are, and what benefits cloud services actually bring. This is not just exam theory. And honestly, these ideas drive real-world decisions around cost, security, resilience, governance, and how much day-to-day operational work stays with the team versus gets handed over to Microsoft.

My advice for AZ-900 is dead simple: don’t just memorize isolated definitions. Learn to spot the pattern in a scenario instead. If a question emphasizes maximum control, think IaaS. If it emphasizes least management, think SaaS. If it describes automatic adjustment to demand, think elasticity. That approach is much more reliable than rote memory.

2. What Cloud Computing Actually Means

In plain English, cloud computing is the on-demand delivery of IT services over a network, usually with pay-for-what-you-use pricing. In Azure, that can mean compute, storage, networking, databases, identity, analytics, and application platforms. The important point is that cloud is not only “someone else’s datacenter.” It is also a delivery model built around rapid provisioning, automation, pooled resources, and managed services.

At AZ-900 level, it helps to know the classic characteristics of cloud computing:

• On-demand self-service: resources can be provisioned when needed without waiting for hardware procurement.
• Broad network access: services are accessible over networks from many client types.
• Resource pooling: provider resources are shared efficiently across customers using multitenancy and logical isolation.
• Rapid elasticity: capacity can grow or shrink quickly.
• Measured service: usage is monitored and billed based on consumption.

Cloud, especially in IaaS setups, leans heavily on virtualization. In practical terms, that means one physical server can host several virtual machines, with the hypervisor carving up the hardware into separate, isolated environments. But modern cloud goes further than virtualization alone. Azure also uses containers, orchestration, software-defined networking, distributed systems, and managed control planes to deliver higher-level services such as Azure App Service, Azure SQL Database, Azure Container Apps, and Azure Functions.

That is why cloud-native thinking matters. A VM in Azure is cloud, but so is a managed database you never patch, or a serverless function that runs only when triggered. The exam expects you to understand that cloud is broader than virtual servers.

3. Why Organisations Move to the Cloud

Organisations move to the cloud because it gives them speed, flexibility, global reach, better resilience options, and a much cleaner route for modernising older systems. A startup usually wants to move quickly without pouring a load of money into servers before it’s even proved the idea will work. A large enterprise might want to modernise older applications, improve disaster recovery, or give global users better latency.

The usual reasons are faster provisioning, less hardware to look after, access to managed services, room to experiment, and the financial flexibility that comes with OpEx-style spending. Cloud can also make business continuity a lot more practical, because backup, replication, and recovery options are usually easier to put in place than they are in one single on-premises site.

But cloud adoption has tradeoffs. It can introduce governance problems, unexpected cost growth, skills gaps, vendor dependency, and migration complexity. So the exam-safe answer is not “cloud is always better.” The better answer is that cloud offers strong advantages when matched to the right workload and managed well.

4. Cloud Deployment Models

AZ-900 expects you to tell the difference between public cloud, private cloud, hybrid cloud, and multicloud.

Public Cloud

Public cloud provides services on provider-managed infrastructure shared across many customers through multitenancy, with logical isolation between tenants. Azure is the core example. Public cloud gives you fast provisioning, a broad range of services, good scalability, and pay-as-you-go pricing. You might access it over the public internet, but Azure services can also be reached through private connectivity options like VPN, dedicated private connectivity, or private endpoints.

Private Cloud

Private cloud is a cloud environment dedicated to one organization. It may be hosted on-premises or by a third party. The key point is dedicated tenancy and greater control, not necessarily that the customer owns every physical facility outright. Private cloud can be a really good fit for specialised, legacy, or tightly regulated workloads, but there’s a catch: you’ll usually take on more management effort, and it won’t feel as elastic as public cloud.

Hybrid Cloud

Hybrid cloud means public cloud working together with on-premises or private infrastructure, but the key thing is integration. It’s not just about having both environments sitting there side by side; they’ve actually got to work together. In Azure, that integration might include Microsoft Entra ID, site-to-site VPN, dedicated private connectivity, Azure Arc, data synchronisation, central monitoring, or shared governance. Hybrid is really handy when you’re migrating in stages, dealing with compliance requirements, or keeping some workloads that just aren’t ready to move fully into the cloud yet.

Multicloud

Multicloud means an organisation is using services from more than one cloud provider. That is different from hybrid cloud. Hybrid cloud means you’re connecting cloud services with on-premises or private infrastructure. Multicloud, on the other hand, means you’re using services from more than one public cloud provider. Organisations often go multicloud for reasons like resilience, vendor flexibility, wider regional coverage, or access to specialist features. That said, it does add more complexity, and it usually comes with more governance overhead too.

5. Cloud service models: IaaS, PaaS, and SaaS in plain English

Service models are basically a way of showing how much of the tech stack Microsoft looks after for you, and how much still stays on your side.

IaaS

Infrastructure as a Service gives you virtualised infrastructure like Azure Virtual Machines, virtual networks, and storage. You’re responsible for the operating system, patching, applications, data, and the logical network and security settings. Microsoft handles the physical datacentre, the servers, the storage hardware, and the virtualisation layer. IaaS usually makes sense when you need maximum control or you’re moving older workloads that still depend on a server-style setup.

PaaS

Platform as a Service gives you a managed platform for applications and data, so you can focus more on building than on running the underlying infrastructure. Good examples are Azure App Service and Azure SQL Database. Microsoft manages the infrastructure, operating system, and much of the runtime and platform maintenance. You focus on your application, data, identity, and configuration. PaaS cuts down a lot of operational overhead and is often a really strong fit for modern web apps and APIs.

SaaS

Software as a Service gives you a finished application, like Microsoft 365 is a good example of SaaS, because it gives you a finished service that Microsoft runs for you.. Microsoft manages the application and underlying platform. The customer manages tenant settings, user access, data usage, and governance within their scope. SaaS provides the least infrastructure management but also the least low-level control.

A useful way to compare them is with the same workload. Suppose you need a company web application. With IaaS, you’re building the virtual machines, patching the operating system, and looking after the web server yourself. With PaaS, you deploy your code to App Service and let Microsoft take care of the platform underneath. With SaaS, you’re not hosting your own application at all — you’re simply using a finished service that the vendor provides.

6. Shared Responsibility Model

The shared responsibility model means Microsoft is responsible for security of the cloud, while the customer is responsible for security in the cloud. The exact split changes by service model and sometimes by the specific service and configuration.

With IaaS, a lot still sits on your side of the fence. You’re usually responsible for the guest operating system, patching, endpoint protection, application security, data protection, identities, and a lot of the logical network controls, like network security groups and firewall rules. With PaaS, Microsoft takes care of more of the platform underneath, but you’re still responsible for things like identities, access, application code, data governance, and configuration. With SaaS, Microsoft runs the application for you, but you still manage things like tenant access, user lifecycle, data classification, retention settings, and the settings inside your own tenant.

CCommon beginner mistake: assuming that cloud means Microsoft handles backups, logging, patching, and security for absolutely everything. Sometimes it does — and sometimes it definitely doesn’t. A VM requires much more customer management than a managed database or a Microsoft 365 is a good example of SaaS, because it gives you a finished service that Microsoft runs for you. tenant.

7. Serverless and Cloud-Native Services

Serverless computing means you don’t manage the underlying servers directly. Azure Functions is the main AZ-900 example here. It’s usually event-driven and often uses consumption-based billing, especially on Consumption plans, although the exact billing and scaling behaviour still depends on which plan you choose.

Typical triggers include HTTP requests, timers, queue messages, event notifications, and blob uploads. That’s why serverless is such a good fit for automation, background processing, lightweight APIs, and workloads that come in bursts. It also supports automatic scaling.

There are limits to remember. Serverless workloads are often designed to be stateless, they can hit cold starts, and they’re not always the best choice for long-running or heavily customised applications. The exam point is straightforward: serverless does not mean “no servers exist.” It means Microsoft manages them for you.

8. Core Benefits of Cloud Computing

AZ-900 tests several cloud benefits that sound similar but are not identical.

High availability and disaster recovery: the basics, explained simply

High availability means keeping a service available with as little downtime as possible, usually by building in redundancy and failover so one failure doesn’t bring the whole thing down. Disaster recovery is a different concern altogether — it’s about recovering from bigger disruptions like a regional outage, major data corruption, or the loss of an entire site. Cloud gives you the tools for both, but neither one just happens by default.

Scalability and Elasticity

Scalability is the ability to increase capacity. Scale up means adding more power to one resource, such as moving to a larger VM size. Scale out means adding more instances, such as more VMs behind a load balancer or more instances in Azure App Service.

Elasticity means resources can adjust dynamically, often automatically, as demand changes. Azure VM Scale Sets, App Service autoscale, and consumption-based services are all common examples. A system can definitely be scalable without being elastic if someone still has to jump in and make the changes manually.

Reliability

Reliability is about how consistently a system performs and how well it bounces back from failures while still meeting the expectations people have for it. Availability is mainly about whether the service is up and reachable, while reliability goes a bit wider and includes resilience, recovery behaviour, and how the system handles faults.

Predictability

Predictability covers both performance and cost, so it’s not just about how fast something runs. It’s also about knowing what the system is likely to do and what it’s likely to cost. Standardised deployments, monitoring, and governance help teams get a much clearer picture of how systems are likely to behave and what they’re likely to cost. That’s where budgets, tagging, and a consistent architecture really start to pay off in a practical way.

Security

Cloud security starts with identity, and honestly, that’s the part people underestimate most often. In Azure, that usually means Microsoft Entra ID, multifactor authentication, least privilege, and role-based access control. It also includes encryption at rest and in transit, network segmentation, secrets management with Azure Key Vault, and strengthening your security posture with services like Microsoft Defender for Cloud.

Governance and manageability basics in Azure

Governance helps keep Azure organised, consistent, and aligned with compliance requirements. The main concepts here are management groups, subscriptions, resource groups, role-based access control, resource locks, tags, and Azure Policy. Manageability means you can deploy and control resources through the Azure portal, Azure CLI, PowerShell, APIs, and Infrastructure as Code tools like ARM templates or Bicep. The big idea is consistency at scale, and that becomes absolutely crucial once environments start to grow and get messy.

9. Regions, Availability Zones, Region Pairs, and Connectivity

An Azure region is basically a geographic area that contains one or more datacentres. The region you choose affects latency, compliance, data residency, and resilience options. Not every Azure service is available in every region, so you’ve got to think about service availability as well as location.

Availability Zones are physically separate locations within selected Azure regions. They help protect against datacentre-level failure, but only if the service and your architecture are actually designed for zone redundancy or multi-zone deployment. Not every region supports Availability Zones.

Region pairs are Azure-defined regional relationships used in resiliency planning. They can affect platform recovery priorities and some replication patterns, but they won’t automatically fail over your workload for you. Real failover still depends on your architecture and on what the specific Azure service can actually do.

Connectivity also matters. Azure services may be consumed through public endpoints, private endpoints, VPN Gateway, or dedicated private connectivity. That is why “cloud over the internet” is only partly true. In many enterprise designs, cloud access is private or hybrid-connected.

10. Pricing Basics and Cost Control Fundamentals

Cloud pricing is built heavily around a consumption model: you pay for what you use. That usually shifts spending from CapEx, which is upfront investment in owned assets, toward OpEx, which is ongoing operating spend. In hybrid or private scenarios, organizations may still have both.

Azure cost is affected by more than just VM runtime. Key drivers include selected SKU or pricing tier, storage consumed, storage transactions, outbound data transfer, licensing, and whether resources are left running when not needed. Common savings approaches include right-sizing, shutting down dev/test resources, using reserved capacity where appropriate, and evaluating discounted pricing for interruptible workloads.

For planning, Azure provides pricing calculators and total cost comparison tools. For control, teams use budgets, cost alerts, tagging, and regular review of idle resources. Exam-safe message: cloud can be cost-effective, but it is not automatically cheaper.

11. Practical Azure Scenarios

Startup web app: Azure App Service fits because the team wants speed and low management overhead. Add Microsoft Entra ID integration, autoscale, and Azure SQL Database for a common PaaS design.

Legacy business application: Azure Virtual Machines fit if the app needs OS-level control or has tight dependencies. This is often the first migration step before modernization.

Enterprise hybrid environment: On-premises systems connect to Azure over VPN or dedicated private connectivity, identities are integrated with Microsoft Entra ID, and Azure Arc may help with unified management. This is hybrid cloud because the environments work together.

Seasonal retail demand: App Service autoscale or VM Scale Sets handle web traffic spikes, while Azure Functions process order events asynchronously. This demonstrates scalability and elasticity.

Microsoft 365 is a good example of SaaS, because it gives you a finished service that Microsoft runs for you.: A clear SaaS example. The organization manages users, access, and compliance settings, but not the underlying application platform.

12. Troubleshooting and Diagnostic Thinking for Beginners

If a cloud workload is costing too much, look for oversized resources, idle dev/test systems, the wrong pricing tier, heavy outbound data transfer, or poor tagging that hides ownership. If an app is not highly available, check whether it is running as a single instance, in a single zone, or without failover planning. If access is failing, examine role assignments, Microsoft Entra ID sign-in issues, conditional access, and network restrictions.

Azure fundamentals-level diagnostic services to know include Azure Monitor, Log Analytics, alerts, Service Health, and Azure Advisor. You do not need deep operational expertise for AZ-900, but you should understand that cloud environments are observable and manageable through monitoring and recommendations, not just manual guesswork.

13. Common AZ-900 Question Patterns and Final Review

Look for wording clues:

• Most control → IaaS
• Least management → SaaS
• Focus on code, not servers → PaaS
• Automatic adjustment to demand → Elasticity
• Integrated on-premises and cloud → Hybrid cloud
• Multiple cloud providers → Multicloud
• Upfront purchase → CapEx
• Pay for usage → OpEx

Rapid review:

• Cloud computing delivers services on demand with pooled resources and measured usage.
• Public cloud is shared and provider-operated; private cloud is dedicated; hybrid combines cloud with on-premises or private infrastructure; multicloud uses multiple providers.
• IaaS gives the most control, PaaS reduces platform management, and SaaS delivers finished software.
• Shared responsibility always exists and varies by service model and service type.
• Scalability is growth capacity; elasticity is dynamic adjustment.
• Availability is uptime and accessibility; reliability includes consistent operation and recovery.
• Regions affect latency and compliance; zones exist only in selected regions; region pairs support resiliency planning but do not replace architecture.
• Cloud cost depends on design and governance, not just the fact that it is cloud.

If you can explain those points in plain English and apply them to simple scenarios, you are well prepared for the Cloud Concepts portion of AZ-900.