Microsoft AZ-104 Azure Administrator Readiness Matrix: How to Diagnose Your Weakest Exam Domains

 

Most AZ-104 candidates do not need another generic list of Azure services. They need a reliable way to determine which parts of Azure administration they can actually perform, which parts they only recognize, and which exam domains are consuming the largest share of their mistakes. That is the purpose of an AZ-104 readiness matrix.

Microsoft’s current AZ-104 skills outline, measured from April 17, 2026, organizes the exam around five major areas: managing Azure identities and governance at 20–25 percent, implementing and managing storage at 15–20 percent, deploying and managing Azure compute resources at 20–25 percent, implementing and managing virtual networking at 15–20 percent, and monitoring and maintaining Azure resources at 10–15 percent. Those percentages help with prioritization, but they do not tell you whether you are ready.

Readiness is better measured through evidence. Can you interpret an existing configuration? Can you predict the effect of a change? Can you choose the right Azure control for a stated requirement? Can you troubleshoot when the obvious configuration looks correct? Can you complete the task through the Azure portal and still explain how you would approach it with PowerShell, Azure CLI, ARM templates, or Bicep where relevant?

ExamSnap already has broader AZ-104 preparation coverage, including a AZ-104 overview, a AZ-104 prep guide, and an article on AZ-104 study methods. This article deliberately takes a narrower approach: build a diagnostic matrix that tells you where the next hour of study should go.

The readiness matrix uses four levels, not one score

For every skill area, rate yourself at one of four levels.

Level 0: unfamiliar

You do not recognize the service, configuration, or task well enough to explain it. You may have seen the name but cannot describe its purpose confidently.

Level 1: conceptual

You understand what the service or feature does, but you would need documentation or a walkthrough to configure it. You can answer simple definition questions but struggle with scenarios.

Level 2: operational

You can configure the feature in a lab, interpret common settings, and solve straightforward administration tasks. You understand the consequences of the main options.

Level 3: scenario-ready

You can compare alternatives, troubleshoot misconfiguration, predict dependencies, work across connected Azure services, and explain why one solution fits a requirement better than another.

For AZ-104, Level 3 is the target for high-frequency skills. You do not need expert depth in every edge case, but the exam is role-based. Recognition alone is weak evidence.

Add a second dimension: confidence versus proof

Candidates frequently overrate skills because they feel familiar. A better matrix records both your rating and the evidence supporting it.

Acceptable evidence could include:

• completed a configuration from a blank environment without a step-by-step guide;
• troubleshot a deliberately broken configuration;
• explained the task aloud without notes;
• interpreted an existing ARM template or Bicep file;
• answered several fresh scenario questions correctly and explained the distractors;
• reproduced the task with both the portal and a command-line or declarative method where appropriate;
• identified dependencies between the service and identity, networking, storage, monitoring, or governance.

If your rating is Level 3 but your only evidence is “watched a video,” lower the rating.

Matrix 1: Manage Azure identities and governance — 20–25 percent

This domain covers Microsoft Entra users and groups, licensing, external users, self-service password reset, Azure roles and scopes, Azure Policy, resource locks, tags, resource groups, subscriptions, cost management, Azure Advisor recommendations, and management groups.

It is one of the largest parts of the exam and a common source of scenario questions because identity and governance affect almost every Azure resource.

Diagnostic area: Microsoft Entra users and groups

Ask yourself whether you can:

• create and manage users and groups;
• distinguish group types and membership approaches at an administrative level;
• manage user and group properties;
• reason about licensing implications;
• manage external users;
• configure and troubleshoot self-service password reset at the level expected of an Azure administrator.

A Level 1 candidate knows what Microsoft Entra ID is. A Level 3 candidate can look at a scenario involving an external user, group-based access, licensing, and password reset and identify which configuration should change.

If this part is weak, the planned Entra and governance is the natural next destination.

Diagnostic area: Azure RBAC and scope

This is one of the most important readiness tests in AZ-104.

Can you explain the relationship among management groups, subscriptions, resource groups, and individual resources? Can you predict how a role assignment at one scope affects child resources? Can you distinguish a role definition from a role assignment? Can you inspect effective access rather than assuming the most visible assignment is the only one?

