AZ-104 — Microsoft Azure Administrator

📅 Last Researched: May 2026 · 📖 Source: Microsoft Learn Official Study Guides

⚡ Strategy: You already work heavily with Azure — this guide focuses on exam-specific nuances, decision-tree logic, and the details Microsoft actually tests. Conceptual overviews are kept brief; depth is on the tricky parts.

Exam Overview & Strategy

AZ-104 is operational and hands-on. You must know how to configure, deploy, and manage Azure resources — not just what they are. Expect scenario-based questions asking you to choose the right command, portal setting, or configuration sequence.

Questions	Pass Score	Duration	Updated	Labs
40–60	700 / 1000	100 min	Apr 17, 2026	Yes (performance-based)

Recommended Study Order

D1 Identity & Governance → D2 Storage → D4 Networking → D3 Compute → D5 Monitor

Why This Order?

Identity and RBAC underpins every other domain. Networking is the hardest — study it before compute so you understand the network layer VMs/containers rely on.

Domain 1 – Manage Azure Identities and Governance (20–25%)

1.1 Manage Microsoft Entra ID (formerly Azure AD)

What’s Tested

• Create and manage users (bulk create via CSV, guest invites)
• Create and manage groups: Security vs. Microsoft 365, Assigned vs. Dynamic
• Dynamic group membership rules — e.g., user.department -eq "Sales"
• Manage device settings: Entra Join vs. Hybrid Entra Join vs. Entra Registered
• Self-Service Password Reset (SSPR) — enabling per group, authentication methods required
• Microsoft Entra Connect — password hash sync vs. pass-through auth vs. federation

Feature	Entra Joined	Hybrid Entra Joined	Entra Registered
Who uses it	Cloud-only orgs	Corp devices with on-prem AD	BYOD / personal devices
Managed by	Intune/MDM	Group Policy + Intune	MDM (optional)
SSO to on-prem	No (without Hybrid)	Yes	No

Entra ID Licenses:

• Free: Basic user/group management, MFA for admins
• P1: Conditional Access, dynamic groups, SSPR, Hybrid Entra Join
• P2: PIM, Identity Protection, Access Reviews

Exam Tip

If a question involves Conditional Access, dynamic groups, or SSPR → P1 license required. If PIM or Identity Protection → P2 required.

1.2 Manage Azure Role-Based Access Control (RBAC)

What’s Tested

• Assign built-in roles: Owner, Contributor, Reader, User Access Administrator
• Create custom roles — know Actions, NotActions, DataActions, NotDataActions JSON fields
• Scope hierarchy: Management Group → Subscription → Resource Group → Resource
• Role assignments are additive — most permissive wins (except explicit deny)
• Managed Identities: System-assigned vs. User-assigned

Role	Manage Resources	Assign Roles	Give Others Access
Owner	✅ Yes	✅ Yes	✅ Yes
Contributor	✅ Yes	❌ No	❌ No
Reader	❌ Read-only	❌ No	❌ No
User Access Admin	❌ No	✅ Yes	✅ Yes

Managed Identity Use Cases:

• System-assigned: Tied to resource lifecycle. Deleted when resource is deleted. Use for single-resource access.
• User-assigned: Standalone resource. Can be shared across multiple resources. Use when multiple VMs/apps need the same identity.

Exam Trap

“User Access Administrator” can grant roles but CANNOT manage resources. Often confused with Contributor.

1.3 Manage Azure Policy and Governance

What’s Tested

• Azure Policy effects: Deny, Audit, AuditIfNotExists, DeployIfNotExists, Modify, Append
• Policy vs. Initiative (policy set)
• Management Groups: up to 6 levels deep below root, max 10,000 management groups
• Resource locks: CanNotDelete vs. ReadOnly

Policy Effects — Know the Priority:

1. Disabled — policy not evaluated
2. Append — adds fields to request (e.g., force tags)
3. Modify — changes/adds properties
4. Deny — blocks the request
5. Audit / AuditIfNotExists — allows but logs non-compliance
6. DeployIfNotExists — deploys a related resource if missing

Resource Locks:

• CanNotDelete: Can read and modify, cannot delete
• ReadOnly: Can read only, cannot modify or delete
• Applied at resource, RG, or subscription scope — inherited downward
• Only Owner or User Access Administrator can manage locks

Exam Trap

ReadOnly lock on a storage account prevents listing access keys — even though it looks like a read. Listing keys is internally a write operation.

1.4 Manage Subscriptions and Costs

What’s Tested

• Move resources between resource groups and subscriptions (not all resources are moveable)
• Apply and manage tags — tags are NOT inherited by default (use Policy)
• Cost Management + Budgets — create budget alerts
• Azure Reservations vs. Spot VMs vs. Savings Plans

Non-moveable resources (commonly tested): Azure AD Domain Services, Recovery Services Vaults (with conditions), VNet gateways when VNet has peerings.

Domain 2 – Implement and Manage Storage (15–20%)

2.1 Configure Storage Accounts

What’s Tested

