Microsoft AZ-104: Running Azure Infrastructure with Control

AZ-104 measures the work of an administrator who has to keep an Azure environment usable after the initial deployment is finished. An administrator needs to manage identity, governance, storage, compute, networking and monitoring as one operating system for the organization, not as separate portal demonstrations. Microsoft's April 17, 2026 blueprint remains active. The central skill is practical control: determine which setting governs a result, make a change safely, and verify that the intended service behaves correctly. Someone who can create a virtual machine but cannot explain why its users cannot reach it has only part of the knowledge AZ-104 demands.

Treat resource organization as an access and cost decision

Subscriptions and resource groups provide scopes for governance, permissions, policies and deployment operations. Their design should reflect ownership, lifecycle and compliance needs rather than an arbitrary naming convention. A resource group is not a security boundary by magic; controls must be assigned and inherited appropriately. Tags can support reporting and automation but do not themselves enforce authorization. Management groups and policy assignments become important when teams have many subscriptions with different regulatory or financial constraints.

Suppose one company has production applications, isolated training environments and shared networking. Administrators should decide where access should be scoped, how costly resources are controlled and which configurations must be denied rather than merely reported. A policy preventing public endpoints requires a different mechanism from a cost budget that alerts when spending rises. Effective RBAC, policy and governance separate who may act, which configurations are allowed and what simply needs financial monitoring. In preparation, practice explaining the effect of changing an assignment's scope, not only the clicks that create it.

Microsoft Entra ID is not the same as resource authorization

Azure identity administration includes users, groups, devices and service principals as well as resource-level authorization. Authentication confirms an identity; authorization determines which operations it may perform. Microsoft Entra roles manage directory tasks, while Azure RBAC roles govern Azure resource actions. Confusing them can produce either unnecessary privilege or a frustrating permission failure. A user may sign in correctly to the Azure portal and still lack permission to modify a storage account or read a key from a vault.

For a managed application running inside Azure, prefer identity-based service access over distributing static credentials where supported. Troubleshoot access by checking the identity in use, role assignment scope, conditional restrictions and whether the requested operation belongs to the data plane or management plane. An engineer may have permission to configure a storage account but not to read the blobs inside it. Microsoft Entra administration provides context, while AZ-104 expects candidates to diagnose how identity decisions interact with the actual resource operation and security policy.

Storage choices depend on access, resilience and lifecycle

Azure Blob Storage, Azure Files and managed disks support distinct patterns. Object storage is well suited to unstructured data accessed over appropriate APIs; file shares expose file-oriented access; disks back VM workloads. Within each, understand redundancy choices, performance tiers, access tiers, encryption and network restrictions. Hot, cool and archive are not merely price labels. Retrieval expectations and minimum storage durations can make a superficially cheaper tier operationally unsuitable. Azure Files and Blob features also differ in backup and identity options.

Consider a workload storing transaction images for seven years. Policy may require immutability or carefully limited deletion rights, while application retrieval uses only the most recent month. Plan lifecycle transitions, replication and access separately. A storage account behind a firewall may be configured correctly yet become inaccessible because DNS or private endpoint routing is wrong. Azure blob and file storage is easier to learn through those causal relationships than through a list of toggles. Practice restoring deleted content and verifying which redundancy method protects against which failure.

Virtual machines and containers have different operating costs

For virtual machines, administrators manage images, sizes, disks, extension behavior, availability configuration, patching and access. Increasing VM size does not solve every performance problem; a disk bottleneck or an unhealthy guest process can dominate. Availability sets, zones and scale sets address different patterns, and a high-availability diagram must explain the failure it is meant to survive. For containers and App Service, platform responsibilities shift, but application settings, identities, networking and release controls still require deliberate management.

