Microsoft AZ-900 Azure Fundamentals Practical Preparation: Scenarios, Exercises, and Skills to Rehearse

 

AZ-900 is designed to validate foundational understanding, not day-to-day Azure administration. That distinction should shape practical preparation. A candidate does not need to become a production cloud engineer before sitting the exam, but passive reading is still a weak way to learn relationships among cloud models, Azure architecture, storage, identity, governance, cost, deployment, and monitoring. The most effective exercises make concepts visible: draw boundaries, compare options, inspect a small Azure environment, predict what a control will do, and explain why one service fits a scenario better than another.

The current Microsoft blueprint, with skills measured as of July 20, 2026, allocates 25–30 percent to cloud concepts, 35–40 percent to Azure architecture and services, and 30–35 percent to Azure management and governance. Practical work should therefore cover all three domains. It should also stay at the right depth. You are rehearsing decisions and mental models, not memorizing commands that belong in a role-based administrator exam. The exercises below are deliberately small, repeatable, and tied to exam reasoning.

Start with a diagnostic before you build anything

Before opening a portal or terminal, write down ten statements you believe you can explain: public versus private versus hybrid cloud, IaaS versus PaaS versus SaaS, regions versus availability zones, subscriptions versus resource groups, virtual machines versus containers versus functions, VPN Gateway versus ExpressRoute, Blob Storage versus Azure Files, authentication versus authorization, Azure Policy versus resource locks, and Advisor versus Service Health versus Azure Monitor.

Give yourself one minute per comparison. For each, state what problem each option solves, what makes the options different, and one scenario that would change your choice. Any comparison that becomes fuzzy should be tagged for deliberate practice. This keeps hands-on time from turning into random exploration.

The AZ-900 readiness matrix is useful for this diagnostic because it converts the blueprint into evidence-based rows. Use practical work to repair yellow and red rows rather than trying to touch every Azure feature.

Exercise 1: model the cloud without using Azure product names

Create three short business cases. The first is a startup that wants to launch quickly and avoid owning datacenter infrastructure. The second is a regulated organization that must keep a specific legacy workload on dedicated infrastructure but wants public-cloud analytics for new projects. The third is an enterprise modernizing gradually while retaining some systems on premises. For each case, choose public, private, or hybrid cloud and defend the choice.

Then repeat the exercise for service models. Take a custom legacy application that needs operating-system control, a new web application where developers want the platform to handle operating-system maintenance, and a business team that needs an email or collaboration application. Map them to IaaS, PaaS, and SaaS respectively, then identify what the provider manages and what the customer still owns. The goal is not to memorize a responsibility table. It is to learn how abstraction shifts operational responsibility.

Finish by adding a serverless variation. Imagine a small piece of code that runs only when an event occurs. Explain why a serverless platform can be attractive for bursty execution and why “serverless” does not mean physical servers disappear. That explanation is a strong check that you understand the model rather than the label.

Exercise 2: draw shared responsibility as a sliding boundary

On paper, create rows for physical facilities, physical network, physical hosts, operating system, runtime or middleware, application, identity, and data. Draw four columns: on premises, IaaS, PaaS, and SaaS. Mark which party primarily manages each layer, then challenge your own diagram with a security incident.

For example, a SaaS customer grants a former employee excessive permissions. Who is responsible for correcting the access assignment? A PaaS customer writes insecure application code. Who owns the application logic? An IaaS customer neglects operating-system patching. Who owns that layer? These scenarios teach a crucial rule: moving to a more managed service changes responsibilities, but the customer never becomes responsibility-free.

A good second pass separates provider responsibility from customer accountability. The provider may operate the physical infrastructure, but the customer still decides how identities are assigned, how data is classified, and how applications are configured. If your answers become “Microsoft handles security because it is Azure,” repeat the exercise until the boundary is clear.

Exercise 3: build an Azure scope map

