AZ-104: Administering Azure Infrastructure with Confidence

Microsoft AZ-104, Azure Administrator, evaluates the day-to-day responsibility for an organization's Azure identity, governance, storage, compute, networking and monitoring. Microsoft's English-language skills outline was updated April 17, 2026. Candidates should already be comfortable with operating systems, servers, networking and virtualization, because Azure administration requires translating these fundamentals into the correct cloud control plane. An administrator is expected to implement and maintain resources, not merely recommend their architecture, and to understand the security and operational consequences of routine changes.

A practical AZ-104 scenario may start with an application that becomes unreachable after a network change. Troubleshooting could involve DNS, route tables, security rules, load balancing, instance health or an expired identity credential. A command or portal action is useful only if it tests a plausible cause. The exam's breadth can tempt candidates into memorizing screens; a better approach follows dependencies from tenant authorization through resource configuration to application behavior. Understanding Azure governance demands that relationship-focused view to avoid creating new outages while fixing the first one.

Establish identity, scope and resource governance

Azure resources sit within management structures that commonly include tenants, subscriptions, resource groups and individual resources. Role assignments apply at particular scopes and may be inherited downward. Microsoft Entra identities establish who or what is authenticated, while Azure role-based access control determines which management operations are permitted. A user who can sign in to the portal does not automatically have permission to modify a production virtual network. Conversely, an overbroad subscription-level role can affect far more infrastructure than the user needs to administer.

Azure RBAC should be applied with least privilege and periodic review. Custom roles may be appropriate for genuinely specific tasks, but their action patterns need careful testing. A managed identity is useful for workloads that must access Azure services without storing ordinary credentials; it still requires narrowly scoped authorization. Group-based assignments can simplify lifecycle management, provided group ownership is controlled and stale membership does not persist after a job change.

Policies, tags and resource locks govern different aspects of operations. Azure Policy can evaluate and, for suitable effects, constrain resource configuration against organizational rules. Tags support reporting and cost allocation but are not security boundaries. Locks help reduce accidental deletion or modification of specific resources, yet they can obstruct legitimate automated deployment or recovery if used without planning. Azure management scopes and locks deserve attention because an apparently simple action may inherit controls from above the resource being edited.

Choose storage behavior based on access and durability needs

Azure Storage provides services with different data models, including object data and shared file access. Authentication options include identity-based access and short-lived delegated mechanisms such as Shared Access Signatures. A SAS grants access according to its scope and lifetime; it should not be published broadly or treated as equivalent to an interactive user identity. Azure storage access with SAS and Entra ID helps clarify when one access pattern is appropriate and where compromise or accidental exposure can occur.

Storage redundancy affects the failures against which data is protected. Locally redundant and zone-redundant configurations protect against different infrastructure events; geographically replicated options add cross-region copies with their own behavior and recovery considerations. These are not interchangeable promises that an application will always remain available. LRS, ZRS, GRS and GZRS should be evaluated alongside recovery point requirements and the application's ability to use a replica after a regional disruption.

Lifecycle policies and access tiers also have operational consequences. A blob moved to a lower-cost tier may incur retrieval delay or costs. Immutable storage or retention controls can prevent accidental deletion but may restrict legitimate cleanup processes. Storage administrators should understand capacity, network access, encryption, identity and operational recovery together rather than treating the storage account as a single configuration choice. Backups remain necessary for deletion or corruption scenarios not addressed by redundancy alone.

Operate Azure compute under real constraints

Virtual machines require appropriate image selection, size, disks, networking and update procedures. A larger VM does not automatically improve application performance if the bottleneck lies in an external database or disk throughput. Availability zones, virtual machine scale sets and health-aware traffic distribution provide different resilience techniques. A single VM with regular snapshots is not a highly available architecture, and adding replicas does not guarantee stateful applications can fail over correctly.

App Service and container options change the operator's responsibility. Managed platforms can simplify runtime maintenance while requiring attention to deployment slots, configuration values, scaling limits and connectivity to dependencies. An application that starts successfully may still fail health checks because a database is unavailable or a required secret is missing. Choose compute based on runtime needs, scale patterns, operational ownership and cost. Maintain a clear inventory of what the platform manages and what the application team must still update.

