Microsoft AZ-104: A Practical Study Plan for Azure Administrators

The AZ-104 exam rewards people who can operate an Azure environment when the easy path fails: an inherited role assignment grants too much access, an application loses storage connectivity, a network rule blocks a healthy service, or a recovery policy proves inadequate during a restore. Those decisions are related. Strong preparation therefore looks less like memorizing Azure portal screens and more like building, observing, breaking, and repairing a small environment with deliberate constraints.

The current Microsoft AZ-104 exam leads to Microsoft Certified: Azure Administrator Associate. Microsoft’s study guide, with skills effective April 17, 2026, organizes the assessment into five domains: identity and governance (20–25%), storage (15–20%), compute (20–25%), virtual networking (15–20%), and monitoring and maintenance (10–15%). These are weighting ranges, not five fixed percentages. An administrator needs to know how a choice in one domain changes the others, particularly access, routing, availability, recovery, and cost.

Use the official objectives as the coverage contract. This independent study plan turns them into experiments and decisions you can explain, including why plausible alternatives fail. The exam scope changes periodically; check Microsoft’s current AZ-104 study guide and registration details before booking rather than treating an older preparation article as a permanent syllabus.

Build an Azure environment with administrative boundaries

Begin with a subscription you are authorized to use and a small lab resource group. Set a budget alert and a clear naming convention; resource group names, subscription selection, and deployment region should not be afterthoughts. Establish who may create resources, who may read diagnostics, and who may change policy before you deploy workloads. A resource group is a management boundary, not a substitute for the identity and network boundaries of the resources inside it.

Identity questions often combine Microsoft Entra users and groups with Azure resource access. Entra group membership and licensing govern one set of concerns; Azure role-based access control authorizes actions against resources. A user may authenticate successfully but still lack the Azure role required to change a virtual machine. Conversely, a contributor role on a resource group does not make that person a tenant-wide identity administrator. Practice creating a user or test group, granting a narrowly scoped built-in role, inspecting inherited assignments, and removing it. Then document what changed in the effective permission set. Microsoft Entra ID administration and Azure RBAC, Policy, and governance each deserve attention because they solve different access problems.

For the governance experiment, attempt three changes: deploy a resource in an unexpected region, delete a protected resource, and assign an operator read-only access. Ask which control belongs to each requirement. Azure Policy evaluates configuration compliance and can deny selected deployments; a resource lock guards against particular management changes; RBAC controls authorized actions. Tags help organize resources but are not permission boundaries. An exam scenario may describe an outcome without naming the right control, so the valuable skill is selecting the mechanism with the fewest unintended consequences.

Finish this lab by reviewing subscription costs, Azure Advisor recommendations, and a budget alert. Cost management is part of operational governance. Deleting a test resource group can clean up many resources, but first inspect shared or external dependencies and verify that deletion is safe in your own environment.

Storage preparation: choose the access path before the account settings

Storage scenarios usually hide several questions inside one request: which data service fits, which identity can reach it, which network path is permitted, how data is protected against mistakes, and what recovery looks like. Start by comparing Blob Storage for object data with Azure Files for managed file shares. A blob container and an SMB-mounted file share can both store application data, but they are not interchangeable access models.

Create a nonproduction storage account and test two distinct authorization approaches. A short-lived shared access signature delegates specific permissions over a defined period; identity-based authorization is preferable when an application can use a managed identity and the target service supports the desired operation. Shared account keys provide broad access and should not be the casual default. Combine identity decisions with storage firewall rules, private networking requirements, and the service endpoint model instead of assuming that a successful token automatically means a client can connect.

Then compare locally redundant and geo-redundant options against an actual recovery requirement. Geographic redundancy does not mean every accidental deletion will be reversible, and replication is not a replacement for versioning, soft delete, or backup where those controls are applicable. Test blob versioning and soft-delete behavior with a disposable file. For Azure Files, distinguish share snapshots from ordinary blob versioning. Lifecycle policies and blob access tiers help manage cost but can change retrieval expectations. The Blob and Azure Files operations coverage should be read alongside your own restore results rather than as an isolated vocabulary list.

