AZ-104 — Microsoft Azure Administrator Scenario Practice Guide

Preparing for Microsoft Azure Administrator (AZ-104) scenario questions is less about memorizing isolated facts and more about making disciplined decisions from incomplete but sufficient information. A good scenario usually gives you an Azure environment, a current problem or goal, several constraints, and answer choices that are all somewhat familiar. Your task is to choose the option that best satisfies the stated requirement with the right Azure service, scope, permission, configuration, or troubleshooting step.

This guide is independent exam-preparation guidance. It focuses on public, practical reasoning habits for AZ-104 candidates and does not claim affiliation with Microsoft.

The core habit: turn the scenario into an admin decision

Read each scenario as if you are the Azure administrator receiving a work item. Before looking for the answer, ask:

• What is the environment?
• What is the current state?
• What is the requested outcome?
• What constraint must not be violated?
• What Azure control, service, or action directly changes that state?
• What is the least broad, least disruptive, and most defensible answer?

The best answer is often not the most powerful option. It is the option that meets the requirement at the correct scope while respecting security, availability, cost, and operational constraints.

A practical AZ-104 reading sequence

Use the same sequence on every scenario, especially under time pressure.

1. Identify the Azure environment

First, locate the administrative boundary. AZ-104 scenarios frequently depend on where a resource lives and what scope the change applies to.

Look for:

• Tenant, subscription, management group, or resource group
• Region, availability zone, paired region, or recovery location
• VNet, subnet, peering, gateway, private endpoint, or DNS zone
• VM, scale set, storage account, container, backup vault, or Log Analytics workspace
• User, group, managed identity, role assignment, policy, or lock
• Existing monitoring, diagnostic settings, alerts, or backup configuration

Do not treat these details as background noise. In Azure administration, scope often determines the correct answer.

For example, if users need access to manage only resources in one resource group, the scope is likely the resource group, not the subscription. If a VM in one subnet cannot reach a private endpoint, the relevant facts may be subnet routing, NSGs, DNS resolution, and private endpoint configuration.

2. Name the goal in one sentence

Before evaluating answer choices, rewrite the scenario as a short task.

Examples:

• “Grant a group the minimum permissions needed to manage VMs in one resource group.”
• “Allow a VM to resolve and reach a storage account privately.”
• “Configure alerts when a resource crosses a performance threshold.”
• “Protect a VM so it can be restored after accidental deletion or corruption.”
• “Apply a required tagging rule to new resources in a subscription.”
• “Move resources while minimizing downtime and preserving dependencies.”

If you cannot summarize the goal, reread the final sentence and the wording around “must,” “need,” “ensure,” “minimize,” and “only.”

3. Separate current state from desired state

Scenario questions often describe both what exists and what must be true after the change.

Mark the difference:

• Current state: What is already configured?
• Desired state: What must be added, removed, fixed, or verified?
• Gap: What single Azure action bridges that gap?

Example:

• Current state: A storage account allows public network access.
• Desired state: Access should occur from a VNet without using the public internet.
• Likely gap: Private connectivity and name resolution, not just an NSG rule.

This step helps you avoid choosing an answer that sounds relevant but does not actually change the missing condition.

4. Separate constraints from preferences

AZ-104 scenarios often include both hard requirements and softer preferences. Hard requirements control the answer.

Hard constraints may include:

• Use least privilege
• Minimize administrative effort
• Minimize downtime
• Preserve data
• Prevent public access
• Apply to only one resource group
• Support a specific region or availability design
• Avoid changing existing IP addresses or network topology
• Retain logs or backups for a defined business need

Preferences may include words like “prefer,” “where possible,” or details that support the scenario but do not override the main requirement.

When choices conflict, the hard constraint wins. For example, an answer that grants Owner at the subscription scope may solve an access problem, but it usually fails a least-privilege requirement if the task is limited to one resource group.

5. Match the Azure control to the requirement

