Microsoft AZ-900 is an introductory certification examination about cloud concepts and the basic architecture, services and governance model of Azure. It does not demand the configuration depth expected on AZ-104 or the SC-500 cloud and AI security engineer assessment (successor to the retired AZ-500), but it can still be difficult for candidates new to cloud computing. The challenges come from understanding closely related concepts—such as elasticity versus scalability, resource groups versus subscriptions, and authentication versus authorization—well enough to choose correctly in a scenario rather than recognizing a memorized definition.
Candidates should first know which exam version they are studying. As of Microsoft’s July 20, 2026 skills-measured guide, AZ-900 has three weighted skills groups, not six separately weighted domains. The three official groups are cloud concepts (25–30%), Azure architecture and services (35–40%), and Azure management and governance (30–35%). Security, identity and cost management remain important, but they appear within those larger groups. Any preparation source presenting six current domains or an old fixed topic percentage table should be cross-checked with the official guide.
The current three-domain blueprint shapes preparation
The first group tests fundamental cloud ideas: the shared responsibility model; public, private and hybrid deployment; consumption-based pricing; serverless computing; service types such as infrastructure, platform and software as a service; and benefits such as high availability, reliability and elasticity. A common mistake is treating service models as a simple hierarchy in which one category is always better. The appropriate model depends on which operating responsibilities the customer must retain. A managed application service can remove some patching obligations while restricting low-level configuration choices.
The second group covers Azure’s regional and resource hierarchy, compute and networking options, storage, identity and security. The third group deals with cost tools, Azure Policy, resource locks, deployment and monitoring. These are official weighted groups, not a requirement to write answers about every service equally. The exam blueprint should guide the study plan, but hands-on exposure clarifies how a subscription, role assignment or policy behaves much faster than memorizing a list of portal menu names.
Cloud models and shared responsibility create frequent confusion
The public-cloud label says where a provider operates infrastructure; it does not mean that the customer has no security duties. In infrastructure as a service, the customer normally manages guest operating systems, applications and many configuration controls. With managed databases or software services, more operational duties shift to the provider, while the customer still needs to control identities, data classification and appropriate access. Shared responsibility therefore changes by service type, and an exam answer that assumes the same security boundary for all Azure services is usually flawed.
Elasticity is the ability to change resources with demand; scalability is the ability to handle increased workload, which may require scaling vertically or horizontally. High availability reduces service interruption under component failures; disaster recovery plans for restoration after wider disruption and can involve different recovery objectives. These pairs are related but not interchangeable. Concrete examples—such as a website handling a traffic spike, a database recovering after regional failure and a company managing compliance requirements—help candidates reason about which term is actually being tested.
Regions, zones, subscriptions and resource groups
Azure regions are locations where services run, while availability zones provide separate fault domains within supported regions. Some services are zonal, zone-redundant or regional, and not every SKU offers the same placement choices everywhere. A region pair can matter to a disaster recovery plan, but a region pair should not be mistaken for a promise that any workload has automatic cross-region failover. The reasoning behind regions and availability zones is especially useful because a service’s actual deployment settings determine resilience.
Management groups organize subscriptions, subscriptions form billing and administrative boundaries, resource groups collect related resources and individual resources hold service configurations. Role assignments and Azure Policy can apply at different scopes; inheritance matters. The scope hierarchy explains why an administrator with broad subscription access can affect many workloads and why governance decisions should be made before hundreds of unlabelled resources exist. A resource group is not itself a network security boundary, and a tag is metadata rather than permission enforcement.
Choose compute, networking and storage by requirement
Azure virtual machines offer OS-level control and require patching and capacity choices. Azure App Service supplies a managed hosting model for many web workloads. Containers and serverless functions solve different packaging and execution problems. Candidates should be comfortable recognizing the trade-off between explicit host control and managed platform behavior, not ranking compute products by prestige. Azure Functions has event-driven execution characteristics, but its pricing and scaling depend on the chosen plan.
Virtual networks define private addressing and subnet organization. Network security groups filter traffic at supported scopes, peering connects virtual networks, VPN Gateway supports encrypted connectivity and ExpressRoute offers private connectivity options. Public and private endpoints represent different exposure models. In storage, blob, file, queue and table offerings serve different workloads; redundancy choices affect durability and availability, while access tiers change the cost of retrieval and retention. Studying Azure compute choices can help connect product definitions with actual operating consequences.
Identity, authorization and zero trust are distinct concepts
Microsoft Entra ID provides cloud identity capabilities used by many Azure services. Authentication establishes the claimed identity; authorization determines the actions that identity is permitted to perform. An Azure RBAC assignment grants or denies permissions according to role and scope, but it does not replace the application’s own authorization checks. Conditional Access evaluates access policy using signals such as identity, device posture and risk where the necessary licenses and integrations exist. Zero trust asks administrators to verify access explicitly and restrict its scope instead of assuming that a corporate network location confers trust.
Encryption, firewalls, Defender for Cloud and identity policies defend different layers. An encrypted storage account can still expose information to an overly privileged principal; a well-scoped role can still be used through a stolen token. A strong candidate identifies the control relevant to the question and the boundary it enforces. Azure security is not one magic toggle, and AZ-900 mainly expects broad recognition and clear distinctions rather than the complete deployment syntax used on specialist certifications.
Management tools, policy, monitoring and costs
The Azure portal is a graphical administration surface; Azure CLI and PowerShell allow repeatable operations and scripting; Azure Resource Manager deployments represent a declarative provisioning model. Infrastructure as code can keep resources reproducible, but successful execution is not enough: policy, identities and monitoring must also confirm that the deployed state meets expectations. Azure Policy governs allowed or audited resource configuration, while resource locks protect against certain accidental management changes. A lock does not substitute for backups or security authorization.
Budget alerts, cost analysis, tags and the pricing calculator solve related but different finance tasks. Pricing estimates depend on location, service tier, usage and data transfer; tags help attribute cost to owners or projects; budgets notify but do not ordinarily prevent all spending. Azure Monitor, Log Analytics and Application Insights expose different telemetry. A practical example can start with one small service, tag it, set a budget, review metrics and then delete test resources responsibly. Azure cost management is easier to understand when the user can trace a real resource to consumption and a responsible owner.
Exam difficulty depends on starting knowledge
For a systems administrator already familiar with virtual machines, identity and networking, the hardest AZ-900 questions may involve Azure terminology or service boundaries rather than new technology concepts. A beginner without an IT background may need more time to understand networking, storage and the difference between computing models before Azure-specific names make sense. Neither group should assume AZ-900 is a mere vocabulary quiz. Cloud design choices contain trade-offs that the exam can describe in realistic business cases even when the exam remains foundational.
Microsoft’s official exam page lists a scaled passing score of 700, but candidates should not confuse the scaled score with 70 percent of questions. Item weights, delivery rules, scheduling costs, language availability and retake policies can change. A sensible preparation strategy is to use current Microsoft Learn modules, verify the skills outline, complete a few controlled labs and use representative practice assessments only to identify weaknesses. Exact exam-day details should be confirmed in the booking portal instead of copied from an old screenshot or article.
A practical study plan with verifiable skills
Start by classifying each topic from the current three official domains as known, partially known or unfamiliar. Learn the definitions, then use a concrete service or resource example to test each distinction. Create an Azure resource group, examine regional availability, compare one VM with a managed service, inspect a role assignment and observe a cost estimate before deploying anything expensive. Where access to a live Azure account is unavailable, use documented examples and Microsoft’s training sandbox; do not invent access to subscription features or paid services.
After two or three topic blocks, complete mixed practice questions without notes and record why a wrong option was tempting. A frequent issue is confusing similar service names; another is knowing a product definition but forgetting the administrative scope. Review that reasoning error against the official documentation, not an unexplained answer key. The objective is to understand which Azure component or management control meets the stated need. That produces a stronger AZ-900 result and a more reliable basis for subsequent hands-on Azure work.
