Microsoft AZ-104 Azure Administrator Practical Preparation: Scenarios, Exercises, and Skills to Rehearse

 

AZ-104 is an administration exam, so the most valuable practice is not memorizing where settings live in the Azure portal. It is learning to translate a requirement into the right control, apply that control at the right scope, and then prove that the result behaves as intended. Microsoft’s current skills measured as of April 17, 2026 still center on five areas: identities and governance, storage, compute, virtual networking, and monitoring and recovery. The practical challenge is that real scenarios frequently cross two or three of those areas at once.

A useful lab therefore begins with a requirement, not a service. “Create a virtual machine” is a product exercise. “Deploy a workload that survives an infrastructure failure, is reachable only through an approved path, is monitored, and can be restored” is an administrator exercise. The second forces you to make decisions about availability, networking, identity, monitoring, and recovery. That is the level of thinking this guide is designed to build.

Use the AZ-104 readiness article to identify weak domains, then use the exercises here to generate evidence that those weaknesses are improving. Keep the AZ-104 exam and Azure Administrator pages as reference points, but treat hands-on work as a way to understand the technology rather than a way to memorize a particular question pattern.

What practical competence looks like on the current AZ-104 blueprint

The five current skill areas are not equally weighted, and practical rehearsal should reflect that. Identities and governance and compute are each 20–25 percent; storage and virtual networking are each 15–20 percent; monitoring and maintenance are 10–15 percent. Those percentages are useful for time allocation, but they should not create five isolated study silos. Monitoring is embedded in good compute practice. Identity affects storage and application access. Networking affects nearly every private-service scenario.

For hands-on work, translate each domain into observable administrator behaviors:

• Identity and governance: create or modify principals, assign roles at appropriate scope, inspect effective access, apply governance controls, and explain why Policy, RBAC, locks, tags, and hierarchy are not interchangeable.
• Storage: select an authorization method, configure the network path, choose redundancy and recovery features, move data with appropriate tools, and explain how lifecycle settings change cost and recoverability.
• Compute: deploy and modify resources, reason about availability and scaling, interpret Bicep or ARM definitions, and connect compute to networking, identity, monitoring, and backup.
• Networking: design address space, control routes and filtering, build private connectivity, configure name resolution and load balancing, and troubleshoot from the packet path.
• Monitoring and recovery: interpret metrics and logs, create useful alerts, use network diagnostics, configure backup, and distinguish restoration from disaster-recovery failover.

A good lab should produce evidence for at least two of these behaviors. Screenshots are less useful than a short record of the requirement, your chosen control, the validation evidence, and the fault you introduced. That record tells you whether you actually understood the task or merely reached the desired state.

Build labs around administrative decisions

Build a lab around decisions, not around clicking

A weak lab asks, “Can I create a virtual machine?” A stronger lab asks, “Can I deploy a virtual machine that meets a specific availability, networking, storage, access, and monitoring requirement, and can I explain every choice?” The second version is closer to the work of an administrator and more useful for scenario-based exam preparation.

For every lab, write a short requirement before touching the portal. Define the business objective, technical constraints, expected outcome, and validation step. For example: a development team needs two virtual machines in the same region, the workload must tolerate a single datacenter failure, management traffic must not require direct public RDP or SSH exposure, and the operations team must receive an alert if CPU remains above a threshold. That requirement forces you to think about availability zones or sets, Azure Bastion, network security, and Azure Monitor rather than treating each feature as an isolated checklist item.

When the configuration is complete, deliberately break one dependency. Remove an NSG rule, change a route, alter a role assignment, or point a DNS record at the wrong destination. Troubleshooting the broken state teaches more than repeating a successful wizard. The exam can present symptoms rather than instructions, so your practice should include symptoms too.

Use one repeatable exercise template

A consistent exercise template reduces wasted time and makes results comparable. Use five stages for most AZ-104 labs.

1. Define the requirement in plain language.
2. Predict the Azure services and settings that should satisfy it.
3. Implement the configuration using at least one administrative interface.
4. Validate the result with evidence rather than assumption.
5. Change or break one component and troubleshoot the outcome.