You can learn management groups, subscriptions, resource groups, and resources without creating an elaborate environment. Draw a fictional organization with two business units, each with production and nonproduction subscriptions. Add management groups above the subscriptions, resource groups inside each subscription, and representative resources inside the groups.

Now apply four requirements: a policy must affect all production subscriptions; a team should receive access only to one application’s resources; finance needs separate billing visibility for a subscription; and a set of resources should be managed together through a common lifecycle. Decide where each control belongs. The exact organization design can vary, but the reasoning should respect scope and inheritance.

If you have access to an Azure environment, inspect the portal hierarchy and compare it with your drawing. Do not create resources merely to click through screens. The value is recognizing that a resource belongs to one resource group, resource groups sit within subscriptions, and management groups organize subscriptions for governance at scale.

Exercise 4: compare regions, availability zones, and multi-region design

Take a simple web application and write three failure events: one server fails, one datacenter location within a region becomes unavailable, and an entire region becomes unavailable. For each event, identify what architecture concept addresses the failure boundary.

A single redundant virtual machine configuration can address host-level risk, depending on design. Availability zones are relevant when you want physically separate locations within a region. A cross-region strategy addresses a larger geographic failure domain. The point is not to design a production disaster-recovery solution. It is to stop treating “region,” “zone,” and “datacenter” as interchangeable terms.

Add one governance twist: the organization must use a sovereign cloud environment because of jurisdictional or operational requirements. That requirement is different from high availability. This helps separate geographic resilience from sovereign-region concepts.

Exercise 5: choose compute by control, packaging, and execution pattern

Create a four-column card for virtual machines, containers, web apps, and functions. Under each, write the level of operating-system control, deployment unit, operational overhead, and common workload shape.

Then classify scenarios. A vendor application requires access to a specific operating system configuration: a virtual machine may be appropriate. A team packages an application with its dependencies and wants a portable runtime: containers may fit. A conventional web application should run on a managed platform without the team managing servers: a web app can fit. Small event-driven code should run in response to triggers and scale with demand: functions can fit.

Include Azure Virtual Machine Scale Sets, availability sets, and Azure Virtual Desktop in the exercise as concepts rather than configuration labs. Explain that scale sets help manage groups of VMs with scaling, availability sets distribute VMs across fault and update domains within a datacenter-based design, and Azure Virtual Desktop provides virtualized desktops and applications. Your objective is to recognize why each exists.

Exercise 6: draw network paths instead of memorizing names

Networking becomes easier when every feature is attached to a traffic path. Draw two virtual networks, each with subnets. Connect them using peering. Add an on-premises office and draw one path through VPN Gateway and another conceptual path through ExpressRoute. Label the difference: VPN connectivity can use encrypted tunnels across the public internet, while ExpressRoute provides private connectivity through a connectivity provider.

Now add a platform service with both a public endpoint and a private endpoint. Explain how a private endpoint gives the service a private IP presence in a virtual network so traffic can follow a private path. This is enough for AZ-900; you do not need to master route tables or enterprise network design.

Finally, add Azure DNS as the name-resolution component. Ask what each networking feature changes: address space, segmentation, connectivity between networks, connectivity from on premises, or name resolution. If a feature cannot be placed on the diagram with a clear purpose, revisit it.

Exercise 7: make three storage decisions separately

For each sample workload, make three decisions: storage service, access tier, and redundancy concern. Do not allow one decision to substitute for the others.

Scenario one is a collection of images and backup objects. Blob Storage is a natural fit. Scenario two is shared file access using familiar file semantics. Azure Files is relevant. Scenario three is a very large data-transfer requirement where network transfer is impractical; Azure Data Box may be relevant for migration. Scenario four requires synchronizing an on-premises Windows file server with Azure Files; Azure File Sync is relevant. Scenario five requires a command-line copy operation; AzCopy may be relevant, while Azure Storage Explorer provides a graphical management experience.