• Types: Standard (GPv2) vs. Premium (BlockBlob, FileShares, Page)
• Redundancy: LRS → ZRS → GRS → GZRS (and read-access variants RA-GRS, RA-GZRS)
• Access tiers: Hot, Cool, Cold, Archive (Archive is offline — rehydration takes hours)
• Storage firewall and virtual network rules; private endpoints

Redundancy	Copies	Survives	Cost
LRS	3 in one datacenter	Hardware failure	Lowest
ZRS	3 across AZs	Zone failure	Medium
GRS	6 (3 local + 3 remote region)	Regional outage	Higher
GZRS	6 (3 zone + 3 remote region)	Zone + regional	Highest

Key Rule

Zone failure → ZRS minimum | Regional failure → GRS minimum | Zone AND regional → GZRS

2.2 Manage Azure Blob Storage

What’s Tested

• Blob types: Block (files/streaming), Append (logging), Page (VHDs/random write)
• Lifecycle management policies — automate tier transitions and deletions
• Blob versioning, soft delete, point-in-time restore
• SAS: Account SAS vs. Service SAS vs. User Delegation SAS
• Immutability policies: Time-based retention vs. Legal hold

SAS Type	Signed by	Recommended for
Account SAS	Storage account key	⚠️ Avoid — broad access
Service SAS	Storage account key	Service-specific access
User Delegation SAS	Entra ID credentials	✅ Preferred — most secure

Exam Tip

User Delegation SAS = signed with Entra ID = most secure. Always prefer this when the exam asks for “most secure” option.

2.3 Configure Azure Files and Azure File Sync

What’s Tested

• SMB (port 445) vs. NFS shares — NFS requires Premium FileStorage + VNet

• Azure File Sync: Server endpoint, Cloud endpoint, Sync group

• Cloud tiering — stores hot files locally, cold files as pointers to Azure

• Mounting: Windows (net use), Linux (cifs-utils)

• Sync group = one cloud endpoint (Azure file share) + one or more server endpoints

• Cloud tiering = only on server endpoints; frees up local disk but keeps namespace visible

• Registered server = Windows Server registered with Storage Sync Service

2.4 Configure Azure Storage Security and Tools

What’s Tested

• Storage access keys vs. SAS vs. Entra ID RBAC (data plane)
• Azure Key Vault integration for customer-managed keys (CMK)
• AzCopy: azcopy copy, azcopy sync, azcopy login
• Azure Data Box family: Data Box Disk, Data Box, Data Box Heavy (offline transfer)

# Copy blob to blob
azcopy copy 'https://source.blob.core.windows.net/container/file' \
  'https://dest.blob.core.windows.net/container/' --recursive

# Sync (only copies new/changed, can delete destination extras)
azcopy sync 'source' 'dest' --delete-destination=true

# Login with Entra ID (preferred over SAS for automation)
azcopy login

Domain 3 – Deploy and Manage Azure Compute Resources (20–25%)

3.1 Configure Virtual Machines

What’s Tested

• VM sizes: D-series (general), F-series (compute), E/M-series (memory), L-series (storage), N-series (GPU)
• Availability: Availability Sets (FD/UD) vs. Availability Zones
• Managed Disks: Standard HDD, Standard SSD, Premium SSD, Ultra Disk
• Disk encryption: SSE (default) vs. ADE (guest OS level) vs. Encryption at host
• Resize a VM — requires deallocating if moving to a different hardware cluster

Option	SLA	Scope	Use Case
None	No SLA (99.9% if Premium SSD)	Single VM	Dev/Test
Availability Set	99.95%	Within a datacenter	Legacy HA (multiple racks)
Availability Zones	99.99%	Separate physical datacenters	Production HA
VMSS (Flexible)	99.99%	Cross-zone	Auto-scaling production

Exam Tip

Availability Sets = protect against rack failures within one datacenter. Availability Zones = protect against an entire datacenter failure. “Zone failure” in the question → needs Availability Zones.

3.2 ARM Templates and Bicep

What’s Tested

• ARM template structure: $schema, contentVersion, parameters, variables, resources, outputs
• Bicep syntax — transpiles to ARM JSON
• Deployment stacks: enforce what can/can’t be deployed, managed cleanup
• What-if deployments before applying changes
• Template specs — store and share ARM templates as Azure resources

{
  "type": "Microsoft.Compute/virtualMachines",
  "apiVersion": "2023-09-01",
  "name": "[parameters('vmName')]",
  "dependsOn": ["[resourceId('Microsoft.Network/networkInterfaces', variables('nicName'))]"]
}

• dependsOn = explicit dependency (when resource references don’t create implicit dependency)
• [resourceId()] = function to reference another resource’s ID
• Bicep string interpolation: '${param1}-suffix'

3.3 Virtual Machine Scale Sets (VMSS)

• Uniform vs. Flexible orchestration modes
• Autoscale rules: metric-based, schedule-based
• Scale-in policy: Default, NewestVM, OldestVM
• Overprovisioning — creates extra VMs, deletes extras (no charge for over-provisioned VMs)
• Rolling, blue/green upgrade policies

3.4 Azure App Service Plans and Web Apps