The prediction step is especially important. If you open the portal first and browse until you find a plausible setting, you can accidentally train yourself to recognize menus rather than solve problems. Predicting first forces you to retrieve knowledge from memory. Even when the prediction is wrong, the correction becomes memorable because it is connected to a decision you made.

A useful practice log records the requirement, your predicted solution, commands or settings used, the evidence that proved success, and the mistake you made. Over several weeks, this becomes a personalized troubleshooting guide. It also reveals recurring weaknesses, such as confusion over RBAC scope, private endpoint DNS, storage authorization, or backup vault selection.

Score labs by evidence, not by completion

A lab is not necessarily successful just because the resource exists. Use a scoring rubric that separates configuration, explanation, validation, and troubleshooting. Give yourself one point for each of the following: you chose the right Azure service without browsing for hints; you configured the important settings correctly; you can explain the security and operational consequences; you validated the result with an observable test; and you can diagnose at least one intentional failure.

This changes the meaning of “I know virtual networking.” A candidate who can create a VNet from a wizard may have basic familiarity, but a candidate who can predict address-space interactions, evaluate an NSG, explain a custom route, diagnose a failed peering path, and prove that traffic reaches the intended destination has much stronger readiness. The same applies to identity, storage, compute, and monitoring.

Keep scores by objective area rather than by lab. You may discover that you can deploy storage accounts reliably but still make errors with authorization. You may understand VMs but struggle with scale sets or App Service networking. You may be comfortable creating alerts but uncertain about log queries. This level of detail is more actionable than a single practice-test percentage.

Revisit low-scoring areas after several days rather than immediately. Delayed repetition tests whether the skill is durable. If you can complete the same type of scenario after a gap and with different resource names, regions, or constraints, you are less likely to be relying on short-term memory of a previous walkthrough.

Identity and governance rehearsal

Rehearse Microsoft Entra ID and governance as a lifecycle

Identity and governance are not separate administrative topics. They define who can act, what they can act on, and which organizational rules limit those actions. A more useful exercise begins with a lifecycle rather than a single role assignment.

Create a small fictional organization with users, groups, an external collaborator, two resource groups, and at least one subscription-level requirement. Practice creating and modifying users and groups, assigning group membership, reviewing properties, handling an external identity, and configuring self-service password reset concepts. Then move into Azure role-based access control. Give one group Reader access at a broad scope and another group Contributor access only to a specific resource group. Verify what each identity can see and change.

Next, change the scope. Assign a role at the subscription level and observe how inheritance affects child resources. Remove a direct assignment and determine whether effective access remains because of a parent scope. The purpose is to understand *effective permissions*, not simply to know where the “Add role assignment” button is.

Extend the same environment with Azure Policy, tags, and resource locks. Create a policy that audits or restricts a property. Apply a required tag. Add a delete lock to a critical resource. Then ask a scenario question: if a user has Contributor but a delete lock exists, what happens? If a resource complies with RBAC but violates policy, what happens? These comparisons train the distinction among authorization, governance, and protection from accidental change.

The deeper Entra governance is useful when this area needs more focused review. You can also test governance details with the governance practice.

Storage rehearsal

Create storage exercises that test access, resilience, and lifecycle

Storage becomes much easier to remember when you treat it as three questions: who can access the data, how durable or available the data must be, and how the data should behave over time. Build labs that force all three questions into the same scenario.

Create a storage account and compare access through account keys, shared access signatures, and identity-based authorization. Generate a SAS with a limited permission set and expiration time, then confirm what it can and cannot do. Rotate or regenerate an access key and consider which applications would be affected. Configure firewall or virtual-network restrictions and verify that a previously working path can be blocked.

Then work with Azure Files and Blob Storage. Create a file share, create a blob container, upload test data, and practice using a management tool such as Storage Explorer or AzCopy. Configure blob versioning, soft delete, storage tiers, or lifecycle management. The point is not to enable every option at once. The point is to observe what changes in recovery behavior and cost-management possibilities when those options are enabled.

