AZ-900 does not require production administration, but a small amount of hands-on Azure work makes the terminology much easier to retain. A safe lab should demonstrate resource hierarchy, basic services, identity, cost, governance, deployment and monitoring without drifting into associate-level configuration. Use the current AZ-900 objectives as the lab boundary.
Lab one: explore the Azure portal and resource hierarchy
Open the portal, identify your directory/tenant context, subscription, resource groups and resources. Create one disposable resource group if your account permits it and tag it with owner/environment.
Then delete the group when the lab is complete so cost and cleanup become part of the exercise.
Lab two: compare regions and availability zones
Browse regional availability for a common service and note whether zone support exists. Compare two regions conceptually for geography, latency or service availability.
You do not need to deploy a multi-zone workload; the practical goal is recognizing the location hierarchy.
Lab three: inspect compute choices
Compare the creation experiences or documentation for a VM, Web App, container service and Function App. Write who manages the OS/runtime and what workload each fits.
This turns IaaS/PaaS/serverless concepts into visible management differences.
Lab four: explore VNet and endpoint concepts
Create or inspect a simple virtual network and subnet, then review peering, VPN Gateway, ExpressRoute and private endpoint concepts in the portal/documentation.
Keep the lab conceptual: AZ-900 needs purpose, not routing-table or firewall engineering.
Lab five: create a small storage example
Inspect a storage account, containers/file shares, access tiers and redundancy choices. Upload a harmless file and observe where the options live.
Compare the lab with an AZ-900 hands-on approach and note which storage/migration concepts become clearer through direct observation.
Lab six: inspect Entra ID and RBAC safely
Review users/groups or a test identity, inspect available RBAC roles on a resource group and compare Reader versus Contributor conceptually. If you lack permission to assign roles, use screenshots/documentation rather than requesting excessive privileges.
Then compare RBAC with Conditional Access and MFA so authorization and authentication remain distinct.
Lab seven: create a cost estimate and budget concept
Use Azure Pricing Calculator for a simple VM/storage example. If cost-management access exists, inspect Cost Management and create a small budget/alert in a lab subscription.
A cost-optimization exercise should show that region, size, runtime, storage and data movement can all affect spend.
Lab eight: test Policy and resource locks conceptually
Inspect Azure Policy definitions and create a policy assignment only in an authorized sandbox. Add a resource lock to a disposable resource if permitted and observe how it changes modification/deletion behavior.
The goal is to see governance enforcement, not to lock shared production resources.
Lab nine: deploy one resource with IaC
Use a very small ARM template or read a Microsoft quickstart template. Identify parameters, resources and declarative desired state. Deploy only if the environment is disposable and cost is controlled.
An ARM-template exercise demonstrates why infrastructure as code improves repeatability compared with manual clicking.
Lab ten: inspect Advisor, Service Health and Monitor
Open Azure Advisor, Service Health and Azure Monitor. Look at a metric/log/alert concept and, if a web app is available, inspect Application Insights.
Add a cloud-model tabletop before portal work. Describe which parts of the reference company would remain private/on-premises, which could move to public Azure and what a hybrid environment means. This gives every later lab a business context.
Add a service-model comparison using a VM, App Service-style web app and Microsoft 365/SaaS example. Record which layers you can configure and which Microsoft operates. The hands-on value is observing how management responsibility changes as the service becomes more managed.
Add a resource-group lifecycle exercise. Put two disposable resources in one lab group, apply a tag and inspect the group’s activity/deployment context. Clean up the group at the end and confirm contained resources are removed. This demonstrates why grouping can support lifecycle management.
Add a subscription/management-group diagram even if your lab has only one subscription. Draw how an enterprise could separate production, development or business units and apply Policy or RBAC at broader scopes. Azure Fundamentals expects conceptual scale beyond a personal account.
Add a VM configuration observation rather than a full production deployment. Note image, size, disk, network and region choices. These components are enough to understand what resources a VM needs without spending money on a long-running instance.
Add a serverless comparison by browsing Function App creation and trigger concepts. Compare with the VM setup: there is no guest OS management step. This makes serverless abstraction visible without writing application code.
Add an Azure DNS/peering/VPN/ExpressRoute comparison diagram. For each, write whether it addresses name resolution, VNet-to-VNet connection, encrypted connectivity or dedicated private connection. Hands-on preparation can be diagram-based when deployment cost/permissions would be excessive.
Add a storage-redundancy observation. In a storage account wizard or documentation, compare locally, zone and geo redundant options conceptually. Ask which failure boundary each is intended to protect and how additional redundancy can affect cost.
Add a file-movement lab with Storage Explorer or AzCopy if available. Upload/download a small harmless file, then compare with File Sync and Data Box use cases on paper. This connects ordinary transfer, synchronization and offline migration.
Add an Entra authentication comparison. Review MFA, passwordless and SSO concepts and identify which are authentication experiences versus authorization. Avoid changing production tenant policies; a conceptual or sandbox exercise is enough.
Add a Conditional Access tabletop. Define a policy such as requiring MFA for a particular risk/context and list the signals, target and control. Do not deploy broad access policies in a shared tenant just for exam practice.
Add an RBAC inheritance exercise using a resource group. Inspect who has Reader or Contributor-like access and at what scope. The purpose is to see that roles assigned higher in the hierarchy can affect lower resources.
Add a tags-versus-Policy lab. Give a resource a CostCenter tag, then inspect a policy definition that would require or audit tags. The tag is metadata; the policy is the governance mechanism. Seeing both removes a common exam confusion.
Add a resource-lock lab only on a disposable resource. Apply a delete lock, attempt the relevant change and then remove the lock before cleanup. This demonstrates that locks protect resource operations even when the user otherwise has permission.
Add an Arc review using screenshots/documentation if no hybrid server is available. Identify how a non-Azure server can appear as an Azure-managed resource and which governance/management scenarios this enables. The concept matters more than standing up extra infrastructure.
Add an Advisor/Service Health/Monitor comparison worksheet after exploring each blade. Record one example signal and one non-use-case for each. This prevents “all Azure monitoring tools are the same” thinking.
Add an Application Insights observation on a sample web application if available. Look for request duration, failures or dependency telemetry. You do not need to build a full monitoring strategy; the lab simply shows application telemetry inside Azure Monitor.
Close the hands-on sequence with a cost-and-cleanup audit. Review created resources, tags, locks, budgets and billing estimates, then remove anything disposable. Responsible Azure learning includes knowing what remains deployed and why.
Add an availability-set versus zone comparison on paper. Place two VMs into a classic availability-set concept and then redraw them across availability zones. The point is understanding that fault/update-domain distribution and zone isolation are distinct resilience models.
Add a VM Scale Set walkthrough using screenshots or documentation if deployment is not practical. Identify the repeated VM definition, scaling concept and load-balancing relationship. The exam expects purpose, not autoscale-rule engineering.
Add a Microsoft Purview observation in documentation or an available portal surface. Identify how it relates to data governance/compliance and contrast that with Azure Policy. This fills a common fundamentals gap because many learners spend more time on compute than data governance.
Add a Defender for Cloud observation. Look at security-posture recommendations or the service overview and describe what it contributes that ordinary RBAC does not. RBAC controls permissions; Defender for Cloud evaluates and helps protect cloud security posture/workloads.
Add a storage-tier comparison using one hypothetical dataset such as daily logs retained for years. Decide when data is hot, cool or archival and what retrieval expectations would make one tier unsuitable. This connects technical storage terms with business usage.
Add a Data Box tabletop where a company needs to move a very large dataset with constrained bandwidth. Compare shipment/offline transfer with AzCopy or network migration. This makes migration-tool selection easier without ordering hardware.
Add a final “explain the portal” walkthrough for a nontechnical colleague. Show where resources, costs, identity, Policy and Monitor concepts live, but explain purpose rather than clicking through every option. Teaching the map is a strong way to test foundational understanding.
Add a simple Resource Manager activity-log observation. Create or delete a disposable resource and review the management event if your permissions allow it. This is not an exam requirement by itself, but it reinforces that portal actions become control-plane operations rather than mysterious GUI-only changes.
Add a shared-responsibility worksheet immediately after the compute lab. For the VM, web app and serverless example, mark who patches the OS, manages runtime, secures application code, controls identities and protects data. Practical comparison makes the IaaS/PaaS/serverless differences durable.
Finish by producing a one-page lab evidence sheet containing a resource hierarchy sketch, one cost estimate, one IAM/RBAC distinction, one governance example and one monitoring example. If each artifact can be explained without portal-specific jargon, your hands-on work has reinforced fundamentals rather than distracted from them.
The Application Insights context should make the monitoring distinction concrete: recommendations, service health, platform telemetry and application telemetry answer different operational questions.