AZ-900 Cloud Concepts: A Beginner-Friendly Guide to Azure Fundamentals

Introduction

AZ-900 Cloud Concepts is the foundation for the rest of Azure Fundamentals. If you can keep deployment models, service models, shared responsibility, resiliency terms, and pricing concepts straight, you’re already doing yourself a huge favor. That’s a big chunk of the exam right there. Honestly, it’s not usually the concepts themselves that cause the trouble. What usually trips people up is that a bunch of these terms sound almost the same when you’re hearing them for the first time. AZ-900 tests those distinctions directly.

The mental model to keep throughout this article is simple: cloud computing delivers IT capabilities on demand over a network; deployment models describe where workloads run and how environments are owned or integrated; service models describe how much of the stack the customer manages; and the shared responsibility model explains which tasks stay with the customer.

What Is Cloud Computing?

Cloud computing is the on-demand delivery of compute, storage, networking, databases, analytics, and software services over a network. In Azure, some services can also be accessed through private connectivity options such as ExpressRoute, so “over the internet” is common shorthand, but “over a network” is more precise.

Cloud works through virtualization, abstraction, and resource pooling. Virtualization is basically what lets one physical server host multiple isolated workloads at the same time. That’s a big part of how cloud providers get so much mileage out of the hardware they own. Abstraction basically hides all the hardware details you don’t need to think about day to day. So instead of sweating every layer underneath, you ask for the service you need and keep going. Resource pooling means a provider can serve many customers from shared infrastructure while keeping tenants logically isolated.

That last point matters: public cloud is typically a multi-tenant environment. Multiple customers use the provider’s infrastructure, but their workloads and data are separated through logical isolation and security controls.

Core Characteristics of Cloud Computing

AZ-900 questions often align well with the standard cloud characteristics. These are worth knowing because they explain why cloud behaves differently from traditional infrastructure.

On-demand self-service: customers can provision resources when needed without waiting for hardware procurement. In Azure, creating a virtual machine or storage account is an example.

Broad network access: services are accessible over standard network mechanisms from different client types and locations.

Resource pooling: provider resources are pooled to serve multiple customers efficiently, with logical isolation between tenants.

Rapid elasticity: resources can expand or contract quickly as demand changes.

Measured service: usage is metered, enabling consumption-based billing and cost tracking.

Exam cue: if a question emphasizes self-service, pooled resources, metered usage, or rapid adjustment, it is pointing to core cloud characteristics.

Why Organizations Move to the Cloud

Organizations move to the cloud for both business and technical reasons. The main drivers are agility, global reach, elastic capacity, reduced hardware ownership, and faster innovation. Instead of waiting for servers to be purchased, delivered, installed, and patched, teams can provision resources quickly and focus more on the workload itself.

Cloud can also improve business continuity and support modernization. A company with aging servers might move a legacy application into Azure virtual machines as a short-term lift-and-shift step, then later refactor it into a platform service.

But cloud is not automatically the right answer for every workload. Some systems have tight latency requirements, unsupported legacy dependencies, regulatory constraints, or cost patterns that make migration a lot harder than it looks on paper. I’ve seen more than one team discover that the app itself was only half the story—the dependencies were the real headache. I’ve seen plenty of teams discover that the spreadsheet looks good until they actually map out dependencies. And honestly, cloud can get expensive if resources are oversized or left running when nobody’s using them. For AZ-900, the balanced answer is this: cloud provides flexibility and speed, but it still requires design, governance, and cost control.

Public, Private, Hybrid, and Multicloud

Deployment models describe how cloud environments are deployed and integrated.

Public cloud uses provider-owned infrastructure in a multi-tenant environment. Customers consume services hosted in the provider’s datacenters, and logical isolation keeps each tenant separated from the others. So even though a lot of the physical infrastructure is shared, the workloads themselves are still separated. So even though the infrastructure is shared, the workloads are still kept apart. That’s a really important distinction for beginners to hold onto. This model is common for web apps, dev/test, analytics, and workloads that benefit from fast provisioning and elastic scale.

