AZ-900: Understanding Azure Cloud Fundamentals

AZ-900, Microsoft Azure Fundamentals, introduces the concepts a practitioner needs to make sense of cloud services before choosing a technical specialization. Its audience includes developers, administrators, analysts, managers, and people working with cloud procurement or governance. Candidates are not expected to operate a large enterprise Azure platform, but they should explain cloud models, basic infrastructure and platform services, management controls, and cost decisions without confusing a product's name with its purpose. The exam remains active as of October 2026. Strong preparation connects business requirements to cloud mechanisms: why a service is used, which responsibilities Microsoft assumes, which remain with customers, and what evidence can show a deployment is secure and cost-conscious.

Explain elasticity and the shared responsibility model

Cloud computing provides access to pooled compute, storage, networking, and managed services with on-demand provisioning. Elasticity refers to adjusting capacity as demand changes; scalability refers more broadly to supporting increased demand through appropriate architecture. Availability describes whether a service can be reached, while reliability includes the ability to behave correctly over time and recover after failure. A system can be elastic yet unreliable if state management or dependencies are weak. Learners should distinguish capital expenditure from consumption-based operating costs without assuming that consumption is always cheaper. Unused resources, data transfer, licensing, and continuously running workloads all affect the economic result.

The shared responsibility model changes according to the service layer. With infrastructure as a service, the customer typically administers the guest operating system and many workload controls. In a platform service, the provider manages more of the underlying environment, but application identity, access policies, and data still require customer decisions. A software-as-a-service tenant needs governance of users, content, configuration, and retention even though the vendor operates the application. Service selection should therefore begin with the team's capabilities and risk requirements. A company that cannot reliably patch operating systems may benefit from a managed platform, but only if the application's security and data requirements are compatible with it.

Choose compute services by operational ownership

Azure Virtual Machines give customers a familiar guest operating system and software installation model, with responsibility for patching, configuration, and application monitoring. Virtual machine scale sets can help operate groups of instances under defined scaling behavior. Azure App Service provides a managed environment for supported web workloads, reducing some host-management responsibilities. Azure Functions fits event-driven code with execution and scaling characteristics that differ from an always-on virtual machine. Containers package an application and dependencies, while managed orchestration such as Azure Kubernetes Service introduces a control plane and a different operational skill set. None of these offerings is universally better than the others.

Consider a small scheduling application that runs a short task whenever a file arrives. An event-driven function may offer a simpler fit than maintaining an idle server, provided time limits, triggers, and state handling suit the job. A heavily customized legacy application may require a virtual machine while it is being modernized. A web application with standard deployment needs might be a candidate for App Service. The correct comparison considers operational effort, scaling, connectivity, security, recovery, and costs, rather than selecting the newest or most technically sophisticated product. AZ-900 expects the learner to recognize these categories and their broad uses, not master complex deployment syntax.

Recognize storage choices and data durability

Azure storage services support different access patterns. Blob storage is suitable for object data such as images, backups, or large files accessed through APIs. Azure Files supports managed file-share patterns, while managed disks are attached to virtual machines. Queue and table storage address other application needs. Choosing among them depends on whether software expects a filesystem, an object API, structured records, or asynchronous messages. Access models also differ; it matters whether a client uses an identity-based mechanism, a scoped token, or a broad storage account key. Encryption alone does not provide appropriate authorization.

Durability and availability should be separated. Local redundancy, zone redundancy, and geo-replication place copies across different fault domains but offer different tradeoffs in price and recovery behavior. A second copy does not automatically provide a valid point-in-time backup after accidental deletion. Lifecycle policies can reduce costs for older data, though cool and archive tiers have access and retrieval implications. The Azure storage redundancy options provide deeper context for anyone moving from fundamentals toward hands-on administration. At the AZ-900 level, the goal is to make sensible distinctions among storage service types and redundancy goals.

Connect networking concepts to application access

An Azure virtual network supplies a logical networking boundary with address ranges and subnets. Network security groups can filter defined traffic, while public IP addresses and internet-facing services may expose workloads to external clients. Virtual network peering connects networks under particular routing and authorization conditions. Site-to-site VPN and ExpressRoute provide different approaches to hybrid connectivity, and Azure DNS supports public and private naming patterns. A private endpoint allows supported services to be reached through private network addressing, but DNS and access policies still determine whether clients can use it. Learners should avoid treating every networking feature as a firewall or assuming that resources in one subscription automatically communicate securely.