Then discuss access frequency. Hotter data justifies a tier optimized for frequent access; cooler or archival data can trade retrieval characteristics for lower storage cost. Separately, discuss redundancy. Local redundancy and geographically distributed approaches solve durability and availability concerns at different scopes. You do not need to memorize every acronym in isolation if you understand what the redundancy choice is trying to protect against.

Exercise 8: separate identity, authentication, authorization, and access policy

Create one user scenario and force four different questions. First: where does the identity exist? Microsoft Entra ID is the cloud identity and directory service. Second: how does the user prove identity? Authentication methods can include passwords, MFA, passwordless methods, and SSO experiences. Third: under what conditions should sign-in be allowed? Conditional Access can evaluate signals and enforce access requirements. Fourth: what can the identity do to Azure resources after access is granted? Azure RBAC controls authorization through role assignments at scopes.

Now add an external partner. Explain how external identities support collaboration outside the organization. Add a legacy application that expects traditional domain capabilities and discuss Microsoft Entra Domain Services at a fundamentals level. Finally, map the scenario to Zero Trust: verify explicitly, use least privilege, and assume breach.

This exercise is valuable because many weak candidates answer every identity question with “Entra ID.” The exam expects you to distinguish the directory from authentication methods, policy decisions, and resource authorization.

Exercise 9: compare tags, Azure Policy, resource locks, and Purview

Create four requirements and assign one primary tool to each. “Classify resources by cost center” suggests tags. “Audit or enforce an organizational configuration requirement” suggests Azure Policy. “Prevent accidental deletion of a critical resource” suggests a resource lock. “Discover, understand, and govern data across an estate” points toward Microsoft Purview.

Then add a deliberately ambiguous requirement: “Improve governance.” That sentence is too broad to select a tool. Rewrite it into a specific outcome. The habit of translating vague language into an enforceable or observable requirement is exactly what prevents mistakes on scenario questions.

If you can access Azure, inspect where tags, Policy, and locks appear in the portal. You do not need to build a complex policy initiative. Seeing that they are separate controls with different scope and behavior is enough to strengthen the conceptual distinction.

Exercise 10: rehearse cost reasoning without memorizing prices

Pick a hypothetical workload and list its cost drivers: compute size and runtime, storage amount and tier, region, outbound data transfer, redundancy, licensing, and any commitment or reservation model that could change effective pricing. Then explain what the Azure pricing calculator is for: estimating expected costs before deployment based on selected services and assumptions.

Next, imagine that the environment is already running. Cost management capabilities help analyze spending, set budgets, detect trends, and allocate costs. Tags can improve allocation when they are applied consistently. None of these controls means cloud spending is automatically low. Cost management is an operational discipline built on visibility, ownership, and resource decisions.

The exercise should end with one sentence: “Consumption pricing makes cost responsive to usage, but poor resource choices can still waste money.” If that sentence makes intuitive sense, your cloud economics model is on the right track.

Exercise 11: compare management and deployment interfaces

Choose one fictional task such as creating or inspecting a resource. Explain how the Azure portal provides a graphical interface, how Azure Cloud Shell provides a browser-accessible shell, and how Azure CLI and Azure PowerShell support command-line management and automation. The exam is not asking you to memorize command syntax. It is asking whether you understand that several interfaces can operate against the same Azure control plane.

Then introduce infrastructure as code. Instead of repeatedly clicking through a portal, the desired infrastructure is described in a repeatable definition. Azure Resource Manager is the deployment and management service for Azure resources, and ARM templates are a declarative way to define those resources. Azure Arc extends Azure management and governance approaches to resources outside Azure.

A useful proof task is to explain which concept addresses repeatability, which interface is graphical, which tools are command-line oriented, and which service helps bring non-Azure resources under Azure management. If you can answer those four questions, the cluster is probably ready.

Exercise 12: triage with Advisor, Service Health, and Azure Monitor

