Microsoft AZ-104 Study Plan: A Domain-by-Domain Sequence

A useful Microsoft AZ-104 study plan should resemble the work of an Azure administrator, not a tour through a list of services. Microsoft’s current blueprint is organized around identity and governance, storage, compute, virtual networking, and monitoring and maintenance. The first four are tightly connected, while the fifth tests whether you can operate and recover what you built. Studying them in an intentional sequence makes later scenarios easier because each new domain can reuse controls learned earlier. The Microsoft AZ-104 learning center maps the corresponding technical guides and practice tests; use it to find the right resources as you move through the phases below.

The goal is not to spend the same number of days on every domain. Microsoft weights identities/governance and compute most heavily, storage and networking close behind, and monitoring/maintenance somewhat lower. Use those weights as a planning signal, then adjust for your own weaknesses. A network engineer may need more practice with storage and governance; a systems administrator may need more work on Azure networking and platform services.

Phase 1: establish the Azure control plane before memorizing services

Begin by making sure you can navigate the hierarchy and operating model: tenant, management group, subscription, resource group, resource, region, availability zone, and Microsoft Entra identity. You should understand what changes at each scope and which controls inherit. Without that foundation, later questions about RBAC, policy, networking, or deployment become guesswork.

Use the portal for orientation, but do not make the portal your only interface. Repeat simple administrative tasks with Azure CLI or PowerShell, and read ARM or Bicep examples so that you recognize declarative deployment patterns. AZ-104 is an administrator exam; operational fluency across interfaces matters more than memorizing where a portal button happens to sit.

At the end of this phase, you should be able to explain where a setting lives, who can change it, and what downstream resources it can affect.

Phase 2: learn identities, RBAC, policy, and governance as one system

Move next into the identities and governance domain because it influences every later lab. Practice users and groups, role assignments, scope inheritance, subscriptions, management groups, Azure Policy, resource locks, and tagging. Do not study those as separate vocabulary lists. Build a small environment where different users need different administrative rights, then enforce configuration standards and protect a critical resource from accidental deletion.

Authorization becomes clearer when Azure RBAC and least privilege are studied alongside Azure Policy, locks, and resource governance. RBAC answers who can perform an action; Policy evaluates resource configuration; locks protect against specific management changes. For every lab, state the scope before applying the control.

To test this phase, diagnose why a user can or cannot perform an action and whether the fix belongs in Entra identity, an Azure role assignment, policy, or a resource-level configuration.

Phase 3: build storage around access, durability, and network boundaries

Storage becomes easier when you organize it around decisions. First choose the service and data pattern: blobs, files, or another storage capability. Then consider redundancy and lifecycle. Next decide how clients authenticate and what authorization model applies. Finally decide whether access is public, firewall-restricted, or private.

Practice storage accounts with different redundancy choices, blob containers, Azure Files, access controls, shared access signatures where appropriate, lifecycle rules, and network restrictions. Add an AzCopy or Storage Explorer task so that data movement is part of the lab rather than an isolated fact.

When reviewing, do not ask only “What is GRS?” Ask which failure or availability requirement makes a redundancy choice appropriate, what changes if a private endpoint is introduced, and how the identity accessing the data receives authorization. That style of questioning turns storage knowledge into exam reasoning.

Phase 4: deploy compute and deliberately change the constraints

Compute should be learned through comparison. Deploy a virtual machine, then examine availability, disks, extensions, identity, networking, and backup. Work with a scale set to understand elasticity. Then contrast that with container workloads and App Service so you can explain why a scenario would favor one operating model over another.

For infrastructure deployment, practice reading and modifying ARM templates or Bicep rather than only clicking through creation wizards. For App Service, include deployment slots, configuration, TLS/certificates, networking, and scaling. For containers, focus on the administrative responsibilities named by the blueprint rather than trying to become a Kubernetes specialist.

Use each lab to generate “what changes if…” questions. What changes if the application cannot have a public endpoint? What changes if instances need to scale? What changes if a workload identity must access another Azure service? This is more valuable than repeating identical deployments.

Phase 5: make networking the connector between the previous domains