A useful troubleshooting sequence is: does the name resolve; can the client reach the service endpoint; does the chosen authentication method work; is the relevant authorization present; and is the object, container, or share in the expected state? Record the first failing step. This distinction prevents wasted changes to account keys when the actual problem is a restrictive firewall or a private DNS configuration.

Compute and repeatable deployment: understand the operating model

Deploy one small virtual machine, inspect its disk and network dependencies, and then modify a setting using a repeatable deployment description. Microsoft expects candidates to interpret, modify, and deploy Azure Resource Manager templates or Bicep files, not merely recognize their file extensions. When a deployment fails, separate malformed template input, missing permissions, invalid resource properties, regional availability, quotas, and existing resource conflicts.

Learn the consequences of sizing, managed disks, encryption at host, availability zones and availability sets, and Virtual Machine Scale Sets. A scale set addresses management of a fleet; it does not automatically make an application stateless or repair every availability risk. Availability zones provide a different failure model from availability sets. Moving a VM across scopes or regions also demands dependency checks; the presence of a move option is not evidence that every attached or related resource will move without restrictions.

Next deploy a minimal container workload and compare Azure Container Instances, Azure Container Apps, and App Service. These products shift different responsibilities to the platform. Container Instances fits straightforward container execution; Container Apps adds managed application capabilities such as revision-oriented deployments and autoscaling; App Service provides a managed web application platform and App Service plan capacity. AZ-104 requires selecting and operating these hosting models at an administrator’s level rather than designing advanced application frameworks. Study Azure VM operations alongside containers and App Service administration to notice where configuration, scaling, networking, and recovery responsibilities differ.

Keep one deployment repeatable. Store a simple Bicep file and its parameter values, deploy it to a lab resource group, inspect the resulting resources, change one property, and redeploy deliberately. Know how a changed desired state affects an existing deployment and why blindly rerunning a script can differ from an idempotent declarative template. The Bicep, ARM, PowerShell, and Azure CLI discussion becomes practical when you can explain which tool is used for what and how identity and scope constrain its execution.

Networking: trace the packet and the name

A typical AZ-104 networking case contains a source, destination, name, route, security rule, and service endpoint. An incorrect answer often fixes only one of them. Build two virtual networks in nonoverlapping address spaces, with separate subnets for a test application and administration. Add a network security group, create a rule that blocks a known connection, and inspect effective security rules before undoing it. Next establish peering and verify reachability. Peering connects networks but does not make all custom routes, gateways, or peered relationships transit automatically.

Place a private endpoint or another appropriately supported private service access pattern in the lab and trace its DNS behavior. A private endpoint can be healthy while a client still resolves the public service address. Conversely, correct DNS does not override NSG or routing restrictions. Learn when private endpoints differ from service endpoints, and where Azure Bastion fits when administration must avoid an exposed management port. For a detailed route-first method, compare Azure virtual network configuration with DNS, peering, and routing.

For load balancing, separate a transport-level Azure Load Balancer from application-layer needs and be clear about the health probe, frontend, backend pool, rule, and return traffic. A healthy VM does not imply the load balancer’s probe will succeed; a probe may use a different port or path. Run a controlled failure, observe what the client receives, inspect probe and backend health, and then fix the minimum necessary setting. The load-balancing scenarios are most useful when connected to that service-chain approach.

When diagnosing connectivity, make a short evidence record: the resolved address, source and destination, effective NSG rules, next hop, DNS zone, and the response from an appropriate test. Azure Network Watcher can help establish where the connection diverges from expectation. Changing every NSG and route table until traffic works may recover a lab, but it is not a defensible production troubleshooting method.

Monitoring, backup, and recovery should close the loop

Monitoring becomes useful only when it changes the operator’s next action. Pick one failing resource and ask which signal would have revealed the problem sooner. Metrics support timely measurement and threshold alerts; logs can help reconstruct detailed event sequences. Configure an alert rule, link an action group, and test the response path. Learn the difference between the signal, the trigger, the action, and alert processing rules. An alert with no reliable action path is mostly a notification artifact.