After identifying the goal and constraints, choose the Azure mechanism that directly addresses them.

Common AZ-104 mappings:

• Need to grant management access: Azure role-based access control at the correct scope
• Need to grant directory administration: Microsoft Entra role, not Azure RBAC
• Need to control resource creation or enforce configuration: Azure Policy
• Need to prevent deletion or modification: Resource lock
• Need private access to a PaaS resource: Private endpoint, private DNS, and network configuration
• Need network filtering: NSG, firewall, route table, or service-specific firewall, depending on traffic path
• Need VM protection and restore points: Azure Backup
• Need disaster recovery or failover replication: Azure Site Recovery style reasoning
• Need performance or availability visibility: Azure Monitor metrics, logs, alerts, or diagnostic settings
• Need centralized log queries: Log Analytics workspace
• Need repeatable resource deployment: ARM template, Bicep, Azure CLI, PowerShell, or automation approach depending on the answer options

The correct answer is the one that aligns with the control plane or data plane actually involved.

6. Choose the least broad complete answer

A strong AZ-104 answer usually has three qualities:

• It fully satisfies the requirement.
• It applies at the smallest appropriate scope.
• It avoids unnecessary disruption or privilege.

Use this elimination order:

1. Remove answers that violate an explicit requirement.
2. Remove answers that operate at the wrong scope.
3. Remove answers that solve a different layer of the problem.
4. Remove answers that are unnecessarily broad, disruptive, or manual.
5. Choose the remaining answer that is complete and operationally practical.

Reading Azure identity and access scenarios

Identity scenarios require careful separation of management permissions, directory permissions, and data access.

Ask what kind of access is needed

Management-plane access controls Azure resources, such as creating VMs, managing network interfaces, or configuring storage account settings. This usually points to Azure RBAC.

Directory administration controls Microsoft Entra ID objects, such as users, groups, and tenant-level identity settings. This points to Microsoft Entra roles.

Data-plane access controls the actual data inside a service, such as reading blobs or accessing files. This may require a data-specific role, SAS, access key, or service-specific access model depending on the scenario.

Check the scope

Azure RBAC can be assigned at different scopes, such as management group, subscription, resource group, or resource. The scenario’s boundary matters.

If the task is limited to one resource group, avoid answers that grant permissions across the subscription unless no smaller valid scope is available in the choices.

If the user needs to manage only one resource, a resource-level role assignment may be more defensible than a broader assignment.

Example reasoning

Scenario idea: A team must restart and monitor VMs in one resource group, but must not manage networking or storage accounts elsewhere.

Reasoning:

• The environment is one resource group.
• The goal is limited VM administration.
• The constraint is least privilege.
• The answer should use Azure RBAC at the resource group scope with a role that covers the required VM operations.
• Subscription-wide Owner or Contributor access is broader than necessary.

Reading governance scenarios

Governance questions often test whether you can distinguish between access, enforcement, organization, and protection.

Azure Policy is for rules, not permission grants

Use Azure Policy reasoning when the scenario says resources must comply with a standard, such as requiring tags, restricting regions, auditing configurations, or deploying required settings.

Azure Policy does not grant a user permission to manage resources. If the scenario asks who can perform an action, think RBAC. If it asks how to enforce or audit resource configuration, think Policy.

Resource locks are for protection, not compliance design

Locks help prevent deletion or modification. They are useful when the scenario says a critical resource must not be accidentally deleted or changed.

A lock does not replace RBAC, and it does not enforce broad configuration standards across future deployments.

Management groups and subscriptions are about hierarchy

If the scenario involves applying governance consistently across many subscriptions, management group scope may be relevant. If it involves only one subscription or one resource group, a narrower scope may be better.

Reading storage scenarios

Storage scenarios often include network access, redundancy, lifecycle, data access, or backup requirements.

Identify what the storage account is being used for

Ask:

