AZ-104 Microsoft Azure Administrator Associate

Compressed Complete Study Guide

Exam: AZ-104: Microsoft Azure Administrator
Certification: Microsoft Certified: Azure Administrator Associate
Blueprint version used: Skills measured as of April 17, 2026
Purpose: A practical, scenario-focused course for rapid learning, realistic revision, and exam-day decision making.

Table of Contents

1. Exam Overview
2. Exam Domains
3. Start-to-Finish Study Path
4. Core Concepts by Domain
5. Service Selection Guide
6. Architecture Patterns
7. Exam Traps
8. Quick Memory Rules
9. Final Revision Notes
10. Exam-Day Checklist

1. Exam Overview

AZ-104 tests whether you can operate an Azure environment safely and efficiently. It is not mainly a memorization exam. Most scenarios ask you to choose the most appropriate administrative action while balancing:

• Least privilege
• Minimum operational effort
• Scope
• Availability
• Security
• Recoverability
• Cost
• Troubleshooting efficiency

A passing score is 700 or greater. Microsoft periodically updates the exam. This guide follows the skills measured as of April 17, 2026.

What an Azure administrator is expected to manage

You should be comfortable administering:

• Microsoft Entra users, groups, licenses, and external identities
• Azure role-based access control (Azure RBAC)
• Subscriptions, management groups, policies, locks, tags, budgets, and Advisor recommendations
• Azure Storage accounts, blobs, Azure Files, access controls, replication, tiers, and recovery controls
• Azure virtual machines, disks, availability, scale sets, templates, and Bicep
• Azure Container Registry, Azure Container Instances, and Azure Container Apps
• Azure App Service plans, apps, TLS, DNS, deployment slots, backups, networking, and scaling
• Virtual networks, subnets, peering, routes, NSGs, Bastion, private endpoints, service endpoints, DNS, and load balancers
• Azure Monitor, Log Analytics, alerts, Network Watcher, Backup, and Site Recovery

The core AZ-104 mindset

When a scenario gives several valid-looking options, ask:

1. What exact requirement is being tested?
2. Is the requirement about management-plane control, data-plane access, routing, filtering, monitoring, availability, or recovery?
3. What is the smallest scope that meets the requirement?
4. Does the chosen feature solve the requirement directly, or is it only related?
5. Is there an Azure-native feature that avoids a manual workaround?

A common exam pattern is to offer a distractor that is technically useful but solves the wrong layer of the problem.

2. Exam Domains

Suggested effort allocation

Because the official weights are ranges, use this revision split:

Highest-value cross-domain themes

These themes appear repeatedly because they connect multiple domains:

• Scope inheritance: tenant, management group, subscription, resource group, resource
• Least privilege: choose the smallest role and smallest scope
• Private access: private endpoint versus service endpoint
• Traffic flow: DNS → route → NSG → load balancer → backend health
• Availability: availability zones, availability sets, scale sets, backups, and Site Recovery solve different problems
• Recoverability: soft delete, versioning, snapshots, Backup, and Site Recovery are not interchangeable
• Automation: prefer ARM templates or Bicep for repeatable deployments
• Monitoring pipeline: collect → query → evaluate → notify

3. Start-to-Finish Study Path

Phase 1 — Build the Azure mental model

Learn the basic Azure hierarchy first:

Microsoft Entra tenant
└── Management groups
    └── Subscriptions
        └── Resource groups
            └── Resources

Then separate two types of access:

This distinction eliminates many wrong answers. For example, Reader can view a storage account configuration but does not automatically grant permission to read blobs.

Phase 2 — Master service selection

Build quick decision rules:

• Need to prevent a deployment? Azure Policy
• Need to stop accidental deletion? CanNotDelete lock
• Need to block changes and deletion? ReadOnly lock
• Need time-limited delegated storage access? SAS
• Need storage access through a private IP? Private endpoint
• Need selected subnet access while using a public PaaS endpoint? Service endpoint
• Need secure RDP or SSH without VM public IP addresses? Azure Bastion
• Need multiple identical VMs with autoscale? Virtual Machine Scale Sets
• Need revisions and scale-to-zero for containerized microservices? Azure Container Apps
• Need simple fast serverless container execution? Azure Container Instances
• Need logs sent to Log Analytics? Diagnostic settings
• Need threshold-based notification? Alert rule + action group
• Need regional disaster recovery orchestration? Azure Site Recovery

