Microsoft Azure Fundamentals AZ-900: Cloud Concepts Explained

1. What Is Cloud Computing?

Here’s the simplest way I think about cloud computing: you get the IT resources you need, when you need them, over the internet or through provider-hosted connectivity, and you usually pay only for what you actually use. In Azure terms, that means you can stand up compute, storage, networking, databases, identity services, analytics, and a whole lot more without first buying, racking, and cabling physical hardware.

For AZ-900, the key idea is not “servers somewhere else.” It is service consumption. Traditional on-premises IT usually requires upfront purchasing, capacity forecasting, deployment lead time, and ongoing maintenance. Cloud changes that operating model by giving you faster provisioning, more flexible scaling, and a shift away from owning the physical infrastructure.

Microsoft Azure is Microsoft’s public cloud platform. Azure provides the services; cloud computing is the broader model behind how those services are delivered.

Cloud platforms also come with a handful of core characteristics that make them different from old-school hosting:

• The nice thing about on-demand self-service is that you’re not stuck waiting on a hardware refresh cycle just to get moving.: users can provision resources when needed without waiting for hardware procurement.
• Broad network access: services are accessible over standard networks from many device types.
• Resource pooling: provider resources are shared efficiently across customers using multi-tenant architecture with logical isolation.
• Rapid elasticity: capacity can expand or contract quickly.
• Measured service: usage is monitored and billed according to consumption or service-specific pricing models.

2. Why Organizations Move to Cloud Services

Organizations move to the cloud for a mix of business and technical reasons — faster delivery, less datacenter overhead, global reach, better resiliency options, access to managed services, and, honestly, much clearer cost visibility. The first win is often agility rather than immediate savings. A team that can deploy a test environment in an hour instead of waiting weeks for hardware gains a real business advantage.

Common adoption drivers include:

• Speed: faster provisioning for development, testing, and production workloads.
• Operational efficiency: less time spent on physical hardware, firmware, and facility management.
• Global deployment: place workloads closer to users for better latency.
• Resiliency: use backup, replication, and distributed infrastructure more easily.
• Innovation: consume managed databases, AI, analytics, and app platforms without building everything from scratch.
• Cost governance: track and optimize spend more frequently than in a hardware refresh model.

And honestly, cloud isn’t the right fit for every workload, so you’ve really got to stay realistic about what should move and what should stay put. That’s just being practical. Some systems have tight latency requirements, licensing limitations, regulatory constraints, or older dependencies that make cloud adoption a lot more complicated than people first expect. That’s usually where the real-world trade-offs start to show up, and honestly, that’s where the conversation gets a lot more interesting. That’s why organizations usually take a careful look at workload fit, data residency, integration dependencies, and risk before they move anything at all.

3. At the simplest level, CapEx vs. OpEx comes down to whether you’re buying infrastructure upfront or paying for services as you use them. That’s really the core difference.

CapEx is capital expenditure: upfront investment in assets such as servers, storage, switches, or datacenter equipment. OpEx is operational expenditure: ongoing spending to run services, such as Azure subscriptions and resource consumption.

Cloud often shifts spending away from CapEx and toward OpEx because you’re consuming provider-hosted services instead of buying the infrastructure yourself. That can mean lower startup costs and a lot more flexibility, but it definitely doesn’t guarantee a lower total cost. Azure pricing can include pay-as-you-go consumption, reserved capacity or commitment-based discounts, licensing costs, and fixed service charges, depending on the service you’re using.

A practical example: buying on-premises hardware based on a three-year forecast is a classic CapEx move. Running Azure VMs monthly is OpEx. If those VMs are oversized or left running when nobody needs them, OpEx can climb pretty quickly. Cost optimization matters.

4. Core Benefits of Cloud Computing

For AZ-900, you really do need to keep a few related cloud benefits straight, because they’re easy to mix up.

High availability means designing services to stay accessible during failures. In Azure, that could mean redundant instances, Availability Sets for VMs, or Availability Zones in supported regions. People usually talk about high availability in terms of uptime targets and service level agreements.

Disaster recovery is different. Disaster recovery is what you do to restore service after a serious outage has already happened. You will often hear two recovery terms: RPO (Recovery Point Objective), which is how much data loss is acceptable, and RTO (Recovery Time Objective), which is how quickly service must be restored.

Scalability is the ability to increase or decrease capacity. Vertical scaling means scale up or down, such as moving to a larger or smaller VM size. Horizontal scaling means scale out or in, such as adding or removing instances. Elasticity usually implies automatic or near-real-time adjustment based on demand.