For resilience, compare locally redundant, zone-redundant, geo-redundant, and related replication choices conceptually. Be ready to explain what type of failure each option is intended to address and why a more resilient option may introduce different cost or recovery characteristics. Do not reduce redundancy to an acronym-matching exercise.

A good final scenario is to provide a requirement such as: “Data must be private, only a specific workload should access it, accidental deletions should be recoverable, and older objects should move to a lower-cost tier.” Then implement or describe the configuration in the right order. The storage guide can support this practice, along with focused storage security practice.

Compute and infrastructure-as-code rehearsal

Practice compute as a set of deployment choices

Azure compute in AZ-104 is broader than virtual machines. The current skills include ARM templates or Bicep, virtual machines and scale sets, containers, Azure Container Registry, Azure Container Instances, Azure Container Apps, and App Service. Practical preparation should teach you to decide which operational model fits a requirement.

Start with a virtual machine lab. Choose an image, size, disk configuration, network interface, subnet, and availability design. After deployment, resize the VM, attach or modify disks, move resources where supported, and review the effect of availability choices. Add monitoring so the exercise connects compute to operations.

Then repeat the requirement with a different compute model. Could a small stateless web workload run on App Service instead? What changes if the requirement emphasizes fast container deployment rather than operating-system control? When would a scale set be more appropriate than manually creating several VMs? You do not need to become a specialist in every service, but Make sure you understand the administrative tradeoffs.

For App Service, practice creating a plan and app, configuring scaling, mapping a custom DNS name conceptually, reviewing TLS/certificate settings, configuring a backup, examining networking options, and using a deployment slot. For containers, practice the relationship among a container image, a registry, a running container instance or app, and scaling settings.

Finally, take a simple resource deployment and represent it with Bicep or an ARM template. Read the file before deploying it. Identify parameters, resources, dependencies, and outputs. Change one property and redeploy. The exam objective is not to turn you into a full-time infrastructure-as-code developer; it is to make sure an Azure administrator can interpret and modify common deployment definitions. For more depth, use the compute guide.

Networking rehearsal

Build networking labs from packets and paths

Networking is one of the easiest AZ-104 areas to study superficially because the portal makes configuration look simple. The real skill is predicting the path traffic should take and identifying which control can allow, deny, translate, route, or resolve that traffic.

Create a virtual network with multiple subnets and deploy small test workloads. Add an NSG and write rules that intentionally allow one flow and deny another. Before testing, predict which rule should win based on priority, direction, source, destination, protocol, and port. Review effective security rules rather than assuming the rule you created is the only rule that matters.

Next, connect virtual networks with peering. Verify address-space requirements and connectivity expectations. Add a user-defined route and observe how changing the next hop affects the path. Practice diagnosing connectivity by checking the sequence of controls: DNS resolution, route selection, NSG evaluation, service-specific restrictions, and application listening state.

Secure administrative access with Azure Bastion rather than exposing management ports directly. Compare service endpoints with private endpoints at a conceptual level, then build a private-access scenario if your lab allows it. Pay particular attention to DNS because a private endpoint that resolves to the wrong address can look like a firewall problem even when the network controls are correct.

Add Azure DNS or name-resolution exercises and configure a basic load-balancing scenario. Validate not only that the front end responds, but also that backend health and rule configuration explain the result. The networking guide and networking practice are natural follow-ons if path analysis remains a weak point.

Monitoring, backup, and recovery

Connect monitoring to a troubleshooting story

Monitoring makes more sense when you start with a problem. Instead of creating an alert because the objective mentions alerts, create an alert because a workload has a defined operational condition that should trigger action.

Deploy a resource and identify a meaningful metric. Create or inspect a log source. Build an alert rule, associate an action group, and understand how alert processing changes notification behavior. Use Azure Monitor to compare metrics with logs: metrics give efficient numerical time-series data, while logs support richer queries and event analysis. Practice knowing which type of evidence you would seek for a given incident.

For a virtual machine, storage account, or network, review available Insights experiences. Use Network Watcher or Connection Monitor when a connectivity problem is part of the scenario. The objective is to choose a diagnostic tool because of the question you are asking, not because the tool name sounds related to networking.

