Microsoft AZ-104: A Practical Study Plan

AZ-104 rewards candidates who can operate Azure, not people who have only memorized service descriptions. Microsoft’s current objectives, effective April 17, 2026, cover identity and governance, storage, compute, virtual networking, monitoring, backup, and recovery. The practical way to study AZ-104 is therefore to build a small environment, administer it repeatedly, break it on purpose, and learn to diagnose why it behaves differently from what you expected.

The associated Azure Administrator credential assumes familiarity with PowerShell, Azure CLI, the Azure portal, ARM or Bicep deployments, Microsoft Entra ID, operating systems, virtualization, and networking. A study plan that never moves beyond reading leaves too many of those skills untested. Hands-on work should begin early, even if the lab environment is modest.

A useful sequence is to build one administration environment and keep extending it. Start with identity and governance, add storage, deploy compute, connect the network, enable monitoring, and finish with backup and recovery. This creates the same dependency chain an administrator encounters in production and reduces the tendency to study each objective as a separate vocabulary list.

Week one should establish identity, scope, and governance habits

Begin with users, groups, subscriptions, resource groups, role assignments, tags, locks, budgets, and policy. The important distinction is between identity, authorization, and governance. Microsoft Entra ID and Azure RBAC determine who can sign in and what they can do, while policy evaluates or constrains resource configuration. Candidates often know those definitions yet still struggle when a scenario combines them.

Create a resource group and assign two different roles at different scopes. Test inheritance. Add a lock and observe which actions are blocked. Apply a simple policy, intentionally deploy something that violates it, and inspect the compliance result. Then read Azure Policy with the lab still fresh. The goal is to be able to explain the control that caused an outcome instead of guessing from a list of Azure features.

Storage practice should combine authorization, networking, and resilience

The storage domain looks compact until access and resilience are combined. Build a storage account, create blob containers and a file share, test identity-based access, generate a SAS, rotate an access key, and change network restrictions. Ask what a client needs at each layer: valid authentication, sufficient authorization, and an allowed network path. A failure at any one of those layers can look like “storage is broken” unless you inspect the right control.

Then compare redundancy and lifecycle choices. Azure Storage redundancy becomes easier to remember when you connect each option to the failure it is designed to survive. Add versioning, soft delete, or lifecycle rules and restore something you deliberately removed. Recovery operations make retention settings far more concrete than memorizing feature names.

Compute study should move from a VM to repeatable deployment

Deploy a virtual machine, attach and resize disks, change its size, place it in an availability design, and inspect what can or cannot be changed without downtime. Then compare that operational model with App Service, Container Instances, and Container Apps. AZ-104 expects administrators to recognize service boundaries: the correct answer is often the option that meets the requirement while minimizing unnecessary infrastructure management.

Do not postpone infrastructure as code. Export a template or write a small Bicep deployment, change a parameter, and redeploy. You do not need to become a full-time platform engineer, but you should be comfortable reading declarations and mapping them to real resources. Repeatability is part of administration because manual portal work does not scale across environments.

Networking deserves more lab time than its percentage suggests

Build two virtual networks with multiple subnets, peer them, attach network security groups, add a route table, and test name resolution. The value of a virtual network peering lab is not the successful connection; it is learning which setting to inspect when communication fails. Change one control at a time and predict the result before testing.

Practice tracing a packet conceptually from source to destination. Check addressing, DNS, route selection, NSG evaluation, service endpoints or private endpoints, and the target service itself. When every connectivity question becomes “what is the path and where can it be interrupted?”, networking stops feeling like a collection of unrelated portal pages. Candidates who want deeper networking responsibility can later build on this foundation with AZ-700.

Monitoring should be configured before the lab is considered complete

An administrator should never treat deployment as the end state. Enable diagnostic settings, inspect metrics, collect logs, create an alert, and route it through an action group. A focused exercise using Azure Monitor alerts and action groups helps connect telemetry to an operational response. The useful question is not “where is the alert menu?” but “what signal would reveal this failure quickly enough to act?”

