The five AZ-104 objective groups look separate on a study guide, but they are designed around one operating environment. Identity and governance controls who can manage resources. Storage and compute host data and workloads. Networking determines reachability. Monitoring and recovery show whether the environment is healthy and how it returns to service after failure. Understanding those dependencies is more useful than treating the exam as five independent chapters.
Microsoft’s current April 17, 2026 blueprint gives the highest weighting to identities and governance and to compute, at 20–25% each. Storage and networking are 15–20% each, while monitoring and maintenance accounts for 10–15%. The weighting should influence study time, but it should not encourage candidates to ignore smaller domains. A monitoring or networking detail can be the deciding factor inside a compute scenario.
The AZ-104 exam is best approached as a set of operational relationships. The more clearly a candidate can explain why one configuration affects another, the less the exam depends on memorizing disconnected feature lists.
Identity, authorization, and governance form three different control layers
Microsoft Entra users and groups answer the question “who is the identity?” Azure RBAC answers “what may that identity do to this scope?” Governance controls such as Azure Policy, locks, tags, management groups, and cost tools answer “what conditions should apply to the environment?” Those layers work together, but they solve different problems.
A common mistake is to treat a role assignment as a general security policy. RBAC authorizes operations; it does not enforce naming conventions, required tags, allowed locations, or resource-type restrictions. Azure Policy is built for those conditions. Likewise, a resource lock does not replace RBAC: a user might have broad rights but still be blocked from deleting a locked resource until the lock is removed.
Scope connects the three layers. Management groups sit above subscriptions, subscriptions contain resource groups and resources, and assignments can inherit downward. This is why Azure RBAC should be studied together with subscription and governance hierarchy rather than as a standalone permission table.
Storage security depends on both identity and network design
The storage domain is a good example of cross-objective thinking. A storage account can be protected through keys, SAS tokens, identity-based access, firewall rules, and virtual-network restrictions. Each control operates at a different layer. An RBAC assignment may authorize a user, yet a network rule can still prevent connectivity. A shared access signature can grant tightly scoped access even when the recipient does not receive general Azure management rights.
Redundancy and data-protection features answer still different questions. Geo-redundancy addresses infrastructure failure across locations. Soft delete protects against accidental deletion. Blob versioning allows previous object states to be recovered. Lifecycle management moves data between tiers or deletes it according to policy. A resilient storage design often uses several of these together.
Working through Azure Storage configuration as a chain of access, durability, protection, and cost decisions is more useful than memorizing feature definitions one by one.
Compute depends on governance, storage, identity, and networking
A virtual machine exists inside a management hierarchy, uses managed disks, attaches to a network interface and subnet, may receive a managed identity, and produces metrics and logs. An App Service can use custom domains, certificates, deployment slots, networking integration, backups, and scaling rules. Containers depend on registries, resource sizing, connectivity, and identity. Compute therefore touches almost every other objective group.
The current blueprint also expects administrators to use ARM templates or Bicep. Infrastructure as code matters because it changes how administrators create and troubleshoot resources. If a deployment repeatedly produces the wrong configuration, the issue may be in the template rather than in the resource after deployment. ARM template deployment is therefore connected to governance, repeatability, and operational consistency, not just automation.
Availability concepts also sit inside compute. Availability sets, availability zones, Virtual Machine Scale Sets, App Service scaling, and container scaling do not solve the same problem. Some reduce the impact of host or datacenter failures; others increase or decrease capacity in response to workload. Candidates should learn the failure boundary and scaling behavior of each.
Networking is where many otherwise-correct deployments fail
Azure networking includes address spaces, subnets, peering, public IPs, routes, DNS, load balancing, service endpoints, private endpoints, Bastion, and security groups. The challenge is not remembering that each exists; it is tracing how traffic should move from a source to a destination and identifying every control along that path.
A route may send traffic to the wrong next hop. An NSG may deny the port. DNS may resolve to the wrong address. A load-balancer probe may mark a backend unhealthy. A private endpoint may be configured correctly while name resolution still points clients to the public endpoint. Each symptom requires a different diagnostic path.
Studying virtual networks, network security groups, and Azure Load Balancer together helps candidates see the complete traffic path instead of viewing those services as unrelated exam terms.
Monitoring turns symptoms into evidence
The monitor-and-maintain domain is not an appendix to the exam. It is the evidence layer for every operational problem described elsewhere. Azure Monitor metrics can show resource behavior over time, logs can expose detailed events, alerts can detect conditions automatically, and workload-specific Insights can make large telemetry sets easier to interpret.
Azure Monitor also creates a study habit that applies across the exam: define the expected state, observe the actual state, compare them, and narrow the fault domain. When a VM cannot be reached, monitoring data and Network Watcher can help decide whether the problem is compute, guest OS, routing, name resolution, or a security rule.
This evidence-first approach is especially useful in scenario questions because several answer choices may describe valid Azure features. The right choice is the one that addresses the actual failure or requirement with the narrowest appropriate control.
Backup and recovery connect architecture choices to business continuity
Recovery is another area where similar-sounding features have distinct purposes. Azure Backup creates protected recovery points and supports restore operations. Azure Site Recovery replicates workloads and orchestrates failover for continuity. Storage redundancy preserves copies of data at the storage platform layer. Availability zones reduce the impact of certain infrastructure failures. None of these is a universal replacement for the others.
Azure Backup belongs in a broader recovery conversation that begins with what must be restored, how much data loss is acceptable, how quickly service must return, and what failure is being planned for. AZ-104 does not ask candidates to build a full enterprise continuity program, but it does expect them to configure and operate the Azure services that implement those decisions.
The current blueprint’s inclusion of backup reporting and alerts reinforces the operational point: a configured backup policy is not enough. Administrators need evidence that protection is succeeding and that restores or failovers can be executed when needed.
The same relationship-based approach helps when commands or portal locations change. If you understand that a private endpoint changes the network path to a PaaS service, or that a role assignment is evaluated at a scope and inherited downward, you can reconstruct the correct administration steps even when the interface looks different. Conceptual dependencies are therefore not an alternative to hands-on practice; they are what make hands-on knowledge durable.
The objective groups meet in realistic administration workflows
Consider a simple application running on Azure virtual machines. The administrator may place the VMs in availability zones, attach managed disks, connect them to a subnet, protect inbound traffic with an NSG, distribute traffic through a load balancer, grant a managed identity access to storage, enforce policy at the subscription, monitor performance, and back up the workload. Every one of those actions belongs to a different objective group, but they describe one system.
That is the pattern candidates should practice. For each lab, identify which objective groups are participating. For each scenario, ask which layer owns the requirement: identity, authorization, policy, storage, compute, network, monitoring, or recovery. Then check whether another layer could block or modify the outcome.
The Azure Administrator Associate credential rewards that cross-domain operating model. Administrators do not need to be the deepest specialist in every service, but they do need enough breadth to recognize dependencies and coordinate effectively with networking, security, database, application, and DevOps teams.
Weight the domains, but study the boundaries between them
The published percentages are useful for time allocation. Identity/governance and compute deserve substantial attention, followed by storage and networking, then monitoring and maintenance. Yet the hardest questions often sit on boundaries: a storage-access issue caused by networking, a VM issue caused by identity, a deployment problem caused by governance, or an availability problem that requires both compute and recovery knowledge.
A strong final review should therefore include mixed scenarios rather than only domain quizzes. Build a resource, secure it, connect it, observe it, break one dependency, diagnose the result, and recover it. That workflow mirrors the administrator role much more closely than reading five separate sets of notes.
Across Microsoft certifications, AZ-104 is a broad operational credential precisely because Azure environments are interconnected. The objective groups are study boundaries, not real-world silos. Candidates who learn the connections will be better prepared both for the exam and for the work the certification is intended to represent.