AZ-104 Study Manual for Azure Administrators in 2026

Practice Exams:

View All

The Microsoft AZ-104 exam remains active in October 2026 and Microsoft’s English skill outline was refreshed on April 17. The Azure Administrator role still centers on implementing, managing, securing, and monitoring an Azure environment across identities and governance, storage, compute, networking, and resource monitoring.

That broad scope is why Microsoft AZ-104 preparation should be operational rather than purely conceptual. Candidates need to configure resources, understand effective state, troubleshoot failures, automate repeatable work, and explain the security and governance consequences of changes.

A strong study manual therefore follows the life of an Azure environment: establish governance and identity, deploy resources, connect them, observe them, recover them, and improve the operating model.

Turn this study manual into five tested work records

A manual is useful only if another person can follow it and reach a verifiable outcome. The procedures below use a disposable Azure lab rather than production infrastructure. Choose permitted resources, check estimated costs and quotas, create a budget or spending guardrail, and arrange cleanup before starting. Do not test failures against company services or real data. Each exercise has the same record: requirement, action, observation, correction, and reset.

Work record 1: a permission that is correct at one scope

Requirement: a test operations group should read the configuration of resources in one resource group but must not modify them. Choose a suitable built-in Azure Reader role assignment at the narrow resource-group scope and document who approves access. Before assigning it, identify the test principal and its other effective roles; inherited Contributor permissions elsewhere would invalidate the negative test.

Action: use the Azure portal or an authorized administration tool to create the role assignment. After appropriate propagation, sign in as the test identity where feasible or use an appropriate access check. Verify that resource properties can be read, then attempt a harmless management action that should be denied. Do not modify a production resource just to generate a failure.

Record: the principal identifier, the exact scope, the assignment, the successful read, and the denied write. If the write succeeds, inspect other direct or inherited role assignments before assuming RBAC failed. Finish by removing the temporary lab assignment and documenting why the test behavior changed.

Work record 2: one Blob access path with two separate controls

Requirement: a test application must read a nonproduction container without using an account key, and the service must allow the intended client network path. Use a supported Microsoft Entra and Blob data-role pattern; do not paste credentials into notes. First confirm the application’s principal and its data permissions at the relevant scope. Next determine whether it reaches the storage public endpoint under an allowed firewall configuration or an explicitly planned private endpoint.

Action: issue a permitted read from the actual test identity and client location. Record the result and the storage access settings. Create one reversible denial at a time in the lab: first remove or change only the data role, then restore it; separately alter only an authorized network or DNS setting, then restore it. The error signatures should differ. A role assignment cannot correct a DNS answer or route by itself.

Record: principal, data role, resolved hostname and IP, network permission, first successful read, each observed failure, and the outcome after restoration. Clean up private endpoints, networking and retained test objects according to the lab plan.

Work record 3: a compute deployment another person can reproduce

Requirement: deploy a small authorized workload from a reviewed ARM template or Bicep file, rather than relying only on screenshots of portal clicks. The deployment should identify its resource group, parameter choices, region, hosting model, identity and monitoring requirements. Choose between a VM and a managed hosting option by maintenance responsibility, not by which option you used most often.

Action: execute the supported deployment in the test scope and verify the resulting resources. Make one planned configuration change, then confirm the intended state and application response. Ask whether a VM needs OS maintenance and disk protection, or whether the workload is better served by a platform-managed web app. Record an update path and how the deployment is reviewed before repeating it.

Record: template reference, parameters without secrets, successful deployment ID, expected runtime behavior, measured verification and cleanup. If a dependency or quota prevents deployment, diagnose it before increasing permissions or deploying uncontrolled resources.

Work record 4: private connectivity and the actual name resolved

Requirement: a test client inside an approved network must reach a private service endpoint, with no assumption that creation of the endpoint means DNS is correct. Capture a simple client-to-service diagram including VNet, subnet, route, NSG, DNS resolver and endpoint address.

Action: from the real test client, query the hostname and confirm whether it resolves to the intended address. Only then test the required port, inspect effective routes and security rules, and verify application authorization. If the service is reached through a hybrid resolver, include forwarding behavior. Change one safe lab condition at a time and observe which symptom appears. Do not generalize one service’s private DNS zone to every Azure platform service.

Record: original DNS answer, expected endpoint IP, successful and failed connection outcomes, relevant security and routing evidence, and a retest after the fix. Use the private endpoint diagnostic guide when DNS and network authorization need to be separated more carefully.

Work record 5: an alert and a restore with useful evidence

Requirement: an operator must know when an important workload symptom appears and must be able to restore selected nonproduction state. Choose a supported metric or log condition for the workload, define who receives it and what action is expected, then create a safe test condition that should trigger the signal. Confirm the alert actually evaluates as expected rather than assuming a configured rule has been tested.