Phase 3 — Learn the major comparison tables

Spend time on the comparisons that generate the most exam traps:

• Azure RBAC versus Azure Policy versus locks
• Availability zones versus availability sets versus backups versus Site Recovery
• Private endpoints versus service endpoints
• Blob soft delete versus container soft delete versus blob versioning versus snapshots
• Azure Container Instances versus Azure Container Apps versus Virtual Machine Scale Sets versus App Service
• Metrics versus logs versus Activity Log
• Recovery Services vault versus Backup vault

Phase 4 — Practice layered troubleshooting

For network failures, use this sequence:

Name resolution
→ Route selection
→ NSG filtering
→ Public/private endpoint design
→ Load balancer probe
→ Backend application state

For monitoring failures, use:

Telemetry source
→ Diagnostic setting or agent
→ Workspace destination
→ KQL query
→ Alert rule
→ Action group
→ Alert processing rule

For access failures, use:

Identity
→ Group membership
→ Role
→ Scope
→ Inheritance
→ Data-plane permission
→ Network restriction

Phase 5 — Final revision

Before the exam:

• Re-read the quick memory rules
• Rebuild each architecture pattern from memory
• Practice explaining why the strongest distractor is wrong
• Review high-value traps
• Use the exam sandbox to understand the interface

4. Core Concepts by Domain

Domain 1 — Manage Azure Identities and Governance

4.1 Microsoft Entra users and groups

Microsoft Entra ID manages identities used across Azure.

User types

Groups

Decision rule

When the question says:

Membership must update automatically when the user's department changes.

Choose:

A dynamic Microsoft Entra security group with a membership rule based on the department attribute.

Do not choose an assigned group. Assigned membership requires manual maintenance.

Group-based licensing

Group-based licensing applies licenses to members of a Microsoft Entra group. If assignment fails:

1. Review license assignment errors.
2. Identify conflicting service plans or missing prerequisites.
3. Resolve the license issue.
4. Reprocess the assignment.

Do not confuse Azure resource roles with Microsoft Entra license management.

External users

Use Microsoft Entra B2B guest invitations when external partners should authenticate with their existing organizational identities.

Avoid:

• Sharing one internal account
• Sending passwords manually
• Creating unnecessary cloud-only member users for partners

Self-service password reset

Use SSPR when users must reset their own passwords.

Key exam clue:

Enable the feature for a pilot group only.

Answer:

Enable SSPR for selected users and choose the pilot group.

4.2 Azure RBAC

Azure RBAC controls who can perform actions on Azure resources.

Role assignment model

Security principal + Role definition + Scope

Scope hierarchy

Management group
→ Subscription
→ Resource group
→ Resource

Permissions inherit downward. Prefer the smallest scope that meets the requirement.

Important built-in roles

Additive permissions

Azure RBAC assignments are additive.

Example:

• Reader at subscription scope
• Contributor at resource-group scope

Result:

• Contributor within that resource group
• Reader elsewhere in the subscription

The Reader role does not override Contributor.

Least-privilege pattern

Question:

A developer must upload blobs to one storage account only.

Best answer:

Assign Storage Blob Data Contributor at the storage-account scope.

Wrong answer:

Assign Contributor at subscription scope.

Why wrong:

• Contributor is broader
• Subscription scope affects unrelated resources
• A management-plane role may not be the best fit for blob data access

4.3 Azure Policy, locks, and tags

These are frequently confused.

Azure Policy

Use Azure Policy to:

• Deny unsupported regions
• Require tags
• Audit configurations
• Deploy required settings when missing
• Modify supported properties
• Apply governance at scale

Policy effects

Remediation

A DeployIfNotExists or Modify policy may need a remediation task for existing resources.

Decision rule:

New deployments are corrected, but existing resources remain noncompliant.

Choose:

Create a remediation task.

Policy initiatives

An initiative groups related policy definitions.

Use an initiative when several policies should be managed together, such as:

• Allowed locations
• Required tags
• Diagnostic settings
• Encryption controls

Policy exclusions and exemptions

Resource locks

Memory rule:

• Protect from deletion only: CanNotDelete
• Freeze configuration: ReadOnly

Tags

Use tags for:

• Cost allocation
• Ownership
• Environment labeling
• Operational grouping
• Reporting

Examples:

Environment=Production
Owner=Finance
Application=Billing
CostCenter=CC-2040

Do not treat tags as security boundaries. Tags do not isolate resources or enforce network access.

4.4 Resource groups, subscriptions, and management groups

Resource groups

A resource group is a lifecycle and management container for Azure resources.

Use resource groups to:

• Organize related resources
• Apply RBAC
• Apply policies
• Apply locks
• Move compatible resources when supported

Before moving a resource:

• Check whether the resource type supports the move
• Identify dependencies
• Select required dependent resources
• Validate before committing

Subscriptions

Subscriptions provide boundaries for:

• Billing
• Quotas
• Governance
• Access control
• Environment separation

Typical pattern:

Production subscription
Development subscription
Shared services subscription
Sandbox subscription

Management groups

Management groups sit above subscriptions.

Use management groups to:

• Apply policy across subscriptions
• Apply Azure RBAC across subscriptions
• Build governance hierarchies

Example:

Tenant root
├── Production management group
│   ├── Production subscription A
│   └── Production subscription B
└── Non-production management group
    ├── Development subscription
    └── Sandbox subscription

Cost management

Use:

Domain 1 Exam Traps

• Contributor cannot manage Azure RBAC assignments by default.
• Owner is often correct but too broad.
• A lock does not replace Azure Policy.
• A tag does not enforce anything.
• A resource group does not span subscriptions.
• A management group governs subscriptions; it does not hold application resources directly.
• Azure RBAC permissions are additive.
• Storage configuration access and blob data access are different.

Domain 2 — Implement and Manage Storage

4.5 Storage account fundamentals

Common storage services

Storage account kind

For general-purpose support of blobs, files, queues, and tables, choose:

StorageV2

Redundancy options

Fast selection rules

• Need zone resilience in one region? ZRS
• Need geo-replication? GRS
• Need readable secondary endpoint? RA-GRS or RA-GZRS
• Need minimum cost only? LRS

4.6 Storage access control

Storage security is layered.

Identity permission
+ SAS or key strategy
+ Network restriction
+ Encryption

Storage firewalls and virtual network rules

Use storage networking settings to:

• Allow selected public IP ranges
• Allow selected virtual networks
• Restrict public access
• Configure private endpoint access

Access keys

Storage accounts have access keys. Treat them like high-value secrets.

Rotation pattern:

1. Regenerate the unused key.
2. Update applications to use the new key.
3. Validate access.
4. Regenerate the exposed or old key.

Do not rotate both keys simultaneously unless downtime is acceptable.

Shared access signatures

A SAS provides delegated, time-limited access.

Use SAS when:

• A vendor needs temporary blob access
• A client should upload files for a limited period
• Sharing the full account key would be too broad

Limit:

• Resource scope
• Permissions
• Start time
• Expiry time
• Allowed protocol
• Allowed IP range when appropriate

Stored access policies

Use a stored access policy when multiple service SAS tokens need centralized revocation or modification.

Decision rule:

Revoke several SAS tokens before their individual expiry times.

Choose:

Associate SAS tokens with a stored access policy.

Identity-based access for Azure Files

Use identity-based authentication for Azure Files when users should access SMB shares using identities instead of shared keys.

4.7 Blob Storage

Containers

A blob container organizes blob objects.

Use blobs for:

• Images
• Documents
• Backups
• Logs
• Static content
• Data lake objects

Access tiers

Decision rule:

• Rare access but immediate retrieval required → Cool or Cold, depending on expected retention and economics
• Long-term archive with acceptable retrieval delay → Archive

Lifecycle management

Lifecycle rules automate:

• Tier changes
• Deletion
• Retention behavior based on age and conditions

Example:

Move blobs to Cool after 30 days
Move blobs to Archive after 180 days
Delete blobs after 730 days

Blob protection features

Important distinction