Private cloud is dedicated to a single organization. It can run on-premises, or it can also be hosted by a third party. The location can vary, but the important part is that the environment is dedicated to one organization. The important thing is that it’s dedicated to one organization, not shared across multiple customers the way public cloud is. That’s the real distinction, not just where the servers happen to sit. The key point is dedication to one organization, not necessarily physical ownership of every component. Also, private cloud is not just “virtualization in your server room.” A true private cloud should still offer cloud-like characteristics such as self-service and elasticity.

Hybrid cloud combines and integrates public cloud with private or on-premises environments so that apps, data, and processes can span both. That setup is very common during phased migrations, data residency scenarios, or when some systems need to stay local while others move into Azure. In the real world, that kind of split is often the norm rather than the exception. In real life, that’s often the most realistic path, not some clean all-at-once migration. Connectivity may use technologies such as VPN or ExpressRoute.

Multicloud is different from hybrid cloud. Multicloud simply means using cloud services from more than one provider. That’s all it means at the basic level. It doesn’t automatically mean anything is integrated across those environments. You can absolutely have multiple clouds without any real connection between them. Hybrid is about integration across environments; multicloud is about provider diversity.

Quick scenarios: a campaign website launched quickly in Azure fits public cloud. A dedicated regulated environment for one organization fits private cloud. A hospital keeping core records in a controlled environment while using Azure for patient portals is a classic hybrid cloud example. That kind of split is pretty common when not everything can move at once. A lot of organizations live in that in-between state for quite a while. A company using Azure and another cloud provider for different services fits multicloud.

IaaS, PaaS, and SaaS

Service models describe how much of the technology stack the customer manages.

IaaS provides infrastructure components such as virtual machines, storage, virtual networks, managed disks, load balancers, and network security groups. The provider handles the physical datacenter, the servers, the storage hardware, and the virtualization layer. Basically, they’re taking care of the heavy lifting underneath your workload. In other words, they take care of the stuff under the hood that you’d rather not own yourself. The customer still manages the guest operating system, a lot of the network and security settings, the applications, and the data. Azure Virtual Machines are the classic example.

PaaS provides a managed platform for building and running applications. With PaaS, the provider takes care of more of the stack, usually including the operating system, runtime, and platform maintenance. That’s a big reason teams like it when they’re trying to reduce operational overhead. That’s a pretty big shift if you’re coming from an infrastructure background. That leaves the customer with more time to focus on application code, configuration, identities, and data. Azure App Service, Azure SQL Database, and Azure Functions are useful Azure examples.

SaaS is finished software delivered as a service. The provider manages the application itself and most of the stack underneath it. From the customer’s point of view, it’s about using the software, not running the software platform. The customer still manages user access, tenant configuration, data governance, and how the service gets used. So the responsibility doesn’t disappear—it just shifts upward. Microsoft 365 and Dynamics 365 are common examples.

How to choose: use IaaS when a workload needs OS-level control or has legacy dependencies. Use PaaS when you want to focus on code and reduce the amount of platform administration you have to deal with. That tradeoff is really the whole point of PaaS. That tradeoff is really the whole point: more control with IaaS, less management burden with PaaS, and even less to manage with SaaS. Use SaaS when the business primarily wants to consume software rather than build and run it.

Understanding the Shared Responsibility Model

The shared responsibility model is often summarized as security of the cloud versus security in the cloud. The provider secures the underlying cloud platform. The customer secures what they deploy, configure, store, and allow users to access.

In IaaS, Microsoft manages the physical hosts and virtualization platform, but the customer is still responsible for the guest OS, patching, application security, identities, many network controls, backups they configure, and data protection decisions.

In PaaS, Microsoft manages more of the platform, but the customer still secures application code, secrets, identities, access policies, and data.

In SaaS, Microsoft manages the application service itself, but the customer still controls user accounts, MFA, data classification, retention choices, sharing settings, and device posture.

