Microsoft AZ-104: Administering Azure Across Identity, Compute, Storage, and Networks

Microsoft AZ-104, Microsoft Azure Administrator, remains the core exam for Microsoft Certified: Azure Administrator Associate. The current English blueprint, updated April 17, 2026, measures administration across identities and governance, storage, compute, virtual networking, and monitoring. The role is operational: candidates are expected to implement, manage, and observe an Azure environment rather than merely recognize cloud concepts.

The Azure Administrator Associate credential sits at the center of several Azure career paths because administrators touch the controls that other roles depend on. An architect may design a network, a developer may deploy an application, and a security engineer may define controls, but the administrator often implements or maintains the resources those designs require. That makes AZ-104 broad by design.

Preparation should be built around change and troubleshooting. A candidate who can create a virtual network from memory but cannot diagnose why a workload cannot reach a private endpoint is not finished. Strong labs should include misconfiguration, permission failures, capacity constraints, broken name resolution, unhealthy resources, and recovery tasks. The exam rewards understanding of how Azure components interact.

Identity and governance determine who can change the environment

Azure administration starts with Microsoft Entra ID, role-based access control, subscriptions, resource groups, policy, locks, tags, and governance structures. These controls answer different questions. Identity establishes who or what is making a request, RBAC determines permitted actions at a scope, policy evaluates resource configuration, and locks protect resources from specific management-plane changes.

The Entra ID and Azure governance material is useful for practicing those distinctions. Build a resource group where one user can manage virtual machines but cannot alter networking, apply a policy that restricts a resource property, and add a lock to a critical resource. Then predict which control blocks each attempted action before testing it.

Storage administration is a mixture of durability, access, and data movement

Azure Storage questions rarely reduce to choosing a storage account. Administrators need to understand redundancy, performance tiers, blob and file services, access methods, lifecycle policies, encryption, network restrictions, shared access signatures, identity-based access, and common transfer tools. The right design depends on both workload behavior and operational requirements.

Use the Azure storage scenarios for AZ-104 to compare two scenarios: one requiring low-cost archival with controlled retrieval and another requiring shared file access from distributed workloads. Add a network restriction and test access through identity and SAS mechanisms. The objective is to understand why a configuration works, not just how to create it.

Compute administration requires lifecycle thinking

Virtual machines, scale sets, App Service, containers, and related compute options expose different operational models. Administrators should be able to deploy resources, change size or capacity, manage disks and extensions, configure availability, apply updates, and recognize when a platform-managed service changes the responsibilities compared with a VM-based design.

The AZ-104 compute coverage is most useful when turned into failure scenarios. Create a VM that fails to boot because of a configuration issue, a scale set that needs capacity adjustment, and an App Service deployment that must be rolled back. For each one, identify the management plane, health signals, and recovery path.

Virtual networking is where isolated settings become one system

Address spaces, subnets, network security groups, route tables, peering, private endpoints, DNS, load balancing, and hybrid connectivity interact. A network can look correct at one layer while traffic still fails because a route, name-resolution path, security rule, or endpoint configuration is wrong. That is why networking deserves scenario-based practice rather than isolated definitions.

Work through virtual networking for AZ-104 with a three-subnet lab. Put an application in one subnet, a data service behind a private endpoint in another, and an administrative host in a third. Then deliberately break DNS, an NSG rule, and a route one at a time. Diagnosis becomes easier when you learn to trace traffic in layers.

Monitoring should connect signals to an action

Azure Monitor, Log Analytics, alerts, metrics, activity logs, and diagnostic settings are most useful when administrators know what question each source can answer. Resource metrics can show performance, the activity log can show management-plane changes, and collected logs can expose application or platform details. Good monitoring design starts with an operational question rather than enabling every signal indiscriminately.

Create an alert for a meaningful threshold, route it to an action group, and then verify what happens when the condition clears. Add diagnostic settings to a resource and query the resulting logs. The exercise should end with a decision: scale, investigate, restart, change a policy, or do nothing. Monitoring without a response model produces noise rather than operational control.

Backup and recovery should be tested as restoration, not configured as a checkbox

