Azure Fundamentals AZ-900: Cloud Concepts Explained for Beginners

Introduction

Honestly, Cloud Concepts is where AZ-900 really begins. Once you’ve got a handle on what the cloud actually is, why companies go for it, how the service models differ, and where the responsibility shifts, Azure starts feeling a lot less like a jumble of similar-sounding terms and a lot more like something you can actually reason through. This is also where a lot of people get tripped up by the wording, honestly. Scalability versus elasticity, high availability versus disaster recovery, hybrid versus multicloud, and IaaS versus PaaS all sound pretty close until you slow down and compare them side by side.

My goal here is pretty simple: I want you to walk away with cloud concepts you can actually use on the exam and in real environments too. We’ll keep the focus on the AZ-900 skills measured, but I’ll tie the ideas back to actual Azure examples so the terms mean something practical.

What Is Cloud Computing?

Cloud computing is the delivery of computing services over a network, typically over the internet or through private connectivity, such as VPN or Azure ExpressRoute. So instead of buying all the gear and taking care of every piece yourself, you just consume compute, storage, networking, platforms, and software as services when you need them.

For AZ-900, it’s absolutely worth knowing both the plain-English definition and the core characteristics behind it:

• On-demand self-service — resources can be provisioned when needed without waiting for hardware procurement.
• Broad network access — services are accessible over network connections from different client types and locations.
• Resource pooling — provider resources are pooled to serve many customers efficiently.
• Rapid elasticity — resources can expand or contract quickly as demand changes.
• Measured service — usage is monitored and billed based on consumption.

Two supporting ideas matter here. First, multi-tenancy means a provider can serve multiple customers on shared underlying infrastructure while keeping customer environments logically isolated. Second, abstraction means you consume a service without needing to manage every physical component behind it.

Virtualization is part of that story because it allows physical hardware to host multiple logical workloads. Containers add another layer of packaging consistency, but remember this for the exam: containers are not a formal cloud service model. They are a deployment and runtime approach. If you run them yourself on virtual machines, that behaves more like IaaS. If you use a managed container platform, it behaves more like PaaS from an operations perspective.

Why Organizations Move to the Cloud and What They Get Out of It

Organizations move to the cloud for a mix of business and technical reasons—faster delivery, easier scaling, global reach, better resilience, and less infrastructure overhead to deal with. But AZ-900 also expects you to know the formal cloud benefits and how they’re different from one another.

High availability means keeping services accessible during expected component failures or maintenance. In Azure, that often means using multiple instances, load balancing, and sometimes availability zones so things keep running smoothly.

Scalability means increasing capacity to handle growth. This can be scale up (vertical scaling, such as choosing a larger VM size) or scale out (horizontal scaling, such as adding more instances).

Elasticity means capacity can grow and shrink with demand, often automatically. So, if a retailer gets slammed during a holiday sale and needs extra web capacity for a few hours or even a few days, then scales back once the rush is over, that’s a perfect example of elasticity.

Reliability means the system performs correctly and consistently over time. Availability is about whether the service is reachable; reliability is about whether it behaves as expected.

Predictability means performance and cost can be planned with greater confidence through standardization, monitoring, and repeatable deployments.

Security, governance, and manageability are also core benefits. Cloud providers give you a solid set of platform capabilities, but you still have to configure and use them correctly on your side.

One practical caution I always give people: cloud can absolutely improve speed and flexibility, but that doesn’t mean it automatically makes everything cheaper or better. If the architecture is messy, governance is loose, or you’ve sized resources way bigger than you actually need, waste can pile up pretty quickly.

Public, private, hybrid, and multicloud

Public cloud is owned and operated by a third-party cloud provider and delivered over public or private connectivity. In Azure’s public cloud, Microsoft takes care of the physical datacenters and core infrastructure, while customers consume services on top of that foundation.

Private cloud is dedicated to one organization. It can be on-premises or hosted by a third party, but it isn’t shared with other customers. And just to be clear, private cloud can still use cloud-style automation and self-service.

Hybrid cloud combines public cloud with private or on-premises resources in an integrated environment. The big thing to remember there is integration. Identity, networking, management, or data flows connect the environments.

Multicloud is different. It means using services from more than one cloud provider, such as Azure plus another major cloud platform, but that alone does not automatically make it hybrid.

In Azure, hybrid usually involves services such as VPN Gateway, ExpressRoute, Microsoft Entra ID integration, backup, and management across both on-premises and cloud resources.

