Microsoft AZ-104: Administering Azure with Secure Foundations

The AZ-104 Microsoft Azure Administrator exam assesses the day-to-day engineering required to implement, manage and monitor an Azure environment. Microsoft's April 2026 objective guide spans identities and governance, storage, compute, networking, and monitoring and maintenance. It is not primarily an architecture slide-deck exam: candidates must recognize how settings affect actual resources and what evidence is needed when a deployment or service fails. Among Microsoft certifications, AZ-104 develops operational depth that later supports more design-focused work such as AZ-305 and engineering collaboration across networking, security and application teams.

The administrator's hardest decisions usually involve boundaries. A subscription belongs to an organization and budget, a resource group scopes deployments and lifecycle operations, an identity receives specific permissions and a virtual network defines connectivity. These abstractions are related but not interchangeable. A resource can be deployed successfully while the application cannot reach a dependency, or an identity can authenticate while lacking authorization to modify the resource. Studying AZ-104 as a sequence of such scenarios gives the technical objectives useful context.

Organize access and governance before deploying resources

Microsoft Entra ID provides identity functions, while Azure RBAC controls actions on Azure resources at assigned scopes. A user who can sign in to the Azure portal is not automatically allowed to change every storage account. A role assignment has a principal, role definition and scope, and inheritance from a management group, subscription or resource group can affect the effective result. The article on Microsoft Entra Conditional Access helps clarify that sign-in conditions are distinct from authorizing resource-management actions. Both must be considered when designing administrative access.

Governance policies define allowable resource configurations or report noncompliance, but they have a different purpose from RBAC. A role can grant permission to create a resource while an Azure Policy assignment may deny that resource's configuration or require particular tags. Management groups provide hierarchy across subscriptions, while resource groups support practical lifecycle and deployment boundaries. If a deployment fails with a policy denial, adding more administrator privileges may not help; the candidate should inspect the inherited policy and its effect. The guide to Azure Policy inheritance provides a useful example of why scope reasoning matters.

Tags can support cost analysis and operations but should not be treated as a security control. A resource labelled “confidential” does not become inaccessible unless actual permissions and protection mechanisms enforce that intent. Resource locks can help prevent accidental deletion or modification under certain conditions, while still requiring careful governance around who can change locks. Administrator competence includes knowing the limits of each control. A solution that piles policies, tags and locks onto every resource without an operational ownership model can be difficult to troubleshoot and expensive to manage.

Practical identity work also covers managed identities, service principals, groups and privileged access. Long-lived application secrets are a liability when a platform-supported identity can provide scoped authorization. A managed identity still needs suitable role assignments; removing a secret does not automatically minimize privileges. The article on Azure managed identities shows how resource identity can reduce credential handling while preserving the need for least privilege. Test role changes under the actual principal that will use the service instead of only under a highly privileged administrator account.

Choose storage and compute for their operational behavior

Azure Storage services support different data patterns and access methods. Blob storage holds objects, Azure Files exposes file-sharing use cases and other services suit queues or tables. Durability and availability depend on chosen redundancy and service configuration. Locally redundant storage is not the same as geo-replicated storage, and a secondary copy may have recovery or consistency considerations that matter during an incident. The explanation of Azure Storage redundancy options can help connect a configuration setting to realistic failure scenarios rather than treating all replication choices as interchangeable.

A storage account's exposure depends on network settings, shared access policies, identity-based authorization and the application path. A shared access signature grants bounded delegated access but must still be handled as a credential; overly broad permissions or long expiry extend risk. Private endpoints affect network access and DNS resolution, and they can be misconfigured even when the account itself is healthy. The Azure Private Link and service endpoint distinction matters when an application can connect from one network but not another. Candidate answers should distinguish failed authentication from failed routing or name resolution.

