Microsoft AZ-900: Learn Azure by Doing

Microsoft AZ-900 is a fundamentals exam, but hands-on practice still improves understanding. The purpose of a lab is not to become an Azure administrator; it is to make cloud concepts, service purposes, scope, cost, governance, and monitoring concrete enough that you can explain them without relying on memorized definitions.

AZ-900 is current on October 6, 2026 under Microsoft’s July 20 English blueprint. The exercises below deliberately stay at fundamentals depth.

Make cloud models and Azure scope concrete

Keep the labs intentionally small. A free or low-cost sandbox resource, diagram, calculator exercise, or guided portal exploration is enough to make concepts concrete. The purpose is to see how subscription scope, resource groups, regions, tags, locks, monitoring, or service categories appear in Azure—not to build a production environment. Delete resources when finished and keep cost awareness part of the exercise, because consumption-based pricing is itself an AZ-900 concept.

Clean up the lab resources when finished.

Keep labs intentionally small. A sandbox resource, architecture diagram, pricing estimate, or portal observation is enough when the goal is conceptual understanding. Delete resources afterward and record what the exercise demonstrated so hands-on work does not inflate the claimed skill level.

Exercise 1: compare cloud service models

AZ-900 cloud concepts are best practiced by comparing IaaS, PaaS, and SaaS for the same simple business application. Record what Microsoft manages, what the customer still manages, how scaling changes, and how the consumption model differs.

Write what the provider manages, what the customer manages, how scaling works, and how pricing behavior changes. The exercise should make shared responsibility visible rather than turn into a deployment lab.

Exercise 2: map Azure scope

Sketch a tenant, management groups, subscriptions, resource groups, and resources for a small organization.

Assign one governance, billing, or access responsibility at each level and explain why the scope is appropriate. The outcome is a scope model you can reason about when a question mentions policy or cost.

Close the lab by checking that no unnecessary Azure resources remain running.

Compare core Azure service categories

For monitoring practice, create a small question set around “who knows what?” Service Health tells you about Azure service issues affecting your environment; Azure Monitor collects and analyzes telemetry; Advisor provides recommendations; Resource Health focuses on resource availability; Application Insights helps observe application behavior. Knowing which question each tool answers is more durable than memorizing where its blade appears in the portal.

Exercise 3: compare compute choices

Create a simple table for virtual machines, containers, App Service, and Functions using control, operating responsibility, scaling, and workload fit.

Choose a basic web application and explain how the customer’s responsibilities change across the options. Do not configure every service; focus on the abstraction tradeoff.

Exercise 4: trace a network path

Draw a user reaching an Azure application and a branch office reaching an Azure virtual network.

Add DNS, public or private connectivity, VPN or ExpressRoute concepts, and a simple security boundary. The goal is to understand connectivity purpose, not design an enterprise network.

After each lab, write a “what this does not prove” note. Creating a virtual network does not make you a network engineer; applying a tag does not demonstrate enterprise cost governance; viewing Azure Monitor does not prove operational observability design. This habit keeps the certification level honest while still using hands-on work to strengthen foundational understanding.

Use diagrams as practical exercises when creating real resources would add little. Draw a region with availability zones, a virtual network with subnets, a public and private access path, or a management-group hierarchy. Label the purpose of each component and the responsibility boundary. A clear diagram can demonstrate fundamentals understanding more directly than clicking through a deployment wizard whose implementation details are beyond the exam’s scope.

Exercise 5: choose storage properties

Compare hot versus archive access, local versus regional redundancy, object versus file storage, and migration options for three simple datasets.

Explain which property—cost, durability, access frequency, compatibility, or migration need—drives each choice. Fundamentals readiness is recognizing the deciding property. Verify cleanup and costs.

Practice governance and management tools

Add a simple cost exercise to the capstone. Estimate one service with Azure Pricing Calculator, apply tags that identify owner and environment, and describe how Cost Management would help track spend over time. The exact price is less important than understanding that configuration, region, scale, service tier, and usage shape cloud cost. Then explain which cost responsibility remains with the customer under the selected service model.

