Confirm the current AZ-104 scope before making a study schedule
Microsoft Certified: Azure Administrator Associate is intended for people who implement, manage and monitor Azure environments. The April 2026 AZ-104 study guide covers five weighted skill areas: manage Azure identities and governance (20–25%), implement and manage storage (15–20%), deploy and manage Azure compute (20–25%), implement and manage virtual networking (15–20%), and monitor and maintain resources (10–15%). The percentages describe relative emphasis, not a fixed question count on your exam appointment.
Practical background in operating systems, networking, servers and virtualization helps, as do the Azure portal, PowerShell, Azure CLI, ARM/Bicep and Microsoft Entra ID. Those are recommended capabilities in the audience profile, not proof that every candidate must have held a particular job for six months before registration. Review the current exam registration and policy conditions directly from Microsoft. The best preparation plan begins with what you can actually configure and diagnose, not with a guaranteed passing formula or an old list of Azure products.
Define readiness using evidence, not remembered definitions
Build a small skills matrix. For each of the five official domains, record one implementation task, one intentionally failing test, and one piece of evidence you could hand to another administrator. For identity, you might demonstrate a limited RBAC assignment and a denied operation. For storage, you could compare two access methods and a recovery point. For compute, change a VM’s configuration safely. For networking, isolate a wrong DNS answer and an effective NSG deny. For monitoring, distinguish a metric alert from a log-based diagnosis and prove a restore.
Rate a skill as unknown, explainable, performed in a lab or independently reproducible. A candidate who recognizes every service icon but cannot show which principal made a storage request has more work to do. A repeatable error investigation is stronger than the number of practice questions completed. Use a sandbox or disposable resource group with synthetic data; do not make unsupported claims that a written exercise was performed on a live Azure subscription.
Identity and governance: make one assignment and prove the boundary
Use Microsoft Entra ID to create or manage appropriately scoped test users or groups, then compare that tenant role with an Azure RBAC role at a resource scope. The Entra administration lesson covers lifecycle and self-service password reset, while Azure RBAC establishes the difference between principal, role and scope. A directory administrator does not automatically have resource management permissions. Test an authorized request and a denied one using separate principals.
Governance adds another decision boundary. Assign an Azure Policy rule to the intended test scope, trigger a known compliance outcome, and record whether the selected effect audits or denies. A resource lock has a different purpose and can block an action that RBAC would otherwise allow. Ask what should happen if an operator has Contributor at a resource group but the chosen region is prohibited by inherited policy. A strong answer identifies the policy assignment, rather than recommending subscription Owner as a general repair.
Storage: separate service selection, credentials and recovery
Start by choosing whether the workload actually needs Blob Storage, Azure Files or another supported storage service. The data model and client protocol determine which account settings, authorization methods and protection features matter. Create a disposable account and record selected redundancy, network exposure, access scope and encryption assumptions. A storage account’s management role does not necessarily grant the client the matching data permission.
Test one identity-based request and one deliberately restricted request. An HTTP 403 can result from insufficient data-role scope, a storage firewall or a malformed or expired SAS; the storage access diagnosis walks through those independent boundaries. Never broaden firewall rules and role assignments at the same time simply to make a lab pass. Change one condition, inspect the actual response and record which restriction was responsible.
Next introduce a recoverable loss. For supported blobs, consider versioning, soft delete and lifecycle controls; for Azure Files, distinguish share snapshots and a protected backup policy. The Blob and Files protection treatment separates logical recovery from geo-redundancy. Prove a small restore where possible, rather than treating a configured backup setting as evidence that users can recover their data.
Compute: administer the whole deployment, not only a running VM
Plan a VM with a supported image, size, managed disks, operating-system settings, network interface and availability expectation. Resize only after checking capacity, cost, downtime and application compatibility. Different disk encryption controls protect different boundaries; identify the one required before enabling a checkbox. The VM operations exercise reviews disks, availability and scale sets as operational choices.
Do a narrow change through a reviewed ARM JSON or Bicep deployment. Inspect the what-if result, target scope and actual resource API version. A Bicep change preview is useful evidence before applying configuration. Valid Bicep syntax does not guarantee the intended region, quota, permissions or policy will accept the resource. If the observed difference contains unrelated replacements, stop and reconcile the source definition first.
App Service and container hosting have different release and scaling mechanics from VMs. Choose the operational model that fits the workload and evaluate ingress, identity, deployment slots or revisions where relevant. A candidate should know how to trace a failing workload from Azure resource state into the guest process or application listener; a Running status alone does not prove that users can reach the service.
Networking: trace the packet and resolver paths
Practise nonoverlapping VNet and subnet addressing, including the five Azure-reserved addresses in a normal subnet. A /24 contains 256 total addresses but fewer normally assignable addresses after Azure reservations. Think about growth, delegated services, private endpoints, gateways and eventual peering before choosing every address prefix. The VNet planning walkthrough covers public IP and explicit outbound configurations rather than assuming all private VMs have implicit internet access.
When a connection fails, begin with the queried hostname, DNS resolver, returned IP, selected subnet, effective NSG rules and user-defined routes. Distinguish the request path from the return path. If a private endpoint exists but one client resolves the service’s public address, adding a role assignment cannot correct the resolver. The Azure DNS diagnostics article connects Network Watcher evidence with name resolution and service health.
Test a deliberate NSG deny and then a permitted connection under otherwise identical conditions. If both attempts fail, inspect the effective rule order, next hop, guest firewall and listener. A successful ping does not prove an HTTP listener is reachable, and an application-specific timeout does not prove the selected Azure load balancer is defective. Record the packet path as a diagram plus observed command outputs rather than as a list of portal clicks.
Monitoring and recovery: define acceptable evidence
Metrics, logs and activity records answer different questions. A metric alert may identify high CPU or request failures, while a log query can show detailed diagnostic events after appropriate collection is configured. Azure Activity logs help investigate management changes, including authorization and deployment errors. Use Azure Monitor to define a useful signal, owner, retention plan, alert route and expected response; collecting more data without a diagnostic purpose increases cost and potential privacy exposure.
For recovery, separate availability from a backup restore point and from Site Recovery replication. Write the incident you are protecting against: accidentally deleted object, broken VM or regional outage. A supportable configuration has a restoration operator, protected data class, recovery target and a repeatable verification method. A green backup dashboard is not proof the restored application works; test an appropriately scoped scenario using a disposable workload before accepting it.
Keep evidence from your failure drills. Record the time, affected resource ID, control that denied a request, change that resolved it, and why a broader permission would have been inappropriate. That record can be reviewed independently and demonstrates more practical administrator competence than simply reciting recovery-product names.
Turn domain exercises into one cross-service lab
A realistic final exercise is a small internal document service. It uses a versioned policy file in Azure Storage, a private workload, one read-only application identity, one disallowed test identity, and controlled monitoring. Start with a resource group and scope-limited role assignment. Create a VNet whose address ranges do not collide with the existing environment. Choose the storage access path and expose only what is necessary to deliver the service. Write a deployment receipt containing the intended configuration and the evidence of its acceptance.
Inject three specific failures in a lab: a storage request denied by a network rule, a deployment rejected by inherited Azure Policy and a user whose Azure RBAC scope does not include the intended resource. A correct response classifies the error without simultaneously weakening every policy. Then test a recoverable deletion of a disposable object, inspect the monitoring result and verify cleanup. If the activity is hypothetical, label it as a proposed experiment and write down what evidence would be needed to claim it succeeded.
Ask another person to review the record without watching the lab: could they identify which principal was authorized, why a request failed and what changed? Could they reproduce the deployment, examine a bad DNS answer and locate the chosen restore point? If the answer is no, improve the evidence contract rather than increasing the number of slides or practice questions.
Plan study time around gaps, not an invented exam formula
One possible schedule is to spend initial sessions on identities and storage, move to compute and networking, and then integrate monitoring, restoration and cross-domain failures. Adjust the time allocated to each topic according to your starting skills and the official objective weights. A beginner may need substantially more time than an experienced operator who already deploys Azure resources in their job. No arbitrary four-week plan or fixed mock-exam score can guarantee a pass.
Before scheduling, review the current Microsoft exam page for language, duration, exam policy and active skills. Exam question formats and features may change; Microsoft owns the official blueprint. Differentiate the administrator role from the architect role: AZ-104 tests resource operations, while Azure Solutions Architect Expert has a distinct design-focused AZ-305 requirement plus the Azure Administrator Associate prerequisite certification. Do not use an outdated Blueprints tutorial as evidence of a current administrator exam objective: Azure Blueprints is retiring, and governance/deployment workflows now rely on supported Azure Policy and ARM/Bicep mechanisms.
Use a practical readiness decision
You are closer to readiness when you can make a justified Azure change within a constrained scope, predict a denied request, diagnose it with the appropriate log or effective configuration, verify data recovery and clean up the resources. If your explanation depends only on a service name or cannot distinguish an authentication failure from a network failure, revisit the corresponding lab. Record what you actually executed and the results; do not claim hands-on validation based on written examples alone.
undefined