AZ-900: Understanding Azure Cloud Fundamentals

AZ-900, Microsoft Azure Fundamentals, is an active foundational exam for people who need to understand cloud computing and the architectural and governance concepts behind Azure. It does not expect the same hands-on deployment depth as a role-based administrator or network engineer exam. Its purpose is to distinguish core terms and recognize why one type of Azure service or control fits a business requirement. A project manager, developer, support engineer or new infrastructure administrator can use that knowledge to communicate more accurately with specialists.

Microsoft's July 20, 2026 guide covers cloud concepts, Azure architecture and services, and management and governance. A productive approach is to learn how responsibility, location, cost and risk change as an application moves from owned infrastructure to different cloud service models. Merely recognizing product icons is not enough to explain the consequences of a design decision.

Learn cloud service models through operational responsibility

Cloud computing provides access to computing resources through provider-managed infrastructure and metered services. The word cloud does not mean that every serverless or managed service has zero administrative responsibility. Organizations still own their data, access policies, application configuration and much of their security posture. Understand which layer the provider operates and which controls remain with the customer.

Infrastructure as a service provides configurable computing and networking primitives, such as virtual machines and virtual networks. It leaves organizations responsible for their guest operating systems and many operational controls. Platform as a service removes more platform maintenance work but can constrain low-level configuration choices. Software as a service exposes finished applications with an administrative and data-governance layer. These models are not mutually exclusive: a single business solution can use all three.

A practical comparison starts with a web application. On a VM, an engineering team patches the guest OS and web server. On a managed application platform, the provider handles more runtime infrastructure but the team still owns application code, identity, configuration and data protection. With an external SaaS product, the organization may configure user access, retention and business workflows rather than operating the application stack. The shared responsibility model for cloud security helps explain why outsourcing operations never removes all accountability.

The consumption model can reduce upfront hardware purchases while introducing variable charges and resource-sprawl risk. A deployed VM may incur cost even when it performs no useful work; storage and data transfer can continue costing money after an application stops. FinOps-style cost visibility and environment ownership are relevant fundamentals, not advanced details reserved for architects.

Understand regions, availability zones and organizing scopes

Azure organizes resources within a hierarchy of tenants, management groups, subscriptions and resource groups. Each level answers a different management question. A Microsoft Entra tenant anchors identity context, subscriptions provide billing and administrative boundaries, resource groups organize manageable collections of resources, and management groups allow governance across subscriptions. A resource group is not a physical datacenter and does not inherently isolate network traffic.

Regions represent geographic deployment locations. Availability zones provide separation of datacenter facilities within supported regions, enabling designs that withstand some localized infrastructure failures. Region pairs and regional availability characteristics help inform resilience, but not every service supports identical zone or failover behavior. Product availability and data residency requirements need checking for the actual target region.

Reliability is a system property. Putting a VM in an availability zone may protect it from certain facility failures, but an application that depends on one database and one fragile network component still has a single point of failure. Likewise, replicating data between regions has latency, consistency, cost and regulatory implications. Highly available Azure application design provides an example of thinking about dependencies instead of assuming a geographic checkbox solves recovery.

A useful exercise draws a basic organizational hierarchy: production and test subscriptions, resource groups for individual workloads and region choices for each data store. Ask which owner pays the bill, who may deploy resources, where logs are retained and where a failed workload can recover. That connects abstract hierarchy terms to real operations.

Distinguish compute, networking and storage options

Azure compute services range from virtual machines to managed applications, containers and event-driven functions. Choose based on control requirements, duration, scaling behavior and application packaging. A continuously running specialized service may be comfortable on a VM; an intermittently triggered workflow may benefit from event-driven execution. Serverless reduces infrastructure management but introduces its own execution limits and monitoring questions.

Virtual networks and subnets organize IP connectivity. Network security groups control selected network flows; VPN gateways and ExpressRoute can connect Azure with organizational networks. Load balancing distributes traffic according to different layers and scopes. Do not treat every connectivity feature as an interchangeable gateway or every private address as proof of security. For example, virtual network peering design illustrates why topology and routing are separate from application authorization.

Storage services address different access patterns. Azure Blob Storage suits object data, Azure Files offers managed file-sharing patterns, disks support VM block-storage needs and specialized data platforms handle structured or analytic data. Performance, availability, retention and access control are more useful selection criteria than the vague instruction to choose the cheapest storage. Azure Storage redundancy options show why replication choices cannot be collapsed into a single definition of backup.

