Microsoft AZ-900: Where Your Azure Fundamentals Are Weak

On October 6, 2026, Microsoft AZ-900 remains current under Microsoft’s July 20 English blueprint. A readiness matrix for Azure Fundamentals should test conceptual comparison and clear explanation rather than administrator-level implementation. The current domains are cloud concepts, Azure architecture and services, and Azure management and governance.

Cloud models, benefits, and Azure scope

Readiness also includes being able to explain why a management or governance control belongs at one Azure scope rather than another. That scope decision is often more important than remembering the feature name.

Use the matrix to identify foundational dependencies. If shared responsibility is weak, IaaS/PaaS/SaaS questions will remain confusing. If Azure hierarchy is weak, governance scope and cost questions will suffer. If service categories are unclear, management-tool questions will feel like memorization. Mark those upstream concepts separately and fix them first because one foundational gap can create errors across several objectives. Use scope deliberately.

Readiness level 1: cloud models and responsibility

You can compare public, private, and hybrid cloud and explain how shared responsibility changes across IaaS, PaaS, and SaaS. Take one business workload and describe what the provider manages versus what the customer still owns under each service model.

If the answer is only definitions, the concept is not ready.

Readiness level 2: cloud benefits and economics

You can explain availability, scalability, elasticity, reliability, predictability, security, governance, manageability, CapEx/OpEx, and consumption-based pricing. For a seasonal workload, explain why elasticity and consumption pricing may matter and which risks or costs remain.

Readiness means the business consequence is clear.

Readiness level 3: Azure scope and architecture

You can explain regions, zones, resources, resource groups, subscriptions, management groups, and the purpose of Azure Resource Manager. Draw the hierarchy and attach one billing, governance, access, or resilience decision to the correct scope.

A scope diagram is stronger evidence than a memorized list.

When the matrix is complete, remove topics that are strong and stable from active review. Keep only weak comparisons, uncertain scope decisions, and objective areas supported only by recognition. A shrinking matrix is a good sign: it means final study is concentrating on evidence-backed gaps rather than repeatedly reviewing concepts you can already explain.

Add one matrix row for scope decisions. Given a policy, role assignment, budget, tag, or monitoring requirement, explain whether it belongs at management group, subscription, resource group, or resource level and why. Scope mistakes are common because Azure controls can be technically valid while applied at the wrong administrative boundary.

Core Azure service categories

For the AZ-900 readiness capstone, explain one small Azure environment from cloud model through resource hierarchy, service categories, identity, governance, cost, and monitoring. Then alter one business requirement—such as resiliency, ownership, or spending visibility—and identify only the concepts that should change. That exercise demonstrates fundamentals reasoning without drifting into administrator-level design.

Finish by explaining one small Azure environment from cloud model through resource hierarchy, service categories, identity, governance, cost, and monitoring. If that story is coherent without screenshots or acronyms as definitions, the fundamentals model is ready.

Readiness level 4: compute and networking purpose

You can compare VMs, containers, App Service, Functions, virtual networks, peering, VPN, ExpressRoute, DNS, and endpoints at a descriptive level. Given a simple application and connectivity requirement, identify which service category fits and what responsibility it changes.

Stay at fundamentals depth rather than designing the production network.

Keep implementation depth under control. Routing protocols, advanced KQL, custom RBAC, and enterprise landing-zone design may be valuable professional knowledge, but they should not crowd out the fundamentals the July 20 blueprint actually measures.

Readiness level 5: storage concepts

You can describe Azure storage categories, access tiers, redundancy options, migration concepts, and the relationship between durability, access frequency, and cost. Choose properties for an archive, shared file workload, and frequently accessed object data.

The deciding property should be explicit.

Identity, governance, cost, and management

Add one readiness row for cost and management decisions together. Given a small Azure workload, explain how pricing is estimated, how spending is tracked, which tags or scopes help allocate cost, and which monitoring or health service answers an operational question. The point is not to master billing administration; it is to prove that management, governance, and economics fit into the same fundamentals model.

Use comparison drills for the most easily confused concepts. Availability versus reliability, scalability versus elasticity, Advisor versus Service Health, Policy versus locks, public endpoint versus private connectivity, and authentication versus authorization are useful pairs. Write one scenario where selecting the wrong member of the pair produces a visibly different outcome. Contrast sharpens the conceptual boundaries AZ-900 expects.