Create three incident cards. Card one says, “A Microsoft platform incident is affecting services in the region where my resources run.” Card two says, “I want recommendations that may improve cost, reliability, security, or performance.” Card three says, “I need metrics, logs, application telemetry, and alerts when a threshold is crossed.”

Match them to Service Health, Advisor, and Azure Monitor respectively. Then expand the third card: Log Analytics helps query and analyze log data; Azure Monitor alerts can notify or trigger actions based on conditions; Application Insights focuses on application performance and telemetry scenarios. You should be able to place these under the Azure Monitor umbrella without confusing them with platform-health notifications.

Repeat the exercise until the words “incident,” “recommendation,” and “telemetry” immediately suggest different tools. This comparison is small but high value because the services frequently appear together in fundamentals preparation.

Exercise 13: connect practical work back to cloud concepts

Hands-on work becomes misleading if it makes Azure look like a collection of screens. After every exercise, ask what cloud concept the activity demonstrates. Creating a scalable compute design connects to scalability. Choosing a managed service connects to shared responsibility and PaaS. Applying Policy connects to governance. Using a private endpoint connects to network isolation and security. Monitoring a workload connects to manageability and reliability.

If the conceptual relationship is unclear, review the AZ-900 cloud concepts guide before doing more portal work. The goal is to make product behavior reinforce a cloud principle, not to collect screenshots.

Build a scenario notebook instead of a command notebook

For AZ-900, a scenario notebook is more useful than pages of commands. Use one page per concept pair. At the top, write the decision: “VPN Gateway or ExpressRoute?” Under it, write the distinguishing requirement, one example that fits each, and one tempting wrong answer. Repeat for RBAC versus Conditional Access, tags versus Policy, availability zones versus regions, and Advisor versus Service Health versus Monitor.

Add a short “because” sentence to every answer. “Use ExpressRoute because the requirement is private connectivity through a connectivity provider rather than an encrypted tunnel over the public internet.” “Use RBAC because the requirement is authorization to Azure resources, not a sign-in condition.” Explanations expose weak reasoning faster than answer keys do.

Use practice questions as experiments, not scoreboards

A practice question is useful when it reveals what your mental model does under unfamiliar wording. After each set, classify misses into four categories: missing concept, confused comparison, scenario-reading error, or careless execution. The repair should match the error. Missing concept requires learning. Confused comparison requires a side-by-side distinction. Scenario-reading errors require identifying requirement words. Careless execution requires slower reading and a deliberate final check.

Avoid repeatedly answering the same set until the score looks good. That can turn recognition into an illusion of mastery. Rotate scenarios, rewrite questions in your own words, and explain why each distractor is wrong. If you cannot explain the distractors, the concept is probably not stable yet.

A practical final-week sequence

Seven days before the exam, freeze new resource collection. Use the first two days to repair red topics from your readiness matrix. Use the next two days for mixed scenario exercises across architecture, services, identity, governance, and monitoring. Use day five for a timed practice set and a detailed error review. Use day six for targeted repair only. Use the final day for a light conceptual pass, exam logistics, and rest rather than an all-night cram.

The sequence can be shorter or longer depending on your background, but preserve the order: diagnose, rehearse, test, repair. Practical preparation is effective because it makes abstractions concrete. It stops being effective when it becomes aimless resource creation or command memorization.

AZ-900 rewards candidates who can look at a simple requirement and choose the right cloud concept or Azure capability at the right level. Rehearse that decision repeatedly. Draw the architecture. Classify the service model. Follow the network path. Separate identity from authorization. Match governance controls to outcomes. Match monitoring tools to signals. If you can perform those small exercises without notes and explain the tradeoffs, your practical preparation is doing the job it should.

Exercise 14: rehearse availability, scalability, reliability, and predictability as separate goals