Create a scenario with three resource groups, two teams, and one administrator. Assign roles at different scopes and calculate who can perform which actions. Then change one assignment and predict the effect before checking the portal.

If this exercise feels slow, RBAC should remain high on your study list.

Diagnostic area: Azure Policy versus RBAC versus locks

These controls are easily confused because all three influence what happens to Azure resources.

RBAC controls who can perform actions. Azure Policy evaluates or enforces resource compliance and configuration rules. Resource locks help protect resources from deletion or modification depending on the lock type.

A scenario-ready candidate can tell which control fits the requirement without choosing the strongest-sounding option.

If the requirement is “Only the network team should change virtual networks,” think authorization. If it is “Every storage account must meet a defined configuration requirement,” think policy. If it is “Prevent accidental deletion of this production resource,” think locks.

Diagnostic area: subscriptions, management groups, tags, and cost controls

Can you organize subscriptions under management groups and explain why governance at a higher scope matters? Can you use tags for organization and reporting without assuming tags are security boundaries? Can you manage resource groups and subscriptions with an understanding of scope? Can you configure budgets and alerts and interpret Azure Advisor cost recommendations?

This section tests whether you can manage Azure as an environment rather than as a collection of individual resources.

Readiness score for identity and governance

Give yourself separate 0–3 ratings for:

• Entra users/groups/external identities;
• SSPR and identity administration;
• RBAC and scopes;
• Azure Policy;
• locks and tags;
• subscriptions, resource groups, and management groups;
• cost alerts, budgets, and Advisor recommendations.

Do not average the scores yet. Circle every Level 0 or Level 1 item. Those are remediation tasks.

Matrix 2: Implement and manage storage — 15–20 percent

Storage questions can look straightforward until access, networking, redundancy, lifecycle, encryption, and data-management features appear in the same scenario.

The current skills include configuring storage firewalls and virtual networks, shared access signatures, stored access policies, access keys, identity-based access for Azure Files, storage accounts, redundancy, object replication, encryption, Storage Explorer, AzCopy, Azure Files, Blob Storage, tiers, soft delete, snapshots, lifecycle management, and versioning.

Diagnostic area: storage access

Can you distinguish account keys, SAS, stored access policies, and identity-based access? Can you explain the security consequence of each?

A Level 1 candidate knows that SAS provides delegated access. A Level 3 candidate can decide whether a scenario should use identity-based access, a constrained SAS, a stored access policy, or another method based on who needs access, for how long, and with what permissions.

Also test networking. If a storage account is protected by network rules, can you determine why an application can authenticate correctly but still cannot reach the service?

Diagnostic area: redundancy

You should understand the purpose and trade-offs of Azure Storage redundancy options well enough to map them to availability and disaster-recovery requirements. Avoid memorizing only acronyms. Ask what failures the design must tolerate and whether replication crosses zones or regions.

Create scenarios with different requirements: local hardware failure, zone failure, regional outage, read access to a secondary region, or cost sensitivity. Choose a redundancy approach and defend the trade-off.

Diagnostic area: Blob Storage and Azure Files

Can you create and configure containers and file shares? Can you reason about access, tiers, snapshots, soft delete, versioning, and lifecycle rules? Can you tell when a lifecycle rule is a better answer than a manual administrative process?

This topic should feel operational, not theoretical.

The planned Azure Storage deep dive will provide a focused follow-on if storage remains one of your weaker matrix rows.

Diagnostic area: tools and data movement

Know when Azure Storage Explorer or AzCopy is appropriate. You do not need to memorize every command-line switch, but you should be comfortable with the purpose of the tools and the types of data-management tasks they support.

Readiness score for storage

Rate yourself 0–3 for:

• network and firewall access;
• SAS and stored access policies;
• keys and identity-based access;
• storage account configuration;
• redundancy and replication;
• encryption;
• Blob Storage and Azure Files;
• tiers, lifecycle, soft delete, snapshots, and versioning;
• Storage Explorer and AzCopy.

If you score high on definitions but low on scenario selection, build labs around access and redundancy first.

Matrix 3: Deploy and manage Azure compute resources — 20–25 percent

Compute is another large domain. The current outline includes ARM templates and Bicep, virtual machines, disks, availability zones and sets, Virtual Machine Scale Sets, Azure Container Registry, Azure Container Instances, Azure Container Apps, App Service plans, scaling, TLS and certificates, custom DNS names, backup, networking, and deployment slots.