Reliability is the ability of a workload to perform consistently over time. Resiliency is the ability to recover from failures and continue operating. They’re connected, absolutely, but they’re not the same thing at all. A lot of beginners confuse them at first, and honestly, I get it — but in real environments, they work very differently.

Predictability includes both performance and cost. Azure can improve predictability with monitoring, pricing tools, budgets, tagging, and right-sizing, but a lot still comes down to how well the environment is planned and managed. The platform helps, but it doesn’t replace good design.

Security means using platform capabilities and secure configuration to protect identities, data, applications, and networks. Azure gives you a lot of security features, but customers still need to make some very important decisions about access, exposure, encryption, and how data’s handled. And yeah, those decisions still matter a lot.

Governance is broader than security. It includes policy enforcement, compliance, organization, cost control, lifecycle standards, and the day-to-day consistency that keeps environments from turning into a mess. Without governance, cloud can get messy fast, and I’ve seen that happen more than once.

Manageability improves through centralized portals, automation, templates, APIs, monitoring, and Infrastructure as Code.

5. When you compare IaaS, PaaS, and SaaS, you’re really deciding how much control you want versus how much operational responsibility you’re willing to keep. That trade-off is the heart of the decision.

IaaS provides virtualized infrastructure such as VMs, storage, and networking. Microsoft manages the physical datacenters, the physical network, the storage layer, and the hypervisor sitting underneath it all. You’re still responsible for the guest operating system, patching, applications, data, and network controls at the resource level, such as network security groups and firewall rules.

PaaS provides a managed platform. Microsoft takes care of more of the stack here, including things like the operating system and runtime. You can focus more on application code, data, configuration, secrets handling, and identity integration. Good examples include Azure App Service and Azure SQL Database, both of which take a lot of infrastructure work off your plate. That’s a big reason teams like PaaS — it takes a lot of the operational burden off their plate.

SaaS delivers a complete application, such as Microsoft 365. In that model, the provider takes care of the application itself, the platform it runs on, and the infrastructure underneath it. That’s what makes SaaS the least hands-on option for most customers. The customer still handles tenant configuration, user access, data governance, and the security settings associated with the service.

6. Shared Responsibility Model

Shared responsibility means Microsoft secures the cloud, while customers secure what they place in the cloud. The exact split of responsibilities changes depending on the service model, and sometimes even on how a specific service is configured. So yeah, there isn’t a one-size-fits-all answer here.

Even with SaaS, customers still have responsibilities like identity, data classification, endpoint security, tenant configuration, and access control. So no, SaaS doesn’t mean you can stop paying attention and walk away from the service. Moving to the cloud changes who handles what, but it definitely doesn’t make responsibility disappear. Someone still has to own each part of the stack.

Quick responsibility check: physical datacenter security = Microsoft; VM guest OS patching = customer; app code in App Service = customer; user access in Microsoft 365 = customer.

7. Cloud Deployment Models

Public cloud uses provider-hosted infrastructure shared across customers with logical isolation. Azure is a public cloud platform. Access may occur over the internet or through private connectivity options such as dedicated private network connectivity.

Private cloud delivers cloud characteristics such as self-service, elasticity, and pooled resources in an environment dedicated to one organization.

Hybrid cloud combines public cloud with on-premises or private cloud resources. A very common pattern is to keep legacy databases on-premises while moving applications, backup, or identity services into Azure. For larger environments, that kind of split is often the most practical way to move forward.

Multi-cloud means using more than one cloud provider. It isn’t automatically more resilient, either; resilience only improves if the architecture, identity, operations, and data replication are planned for it on purpose.

8. Azure Global Infrastructure Basics

An Azure geography is a market or boundary area that usually contains multiple regions. A region is a set of one or more datacenters in a specific geographic area. An Availability Zone is a physically separate location within a supported Azure region, made up of one or more datacenters with independent power, cooling, and networking. Not every Azure region supports Availability Zones, and not every service is available in every region. That’s one reason region selection deserves careful attention.

A region pair is a Microsoft-defined pairing used to support platform recovery priorities and update sequencing, but region pairs do not automatically fail over your applications. Customers still need to design and implement their own disaster recovery plans. That’s one of those details people sometimes miss early on, so it’s definitely worth keeping in mind.

For AZ-900, region selection usually comes down to latency, compliance, data residency, and service availability.ity. Those are the big factors to keep in mind. Azure also offers edge delivery and content distribution options that help place content closer to users. That can make a real difference for performance.

9. Azure Resource Organization and Governance Tools

Azure organizes resources through a hierarchy: management groups → subscriptions → resource groups → resources. Azure Resource Manager is the deployment and management layer behind that whole model.