Study virtual networking after you already have identities, storage, and compute to connect. Build a virtual network with multiple subnets, apply NSGs, connect resources, configure peering, and examine routes. Add DNS, private endpoints, and a load-balancing scenario. The point is to trace traffic from a source to a destination while accounting for security and name resolution.

Private connectivity is particularly useful because it forces several domains to interact. A storage account or application can have the correct permissions and still be unreachable because the network or DNS path is wrong. Working through private endpoints and DNS troubleshooting teaches you to trace name resolution, routing, network controls, destination configuration, and authorization as one path.

By the end of this phase, you should be able to draw a packet path, explain where it can be filtered or misrouted, and identify which Azure tool gives evidence about the problem.

Phase 6: add monitoring, backup, and recovery to every lab

Do not study monitoring as a final list of features. Return to the resources you already deployed and instrument them. Enable diagnostic settings where appropriate, inspect metrics and logs, create an alert, query Log Analytics, and use network diagnostics for a connectivity problem. This creates a direct relationship between a failure and the evidence that reveals it.

Protection and recovery should be added to every lab. Back up a supported workload, reason about restore, then compare that requirement with replication or disaster recovery. Azure Backup and Site Recovery make more sense when learned through the failure being protected against and the recovery workflow expected afterward.

A strong administrator can answer three questions for any important resource: how is it monitored, how is a problem detected, and how is the workload recovered when prevention fails?

Use integrated scenarios for the final third of your preparation

Once each domain is independently usable, stop studying them in isolation. Build scenarios that cross at least three domains. For example, deploy an application into a subnet, grant it access to storage with least privilege, remove unnecessary public access, configure private connectivity and DNS, enable monitoring, then create a recovery plan. Break one dependency at a time and diagnose it.

This is also the right stage to use practice questions as diagnostics. Record why an answer was wrong: missing fact, wrong scope, confused control, weak dependency reasoning, or rushed reading. A score alone does not tell you what to repair.

Maintain a short error log and revisit the pattern, not only the original question. If you repeatedly miss scope, do new RBAC and policy scenarios. If private access causes mistakes, rebuild the DNS and endpoint path. If monitoring answers blur together, start from failure symptoms and identify the evidence source.

In the final stage, stop treating labs as isolated successes. Combine them. Deploy a workload, assign access with least privilege, place it on the intended network path, protect the storage it consumes, enable monitoring, and define what happens if the workload or data becomes unavailable. Then change one requirement: make access private, move the resource to a different scope, add a policy restriction, rotate an identity, or introduce a recovery target. The value comes from seeing which other controls must change with it.

Use domain weights as a prioritization tool, not a study-time formula. A heavily weighted domain that is already strong may need less repair than a lower-weight domain where you repeatedly miss scenario decisions. Track mistakes by cause—scope, identity, storage access, compute configuration, network path, monitoring evidence, or recovery design. That produces a study plan driven by observed weaknesses instead of by chapter order.

When you can explain the purpose of a control, configure it, validate it, and troubleshoot a realistic failure without depending on step-by-step instructions, that skill is ready for maintenance rather than more foundational study. Redirect the saved time into integrated scenarios and the specific weak domains your evidence identifies.

Finish with a domain-weighted readiness check

In the final review, use the current blueprint rather than a generic “Azure administrator” checklist. For identities and governance, prove that you can reason about Entra, RBAC, policy, locks, subscriptions, and resource organization. For storage, prove access, redundancy, lifecycle, and network controls. For compute, prove deployment, availability, scaling, containers, and App Service. For networking, prove segmentation, peering, routing, DNS, private connectivity, and load balancing. For monitoring and maintenance, prove evidence collection, alerts, network diagnostics, backup, and recovery.

The Microsoft Certified: Azure Administrator Associate credential provides role context, but the current AZ-104 blueprint should determine the learning sequence. The goal is not to finish every Azure tutorial; it is to operate an environment independently across identity, governance, storage, compute, networking, monitoring, and recovery, and to explain how those areas interact.

A good AZ-104 plan therefore becomes progressively less linear. Early study establishes individual controls; middle study builds each domain; late study combines them. That progression is closer to both the exam and the job than a chapter-by-chapter service catalog.