Automation through templates, scripts and other declarative mechanisms improves repeatability but can make mistakes repeatable too. Review change scopes, access rights and parameter values before applying them to production. Distinguish desired configuration from evidence that the deployed resource actually works. A pipeline that reports a successful template deployment may still leave an unusable application because the template cannot validate every runtime dependency.

Diagnose Azure networking without guessing

Virtual networks define private address spaces and contain subnets; network security groups filter allowed traffic according to their rules and association. Route tables influence next-hop selection, while peering provides connectivity between suitable virtual networks. Peering does not automatically mean every network can transit through every other peered network. Virtual network peering should be analyzed with actual routes, security filtering, DNS and the presence or absence of gateways.

A public endpoint and a private endpoint have different access implications. Private endpoints connect suitable platform services through private network addresses, but their name resolution must also lead clients to the intended address. Private endpoints and private DNS often explain an application that works on one network and fails from another. Check resolver paths and conditional forwarding rather than assuming an allowed TCP port proves that the application will find the correct service.

Load Balancer distributes connections at a network layer under configured rules; Application Gateway can handle HTTP-related routing and other application-layer capabilities. Load Balancer versus Application Gateway is relevant when selecting the correct service and interpreting health probes. Traffic distribution cannot repair a failing backend, and a healthy network probe may not guarantee business-level correctness. Administrators should correlate listener configuration, backend health, routing and application logs when diagnosing availability.

Monitor, back up and recover resources effectively

Azure Monitor and Log Analytics collect and query operational information according to configured data sources and retention. Metrics can show CPU or service latency trends; logs can provide event context; alerts can notify operators when conditions cross thresholds. An alert on average CPU alone may miss an application dependency failure. Azure Monitor, Log Analytics and alerting should connect measurements to user experience and known failure conditions, with clear ownership for responding to alerts.

Backup policies must distinguish recovery of an individual file, a VM, an application workload or an entire site. Recovery Services vaults and related capabilities have constraints about supported workloads, retention and replication. Azure backup and recovery design becomes operational only after restoration is tested. An organization may retain backups successfully yet discover during an incident that credentials, network rules or dependent databases prevent a usable restore.

Disaster recovery introduces recovery time and recovery point objectives. Replication can reduce potential data loss but may not substitute for a tested application restart procedure. A team should know the dependencies required for successful service restoration and have an approved plan for switching traffic or credentials. Running a failover exercise in a non-production environment can reveal hidden reliance on a region-specific IP address, expired certificate or manual configuration.

A routine capacity incident illustrates why AZ-104 operations cannot be compartmentalized. Suppose an application reports failed writes while virtual-machine CPU and network metrics remain normal. Inspect storage capacity, transaction throttling, authorization failures and recent firewall changes before resizing compute. A newly applied storage-account network rule may reject the application even though Azure reports that both the VM and storage service are healthy. The appropriate repair could be a corrected private endpoint, authorized identity assignment or client retry strategy rather than larger infrastructure. Document the evidence used to distinguish a service configuration problem from an application defect.

Operational changes also need a rollback boundary. When resizing a production VM, changing an IP configuration or altering role assignments, record the expected impact and the recovery action if the change fails. Compare diagnostic measurements before and after implementation, and verify from the application's network context rather than testing only from an administrator's laptop. Azure Activity Log records management operations, but application-level failures may require diagnostic logs and tracing from other sources. An administrator should connect these signals without assuming a successful portal notification means the original user-facing incident is resolved.

Learn through a controlled administration exercise

Create a resource group with clearly scoped rights, a small virtual network and a suitable storage resource. Apply a policy requirement, observe its effect and test access through two identities with different permissions. Deploy a simple application or VM, collect metrics, trigger a harmless alert and document where you would investigate a service outage. Then back up a test workload and rehearse restoring it. Use disposable resources and manage costs by shutting down what is no longer required.

To evaluate readiness, explain what each action proves. A failed connection could be a route, a security rule, DNS or an unavailable application; a missing portal option could be permission or feature entitlement. Candidates interested in design trade-offs and the wider Azure architecture should view AZ-305 as a related but distinct expert-level examination. AZ-104's core competence is administering actual resources safely and keeping them observable, recoverable and governed while organizational requirements evolve.