• Is the scenario about blobs, files, queues, or tables?
• Is access coming from users, VMs, applications, or on-premises systems?
• Is the issue authentication, authorization, network reachability, redundancy, cost, or retention?
• Is the scenario asking for data access or storage account administration?

These questions prevent you from mixing up control-plane configuration with data-plane access.

Network access versus permissions

If a user or application cannot access storage, determine whether the blocker is identity or network path.

Identity issue clues:

• Role assignment
• SAS token
• Access key
• Managed identity
• User or group permission
• Blob reader or contributor requirement

Network issue clues:

• Public network access disabled
• Firewall rules
• VNet integration
• Private endpoint
• DNS resolution
• Subnet or route configuration

A permission change will not fix a private DNS problem. An NSG change will not grant blob read permission.

Private access scenarios

When the scenario says access must not traverse the public internet, look for private endpoint and DNS-related facts. Private connectivity is not just “allow the subnet” or “open a port.” The client must be able to reach the private IP and resolve the service name correctly.

Reading virtual networking scenarios

Networking scenarios reward layer-by-layer reasoning. Do not jump straight to the most familiar networking service.

Build the path mentally

For a source and destination, ask:

• Are they in the same VNet, peered VNets, on-premises, or public internet?
• What subnet is the source in?
• What route is selected?
• Is an NSG filtering traffic?
• Is a firewall, NVA, or route table involved?
• Is DNS resolving the destination to the expected address?
• Is the destination service firewall allowing traffic?
• Is the required port or protocol allowed?

You do not need to redesign the network unless the scenario asks for design. Most troubleshooting scenarios require finding the specific missing link.

Match the tool to the network problem

Use this reasoning:

• NSG: Allow or deny traffic at subnet or NIC level.
• Route table: Control next hop selection.
• VNet peering: Connect VNets, subject to address and routing considerations.
• VPN gateway or ExpressRoute-style reasoning: Connect Azure to on-premises networks.
• Private endpoint: Provide private access to supported Azure services.
• Private DNS zone: Resolve private endpoint names correctly.
• Azure Firewall or NVA: Centralized inspection and filtering when the scenario requires it.

Example reasoning

Scenario idea: A VM must connect to a storage account by using a private endpoint. The private endpoint exists, but the VM still resolves the storage account to a public address.

Reasoning:

• The private endpoint may exist, but the name resolution path is wrong.
• The symptom is DNS, not necessarily routing or RBAC.
• The likely answer involves private DNS configuration or linking the private DNS zone to the VNet.

Reading compute scenarios

Compute questions often involve VMs, disks, availability, scale, extensions, images, updates, or identity.

Determine the operational intent

Ask whether the scenario is about:

• Creating or resizing a VM
• Moving a VM or disk
• Improving availability
• Scaling out capacity
• Running a script or configuration
• Assigning a managed identity
• Backing up or restoring
• Monitoring health or performance

The same VM can appear in many domains. The scenario’s action verb tells you which domain is active.

Availability choices depend on the failure domain

If the requirement is to protect against host-level failures, zone-level failures, or regional failures, choose the option that matches that level of resilience. Do not choose a regional disaster recovery answer for a local availability requirement unless the scenario requires regional failover.

Least disruptive compute fixes

When troubleshooting a VM, favor the answer that fixes the identified configuration before choosing a rebuild or redeploy option.

For example:

• If boot diagnostics or logs indicate an extension failure, investigate or repair the extension rather than replacing the VM.
• If connectivity fails only from one subnet, inspect NSGs, routes, and DNS before changing the VM size.
• If a disk performance issue is described, match the fix to disk type, size, caching, or configuration as supported by the scenario facts.

Reading backup, restore, and recovery scenarios

AZ-104 backup scenarios usually ask whether you understand the difference between backup, restore, replication, and monitoring.

Identify the recovery goal

Ask:

• Is the goal to restore deleted or corrupted data?
• Is the goal to restore an entire VM?
• Is the goal to retain recovery points?
• Is the goal to fail over to another region or site?
• Is the goal to protect against accidental deletion of the backup configuration itself?