A useful exercise is to create a simple outage narrative. For example, users report intermittent access to an application. Check whether the backend is healthy, whether resource metrics show saturation, whether network connectivity is successful, and whether logs reveal application or platform errors. Write down the order in which you investigated. Then ask whether a different first step would have reduced time to diagnosis.

Rehearse backup and recovery before you need them

Backup preparation should include both configuration and recovery. Creating a vault and policy is only half the skill. You need to understand what is protected, the retention behavior, and how restoration changes the environment.

Create the appropriate vault for a supported workload, define a backup policy, perform or inspect a backup, and walk through a restore process. Note which choices are made when the backup policy is created and which choices appear only at restore time. If you can, compare file-level or resource-level recovery concepts with full workload recovery.

Then study Azure Site Recovery as a continuity mechanism rather than treating it as another backup feature. Backup is primarily about recoverable copies of data or workloads; Site Recovery is about replication and failover to maintain or restore service when a primary environment is unavailable. Practice explaining this difference in a scenario.

Create a disaster-recovery tabletop exercise even if you cannot build the full environment. State the primary region, recovery region, dependencies, replication requirement, failover trigger, validation step, and failback considerations. This forces you to think in sequence and reveals dependencies such as networking, DNS, identity, and data consistency.

Use multiple interfaces and troubleshoot deliberately

Use both portal and command-line interfaces

Candidates sometimes become comfortable with one interface and avoid the others. That can limit understanding. The portal is excellent for visual discovery. Azure CLI and PowerShell reveal resource identifiers, parameters, and repeatable operations. Bicep or ARM templates reveal declarative structure and dependencies.

For common tasks, perform the first attempt in the portal and the second attempt with a command-line tool. Create a resource group, list resources, inspect properties, apply a tag, query a role assignment, or examine a network object. You do not need to memorize every command. You do need to recognize what information a command requires and what its output tells you.

After a command succeeds, inspect the resource in the portal. After a portal change, retrieve the state from the command line. Moving between interfaces builds a stronger mental model because the same resource is being represented in different ways.

For infrastructure as code, focus on reading and modifying. Given a Bicep file, identify the resource type, API version, name, location, properties, and dependencies. Predict the change before deploying it. This is more useful than memorizing syntax fragments without understanding the resulting Azure state.

Turn troubleshooting into a deliberate skill

A practical administrator needs a disciplined troubleshooting method. Use one for every lab failure:

6. Restate the expected behavior.
7. Confirm the actual symptom.
8. Identify the layer most likely to contain the fault.
9. Gather evidence before changing settings.
10. Make one change at a time.
11. Retest the original requirement.
12. Document the cause and the proof of resolution.

This prevents random clicking. Suppose a VM cannot reach a storage endpoint. Possible causes include DNS, routes, NSGs, storage firewall settings, private endpoint configuration, or application behavior. Changing all of them at once may restore access but teaches you nothing. A controlled process teaches causality.

Create intentional faults in your labs: an incorrect subnet, a too-restrictive NSG rule, a role assignment at the wrong scope, an expired SAS, a missing route, a stopped backend, or an alert with the wrong threshold. The troubleshooting step is where isolated AZ-104 topics become integrated skills.

Short-form scenarios and practice questions

Build scenario cards for fast rehearsal

Not every practice session needs a full lab. Scenario cards are useful when you have 20 or 30 minutes. Each card contains a short requirement on one side and a solution outline on the other.

Example: “A team must upload files for two hours without receiving the storage account key.” Your answer should consider a time-limited SAS with appropriate permissions and scope. Another card might say: “A developer can view resources but cannot modify them, despite a Contributor assignment on the resource group.” Your investigation should consider inherited deny-like governance effects, role scope, effective assignments, resource locks, and whether the operation is controlled by Azure RBAC at all.

Create cards that combine domains. A web app may need a private storage connection, monitoring, backup, and least-privilege administration. A VM migration scenario may involve resource groups, subscriptions, networking, disks, and policy. Combination scenarios are valuable because real administration rarely arrives as one-objective-at-a-time tasks.