Examples: replacing failed datacenter hardware is the provider’s responsibility. Patching Windows inside an Azure VM is the customer’s responsibility. Securing custom code in App Service is the customer’s responsibility. Configuring MFA for Microsoft 365 users is the customer’s responsibility.

This is where beginners often make mistakes: cloud does not remove customer responsibility. Misconfigured access, weak identities, poor data governance, and unprotected endpoints can still create risk even when the platform itself is secure.

Authentication, Authorization, and RBAC Basics

AZ-900 candidates also benefit from a basic identity model. Authentication means proving who you are. Authorization means determining what you are allowed to do. Microsoft Entra ID is Microsoft’s cloud-based identity and access management service used for authentication, authorization, and identity governance scenarios across Azure and Microsoft cloud services.

Azure RBAC is role-based access control. It lets permissions be assigned based on roles instead of giving everyone broad access. This supports least privilege, meaning users should receive only the access they need.

Exam cue: “sign in” points toward authentication. “permissions” points toward authorization. “assign a role” points toward RBAC.

Scalability, Elasticity, Availability, Reliability, Fault Tolerance, and Disaster Recovery

These terms are related but not interchangeable.

Scalability is the ability to increase or decrease capacity. It can be vertical or horizontal. Vertical scaling means scaling up or down, like moving to a bigger VM size. That’s the “bigger box” approach. Horizontal scaling means scale out or in, such as adding or removing instances behind a load balancer.

Elasticity is the ability to automatically or dynamically allocate and deallocate resources as demand changes. Both the expansion and the contraction matter. If an e-commerce site adds instances during a sale and then removes them once traffic drops, that’s elasticity. That automatic up-and-down behavior is the key clue. If it reacts to demand on its own, you’re in elasticity territory. Autoscaling may use triggers such as CPU usage or queue length.

High availability focuses on minimizing downtime and keeping a service accessible during normal failures. Fault tolerance is stronger: the system continues operating with little or no interruption even when a component fails. Reliability is the broader ability of a system to perform consistently, recover from failures, and continue meeting expected service levels over time.

Disaster recovery focuses on restoring service after a major disruptive event, such as a regional outage. Two useful fundamentals terms are RPO and RTO. RPO is the acceptable data loss window. RTO is the acceptable recovery time.

Quick mapping: “grow with demand” suggests scalability. “automatic response to demand” suggests elasticity. “stay online during failures” suggests high availability. “continue operating through component failure” suggests fault tolerance. “recover after a major outage” suggests disaster recovery.

Resiliency Design Building Blocks in Azure

Azure provides infrastructure building blocks that support resiliency. Geographies are broad market areas that can contain multiple regions and may align with compliance or data residency needs. Regions are sets of datacenters within a geographic area. Availability Zones are separate physical locations within a region, each with independent power, cooling, and networking. Not every Azure region supports Availability Zones, so support varies by region and service.

Region pairs are an Azure resiliency concept in which most regions are paired with another region in the same geography, with some exceptions and nuances for newer geographies. Region pairs help support platform update sequencing and disaster recovery prioritization concepts.

For performance and resiliency, region selection depends on latency, compliance, service availability, and cost. A workload serving European users will usually perform better in a nearby region. That’s just the practical reality of distance and latency. A regulated workload may need data residency in a specific geography, which is another reason region choice matters. That’s not just a technical choice—it can be a legal or business one too. A highly available design might use multiple zones in one region, while a disaster recovery design might replicate to another region.

Azure also has edge network presence and content delivery capabilities that help bring content closer to users for lower latency scenarios.

Consumption-Based Pricing, CapEx vs OpEx, and Basic Cost Optimization

Traditional on-premises environments often require CapEx, meaning upfront capital spending on hardware. Cloud commonly shifts spending toward OpEx, meaning ongoing operational spending based on usage. The classic model is pay-as-you-go, but cloud pricing is not limited to that. Azure also offers options such as reservations or reserved capacity, and some organizations operate with mixed financial models.

