Azure Administrator exam preparation fails when it teaches candidates to recognize service names without deciding why a particular control meets a requirement. Microsoft AZ-104 measures administration of an Azure environment, where a plausible-looking change can be wrong because it targets the wrong scope, grants unnecessary permissions, or fixes a symptom in the wrong layer. Building administrator judgment means predicting the behavior of a configuration, testing that prediction, and rejecting attractive alternatives for specific technical reasons.
The four connected cases below test one decision habit: identify the precise requirement, choose the Azure control that owns it, and collect evidence that it worked. They span the five areas in the Microsoft AZ-104 learning center and Microsoft’s current AZ-104 study guide, but the emphasis here is how services behave together during a real change or incident.
Read the requirement as a constraint, not a product name
A well-formed administration request usually has more than one valid-sounding tool attached to it. “Keep production resources in approved regions” suggests governance. “Give this group read-only access to one resource group” suggests authorization. “Allow an app to read a private Blob container without account keys” spans identity, storage authorization and network access. The answer depends on which observable behavior the organization wants and which existing boundary must be preserved.
Before selecting a feature, translate a requirement into a short written test: Who is acting? On which resource? What exact operation should succeed? From which network path? Under what protection or availability constraint? What evidence would prove success? If you cannot answer those questions, browsing the portal is likely to produce a configuration that looks reasonable without satisfying the actual request.
The final detail is the negative requirement. “Without widening subscription permissions” or “without a public endpoint” is not background color; it eliminates otherwise workable choices. A strong candidate treats those words as implementation constraints from the beginning.
A six-step decision path for AZ-104 scenarios
Use the steps as a reasoning order, not as a rigid menu sequence. An incident may begin with a failed storage upload, but investigation can establish that DNS is the first broken dependency. In that case, adding broader Azure role assignments is both ineffective and risky. Equally, a correctly resolved private endpoint does not prove that the calling identity may access the requested data.
Scenario one: permissions are correct at the wrong scope
A help-desk team needs to restart a defined set of virtual machines inside a single resource group. It should not edit networking, delete unrelated resources or grant roles to other users. Assigning Contributor to the entire subscription seems convenient: the team would probably be able to restart the VMs. Yet it violates the important constraints by granting far broader management powers than the requirement describes.
Start with the principal—a group is often easier to maintain than many individual assignments—and determine the smallest scope that contains only the necessary machines. Review the permissions of a built-in role that supports the required VM operations, noting that a role can allow additional operations you did not anticipate. The correct model is principal + role definition + scope, with inherited assignments considered before declaring effective access. A group that also inherits Contributor elsewhere may still have broader power despite your narrower new role.
Azure Policy does not decide which identity can restart a virtual machine, and a resource lock is not a substitute for granting access. The principal, role, and scope in the Azure RBAC model determine authorization. Test least-privilege role assignments at one scope, then move the assignment and observe whether the permitted actions change. That difference is the evidence a scenario requires.
To validate the decision in an authorized lab, confirm that the team can perform the permitted task and cannot perform a disallowed harmless management operation. Record the actual result. A screenshot of the assignment blade alone cannot prove the requirement was met.
Scenario two: data access fails, but the storage account exists
A test application uses a managed identity to upload a report into a Blob container. Its storage account has been deployed successfully and its operator can manage the account. The upload is denied. The instinctive response is to make the application identity Contributor on the resource group or to temporarily expose the storage account publicly. Neither change follows from the symptom.
First establish which identity the application uses and what authentication method the request follows. In an Entra-authorized data path, a suitable Blob data role and scope may be required. Managing the storage account through the control plane does not automatically grant data-plane permission to read or write Blob objects. When the service returns an authorization error, examine the precise operation, principal, data role and scope before increasing permissions.
Separately establish whether the client can reach the correct storage endpoint. A private endpoint requires appropriate DNS resolution and a usable traffic path. If the application cannot connect at all, an extra data role will not repair DNS, routing or a firewall. If the network path works but the service rejects authorization, opening the endpoint is unlikely to be justified. Those are different tests, not alternative guesses.
In a disposable storage lab with fabricated data, record the name resolved, target endpoint, identity, Blob data role and request result. Change one variable at a time and restore it afterward. The Azure Storage walkthrough helps distinguish an authorization denial from a DNS or network-path failure. Demonstrate both failures rather than calling every access problem an RBAC issue.
Scenario three: the web service deployed but users still see errors
A team launches a managed web application with a healthy Azure resource status, but its pages intermittently fail when retrieving data. A completed ARM or Bicep deployment means the resource declarations were processed; it does not prove that the application’s dependencies are functioning. Increasing VM size or scaling an App Service plan can be irrelevant if the true failure is name resolution, a missing managed-identity permission, an application configuration value, or the backend service.
Read the symptoms before selecting compute controls. Is the failure consistent or intermittent? Does a health probe show the app process is responding? Is the backend DNS result correct from the workload environment? Do platform metrics show a capacity constraint, or do application logs show permission errors? A high CPU signal may justify a compute investigation; a 403 from the data service suggests a different layer.
A safer deployment process and a highly available service solve different risks. If a change might introduce defects, inspect deployment and verification; if a workload must survive a failure, examine which component or zone is the failure boundary. The AZ-104 dependency model illustrates why a green compute resource cannot by itself prove the whole application is healthy.
Evidence of a correct change is the restored user transaction, matched against monitoring that can catch the same failure later. An administrator should leave behind that verification record, not only the successful deployment activity.
Scenario four: a backup is green but recovery is uncertain
An environment has Azure Backup configured for an eligible VM. The backup job succeeded, and the team assumes recovery objectives are therefore met. That conclusion skips the important test. A scheduled backup creates a protected recovery point under its policy, but recovery depends on what that point contains, how it is restored, which permissions are available, and whether the restored workload can reconnect to data and identity services.
Start with the business request. Is the problem accidental deletion of a file, a failed VM, the need to tolerate a zone outage, or a regional disaster? A file restore, workload backup, high-availability architecture and Azure Site Recovery replication are not interchangeable. Compare the intended recovery time and allowable data loss with the supported protection and failover mechanisms.
Then rehearse a safe restoration of test data or a test workload. Record the chosen recovery point, elapsed time, outcome, networking and authentication dependencies, and what operators must do next. A virtual machine booting successfully is not the same as a recovered customer-facing application. Microsoft’s recovery-point guidance describes the foundation for restore operations; the Azure backup and recovery guide compares the decisions.
Turn wrong choices into durable knowledge
When you miss a question, do not save only the right letter. Write down why your original choice looked plausible, which explicit constraint disqualified it, and how you could test the correct principle in Azure. Categorize the mistake as wrong service, wrong role or scope, wrong data-versus-control-plane assumption, wrong network layer, incomplete availability or recovery model, or simply a missed requirement.
For example, “I chose an NSG because connectivity failed” is not a useful study note. “The client resolved the public service hostname despite the intended private endpoint; an NSG change would not repair the wrong DNS answer” is much more useful. A second scenario with different resource names should still be solvable from the same principle. Repetition of a memorized answer does not demonstrate that transfer.
Use scenario questions after recreating the underlying behavior. An Azure RBAC exercise tests the principal and assignment scope; private endpoint DNS troubleshooting tests the resolver, route and network boundary; and Azure Monitor distinguishes metrics, logs, alerts and response evidence. Explain why plausible alternatives fail before checking an answer. A configuration you can reproduce and reverse provides stronger evidence of readiness than recalling the wording of a practice question.
What administrator judgment looks like on exam day
When a question supplies a long environment description, reduce it to the actor, resource, required operation, dependency path and prohibited shortcuts. Find the narrowest technically supported control that meets those conditions. Never choose a familiar feature merely because it appears in the scenario; the relevant behavior may depend on the exact permission scope or the order in which faults must be isolated.
AZ-104 covers five official domains, but the skill that connects them is making changes from evidence. Learn how to explain a proposed fix, predict what it should change, verify the original user operation, and reverse the change if the outcome is not correct. That is what distinguishes administrator judgment from portal memory—and what keeps this preparation guide separate from a domain study calendar or an exam format summary.
