AZ-104 in 2026: The Azure Administrator Role From Identity to Recovery

Microsoft AZ-104 remains Microsoft’s active exam for Azure Administrator Associate in 2026. The current blueprint, measured as of April 17, focuses on identity and governance, storage, compute, virtual networking, and monitoring and maintenance. Those domains are not separate in real work; they interact every time an administrator deploys or troubleshoots an Azure workload.

Candidates preparing for Microsoft AZ-104 should be comfortable with the Azure portal, PowerShell, Azure CLI, ARM templates or Bicep, and Microsoft Entra ID. More importantly, they should understand how scope, identity, network paths, resource configuration, monitoring, and recovery fit together.

The Azure Administrator Associate role is operational. You are expected to implement and manage an environment, work with adjacent specialists, and diagnose problems with evidence. That makes AZ-104 much more than a portal-navigation exam.

A strong study plan therefore uses one integrated lab instead of dozens of isolated demos. Build the environment, secure it, monitor it, recover it, and explain why each control exists.

An administrator’s change ticket, from access request to recovery

A more realistic way to understand the Azure Administrator role is to follow one ordinary change from the initial request through operation and handoff. Imagine an internal claims application being moved to a new Azure resource group. The ticket states that operators need limited management access, the application must use a managed identity to read a storage container, users connect privately from the corporate network, and the service must be monitored and recoverable. The request crosses every AZ-104 domain, but each decision has a different owner and a different form of evidence.

Before deployment: clarify the boundary

The administrator asks who approves the change, which subscription and resource group own the assets, and who may alter production configuration. Assigning Owner at subscription scope would be easy to explain but difficult to justify for a team that only needs VM and log access. Use a group-based assignment and the narrowest appropriate scope. Confirm effective access with an actual test rather than assuming that group membership or a displayed role name proves all permissions.

The application identity is a separate concern. A managed identity may avoid application credentials stored in code, yet its existence alone does not authorize data reads. The workload must have the necessary data role at a suitable scope, and the target service must be reachable. A good change ticket keeps these identity and network checks separate so the next operator does not respond to a 403 error by widening firewall access or to a timeout by granting extra roles.

During deployment: prove the requested service path

After applying a reviewed ARM or Bicep deployment, record which resources were created and whether the platform reached its declared state. Then test the operation users actually require. From an authorized client, resolve the application and storage hostnames, check the expected private endpoint addresses where applicable, confirm the network path, and perform a permitted read. A green deployment notification is not the same as an end-to-end success.

Ask another administrator to trace the same request from the diagram: client to DNS, DNS to address, address through routing and filtering, then authentication and data access. If the diagram cannot explain a failed request without trial-and-error permission escalation, the handoff is incomplete. The AZ-104 hands-on scenarios offer additional safe exercises for these dependencies.

After deployment: take operational ownership

Operational responsibility begins when the initial release has passed. Configure a signal that reveals failure from the user’s perspective, decide whether metrics or logs provide the best evidence, and give the alert a recipient and escalation action. An alert that fires but has no accountable owner is not an operating control. Record expected steady-state behavior so a future spike in errors or latency can be judged against something more informative than intuition.

Protection is the last part of the ticket, not an optional appendix. Specify which files, configuration and workload state must be recoverable, confirm a supported Azure Backup method where appropriate, and execute a small authorized restore of test data. Note the elapsed time, required permissions, and missing dependencies. A restored VM that cannot authenticate, resolve its service name, or reach storage is not a restored application.

The handoff document is the deliverable

Handoff item	Evidence	Owner after release
Scope and permission	Approved role assignments and observed allow/deny tests.	Identity or subscription administrator.
Workload and data path	Deployment record, service diagram and successful request trace.	Application owner with cloud operations support.
Health and incident response	Alert definition, diagnostic source and escalation route.	Named support rotation.
Recovery	Protected resources, tested restore procedure and dependency checklist.	Service owner and recovery operator.

The important skill is being able to continue after the person who created the resources leaves the room. A role-based certification maps neatly to that responsibility: work has to remain understandable, operable and recoverable. This operational handoff angle is different from a credential fact sheet or a simple domain-by-domain learning order. Use the Azure troubleshooting incident for a more detailed failure investigation once the environment is running.

Identity and governance define who can change Azure

Azure administration begins with scope. Management groups, subscriptions, resource groups, and individual resources form a hierarchy through which access and policy can be applied. Administrators need to know how those scopes inherit permissions and governance.

Microsoft Entra users, groups, service principals, and managed identities provide identities. Azure RBAC determines what those identities can do at Azure scopes. Azure Policy evaluates or enforces resource rules. Locks protect against certain changes but do not replace identity or policy.

Practice by assigning roles at different scopes and testing the result. A user who can read a subscription should not automatically be able to change every resource. A managed identity can exist correctly and still fail because it lacks the data-plane or management-plane permission it needs.

The durable skill is being able to separate authentication, authorization, policy, and resource organization rather than treating access as one setting.

Also learn to recognize the difference between governance intent and technical implementation. A company may require all production resources to use approved regions and tags, but the administrator still has to decide whether policy should audit, deny, or remediate the condition and at which scope the rule belongs.

Storage administration combines data behavior with access controls

AZ-104 includes Blob Storage and Azure Files because administrators need to configure storage for applications and users. The operational questions include account type, redundancy, access tier, lifecycle, network exposure, identity-based access, shared access signatures, encryption, and recovery.