For cost practice, change one variable at a time. Compare a larger compute size, a different storage tier, additional regional redundancy, or a longer running time and predict which part of the cost model changes. You do not need to memorize prices, which are variable. You need to understand that cloud cost follows consumption and design choices and that Azure provides tools to estimate, monitor, allocate, and optimize that spend.

Exercise 6: apply governance to a small environment

Governance exercises should begin with business rules such as approved regions, required ownership tags, deletion protection, and cost visibility. AZ-900 shared responsibility and governance helps map those rules to Policy, tags, locks, Cost Management, and the correct administrative scope.

Map each requirement to Policy, tags, locks, Cost Management, or management-group scope as appropriate. This turns governance terminology into business controls.

Exercise 7: compare management interfaces

Perform or simulate one simple resource-management task through the portal and describe how CLI, PowerShell, Cloud Shell, ARM templates, and infrastructure as code would approach the same need.

Identify which tools are interactive, scripted, or declarative. The exercise is about management models, not memorizing commands.

Connect monitoring to a complete fundamentals scenario

As a final practical check, explain the fictional Azure environment to another person from responsibility to scope to service purpose to governance and monitoring. If they can follow the story without seeing the portal, the exercises have reinforced concepts rather than interface memory.

Use one fictional small company as a capstone. Choose a cloud model, place resources, connect users, select storage properties, apply governance and cost controls, and decide which health signals matter. The exercise should explain why each concept exists without becoming a production architecture project.

Include one service-health event and one workload-performance issue so the lab proves that Azure platform status and application telemetry answer different operational questions.

Explain which signal belongs to Azure and which belongs to the workload.

Add one management-tool comparison to the capstone. Let Azure Service Health report a regional platform issue, Resource Health show the state of a specific resource, Azure Monitor surface workload telemetry, and Advisor recommend an improvement. Explaining why those four signals are not interchangeable reinforces the management-and-governance part of AZ-900 without drifting into administrator-level configuration.

The exercise should end with a plain-language explanation of which Azure signal would be checked first for each kind of problem.

Exercise 8: read health and monitoring signals

Compare Azure Advisor, Service Health, Resource Health, Azure Monitor, Log Analytics, alerts, and Application Insights by the question each answers.

Given a slow application and a regional Azure incident, decide which signal helps diagnose each situation. Separating platform health from workload monitoring is the key learning outcome.

Exercise 9: explain Azure through an integrated fundamentals scenario

The capstone should still stay at fundamentals depth

Microsoft Certified: Azure Fundamentals should be demonstrated through clear explanations of cloud models, Azure scope, service purpose, governance, cost, and monitoring—not through specialist implementation detail.

If you cannot explain why a control or service exists without repeating Microsoft terminology, return to the underlying business need. That final exercise checks understanding rather than recall.

One useful capstone is to design a fictional small company moving one application to Azure. Decide which responsibilities remain with the company, where resources live, which compute abstraction fits, how users connect, what storage properties matter, how cost is tracked, which governance rules are needed, and how health is monitored. Keep every choice at conceptual depth and explain it in plain language. That single scenario can reinforce all three AZ-900 domains.

Finish by reviewing resource cleanup and lifecycle. Deleting a lab resource shows that cloud consumption ends when resources are removed and reinforces the difference between temporary experimentation and long-running production services. Record what you created, where it lived, which scope governed it, what cost or monitoring signal appeared, and whether any dependent resource remained. This small habit connects fundamentals learning to responsible cloud use.

Keep an evidence note for each AZ-900 exercise: what concept the exercise was meant to demonstrate, what Azure object or tool you observed, what responsibility remained with the customer, and what the exercise did not prove. That small record prevents hands-on work from becoming a collection of screenshots and makes it easier to connect practical observations back to the fundamentals blueprint during final review.

Add a simple cost and ownership dimension to the fictional company. Estimate one resource, tag it with an owner and environment, explain how a budget would surface spending risk, and state which responsibilities still belong to the customer under the chosen service model. That keeps economics connected to the same fundamentals story.