Action: protect an eligible test item using an appropriate supported backup, snapshot or native data-protection method. Delete or alter only disposable test data after verifying that a valid recovery point or mechanism exists. Restore, compare the recovered state to the documented expectation, and note required identity, network, keys and application dependencies. Do not confuse Azure Backup, high availability and Site Recovery failover.

Record: signal and alert response, recovery mechanism, chosen recovery point, duration, recovered test data, dependencies and cleanup. The Azure Monitor operations guide and recovery planning guide provide deeper concepts for this test.

A compact command-line inspection habit

The Azure CLI can help verify context and inventory, but commands should be run only in an account and subscription you are authorized to inspect. A simple read-only starting point is:

az account show --output table
az group list --output table
az resource list --resource-group <YOUR_TEST_RG> --output table

Replace the placeholder with the name of your own test group. These commands do not perform a lab for you; they help document the subscription context and created resources. Review output for accidental secrets before sharing logs. Portal views, PowerShell and CLI are alternative administration surfaces; understanding what the resource state means is more important than memorizing a command by itself.

How to mark a work record complete

Test	Required evidence	When to repeat
Requirement	You can explain the intended users, resources, scope and failure condition.	The lab task is only a list of buttons to click.
Configuration	Resource and control choice match the stated constraint.	You chose a broader permission or more exposed endpoint than necessary.
Verification	There is an observed positive test and, where safe, a negative test.	Only deployment success is recorded.
Recovery	Reversible changes are reset and the original behavior is retested.	The environment remains broken or cannot be cleaned up safely.
Handoff	Someone else can understand the result from the record.	The only evidence is your memory of a portal session.

Use this manual as a working reference after choosing a study sequence—not as another undifferentiated chapter list. The AZ-104 domain study plan establishes the order of learning; this workbook provides reusable evidence tests. If a completed procedure exposes a knowledge gap, the Microsoft AZ-104 learning center leads to the relevant deep-dive and original practice scenarios.

Start with Entra ID and governance because every workload inherits them

Use Microsoft Entra ID and Azure governance to practice users, groups, RBAC, subscriptions, management groups, Azure Policy, tags, locks, and resource organization.

Do not memorize built-in roles without understanding scope. A role assignment at subscription level can be far broader than the same role at one resource group.

Create a small hierarchy and test inheritance. Governance becomes memorable when you can predict whether a principal or policy affects one resource, a group, a subscription, or everything below a management group.

Identity labs should include both human administration and workload access. Create a user or group path for administrators and a managed-identity path for an application. Compare lifecycle, secret handling, auditability, and scope so Entra concepts are connected to real resource access.

Storage administration is about access and lifecycle

Practice storage accounts, Blob Storage, Azure Files, redundancy, access tiers, network controls, shared access mechanisms, lifecycle management, and data protection.

Separate data-plane access from resource administration. A user who can configure a storage account does not automatically need permission to read every object inside it.

Add a recovery test. Delete or change data deliberately and verify which control—versioning, snapshot, backup, soft delete, or replication—actually helps.

Storage study should measure behavior. Upload many small objects, use a file share, apply lifecycle policy, test a private endpoint, and restore deleted data. These experiments reveal which configuration affects cost, access, and recovery rather than leaving storage as a menu of options.

Compute administration includes VMs, containers, and App Service

Build and manage virtual machines, availability patterns, extensions, disks, scale sets, container workloads, and App Service configuration.

Practice replacement and change rather than only creation. Update an image, resize capacity, rotate a setting, or recover a failed instance and observe which state persists.

Use automation where it improves repeatability, but keep enough understanding to troubleshoot the underlying resource when the automation fails.

Compute practice should compare at least two hosting models. Deploy the same simple service on a VM and a managed application or container platform, then note patching, scaling, networking, identity, logging, and deployment differences. Administration decisions become easier when the operating burden is visible.

Virtual networking should be learned through traffic flow

Review subnets, routes, peering, gateways, and private connectivity and trace a packet from source to destination.

Configure VNets, subnets, NSGs, DNS, peering, load balancing, public and private access, and hybrid connectivity scenarios. Know which layer blocks traffic before changing rules.

Networking is a common source of false confidence because diagrams look simple. Labs with wrong routes, DNS errors, or health probes expose whether you really understand the path.

Networking exercises should include asymmetric or partial failures. One subnet may resolve DNS while another cannot; one route may reach the target while return traffic follows a different path. Capture evidence with built-in tooling instead of solving the lab by trial and error.

Monitoring should produce actionable evidence

Use metrics, logs, dashboards, and alerting to design a monitoring path around a workload rather than around the Azure portal.

Collect signals for health, performance, errors, capacity, and changes. An alert should have an owner and a next action; otherwise it becomes noise.