IaaS, PaaS, and SaaS are basically the three big cloud service models you’ll keep running into.

These service models are really just about how much the provider manages versus how much you still manage.

IaaS gives you infrastructure such as virtual machines, storage, and networking. Azure Virtual Machines are the classic example here. You manage the guest operating system, patching, applications, data, and many security settings.

PaaS gives you a managed application platform. Azure App Service and Azure SQL Database are solid examples. Microsoft takes care of more of the underlying platform, but you’re still on the hook for your code, data, access, and usually things like scaling rules or app configuration.

SaaS gives you a complete application, such as Microsoft 365. The provider takes care of the application, the platform it runs on, and the infrastructure underneath it too. But you’re still responsible for things like tenant settings, user identities, access control, data handling, retention policies, and the compliance settings around all of that.

Two common exam edge cases:

• Azure Functions is serverless compute and is generally treated as highly managed PaaS.
• Containers/Kubernetes are not separate service models. How they’re operated depends on whether you manage the hosts yourself or use a managed service.

If a question says full OS control, think IaaS. If it says focus on code, think PaaS. If it says ready-to-use application, think SaaS.

Getting the Shared Responsibility Model Straight

The shared responsibility model means Microsoft is responsible for security of the cloud, while the customer is responsible for key aspects of security in the cloud. The exact split does change depending on the service and how it’s set up, but the big pattern stays the same: as you move from IaaS to PaaS to SaaS, Microsoft takes on more of the heavy lifting, but you never get to drop your responsibility entirely.

Practical examples make this easier:

• An unpatched Windows VM in Azure gets compromised. That is primarily the customer’s responsibility in IaaS.
• An App Service app is breached because the code has a vulnerability. The platform is managed by Microsoft, but the insecure code is still the customer’s responsibility.
• A Microsoft 365 tenant has no MFA and weak permissions, leading to account compromise. That is still the customer’s responsibility.

Also be careful with backup assumptions. A provider may deliver a resilient service, but workload-level backup, retention design, and recovery procedures may still be customer responsibilities depending on the service.

Azure infrastructure basics: regions, zones, region pairs, and SLAs

Azure regions are geographic areas containing one or more datacenters. The region you choose can affect latency, compliance, data residency, service availability, and sometimes even pricing too.

Availability zones are physically separate locations within some Azure regions. They help improve resilience inside a region, but not every region supports availability zones, and not every service supports zonal or zone-redundant deployment.

Region pairs support business continuity planning. They provide a logical secondary region relationship, but region pairs do not automatically fail over your workloads. You still have to plan replication and failover yourself, usually by using service features like backup, geo-replication, or Azure Site Recovery.

For disaster recovery, there are two basic terms worth knowing:

• RPO — Recovery Point Objective, or how much data loss is acceptable.
• RTO — Recovery Time Objective, or how quickly service must be restored.

SLAs are Microsoft’s financial commitments regarding service availability. They don’t mean your app will never go down, though. That’s the part people sometimes misunderstand. Higher availability usually depends on the service tier you pick and how you design the solution — things like using multiple instances, availability zones, or even multiple regions.

Azure Examples That Make the Concepts Real

Use a few anchor examples to connect the theory:

• Azure Virtual Machines — IaaS, best when you need OS-level control or are lifting and shifting a legacy server.
• Azure App Service — PaaS, best when you want to host web apps or APIs without managing the underlying OS.
• Azure Functions — event-driven serverless compute, useful when you want very high abstraction and pay for execution.
• Microsoft 365 — SaaS, best when the business needs a complete collaboration platform instead of building one.

A common exam scenario is a company modernizing in phases—moving email to Microsoft 365, keeping a legacy app on Azure VMs, and building a new API on App Service. That single company is using multiple service models at once, which is completely normal.

Networking, Storage, Identity, Governance, and Security Fundamentals

At the AZ-900 level, you don’t need deep engineering detail, but you absolutely do need to understand the concepts.

Networking: Azure Virtual Network provides private network boundaries. Inside a VNet, you use subnets to segment workloads, network security groups to control traffic, and sometimes peering to connect VNets. Hybrid connectivity often uses VPN Gateway or ExpressRoute. Azure Load Balancer spreads traffic at the network layer, while Azure Application Gateway is usually the better fit when you need web-focused features like HTTP awareness and smarter request handling.