Backup and disaster recovery are related but not identical. A backup answer is usually best when the scenario asks for recovery points and restore. A replication or failover answer is more likely when the scenario asks for continuity during a site or regional outage.

Watch the existing configuration

If a Recovery Services vault, backup policy, or protected item already exists, the question may be asking for a configuration change rather than a new deployment. Identify whether the answer should create protection, modify retention, trigger a backup, restore data, or verify job status.

Reading monitoring and logging scenarios

Monitoring scenarios frequently distinguish between metrics, logs, alerts, diagnostic settings, and activity records.

Decide what needs to be observed

Ask:

• Is the scenario about resource performance, such as CPU, storage latency, or availability?
• Is it about platform operations, such as who changed a resource?
• Is it about querying logs across resources?
• Is it about sending data to a workspace, storage account, or event hub?
• Is it about triggering a notification or automated action?

Match the monitoring feature to the outcome

Use this quick mapping:

• Metrics: Numeric time-series signals for performance and health.
• Activity log: Subscription-level management events.
• Resource logs: Service-specific operational details.
• Diagnostic settings: Route platform logs and metrics to destinations.
• Log Analytics workspace: Store and query logs.
• Alerts: Notify or trigger actions when conditions are met.
• Action groups: Define who or what is notified or invoked.

Example reasoning

Scenario idea: An administrator must be notified when a VM’s CPU exceeds a threshold.

Reasoning:

• The desired outcome is notification on a condition.
• The signal is a metric.
• The answer should configure a metric alert and notification action, not merely enable log collection.

Reading implementation-order scenarios

Some AZ-104 questions ask what to do first, next, or in what order. These require dependency reasoning.

Find the dependency chain

Common Azure dependency patterns include:

• Create a resource group before deploying resources into it.
• Create or select a VNet and subnet before attaching NICs or private endpoints.
• Create a Log Analytics workspace before sending diagnostic data to it.
• Create a vault and policy before enabling backup for a protected item.
• Configure identity before assigning permissions to that identity.
• Configure DNS linkage when private endpoint name resolution is required.
• Assign policy at the correct scope before expecting enforcement or audit at that scope.

When answer choices contain valid tasks, choose the one that must occur before the others can work.

Do not overbuild

If the question asks for the minimum steps, avoid adding services that are not required by the stated goal. For example, do not add a firewall, gateway, or new VNet if a targeted NSG, DNS, route, role assignment, or diagnostic setting directly solves the problem.

Reading troubleshooting scenarios

Troubleshooting questions are decision questions, not free-form investigations. Your job is to choose the next most useful step or the most likely fix from the provided facts.

Use a simple troubleshooting ladder

1. Confirm the affected scope: one user, one VM, one subnet, one region, or all resources.
2. Identify the layer: identity, network, compute, storage, policy, backup, or monitoring.
3. Match the symptom to a configuration point.
4. Prefer the least disruptive verification or fix.
5. Avoid destructive changes unless the scenario proves they are necessary.

Symptom interpretation examples

If only one user cannot manage resources:

• Think role assignment, scope, group membership, or directory identity state.

If all users cannot deploy a resource type in a subscription:

• Think policy, quota-like constraints if explicitly stated, provider registration if relevant, or subscription-level governance.

If one VM cannot reach a service but another VM in a different subnet can:

• Think subnet-level NSG, route table, DNS, or service firewall configuration.

If monitoring data is not available in Log Analytics:

• Think diagnostic settings, agent or data collection configuration where applicable, workspace selection, or data source configuration.

If backup is not occurring:

• Think vault association, backup policy, protected item state, permissions, or job failures based on the scenario facts.

Handling “most cost-effective” and “minimum effort” wording

AZ-104 scenarios often include efficiency constraints. Treat them carefully.

Minimum cost