This domain often exposes candidates who have used one compute service heavily but ignored the others.

Diagnostic area: ARM templates and Bicep

You should be able to interpret and modify existing templates, not merely recognize that infrastructure as code exists.

Can you read parameters, resources, dependencies, and common property structures? Can you make a small change and predict which Azure resource is affected? Can you deploy a template or Bicep file and troubleshoot a simple failure? Can you explain why declarative deployment improves repeatability?

A useful readiness exercise is to export or inspect a simple deployment and identify which parts should become parameters before reuse.

Diagnostic area: virtual machines

Can you create and configure a VM, manage size and disks, reason about encryption at host, move a VM where supported, and design for availability using zones or availability sets? Can you distinguish scaling a single VM vertically from using a scale set to manage multiple instances?

Scenario-ready knowledge also includes dependencies: networking, NSGs, disks, identity, monitoring, and backup.

If you configure a VM successfully but cannot troubleshoot why it lacks connectivity or why an application is unavailable, your compute and networking knowledge is not yet integrated.

Diagnostic area: containers

Can you explain the administrative role of Azure Container Registry, Azure Container Instances, and Azure Container Apps? Can you provision containers and reason about sizing and scaling?

Do not confuse being able to explain containers conceptually with being ready for an Azure administration task. Create a small container workload, store an image appropriately, deploy it, and inspect its configuration.

Diagnostic area: App Service

Can you create an App Service plan and app, configure scaling, certificates and TLS, custom DNS, backup, networking, and deployment slots?

Deployment slots are a good readiness test because they require you to think about application lifecycle rather than only resource creation. Networking is another common integration point because an app may be deployed correctly but unable to reach a required private resource.

The planned Azure compute guide is the next step if VMs, containers, or App Service remain fragmented in your understanding.

Readiness score for compute

Rate yourself for:

• ARM template interpretation and modification;
• Bicep interpretation and modification;
• virtual machine creation and configuration;
• disks and VM sizing;
• availability zones and sets;
• Virtual Machine Scale Sets;
• Container Registry;
• Container Instances and Container Apps;
• App Service plans and applications;
• scaling;
• TLS/certificates and custom DNS;
• App Service networking, backups, and slots.

A broad domain requires multiple scores. One “compute = 8/10” number hides too much.

Matrix 4: Implement and manage virtual networking — 15–20 percent

Networking is one of the strongest predictors of whether Azure administration feels intuitive or confusing. Many Azure services are deployed correctly but fail because routing, DNS, NSGs, peering, endpoints, or load balancing are misunderstood.

The current outline includes virtual networks and subnets, peering, public IP addresses, user-defined routes, connectivity troubleshooting, NSGs, application security groups, effective security rules, Azure Bastion, service endpoints, private endpoints, Azure DNS, internal and public load balancers, and load-balancing troubleshooting.

Diagnostic area: VNets, subnets, and peering

Can you design address spaces without overlap? Can you create subnets for different workloads? Can you configure peering and explain that peering relationships have specific behavior rather than turning two networks into one flat network automatically?

When connectivity fails, can you distinguish an address-space problem from NSG, route, DNS, endpoint, or application issues?

Diagnostic area: NSGs and effective rules

Do not stop at creating an NSG. Be able to interpret effective security rules and reason about rule priority, source, destination, service, and direction.

Create a scenario where a VM should accept one type of traffic from one subnet and deny unrelated access. Write the required rule logic before configuring it.

If a question gives several NSG rules, calculate the effective outcome rather than guessing from the most restrictive-looking line.

Diagnostic area: service endpoints versus private endpoints

This is a common comparison area because both relate to secure access to Azure PaaS services but work differently.

A readiness test should require you to explain what changes in network path, addressing, and exposure when each is used. Do not memorize “private endpoint is more private” without understanding why.

Diagnostic area: Azure Bastion

Can you explain why Bastion may reduce the need to expose VM management ports directly to the internet? Can you place it correctly in an administrative-access scenario?

Diagnostic area: Azure DNS and load balancing

Can you configure Azure DNS records and reason about name resolution? Can you distinguish an internal load balancer from a public one and troubleshoot when traffic is not distributed as expected?