Start from the workload. Object data, shared files, and VM disks have different access patterns. Then decide how clients should authenticate and which network path is allowed. The AZ-104 storage scenarios are useful because they connect account configuration with permissions, networking, and operational recovery.

In a lab, restrict a storage account, grant access through a managed identity, and verify both success and denial cases. Then test versioning, soft delete, or another recovery mechanism so storage protection is more than a checkbox.

Storage administration also includes performance and cost awareness. A technically valid account can still be the wrong design if transaction volume, access frequency, or network placement makes the workload slow or unnecessarily expensive.

Compute administration is a lifecycle, not a deployment event

Virtual machines, scale sets, App Service, and containers appear in AZ-104 because administrators need to operate compute after it is created. Sizing, availability, disks, networking, identity, extensions, scaling, patching, and monitoring all influence the workload.

Deploying a VM successfully is only the first step. The administrator should know how the machine is reached, how updates are handled, how disks are protected, which identity the workload uses, and which signals reveal performance or availability problems.

Infrastructure as code is useful because it makes deployment repeatable. Recreate the same environment with Bicep or an ARM template and compare the declarative resource model with one-by-one portal changes.

Also compare compute models. A VM offers more control and more responsibility, while managed platforms remove some infrastructure work. The exam often rewards understanding that operational model rather than memorizing one preferred service.

Lifecycle thinking should include scale-down and removal too. Orphaned disks, unused public IP addresses, stale extensions, or forgotten development VMs can create cost and security problems long after the original deployment task is complete.

Virtual networking should be traced from source to destination

Azure networking questions become easier when you draw the traffic path. Identify the source, destination, DNS resolution, subnet, route, network security group, peering, private endpoint, load balancer, or gateway involved.

Then change one condition at a time. A denied NSG rule creates a different failure from a wrong route. Private access can fail because of DNS even when authentication is correct. Peering connects virtual networks but does not automatically make every topology transitive.

Strong administrators isolate the layer before making changes. That reduces accidental fixes that hide the original problem and makes troubleshooting repeatable for the next incident.

Keep a simple network diagram in the lab. Mark subnets, routes, private endpoints, DNS dependencies, and public exposure. When a scenario changes, update the diagram first and predict the result before opening the portal.

Monitoring should answer a specific operational question

Azure Monitor, metrics, logs, diagnostic settings, Log Analytics, alerts, action groups, and resource insights provide many signals. Administrators do not need to collect everything; they need to know what evidence is required to operate the workload.

Create an alert tied to a measurable condition and route it to an action group. Send diagnostic data to a Log Analytics workspace and use KQL to answer a small troubleshooting question. Compare resource metrics with logs so the distinction becomes concrete.

Monitoring design should also consider noise and cost. Alerts that fire constantly are ignored, while unlimited log collection can become expensive. Every alert should have an owner and an expected response.

A good lab includes a controlled change that triggers the alert so you can verify the full path from condition to notification and recovery.

Trend analysis is valuable too. A workload can remain available while latency, capacity use, or error rate slowly deteriorates. Administrators should learn to recognize degradation before it turns into an outage.

Backup and recovery are verified outcomes

Azure Backup and Site Recovery support different continuity needs. A successful backup job does not prove that a workload can be restored within the time the business expects.

Administrators should understand retention, restore points, vault behavior, recovery objectives, and the dependencies required after a restore. A VM or data store may come back while DNS, identity, network rules, or application configuration still prevent users from working.

Perform an actual restore in a lab and document the steps. Measure how long it takes and which permissions are required. If recovery depends on undocumented knowledge held by one person, the process is not mature.

This evidence-based approach turns continuity from a configuration topic into an operational responsibility.

Use failure scope to choose the mechanism. Restoring one file, recovering a deleted VM, and failing over an application to another region are different problems. The administrator should be able to explain which Azure capability addresses each one.

Automation matters when administration must scale

PowerShell, Azure CLI, Bicep, templates, and automation help administrators apply repeatable changes across environments. The goal is not to eliminate graphical tools; it is to know when repeatability, scale, or auditability makes automation the better choice.

Start with inventory and simple changes. Query resources, inspect configuration, create a resource group, or assign a role through a script. Then compare the result with the portal so you understand the same Azure resource model behind both interfaces.

Automation should also include error handling and scope control. A script that can change hundreds of resources needs stronger validation than a manual change to one development resource. The AZ-104 study method article shows how to connect those tools into one integrated preparation environment rather than learning commands in isolation.

Keep scripts and templates under version control where practical. That makes changes reviewable, creates a history of the environment, and reduces the risk of relying on one administrator’s local files.

AZ-104 readiness means operating the environment through change

A strong candidate can take an unfamiliar Azure scenario, identify the controlling layer, make a reasoned change, and explain how to verify the outcome. That is more durable than memorizing hundreds of portal locations.

Before the exam, rebuild a small environment from a clean starting point. Configure governance, identity, storage, compute, networking, monitoring, and recovery. Use both graphical and command-line tools. Then introduce several controlled faults and diagnose them without changing multiple settings at once.

After AZ-104, the Azure solutions architecture is one possible direction, while networking, security, development, and DevOps are others. The next credential should follow the work you want to own.

The administrator foundation remains valuable in every direction because operational consequences teach you how cloud designs behave after deployment.

Document the final lab like a production handoff: architecture, identities, dependencies, monitoring, backup, deployment method, known risks, and recovery steps. If another administrator can operate the environment from those notes, your preparation is close to the real role.