Begin with the administrator’s operating model

An Azure administrator usually works within a larger platform team. A role assignment that permits a resource configuration change may not grant access to the resource’s data. A network route can exist without the correct DNS answer. A running virtual machine can still have broken authentication, application dependencies, or restore procedures. Effective administration means following the requested operation through identity, resource scope, data and network paths, and observable outcomes.

Microsoft’s April 17, 2026 AZ-104 skills guide allocates approximately 20–25% each to identity/governance and compute, 15–20% each to storage and virtual networking, and 10–15% to monitoring and maintenance. The weights help prioritize a study plan, but they do not imply that ignoring a small domain is safe. An incident can cross several domains at once, and a common application failure may originate in a control that was not the first screen opened by the operator.

Start with the AZ-104 skills map when assessing what you already understand and where hands-on gaps remain. Microsoft is the examination issuer; the separately branded Exam-Labs Microsoft AZ-104 resource is the site’s own practice-related destination, not Microsoft exam registration or the official skills-measured document. For current official objectives and exam logistics, use Microsoft’s first-party certification information.

1. Identity and governance: explain who can do what, and where

Before any Azure resource can be administered, someone needs the appropriate identity and authorization. Microsoft Entra users and groups represent people and memberships; Azure RBAC assignments control actions at management group, subscription, resource group, or resource scope. Directory administration and resource authorization belong to different planes. The Entra users, groups and administrative units guide provides the identity boundary, while Azure RBAC scope and inheritance helps diagnose why a role applies, or unexpectedly does not apply, to a resource.

Governance adds controls over what state is allowed. Azure Policy can assess or restrict configured resource properties; RBAC controls who can perform operations. A role does not make a noncompliant deployment acceptable, and a policy does not automatically grant someone the right to remediate it. The Azure Policy versus RBAC decision framework explains that distinction. Resource locks, budgets and tags create additional constraints that must be understood before a production resource is modified or removed.

Practical exercise to design: give a new operations engineer access to monitor a single resource group, but not to edit unrelated production subscriptions. Record their directory identity, chosen role, assignment scope, inheritance, effective permission, and the governance rules still in force. Then explain why a broad subscription-wide assignment would be unnecessarily risky. This is a design exercise, not a claim that a real Azure tenant change has been performed here.

2. Storage: choose security, resilience and recovery separately

A storage account's firewall and permitted networks determine which clients can reach the service; blob roles or appropriately scoped delegated credentials determine what an authorized client can read or change. For one user, an interactive download may be sufficient. For a repeatable multi-gigabyte operation, command scope, file selection, overwrite behavior and the transfer evidence matter much more. The practical AzCopy and Storage Explorer comparison distinguishes controlled copy from synchronization, including the danger of deleting destination-only objects.

Azure Storage redundancy addresses infrastructure failure, not the same problem as accidental modification of logical data. LRS, ZRS and geo-redundant patterns differ in the failure boundary they cover; earlier blob versions and soft-deleted containers preserve different states of data. The storage redundancy decision explains infrastructure resilience, while blob protection and object replication explains versioning, deletion recovery and asynchronous copying of selected blobs between accounts.

Practical exercise to design: copy five known test objects into a nonproduction container and document source hashes, expected destination paths, permissions and recovery options. Consider what would happen after an accidental overwrite or after a synchronization with destination deletion enabled. The required outcome is a demonstrably recoverable dataset, not simply a successful upload notification.

3. Compute: operate the workload, not only its VM or container

Resource deployment should be reproducible, with traceable configuration and a known rollback path. ARM templates and Bicep files declare Azure infrastructure and can be reviewed, versioned, and redeployed; their syntax alone does not guarantee that a release is safe. The ARM and Bicep decision guide frames that choice around ownership, repeatability and governance. Resource drift, missing identity roles and broken downstream dependencies can still cause an apparently successful deployment to fail.

Azure virtual machines raise placement, sizing, data disk, scaling and protection questions. An availability set and a zone address different failure boundaries. VM scale sets add autoscaling and replacement behavior rather than guaranteeing the application can cope with sudden replica growth. The host encryption and resource movement guide explains the difference between storage encryption at rest, encryption at the VM host, same-region management-scope moves, and actual regional relocation.

Container orchestration and image storage are different responsibilities. Azure Container Registry stores and distributes images; an application runtime still needs permission and network reachability to pull them. The Container Registry permission guide separates identity authorization, registry repository scope, and image pull diagnostics. Azure Container Instances and Container Apps are different runtime choices whose suitability depends on ingress, revisions, scale behavior, and operational ownership.

App Service is another compute operating model. A deployment slot can simplify promotion, but the site’s custom domain, certificate, inbound access rules, outbound VNet integration and restore path need separate configuration. The App Service custom domain, TLS, networking and backup guide addresses those service boundaries. When a restore appears successful but customers cannot reach the app, the missing element may be a certificate binding or private dependency rather than the application’s file content.

Practical exercise to design: stage a workload release using an identified image or artifact, the narrowest runtime permissions, an approved networking configuration and a recovery plan. Explain how you would validate startup, permissions, data access, and rollback independently. These are intended practice steps, not claims that the project has run a subscription or deployed a live sample.

4. Networking: follow an actual packet and DNS query