Use practice questions after hands-on work, not instead of it

Practice questions are most useful when they test a model you have already built. After completing a networking lab, use a small set of networking questions and explain why each alternative is right or wrong. After a storage lab, use questions to check whether you can transfer what you observed into a new scenario.

The goal is not to memorize the wording. Record the underlying rule. If a question exposes confusion about NSG priority, write the rule for rule evaluation and test it in a lab. If a storage question exposes confusion about SAS scope, generate a SAS and verify what it permits. If a governance question exposes confusion about policy versus RBAC, create a simple example and observe the difference.

The broader AZ-104 guide can help you integrate labs with reading and review, while study methods provide additional ways to structure repetition.

Integrated capstones

Capstone scenario 1: secure internal application

Build or design an internal application environment for a small operations team. The application runs on Azure compute, uses storage, and should not expose administrative ports to the public internet. Only designated administrators should be able to change the resources. The environment must be tagged for cost allocation, monitored for failures, and recoverable after an accidental deletion or workload problem.

Break the scenario into decisions. Choose the compute model and explain why it fits. Place resources into resource groups that support administration and lifecycle. Assign RBAC at the narrowest practical scope. Apply tags and a lock where it makes sense. Design networking with subnets, NSGs, Bastion or another secure administration path, and private access to storage if the scenario calls for it. Configure monitoring and an alert. Decide what is protected by backup and what can be recreated from code.

Then change one requirement: the application must now scale for a temporary event. Ask whether your original compute choice still makes sense. Change another requirement: an external support engineer needs temporary read-only access. Ask how identity and scope should change. Capstone work is valuable because it forces you to adapt a configuration instead of treating the first design as permanently correct.

Capstone scenario 2: department migration with governance

Imagine that a department is moving several workloads into a new Azure subscription. The organization requires a standard tag set, restricted deployment regions, budget alerts, and centralized visibility. Different teams need different levels of access, and one legacy application uses a file share that must remain available during the transition.

Start at the hierarchy. Decide whether management groups are relevant, how policy should be assigned, which controls belong at subscription scope, and which permissions should remain at resource-group scope. Create a cost-management approach with budgets or alerts. Plan the identity model so day-to-day operators do not receive unnecessary rights.

Next, design the storage migration. Determine how data will be transferred, how access will be authorized, how the file share will be protected, and how you will validate availability. If a virtual machine moves between resource groups or subscriptions, identify dependencies that may prevent or complicate the move. Think about resource locks and policy assignments before assuming every move will succeed.

Finish with monitoring. What evidence will show that the new environment is healthy? Which logs or metrics matter? Who should receive alerts? What would you check first if the migrated application is reachable from one network but not another? The point is not to build a perfect enterprise architecture. It is to practice making connected administrative decisions under realistic constraints.

Capstone scenario 3: recover from a service incident

Create an incident in which users cannot reach an Azure-hosted application. The application has a front end, compute backend, storage dependency, and monitoring. Do not decide the cause before starting. Instead, generate several possible faults and select one at random: an NSG rule changed, a backend became unhealthy, DNS points to an old address, a storage firewall blocks the workload, a role assignment prevents an automation task, or a resource has exhausted capacity.

Work the incident using evidence. Confirm scope: all users or some users, all functions or one function, one region or all regions. Check monitoring for the time the incident began. Test name resolution and network connectivity. Inspect security rules and routes. Review the health of the compute target. Check storage access only if evidence points in that direction. Record each hypothesis and whether the evidence strengthens or weakens it.

After resolution, write a short post-incident note. What changed? What monitoring signal could have detected the issue sooner? Could policy, infrastructure as code, access control, or a lock have prevented the change? Should an alert threshold be adjusted? This exercise connects troubleshooting with governance and operations, which is exactly the kind of integrated thinking that makes AZ-104 preparation more durable.

A four-week practical rehearsal model

A four-week hands-on cycle can work well after you have completed an initial content review.

Week 1: identity, governance, and storage