These four benefits are easy to blur because they can appear in one architecture. Give each one a distinct operational question. Availability asks whether users can still reach the service when a component fails. Scalability asks whether capacity can grow or shrink to handle workload. Reliability asks whether the system can recover from failures and continue producing correct outcomes. Predictability asks whether performance or spending can be understood and managed within expected ranges.

Build a scenario around an online enrollment service. During registration week, demand grows by a factor of ten. That is primarily a scalability problem. A single datacenter location fails, but the service should remain reachable. That is an availability design problem. A background process must resume correctly after an infrastructure failure without losing data. That is a reliability concern. Finance wants a stable forecast and guardrails around variable usage. That is a predictability and cost-management concern.

Now force yourself to name one Azure concept that could support each goal without claiming the concept guarantees the outcome. Scale sets or managed scaling options can support scalability. Availability zones can support availability against a datacenter-level fault. Redundant storage and resilient application design support reliability. Budgets, cost analysis, sizing, and suitable pricing models support cost predictability. The wording “support” matters because architecture still has to be designed correctly.

Exercise 15: compare storage redundancy through failure questions

Instead of memorizing redundancy acronyms, ask what failure you are trying to survive and where additional copies exist. Start with locally redundant storage as the simplest model: copies remain within a primary region at a local scope. Then consider zone-redundant storage, which distributes copies across availability zones in a region. Geo-redundant approaches replicate to a secondary region, and geo-zone-redundant approaches combine zonal resilience in the primary region with geographic replication.

You do not need to become a storage architect for AZ-900. You do need to understand that higher geographic separation addresses broader failure domains and can affect cost and access characteristics. Write four cards with failures: disk or rack failure, datacenter-zone failure, regional disaster, and requirement for read access from a secondary region. Match the cards to the conceptual redundancy options, then confirm the exact names in the current Azure documentation during study.

The lesson is broader than storage. Azure designs expose choices because different resilience requirements have different costs and tradeoffs. When an exam question mentions durability, zone failure, or regional failure, read the scope of the failure before jumping to an acronym.

Exercise 16: practice least privilege with RBAC scopes

Create a small hierarchy on paper: one subscription with two resource groups, “Finance-App” and “Marketing-App.” Add one virtual machine and one storage account to each group. Now create three users. User A should only view resources across the subscription. User B should manage resources in Finance-App but have no administrative rights over Marketing-App. User C should manage one storage account but nothing else.

Without memorizing every built-in role, decide the appropriate scope for each assignment. The lesson is that Azure RBAC combines a security principal, a role definition, and a scope. Broad scope gives the role broader reach; narrow scope limits reach. Inheritance means an assignment at a higher scope affects child scopes unless another design choice changes effective access.

Then add Conditional Access to the scenario. Suppose User B can manage Finance-App only after successful sign-in from an approved context with MFA. Conditional Access governs sign-in and access conditions; RBAC governs what the authenticated identity can do to Azure resources. Putting both controls in one scenario is one of the fastest ways to stop confusing them.

Exercise 17: convert governance requirements into testable statements

Write five vague executive statements: “keep Azure secure,” “control costs,” “follow standards,” “protect critical resources,” and “organize everything.” For each, turn the statement into a measurable requirement. “Follow standards” might become “resources in production must use approved regions.” That can be evaluated with Azure Policy. “Protect critical resources” might become “a database resource must not be accidentally deleted.” A resource lock can help. “Organize everything” might become “every resource must carry cost-center and owner metadata.” Tags provide the metadata, while Policy can help require them.

This exercise teaches you not to choose tools from adjectives. “Secure,” “governed,” and “managed” are not sufficient requirements. Certification questions usually contain a more precise operational clue. Extract that clue first, then choose the tool.

Extend the exercise to Microsoft Purview. A requirement such as “discover where sensitive enterprise data exists and improve data governance across sources” is fundamentally different from “enforce an allowed Azure region.” Purview and Azure Policy both participate in governance discussions, but they operate on different governance problems.

Exercise 18: rehearse migration and file-movement tools by constraint

