Microsoft AZ-104: The Troubleshooting Trail Across Azure
An Azure outage rarely announces itself as “a networking problem.” Users report that an application is unavailable. The virtual machine is running, the service health page looks normal, and administrators begin changing settings without establishing what failed. Microsoft AZ-104 rewards a different habit: tracing access, compute, storage, connectivity and monitoring until the evidence points to a specific control.
The exam, Microsoft Azure Administrator, covers implementing, managing and monitoring Azure resources. Its current English objectives, revised in April 2026, span identity and governance, storage, compute, virtual networking, and operations. The Microsoft AZ-104 page belongs alongside those official objectives rather than replacing hands-on troubleshooting.
Imagine that a small internal service stopped responding after a routine deployment. Before restarting virtual machines, establish whether every user is affected, whether the application still starts locally, whether DNS resolves correctly, and whether the problem appears only from outside the virtual network. These observations determine whether to investigate identity, routing, a private endpoint, application configuration or the workload itself. If the incident turns into a connectivity or DNS problem, Microsoft AZ-700 network troubleshooting follows that layer in more detail.
Azure networking demands this distinction. A network security group controls traffic at its associated scope, while user-defined routes influence next hops. Private endpoints and service endpoints solve different connectivity problems. If a private endpoint is configured but a client resolves a public address, the immediate suspect may be private DNS rather than the endpoint service. Practice reading effective routes and security rules instead of guessing from resource names. User-visible delays can also originate above the infrastructure layer; Microsoft AZ-140 virtual desktop performance follows that path through virtual desktop sign-in and session behavior. Readers who need a refresher on basic cloud responsibility and service models can contrast these administrator cases with Microsoft AZ-900 cloud fundamentals.
Identity and governance can generate confusing symptoms. Azure role-based access control defines what a principal can do at a particular scope. Azure Policy evaluates resource configuration against organizational rules; a resource lock can prevent specific changes. A user who can read a subscription but cannot deploy a storage account might lack a role assignment, encounter a policy denial, or face a lock. Those are different causes with different remedies.
Walk through a failed deployment record and find the denial before broadening permissions. The shortcut of assigning Owner privileges may make the error disappear, but it violates least privilege and conceals the underlying governance requirement. Also understand management groups, subscriptions, resource groups, tags and cost budgets as parts of an operating model, not just navigation levels in the portal.
When a report cannot upload to Blob Storage, check authentication, network restrictions, account configuration and object permissions separately. Shared access signatures grant time- and scope-limited access; account keys are much broader secrets. Storage firewalls can block a correctly authenticated application, while an expired SAS can make a reachable service return an authorization error.
AZ-104 also expects storage administration decisions: redundancy options, lifecycle tiers, soft delete, versioning, Azure Files, snapshots and identity-based access. Consider a finance team accidentally deleting a document. High availability of the storage service will not restore a deleted version by itself. The appropriate protection depends on which deletion, corruption or regional event you are trying to recover from.
Virtual machines, scale sets, App Service, containers and deployment templates serve different workloads. Know where settings live and how to inspect them. A VM may be healthy yet constrained by disk performance or an unavailable dependency. An App Service deployment slot can help stage an application change but does not excuse a broken configuration connection string or insufficient service-plan capacity.
Automation with ARM templates or Bicep introduces repeatability. Learn to inspect a deployment, adjust a parameter and interpret errors. The right lab is not simply creating a resource; it is modifying it safely, observing the impact and recovering when the initial specification is wrong.
Azure Monitor, alerts, logs, metrics, diagnostic settings and backup tooling occupy the operational end of the syllabus. A metric can show that CPU rose; a log may reveal the failed requests; an activity record may show a configuration change. The useful diagnosis comes from correlating them. Decide what the team should alert on, who receives the alert and what the first response should inspect.
For a real incident, record a timeline: when users noticed the issue, when a deployment changed configuration, and when a monitoring signal deviated. That produces a stronger root-cause hypothesis than relying on a single dashboard. In exam scenarios, pay attention to the requested outcome—restore access, prevent recurrence, or preserve data—because the correct action changes with the objective.
Build a small environment with two subnets, a storage account, a workload and a narrowly scoped identity. Deliberately introduce a DNS mismatch, a denied role assignment, an expiring access token and a resource policy restriction. Troubleshoot each by collecting evidence before changing configuration. The exam’s domain weights emphasize identity and governance as well as compute, with storage, networking and monitoring closely behind. A successful administrator learns to connect those domains without turning every failed request into a wider permission grant.