The strongest candidates connect load balancing to backend health, network rules, frontend configuration, probes, and application state rather than assuming every failure is a load-balancer problem.

Readiness score for networking

Rate yourself for:

• VNet and subnet design;
• peering;
• public IPs;
• user-defined routes;
• connectivity troubleshooting;
• NSGs and application security groups;
• effective-rule interpretation;
• Bastion;
• service endpoints;
• private endpoints;
• Azure DNS;
• internal and public load balancers;
• load-balancing troubleshooting.

Any Level 0 or Level 1 in networking deserves attention because networking errors often spill into compute, storage, and monitoring scenarios.

Matrix 5: Monitor and maintain Azure resources — 10–15 percent

This is the smallest weighted domain, but it is where administration becomes observable and recoverable. The current outline covers Azure Monitor metrics and logs, log queries, alert rules, action groups, alert processing rules, Azure Monitor Insights, Network Watcher, Connection Monitor, Recovery Services vaults, Backup vaults, backup policies, restore operations, Site Recovery, failover, and backup reports and alerts.

Diagnostic area: Azure Monitor

Can you distinguish metrics from logs and explain which is more appropriate for a given investigation? Can you configure diagnostic or log settings at the appropriate level? Can you query logs and interpret results rather than only open a dashboard?

Can you create an alert rule and explain the relationship among the monitored signal, condition, action group, and alert processing behavior?

A Level 3 candidate can start with “users report intermittent failures” and choose an evidence path instead of clicking randomly through monitoring blades.

Diagnostic area: Insights and Network Watcher

Can you use Azure Monitor Insights to interpret the health or performance of common resources? Can you use Network Watcher and Connection Monitor to investigate connectivity?

These are practical troubleshooting skills. Build a lab with a deliberately broken connection and use evidence to isolate whether the issue belongs to DNS, routing, NSG rules, endpoint configuration, or application behavior.

Diagnostic area: backup and restore

Can you create the appropriate vault, configure policy, perform backup and restore operations, and interpret alerts and reports? More importantly, can you distinguish backup from high availability and disaster recovery?

A backup does not keep a failed production service continuously available. A replicated service does not replace every retention requirement. Know the recovery objective behind the tool.

Diagnostic area: Azure Site Recovery

Can you explain when Site Recovery is used, configure protection at an administrative level, and reason about failover to a secondary region?

A readiness test should include both configuration and decision making: when would Site Recovery address the requirement better than an ordinary backup restore?

Readiness score for monitoring and recovery

Rate yourself for:

• metrics;
• log settings and collection;
• log queries;
• alerts, action groups, and processing rules;
• Azure Monitor Insights;
• Network Watcher;
• Connection Monitor;
• Recovery Services and Backup vaults;
• backup policies;
• restore operations;
• Site Recovery;
• failover;
• backup monitoring and reporting.

Use proof artifacts for every readiness score

A readiness matrix becomes much more reliable when every Level 2 or Level 3 rating has a piece of evidence attached to it. That evidence does not need to be a formal portfolio. It can be a saved command, a configuration screenshot, a short Bicep file, a diagram, a query, a troubleshooting note, or a written explanation of why one Azure control was selected over another.

For identity and governance, evidence might be an RBAC scenario showing scope inheritance, an Azure Policy assignment with the expected compliance result, or an explanation of why a lock does not replace authorization. For storage, it might be a storage account protected by network rules, a constrained SAS, a lifecycle rule, and a successful data-transfer task. For compute, it might be a modified Bicep deployment, a VM availability design, a container deployment, or an App Service slot swap you can explain.

Networking evidence should include more than “VNet created.” Capture the address plan, peering or route decision, effective NSG rules, DNS behavior, and a troubleshooting case. Monitoring evidence should include a metric, a log query, an alert rule, and a recovery operation. Backup is not proven by a green backup job alone; a restore or recovery test is much stronger evidence.

This approach mirrors the current AZ-104 role profile. Microsoft describes the Azure administrator as someone who implements, manages, and monitors Azure environments across identity, storage, compute, networking, security, and governance. Readiness should therefore look like administration, not recognition.

Do not average the five domains too early

A simple average hides dangerous weaknesses.

Suppose your domain ratings are:

• Identity and governance: 2.7
• Storage: 2.6
• Compute: 2.5
• Networking: 1.4
• Monitoring and recovery: 2.8

The average looks respectable, but networking is still a major risk. Because networking also affects compute, storage, private endpoints, App Service, and troubleshooting, that weakness may create failures outside the networking domain.

Use the matrix to identify bottlenecks, not to create a flattering overall score.

Add a dependency score

Some skills affect several domains. Mark these as high-dependency topics:

• Azure RBAC and scope;
• Microsoft Entra identity;
• virtual networking and DNS;
• NSGs and connectivity;
• ARM/Bicep interpretation;
• Azure Monitor and logs;
• storage access;
• resource organization and governance.

A weakness in one of these topics deserves extra priority because it can appear in several different contexts.

Build a red-yellow-green remediation map

After rating every skill, convert the matrix into three categories.

Red: immediate remediation

Level 0 or Level 1 skills, especially in high-weight or high-dependency areas.

Yellow: scenario reinforcement

Level 2 skills that work in a clean lab but become uncertain when combined with other services.

Green: maintenance

Level 3 skills supported by recent hands-on evidence and fresh scenario performance.

Spend most study time on red, then yellow. Green topics still need periodic mixed review, but they should not consume the same time as genuine gaps.

Convert every red item into a lab

Reading is useful for understanding. Hands-on work provides stronger evidence for a role-based exam.

Turn weaknesses into small tasks:

• RBAC weak: build several scopes and role assignments, then inspect effective access.
• Policy weak: create a policy scenario, assign it, and observe compliance behavior.
• Storage access weak: compare identity-based access, SAS, and network restrictions in a lab.
• Bicep weak: modify a small deployment and redeploy it.
• VM availability weak: deploy resources across availability constructs and explain the failure assumptions.
• NSG weak: build rules, predict effective access, then test connectivity.
• Private endpoints weak: create a PaaS connectivity scenario and observe DNS and network behavior.
• Monitoring weak: generate a condition, collect evidence, create an alert, and validate notification behavior.
• Backup weak: perform an actual restore instead of stopping after policy creation.

The planned AZ-104 labs expands this hands-on approach across the exam.

Diagnose mistakes by layer

When you miss an AZ-104 practice question, classify the mistake by layer.

Azure-service knowledge

You did not know what the service or feature does.

Scope and hierarchy

You misunderstood management group, subscription, resource group, or resource scope.

Identity and permission

You confused authentication, RBAC, data-plane permissions, or effective access.

Network path

You overlooked NSGs, routes, DNS, endpoints, peering, or addressing.

Configuration dependency

You knew the main service but missed a prerequisite or connected service.

Availability and recovery

You selected a backup, redundancy, scaling, or disaster-recovery feature that did not match the requirement.

Tool or interface

You understood the outcome but could not interpret a template, Bicep file, portal configuration, CLI command, or PowerShell operation.

This classification makes remediation much faster than simply rereading a chapter called “Azure networking.”

Use scenario proof instead of memorized facts

For every skill that you rate Level 3, challenge yourself with a scenario that changes one condition.

If you know how to assign RBAC at a resource group, what changes when access should apply to several subscriptions? If you know how to use a SAS token, what changes when the requirement says access should be tied to an organizational identity? If you can create a VM, what changes when the requirement demands zone resilience? If you can reach a storage account publicly, what changes when public access must be restricted? If you can monitor a metric, what changes when the investigation requires searching historical event detail?

A real Level 3 skill survives these variations.

Create cross-domain scenarios

The best AZ-104 readiness test mixes domains because real Azure administration does.

Scenario 1: private application storage

An App Service application needs access to a storage account without exposing the storage service publicly. The application also needs least-privilege authorization and monitoring.

This scenario touches compute, storage, networking, identity, and monitoring.

Scenario 2: production VM recovery

A production VM must remain resilient to infrastructure failure, be backed up, and be recoverable after a larger regional event.

This touches compute availability, backup, Site Recovery, networking, and monitoring.

Scenario 3: subscription governance

A company has several subscriptions for different departments. Administrators need consistent tagging, restricted regions, controlled permissions, and cost visibility.

This touches management groups, Azure Policy, RBAC, tags, budgets, and governance.