Compute decisions involve virtual machines, scale sets, containers and managed application options. A VM provides operating-system control but requires patching, capacity and operational ownership; a managed service can simplify some of those tasks while constraining configuration. For AZ-104, know how to select VM sizes, disks, availability arrangements, extensions and monitoring. An application that consumes a full VM's CPU may require a workload investigation rather than an immediate resize. Autoscaling is useful only when the chosen metric reflects demand and the application can handle changes in instance count.

Infrastructure deployment tools such as ARM templates and Bicep enable repeatability. They express a desired resource configuration, but deployment success does not guarantee that application data, DNS or downstream permissions are correct. The article on Bicep and ARM deployment behavior illustrates why an administrator should review parameters, existing-state effects and failed operations. Treat declarative deployments as change-controlled infrastructure work with validation and rollback considerations, not as magical scripts that eliminate every configuration risk.

Troubleshoot connectivity through the actual network path

Azure virtual networking includes subnets, network interfaces, network security groups, routes, DNS settings and gateway or load-balancing components. Each influences a different part of packet delivery. A VM may have a private address while an application remains unreachable because a route points toward an unavailable appliance, an NSG blocks the port or a service is not listening. Work from the observed symptom toward the relevant layer, rather than applying several network changes at once and losing the evidence about what fixed the issue.

Network security groups filter traffic according to rules and effective priority, while user-defined routes influence where packets are forwarded. A permitted NSG flow can still fail because the next hop is wrong. The Azure route tables and UDR model gives an operational example of this separation. When a path unexpectedly traverses a firewall or a peering connection, inspect effective routes and connected topology rather than treating the route-table configuration as a cosmetic label. A successful DNS lookup similarly does not prove the resolved endpoint is reachable.

Load balancing introduces health checks and backend selection. A public-facing application might depend on Azure Load Balancer, Application Gateway or Front Door for different protocol and routing needs. An unhealthy backend could reflect a failed probe, an application error or a listener mismatch. Operators should determine whether a request reached the edge, was routed to a backend and produced an application response. The correct service choice depends on layer, feature needs, TLS behavior and scope; no single load-balancing product replaces all others in every use case.

Monitoring should be woven into investigation. Azure Monitor metrics can reveal utilization and latency; logs and diagnostic data give richer event-level context. Network Watcher can support connectivity and path analysis. The discussion of Azure Monitor versus log analysis is relevant because a graph showing CPU pressure does not reveal the exact failed authentication or network rule. An administrator should choose data that tests a hypothesis and note the time period, resource scope and any gaps in collection before declaring a root cause.

Rehearse recovery, governance and change control together

Backups and disaster recovery serve different goals. A backup supports restoring data or configurations from a known point; a regional failover strategy addresses service continuity under a broader outage. Recovery point and recovery time objectives must inform choices about retention, replication and failover design. The article on Azure backup vault design helps explain why a policy is not sufficient until restores have been tested. A completed backup job does not establish that an application can recover its database, identity and network dependencies within the required time.

A good AZ-104 practice environment begins with a resource group, virtual network, subnet, limited administrative role and a small VM or supported application. Deploy storage with deliberate network restrictions, then test access from a permitted and a denied location. Add monitoring, simulate a missing route or insufficient role assignment, and explain the error using effective configuration and logs. Delete the test resources when finished and confirm that the resulting costs and access policies match expectations. Safe experimentation includes cleanup and cost awareness.

Daily operations also require deciding who is authorized to make changes. Use versioned infrastructure definitions, controlled access and meaningful alerts; avoid responding to a resource warning by permanently expanding privileges or disabling protective policies. If an incident requires an exception, document its owner, scope and removal condition. A technically working workaround can become a future vulnerability when nobody remembers why it exists. This is part of what an administration certification should validate: service recovery without sacrificing long-term control of the environment.

Review the official April 2026 AZ-104 guide and maintain a lab notebook organized by identity, storage, compute, networking and monitoring. For each scenario, state the desired result, the observed result, the component that controls it and the smallest defensible change. Azure constantly adds features, but the administrator's method remains durable. Candidates who understand scope, dependency and evidence can adapt to new interfaces without mistaking a successful portal operation for proof that an entire service is healthy.