A design may combine services: an application tier behind a managed gateway, a transactional database, blob storage for user uploads and a monitoring service. In AZ-900, the key question is what job each service performs and who remains responsible for protecting it, not the precise command needed to create every resource.

Recognize identity, security and governance controls

Microsoft Entra ID provides identity capabilities for users and workloads. Azure RBAC governs access to Azure resource operations at assigned scopes. A user allowed to sign in is not necessarily authorized to create a VM or read a storage object's data. The distinction prevents a common misunderstanding in which every authentication problem is blamed on a network rule and every authorization problem is blamed on a password.

Conditional Access, multifactor authentication, Microsoft Defender for Cloud, resource locks, Azure Policy and Key Vault address different concerns. MFA improves authentication assurance; policy can enforce or evaluate configurations; a resource lock limits certain management actions but is not a comprehensive protection against data-plane deletion or all administrative threats. Key Vault helps manage cryptographic material and secrets, yet access to the vault must itself be constrained.

Security posture management creates visibility into risks and deviations. A recommendation is not automatically an incident, and a configuration score is not proof an application is secure. Understanding this relationship prepares learners to work productively with engineers. Azure RBAC and permission scope is a strong supporting topic because Azure governance depends on who can perform which action against which resource.

Governance also includes tagging, organizational standards, compliance obligations and auditability. Tags can support owner and cost reporting, but they do not replace network segmentation. Azure Policy can limit prohibited resource configurations, while management groups make broad assignment possible. The choice between an audit effect and a deny effect affects rollout behavior and the cost of correcting noncompliance.

Understand visibility, costs and support before deploying

Azure Monitor and related services collect operational evidence: metrics indicate measured conditions, logs provide recorded events and alerts notify responders about selected patterns. A CPU metric does not necessarily describe a user's experience, and a log search is not an automatic recovery plan. Choose which signals matter for a workload and where administrators can find them during an incident.

Cost management begins with resource discovery and accountable ownership. Pricing calculators estimate planned resource use, while cost analysis helps examine actual spending. Budgets and alerts can flag unusual expense, but they do not automatically shut off every cost-producing resource. Resource tags and subscription boundaries support reporting only when deployed consistently. The discussion in cost-aware Azure architecture is relevant when learners need to see how design decisions affect costs over time.

Service-level agreements, service health information and support plans describe different concepts. An SLA is a contractual performance commitment for a defined service and configuration; it is not the same as an organization's end-to-end application availability. Azure Service Health concerns platform events and maintenance relevant to subscriptions, while a support plan defines available engagement options. Businesses must still have runbooks, owners and recovery procedures.

Review a hypothetical monthly invoice: idle VMs, storage tiers, outbound traffic, and a forgotten test environment. Decide which costs are genuinely required and which represent design or lifecycle problems. That exercise teaches the financial side of cloud adoption more effectively than memorizing a price list that can change by region and date.

Prepare for AZ-900 through decisions, not product memorization

A good AZ-900 study project follows one small business requirement through the Azure hierarchy. Describe whether cloud is appropriate, choose a service model, select a region, define identity and access, propose storage and compute, estimate cost, and state how operators would recognize an outage. Defend each choice in plain language. A foundational learner does not need to build an enterprise landing zone but should understand why such a platform exists.

Compare AZ-900 with AZ-104: the former checks broad knowledge while the latter assesses hands-on Azure administration and troubleshooting. An architect or DevOps engineer uses fundamentals but also needs much deeper skills in designing or operating solutions. AZ-900 is not a universal prerequisite for all role-based Microsoft certifications, and earning it does not independently demonstrate production-engineering ability.

Practice questions should explain the wrong alternatives. If a scenario asks for managed file sharing, identify why an object store or VM disk has different access semantics. If it asks for governance across subscriptions, explain why a management group is more relevant than an individual resource lock. If it mentions a shared responsibility model, identify the customer's continuing obligation even with a managed service.

The July 2026 objective structure should be the baseline for this article, but public cloud offerings evolve. At publication time, verify the current Microsoft Learn AZ-900 guide and avoid absolute claims about pricing, regional availability or product features. A learner who understands the service decision and its trade-offs will be better prepared than one who remembers only marketing labels.