Troubleshooting is woven throughout AZ-104 even though Microsoft does not present it as one large standalone domain. The current blueprint explicitly includes troubleshooting network connectivity and load balancing, interpreting monitoring data, querying logs, using Network Watcher and Connection Monitor, performing restore operations, and working with the identity, storage, compute, and governance controls that can cause failures in the first place.<\/p>\n
That means candidates need more than a list of repair steps. They need a method for narrowing the fault domain. A reliable method is to define the expected state, identify the observed symptom, determine which layer could produce that symptom, gather evidence, and change only the configuration that evidence supports.<\/p>\n
The AZ-104 exam<\/a> rewards this kind of disciplined diagnosis because many answer choices can describe valid Azure features while only one addresses the demonstrated cause.<\/p>\n If a user cannot create or modify a resource, the problem may involve Azure RBAC, policy, locks, quotas, or deployment configuration. If an application cannot reach a resource that already exists, the issue may involve network routing, service firewalls, DNS, authentication, or data-plane authorization. Mixing these planes can send troubleshooting in the wrong direction.<\/p>\n For example, a user may be able to view a storage account in the portal yet still be unable to read blob data. Management-plane visibility does not automatically imply data-plane access. Conversely, a workload could have data access through an identity while the operator lacks rights to change the storage account itself.<\/p>\n Use Azure RBAC<\/a> questions to practice identifying which operation is failing and at which scope before changing permissions.<\/p>\n When connectivity fails, start with the destination the client is actually using. Confirm name resolution, then identify the source and destination addresses, expected route, security rules, and service-specific network controls. This order avoids random configuration changes.<\/p>\n If DNS resolves correctly, inspect effective routes and peering. If the route is correct, evaluate NSGs and application security groups. If the destination is a PaaS service, consider service endpoints, private endpoints, and the service firewall. If a load balancer is involved, check backend health and probes. Each step removes an entire class of possible causes.<\/p>\n Azure Network Watcher<\/a> is valuable because it provides evidence about connectivity instead of requiring guesswork. Pair it with network security group<\/a> evaluation so you can distinguish path problems from filtering problems.<\/p>\n A client may be able to reach the load-balancer frontend while still receiving failures because one or more backend instances are unhealthy. Health probes decide whether a backend should receive traffic. A probe can fail because the port is wrong, the application is not listening, an NSG blocks the probe, or the backend itself is unhealthy.<\/p>\n When a scenario mentions intermittent success, uneven traffic, or healthy VMs that are not receiving requests, inspect the relationship among frontend IP, rule, backend pool, probe, NSGs, and routes. Do not assume the load balancer itself is misconfigured just because it sits in the middle.<\/p>\n A practical review of Azure Load Balancer<\/a> is most useful when each component is tied to a specific failure symptom.<\/p>\n When storage access fails, check network reachability, authentication method, and authorization. A storage firewall can deny a request before the supplied identity or SAS permissions matter. A valid network path can still fail if the token is expired or lacks the required permission. An authenticated identity can still lack the data role needed for the operation.<\/p>\n Keys, SAS, and identity-based access also create different troubleshooting evidence. A shared key problem is different from an Entra role-assignment problem. A stored access policy can affect SAS behavior. Private networking can add DNS dependencies that do not exist for a public endpoint.<\/p>\n Azure Storage<\/a> troubleshooting becomes much faster when candidates refuse to label every failure \u201cpermissions\u201d and instead test reachability, credential validity, and authorization separately.<\/p>\n An ARM or Bicep deployment can fail because the template is invalid, a dependency is missing, the resource provider rejects a property, the user lacks permission, a policy denies the requested state, or the subscription has a quota or location restriction. The deployment output is therefore a diagnostic source, not merely a red error banner.<\/p>\n Compare the declared state with the environment\u2019s controls. If the same template works in one subscription but not another, look at policy, role assignments, provider registration, quotas, and region availability. If a deployment repeatedly creates an unexpected property, inspect the template or parameter source rather than correcting the resource manually after every run.<\/p>\n ARM template<\/a> troubleshooting teaches a broader administrator habit: identify whether the failure is in the requested configuration, the caller\u2019s authority, or the environment\u2019s governance.<\/p>\n Sometimes the problem is not that Azure Monitor lacks data, but that the expected signal was never configured. A log setting may not send data where a query expects it. An alert rule may monitor the wrong scope or metric. An action group may not contain the intended notification or automation target. A threshold may be correct while the evaluation frequency creates unexpected behavior.<\/p>\n Start with the question being asked. If you need a time-series measurement, use metrics. If you need detailed events, inspect logs. If you need notification when a condition occurs, validate the alert rule and action group. If the issue is resource-specific and supported by an Insight, use that curated view as another evidence source.<\/p>\n Azure Monitor<\/a> troubleshooting is fundamentally about matching the evidence type to the operational question.<\/p>\n Backup failures can originate in policy configuration, vault association, permissions, protected-item state, network access, or unsupported configuration. A successful policy assignment is not proof that every backup is completing. Reports and alerts exist because protection itself must be monitored.<\/p>\n When restoration is required, identify the protected item, recovery point, target, and desired outcome. Restoring a file, a disk, or a full workload can require different steps. Site Recovery adds replication health, recovery plans, target-region resources, and failover state to the investigation.<\/p>\n Azure Backup<\/a> should therefore be practiced from failure through restore, not just through initial configuration.<\/p>\n Keep timestamps and recent changes in the investigation. Many incidents become easier when you compare when the symptom began with deployments, policy changes, role assignments, network edits, or scaling events. Azure activity records and monitoring data can help establish that timeline. Even when the exam does not ask for a full incident process, thinking chronologically prevents you from treating every configuration in the environment as equally likely to be the cause.<\/p>\n A strong troubleshooter avoids making five changes at once. If you suspect an NSG, test or inspect the effective rule rather than opening all traffic. If you suspect RBAC, examine the assignment and scope rather than granting Owner. If you suspect DNS, compare resolution before changing routes. Broad changes can hide the root cause and create new risk.<\/p>\n This principle also maps to exam scenarios. An answer choice that grants excessive privilege or removes an important security control may technically make a symptom disappear, but it is usually weaker than a targeted correction that preserves the intended architecture.<\/p>\n The administrator role is about restoring service without destroying governance. Least privilege, controlled scope, and evidence-based changes are operational requirements, not just security slogans.<\/p>\n After you build a working environment, break one dependency. Remove a role assignment, deny a port, change a route, alter a health probe, block storage networking, stop telemetry flow, or create a failed deployment. Write down the symptom before you inspect the cause. Then diagnose it using the same sequence you would use if you did not know what was changed.<\/p>\n This produces a much stronger learning effect than only configuring happy paths. The exam can present an environment that is mostly correct, and real administrators spend a large part of their time explaining why a previously working system no longer behaves as expected.<\/p>\nStart every incident by separating control-plane and data-plane symptoms<\/h3>\n
Trace network failures in a fixed order<\/h3>\n
Load-balancing failures often begin behind the frontend<\/h3>\n
Storage troubleshooting requires three separate access checks<\/h3>\n
Deployment failures should be read as messages from multiple policy layers<\/h3>\n
Monitoring failures are often failures of evidence collection<\/h3>\n
Recovery troubleshooting begins before a restore is attempted<\/h3>\n
Use the smallest safe change that tests your hypothesis<\/h3>\n
Turn every practice lab into a troubleshooting lab<\/h3>\n