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

AZ-104: Microsoft Azure Administrator tests the ability to implement, maintain and troubleshoot resources in an Azure environment. Microsoft's April 17, 2026 outline covers identities and governance, storage, compute, virtual networking, and monitoring and maintenance. Candidates need hands-on familiarity with the Azure portal, PowerShell, Azure CLI, Bicep or ARM templates, and Microsoft Entra ID. Unlike an architecture examination that asks which design should be chosen, AZ-104 asks how to deploy a justified design, manage it safely and resolve operational failures.

The most useful mental model is the lifecycle of a running workload. A virtual machine requires the right subscription, permissions, network, storage and monitoring. A change to one dependency can break a service that was otherwise healthy. The administrator should diagnose the chain rather than treating resource names as unrelated objects. This is why AZ-305 is a natural later route for someone moving from operations to architecture, while AZ-104 itself concentrates on precise management decisions.

Manage Entra identities and governance without excessive privilege

An Azure environment starts with tenant, subscription, management group and resource group boundaries. Microsoft Entra user and group objects identify people, while Azure role-based access control grants rights to Azure resources at specific scopes. A user may be present in the directory but lack permission to manage a VM; conversely, a narrowly scoped role can allow VM restart without giving authority over every subscription. Administrators must inspect effective assignments, inherited roles and restrictions before attempting broad permission changes.

Azure Policy enforces or audits resource properties, whereas RBAC determines who can perform operations, and resource locks protect against accidental changes to particular resources. These mechanisms answer different questions. A developer may have permission to create a public storage account, yet a policy can deny that configuration. A lock can prevent deletion even for a role that otherwise permits it. When a deployment fails, distinguishing Azure Policy, RBAC and resource locks prevents a dangerous workaround: first identify whether the problem is a denied configuration, insufficient role assignment or management-plane lock, then correct that specific boundary.

Governance also includes tagging standards, cost budgets, management groups and review of unused resources. A shared development subscription that never removes large VMs can exhaust a budget without a breach or outage. Set cost alerts and use Azure Advisor where applicable, but review recommendations against business context. Automated cleanup needs approval boundaries so it does not delete an active service merely because the owner failed to apply a tag. Good administration is precise enough to manage cost and risk without obstructing necessary work.

Protect Azure storage with the right access and redundancy

Azure Storage accounts support multiple service types and access mechanisms, including identity-based access, account keys and shared access signatures. Administrators should prefer least-privilege mechanisms appropriate to the workload and avoid distributing long-lived keys unnecessarily. An expiring SAS can break an integration even when the storage account is healthy. Diagnose authentication, firewall restrictions, private endpoints and token scope before recreating a resource or expanding network access indiscriminately.

Redundancy choices reflect failure tolerance. Local redundancy protects against certain failures within a location, while zone or geo strategies offer different resilience properties and costs. A backup or replication choice must match recovery point and recovery time objectives; replication alone may not protect against accidental deletion or malicious modification. Soft delete, versioning, snapshots and lifecycle policies address additional cases. For an important finance document container, test restoring a prior object and verify that retention does not conflict with legal disposal requirements.

Azure Files and Azure Blob Storage have different semantics and client requirements. A legacy file application needing SMB access is not automatically a good fit for object storage. File shares need identity and permission checks, while blob containers depend on object operations and storage tiers. Evaluate access patterns, egress charges and performance as well as price per gigabyte. A correct AZ-104 solution balances usability and protection rather than defaulting every workload to the cheapest advertised tier.

Deploy compute and automate repeatable configuration

Compute administration includes virtual machines, availability sets and zones, scale sets, App Service, container services and deployment templates. The decision begins with the workload: an existing Windows application may need a VM, a managed web API could use App Service, and a small event-driven function may require less operational overhead. The administrator must understand scaling, configuration, network dependencies and backup even when another architect selected the platform.

Infrastructure templates can make changes reproducible. ARM templates and Bicep express resources and dependencies, but using code does not automatically make deployment safe. Review parameter values, scopes, credentials and the effect of removing a resource. Use a controlled preview where possible, keep definitions in version control and deploy through a service identity with limited permissions. A reproducible mistake is still a mistake unless it is caught before production.