Question:

Users overwrite documents and need to recover earlier values.

Choose:

Blob versioning.

Question:

An entire container was deleted accidentally.

Choose:

Container soft delete.

Question:

A blob was deleted accidentally.

Choose:

Blob soft delete.

4.8 Azure Files

Azure Files provides managed file shares.

Use it when applications or users need:

• Shared file-system access
• SMB-based access
• Managed cloud file shares
• Mountable shares for multiple clients

Azure Files protection

Snapshot versus soft delete

• Need a known point-in-time copy before a change? Share snapshot
• Need recovery after accidental deletion? Soft delete

4.9 Data movement and encryption

Tools

Encryption

Azure Storage encrypts data at rest. If the scenario requires control over the encryption key, use:

Customer-managed key stored in a supported key-management service such as Azure Key Vault.

Do not confuse access delegation with encryption. A SAS token controls access; it does not select the encryption key.

Domain 2 Exam Traps

• Blob versioning is not the same as blob soft delete.
• Blob soft delete does not specifically recover an entire deleted container.
• Archive is not immediately readable.
• GRS replicates to a secondary region, but RA-GRS provides read access to the secondary endpoint.
• A SAS is safer than sharing an account key for limited delegated access.
• A stored access policy helps centrally revoke service SAS tokens.
• AzCopy is a command-line transfer tool; Storage Explorer is a graphical management tool.
• A private endpoint provides a private IP; a service endpoint does not.

Domain 3 — Deploy and Manage Azure Compute Resources

4.10 ARM templates and Bicep

Infrastructure as code makes deployments repeatable.

ARM templates

ARM templates are declarative JSON files.

Bicep

Bicep is an Azure-native declarative language that compiles to ARM JSON.

Use Bicep when you want:

• Cleaner syntax
• Reusable modules
• Parameters
• Outputs
• Repeatable deployment
• Easier maintenance than raw JSON

Common deployment tasks

You should be able to:

• Interpret ARM templates or Bicep files
• Modify parameters
• Modify resources
• Deploy resources
• Export existing deployments
• Convert an ARM template to Bicep
• Use reusable modules

Deployment modes

Exam rule:

Resources not listed in the template must remain.

Choose:

Incremental mode.

Export and decompile

Use export as a starting point for infrastructure as code. Review generated templates before production use.

Possible workflow:

Existing Azure resources
→ Export ARM template
→ Refine template
→ Optionally decompile to Bicep
→ Parameterize
→ Deploy repeatedly

4.11 Virtual machines

VM components

A VM commonly includes:

• VM resource
• Network interface
• Virtual network and subnet
• OS disk
• Optional data disks
• Optional public IP
• Optional NSG
• Boot diagnostics
• Optional availability configuration

Resize a VM

Resize when you need more CPU or memory while keeping existing disks and configuration.

Managed disks

Change disk size or SKU when you need more capacity or performance.

Encryption at host

Use encryption at host when security policy requires host-level encryption for:

• Temporary disks
• Disk caches
• Data paths on the host

Do not confuse this with only encrypting managed disks at rest.

Moving VMs

Before moving a VM:

• Check move support
• Check dependent resources
• Include required NICs, disks, and related resources
• Validate before committing

A move between regions is different from a move between resource groups.

4.12 VM availability and scale

Availability options solve different failure modes.

Availability sets

Use when:

• Multiple VMs must reduce correlated host-failure and maintenance risk
• Availability zones are not used or not available for the workload

Availability zones

Use when:

• Datacenter-level fault isolation is required within one Azure region
• The region and service support zones

Virtual Machine Scale Sets

Use when:

• Instances are similar
• Scale-out and scale-in are required
• Workload is stateless or appropriately designed
• Autoscale rules should change instance count

Memory rule:

• Availability set: resilient placement
• Availability zones: datacenter separation
• Scale set: resilient group plus scaling

4.13 Containers

Azure Container Registry

Use Azure Container Registry (ACR) to store private container images and artifacts.

Azure Container Instances

Use Azure Container Instances (ACI) when you need:

• Fast container execution
• No server administration
• No orchestrator management
• A simple batch or utility workload
• Explicit CPU and memory sizing for a container group