Practice KQL or query-based investigation where the current exam expects it, and correlate infrastructure state with application symptoms.

Monitoring work should include baseline creation. Know the normal CPU, memory, latency, request rate, storage, and error characteristics before you tune alerts. Without a baseline, thresholds can be arbitrary and incident response becomes dependent on guesswork.

Resource automation should reduce drift

Use infrastructure as code with ARM templates or Bicep so environments can be reviewed and reproduced. Understand parameters, dependencies, deployment scope, and what happens when a resource changes outside the template. Infrastructure as code does not eliminate drift unless teams actually use it as the source of intended state.

Test failed deployment and rollback scenarios. A reliable administrator needs to recover from automation problems, not only run successful templates.

Automation practice should distinguish deployment-time configuration from runtime operations. Bicep can create resources, while runbooks, scripts, policies, or platform features may handle recurring maintenance. Choose the mechanism that matches the lifecycle of the task.

Security is normal administration, not a separate chapter

Use least privilege for administrator, workload, and automation identities. Avoid shared standing credentials and excessive subscription-level access.

Protect secrets, private endpoints, encryption settings, network exposure, and monitoring evidence. A configuration change can create a security incident even when the resource remains available.

Review permissions periodically because temporary troubleshooting access tends to become permanent if no one owns cleanup.

Security review should include inherited access. A subscription-level role or policy can affect resources created later, so the administrator needs to understand how effective permission changes when resources move or teams reorganize.

Recovery belongs in the administrator role

Use backup and recovery objectives to connect Azure Backup, Site Recovery, redundancy, and restore operations to business expectations.

Practice restore, not only backup configuration. Record how long recovery takes and which dependencies—identity, DNS, keys, network, application configuration—must also be restored.

Maintenance planning should consider availability during patching, scaling, certificate rotation, and platform changes.

Recovery practice should document prerequisites such as vault access, network paths, encryption keys, DNS, and application configuration. A backup restore can succeed technically while the application remains unavailable because another dependency was omitted from the runbook.

Use the Azure CLI or PowerShell often enough that you can inspect state without depending on one portal blade. Command-line output is especially useful when comparing several resources, automating checks, or documenting a repeatable troubleshooting step.

Quotas and subscription limits should be part of administration practice. A deployment can fail even when the template and permissions are correct because regional cores, public IPs, or another service limit has been reached.

Tagging and naming standards are operational controls when teams use them for cost, automation, ownership, and policy. Practice applying them consistently through deployment rather than cleaning them up manually later.

Keep a small administration runbook that lists common checks for identity, network, compute, storage, and monitoring. Updating the runbook after each lab turns isolated exercises into a reusable operating model.

Include resource moves and ownership changes in administration practice. Azure environments evolve, and moving resources or subscriptions can affect policy, RBAC, cost reporting, and automation assumptions. Understand which controls are inherited and which remain attached to the resource.

Practice certificate and secret expiry as operational incidents. A service can fail even when compute and networking are healthy because a credential or certificate is no longer valid. Monitoring expiry and rehearsing rotation belongs in normal administration.

Use Azure Service Health, Resource Health, and application telemetry together during incident drills. They answer different questions: platform impact, resource condition, and workload behavior. Correlating them prevents false conclusions.

Build a final lab without a step-by-step guide. Give yourself only a requirement—private web app, managed identity, secure storage, monitoring, backup—and implement it from memory. The gaps that appear are your final AZ-104 backlog.

Administrators should practice subscription cleanup as well as deployment. Find unattached disks, stale public IPs, abandoned resource groups, unused identities, and orphaned alerts. Operational hygiene affects both security and cost.

Know where the control plane ends and the workload begins. Azure can report a resource as available while the application inside it is unhealthy. Use platform and application evidence together when troubleshooting.

Build a final troubleshooting sequence you can apply without notes: identify scope, confirm recent change, check identity, verify name resolution and route, inspect resource health, collect logs, test one hypothesis, and verify the fix. A repeatable method is more valuable than memorizing dozens of isolated repair steps.

Keep that sequence short enough to use under pressure and update it after every lab failure.

Use AZ-104 as a foundation, then specialize deliberately

After the exam, the next-step Azure paths include architecture, networking, security, DevOps, data, and other roles. If architecture is the goal, the AZ-104 to AZ-305 progression is especially natural because administrators already understand the implementation details architects need to design credibly.

Book AZ-104 when you can configure and troubleshoot from a requirement without following a step-by-step lab. Administration is demonstrated through controlled action and evidence, not recognition of portal screens.

Near the exam, switch from topic blocks to operational incidents. One scenario might combine a storage access problem, an identity denial, and a network rule. Mixed troubleshooting is closer to real administration and reveals whether you can choose the correct evidence source quickly.