Management groups let you apply governance across multiple subscriptions. Subscriptions are billing, governance, role-based access control, and policy boundaries. Resource groups are logical management containers; a resource can belong to only one resource group at a time. You don’t have to put every related resource in the same resource group. Sometimes that’s helpful, but sometimes it isn’t. Where you place resources usually depends on their lifecycle, access requirements, governance scope, and how you deploy and manage them. In other words, it depends on how the environment is actually used.

Some key governance tools include:

• RBAC: authorization in Azure; controls who can do what at which scope.
• Azure Policy: enforces or audits standards, such as allowed regions or required tags.
• Tags: metadata for cost reporting, ownership, and automation.
• Resource locks: help prevent accidental deletion or modification.
• Budgets: support cost governance and alerts.

Example: assign a policy at the management group level requiring a CostCenter tag, then use RBAC at the subscription level so only approved teams can create production resources.

10. Identity, Security, and Compliance Basics is where the cloud conversation starts getting very practical, because access, protection, and oversight all begin to intersect.

Microsoft Entra ID is Microsoft’s cloud identity and access management service, formerly known as Azure Active Directory. This name change matters because older study materials may still use the previous name.

Authentication proves who you are. Authorization determines what you are allowed to do. In Azure, RBAC is one of the core authorization mechanisms.

Some important security concepts for AZ-900 include:

• Zero Trust: verify explicitly, use least privilege access, assume breach.
• MFA: require more than one factor at sign-in.
• Conditional Access: apply access decisions based on user, device, location, or risk conditions.
• Encryption: protect data at rest and in transit.
• Key management: services such as Azure Key Vault help manage secrets, keys, and certificates.
• Security posture: Microsoft Defender for Cloud helps assess recommendations and strengthen security posture.

Compliance and data residency are related but separate from security. A workload may be secure yet still fail a regulatory requirement if data is stored in the wrong geography.

11. Connectivity, Scaling, and Practical Azure Examples

Public cloud does not always mean “public internet only.” Azure workloads can be reached over the internet, through site-to-site VPN, or by private connectivity such as dedicated private network connections. Hybrid identity can also be integrated so on-premises users access Azure resources with consistent identity controls.

For scaling, Azure examples include:

• VM Scale Sets: scale sets of VMs horizontally.
• Autoscale rules: add instances when CPU or other metrics cross a threshold.
• App Service scale options: scale app plans up or down, or out and in.

Simple autoscale example: if CPU stays above 70% for 10 minutes, add an instance; if it stays below 30% for 20 minutes, remove one. That is elasticity in practice.

Simple high-availability design example: deploy two VM instances in an Availability Set or across Availability Zones in a supported region, place them behind a load balancer, and monitor health. For stronger disaster recovery, replicate or redeploy into another region and define RTO and RPO expectations.

12. Troubleshooting and Diagnostics Fundamentals

Cloud does not remove troubleshooting. It changes the tools and layers you investigate.

• Availability issue: check service health, region status, metrics, and whether the app was designed for redundancy.
• Access denied: verify authentication, then check RBAC role assignments, scope, and Conditional Access requirements.
• Policy denied deployment: review the Azure Policy assignment and compliance details to see which rule blocked the resource.
• Cost spike: use cost management tools, tags, and activity history to identify new or oversized resources.
• Performance issue: review metrics, right-size the service tier, consider autoscaling, and check region placement or content delivery design for latency-sensitive apps.

Azure Monitor, Activity Log, metrics, logs, and alerts are core diagnostic tools at a fundamentals level.

13. Real-World Decision Scenarios

Startup building a new web app: public cloud plus PaaS is often best. It reduces infrastructure administration and supports rapid release cycles.

Enterprise with legacy systems: hybrid cloud is common. Keep some systems on-premises, extend identity and selected workloads to Azure, and migrate in phases.

Regulated organization: choose regions carefully for residency and compliance, enforce governance with Policy and RBAC, and design disaster recovery intentionally rather than assuming region pairs solve it automatically.

Business needing collaboration tools fast: SaaS such as Microsoft 365 fits because the organization wants outcomes, not server administration.

14. AZ-900 Exam Traps and Rapid Review

Common traps:

• Cloud does not mean Microsoft manages everything.
• PaaS does not mean no responsibility.
• Hybrid is not multi-cloud.
• Availability Zones are not the same as region pairs.
• Authentication is not authorization.
• High availability is not disaster recovery.

Final advice: study Cloud Concepts as decisions, not isolated definitions. Ask: what business problem is being solved, what level of control is needed, who is responsible, and what trade-off is acceptable? That mindset is exactly what AZ-900 tests.