Spend the first half of the week on users, groups, external identities, role assignments, scope, policy, locks, tags, resource groups, management groups, and cost-management concepts. Spend the second half on storage access, SAS, keys, network restrictions, redundancy, file shares, blobs, soft delete, versioning, and lifecycle rules. End the week with a scenario that combines RBAC, policy, and private storage access.

Week 2: compute and infrastructure as code

Deploy and manage virtual machines, disks, availability options, and scale concepts. Add a container and App Service exercise. Read and modify a Bicep or ARM deployment. Finish by rebuilding one earlier resource through a different interface.

Week 3: networking

Work through virtual networks, subnets, peering, routes, NSGs, Bastion, service endpoints, private endpoints, DNS, and load balancing. Intentionally misconfigure at least three items and troubleshoot them from symptoms.

Week 4: monitoring, recovery, and integration

Configure metrics, logs, alerts, Insights, Network Watcher, backup, and a disaster-recovery scenario. Use the final days for integrated labs that combine three or more domains. Finish with practice questions only after you can explain your lab decisions without notes.

What readiness should look like

Know what “ready” looks like

You do not need to perform every Azure task from memory without documentation. Administrators use documentation in real work. Exam readiness is better represented by whether you can recognize the appropriate service, locate the relevant configuration, predict the effect of a change, identify dependencies, and troubleshoot a result.

You are moving toward readiness when you can read a requirement and sketch a plausible Azure design before opening the portal. Be ready to explain why an RBAC assignment belongs at a particular scope, why one storage authorization method fits better than another, why a network path fails, why a compute platform matches a workload, and which monitoring evidence would confirm a diagnosis.

If you repeatedly need a walkthrough for the same task, return to the concept behind the steps. If you can perform the steps but cannot explain *why* they work, add scenario questions. If you can explain the design but make execution errors, add more hands-on repetition. Practical preparation works because it lets you diagnose the type of weakness rather than simply adding more study hours.

Final preparation checklist

Before you consider your practical preparation complete, make sure you have rehearsed the major administrative motions of the current AZ-104 blueprint:

• manage users, groups, external identities, and access;
• assign and interpret Azure roles at different scopes;
• use policy, locks, tags, resource groups, subscriptions, and management groups appropriately;
• configure storage access, redundancy, file shares, blobs, lifecycle, and recovery-related settings;
• deploy and modify compute resources, including VMs, scale concepts, containers, App Service, and infrastructure-as-code definitions;
• configure virtual networks, peering, routes, NSGs, Bastion, private connectivity, DNS, and load balancing;
• interpret metrics and logs, configure alerts, and use diagnostic tools;
• configure backup and reason about disaster recovery;
• move between the portal, CLI or PowerShell, and declarative resource definitions;
• troubleshoot from evidence rather than from guesses.

The Microsoft certifications can help you place AZ-104 alongside other Microsoft credentials.

Practical preparation should leave you with more than a collection of successful labs. It should leave you with a repeatable way to approach unfamiliar Azure scenarios: identify the requirement, choose the control, implement carefully, validate with evidence, and troubleshoot methodically. That process is useful on AZ-104 because it is useful in Azure administration itself.

Keep the lab environment inexpensive and disposable

Hands-on practice does not require a permanent production-like Azure estate. Build small, temporary resources and remove them when the exercise is complete. Use modest sizes, limited data, short-running workloads, and clear naming so you can identify what belongs to a study session. Review cost-management information regularly and delete resources that are no longer needed.

The habit of cleaning up is itself useful administrator practice. Before deleting a resource group, predict what will be removed. Check whether a lock prevents deletion. Confirm whether a resource is shared by another exercise. Consider whether data needs to be retained. A disposable lab should still teach lifecycle discipline rather than encouraging careless deletion.

Maintain a simple baseline script or Bicep file for resources you rebuild often. This reduces setup time and gives you additional infrastructure-as-code exposure. But do not automate away every learning step. If the objective of the session is to understand storage networking, it may be useful to deploy the supporting VNet automatically and configure the storage restriction manually. Automation should remove irrelevant repetition, not the part of the exercise you are trying to learn.