AZ-104 rewards candidates who have actually administered Azure. The current blueprint asks for actions such as assigning roles, configuring storage access, deploying infrastructure from templates, creating virtual machines and containers, managing virtual networks, setting alerts, and restoring protected resources. Those are practical skills, not concepts that can be learned reliably from screenshots alone.

A useful lab strategy is to build a small environment that can be reused across domains. The environment does not need to be production-sized. It needs enough moving parts to expose Azure’s control plane, identity, network, storage, compute, monitoring, and recovery behaviors. Each lab should have a clear expected state, one or more deliberate changes, and a way to verify the result.

The AZ-104 exam objectives should determine which labs you build. The goal is not to collect impressive projects; it is to practice the exact administrative decisions Microsoft says are in scope.

Build a governance sandbox before deploying workloads

Create a resource group and apply tags. Add a resource lock, then test what changes are still possible. Assign a policy that checks or enforces a simple condition. If your environment permits it, experiment with subscription-level and resource-group-level settings so you can see inheritance.

Then create a test user or group in Microsoft Entra ID and assign a built-in Azure role at a narrow scope. Verify what the identity can do, change the scope, and observe the difference. This is more valuable than memorizing role names because it teaches how authorization and hierarchy interact.

Use the lab to ask operational questions. What happens if a contributor can modify resources but a delete lock exists? What if a role is assigned at a resource group and a new resource is added? How do policy and RBAC differ when both affect the same deployment? The answers create the mental model behind Azure RBAC and governance.

Create a storage account and test every access path

Deploy one storage account and use it to practice several objectives. Configure redundancy. Create a blob container and an Azure Files share. Move data with Azure Storage Explorer or AzCopy. Enable soft delete or versioning, then delete and recover data so protection behavior is visible.

Next, work through access methods. Use an access key, generate a SAS token with limited permissions and lifetime, and configure identity-based access where appropriate. Change firewall or virtual-network rules and confirm which clients can still reach the service. If a connection fails, determine whether authentication, authorization, or network reachability is the cause.

Finish by configuring a lifecycle rule or tiering behavior. The complete exercise turns Azure Storage into a set of trade-offs: access, durability, data protection, cost, and network exposure.

Deploy the same resource manually and through infrastructure as code

Create a simple resource in the portal, then inspect or export the deployment representation. Modify an ARM template or Bicep file and redeploy it. Change a parameter rather than editing every property directly. The objective is to understand what repeatable deployment looks like from an administrator’s perspective.

ARM templates become easier to troubleshoot when you can compare declared configuration with the actual resource state. Introduce one deliberate mistake: an invalid dependency, wrong parameter value, or property that conflicts with policy. Read the deployment error and fix the definition.

This practice also reinforces governance. If Azure Policy blocks a template deployment, the failure is not “an ARM problem.” It is evidence that the declared state violates a control applied at a higher scope. That cross-domain interpretation is exactly the kind of reasoning an administrator needs.

Build a network, secure it, and then break it

Create a virtual network with at least two subnets. Add a network security group and apply rules that permit only the traffic your test workload requires. Peer another virtual network if your environment allows it. Add a user-defined route and observe effective routes. These tasks make virtual networks tangible.

Then create a failure. Deny a required port with an NSG, remove a route, or change a name-resolution dependency. Use effective security rules, connection troubleshooting, and Azure Network Watcher to identify the break. Restore the correct state and verify traffic flow.

Finally, add a load balancer if you can support multiple backends. Configure a health probe and load-balancing rule, then intentionally make one backend unhealthy. A focused Azure Load Balancer lab shows why probes, rules, backend pools, routes, and NSGs must all align.

Practice compute across virtual machines, containers, and App Service

For virtual machines, create one or more VMs, change sizes, attach or resize disks, and review placement options such as availability zones or sets. If possible, deploy a small scale set so you understand how instance management differs from a standalone VM. Use Bastion or controlled network access instead of assuming every machine needs a public management endpoint.

For containers, push or use an image and deploy it through Azure Container Instances. Then compare that experience with Azure Container Apps at a conceptual and administrative level. Focus on image source, resource sizing, scaling, network access, and identity rather than application code.

For App Service, configure a plan and web app, inspect scaling options, work with TLS and custom-domain settings if practical, and use deployment slots. Add a backup configuration and examine networking controls. This gives you a managed-compute contrast to the VM model.

Turn monitoring into a routine part of every lab

Do not create resources without observing them. For each workload, open Azure Monitor and identify useful metrics. Configure diagnostic or log settings where appropriate. Run a query against collected logs. Create an alert rule and action group, then trigger or simulate the condition if feasible.

The important skill is choosing evidence. If a VM is slow, which metric should you inspect first? If storage access is failing, what logs or network evidence could distinguish authorization from connectivity? If a load-balanced application is unavailable, where do backend health and probe status fit into the investigation?

Repeat those questions across several resources. Monitoring becomes an exam skill when candidates can select the right signal for a requirement, not when they can simply navigate to the Monitor blade.

Practice backup and restore as a complete operation

Create the appropriate vault, configure a backup policy, protect a test workload, and confirm that recovery points are available. Then perform a restore. The restore step matters because it exposes details that policy creation alone does not: target location, identity, networking, recovery-point selection, and expected result.

Review Azure Backup reports or alerts so you can tell whether protection is succeeding. If you can safely practice Site Recovery, focus on the difference between backup-based restoration and replicated failover to another region.

Ask which failure each feature addresses. Accidental deletion, corrupted data, regional outage, host failure, and capacity pressure are not the same event. The exam often rewards the control that matches the failure model rather than the most sophisticated service.

Cost control is also part of practical administration. Use small resource sizes, remove temporary resources after labs, and review cost alerts or budgets as part of the exercise. This is not only housekeeping: the blueprint explicitly includes managing costs with alerts, budgets, and Advisor recommendations. A lab that teaches you to build resources but never to govern their cost leaves out a real administrator responsibility.

Use one integrated capstone instead of ten disconnected mini-labs

After individual exercises, build a small environment that combines them. For example, deploy a web workload behind a load balancer or managed service, place data in a protected storage account, assign a managed identity, restrict traffic, apply tags and policy, configure monitoring, and create a recovery plan. Then document the intended architecture in plain language.

Break one dependency at a time and diagnose it. Remove a role assignment. Block a subnet. Expire or restrict a SAS token. Misconfigure a health probe. Trigger an alert. Restore deleted data. This teaches the most transferable administrator skill: tracing a requirement or symptom through multiple Azure layers.

The Azure Administrator Associate is designed for professionals who operate real environments. A capstone turns abstract objectives into a coherent system and makes weak areas obvious before exam day.

Measure labs by decisions you can explain

Hands-on preparation should not become a race to complete the largest number of exercises. A better metric is whether you can explain why each setting exists, what would happen if it changed, and which tool would verify the result. If you can create an NSG but cannot predict rule evaluation, the lab is incomplete. If you can configure a backup but cannot distinguish it from Site Recovery, repeat the scenario.

Keep notes focused on decisions, not click paths. Portal locations change; Azure concepts are more stable. Record the requirement, the control you chose, the verification method, and a common failure mode. That format is much easier to review than screenshots of every configuration page.

This approach also fits the wider Microsoft certification philosophy: role-based exams are intended to reflect job tasks. For AZ-104, the strongest practice is administration that can be justified, observed, and troubleshot—not just reproduced.