Administrators need to understand how Azure Backup and recovery services protect workloads, what retention settings mean, and how recovery requirements affect configuration. A successful backup job is not proof that a business process can recover. Recovery time, recovery point, permissions, network dependencies, and application consistency can all determine whether a restore is actually usable.

Build a small recovery exercise for a VM or protected data set. Delete or corrupt something intentionally, restore it to an alternate location, and verify application access. Document which identity performed the restore and which dependencies had to be recreated. This turns backup from a passive status indicator into an operational capability.

Infrastructure as code belongs in an administrator’s toolkit

The current AZ-104 role expects familiarity with Azure Resource Manager templates or Bicep in addition to the portal, PowerShell, and Azure CLI. Administrators do not need to become full-time platform engineers to benefit from declarative deployment. Reusable definitions make common environments easier to reproduce, review, and repair.

Take a resource group you previously built manually and represent the essential resources in Bicep. Deploy it to a second environment with parameters, then make a controlled change through code. Compare that with an untracked portal change. The exercise shows why source-controlled infrastructure reduces configuration drift and makes operations easier to audit.

Troubleshooting should move from symptoms to the controlling layer

Many AZ-104 questions are easier when the candidate first identifies the layer that can cause the symptom. An authorization error points toward identity, scope, or role assignment. A connectivity problem may involve DNS, routing, NSGs, endpoints, or service configuration. Poor VM performance may involve size, disk, application load, or platform health. A denied deployment can come from policy even when RBAC allows the user to create resources.

Keep a troubleshooting journal during labs. Record the symptom, the hypothesis, the Azure evidence used to test it, and the corrective action. Over time this creates a practical map between symptoms and diagnostic tools. It also prevents the habit of changing several settings at once and losing the evidence about which change actually fixed the problem.

AZ-104 is also a foundation for architecture and specialist roles

Administration knowledge transfers directly into more advanced Azure work. The AZ-104 to AZ-305 progression shows how implementation experience supports architecture decisions. An architect who has administered storage, networks, identities, and recovery systems can reason more realistically about operational tradeoffs and failure modes.

The AZ-104 and AZ-700 role differences illustrates another direction: a broad administrator may later specialize in networking. The same is true for security, DevOps, databases, and virtual desktop operations. AZ-104 is valuable because it builds a working model of Azure that those specialties can deepen.

A final readiness lab should combine the domains. Deploy a small application environment with identity controls, storage, compute, networking, monitoring, and backup. Then introduce several faults without writing down where they are. Restore access, explain which evidence led to each diagnosis, and document the final configuration. If you can administer that environment under change rather than only create it from a tutorial, you are practicing the judgment the exam is designed to measure.

Administrators should also distinguish the Azure management plane from the data plane. A user may be allowed to configure a storage account without being able to read blobs, or may have data access without permission to change the resource itself. Similar distinctions appear across Key Vault, databases, and other services. When a permission problem occurs, first determine which plane the attempted action belongs to; otherwise it is easy to assign an overly broad role that appears to fix the symptom while weakening least privilege.

Resource organization creates another layer of operational judgment. Subscriptions, resource groups, tags, locks, and policies affect ownership, cost reporting, lifecycle, and control. Moving a resource or reorganizing a resource group can also expose dependencies that were not obvious when the environment was built. Practice by documenting who owns each resource group, how costs are attributed, which policies apply, and which resources should be protected from deletion. Administration becomes easier when structure reflects operational responsibility.

Finally, rehearse maintenance rather than only initial deployment. Rotate access, resize a workload, replace a failing VM, update a route, change a storage lifecycle rule, and validate monitoring after each change. Many real incidents occur during ordinary maintenance because dependencies were assumed rather than tested. A mature Azure administrator treats change as a controlled operation with prechecks, evidence, rollback options, and post-change validation.

Cost control also belongs in routine administration. Tags, budgets, reservations, rightsizing, storage tiers, and shutdown schedules can reduce waste, but administrators should understand the workload effect before changing capacity. Review one resource group and separate steady production capacity from burst usage, nonproduction resources, backup, and storage retention. Cost becomes easier to manage when the administrator can explain which resources are essential to the service and which exist because nobody revisited an old assumption. Document an expected monthly baseline so unusual consumption is easier to investigate.