Microsoft AZ-900 Study Plan: From Cloud Concepts to Governance
Microsoft AZ-900 is a fundamentals exam, but its breadth makes random memorization inefficient. A better preparation plan follows the structure of the current exam: begin with cloud concepts, connect those concepts to Azure architecture and service families, and finish by learning how Azure environments are managed, monitored, costed, and governed.
Microsoft’s current English AZ-900 blueprint is measured from July 20, 2026. Cloud concepts account for 25–30%, Azure architecture and services for 35–40%, and Azure management and governance for 30–35%. That balance makes the Microsoft AZ-900 exam a test of connected fundamentals rather than a catalog of product names.
The related Microsoft Azure Fundamentals certification is most useful when you can explain why a service or control exists, what problem it solves, and how it differs from neighboring concepts. The study plan below is built around that level of understanding.
Begin before Azure. Learn public, private, and hybrid cloud models; infrastructure, platform, and software service models; consumption-based pricing; scalability; elasticity; reliability; high availability; and disaster recovery. These concepts explain many of the choices that appear later in Azure-specific questions.
The shared responsibility model deserves particular attention because moving to the cloud never transfers every security and operational duty to Microsoft. With infrastructure as a service, customers still manage more of the operating system and application stack. With platform services, Microsoft operates more of the runtime and infrastructure. With software as a service, customers continue to own responsibilities around identities, data, configuration, and appropriate use.
Microsoft AZ-900 shared responsibility and governance turns that distinction into a practical exercise. For each service model, identify who controls the physical infrastructure, operating system, application, identity, and data. If you can explain why the boundary changes, you are learning the concept rather than memorizing a table.
Cloud economics should be approached the same way. Pay-as-you-go pricing can reduce large upfront infrastructure purchases, but cloud is not automatically cheaper. Cost depends on consumption, architecture, service choice, data movement, licensing, and governance. Learn the financial model without turning it into a slogan.
Next, understand how Azure is organized. Regions and availability zones describe physical deployment and resilience. Subscriptions, resource groups, and management groups define important administrative, billing, and governance boundaries.
A region is not the same thing as an availability zone. A subscription is not the same thing as a resource group. These distinctions are common exam material because several Azure objects sound like containers while serving different purposes.
Study them as scope decisions. If an organization must enforce a governance rule across many subscriptions, management-group scope may matter. If a team wants to organize one application’s resources, a resource group may be appropriate. If a question asks how to protect against a datacenter-location failure, availability-zone reasoning is more relevant than subscription design.
Draw the hierarchy once: management groups, subscriptions, resource groups, and resources. Put regions and zones beside the hierarchy rather than inside it. That small diagram makes both governance scope and geographic resilience easier to reason about.
For compute, focus on how much control the workload needs and how much infrastructure the team wants to manage. Virtual machines provide operating-system control but create patching and administration responsibilities. Managed application platforms reduce infrastructure work. Containers package applications and dependencies consistently. Serverless services support event-driven execution without requiring the team to manage servers directly.
Do not study these as a maturity ladder. A workload that requires operating-system customization can justify virtual machines. A new web application that should minimize platform administration may fit a managed application service. An event-driven task with irregular demand may fit serverless execution.
Use change-one-requirement drills. Start with a web application and choose an appropriate compute model. Then require full operating-system access. Then remove the operations team’s ability to patch servers. Then make the workload event driven. The answer should change for a reason you can explain.
Networking preparation should answer a simple question: what needs to communicate with what? Understand the purpose of virtual networks, subnets, peering, VPN connectivity, dedicated connectivity, DNS, load balancing, private access, and basic network-security controls.
When a scenario appears, trace the path. Is traffic staying inside one virtual network, crossing between Azure networks, arriving from the public internet, or connecting from an on-premises environment? Is the business concerned mainly with privacy, filtering, resilience, performance, or traffic distribution?
At AZ-900 depth, you do not need to design a complex enterprise network. You do need to know that a virtual network, a secure connection, a DNS service, a firewall, and a load balancer solve different parts of the problem. Keep hybrid connectivity separate from high availability and access control.
Storage becomes much easier when you classify the data before choosing a service. Is it unstructured object data, shared files, queued messages, or structured application data? Is it accessed constantly or rarely? Does the business need copies within one location, across zones, or across regions?
Azure data storage types differ because applications need different combinations of structure, durability, latency, accessibility, and cost. Blob storage is well suited to unstructured objects. Azure Files supports shared-file scenarios. Queues support asynchronous messaging. Database services address structured application needs.
Study access tiers and redundancy as business decisions. A colder tier makes sense only when infrequent access justifies the trade-off. A broader replication pattern makes sense only when the required failure scope warrants the extra cost or complexity.
Build one comparison table with columns for data shape, access pattern, management responsibility, resilience, and cost sensitivity. That is more useful than memorizing isolated service descriptions.
AZ-900 introduces Microsoft Entra ID, authentication, authorization, multifactor authentication, passwordless methods, Conditional Access, and role-based access control. The central distinction is simple: authentication proves identity; authorization determines what that identity may do.
Conditional Access evaluates sign-in context and can require controls before access is granted. Role-based access control grants permissions to Azure resources at a defined scope. Multifactor and passwordless methods strengthen authentication. These capabilities complement one another rather than replace one another.
For every identity concept in your notes, write the business problem it solves. User must prove identity more strongly, administrator needs only limited resource permissions, or risky sign-in should require an extra control are clearer study prompts than feature names alone.
Management and governance account for 30–35% of the current exam, so they deserve more than a final-day review. Learn the purpose of Azure Policy, resource locks, tags, Azure Resource Manager, infrastructure as code, Azure Arc, cost-management tools, Azure Advisor, Service Health, and Azure Monitor.
These tools differ by job and timing. Policy evaluates or enforces resource configurations. Locks prevent accidental deletion or modification. Tags add metadata. Pricing tools estimate costs before deployment, while Cost Management analyzes actual usage and spending. Service Health communicates platform issues. Azure Monitor provides operational telemetry.
Practice translating requirements into verbs: estimate, prevent, enforce, organize, monitor, recommend, deploy, or govern. The verb often reveals the service family that belongs in the answer.
Also understand governance scope. A policy applied to one resource is different from a rule inherited through a management group. Cost reporting by tag is different from billing separation by subscription. Fundamentals questions frequently hinge on those boundaries.
Create one small Azure environment rather than many disconnected labs. Use a resource group, virtual network, storage account, a simple compute or managed-app resource, tags, basic access control, and monitoring. The environment does not need to be production-grade; its purpose is to make responsibilities and scopes visible.
Turn the environment into a scenario engine. What changes if the workload needs another region? What if public access is prohibited? What if only one team may modify resources? What if the organization needs an allowed-region policy? What if a manager wants a cost estimate before deployment and an actual-spend report later?
For every change, identify whether the answer is architecture, identity, governance, cost, or monitoring. Then explain which existing parts stay the same. This builds the mental connections that a glossary cannot.
In the final stage, stop studying one domain at a time. Use mixed scenarios that force you to switch between cloud economics, service choice, identity, networking, storage, cost, and governance. Explain each answer using the requirement rather than the wording of a memorized definition.
Keep an error log with the distinction you missed. Did you confuse authentication with authorization? Policy with monitoring? Region with zone? Pricing estimation with actual cost analysis? Object storage with shared files? Those patterns tell you where another hour of study will help.
Review the current July 2026 blueprint before your appointment, then reduce your notes to a small set of decision rules. The final goal is not to know every Azure feature. It is to understand enough of the platform that a business requirement points naturally toward the right concept or service family.
If you can explain one small Azure environment from responsibility and geography through compute, networking, storage, identity, governance, cost, and monitoring, you have a stronger foundation than someone who can recite a long service list without connecting the pieces.