Practice the distinction between metrics and logs. A threshold on CPU utilization is different from a query that detects a specific event pattern. Use resource insights and Network Watcher where appropriate, and learn to recognize when a scenario is asking for observation, diagnosis, or automated notification. Those are related tasks but not interchangeable answers.

Backup and recovery should be tested, not merely configured

Create a backup policy, protect a workload, and perform a restore. Review the purpose of Recovery Services vaults, Backup vaults, and Site Recovery in the context of the workload being protected. Candidates often remember product names but lose points when a scenario asks whether the requirement is file recovery, workload backup, regional failover, or business continuity.

Build a small failure story around each control. If a file is deleted, what recovers it? If a VM becomes unusable, what is the restoration process? If a region is unavailable, what changes? Thinking in recovery objectives forces you to connect configuration with the outcome the business actually needs.

Use mixed scenarios to turn isolated knowledge into administrator judgment

After the individual domains are comfortable, combine them. Deploy a workload into a governed resource group, assign access, restrict its storage account, place the application behind network controls, enable monitoring, and configure backup. Then deliberately introduce a failure: remove a permission, deny traffic, change DNS, violate policy, or disable a diagnostic setting. Diagnose the problem without immediately looking at the answer.

This mixed-lab phase is what prepares you for questions that cross domains. A user unable to modify a VM might have the wrong RBAC scope. A healthy application may be unreachable because of networking. A deployment may fail because governance blocked it. An apparently successful resource may still fail an operational requirement because monitoring or recovery was never configured.

A useful mid-plan checkpoint is to rebuild part of the environment from a blank subscription or a fresh resource group without following your original notes. Rebuilding exposes which actions you genuinely understand and which were completed by imitation the first time. It also forces you to remember dependencies: a VM needs networking, an application may need a managed identity, a private storage design needs name resolution, and a monitoring rule needs telemetry to exist before it can alert.

Keep a troubleshooting notebook, but record causes rather than click paths. Instead of writing “open Networking and change setting X,” record “traffic was blocked because the effective NSG rule denied the destination port.” Instead of “fix storage in the portal,” record “authorization succeeded, but the network firewall rejected the client.” This makes your notes portable across interface changes and turns them into a model of Azure behavior.

Also practice cost and governance awareness while you build. Delete unused resources, set budgets, and notice which services continue incurring charges when a lab is idle. Administrators are responsible for operational control, not merely technical reachability, and the exam frequently frames resource choices around organizational constraints rather than pure functionality.

Finish with an objective-by-objective readiness test

During the final week, turn Microsoft’s objective list into a task checklist. For each line, mark whether you can explain it, configure it, troubleshoot it, and choose it in a scenario. Any topic you can only define should return to the lab. Command-line work should receive the same treatment: you do not need every parameter memorized, but you should be able to read PowerShell or Azure CLI and understand what resource and operation are involved.

Keep the broader career context in view. AZ-305 moves from administration into architecture, while AZ-140 specializes in Azure Virtual Desktop. The best AZ-104 study plan is not one that rushes toward those next exams. It is one that leaves you able to operate an Azure environment coherently. That operational confidence is what makes the certification useful after the test is over, and it is also the strongest preparation for the exam itself.

For candidates comparing Microsoft credentials more broadly, the Microsoft certifications inventory helps place Azure administration beside networking, architecture, security, data, and AI specialties. Use that context only after the AZ-104 foundation is solid; the immediate goal is disciplined administration, not collecting adjacent exam names.

One final technique is to narrate your troubleshooting aloud. State the symptom, the most likely layer, the evidence you would inspect, the change you would make, and the validation step. If you cannot explain that chain cleanly, the topic is not yet operational knowledge. This is especially useful for identity and networking, where random configuration changes can accidentally fix a lab without teaching you why it failed.

• Category: All Certifications Certifications