A minimum-cost answer must still satisfy the technical requirement. Do not choose a cheaper option that fails availability, retention, security, or performance needs.

Cost reasoning usually favors:

• Using existing resources when they meet the requirement
• Applying configuration changes instead of deploying unnecessary new infrastructure
• Selecting appropriate redundancy or availability rather than excessive resilience
• Automating repeatable tasks without overengineering the environment

Minimum administrative effort

Minimum effort usually favors native Azure features, built-in roles, templates, policies, or centralized configuration. But it does not justify broad permissions or insecure shortcuts if the scenario requires least privilege or private access.

Minimum downtime

Minimum downtime means avoid answers that require unnecessary rebuilds, deletions, or resource recreation. Look for online configuration changes, staged migration, snapshots or backups, failover mechanisms, or scoped network changes when the scenario supports them.

How to evaluate answer choices

When you read the options, do not ask, “Have I seen this feature before?” Ask, “Does this option satisfy the exact requirement?”

For each choice, test it against five filters:

• Requirement fit: Does it produce the requested outcome?
• Scope fit: Is it applied to the correct tenant, subscription, resource group, resource, subnet, or workspace?
• Security fit: Does it follow least privilege and avoid unnecessary exposure?
• Operational fit: Does it minimize downtime, disruption, and manual effort when required?
• Completeness: Does it include all necessary parts, such as DNS with private endpoints or action groups with alerts?

If an option is familiar but fails one of these filters, eliminate it.

Mini examples for final review

Example 1: Access control

A group must manage virtual machines in one resource group. They must not manage resources in other resource groups.

Strong reasoning:

• Goal: Allow VM management.
• Scope: One resource group.
• Constraint: No broader access.
• Likely answer: Assign an appropriate Azure RBAC role at the resource group scope.
• Avoid: Tenant-level directory roles, subscription-wide Owner, or unrelated policies.

Example 2: Governance enforcement

All newly created resources in a subscription must include a required tag.

Strong reasoning:

• Goal: Enforce a configuration rule.
• Scope: Subscription.
• Control: Azure Policy.
• Avoid: RBAC, because access control does not enforce tagging by itself.

Example 3: Private service access

A VM must access a storage account without using the public internet. A private endpoint is planned.

Strong reasoning:

• Goal: Private access.
• Needed elements: Private endpoint, allowed network path, and correct private name resolution.
• Avoid: Only changing an NSG if DNS still resolves to the public endpoint.

Example 4: Alerting

Administrators must receive an email when a VM performance metric crosses a threshold.

Strong reasoning:

• Goal: Notification when a metric condition occurs.
• Control: Azure Monitor alert rule plus an action group.
• Avoid: Only sending logs to a workspace if no alert condition or notification is configured.

Example 5: Backup versus replication

A VM must be restorable to a previous point after accidental corruption.

Strong reasoning:

• Goal: Restore from recovery points.
• Control: Backup configuration and restore process.
• Avoid: Treating every recovery scenario as regional failover.

A compact checklist for AZ-104 scenarios

Before selecting your answer, confirm:

• I know the administrative scope.
• I can state the goal in one sentence.
• I separated current state from desired state.
• I identified the hard constraint.
• I matched the requirement to the correct Azure feature.
• I checked least privilege and least disruption.
• I considered whether the issue is identity, network, compute, storage, governance, backup, or monitoring.
• I eliminated answers that solve a different layer of the problem.
• I chose the answer that is complete, scoped, and defensible.

Practice method for efficient final review

Use scenario practice deliberately, not just as a score check.

For each missed or uncertain question, write three short notes:

• Decision point: What was the scenario really asking?
• Evidence: Which fact in the scenario controlled the answer?
• Rule: What Azure administration principle should I reuse next time?

Then group your misses by domain: identity, governance, storage, networking, compute, backup, or monitoring. Use topic drills to repair weak areas, then return to timed scenario sets and full mock exams to practice pacing and decision discipline.