Application access makes these concepts concrete. A public marketing site may need HTTPS ingress and carefully bounded backend access, while an internal finance application may require private connectivity and stronger identity controls. A content distribution service addresses a different performance requirement from a regional load balancer. The most useful foundational skill is to describe which components are internet-facing, which are private, and where traffic crosses a trust boundary. This helps a learner interpret architecture diagrams and communicate with specialist network engineers even without configuring every routing detail.

Understand organizational scope and governance

Microsoft Entra ID provides identity services, whereas Azure management groups, subscriptions, and resource groups organize management and governance. Azure role-based access control assigns permissions at defined scopes, and role assignments can be inherited from a parent scope. Resource locks can reduce certain accidental changes but are not a complete security model. Tags help organize and report resources, yet they should not be relied upon as a security boundary. Azure Policy can audit or restrict configurations and guide remediation across eligible resource scopes. A fundamentals candidate should know why these controls exist and how they differ without needing to design an entire enterprise landing zone.

A common governance mistake is confusing organizational order with permission design. Putting two applications in separate resource groups does not by itself prevent a highly privileged user from accessing both. Conversely, assigning a restrictive policy at a parent scope can affect workloads in many child subscriptions. Governance begins with ownership: who may create resources, who bears cost, who approves sensitive changes, and who can investigate a policy exception. Azure governance becomes more intelligible when students understand these relationships before learning specific portal operations.

Interpret cost and service guarantees accurately

Azure pricing varies by resource size, location, consumption, reservation and commitment options, storage operations, data egress, and licensed features. A calculator estimates a planned deployment using assumptions; budgets and alerts help detect financial deviations once workloads run. Neither guarantees that a service will stop when a budget is exceeded. Cost analysis becomes more useful when resources have responsible owners and workloads are measured over a representative business cycle. Choosing an expensive redundancy tier without a documented recovery requirement may waste money, while selecting a minimal tier for a critical application may create unacceptable outage exposure.

Service-level agreements specify particular availability commitments under documented conditions and exclusions. An SLA does not mean that every dependent application will be available for the same percentage of time. Combining components can produce a different end-to-end outcome, especially when a single identity system or database remains a shared point of failure. Regions and availability zones address different geographical failure domains; compliance and residency requirements may constrain where data can be stored or processed. The fundamentals learner should recognize that technical architecture, commercial commitments, and business risk must be considered together rather than reduced to a single advertised percentage.

Use observability and practical examples to consolidate the basics

Azure Monitor, logs, metrics, and alerts help teams understand deployed resources. Microsoft Service Health describes relevant platform events, while Azure Advisor supplies recommendations in supported areas such as cost, reliability, performance, operations, and security. These services are not substitutes for application-level monitoring. If a VM is running but the website returns errors, infrastructure health alone may not identify the fault. Azure Monitor and Log Analytics add depth for learners who want to understand what happens after a resource is deployed and why telemetry matters.

For preparation, describe one small scenario from requirements to operations. A school needs a website, a document store, administrative access, predictable spending, and a recovery plan. Choose service categories, identify which data can be public, map management responsibilities, explain how a cost alert works, and describe what happens if one service becomes unavailable. The quality of the reasoning is more useful than memorizing disconnected product names. AZ-900 is a foundation for later technical roles, not a requirement to build an enterprise cloud platform independently. It succeeds as a learning goal when a candidate can explain Azure choices accurately to people with very different responsibilities.

A simple security example ties the service models together. Imagine a team moving an internal document portal from a self-managed Windows server to App Service and managed storage. Microsoft operates more of the hosting environment, but the team still decides who may sign in, whether files are exposed anonymously, how secrets are supplied, and what audit records are kept. Changing service models reduces selected maintenance tasks; it does not transfer responsibility for application data or user permissions. This distinction helps the AZ-900 candidate explain cloud security without making either extreme claim—that the customer manages everything or that the provider handles every risk.