Virtual machine resilience needs practical testing. Availability sets, availability zones and VM scale sets provide different patterns; none replace application-level redundancy or tested recovery. When a VM fails after resizing, check disk attachment, boot diagnostics, extension health and network state rather than immediately recreating the machine. Containers introduce registry access, image integrity and scaling constraints. An operator who knows where execution logs and configuration live can isolate a problem much faster than one who only remembers a portal sequence.

Diagnose virtual network connectivity from the route outward

An Azure virtual network consists of address spaces, subnets, gateways, peering, routing and security controls. A server may have the right IP address but fail to reach a database because an effective route directs traffic to a firewall, an NSG blocks the flow, DNS resolves a public instead of private address, or a private endpoint lacks correct name resolution. Test the network path in layers and record the expected destination rather than randomly opening ports.

Network security groups filter traffic according to rules and evaluation order; application security groups can make rule targets easier to manage. Private endpoints and service endpoints solve different connectivity problems and must not be described as synonyms. Peered VNets do not magically provide full transit routing without appropriate configuration. If a hybrid client cannot reach a private service, inspect name resolution, user-defined routes, firewall logs and gateway state. Azure Network Watcher troubleshooting deepens the evidence-based approach.

Load balancing introduces health probes and backend behavior. A public endpoint may respond intermittently because the probe marks half the instances unhealthy, not because DNS is defective. Understand the distinction between internal and public load balancers and how applications respond to a removed backend. Test actual transaction flows and not just ping. Careful network investigation preserves security controls while narrowing the fault, which is preferable to a broad allow-any rule introduced during an outage.

Observe resources and restore services deliberately

Azure Monitor metrics, logs, alerts and action groups help detect problems, but administrators must choose signals relevant to the workload. CPU percentage alone can miss a storage bottleneck or a network timeout. A web service may return HTTP 200 from its health endpoint while business transactions fail. Use metrics for resource behavior, logs for events and traces or application diagnostics where they are available. Set actionable thresholds, name alert owners and reduce noisy warnings that nobody can reasonably investigate.

Backup planning should cover both service restoration and data correctness. Azure Backup and Site Recovery address different scenarios, and neither should be considered tested until a recovery exercise succeeds. Before a failover, verify dependency order, DNS or routing changes, application credentials and the recovery location's capacity. High availability and disaster recovery are related but separate goals. An available server with missing committed transactions is not a successful restoration.

A practical AZ-104 drill provisions a controlled application, applies role restrictions, stores content, places the application behind a load balancer and configures monitoring. Deliberately expire a storage token, block a subnet flow and break a health probe one at a time. Collect evidence before repairing each problem, then restore a deleted object from the documented protection mechanism. This sequence trains the administrator to identify causes across identity, networking, compute and storage rather than memorizing independent configuration screens.

A storage-restore scenario makes the interaction of Azure controls clearer. Suppose an approved automation accidentally overwrites a configuration blob used by a production API. The storage account remains online, its encryption remains active and the role assignment was valid; none of those facts prove the configuration is correct. An administrator should inspect blob versioning or backup settings, determine the last accepted version, confirm the intended access permissions and restore the object through a controlled procedure. Then restart or refresh the dependent application and verify an actual business request.

Record why the automation was permitted to write the object and whether its access could have been narrower. A resource lock might prevent certain resource-management changes but not every data-plane operation; Azure Policy may enforce deployment properties but not validate the semantics of an application config file. This exercise prevents the common assumption that one protective service covers all unintended state changes. It also links troubleshooting to governance improvements that avoid repeat incidents.

Verify the operational boundary before booking

A study plan should use the current official AZ-104 skills list and a real Azure lab, not only multiple-choice exercises. Prepare to interpret deployment errors, effective role assignments, network routes, backup reports and service metrics. Some tasks can be completed through several interfaces; the point is to understand the resulting state and its security consequences. Use least-privilege lab accounts and sensible spending limits so practice itself does not create avoidable exposure or cost.

Review Microsoft's live registration page for available languages, delivery details and the most recent exam changes. Roles and products evolve, so a 2023 tutorial may teach sound principles while showing an obsolete portal location. Focus on stable relationships: authorization versus policy, redundancy versus recovery, private connectivity versus public exposure, and resource health versus application success. Those distinctions are the durable technical core of AZ-104 and explain why competent Azure administrators remain essential as cloud automation expands.