An internal web service with irregular traffic might be better hosted on a managed application platform than on several permanently running VMs, but an application requiring specialized guest drivers may need VM-level control. The practical lesson is to choose based on dependencies and operational ownership. When troubleshooting a broken VM deployment, inspect provisioning status, boot diagnostics, extensions and network path rather than immediately rebuilding. Operating Azure virtual machines shows why the administrator needs a methodical sequence from resource health to service health, with evidence at each stage.

Networks explain many apparent application failures

Azure virtual networks, subnets, network security groups, route tables, DNS, peering and load balancers interact to determine reachability. A subnet address range must be planned before deployment; overlapping address spaces complicate peering or hybrid connectivity. A network security group rule alone is not the whole route: effective rules, routing and name resolution must all align. Private endpoints add another dependency because an application must resolve the service name to the intended private address for the private path to work.

For example, a VM may reach a public website yet fail to connect to a private storage endpoint. Check whether DNS returns the private address, whether routing reaches the destination, whether an NSG blocks traffic and whether the service accepts the identity. Do not treat a successful ping as proof an application protocol will work. Azure virtual network design and the deeper AZ-700 networking scope support this troubleshooting logic. AZ-104 focuses on implementation and management; AZ-700 adds more specialized network design and operational depth.

Monitoring is useful only when it supports a decision

Azure Monitor, metrics, logs, alerts and workbooks reveal different aspects of service behavior. A CPU metric is not a complete explanation of an application outage, and a green resource status does not guarantee users can log in. Configure diagnostic settings based on the incident questions the team needs to answer. Alert on meaningful thresholds and loss of service, not on every normal variation. Choose retention and access controls carefully: application logs can contain sensitive values even when the infrastructure metrics do not.

A useful incident exercise starts with users reporting intermittent errors. Correlate the time of failures with deployment changes, load balancer health, VM performance, network events and application logs. Decide which signal establishes impact and which merely indicates a possible cause. Azure Monitor and alerting should lead to a runbook with ownership, escalation and verification steps. Monitoring without a response plan produces dashboards rather than operational reliability, especially when many teams share one subscription.

Change control should make configuration drift visible

An Azure estate rarely stays exactly as it was provisioned. Teams create resources in emergencies, temporary firewall exceptions linger and a forgotten role assignment remains after a project changes owners. Administrators should distinguish an intentional exception from unmanaged drift. Resource locks can prevent some accidental operations but do not replace policy, authorization or a review process. A deployment template defines the desired state of resources within its scope, yet blindly reapplying it can overwrite a legitimate operational change if the team has not reconciled differences. AZ-104 preparation benefits from an exercise that first discovers what changed and only then decides how to restore the intended configuration.

Consider a storage account made publicly reachable for a vendor migration. An alert discovers the exposure several weeks later. The response should establish which path was opened, who approved it, whether data were accessed and what dependent jobs will fail if access is closed. Next correct the configuration, record the approved change and add a policy or release check that would catch the same mistake earlier. If several subscriptions share policy assignments, test their effects on an isolated resource before broad enforcement. Control is not the inability to change infrastructure; it is the ability to explain each change, constrain its impact and prove the service still operates securely afterward.

Backup, recovery and automation close the operational loop

Backups and snapshots are not interchangeable with a tested disaster recovery strategy. Administrators should know which resources can be restored, the recovery point objective, the recovery time objective, and how encrypted data or identity dependencies affect recovery. A backup that has never been restored cannot establish that an application will function after a regional incident. Apply the same rigor to provisioning: use templates, scripts and parameterized configuration to make routine tasks repeatable and reviewable, while recognizing that automation can also replicate a bad setting rapidly.

Practice building a resource with Bicep or Azure CLI, modifying a policy, diagnosing a failed deployment and recovering known data. Azure backup and recovery and Bicep, ARM, PowerShell and Azure CLI are most useful when they reinforce one coherent workflow. An AZ-104 administrator should be able to justify a choice in terms of access, cost, availability and operational labor. Those tradeoffs are the foundation for AZ-305 infrastructure architecture, where the same technologies are considered at broader solution-design scale.