Microsoft AZ-104: Thinking Through Scenarios
AZ-104 scenario questions are rarely difficult because of one obscure fact. They are difficult because several Azure controls can influence the same symptom. A virtual machine may be unreachable because of routing, an NSG, DNS, identity, a platform setting, or the application itself. A user may be unable to change a resource because of RBAC, a lock, policy, or scope. Thinking through AZ-104 scenarios means learning to separate those layers before choosing an answer.
The current exam covers identities and governance, storage, compute, virtual networking, monitoring, backup, and recovery. Those areas are connected in real administration work, so practice questions increasingly make sense when you treat the environment as one system. The strongest method is to identify the desired outcome, trace the relevant dependency chain, and then select the control that actually governs the requirement.
Use the following scenario patterns as mental drills. The purpose is not to memorize one answer for each pattern; it is to build a repeatable process that works when Microsoft changes names, portal locations, or surrounding details.
For access problems, separate sign-in from permission and scope
If a user can sign in but cannot modify a resource, authentication is probably not the first problem to investigate. Ask which identity is being used, which role is assigned, where that role is assigned, and whether inheritance reaches the resource. Then check whether a resource lock or policy blocks the operation even when RBAC permits it.
The difference between Azure Policy and Azure RBAC becomes especially important in scenarios. RBAC answers “may this identity perform this action at this scope?” Policy answers “is this resource configuration allowed or compliant?” A delete lock answers another question entirely. When a scenario mixes them, identify which control corresponds to the exact failure.
For storage scenarios, trace authentication, authorization, and network access
A storage client needs a valid way to authenticate, sufficient authorization, and an allowed network path. If one layer fails, the user may simply report that storage is inaccessible. AZ-104 expects you to distinguish shared keys, SAS, identity-based access, firewall rules, private endpoints, and redundancy or lifecycle settings based on the requirement.
Build a mental checklist before choosing an answer: who is the client, what credential or identity does it use, what data operation is required, and from which network does the request originate? Only after those questions should you choose the access mechanism. If the scenario is about resilience rather than access, shift to the failure model and compare Azure Storage redundancy options instead.
For virtual machines, ask what layer owns the requested change
VM scenarios can involve size, availability, disks, extensions, identities, boot diagnostics, networking, or recovery. Start by classifying the requirement. If performance is insufficient, the issue may be VM size or disk design. If deployment must be repeatable, ARM or Bicep is more relevant. If the requirement is access without a public IP, Bastion or another secure connectivity design may matter.
Do not let the presence of a VM force you into a VM-specific answer. A scenario that asks for a managed web workload with minimal operating-system administration may point to App Service or another platform service instead. AZ-104 tests operational judgment across compute options, not loyalty to virtual machines.
For network failures, trace the packet from source to destination
Networking questions become manageable when you narrate the path. What address does the client resolve? Which subnet is it in? What route is selected? Which NSG rules are effective? Is peering configured in the needed direction? Does the destination expose a public endpoint, private endpoint, or service endpoint? Is DNS resolving the intended address?
A lab with Azure virtual network peering is useful because it exposes route and connectivity assumptions. Deliberately break one setting and observe the symptom. Then use Network Watcher or effective routes and security rules to verify the cause. This is much stronger than guessing which networking service “sounds right.”
For governance scenarios, identify the organizational boundary
Management groups, subscriptions, resource groups, tags, locks, policy, budgets, and role assignments operate at different scopes and solve different governance problems. If a requirement applies across many subscriptions, a resource-group-level solution is probably too narrow. If the goal is to prevent accidental deletion, a budget will not help even though both are governance tools.
Write the required outcome in plain language before looking at options. “Ensure all resources in these subscriptions use approved regions” suggests policy at an appropriate scope. “Allow the operations team to restart VMs but not change networking” suggests a role design. “Warn when spending exceeds a threshold” suggests cost management and alerts. Translating the requirement prevents service-name matching.
For monitoring scenarios, decide whether you need metrics, logs, or action
Azure Monitor is broad. A metric alert, log query, diagnostic setting, action group, and resource insight solve different parts of the observability problem. Ask whether the requirement is to collect data, analyze it, detect a threshold or pattern, notify someone, or trigger automation.
Practice the full flow with Azure Monitor alerts and action groups. Configure a signal, cause the condition, verify the alert, and inspect what happens next. A scenario that says “send a notification when CPU exceeds a threshold” is different from one that says “investigate repeated authentication failures over time.”
For backup scenarios, identify what failed and what recovery is required
Backup, soft delete, snapshots, Site Recovery, and storage redundancy all improve resilience, but they address different failures. If a user deletes a file, the solution differs from a regional outage. If a VM must fail over to another region, restoring a backup may not meet the recovery-time requirement. Start by defining the failure and the required recovery point and recovery time.
A practical review of Azure backup and recovery should lead to restore practice. Configure protection, delete or alter something, and perform a recovery. The act of restoring reveals prerequisites and limitations that are easy to miss when you only read about policies.
For multi-domain questions, find the first broken dependency
The hardest questions often combine domains. Imagine an application on a VM that uses managed identity to access storage through a private endpoint. It suddenly loses access. Possible causes exist in identity, RBAC, DNS, routing, NSGs, the private endpoint, or the storage firewall. The fastest approach is to test the dependency chain in order rather than changing several settings at once.
State what must be true for the request to succeed: the workload must have an identity, that identity must be authorized, the hostname must resolve correctly, the network path must be available, and the service must accept the request. Then use the scenario evidence to eliminate layers. This same reasoning applies to many Azure services.
Use adjacent exams to understand where AZ-104 stops
AZ-305 asks more architecture-oriented questions, while AZ-700 goes deeper into Azure networking. AZ-140 specializes in Azure Virtual Desktop. AZ-104 expects administrators to implement and operate the foundational environment across all of these areas without requiring the same specialist depth.
The Azure Administrator credential is strongest when you can diagnose an environment, not just configure one. During final review, take practice scenarios and explain why every wrong option fails the requirement. That discipline exposes hidden assumptions and reduces the temptation to choose an answer because you recognize its product name.
Your best exam-day question is simple: what exact requirement is the scenario asking me to satisfy, and which Azure control directly governs it? If you can trace dependencies and distinguish control layers, long AZ-104 scenarios become much less intimidating.
Container and App Service scenarios benefit from the same layered method. If a web application cannot reach a backend, ask whether the issue is application configuration, managed identity, DNS, private access, or a network rule. If the requirement is deployment without managing virtual machines, first consider whether a platform service satisfies the need before choosing a VM-based design. Azure administration includes knowing when not to administer an operating system.
Command-line scenarios should be interpreted by intent rather than memorized syntax. When you see PowerShell or Azure CLI, identify the resource type, the operation, the scope, and the parameters that materially change behavior. You do not need to recall every switch from memory to recognize that a command creates a role assignment, updates a network rule, or deploys a resource. Practice reading commands as structured descriptions of an administrative action.
Subscription and resource-move questions are another useful drill. Ask which dependencies move with a resource, which identifiers or permissions may change, and whether the source and destination satisfy the service’s move requirements. These scenarios reward candidates who consider the administrative boundary instead of assuming every Azure resource can be moved freely between any containers.
One final scenario pattern is cost without architectural redesign. If a question asks you to reduce waste, look for stopped-but-billable resources, oversized compute, unnecessary redundancy, stale disks, or retention settings before inventing a different platform. Azure administrators are expected to operate resources responsibly, and cost-management clues can be part of otherwise technical scenarios.
If two answers both appear technically possible, prefer the one that satisfies the stated requirement with the appropriate administrative layer and the least unnecessary complexity. That principle is especially useful when the distractor would solve the problem only after introducing extra infrastructure.
- Category: All Certifications Certifications