Use Azure Monitor Insights for a supported VM, storage account, or networking service and observe what additional context it provides. Logs and metrics may have different ingestion, granularity, retention, and cost implications, and not every symptom has an immediately available historical log. The Azure Monitor and alerting material can help you choose the appropriate evidence, but a small failed-workload investigation is what turns that vocabulary into operational judgment.

For recovery, start from recovery point objective and recovery time objective instead of a product name. A backup policy defines what gets protected and for how long; a restore proves whether the result is usable. Site Recovery is relevant to continuity and failover, whereas Azure Backup protects recoverable data and workloads under supported configurations. Know why a Recovery Services vault and a Backup vault can have different supported scenarios. Create a disposable protected item, verify a recovery point, rehearse the supported restore steps, and document what would need to be reconnected after recovery. Review Azure Backup and recovery for the difference between backup, restoration, replication, and failover.

A four-week study sequence built around observable decisions

Four weeks is a planning example, not an official Microsoft duration or a guarantee of readiness. If you are already a hands-on Azure administrator, your gaps may be narrow; if cloud administration is new, allocate additional practice time. Keep one notebook recording each scenario’s requirement, the Azure control you selected, why you rejected alternatives, how you verified the outcome, and which mistake you would avoid next time.

After each week, use the official domain objectives to mark tasks as demonstrated, partly demonstrated, or not attempted. Avoid calling a topic complete merely because you recognized the answer in a quiz. A stronger test is whether you can configure the control, state its limits, identify one failure mode, and undo your own changes safely.

Work one realistic cross-domain incident from end to end

Imagine a team that operates a private internal web service. It runs in App Service, retrieves documents from Azure Storage, and relies on a small VM-based process for a legacy integration. A new deployment causes document requests to fail. The developer says credentials are correct; the networking team says the endpoint exists; the operator sees rising latency and failed requests.

A useful investigation starts with the actual request path. Establish which app identity is being used and whether it has the necessary storage role. Check the resolved storage hostname and whether application networking directs traffic to the intended public or private endpoint. Review access restrictions and routes, then inspect application logs and Azure Monitor signals to see whether failures are authorization errors, connection timeouts, or missing data. If a deployment altered configuration, compare the deployment to the prior known-good state instead of replacing every setting.

Now suppose that fixing connectivity reveals a missing document. Storage replication alone may not restore an accidentally removed object; test the versioning, soft delete, or backup controls that were actually enabled. If the legacy integration VM is also unavailable, use its recovery and availability configuration to choose between restoring data, bringing up replacement capacity, and initiating a supported failover. This one incident tests identity, storage, networking, compute, monitoring, and recovery without reducing AZ-104 to five disconnected reading lists.

Exam readiness: use evidence, not confident guessing

Microsoft’s AZ-104 certification page currently lists a 100-minute exam assessment. The official study guide states that a scaled score of at least 700 is required to pass. Question counts and formats can vary; use the Microsoft exam sandbox to learn the testing interface, and check the booking page for your exact language, accommodations, and delivery details. The Azure Administrator Associate credential renews annually, with free online renewal assessment available to eligible holders through Microsoft Learn.

The official Microsoft Practice Assessment is a useful diagnostic, but it is not a replacement for the current skills-measured document or hands-on administration. Review wrong answers by identifying the missing distinction: wrong scope, incorrect service model, failed routing hypothesis, misunderstood storage protection, weak troubleshooting sequence, or an unfamiliar administration command. Build a small remediation exercise for each recurring category rather than repeatedly memorizing the same item.

Before booking, you should be able to explain the five weighted domains in your own words, perform at least one verified task in each, and connect them during a fault investigation. Use Microsoft’s current study guide as the final checklist, not the order of headings in any commercial preparation article. A good AZ-104 study plan leaves you better able to manage a real environment even if the exact wording of an exam scenario changes.