Scenario 4: connectivity failure

A VM can resolve a hostname but cannot reach a private PaaS resource after a network change.

This may touch private endpoints, DNS, NSGs, routes, service configuration, and monitoring tools.

If your knowledge falls apart when domains combine, return those dependencies to the yellow or red category.

Cross-domain scenario: diagnose a private application path

Assume an App Service must access a storage account without exposing that storage account publicly. Users report intermittent application failures after a network change.

A weak approach starts changing settings randomly. A stronger Azure-administrator approach traces dependencies. Confirm the application’s networking configuration. Check whether the storage service is being reached through the expected endpoint. Review DNS resolution, private-endpoint configuration if used, subnet and VNet integration, storage firewall rules, identity permissions, and relevant monitoring data. Determine whether the failure is name resolution, network reachability, authorization, service configuration, or an application problem.

This single scenario crosses compute, networking, storage, identity, and monitoring. If you can only solve the problem when each domain is presented separately, the matrix is overstating readiness. Cross-domain tasks are therefore one of the best ways to distinguish Level 2 operational familiarity from Level 3 scenario readiness.

Readiness should be current, not historical

Azure changes, and Microsoft periodically updates role-based exam skills. A candidate who studied an older AZ-104 outline should verify that preparation still matches the skills measured for the intended exam date.

The current outline measured from April 17, 2026 keeps the same five broad skill areas, with updates inside parts of the blueprint. Your readiness matrix should therefore be built from the current objective list rather than from an old course table of contents.

This is particularly important when older ExamSnap articles are used for conceptual support. The underlying Azure administration principles may remain useful, but your final checklist should match the current exam scope.

A weekly AZ-104 readiness review

Once the matrix is built, update it weekly.

Step 1: choose two red items

Select the highest-weight or highest-dependency weaknesses.

Step 2: perform hands-on remediation

Build, configure, or troubleshoot the skill rather than only reading about it.

Step 3: explain the configuration

Describe what you changed, why, what dependencies exist, and what would break if one setting changed.

Step 4: validate with fresh scenarios

Use questions or self-created scenarios you have not memorized.

Step 5: move the rating only with evidence

Do not change a skill from red to green after watching a lesson. Move it when you can perform and explain it reliably.

Step 6: protect strong areas

Use short mixed reviews to make sure green skills remain available while you repair weaker ones.

This creates a preparation plan that responds to your actual performance.

When are you close to AZ-104 readiness?

You are approaching a strong readiness state when:

• there are no major Level 0 gaps in the current objectives;
• most high-weight and high-dependency skills are Level 2 or Level 3;
• your red list is short and specific;
• networking failures can be diagnosed methodically rather than guessed;
• you can reason about RBAC and scope without drawing the hierarchy every time;
• storage access methods no longer blur together;
• you can interpret basic ARM/Bicep configurations;
• compute choices are connected to availability, networking, and scaling requirements;
• monitoring is part of your troubleshooting method rather than an afterthought;
• you have actually restored data or rehearsed recovery rather than only configuring backup;
• fresh mixed scenarios feel like variations of known administrative problems rather than entirely new material.

The AZ-104 exam can serve as the main exam destination, while the Azure Administrator certification provides the broader credential context. The Microsoft certifications is useful when you want to connect AZ-104 with the wider Microsoft certification ecosystem.

Let evidence—not comfort—choose the next AZ-104 study session

The value of the matrix is that it turns a vague feeling of preparedness into named technical gaps. If effective NSG rules are slow, private endpoints are confusing, Bicep changes are error-prone, or restore operations have never been tested, those become the next tasks. Comfortable topics remain in maintenance mode instead of consuming most of the schedule.

Keep the matrix aligned to the skills measured as of April 17, 2026: identities and governance, storage, compute, networking, and monitoring/recovery. Microsoft expects familiarity with operating systems, networking, servers, virtualization, PowerShell, Azure CLI, the Azure portal, ARM templates or Bicep, and Microsoft Entra ID. A strong readiness state therefore combines service knowledge with the ability to configure, interpret, troubleshoot, monitor, and recover Azure resources.

Move a skill to Level 3 only when you can demonstrate it in a scenario and explain the dependencies. That standard is stricter than “I have seen this before,” but it is far more useful for a role-based exam.