• Tiers: Free/Shared → Basic → Standard → Premium → Isolated (ASE)
• Deployment slots (Standard+): staging, swapping, traffic routing %
• Autoscale available on Standard and above
• App Service Environment (ASE) — fully isolated, VNet injected

Slot Swap Behavior

Slot-specific settings (marked “slot setting”) stay in their slot. Non-slot settings swap with the app. Swap warms up new slot before completing → zero-downtime deployments.

3.5 Containers

Scenario	Service
Run a single container, no orchestration	Azure Container Instances (ACI)
Microservices with event-driven scaling	Azure Container Apps (ACA)
Full Kubernetes control, custom workloads	Azure Kubernetes Service (AKS)
Build and store container images	Azure Container Registry (ACR)

Exam Tip

ACI = billed per second, no infrastructure management. ACA = Kubernetes abstracted (KEDA, Dapr). AKS = full control but you manage node pools.

Domain 4 – Implement and Manage Virtual Networking (15–20% — Hardest Domain)

4.1 Configure Virtual Networks

• VNet address space planning — Azure reserves 5 IPs per subnet: .0, .1, .2, .3, .255
• VNet peering: non-transitive by default (Hub-spoke requires UDR for transitivity)
• Service endpoints vs. Private endpoints
• DNS: Azure-provided vs. custom DNS servers vs. Private DNS zones

Feature	Service Endpoint	Private Endpoint
Traffic path	Optimized public path	Private IP in your VNet
Source IP seen by service	VNet public IP	Private IP
Works from on-prem	❌ No	✅ Yes (via ER/VPN)
Cost	Free	Per hour + data charge
Recommended	Legacy/simple	Production, compliance

Exam Rule

“On-premises access to Azure PaaS” or “private IP” → Private Endpoint. Service Endpoints don’t extend on-prem.

4.2 Configure Network Security Groups (NSGs)

• NSG rules: Priority 100–4096 — lower number = higher priority
• Default rules: AllowVNetInBound, AllowAzureLoadBalancerInBound, DenyAllInBound
• NSG can attach to subnet AND/OR NIC — both apply
• Application Security Groups (ASGs) — tag VMs for NSG rules without managing IPs

NSG Evaluation Logic:

• Inbound: Subnet NSG → NIC NSG
• Outbound: NIC NSG → Subnet NSG
• Traffic must be allowed at BOTH levels to flow

Exam Trap

NSG on subnet affects all VMs in that subnet. NSG on NIC affects only that specific VM. If both exist, BOTH must allow traffic.

4.3 Configure Load Balancing

Requirement	Service
TCP/UDP load balancing within region	Azure Load Balancer (Standard)
HTTP/HTTPS routing, URL-based, WAF (regional)	Application Gateway
Global HTTP, CDN, WAF, anycast	Azure Front Door
DNS-based global routing, non-HTTP	Traffic Manager
Global redundancy across regional L4 LBs	Cross-region Load Balancer

Exam Trap

Standard Load Balancer requires NSG. Basic LB doesn’t — but Basic is being retired. Always use Standard for new deployments.

4.4 Configure VPN Gateway and ExpressRoute

• Site-to-Site (S2S): on-prem to Azure, requires local network gateway + VPN gateway
• Point-to-Site (P2S): individual client machines to Azure VNet
• VNet-to-VNet: VPN between Azure VNets (different regions/subscriptions)
• ExpressRoute: private MPLS circuit, not over internet
• Basic VPN Gateway SKU: no zone support, no BGP, no active-active
• Global Reach: connect two on-prem sites through Microsoft backbone via ExpressRoute

4.5 Monitor and Troubleshoot Networking

• IP flow verify: tells you if traffic is allowed/denied and which NSG rule is responsible
• Next hop: tells you where traffic is routed (useful for UDR/BGP debugging)
• Connection Monitor: continuous monitoring between sources and endpoints
• Packet capture: capture traffic to/from a VM for deep analysis

Domain 5 – Monitor and Maintain Azure Resources (10–15%)

5.1 Configure Azure Monitor

• Log Analytics workspaces — central store for logs (KQL queryable)
• Azure Monitor Metrics (numerical time-series) vs. Logs (KQL text)
• Diagnostic settings: platform logs/metrics → Log Analytics, Storage, Event Hub
• Action groups: email, SMS, webhook, ITSM, Azure Function, Logic App, Runbook

Alert Type	Data Source	Latency	Use Case
Metric alert	Azure Monitor Metrics	~1 min (near real-time)	CPU > 90%, memory spikes
Log query alert	Log Analytics	1–15 min	Complex query conditions
Activity log alert	Activity log	~5 min	Resource deletion, policy violations

5.2 Configure Azure Backup and Recovery

• Recovery Services Vault: location must match resource being backed up
• Azure Backup for: VMs, SQL in VMs, Azure Files, blobs
• Soft delete — 14-day retention after backup item deletion
• Cross-region restore: replicate vault to paired region
• Backup Center — centralized management dashboard

5.3 Azure Update Manager and Automation

• Azure Update Manager: replaces Update Management in Automation for OS patching
• Azure Automation: runbooks (PowerShell, Python), schedules, DSC
• Change Tracking and Inventory for software/service change detection