A virtual network provides address space and logical connectivity, not unrestricted access to every resource. Subnets, NSGs, ASGs, user-defined routes and peerings interact. A peering link can be healthy while overlapping networks, a wrong next hop, or an NSG rule prevents useful traffic. The VNet address planning and peering guide demonstrates why effective paths matter more than drawing connected lines between networks.

A Private Endpoint changes the network entry point to a PaaS service. A service endpoint extends a subnet’s identity to supported services through a different access model. The correct choice depends on the intended service boundary, security policy, DNS answer and supported feature. The Private Endpoint versus service endpoint model explains the difference. An Azure administrator must then follow the actual public or private DNS resolution path from the calling client.

Not every load-balancing service handles the same traffic. Azure Load Balancer works with transport-level flows, while Application Gateway adds HTTP-aware routing and application-edge features. Azure Bastion provides a protected administration access path rather than serving application requests. A useful configuration review asks what protocol is being handled, where the client enters the network, what backend health means, and which security boundary should reject an unapproved source.

Practical exercise to design: troubleshoot a VM that can resolve one private service but fails to connect from another subnet. Record the client IP and resolver, the expected DNS result, effective route, NSG rule, endpoint type and destination permissions. Do not grant extra access until the blocked layer has been identified. A successful DNS query proves neither network reachability nor application authorization.

5. Monitoring and recovery: make incidents explainable

Azure Monitor metrics, logs and alerts offer different evidence. A metric can show a numeric trend, a log query can explain event context, and an alert rule can turn that data into a fired record. Action groups and alert processing rules then determine who is notified and whether actions are intentionally suppressed. The alert delivery and suppression guide distinguishes the signal, rule and notification paths so that teams do not misdiagnose a missing email as absence of an alert.

Collected evidence depends on how data collection rules, diagnostic settings and Log Analytics workspaces are configured. A dashboard cannot analyze logs that were never collected or cannot be queried at the correct scope. The Log Analytics workspace architecture is therefore related to retention, access, cost and investigations, not just creating a workspace with a convenient name.

Recovery has its own boundaries. A backup job’s green status indicates a recovery point was generated; it is not proof that an application can be restored with identity, network access, and its required data. Azure Backup vaults and Recovery Services vaults support different workload protection models; Azure Site Recovery adds replication and a failover path that must be tested against application dependencies. A backup and restore readiness model begins with recovery objectives and ends with a tested usable service, not merely a stored file or recovery point.

Practical exercise to design: during a planned maintenance change, distinguish a genuine CPU or dependency failure from an intentionally suppressed alert notification. Trace the relevant evidence through resource metrics, logs, action groups, and responders. Next describe how the team would confirm a restored workload is accessible from its intended users and how it would record unresolved gaps.

Build an evidence-based study sequence

Start by listing the official skills you cannot yet perform without referring to a step-by-step guide. An administrator who can define NSGs but cannot troubleshoot effective rules needs different practice from one who understands peering yet cannot follow a private DNS lookup. Choose one realistic scenario per weak skill, record its expected result, then describe the actual observation after completing it in an approved Azure tenant. A documented inability to complete the task is more useful than repeating a memorized answer.

A practical first sequence is identity and RBAC, then storage access/recoverability, then a compute deployment with the right image and permissions, then networking and name resolution, and finally monitoring and restoration. This is not the only possible order, but it makes dependencies visible. On later passes, vary the scenario and require an explanation of why one configuration works and a plausible alternative fails.

Use practice questions as a diagnostic rather than as an answer-memory target. Questions that repeatedly cause confusion should lead back to a precise operational skill: assigning roles at scope, recovering a prior blob version, interpreting an effective next hop, selecting the right App Service network access model or proving that a backup can be restored. Where readers need a structured weekly routine, the existing practical AZ-104 study schedule provides a distinct preparation intent rather than duplicating the five technical domains on this page.

What a complete administration exercise should demonstrate

A useful end-to-end Azure Administrator exercise begins with a service requirement, records an owner and allowed network path, deploys a bounded workload, protects its data, adds appropriate telemetry, and verifies recovery. For example, an internal API might need a restricted managed identity, a private endpoint to storage, a deployment path, health monitoring and a way to restore data after an accidental overwrite. Each stage can be evaluated separately before the full workflow is accepted.

Costs and cleanup matter. Use a permitted sandbox subscription or other approved tenant, watch service pricing and quotas, and avoid making publicly reachable resources by accident. Record any deployed resource group, storage objects, role assignments, certificates and generated secrets so they can be removed responsibly when practice ends. These paragraphs describe a learning design; they do not assert that Exam-Labs tested or deployed the scenario in a live Azure subscription.

The learning objective is a clear causal explanation: who may operate the system, which infrastructure supports it, how a request reaches its destination, which signals show failures, and what evidence confirms recovery. Completing these steps creates a stronger model of Azure administration than finishing a list of disconnected portal tutorials.

Maintain current objectives and honest outcomes

Microsoft changes its certification objectives, capabilities and product restrictions as cloud services evolve. Use the official Microsoft AZ-104 skills-measured document for the actual live version and scheduling details. A historically useful tutorial may describe a feature that is retiring, an older certificate process or a service that now has different network requirements. Read the current official service guidance before running any security-sensitive production command.

This Azure Administrator learning path is an editorial orientation for understanding Azure operational tasks. It is not a Microsoft training or registration portal, a promise that reading articles will earn a credential, or evidence that an unperformed exercise was tested. Use it to choose meaningful work, review risks, and evaluate whether a configuration achieves the outcome that real users and operations teams need.