Create a decision table with AzCopy, Azure Storage Explorer, Azure File Sync, Azure Migrate, and Azure Data Box. For each, write the constraint that makes it relevant. AzCopy is a command-line utility for copying data to or from Azure Storage. Storage Explorer provides a graphical experience for working with storage. Azure File Sync extends Azure Files to help synchronize file-server content. Azure Migrate helps assess and migrate workloads to Azure. Azure Data Box addresses large offline data-transfer scenarios where shipping a physical appliance can be more practical than moving everything across the network.

Now hide the tool names and read only the constraints. “I need a GUI to inspect and move storage objects.” “I need to synchronize a Windows file server with Azure Files.” “I need to assess servers for migration.” “I need to move tens or hundreds of terabytes where network transfer is impractical.” If the tool names come back naturally, you are learning by requirement rather than by flashcard.

This method also protects against overgeneralization. Azure Data Box is not the answer to every migration question, and Azure Migrate is not a file-copy utility. Fundamentals questions often reward a candidate who recognizes the category of problem before the product name.

Capstone scenario: design the concepts for a small hybrid business

Finish practical preparation with one capstone that touches all three domains. Imagine a regional manufacturer with a headquarters datacenter, two branch offices, a customer portal, file servers, and a small analytics team. The company wants to move the customer portal to Azure, keep one legacy manufacturing system on premises, synchronize shared files, improve identity security, control spending, and monitor the new cloud environment.

Start with the cloud model. Because some systems remain on premises while new workloads move to Azure, the overall operating model is hybrid. For the customer portal, compare a virtual machine design with a managed web application platform. The application is modern and the team does not want to manage operating systems, so a PaaS-style web hosting option may reduce operational burden. If a small event-driven component processes uploaded files, functions could provide a serverless execution model. The point is not to produce a final production design; it is to defend the abstraction choices.

Next draw networking. Put the portal and supporting resources inside Azure. Show branch or datacenter connectivity through VPN Gateway as one option, then note where ExpressRoute would be considered if the requirement became private connectivity through a provider with enterprise connectivity characteristics. Add subnets for segmentation and a private endpoint for a platform service that should not be exposed through a public endpoint. Explain what Azure DNS does and what it does not do.

Add storage. Use Azure Files for shared file scenarios and consider Azure File Sync for the existing file server. Use Blob Storage for object data such as uploaded documents or backups. Select access tiers based on access frequency, then discuss redundancy based on the failure scope the business wants to tolerate. If the initial dataset is extremely large and network transfer is impractical, Data Box becomes a migration consideration.

Add identity and access. Put workforce identities in Microsoft Entra ID. Require strong authentication and use Conditional Access to express sign-in conditions. Apply Azure RBAC at the narrowest practical scopes for administrators. Bring in Zero Trust principles by verifying explicitly, applying least privilege, and assuming breach. Explain that these controls complement each other rather than replacing one another.

Add governance. Use management groups and subscriptions to organize the estate at appropriate scale. Use resource groups for lifecycle and logical grouping. Apply tags for owner, environment, and cost center. Use Azure Policy for enforceable standards and resource locks for critical resources that should not be accidentally deleted. If the company needs broader data-governance visibility, Microsoft Purview belongs in that conversation.

Add cost and monitoring. Estimate the planned environment with the pricing calculator, then use cost-management capabilities and budgets once resources are running. Use Advisor for optimization recommendations, Service Health for Azure service-impact information, and Azure Monitor for metrics, logs, alerts, and application telemetry. Notice how three monitoring tools answer three different operational questions.

Finally, explain the whole capstone aloud in five minutes. Do not read notes. If you can move from cloud model to architecture, services, identity, governance, cost, and monitoring without mixing the boundaries, you have rehearsed the kind of connected reasoning that makes AZ-900 questions much easier. If one section collapses into product-name guessing, that is the section to revisit.