Storage: Blob Storage is for unstructured data, Azure Files is for managed file shares, and Managed Disks support VMs. For Blob Storage, access tiers include hot, cool, and archive. Redundancy options such as LRS, ZRS, GRS, and GZRS affect durability and resilience. Archive is not a separate storage service; it is an Azure Blob Storage archive tier.

Identity: Microsoft Entra ID (formerly Azure Active Directory or Azure AD) is central to cloud access. Authentication is basically proving your identity — in other words, showing the system that you really are who you claim to be. Authorization kicks in after that and decides what you’re allowed to do once the system knows who you are. Azure role-based access control, or RBAC, assigns permissions at scopes such as management group, subscription, resource group, or resource. MFA and Conditional Access are core protections.

Governance: Azure uses management groups, subscriptions, and resource groups for organization. Tags help with ownership and cost tracking. Azure Policy can enforce rules such as allowed regions or required tags. Resource locks help prevent accidental deletion. Budgets and alerts help you spot spending early, before it slowly creeps up and turns into a nasty surprise at the end of the month.

Security: Think Zero Trust, least privilege, encryption at rest and in transit, secrets protection, and controlled network exposure. At the fundamentals level, that usually shows up in tools and controls like NSGs, private endpoints, Key Vault, Defender for Cloud, MFA, and, honestly, a strong identity foundation.

CapEx vs OpEx and Cloud Cost Basics

CapEx is upfront spending on long-term assets. OpEx is ongoing operational spending. Cloud often shifts organizations toward OpEx because they consume services as needed instead of buying all infrastructure in advance.

That said, cost control in the cloud still matters a lot, maybe even more than people expect at first. Pay-as-you-go gives you flexibility, but the bill still depends on what you leave running or allocated. A VM that is properly deallocated may stop compute charges, but storage, backups, public IPs, and other associated resources can still cost money. And just shutting down a VM from inside the guest OS isn’t always the same thing as deallocating it in Azure.

At the fundamentals level, keep these optimization ideas in mind:

• Right-sizing — choose resource sizes that fit actual usage.
• Reservations or reserved capacity — lower cost for predictable long-term usage.
• Spot pricing — lower-cost capacity with the risk of interruption.
• Azure Hybrid Benefit — use eligible existing licenses to reduce some costs.
• Budgets and Cost Management — monitor and control spending.

Troubleshooting and Diagnostic Thinking for Cloud Concepts

Even at the fundamentals level, it helps to understand how cloud issues get investigated. Azure uses tools such as Azure Monitor, metrics, logs, alerts, Activity Log, and Service Health to help diagnose problems.

Common beginner failure points are predictable:

• Connectivity problems — often caused by NSG rules, routing, DNS, or missing hybrid connectivity.
• Access denied — usually identity, RBAC, MFA, Conditional Access, or tenant configuration.
• Unexpected cost — idle resources left running, oversized SKUs, or storage still allocated after compute is stopped.
• Region mismatch — a chosen service or feature may not be available in every region.
• Quota or limit issues — deployment fails because the subscription or region has limits.

For exam purposes, the lesson is this: if the problem sounds like permissions, think identity or RBAC. If it sounds like traffic flow, think networking. If it sounds like “why is this still costing money,” think persistent resources and billing scope.

AZ-900 Exam Traps and Answer Strategy

AZ-900 questions often look simple until two answer choices both seem reasonable. The trick is to identify the business requirement first.

• Temporary spike → elasticity
• Long-term growth → scalability
• Stay online during component failure → high availability or fault tolerance
• Recover after major outage → disaster recovery
• Need full OS control → IaaS
• Focus on code, not servers → PaaS
• Complete application for end users → SaaS
• Integrated on-premises plus cloud → hybrid cloud
• Using multiple cloud vendors → multicloud

If you’re stuck between two answers, ask yourself: is the question about control, convenience, normal failure, major disaster, or temporary demand? That usually reveals the right option.

Final Takeaways

For AZ-900 Cloud Concepts, know these cold: what cloud computing is, the difference between public/private/hybrid/multicloud, the difference between IaaS/PaaS/SaaS, how shared responsibility shifts, and how to distinguish scalability, elasticity, high availability, and disaster recovery.

Also remember the Azure-specific anchors: regions, availability zones, region pairs, Virtual Machines, App Service, Functions, Microsoft Entra ID, and the basic cost model. If you can read a short scenario and explain why one concept fits better than another, you are in very good shape for the exam.