Microsoft AZ-104 Exam Guide: Skills, Labs, and Preparation
AZ-104 tests whether you can administer an Azure environment, not whether you can recognize every service name. Preparation is strongest when each objective becomes an action you can carry out, verify and troubleshoot: assigning access, protecting data, deploying compute, diagnosing a connection or recovering a resource. This guide maps the current blueprint to practical exercises and a readiness test that goes beyond a practice-exam score.
On this page
- Start with the live blueprint, not an old course outline
- Build an identity lab that exposes the difference between role and scope
- Treat storage decisions as recovery and access decisions
- Deploy compute using the right control surface
- Diagnose a network failure rather than memorizing network diagrams
- Make monitoring useful before something fails
- Use a study schedule that follows observed gaps
- Decide readiness from the decisions you can defend
Start with the live blueprint, not an old course outline
The Microsoft Certified: Azure Administrator Associate credential is aligned with the AZ-104 exam. Microsoft’s skills outline, applicable to the English exam from April 17, 2026, groups the work into five areas. The ranges are guidance about emphasis, not a promise that your sitting will contain a certain number of questions per topic.
| Domain | Published weighting | What you need to demonstrate |
|---|---|---|
| Azure identities and governance | 20–25% | Apply RBAC, Policy, locks, tags, budgets and management groups |
| Storage | 15–20% | Control data access, redundancy, lifecycle and recovery |
| Compute | 20–25% | Deploy and operate VMs, containers, App Service and templates |
| Virtual networking | 15–20% | Configure VNets, routes, secure access, DNS and connectivity |
| Monitoring and maintenance | 10–15% | Interpret signals, alert intelligently, back up and restore |
Start by reading the current Microsoft AZ-104 study guide, then compare the objective verbs with what you can actually do. “Configure” should produce a configured resource and verification evidence. “Troubleshoot” should produce a failed test, a diagnosis and a confirmed fix. “Interpret” should produce an explanation of why a signal matters. This is more revealing than marking a chapter complete after watching a demonstration.
A previous course can still teach useful Azure concepts, but portal screens, service names, API behavior and the assessed scope change. Confirm a procedural lesson against current documentation before using it as a primary lab. Avoid treating an old practice question as evidence that a feature still behaves the same way.
Build an identity lab that exposes the difference between role and scope
Create a disposable resource group and two test identities or groups in a subscription where you have permission to do so. Give the first identity Reader at the resource-group scope. Give the second a narrowly selected resource role. Verify what each can see or change. Record both the role definition and the assignment scope; one without the other does not explain effective access.
Now move the role assignment to a wider scope in a nonproduction exercise and compare the reach. An identity with Contributor on a resource group has a different blast radius from Contributor on a subscription. Contributor also cannot assign Azure RBAC roles, while Owner can. This distinction matters in administrative change control, not just on an exam.
Now test a separate governance rule. If the lab subscription has appropriate permission, inspect its parent management-group hierarchy and note which policy assignments flow into the subscription. Assign an appropriate Azure Policy definition with an audit effect to a disposable resource group, create a resource that violates the rule and inspect the compliance result. An audit records noncompliance without denying deployment; a suitable deny policy can block the same kind of noncompliant request. Record which result came from policy evaluation rather than RBAC authorization.
Apply a CanNotDelete lock to a disposable resource and test deletion with an identity otherwise authorized to delete it. The operation should be blocked until an authorized administrator removes the lock. A resource lock constrains control-plane management actions; it does not grant a missing role or universally protect data-plane operations. Apply an owner tag and retrieve the tagged resource in an inventory query. Tags help organize assets but are not access-control permissions.
Finally, create a resource-group cost budget with a notification threshold and confirm its scope, recipients and cost reports. Budget alerts do not automatically stop consumption, and cost reporting may lag usage. Review an Azure Advisor recommendation and explain which cost, reliability or security decision it would change before applying it.
Add an access-failure scenario: the test identity can see a storage account’s settings but cannot read its blobs. Determine whether the missing permission is in the management plane or data plane. Test the smallest supported Storage Blob Data role instead of granting Owner, and check whether account keys and Shared Key authorization are allowed before treating management and data access as completely separate.
Treat storage decisions as recovery and access decisions
Deploy a test storage account with deliberately selected redundancy and secure-access settings. Compare which operations concern the storage account itself, which concern a container or share, and which concern a particular blob or file. Test the effect of a shared access signature with a short expiration; it is not equivalent to distributing the account key.
Practice enabling blob soft delete, versioning and lifecycle management where supported. Create and modify a test object, then verify which recovery action restores the needed state. Document the difference between protecting an individual object and recovering an unavailable service. Redundancy improves resilience to particular failures, but it is not a substitute for a tested restore plan.
Include one negative test. Restrict access, attempt a read from an unauthorized context and check the actual response. A secure-storage configuration is not proven by what its portal checkbox says; it is proven by access behaving as intended.
Deploy compute using the right control surface
AZ-104 spans more than virtual machines. The published outline includes VM sizing, disks, availability options, scale sets, Azure Container Instances, Container Apps, registry operations and App Service. Your goal is to know which resource you manage and what operational responsibility follows. Use a small, bounded exercise for each compute model:
- VM: choose a size for a stated workload, inspect disks and the network interface, and verify its availability placement.
- App Service: deploy a trivial application, change one environment setting, and verify what a deployment slot changes.
- Container workload: identify where the image is stored, how the container receives configuration, and which scaling mechanism applies.
Repeat one small deployment through an ARM template or Bicep file. Make one controlled change, preview or validate the deployment, and confirm that the resulting resource configuration matches the intended change. This exercise reveals a useful boundary: an infrastructure file can declare resources consistently, but it does not remove the need to verify identity, connectivity and application health after deployment.
Diagnose a network failure rather than memorizing network diagrams
Build two small nonoverlapping virtual networks in a sandbox, or document the expected result if resource limits prevent deployment. Plan address spaces before configuring peering. A network peering relationship is not automatically transitive: two spokes connected to one hub cannot be assumed to reach one another through that hub without explicit routing or an intermediary.
For a failed VM connection, first establish the intended source, destination address and port. Check the destination IP, subnet and NIC; then examine the effective route and its next hop. Evaluate effective NSG rules on the relevant interfaces before changing any firewall. If a host name is involved, compare the name-resolution answer with the destination you expected.
Use Network Watcher’s diagnostic tools to collect evidence instead of editing multiple settings at once. An effective-route table answers where Azure intends to send traffic. A connection test gives evidence about reachability. A DNS lookup answers which address the client will attempt. These observations isolate different causes and can disagree without any of them being wrong.
Make monitoring useful before something fails
Create one measurable operating objective for a sandbox workload, such as successful requests, VM availability or a storage access failure. Identify the relevant metrics, logs and alert criteria. Connect the alert to an action group and test how an operator would distinguish a genuine problem from expected background activity.
Then design a backup exercise. Select a resource and protection policy, confirm a recovery point exists, and perform a restore in a safe test location. Record how long recovery took, what data state was restored and which dependent settings need separate recovery. Azure Backup and Azure Site Recovery address different recovery scenarios; neither should be chosen simply because its name sounds comprehensive.
Monitoring tests whether an operator recognizes a failure, identifies a useful metric or log and alerts someone who can investigate the cause.
Recovery tests a different outcome: whether the team restores the required service or data state, checks application dependencies and proves that the recovered workload actually functions.
Use a study schedule that follows observed gaps
Use this six-week sequence as a flexible series of tasks, each ending with evidence you can inspect. If your initial diagnostic shows that one area is already familiar, move that practice time to a weaker domain. Advance when you can produce the result in the last column, not simply because another week has elapsed.
| Stage | Study work | Evidence of progress |
|---|---|---|
| Week 1 | Read the current five-domain blueprint; test baseline skills | Objective-by-objective gap register |
| Week 2 | Identity, subscriptions, policy and storage permissions | RBAC scope, Policy compliance, lock, tag and budget evidence |
| Week 3 | Storage resilience, data lifecycle and restore | Version recovery and short restore note |
| Week 4 | VMs, templates, containers and App Service | Reproducible deployment plus configuration verification |
| Week 5 | VNets, peering, routes, DNS, NSGs and connectivity | Fault-isolation worksheet with observed evidence |
| Week 6 | Azure Monitor, alerts, backup and mixed-domain practice | One alert exercise, one recovery exercise and an error log |
Keep short notes on failed attempts. For each error, write the assumed behavior, the actual result, the source used to correct your assumption and the test that would catch it next time. Return to that error log during mixed-domain practice. Repeating a memorized answer is less useful than showing that your explanation now survives a different scenario.
Decide readiness from the decisions you can defend
Readiness means being able to select a resource or control, explain why another plausible choice is weaker, configure the choice and verify the outcome. Test yourself on a scenario combining storage, identity and networking. For example: a service must read private blobs from a specific storage account, accept only authorized connections and produce an actionable failure alert. Can you choose the identity and data permissions, network path and monitoring evidence without granting broad access?
Use Microsoft’s free practice assessment to identify missing knowledge, but do not reduce readiness to one percentage. Practice assessments and the exam sandbox help you prepare for the question format; they do not prove that a lab has been mastered.
Once you have evidence for the operational tasks, check Microsoft’s Azure Administrator Associate certification page for current booking and renewal information. Microsoft presently lists 100 minutes for the AZ-104 assessment; overall seat time and any lab arrangements may differ under the exam policies.
Recheck the exam code, language, candidate policies and latest skill changes before scheduling. An administrator who can explain a permission, a route, a recovery choice and the evidence behind each decision is better prepared for new scenarios than someone who only remembers portal navigation.