Common cost drivers include compute runtime, storage consumed, data transfer, performance tier, and licensing choices. Practical cost control matters even at the fundamentals level, not just in advanced architecture conversations. In other words, this isn’t a “later” topic—it’s part of understanding cloud properly. Useful habits include right-sizing resources, stopping or deallocating unused dev/test VMs, using budgets and alerts, and applying tagging for cost tracking or chargeback.

Scenario: if dev/test VMs are left running overnight and monthly cost rises, that is still the consumption model working as designed. The fix is governance and optimization, not assuming cloud pricing is wrong.

Azure Organization Basics

Although this sits slightly beyond pure cloud theory, it helps with exam clarity. The Azure hierarchy is commonly described as management groups > subscriptions > resource groups > resources.

A subscription is a logical container and a billing, access, and administrative boundary. A resource group is a logical container for resources in a subscription. A resource can belong to only one resource group, resource groups cannot be nested, and resources in the same resource group can still exist in different regions.

An Entra ID tenant provides the identity context. Subscriptions sit under that identity context for billing and administration. This is a common exam confusion: tenant/directory is about identity; subscription is about billing and administrative scope.

Example: Management Group: Contoso. Subscription: Production. For example: Resource Group: WebApp-RG. Resources: App Service, SQL Database, Storage Account.

SLA, Uptime, and Architecture Reality

An SLA is a provider commitment, usually expressed as an uptime percentage. It’s also a financial or contractual commitment, and service credits may apply if the SLA isn’t met. But an SLA does not guarantee zero downtime, and it does not replace good architecture.

If a workload uses multiple services, the effective availability depends on the design, not just a single service’s SLA. That’s why architecture choices like zone redundancy, replication, backups, and failover planning matter. High SLA numbers are useful, but they are not the same as business continuity.

Common AZ-900 Cloud Concept Confusions

Deployment model vs service model: deployment is about environment placement and integration; service model is about management responsibility.

Hybrid vs multicloud: hybrid integrates on-prem/private and public cloud; multicloud uses multiple cloud providers.

Scalability vs elasticity: scalability is capacity change; elasticity is dynamic or automatic scaling, including scale-in.

High availability vs fault tolerance vs disaster recovery: minimize downtime, continue through failure, recover after major disruption.

Authentication vs authorization: prove identity, then determine permissions.

SaaS responsibility myth: provider manages the software platform, but the customer still manages identities, access, data governance, and configuration.

Rapid Scenario Drills for AZ-900

Legacy payroll app with OS dependencies: likely IaaS.

New customer web app where the team wants to focus on code: likely PaaS.

Email and collaboration platform consumed as a finished service: likely SaaS.

Healthcare provider keeps sensitive records in a controlled environment but uses Azure-hosted portals for external users: hybrid cloud.

Retail site automatically adds instances during a holiday sale: elasticity.

One zone fails but the service remains available from another zone: high availability, possibly fault-tolerant depending on the design and interruption level.

Regional outage requires failover to another region with defined recovery targets: disaster recovery with RTO/RPO considerations.

Exam Strategy and Final Review

For AZ-900, focus on keyword spotting. Automatic usually points to elasticity. Finished software points to SaaS. OS-level control points to IaaS. Billing boundary points to subscription. Identity sign-in points to Entra ID and authentication. Permissions point to authorization or RBAC. Upfront purchase points to CapEx.

The most testable distinctions are these: public/private/hybrid/multicloud, IaaS/PaaS/SaaS, customer versus provider responsibility, scalability versus elasticity, and high availability versus fault tolerance versus disaster recovery. If you can explain each pair in one sentence without notes, you are in good shape.

Conclusion

Cloud Concepts is not just the first AZ-900 objective; it is the framework that makes the rest of Azure Fundamentals make sense. Learn the cloud characteristics, understand deployment and service models, keep the shared responsibility model clear, and separate the resiliency terms carefully. Once those distinctions are solid, the exam stops feeling like a list of similar words and starts feeling like a set of logical choices.