Microsoft AZ-104: Five Domains Through Administrator Tasks

Microsoft AZ-104 is easiest to understand as a set of administrator responsibilities that meet in one environment. A role assignment affects whether an application can read storage; a network policy affects whether the application can reach its endpoint; monitoring determines whether an operator notices the resulting failure. This guide turns the current five Microsoft objective groups into an operations-acceptance exercise rather than another product-by-product syllabus list.

As of Microsoft’s April 17, 2026 study-guide version, the domains cover identity and governance, storage, compute, virtual networking, and monitoring and maintenance. Their percentages guide where to study, but an administrator’s work cannot be divided into independent exam chapters. Use a disposable subscription, synthetic records and a small application. Preserve the original resource configuration and the ability to roll back tests. The result should be a repeatable record of what was intended, what happened and how a failure was repaired.

Identify the administrative boundary before creating anything

Start with a resource group, a service owner, a deployment operator and a support analyst. Decide which identity may create resources, which identity may view telemetry and which identity may access data. Microsoft Entra identity membership and Azure role-based access control assignments answer related but different questions. A subscription Contributor assignment, for example, does not automatically authorize reading blob contents through the Azure Storage data plane.

Write a permission test before assigning broad roles. Can the support analyst view a resource’s configuration? Can the application read one private container? Can an ordinary user modify resource-level access? Where an action fails, record the principal, scope, role and exact operation rather than assuming the problem is a bad password. Azure Policy evaluates resource configurations; RBAC authorizes operations; resource locks constrain supported management actions. None of those controls replaces the others.

Choose storage from access and recovery requirements

Consider an application that stores private documents and exposes a small shared file workspace. Blob objects and SMB file shares offer different access and operating semantics. Start with data access pattern, protocol, expected operations, throughput, retention and recovery. Use Azure Blob Storage for object data when its access model fits; do not treat an object URL as a mounted file-share path.

Configure a synthetic blob read with one least-privilege data role and verify the client obtains a token for the intended resource. Then test the private endpoint and DNS path, distinguishing a 403 authorization result from a connection timeout. Show how soft delete, versioning or backups would restore a deliberately replaced test object, and specify which feature covers accidental deletion versus a regional outage. Redundancy alone does not guarantee historical version recovery or application consistency.

Deploy compute with identity, capacity and repair in mind

The compute objective is not satisfied merely because a virtual machine or web app has a running state. For an Azure VM, decide the supported image, disk, availability and patch policy; monitor guest as well as platform health. For application workloads, consider App Service, container options or VMs based on operating control, scale, deployment responsibilities and budget. A managed service reduces some infrastructure tasks but does not absolve the customer of application, data or identity configuration.

In the lab, give an application a managed identity and one expected storage operation. Deliberately remove the required role and observe the failure; then restore the minimal permission. Capture a successful and a failed transaction, not just a green portal tile. Document what would happen if a supporting key, secret, certificate or external service changed independently of the compute deployment.

Trace a network failure through the correct layer

Suppose a private-storage hostname unexpectedly resolves to a public address. Before changing an NSG rule, check the application’s DNS resolver, private DNS zone link and network path. Routes select next hops; NSGs filter allowed flows; application listeners accept requests; they are not interchangeable. A broad allow rule cannot fix a nonexistent private DNS record and may create a second security issue while leaving the first failure intact.

For a virtual-machine-to-API test, record source and destination IPs, port, expected DNS resolution, effective route, NSG evaluation and the service’s listening state. Azure Load Balancer health probes are another potential source of failure: a backend can accept local traffic and still be excluded if the probe reaches a different port or route. Use Network Watcher connection troubleshoot, IP flow verify and next hop for distinct diagnostic questions. For new flow-logging deployments, use Azure virtual-network flow logs rather than retired-for-new-creation NSG flow logging.

Use monitoring evidence to validate remediation

Azure Monitor metrics, resource logs and application traces capture different kinds of events. A spike in VM CPU utilization may explain a slow workload but will not establish why one identity received a 403 or one DNS name resolved incorrectly. Design an alert around a supported failure signal and associate an action group with a responder who can investigate. Test notification delivery in a nonproduction environment so the response plan is evidence-based.

A lab should include one alert with a stated threshold and an expected firing condition. Record which metric or query supports the condition, the evaluation interval, the observed alert state and the first safe diagnostic step. Read the Azure Monitor alerts and action groups subject when the issue is notification behavior; do not assume a dashboard that displays a metric will notify the right person without an alert rule.

Recovery is a verified result, not an enabled checkbox

An Azure Backup policy, replication setting or snapshot proves that a mechanism was configured. It does not by itself prove that an application could be restored within an acceptable time or with consistent data. Define recovery objectives for the fictional application. Create a recovery point, simulate a recoverable fault, and restore to an isolated target. Then verify service reachability, identity, data content and any necessary DNS or application configuration.

Keep the distinction between a VM restoration, a file restoration and application recovery. For a stateful system, the desired restored time may require coordinating databases and external dependencies. Document the chosen point-in-time and whether recent legitimate writes were intentionally discarded. This is closer to an administrator’s accountability than simply memorizing a backup product’s feature list.

Automate the repeatable parts, not unreviewed assumptions

PowerShell, Azure CLI and Bicep help make deployments consistent and auditable. Begin by encoding the intended resource boundaries, parameters, names and identities in version-controlled files. Make changes in a test scope first and review the deployment preview for unintended role or network changes. Avoid granting scripts unrestricted subscription permissions just to eliminate configuration errors.

A successful automation run should leave an observable state: the correct access scope, configuration, enabled monitoring and a passing synthetic transaction. A failed run must be diagnosable and, where supported, reversible. Store secrets outside scripts and ensure a colleague can distinguish an expected idempotent rerun from a partial deployment needing human intervention.

Finish with five cross-domain acceptance tickets

Use five short tickets to test readiness. Ticket one: a new team member can view a service but not modify it. Ticket two: an application can read only the intended private blob. Ticket three: a scale or deployment event keeps the synthetic transaction healthy. Ticket four: a private connection fails and is repaired without opening unnecessary network access. Ticket five: a backup restores a known document with a recorded recovery time. For every ticket, write the initial requirement, observed evidence, minimal correction and final acceptance proof.

The current AZ-104 exam studies the Azure administrator’s ability to manage systems across these layers. This article is an operational acceptance framework, distinct from a quick domain outline and from a dedicated network-troubleshooting tutorial. Before booking, confirm the live Microsoft study guide and official exam delivery information. The strongest preparation is a set of actions you can perform, explain and safely reverse—not a count of features you have seen in the portal.

• Category: All Certifications Microsoft
• Tags: AZ-104, AZ-104 dumps, AZ-104 exam