Use contrast pairs for the areas that blur most easily: scalability versus elasticity, availability versus reliability, Policy versus locks, Advisor versus Service Health, and authentication versus authorization. One scenario where the distinction changes the answer is a better test than repeating two definitions.

Readiness level 6: identity and security basics

You can explain Microsoft Entra ID, authentication versus authorization, MFA, Conditional Access purpose, RBAC, Zero Trust, and Defender for Cloud at a conceptual level. Trace a user to a resource and identify where identity proof and permission are evaluated.

Do not turn AZ-900 into SC-300 or SC-500 preparation.

Readiness level 7: governance and cost controls

Governance readiness should connect business requirements to AZ-900 shared responsibility and governance: Policy, locks, tags, management groups, and Cost Management solve different organizational problems at different scopes.

Governance is ready when you can explain what behavior each control changes.

Readiness level 8: management and monitoring tools

You can distinguish portal, Cloud Shell, CLI, PowerShell, ARM templates, infrastructure as code, Azure Arc, Advisor, Service Health, Resource Health, and Azure Monitor by purpose. For a deployment need, service outage, recommendation, and application-health problem, select the tool category that answers the question.

Tool names should map to management intent.

Cost readiness should include the purpose of estimation and monitoring tools. The Pricing Calculator helps estimate expected cost before deployment, while Cost Management helps analyze and control actual spend afterward. You do not need billing-specialist depth, but you should know why those tools answer different questions.

Use one row in the matrix for management-tool purpose. The portal is interactive administration; Cloud Shell provides browser-based command-line access; CLI and PowerShell support scripting; ARM templates and infrastructure as code support repeatable deployment; Arc extends management to hybrid resources. The exam does not require deep command syntax, but the management model should be clear.

Add a final boundary check between service health and workload health. An Azure regional incident, one unhealthy resource, a slow application, and a best-practice recommendation require different signals. Knowing which tool answers which question prevents every operations scenario from collapsing into ‘use Azure Monitor.’

Final fundamentals explanation

Readiness is also stronger when you can say what AZ-900 does not prove. The certification does not demonstrate production administration, architecture design, network engineering, or security-operations expertise. Keeping that boundary clear prevents fundamentals confidence from turning into unsupported implementation claims.

Add a confidence-source column to the matrix. Production exposure, an independent lab, a scenario solved from first principles, documentation review, and simple recognition are not equivalent. Recognition should carry the least weight because familiarity with a term can hide a weak conceptual boundary.

Readiness level 9: score and explain Azure clearly without overclaiming

Use common AZ-900 preparation mistakes to detect over-studying or false confidence. Readiness at fundamentals level depends on clear conceptual boundaries, not implementation detail.

That is the appropriate readiness standard for a fundamentals exam.

Add a confidence-source column to the matrix. Mark whether each score comes from work experience, a small independent lab, a scenario solved from first principles, documentation review, or simple recognition. Recognition should receive the lowest weight. A fundamentals candidate does not need production-admin depth, but the important concepts should be explainable without prompts. This stops a high self-rating from being driven by familiarity with service names.

Keep implementation depth under control

If your notes include detailed routing protocols, complex role customizations, advanced KQL, or enterprise landing-zone architecture, ask whether that knowledge helps explain the current AZ-900 objective. It may be valuable learning, but it should not crowd out the basics. A readiness matrix is most useful when it shows whether the measured fundamentals are clear, not whether you have collected advanced Azure material.

For a final readiness check, tell the Azure story from the top: what cloud computing changes, how Azure organizes resources, how compute/network/storage categories differ, how identity and governance constrain use, how cost is managed, and how health is observed. If that explanation is coherent and maps back to the July 20 objectives, the platform model is likely ready for a fundamentals exam.

Keep a version date on the matrix. AZ-900 is current on the July 20 blueprint, so every readiness score should be interpreted against that version. If Microsoft publishes a later update, compare the change log and adjust only affected rows. A dated matrix is easier to maintain than a generic study sheet that silently mixes old and new objective wording.

Use the matrix as a decision tool, not a scorecard for confidence.