Azure Container Apps

Use Azure Container Apps when you need:

• Managed microservices
• Revisions
• Ingress
• Replica scaling
• Scale-to-zero behavior
• Event-driven or HTTP-based scaling

Service comparison

Container sizing versus scaling

• Sizing: CPU and memory requested for a container
• Scaling: Number of replicas or instances

Do not confuse adding replicas with increasing the resources of one container.

4.14 Azure App Service

App Service hosts web applications and APIs without requiring VM management.

App Service plan

The App Service plan defines:

• Region
• Pricing tier
• Compute capacity
• Scaling features
• Shared hosting capacity for apps

Scale up versus scale out

Question:

Add instances when CPU rises and remove them when load falls.

Choose:

Autoscale rules on the App Service plan.

TLS and custom domains

To serve a custom domain securely:

1. Configure the DNS mapping.
2. Add the custom domain.
3. Bind an appropriate TLS certificate.
4. Enforce HTTPS.

A DNS record alone does not configure TLS.

App Service networking

Deployment slots

Use slots when you need:

• Pre-production validation
• Minimal-downtime release
• Fast rollback
• Controlled slot swap

Pattern:

Deploy to staging slot
→ Validate
→ Swap staging with production
→ Roll back with another swap if necessary

App Service backup

Configure App Service backups when supported by the selected tier and workload requirements.

Domain 3 Exam Traps

• Incremental mode preserves unrelated resources; Complete mode can remove undeclared resources.
• Resize changes VM compute size; it does not require rebuilding the VM.
• Encryption at host is specifically important for temporary disks and caches.
• Availability zones and availability sets are not autoscaling solutions.
• Scale sets scale VMs, not App Service plans.
• Azure Container Instances is simpler than Azure Container Apps.
• Azure Container Apps is better for revisions, ingress, replica scaling, and scale-to-zero.
• VNet integration is for App Service outbound connectivity.
• A deployment slot supports safer releases; it is not a scaling feature.

Domain 4 — Implement and Manage Virtual Networking

4.15 Virtual networks and subnets

A virtual network is an isolated Azure network. Subnets divide the VNet into segments.

Use subnets to separate:

• Web tier
• Application tier
• Database tier
• Management tier
• Private endpoint subnet
• Bastion subnet

Addressing

Avoid overlapping address spaces when networks must be connected.

Example:

Hub VNet:   10.0.0.0/16
Spoke A:    10.10.0.0/16
Spoke B:    10.20.0.0/16
On-prem:    172.16.0.0/16

VNet peering

Use peering for private communication between VNets over the Microsoft backbone.

Key rule:

VNet peering is not transitive by default.

If:

VNet-A ↔ VNet-B
VNet-B ↔ VNet-C

Do not assume:

VNet-A ↔ VNet-C

Gateway transit

In hub-and-spoke networks:

• Hub peering: allow gateway transit
• Spoke peering: use remote gateways

This allows a spoke to use the hub gateway when supported and correctly configured.

4.16 Routing

Azure uses routes to determine the next hop.

User-defined routes

Use a route table with a UDR when traffic must be directed through:

• A network virtual appliance
• A firewall
• A gateway
• A specific next hop

Pattern:

Subnet
→ Route table
→ UDR
→ Next hop: virtual appliance

Effective routes

When troubleshooting, inspect effective routes on the NIC to see applied routes and selected paths.

Route versus NSG

4.17 NSGs and application security groups

NSGs

Network security groups filter inbound and outbound traffic.

An NSG rule includes:

• Source
• Source port
• Destination
• Destination port
• Protocol
• Direction
• Priority
• Allow or deny

Priority

Lower number = higher priority.

If both rules match:

Priority 100: Allow TCP 443
Priority 200: Deny TCP 443

The priority 100 allow rule applies first.

Effective security rules

A NIC can be affected by:

• Subnet NSG
• NIC NSG

Review effective security rules to see the combined result.

Application security groups

Use application security groups (ASGs) when NSG rules should refer to logical application groups rather than individual IP addresses.

Example:

ASG-Web → allow TCP 1433 → ASG-Database

This is easier to maintain than listing changing VM IP addresses.