完整的考试准备指南
Complete Learning Path for Certification Success
This study guide provides a structured learning path from fundamentals to exam readiness for the Microsoft Azure Administrator Associate (AZ-104) certification. Designed for complete novices, it teaches all concepts progressively while focusing exclusively on exam-relevant content. Extensive diagrams and visual aids are integrated throughout to enhance understanding and retention.
Target Audience: Complete beginners with little to no Azure experience who need to learn everything from scratch.
Study Commitment: 6-10 weeks of dedicated study (2-3 hours per day)
What Makes This Guide Different:
00_overview (this file) - How to use the guide and study plan
01_fundamentals - Chapter 0: Essential Background & Prerequisites
02_domain_1_identities_governance - Chapter 1: Manage Azure Identities and Governance (24% of exam)
03_domain_2_storage - Chapter 2: Implement and Manage Storage (18% of exam)
04_domain_3_compute - Chapter 3: Deploy and Manage Azure Compute Resources (24% of exam)
05_domain_4_networking - Chapter 4: Implement and Manage Virtual Networking (18% of exam)
06_domain_5_monitoring - Chapter 5: Monitor and Maintain Azure Resources (16% of exam)
07_integration - Integration & Cross-Domain Scenarios
08_study_strategies - Study Techniques & Test-Taking Strategies
09_final_checklist - Final Week Preparation Checklist
99_appendices - Quick Reference & Resources
diagrams/ - Contains all Mermaid diagram files (.mmd)
Week 1: Foundations
Week 2: Identity & Governance (Part 1)
Week 3: Identity & Governance (Part 2)
Week 4: Storage
Week 5: Compute
Week 6: Networking
Week 7: Monitoring & Integration
Week 8: Exam Preparation
For those with some IT background:
For complete beginners:
Pass 1: Understanding (First Read)
Pass 2: Application (Second Read)
Pass 3: Reinforcement (Final Review)
Use checkboxes to track your completion:
Chapter Completion:
Practice Test Scores (Target: 75%+ to pass):
Self-Assessment by Domain (Rate 1-5, target 4+):
Throughout this guide, you'll see these markers:
You're about to embark on a comprehensive learning journey. This guide contains everything you need to pass the AZ-104 exam and become a confident Azure Administrator.
Your next step: Open 01_fundamentals and start Chapter 0.
Remember:
Good luck on your certification journey! 🚀
Last Updated: October 2025
Study Guide Version: 1.0
Exam Version: April 18, 2025 skills measured
File: 01_fundamentals
This chapter builds the foundation for your Azure Administrator journey. Before diving into specific Azure services, you need to understand the fundamental concepts that underpin everything in Azure. Think of this as learning the alphabet before reading books.
Prerequisites for this certification:
If you're missing any: Don't worry! We'll explain Azure-specific concepts from scratch. For general IT concepts, consider reviewing basic networking and operating system tutorials online before continuing.
Time to complete this chapter: 3-4 hours
What it is: Cloud computing is the delivery of computing services (servers, storage, databases, networking, software) over the internet ("the cloud") instead of owning and maintaining physical hardware in your own data center.
Why it exists: Traditional IT infrastructure requires significant upfront investment in hardware, physical space, cooling, power, and maintenance staff. When your business grows, you need to buy more servers (which takes weeks or months). When demand decreases, those servers sit idle, wasting money. Cloud computing solves these problems by letting you rent computing resources on-demand, paying only for what you use.
Real-world analogy: Think of cloud computing like electricity. You don't build your own power plant to get electricity - you plug into the power grid and pay for what you use. Similarly, you don't build your own data center - you "plug into" Azure and pay for the computing resources you consume.
How it works (Detailed step-by-step):
💡 Tip: The key advantage of cloud computing is elasticity - the ability to quickly scale resources up or down based on demand. During Black Friday, an e-commerce site can add 100 servers in minutes, then remove them when traffic returns to normal.
Cloud computing offers three main service models, each providing different levels of control and management:
What it is: IaaS provides virtualized computing resources over the internet. You rent virtual machines, storage, and networks, but you're responsible for managing the operating system, applications, and data.
Why it exists: IaaS gives you maximum control and flexibility. It's like renting an empty apartment - you get the space and utilities, but you furnish it and maintain it yourself.
Real-world analogy: Renting a car. The rental company provides the vehicle (infrastructure), but you're responsible for driving it, putting gas in it, and returning it in good condition.
When to use:
Azure IaaS examples: Virtual Machines, Virtual Networks, Storage Accounts
What it is: PaaS provides a complete development and deployment environment in the cloud. The cloud provider manages the infrastructure, operating system, and runtime environment. You focus only on your application and data.
Why it exists: PaaS eliminates the complexity of managing infrastructure, allowing developers to focus on writing code. It's like renting a furnished apartment - you get everything you need to move in and start living.
Real-world analogy: Taking an Uber. You don't worry about the car, maintenance, or driving - you just specify your destination and the service handles everything else.
When to use:
Azure PaaS examples: Azure App Service, Azure SQL Database, Azure Functions
What it is: SaaS provides complete, ready-to-use applications over the internet. You simply use the software through a web browser or app - the provider manages everything else.
Why it exists: SaaS eliminates all infrastructure and application management. It's like staying in a hotel - everything is provided and maintained for you.
Real-world analogy: Netflix. You don't install software, manage servers, or worry about updates. You just log in and watch movies.
When to use:
Azure SaaS examples: Microsoft 365, Dynamics 365, Azure DevOps
Comparison Table:
| Aspect | IaaS | PaaS | SaaS |
|---|---|---|---|
| You manage | Applications, Data, Runtime, OS | Applications, Data | Nothing (just use it) |
| Provider manages | Virtualization, Servers, Storage, Networking | Everything except apps & data | Everything |
| Control level | High | Medium | Low |
| Management effort | High | Medium | Low |
| Flexibility | Maximum | Moderate | Minimal |
| Example | Azure VM | Azure App Service | Microsoft 365 |
| Best for | Custom infrastructure needs | Application development | End-user applications |
⭐ Must Know: For the AZ-104 exam, you'll primarily work with IaaS (Virtual Machines, Storage, Networking) and some PaaS services (App Service, Azure SQL Database). Understanding the difference is crucial for choosing the right service.
Azure organizes resources in a hierarchical structure with four levels. Understanding this hierarchy is absolutely critical for the AZ-104 exam because it affects permissions, billing, policies, and resource management.
📊 Azure Organization Hierarchy Diagram:
graph TB
subgraph "Azure Organization Hierarchy"
ROOT[Root Management Group<br/>Tenant Level]
subgraph "Management Groups Layer"
MG1[Management Group:<br/>Production]
MG2[Management Group:<br/>Development]
MG3[Management Group:<br/>Corporate]
end
subgraph "Subscriptions Layer"
SUB1[Subscription:<br/>Prod-App1<br/>Billing Boundary]
SUB2[Subscription:<br/>Prod-App2<br/>Billing Boundary]
SUB3[Subscription:<br/>Dev-Testing<br/>Billing Boundary]
end
subgraph "Resource Groups Layer"
RG1[Resource Group:<br/>WebApp-RG<br/>Lifecycle Container]
RG2[Resource Group:<br/>Database-RG<br/>Lifecycle Container]
RG3[Resource Group:<br/>Network-RG<br/>Lifecycle Container]
end
subgraph "Resources Layer"
R1[Virtual Machine]
R2[Storage Account]
R3[SQL Database]
R4[Virtual Network]
end
end
ROOT --> MG1
ROOT --> MG2
ROOT --> MG3
MG1 --> SUB1
MG1 --> SUB2
MG2 --> SUB3
SUB1 --> RG1
SUB1 --> RG2
SUB2 --> RG3
RG1 --> R1
RG1 --> R2
RG2 --> R3
RG3 --> R4
style ROOT fill:#e1f5fe
style MG1 fill:#fff3e0
style MG2 fill:#fff3e0
style MG3 fill:#fff3e0
style SUB1 fill:#f3e5f5
style SUB2 fill:#f3e5f5
style SUB3 fill:#f3e5f5
style RG1 fill:#e8f5e9
style RG2 fill:#e8f5e9
style RG3 fill:#e8f5e9
style R1 fill:#ffebee
style R2 fill:#ffebee
style R3 fill:#ffebee
style R4 fill:#ffebee
See: diagrams/01_fundamentals_azure_hierarchy.mmd
Diagram Explanation (Detailed):
This diagram shows the complete Azure organizational hierarchy from top to bottom. At the very top (blue) is the Root Management Group, which represents your entire Azure tenant (your organization's Azure account). This is automatically created when you first use Azure and cannot be deleted.
Below that are Management Groups (orange), which are containers for organizing multiple subscriptions. In this example, we have three management groups: Production, Development, and Corporate. Management groups allow you to apply governance policies and access controls across multiple subscriptions at once. For instance, you might apply a policy at the Production management group level that requires all resources to be tagged with a cost center - this policy would automatically apply to all subscriptions under that management group.
The next layer shows Subscriptions (purple), which are the billing boundaries in Azure. Each subscription has its own billing account and spending limits. In the diagram, Prod-App1 and Prod-App2 are production subscriptions under the Production management group, while Dev-Testing is a development subscription under the Development management group. Organizations typically use separate subscriptions to isolate environments (production vs. development) or to separate billing for different departments or projects.
Below subscriptions are Resource Groups (green), which are logical containers for resources that share the same lifecycle. In the example, WebApp-RG contains resources for a web application, Database-RG contains database resources, and Network-RG contains networking resources. When you delete a resource group, all resources inside it are deleted together - this makes cleanup easy and prevents orphaned resources.
At the bottom are the actual Resources (red) - the Azure services you create and use. These include Virtual Machines, Storage Accounts, SQL Databases, Virtual Networks, and hundreds of other Azure services. Each resource must belong to exactly one resource group and cannot exist outside of a resource group.
The arrows show the inheritance flow: policies, permissions, and tags applied at higher levels automatically flow down to lower levels. For example, if you assign someone the "Reader" role at the Management Group level, they can read all resources in all subscriptions under that management group.
⭐ Must Know: This hierarchy is fundamental to Azure administration. Permissions, policies, and tags flow downward (inheritance), but billing is tracked at the subscription level.
What it is: Management groups are containers that help you manage access, policies, and compliance across multiple Azure subscriptions. They sit above subscriptions in the hierarchy.
Why it exists: Large organizations often have dozens or hundreds of Azure subscriptions. Without management groups, you'd have to apply the same policies and permissions to each subscription individually, which is time-consuming and error-prone. Management groups let you apply governance once at a higher level, and it automatically cascades down to all child subscriptions.
Real-world analogy: Think of management groups like corporate divisions in a company. The CEO (root management group) sets company-wide policies, then each division (management group) can have additional policies, and finally each department (subscription) operates within those constraints.
How it works (Detailed step-by-step):
Detailed Example 1: Multi-Environment Organization
Contoso Corporation has 50 Azure subscriptions across different environments and departments. Without management groups, their IT team had to manually apply the same security policies to each subscription, which took hours and often resulted in inconsistencies.
They implement this management group structure:
At the Production management group level, they apply:
These policies and permissions automatically apply to all 20 production subscriptions. When they add a new production subscription, it automatically inherits all these settings - no manual configuration needed. This saves the IT team approximately 40 hours per month and ensures consistent governance.
Detailed Example 2: Department-Based Organization
Fabrikam Inc. organizes their Azure environment by department:
At the root level, they apply company-wide policies:
At the Finance management group level, they add additional policies:
The Finance subscriptions inherit both the root-level policies AND the Finance-specific policies. This layered approach allows for company-wide governance while still enabling department-specific requirements.
Detailed Example 3: Acquisition Integration
Northwind Traders acquires a smaller company that already has 10 Azure subscriptions. Instead of migrating everything immediately, they create a new management group called "Acquired-Company" under their root management group and move the acquired subscriptions there.
This allows them to:
⭐ Must Know (Critical Facts):
When to use:
Limitations & Constraints:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Thinking management groups are required for Azure
Mistake 2: Trying to put resources directly in management groups
Mistake 3: Assuming you can override inherited policies at lower levels
🔗 Connections to Other Topics:
What it is: An Azure subscription is a logical container that serves as a billing boundary and access control boundary for Azure resources. It's the agreement between you (or your organization) and Microsoft to use Azure services.
Why it exists: Subscriptions solve several critical problems: (1) They provide a clear billing boundary - each subscription gets its own invoice, making cost tracking easy. (2) They provide isolation - resources in different subscriptions are separated for security and management. (3) They enforce quotas and limits - each subscription has limits on how many resources you can create, preventing runaway costs or resource exhaustion.
Real-world analogy: Think of a subscription like a credit card account. You can have multiple credit cards (subscriptions) for different purposes - one for business expenses, one for personal use, one for a specific project. Each card has its own statement (bill), spending limit (quota), and you can control who has access to each card.
How it works (Detailed step-by-step):
Detailed Example 1: Environment Separation
Tailspin Toys uses three subscriptions to separate their environments:
Production Subscription (Prod-TailspinToys):
Development Subscription (Dev-TailspinToys):
Sandbox Subscription (Sandbox-TailspinToys):
This separation provides several benefits:
Detailed Example 2: Department-Based Subscriptions
Contoso Corporation has 5,000 employees across multiple departments. They create separate subscriptions for each major department:
Finance Subscription:
Marketing Subscription:
HR Subscription:
Benefits of this approach:
Detailed Example 3: Project-Based Subscriptions
Fabrikam Inc. creates temporary subscriptions for large projects:
Project Phoenix Subscription (6-month project):
This approach provides:
⭐ Must Know (Critical Facts):
When to use multiple subscriptions:
Limitations & Constraints:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Creating a new subscription for every project or application
Mistake 2: Thinking you can move resources freely between subscriptions
Mistake 3: Assuming subscription limits are hard caps
🔗 Connections to Other Topics:
Troubleshooting Common Issues:
What it is: A resource group is a logical container that holds related Azure resources. It's like a folder that groups resources that share the same lifecycle, permissions, or purpose.
Why it exists: Without resource groups, you'd have thousands of individual resources scattered across your subscription with no organization. Resource groups solve this by: (1) Grouping related resources together for easier management. (2) Allowing you to apply permissions to multiple resources at once. (3) Enabling you to delete multiple resources together. (4) Providing a way to track costs for a group of resources. (5) Organizing resources by application, environment, or any criteria that makes sense for your organization.
Real-world analogy: Think of resource groups like folders on your computer. Just as you create folders to organize related files (Documents/Work/Project1), you create resource groups to organize related Azure resources (RG-WebApp-Prod). When you delete a folder, all files inside are deleted - same with resource groups.
How it works (Detailed step-by-step):
Detailed Example 1: Application-Based Organization
Contoso runs an e-commerce web application with multiple components. They organize resources by application tier:
RG-WebApp-Frontend-Prod:
RG-WebApp-Backend-Prod:
RG-WebApp-Database-Prod:
Benefits of this organization:
Detailed Example 2: Environment-Based Organization
Fabrikam organizes the same application by environment instead of tier:
RG-ECommerce-Production:
RG-ECommerce-Staging:
RG-ECommerce-Development:
Benefits of this organization:
Detailed Example 3: Project-Based Organization
Northwind Traders uses resource groups for temporary projects:
RG-Migration-Phase1:
RG-Migration-Phase2:
After migration completes, resources are moved to permanent resource groups (RG-Production-App1, RG-Production-App2, etc.), and the migration resource groups are deleted. This keeps the migration organized and makes cleanup easy.
⭐ Must Know (Critical Facts):
When to use:
Limitations & Constraints:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Creating one giant resource group for everything
Mistake 2: Organizing by resource type (RG-VMs, RG-Databases, RG-Storage)
Mistake 3: Thinking resource group location affects resource location
Mistake 4: Trying to nest resource groups
🔗 Connections to Other Topics:
Troubleshooting Common Issues:
What it is: Resources are the actual Azure services you create and use - virtual machines, storage accounts, databases, virtual networks, and hundreds of other services. Resources are the "things" that do the work in Azure.
Why it exists: Resources are the fundamental building blocks of your Azure solutions. Each resource provides specific functionality: VMs run your applications, storage accounts store your data, databases manage your structured data, virtual networks connect your resources, etc.
Real-world analogy: If Azure is a city, resources are the individual buildings - houses (VMs), warehouses (storage), banks (databases), roads (networks). Each building serves a specific purpose and can be used independently or connected to others.
How it works (Detailed step-by-step):
Detailed Example 1: Web Application Resources
A typical web application might consist of these resources:
Virtual Machine (VM): "vm-webserver-prod-001"
Storage Account: "stwebappprod001"
SQL Database: "sqldb-webapp-prod"
Virtual Network: "vnet-webapp-prod"
Load Balancer: "lb-webapp-prod"
All these resources work together to deliver the web application. The VM runs the web server, which reads data from the SQL Database and serves static files from the Storage Account. The Load Balancer distributes incoming traffic, and the Virtual Network connects everything securely.
Detailed Example 2: Resource Dependencies
When you create a Virtual Machine, Azure automatically creates several dependent resources:
Primary Resource: Virtual Machine "vm-app-001"
Automatically Created Resources:
Network Interface (NIC): "vm-app-001-nic"
OS Disk: "vm-app-001-osdisk"
Network Security Group (NSG): "vm-app-001-nsg"
Public IP Address (if requested): "vm-app-001-ip"
Understanding these dependencies is crucial because:
Detailed Example 3: Resource Naming and Organization
Contoso uses a consistent naming convention for all resources:
Naming Pattern: {resource-type}-{application}-{environment}-{region}-{instance}
Examples:
vm-ecommerce-prod-eastus-001 (Virtual Machine)st-ecommerce-prod-eastus-001 (Storage Account - note: storage names can't have hyphens)sql-ecommerce-prod-eastus-001 (SQL Database)vnet-ecommerce-prod-eastus-001 (Virtual Network)nsg-ecommerce-prod-eastus-001 (Network Security Group)Benefits:
⭐ Must Know (Critical Facts):
/subscriptions/{subscription-id}/resourceGroups/{rg-name}/providers/{provider}/{resource-type}/{resource-name}When to use:
Limitations & Constraints:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Deleting a VM and assuming all related resources are deleted
Mistake 2: Creating resources without a naming convention
Mistake 3: Assuming all resources can be in any region
🔗 Connections to Other Topics:
Azure provides multiple ways to create and manage resources. Understanding these tools is essential for the AZ-104 exam because you'll need to use all of them in different scenarios.
What it is: The Azure Portal is a web-based graphical user interface (GUI) for managing Azure resources. It's accessible at https://portal.azure.com from any web browser.
Why it exists: The Portal provides an intuitive, visual way to manage Azure resources without needing to learn command-line syntax. It's perfect for beginners, one-time tasks, and exploring Azure services.
Real-world analogy: The Azure Portal is like using a smartphone app - you tap buttons, fill in forms, and see visual representations of your resources. It's user-friendly but not ideal for automation.
How it works (Detailed step-by-step):
Detailed Example 1: Creating a Virtual Machine
Using the Azure Portal to create a VM:
The Portal guides you through every option with helpful tooltips and validation.
When to use:
💡 Tips:
What it is: Azure CLI (Command-Line Interface) is a cross-platform command-line tool for managing Azure resources. It runs on Windows, macOS, and Linux, and uses simple, consistent commands.
Why it exists: Azure CLI provides a fast, scriptable way to manage Azure resources. It's perfect for automation, repetitive tasks, and scenarios where you need to create many resources quickly. Unlike the Portal, CLI commands can be saved in scripts and reused.
Real-world analogy: Azure CLI is like using keyboard shortcuts instead of clicking through menus. It's faster once you learn it, and you can record your actions (scripts) to repeat them later.
How it works (Detailed step-by-step):
az login, which opens a browser for you to sign in.az <service> <subservice> <action> --parametersDetailed Example 1: Creating a Resource Group
# Create a resource group
az group create \
--name RG-WebApp-Prod \
--location eastus \
--tags Environment=Production Application=WebApp CostCenter=IT-001
# Output (JSON):
{
"id": "/subscriptions/xxxx/resourceGroups/RG-WebApp-Prod",
"location": "eastus",
"name": "RG-WebApp-Prod",
"properties": {
"provisioningState": "Succeeded"
},
"tags": {
"Application": "WebApp",
"CostCenter": "IT-001",
"Environment": "Production"
},
"type": "Microsoft.Resources/resourceGroups"
}
This single command creates a resource group with tags in about 2 seconds. In the Portal, this would require clicking through multiple screens.
Detailed Example 2: Creating a Virtual Machine
# Create a VM with one command
az vm create \
--resource-group RG-WebApp-Prod \
--name vm-webserver-prod-001 \
--image Win2022Datacenter \
--size Standard_D2s_v3 \
--admin-username azureuser \
--admin-password 'ComplexP@ssw0rd!' \
--location eastus \
--vnet-name vnet-webapp-prod \
--subnet default \
--public-ip-address vm-webserver-prod-001-ip \
--nsg vm-webserver-prod-001-nsg \
--tags Environment=Production Application=WebApp
# This creates:
# - The VM
# - OS disk
# - Network interface
# - Public IP address
# - Network security group
# - Connects to virtual network
# All in one command!
Detailed Example 3: Scripting Multiple Resources
#!/bin/bash
# Script to create 10 VMs for a web farm
RESOURCE_GROUP="RG-WebFarm-Prod"
LOCATION="eastus"
VM_SIZE="Standard_B2s"
IMAGE="UbuntuLTS"
# Create resource group
az group create --name $RESOURCE_GROUP --location $LOCATION
# Create virtual network
az network vnet create \
--resource-group $RESOURCE_GROUP \
--name vnet-webfarm \
--address-prefix 10.0.0.0/16 \
--subnet-name subnet-web \
--subnet-prefix 10.0.1.0/24
# Create 10 VMs in a loop
for i in {1..10}
do
VM_NAME="vm-web-$(printf "%03d" $i)"
echo "Creating $VM_NAME..."
az vm create \
--resource-group $RESOURCE_GROUP \
--name $VM_NAME \
--image $IMAGE \
--size $VM_SIZE \
--admin-username azureuser \
--generate-ssh-keys \
--vnet-name vnet-webfarm \
--subnet subnet-web \
--public-ip-address "" \
--nsg "" \
--tags Environment=Production Tier=Web Instance=$i
done
echo "Created 10 VMs successfully!"
This script creates 10 VMs in about 10 minutes. Doing this in the Portal would take hours and be error-prone.
Common Azure CLI Commands:
# Authentication
az login # Sign in to Azure
az account list # List subscriptions
az account set --subscription "My Subscription" # Set active subscription
# Resource Groups
az group create --name RG-Test --location eastus
az group list # List all resource groups
az group delete --name RG-Test # Delete resource group
# Virtual Machines
az vm list # List all VMs
az vm start --name MyVM --resource-group RG-Test
az vm stop --name MyVM --resource-group RG-Test
az vm deallocate --name MyVM --resource-group RG-Test # Stop and release compute
az vm delete --name MyVM --resource-group RG-Test
# Storage Accounts
az storage account create --name mystorageacct --resource-group RG-Test
az storage account list
az storage account delete --name mystorageacct --resource-group RG-Test
# Getting Help
az --help # General help
az vm --help # Help for VM commands
az vm create --help # Help for specific command
When to use:
💡 Tips:
--output table for human-readable output: az vm list --output table--query to filter results: az vm list --query "[?location=='eastus']"--dry-run to see what would happen without executing (not all commands support this)⚠️ Common Mistakes:
az account show to verify you're in the right subscription--name "My VM Name"What it is: Azure PowerShell is a set of PowerShell modules (cmdlets) for managing Azure resources. It integrates with the PowerShell scripting language and runs on Windows, macOS, and Linux.
Why it exists: PowerShell provides powerful scripting capabilities with object-oriented programming, error handling, and complex logic. It's ideal for Windows administrators familiar with PowerShell and for scenarios requiring sophisticated automation.
Real-world analogy: If Azure CLI is like using a calculator, Azure PowerShell is like using Excel with formulas. Both can do math, but Excel (PowerShell) can handle much more complex scenarios with variables, conditions, and loops.
How it works (Detailed step-by-step):
Install-Module -Name Az or use Azure Cloud Shell.Connect-AzAccount, which opens a browser for sign-in.Verb-AzNoun -Parameter ValueDetailed Example 1: Creating a Resource Group
# Create a resource group
New-AzResourceGroup `
-Name "RG-WebApp-Prod" `
-Location "East US" `
-Tag @{Environment="Production"; Application="WebApp"; CostCenter="IT-001"}
# Output (PowerShell object):
ResourceGroupName : RG-WebApp-Prod
Location : eastus
ProvisioningState : Succeeded
Tags :
Name Value
=========== ===========
Environment Production
Application WebApp
CostCenter IT-001
Detailed Example 2: Creating a Virtual Machine
# Create a VM with PowerShell
$resourceGroup = "RG-WebApp-Prod"
$location = "East US"
$vmName = "vm-webserver-prod-001"
# Create credential object
$securePassword = ConvertTo-SecureString 'ComplexP@ssw0rd!' -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential ('azureuser', $securePassword)
# Create VM configuration
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize "Standard_D2s_v3" |
Set-AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $credential |
Set-AzVMSourceImage -PublisherName "MicrosoftWindowsServer" `
-Offer "WindowsServer" `
-Skus "2022-Datacenter" `
-Version "latest" |
Add-AzVMNetworkInterface -Id $nic.Id
# Create the VM
New-AzVM -ResourceGroupName $resourceGroup -Location $location -VM $vmConfig
Detailed Example 3: Advanced Scripting with Logic
# Script to resize all VMs in a resource group based on time of day
$resourceGroup = "RG-WebApp-Prod"
$currentHour = (Get-Date).Hour
# Define sizes based on time
if ($currentHour -ge 8 -and $currentHour -lt 18) {
# Business hours: Use larger VMs
$targetSize = "Standard_D4s_v3"
Write-Host "Business hours detected. Scaling UP to $targetSize"
} else {
# Off hours: Use smaller VMs to save costs
$targetSize = "Standard_D2s_v3"
Write-Host "Off hours detected. Scaling DOWN to $targetSize"
}
# Get all VMs in the resource group
$vms = Get-AzVM -ResourceGroupName $resourceGroup
foreach ($vm in $vms) {
$currentSize = $vm.HardwareProfile.VmSize
if ($currentSize -ne $targetSize) {
Write-Host "Resizing $($vm.Name) from $currentSize to $targetSize..."
# Stop the VM
Stop-AzVM -ResourceGroupName $resourceGroup -Name $vm.Name -Force
# Resize the VM
$vm.HardwareProfile.VmSize = $targetSize
Update-AzVM -ResourceGroupName $resourceGroup -VM $vm
# Start the VM
Start-AzVM -ResourceGroupName $resourceGroup -Name $vm.Name
Write-Host "$($vm.Name) resized successfully!"
} else {
Write-Host "$($vm.Name) is already the correct size."
}
}
Write-Host "All VMs processed."
This script demonstrates PowerShell's power: conditional logic, loops, object manipulation, and error handling - all in one script.
Common Azure PowerShell Cmdlets:
# Authentication
Connect-AzAccount # Sign in to Azure
Get-AzSubscription # List subscriptions
Set-AzContext -Subscription "My Subscription" # Set active subscription
# Resource Groups
New-AzResourceGroup -Name "RG-Test" -Location "East US"
Get-AzResourceGroup # List all resource groups
Remove-AzResourceGroup -Name "RG-Test" -Force
# Virtual Machines
Get-AzVM # List all VMs
Start-AzVM -Name "MyVM" -ResourceGroupName "RG-Test"
Stop-AzVM -Name "MyVM" -ResourceGroupName "RG-Test" -Force
Remove-AzVM -Name "MyVM" -ResourceGroupName "RG-Test" -Force
# Storage Accounts
New-AzStorageAccount -Name "mystorageacct" -ResourceGroupName "RG-Test" `
-Location "East US" -SkuName "Standard_LRS"
Get-AzStorageAccount
Remove-AzStorageAccount -Name "mystorageacct" -ResourceGroupName "RG-Test"
# Working with Objects
Get-AzVM | Where-Object {$_.Location -eq "eastus"} # Filter VMs by location
Get-AzVM | Select-Object Name, Location, VmSize # Select specific properties
Get-AzVM | Export-Csv -Path "vms.csv" # Export to CSV
# Getting Help
Get-Help Get-AzVM # Get help for cmdlet
Get-Help Get-AzVM -Examples # Show examples
Get-Command -Module Az.Compute # List all cmdlets in a module
Comparison: Azure CLI vs Azure PowerShell:
| Aspect | Azure CLI | Azure PowerShell |
|---|---|---|
| Syntax | az vm create --name MyVM |
New-AzVM -Name "MyVM" |
| Output | JSON (default) | PowerShell objects |
| Platform | Cross-platform (Python-based) | Cross-platform (PowerShell Core) |
| Learning curve | Easier for beginners | Steeper (need PowerShell knowledge) |
| Scripting | Bash/Shell scripts | PowerShell scripts (.ps1) |
| Object manipulation | Limited (text/JSON parsing) | Powerful (native object handling) |
| Best for | Simple automation, Linux users | Complex automation, Windows admins |
| Integration | CI/CD pipelines, Linux environments | Windows environments, complex logic |
When to use Azure PowerShell:
💡 Tips:
Get-Help extensively - PowerShell has excellent built-in documentationGet-Command -Module Az.* to discover available cmdlets⚠️ Common Mistakes:
-Force when deleting resources, causing interactive prompts in scripts-Force in automated scripts to skip confirmation promptstry/catch blocks and check $? (last command success status)What it is: Azure Cloud Shell is a browser-based shell environment hosted in Azure. It provides both Bash and PowerShell environments with Azure CLI and Azure PowerShell pre-installed.
Why it exists: Cloud Shell eliminates the need to install tools locally. You can manage Azure from any device with a web browser - no installation, no configuration, no maintenance. It's perfect for quick tasks, learning, and managing Azure from devices you don't own.
Real-world analogy: Cloud Shell is like using Google Docs instead of Microsoft Word. You don't install anything - just open a browser and start working. Your files are saved in the cloud and accessible from anywhere.
How it works (Detailed step-by-step):
Detailed Example 1: First-Time Setup
When you first use Cloud Shell:
user@Azure:~$Detailed Example 2: Using Cloud Shell for Quick Tasks
# Scenario: You're at a coffee shop and need to check VM status
# Open Cloud Shell in Azure Portal (no installation needed)
# Already authenticated - no need to run 'az login'
# List all VMs
az vm list --output table
# Check specific VM status
az vm get-instance-view \
--name vm-webserver-prod-001 \
--resource-group RG-WebApp-Prod \
--query "instanceView.statuses[1].displayStatus"
# Output: "VM running"
# Start a stopped VM
az vm start \
--name vm-database-prod-001 \
--resource-group RG-Database-Prod
# Done! Close browser and leave coffee shop.
Detailed Example 3: Persistent Storage
Cloud Shell mounts an Azure File Share to persist your files:
# Your home directory is persistent
cd ~
pwd
# Output: /home/user
# Create a script that will persist across sessions
cat > deploy-vm.sh << 'EOF'
#!/bin/bash
az vm create \
--resource-group $1 \
--name $2 \
--image UbuntuLTS \
--size Standard_B2s \
--generate-ssh-keys
### Azure Cloud Shell
**What it is**: Azure Cloud Shell is a browser-based shell environment hosted in Azure. It provides both Bash and PowerShell environments with Azure CLI and Azure PowerShell pre-installed.
**Why it exists**: Cloud Shell eliminates the need to install tools locally. You can manage Azure from any device with a web browser - no installation, no configuration, no maintenance. It's perfect for quick tasks, learning, and managing Azure from devices you don't own.
**Real-world analogy**: Cloud Shell is like using Google Docs instead of Microsoft Word. You don't install anything - just open a browser and start working. Your files are saved in the cloud and accessible from anywhere.
**Features of Cloud Shell**:
- Pre-installed tools: Azure CLI, Azure PowerShell, kubectl, Terraform, Ansible, Git, and more
- Persistent storage: 5 GB file share for your scripts and files
- Integrated editor: Built-in code editor
- No cost: Cloud Shell itself is free (only pay for storage account)
- Authenticated: Automatically signed in with your Azure credentials
- Secure: Runs in isolated container, destroyed after session ends
**When to use**:
- ✅ Use when: You don't want to install tools locally
- ✅ Use when: You're on a device you don't own
- ✅ Use when: You need quick access to Azure CLI or PowerShell
- ✅ Use when: You're learning and don't want to set up a local environment
- ❌ Don't use when: You need to run long-running scripts (20-minute timeout)
---
## Azure Resource Manager (ARM)
**What it is**: Azure Resource Manager (ARM) is the deployment and management service for Azure. It's the underlying engine that processes all requests to create, update, or delete Azure resources.
**Why it exists**: ARM provides a consistent management layer that ensures all Azure tools work the same way. It handles authentication, authorization, resource deployment, and dependency management.
**Key ARM Concepts**:
**Resource Providers**: Every Azure service is implemented by a resource provider:
- Microsoft.Compute - Virtual Machines, Scale Sets
- Microsoft.Storage - Storage Accounts
- Microsoft.Network - Virtual Networks, Load Balancers
- Microsoft.Sql - SQL Databases
**ARM Templates**: JSON files that define infrastructure declaratively. They enable Infrastructure as Code (IaC) for consistent, repeatable deployments.
⭐ **Must Know**: ARM templates are declarative (describe desired state) and idempotent (running multiple times produces same result).
---
## Chapter Summary
### What We Covered
✅ **Cloud Computing Fundamentals**: IaaS, PaaS, SaaS service models
✅ **Azure Hierarchy**: Management Groups, Subscriptions, Resource Groups, Resources
✅ **Management Tools**: Portal, CLI, PowerShell, Cloud Shell
✅ **Azure Resource Manager**: The engine behind all Azure operations
### Critical Takeaways
1. Azure hierarchy flows downward - permissions and policies inherit from parent to child
2. Subscriptions are billing boundaries - use them to separate costs
3. Resource groups are lifecycle containers - deleting a group deletes all resources inside
4. Choose the right tool: Portal for learning, CLI for automation, PowerShell for complex scripts
5. ARM is the foundation - all tools ultimately use ARM APIs
### Self-Assessment Checklist
- [ ] I can explain IaaS, PaaS, and SaaS with examples
- [ ] I understand the four levels of Azure hierarchy
- [ ] I know when to use management groups vs subscriptions vs resource groups
- [ ] I can use Azure Portal, CLI, and PowerShell
- [ ] I understand what Azure Resource Manager does
### Quick Reference Card
**Azure Hierarchy**:
1. Management Groups → Organize subscriptions
2. Subscriptions → Billing boundaries
3. Resource Groups → Lifecycle containers
4. Resources → Actual Azure services
**Management Tools**:
- Portal: Visual, easy to learn
- CLI: Fast, scriptable, cross-platform
- PowerShell: Powerful, object-oriented
- Cloud Shell: Browser-based, no installation
### What's Next?
Chapter 1 covers **Manage Azure Identities and Governance**:
- Microsoft Entra ID for identity management
- Role-Based Access Control (RBAC)
- Azure Policy for governance
- Cost management and tagging
**Next file**: 02_domain_1_identities_governance
---
**Chapter 0 Complete!** ✅
---
# Chapter 1: Manage Azure Identities and Governance (24% of exam)
**File**: 02_domain_1_identities_governance
## Chapter Overview
This domain represents 24% of the AZ-104 exam - the largest single domain. It covers how to manage identities, control access to resources, and implement governance policies across your Azure environment.
**What you'll learn**:
- Microsoft Entra ID (formerly Azure AD) for identity management
- Creating and managing users and groups
- Role-Based Access Control (RBAC) for permissions
- Azure Policy for governance and compliance
- Subscriptions and management groups organization
- Cost management and resource tagging strategies
**Time to complete**: 8-10 hours
**Prerequisites**: Chapter 0 (Fundamentals) - understanding of Azure hierarchy
---
## Section 1: Microsoft Entra ID Fundamentals
### Introduction
**The problem**: In traditional on-premises environments, Active Directory manages user identities and access to resources. But in the cloud, you need a different approach - one that works across the internet, supports modern authentication protocols, and integrates with cloud services.
**The solution**: Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud-based identity and access management service. It authenticates users, manages their identities, and controls access to Azure resources and Microsoft 365 services.
**Why it's tested**: Identity is the foundation of cloud security. The AZ-104 exam heavily tests your understanding of how to create users, manage groups, assign permissions, and secure access to Azure resources.
### What is Microsoft Entra ID?
**What it is**: Microsoft Entra ID is a cloud-based identity and access management service that helps your employees sign in and access resources. It's the identity provider for Azure, Microsoft 365, and thousands of other SaaS applications.
**Why it exists**: Traditional Active Directory was designed for on-premises networks with domain controllers and Kerberos authentication. Cloud services need an identity system that works over the internet, supports modern protocols (OAuth 2.0, SAML, OpenID Connect), and scales globally. Microsoft Entra ID solves these problems.
**Real-world analogy**: Think of Microsoft Entra ID as a digital security guard for your organization. Just as a security guard checks IDs before letting people into a building, Entra ID verifies identities before granting access to cloud resources. It also keeps a log of who entered when (audit logs).
**How it works** (Detailed step-by-step):
1. **Your organization creates a Microsoft Entra tenant** when you sign up for Azure or Microsoft 365. This tenant is your organization's dedicated instance of Entra ID.
2. **You add users to the tenant** - either by creating them directly in Entra ID (cloud-only users) or by synchronizing them from on-premises Active Directory (hybrid users).
3. **Users authenticate** by entering their username and password (or using multi-factor authentication, passwordless methods, etc.).
4. **Entra ID verifies the credentials** and issues an access token if authentication succeeds.
5. **The user presents the token** to access Azure resources, Microsoft 365, or other applications.
6. **The resource validates the token** with Entra ID and grants or denies access based on the user's permissions.
⭐ **Must Know**: Microsoft Entra ID is NOT the same as Windows Server Active Directory. They serve similar purposes but are different technologies. Entra ID is cloud-native and designed for internet-based authentication.
**Key Differences: Active Directory vs Microsoft Entra ID**:
| Aspect | Windows Server AD | Microsoft Entra ID |
|--------|-------------------|-------------------|
| **Deployment** | On-premises servers | Cloud service |
| **Protocol** | Kerberos, NTLM, LDAP | OAuth 2.0, SAML, OpenID Connect |
| **Structure** | Forests, domains, OUs | Flat structure (tenant) |
| **Authentication** | Domain controllers | Cloud-based authentication |
| **Primary use** | On-premises resources | Cloud resources and SaaS apps |
| **Management** | Group Policy | Azure Policy, Conditional Access |
| **Scope** | Local network | Global (internet-based) |
**Detailed Example 1: Cloud-Only User Authentication**
Contoso Corporation is a startup with no on-premises infrastructure. They create users directly in Microsoft Entra ID:
1. **Admin creates a user**: john.doe@contoso.com in the Azure Portal
2. **John receives a welcome email** with temporary password
3. **John signs in** to portal.azure.com for the first time
4. **Entra ID prompts** John to change his password and set up MFA
5. **John completes setup** and is now authenticated
6. **John accesses Azure resources** - Entra ID issues tokens for each resource
7. **Audit logs record** all of John's sign-ins and activities
This entire process happens in the cloud with no on-premises infrastructure needed.
**Detailed Example 2: Hybrid Identity with Azure AD Connect**
Fabrikam Inc. has 5,000 employees with existing Active Directory accounts on-premises. They want to use Azure but don't want to recreate all user accounts:
1. **Fabrikam installs Azure AD Connect** on a server in their datacenter
2. **Azure AD Connect synchronizes** user accounts from on-premises AD to Entra ID every 30 minutes
3. **Users keep their existing credentials** - same username and password work for both on-premises and cloud resources
4. **Password Hash Synchronization** sends a hash of user passwords to Entra ID (not the actual password)
5. **Users can sign in** to both on-premises resources (using domain controllers) and cloud resources (using Entra ID)
6. **Changes sync automatically** - if a user's password changes on-premises, it syncs to Entra ID within 30 minutes
This hybrid approach allows Fabrikam to leverage their existing identity infrastructure while moving to the cloud.
**Detailed Example 3: External User Collaboration (B2B)**
Northwind Traders needs to collaborate with external consultants from partner companies:
1. **Northwind invites** consultant@partnercorp.com as a guest user
2. **Consultant receives email invitation** with a link to accept
3. **Consultant clicks link** and authenticates with their own organization's credentials (partnercorp.com)
4. **Entra ID creates a guest user object** in Northwind's tenant
5. **Northwind assigns permissions** to the guest user (e.g., access to specific SharePoint sites)
6. **Consultant accesses Northwind's resources** using their own credentials - no need for a separate Northwind account
7. **When project ends**, Northwind removes the guest user, revoking all access
This B2B collaboration allows secure external access without creating and managing separate accounts.
### Microsoft Entra ID Concepts
#### Tenants
**What it is**: A tenant is a dedicated instance of Microsoft Entra ID that your organization receives when you sign up for a Microsoft cloud service. Each tenant represents a single organization and is completely isolated from other tenants.
**Why it exists**: Tenants provide security boundaries. Data and identities in one tenant are completely separate from another tenant. This ensures that Company A's users cannot access Company B's resources, even though both use Microsoft Entra ID.
**Real-world analogy**: Think of a tenant like an apartment building. Each tenant (organization) has their own apartment (Entra ID instance) with their own locks and keys. Tenants share the building infrastructure (Microsoft's cloud) but cannot access each other's apartments.
**Key Facts**:
- Each tenant has a unique domain name: yourcompany.onmicrosoft.com
- A tenant can have custom domains: yourcompany.com
- Tenant ID is a GUID that uniquely identifies your organization
- One organization typically has one tenant (but can have multiple for specific scenarios)
#### Users
**What it is**: A user is an identity in Microsoft Entra ID that represents a person who needs to access resources. Each user has a unique username (User Principal Name or UPN) and authentication credentials.
**Types of Users**:
**1. Cloud-Only Users**:
- Created directly in Microsoft Entra ID
- Credentials stored only in the cloud
- Example: john.doe@contoso.onmicrosoft.com
- Best for: Cloud-first organizations, external contractors
**2. Synchronized Users**:
- Synced from on-premises Active Directory using Azure AD Connect
- Credentials can be synchronized (Password Hash Sync) or federated (AD FS)
- Example: john.doe@contoso.com (exists both on-premises and in cloud)
- Best for: Hybrid organizations with existing AD infrastructure
**3. Guest Users (B2B)**:
- External users from other organizations
- Authenticate with their home organization's credentials
- Example: consultant@partnercorp.com invited to your tenant
- Best for: External collaboration, partners, vendors
**User Properties**:
- Display Name: "John Doe"
- User Principal Name (UPN): john.doe@contoso.com
- Job Title, Department, Manager (optional metadata)
- Contact Information: email, phone
- Licenses: Microsoft 365, Azure AD Premium, etc.
**Detailed Example 1: Creating a Cloud User**
Using Azure Portal:
1. Navigate to Microsoft Entra ID → Users
2. Click "New user" → "Create new user"
3. Fill in details:
- User name: jane.smith@contoso.com
- Name: Jane Smith
- First name: Jane
- Last name: Smith
- Job title: Marketing Manager
- Department: Marketing
4. Set initial password (user must change on first sign-in)
5. Assign licenses (if needed)
6. Click "Create"
Using Azure CLI:
```bash
az ad user create \
--display-name "Jane Smith" \
--user-principal-name jane.smith@contoso.com \
--password "TempP@ssw0rd123!" \
--force-change-password-next-sign-in true \
--job-title "Marketing Manager" \
--department "Marketing"
Using PowerShell:
New-AzADUser `
-DisplayName "Jane Smith" `
-UserPrincipalName "jane.smith@contoso.com" `
-Password (ConvertTo-SecureString "TempP@ssw0rd123!" -AsPlainText -Force) `
-ForceChangePasswordNextSignIn $true `
-JobTitle "Marketing Manager" `
-Department "Marketing"
Detailed Example 2: Bulk User Creation
For creating many users at once, use CSV import:
name,userPrincipalName,initialPassword,jobTitle,department
John Doe,john.doe@contoso.com,TempPass1!,Developer,Engineering
Jane Smith,jane.smith@contoso.com,TempPass2!,Manager,Marketing
Bob Johnson,bob.johnson@contoso.com,TempPass3!,Analyst,Finance
This is much faster than creating users one by one when onboarding many employees.
What it is: A group is a collection of users (and sometimes other groups or devices) that you can manage as a single unit. Groups simplify permission management - instead of assigning permissions to 50 individual users, you assign permissions to one group containing those 50 users.
Why it exists: Managing permissions for individual users doesn't scale. Imagine a company with 10,000 employees and 500 applications. Without groups, you'd need to manage millions of individual permission assignments. Groups reduce this to thousands of group assignments.
Real-world analogy: Groups are like mailing lists. Instead of sending an email to 50 people individually, you send one email to the "Marketing Team" group, and everyone in that group receives it.
Types of Groups:
1. Security Groups:
2. Microsoft 365 Groups:
Group Membership Types:
Assigned Membership:
Dynamic Membership:
Dynamic Group Rule Examples:
# All users in Marketing department
(user.department -eq "Marketing")
# All users in Seattle office
(user.city -eq "Seattle")
# All managers
(user.jobTitle -contains "Manager")
# All users in Marketing OR Sales
(user.department -eq "Marketing") -or (user.department -eq "Sales")
# All users in Marketing AND in Seattle
(user.department -eq "Marketing") -and (user.city -eq "Seattle")
# All devices running Windows
(device.deviceOSType -eq "Windows")
Detailed Example 1: Creating a Security Group
Using Azure Portal:
Using Azure CLI:
# Create group
az ad group create \
--display-name "Finance-Team" \
--mail-nickname "finance-team" \
--description "All finance department employees"
# Add members
az ad group member add \
--group "Finance-Team" \
--member-id <user-object-id>
Detailed Example 2: Creating a Dynamic Group
Dynamic groups automatically maintain membership based on rules:
Now, whenever a user's department is set to "Marketing", they're automatically added to this group. When they leave Marketing, they're automatically removed.
Detailed Example 3: Nested Groups
Groups can contain other groups (nesting):
Group: "All-Employees"
├── Group: "Engineering"
│ ├── User: John (Developer)
│ ├── User: Jane (Developer)
│ └── Group: "Engineering-Managers"
│ └── User: Bob (Engineering Manager)
├── Group: "Marketing"
│ ├── User: Alice (Marketing Specialist)
│ └── User: Charlie (Marketing Manager)
└── Group: "Finance"
├── User: David (Accountant)
└── User: Eve (CFO)
If you assign permissions to "All-Employees", everyone in all nested groups gets those permissions. This hierarchical structure mirrors organizational structure.
⭐ Must Know (Critical Facts):
When to use Security Groups vs Microsoft 365 Groups:
| Use Case | Security Group | Microsoft 365 Group |
|---|---|---|
| Assign Azure resource permissions | ✅ Yes | ❌ No |
| Assign app permissions | ✅ Yes | ❌ No |
| Email distribution list | ❌ No | ✅ Yes |
| Shared mailbox | ❌ No | ✅ Yes |
| Team collaboration (Teams) | ❌ No | ✅ Yes |
| SharePoint site | ❌ No | ✅ Yes (auto-created) |
| Can contain devices | ✅ Yes | ❌ No |
| Can contain other groups | ✅ Yes | ❌ No |
| Dynamic membership | ✅ Yes (Premium) | ✅ Yes (Premium) |
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Using Microsoft 365 groups for Azure resource permissions
Mistake 2: Creating too many assigned groups instead of using dynamic groups
Mistake 3: Not planning group structure before creating groups
🔗 Connections to Other Topics:
The problem: You have hundreds of users who need different levels of access to Azure resources. Some need to create VMs, others only need to view costs, and some need full administrative access. Managing individual permissions for each user on each resource would be impossible.
The solution: Azure Role-Based Access Control (RBAC) allows you to assign roles to users, groups, or service principals at different scopes. A role defines what actions are allowed (read, write, delete, etc.), and the scope defines where those actions apply (subscription, resource group, or individual resource).
Why it's tested: RBAC is fundamental to Azure security. The AZ-104 exam tests your ability to assign appropriate roles, understand role inheritance, and troubleshoot access issues.
What it is: Azure RBAC is an authorization system built on Azure Resource Manager that provides fine-grained access management for Azure resources. It allows you to grant users only the access they need to do their jobs, following the principle of least privilege.
Why it exists: Without RBAC, you'd have only two options: full admin access or no access. RBAC provides granular control - you can give someone permission to manage VMs but not delete them, or view costs but not create resources. This granularity is essential for security and compliance.
Real-world analogy: RBAC is like different levels of access cards in an office building. A janitor's card opens cleaning closets and common areas. An employee's card opens their office and meeting rooms. A manager's card opens all employee offices plus executive areas. The CEO's card opens everything. Each person has exactly the access they need - no more, no less.
How it works (Detailed step-by-step):
The "who" in RBAC - the identity that needs access:
User: An individual person with a profile in Microsoft Entra ID
Group: A collection of users
Service Principal: An identity for applications or services
Managed Identity: A special type of service principal managed by Azure
💡 Tip: Always assign roles to groups, not individual users. This makes management much easier as people join/leave teams.
The "what" in RBAC - the set of permissions:
Built-in Roles (Azure provides 100+ built-in roles):
Owner:
Contributor:
Reader:
User Access Administrator:
Resource-Specific Roles:
Custom Roles:
Role Definition Structure:
{
"Name": "Virtual Machine Contributor",
"Id": "9980e02c-c2be-4d73-94e8-173b1dc7cf3c",
"IsCustom": false,
"Description": "Lets you manage virtual machines, but not access to them, and not the virtual network or storage account they're connected to.",
"Actions": [
"Microsoft.Compute/virtualMachines/*",
"Microsoft.Network/networkInterfaces/read",
"Microsoft.Storage/storageAccounts/read"
],
"NotActions": [],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
]
}
Actions: What operations are allowed
* means all operationsMicrosoft.Compute/virtualMachines/* means all VM operationsMicrosoft.Compute/virtualMachines/read means only read VMsNotActions: Exceptions to Actions (denies)
DataActions: Operations on data within a resource
The "where" in RBAC - where the permissions apply:
Management Group Scope:
/providers/Microsoft.Management/managementGroups/ProductionSubscription Scope:
/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxResource Group Scope:
/subscriptions/.../resourceGroups/RG-WebApp-ProdResource Scope:
/subscriptions/.../resourceGroups/RG-WebApp-Prod/providers/Microsoft.Compute/virtualMachines/vm-web-001Scope Inheritance:
Permissions assigned at a higher scope automatically apply to all child scopes:
Management Group (Owner)
└── Subscription (inherits Owner)
└── Resource Group (inherits Owner)
└── Resource (inherits Owner)
If you assign someone "Reader" at the subscription level, they can read ALL resources in ALL resource groups in that subscription.
Detailed Example 1: Developer Access to Project Resources
Scenario: You have a development team working on a web application. They need to manage all resources in their project's resource group but shouldn't access production resources.
Solution:
Result:
Detailed Example 2: Read-Only Access for Managers
Scenario: Department managers need to view all resources and costs in their department's subscription but shouldn't be able to make changes.
Solution:
Result:
Detailed Example 3: VM Operator Custom Role
Scenario: You have operations staff who need to start/stop VMs for maintenance but shouldn't be able to create or delete VMs.
Solution:
{
"Name": "VM Operator",
"Description": "Can start, stop, and restart VMs but cannot create or delete them",
"Actions": [
"Microsoft.Compute/virtualMachines/read",
"Microsoft.Compute/virtualMachines/start/action",
"Microsoft.Compute/virtualMachines/restart/action",
"Microsoft.Compute/virtualMachines/deallocate/action"
],
"NotActions": [],
"AssignableScopes": [
"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
]
}
Result:
Detailed Example 4: Combining Multiple Role Assignments
Scenario: Alice is a developer who needs different levels of access to different environments.
Role Assignments:
Result:
⭐ Must Know (Critical Facts):
Common Built-in Roles Summary:
| Role | Can Manage Resources | Can Assign Roles | Can Delete | Use Case |
|---|---|---|---|---|
| Owner | ✅ Yes | ✅ Yes | ✅ Yes | Full admin |
| Contributor | ✅ Yes | ❌ No | ✅ Yes | Developers |
| Reader | ❌ No (view only) | ❌ No | ❌ No | Auditors, managers |
| User Access Administrator | ❌ No | ✅ Yes | ❌ No | Security team |
When to use each scope:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Assigning Owner role to everyone "just to be safe"
Mistake 2: Assigning roles to individual users instead of groups
Mistake 3: Thinking Reader role gives access to everything
Mistake 4: Not understanding scope inheritance
🔗 Connections to Other Topics:
Troubleshooting Common RBAC Issues:
Issue 1: "User cannot access resource even though they have Contributor role"
Issue 2: "User can view resources but cannot see storage account keys"
Issue 3: "User has Owner role but cannot assign roles to others"
The problem: You have hundreds of developers creating resources in Azure. Without controls, they might create resources in the wrong regions (violating data residency requirements), use expensive VM sizes (blowing the budget), or forget to apply required tags (making cost tracking impossible). Manually reviewing every resource creation is not scalable.
The solution: Azure Policy allows you to create rules that automatically enforce organizational standards and assess compliance at scale. Policies can prevent non-compliant resources from being created (deny), automatically fix non-compliant resources (modify), or simply report on compliance (audit).
Why it's tested: Azure Policy is a core governance tool. The AZ-104 exam tests your ability to create policy definitions, assign policies at appropriate scopes, and understand policy effects.
What it is: Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, ensuring those resources stay compliant with your corporate standards and service level agreements.
Why it exists: Organizations need to ensure consistency and compliance across their Azure environment. Without Azure Policy, you'd rely on manual processes, documentation, and hope that everyone follows the rules. Azure Policy automates compliance enforcement and provides visibility into compliance status.
Real-world analogy: Azure Policy is like building codes and inspections. Just as a city has building codes (policies) that all construction must follow, and inspectors (Azure Policy) check compliance and can stop non-compliant construction, Azure Policy enforces rules and checks compliance for Azure resources.
How it works (Detailed step-by-step):
What it is: A policy definition describes the compliance condition (what to check) and the effect (what to do if the condition is met). It's written in JSON format.
Built-in Policy Definitions (Azure provides 300+ built-in policies):
Common Built-in Policies:
Policy Definition Structure:
{
"properties": {
"displayName": "Allowed locations",
"description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
"mode": "Indexed",
"parameters": {
"listOfAllowedLocations": {
"type": "Array",
"metadata": {
"description": "The list of locations that can be specified when deploying resources.",
"displayName": "Allowed locations"
}
}
},
"policyRule": {
"if": {
"not": {
"field": "location",
"in": "[parameters('listOfAllowedLocations')]"
}
},
"then": {
"effect": "deny"
}
}
}
}
Key Elements:
What it is: The effect determines what happens when a policy rule is matched. Different effects provide different levels of enforcement.
Common Policy Effects:
Deny:
Audit:
AuditIfNotExists:
DeployIfNotExists:
Modify:
Append:
Disabled:
Effect Comparison:
| Effect | Blocks Creation | Modifies Resource | Audits Only | Auto-Remediation |
|---|---|---|---|---|
| Deny | ✅ Yes | ❌ No | ❌ No | ❌ No |
| Audit | ❌ No | ❌ No | ✅ Yes | ❌ No |
| AuditIfNotExists | ❌ No | ❌ No | ✅ Yes | ❌ No |
| DeployIfNotExists | ❌ No | ✅ Yes | ❌ No | ✅ Yes |
| Modify | ❌ No | ✅ Yes | ❌ No | ✅ Yes |
| Append | ❌ No | ✅ Yes | ❌ No | ❌ No |
What it is: A policy assignment is the act of applying a policy definition to a specific scope. The assignment determines where the policy is enforced.
Assignment Scopes:
Assignment Properties:
Detailed Example 1: Restrict Resource Locations
Scenario: Your organization has data residency requirements - all resources must be in US regions only.
Solution:
Result:
Detailed Example 2: Require Tags on Resources
Scenario: All resources must have "CostCenter" and "Owner" tags for cost tracking.
Solution:
Result:
Detailed Example 3: Auto-Apply Tags
Scenario: Automatically add "Environment" tag to all resources in a resource group.
Solution:
Result:
Detailed Example 4: Audit VM Backup Compliance
Scenario: All production VMs should have Azure Backup enabled, but you don't want to block VM creation.
Solution:
Result:
What it is: An initiative definition (also called a policy set) is a collection of policy definitions grouped together to achieve a larger compliance goal.
Why it exists: Instead of assigning 20 individual policies, you can group them into one initiative and assign the initiative. This simplifies management and ensures related policies are applied together.
Real-world analogy: An initiative is like a checklist. Instead of remembering 20 individual tasks, you have one checklist that contains all 20 tasks. Completing the checklist means completing all tasks.
Example Initiative: "CIS Microsoft Azure Foundations Benchmark"
Custom Initiative Example:
{
"properties": {
"displayName": "Production Environment Standards",
"description": "Policies required for all production resources",
"policyDefinitions": [
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/allowed-locations",
"parameters": {
"listOfAllowedLocations": {
"value": ["eastus", "westus"]
}
}
},
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/require-tag",
"parameters": {
"tagName": {
"value": "CostCenter"
}
}
},
{
"policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/allowed-vm-sizes",
"parameters": {
"listOfAllowedSKUs": {
"value": ["Standard_D2s_v3", "Standard_D4s_v3"]
}
}
}
]
}
}
This initiative groups three policies together. Assigning this initiative applies all three policies at once.
⭐ Must Know (Critical Facts):
When to use each effect:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Assigning Deny policies without testing first
Mistake 2: Thinking policies apply retroactively to existing resources
Mistake 3: Creating too many individual policy assignments
🔗 Connections to Other Topics:
The problem: You have 500 resources across multiple subscriptions. Finance asks: "How much are we spending on the Marketing department?" Operations asks: "Which resources belong to Project Phoenix?" Security asks: "Who owns this VM?" Without proper organization, answering these questions requires manually reviewing each resource.
The solution: Tags are name-value pairs that you attach to resources for organization, cost tracking, and management. Tags allow you to categorize resources by any criteria that makes sense for your organization.
Why it's tested: Tags are fundamental to Azure resource management. The AZ-104 exam tests your ability to apply tags, use tags for cost tracking, and implement tagging strategies.
What it is: A tag is a name-value pair (like "Environment: Production" or "CostCenter: IT-001") that you apply to Azure resources, resource groups, and subscriptions. Tags provide metadata that helps you organize and manage resources.
Why it exists: Azure resources don't have built-in organizational structure beyond resource groups. Tags provide flexible, custom categorization that can span multiple resource groups and subscriptions. They're essential for cost tracking, automation, and resource management.
Real-world analogy: Tags are like labels on file folders. You might label folders by project, department, or date. Similarly, you tag Azure resources by environment, cost center, owner, or any criteria you choose.
Tag Structure:
Common Tagging Strategies:
1. Cost Tracking Tags:
2. Operational Tags:
3. Organizational Tags:
4. Automation Tags:
Detailed Example 1: Comprehensive Tagging Strategy
Contoso implements this tagging strategy for all resources:
Required Tags (enforced by Azure Policy):
Optional Tags:
Example Resource Tags:
Resource: vm-web-prod-001
Tags:
Environment: Production
CostCenter: IT-001
Owner: john.doe@contoso.com
Application: ECommerce
Tier: Frontend
MaintenanceWindow: Weekend
DataClassification: Internal
AutoShutdown: No
Benefits:
Detailed Example 2: Using Tags for Cost Allocation
Fabrikam wants to track Azure costs by department:
Apply CostCenter tags to all resources:
View costs by tag in Cost Management:
Create budgets per department:
Generate cost reports:
Detailed Example 3: Automation with Tags
Northwind uses tags to automate resource management:
Auto-Shutdown Script:
# Find all VMs with AutoShutdown=Yes tag
$vms = Get-AzVM | Where-Object {$_.Tags['AutoShutdown'] -eq 'Yes'}
# Check current time
$currentHour = (Get-Date).Hour
# Shutdown VMs after business hours (6 PM)
if ($currentHour -ge 18) {
foreach ($vm in $vms) {
Write-Host "Shutting down $($vm.Name)..."
Stop-AzVM -ResourceGroupName $vm.ResourceGroupName -Name $vm.Name -Force
}
}
This script runs nightly and automatically shuts down non-production VMs to save costs.
What it is: Tag inheritance means tags applied at a higher scope (subscription or resource group) can be automatically applied to resources within that scope.
Important: By default, tags do NOT inherit. Resources do not automatically get tags from their resource group or subscription.
How to enable inheritance: Use Azure Policy with the "Inherit a tag from the resource group" or "Inherit a tag from the subscription" built-in policies.
Example:
⭐ Must Know (Critical Facts):
When to use tags:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Assuming tags automatically inherit from resource groups
Mistake 2: Using inconsistent tag names (Environment vs Env vs environment)
Mistake 3: Not enforcing required tags
The problem: Cloud costs can spiral out of control quickly. A developer creates a large VM for testing and forgets to delete it - $500/month wasted. Multiple teams create resources without tracking costs - the monthly bill is $50,000 but nobody knows where the money went.
The solution: Azure Cost Management provides tools to monitor, allocate, and optimize Azure spending. It helps you understand where money is going, set budgets, and receive alerts before overspending.
Why it's tested: Cost management is a critical responsibility for Azure administrators. The AZ-104 exam tests your ability to monitor costs, create budgets, and use cost management tools.
What it is: Cost Analysis is a tool in the Azure Portal that shows your Azure spending with various filters, groupings, and visualizations.
Key Features:
Detailed Example 1: Analyzing Costs by Service
Scenario: You want to see which Azure services are costing the most.
Steps:
Insights:
Action: Focus optimization efforts on VMs (largest cost driver).
Detailed Example 2: Analyzing Costs by Tag
Scenario: You want to see costs by department for chargeback.
Steps:
Results:
Action: Send cost reports to department managers for review.
What it is: Budgets allow you to set spending limits and receive alerts when costs approach or exceed those limits.
Budget Types:
Alert Thresholds:
Detailed Example 1: Creating a Monthly Budget
Scenario: Set a $10,000 monthly budget for the IT department.
Steps:
Result:
Detailed Example 2: Budget with Action Groups
Scenario: Automatically shut down development VMs when budget reaches 100%.
Steps:
What it is: Azure Advisor analyzes your resource usage and provides personalized recommendations to reduce costs.
Common Recommendations:
Detailed Example: Following Advisor Recommendations
Advisor shows:
VM vm-web-dev-001 is underutilized
10 unattached disks found
5 VMs eligible for reserved instances
Total potential savings: $420/month ($5,040/year)
1. Right-Sizing:
2. Auto-Shutdown:
3. Reserved Instances:
4. Spot VMs:
5. Storage Optimization:
⭐ Must Know (Critical Facts):
When to use each tool:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Only checking costs at month-end
Mistake 2: Not setting budgets
Mistake 3: Ignoring Azure Advisor recommendations
In this chapter, you learned the fundamentals of Azure identity and governance:
✅ Microsoft Entra ID:
✅ Role-Based Access Control (RBAC):
✅ Azure Policy:
✅ Tags and Organization:
✅ Cost Management:
Microsoft Entra ID is the foundation: All Azure access starts with identity. Understanding users, groups, and authentication is essential.
RBAC follows least privilege: Always assign the minimum permissions needed. Use groups for role assignments, not individual users.
Azure Policy enforces compliance: Use Audit effect first to understand impact, then switch to Deny for enforcement. Group related policies into initiatives.
Tags enable cost management: Without tags, cost tracking is nearly impossible. Enforce required tags with Azure Policy.
Proactive cost management saves money: Monitor costs weekly, set budgets with alerts, and act on Azure Advisor recommendations monthly.
Test yourself before moving to the next chapter:
Microsoft Entra ID:
RBAC:
Azure Policy:
Tags and Cost Management:
📝 Exercise 1: Create Users and Groups
📝 Exercise 2: Implement RBAC
📝 Exercise 3: Apply Azure Policy
📝 Exercise 4: Implement Tagging Strategy
📝 Exercise 5: Cost Management
Microsoft Entra ID:
RBAC Roles:
RBAC Scopes (high to low):
Policy Effects:
Cost Management:
Pattern 1: RBAC Scope Selection
Pattern 2: Policy Effect Selection
Pattern 3: Cost Tracking
Pattern 4: Group Membership
Now that you understand identity and governance, you're ready to learn about storage. The next chapter covers Domain 2: Implement and Manage Storage, where you'll learn about:
Recommended next step: Open file 03_domain_2_storage and begin Chapter 2.
Chapter 1 Complete! ✅
You've mastered Azure identity and governance - the foundation of Azure administration. Take a break, review your notes, and when you're ready, move on to Chapter 2.
File: 03_domain_2_storage
This domain represents 18% of the AZ-104 exam. It covers Azure Storage services, which provide durable, highly available, and massively scalable cloud storage for data objects, files, and disks.
What you'll learn:
Time to complete: 6-8 hours
Prerequisites: Chapter 0 (Fundamentals), Chapter 1 (Identities & Governance)
The problem: Applications need to store data - files, images, videos, backups, logs, and more. Traditional on-premises storage requires buying hardware, managing capacity, ensuring redundancy, and handling backups. Scaling up requires purchasing more hardware, which takes weeks or months.
The solution: Azure Storage provides cloud-based storage that scales instantly, offers multiple redundancy options, and charges only for what you use. You can store petabytes of data without managing any hardware.
Why it's tested: Storage is fundamental to almost every Azure solution. The AZ-104 exam tests your ability to create storage accounts, configure security, manage data, and choose appropriate redundancy options.
What it is: A storage account is a container that provides a unique namespace for your Azure Storage data. Every object you store in Azure Storage has an address that includes your unique account name. The combination of the account name and the Azure Storage service endpoint forms the endpoints for your storage account.
Why it exists: Storage accounts provide a management boundary for storage resources. All storage services (blobs, files, queues, tables) within a storage account share the same configuration, security settings, and billing. This simplifies management and cost tracking.
Real-world analogy: A storage account is like a warehouse. The warehouse (storage account) has a unique address, and inside you can store different types of items (blobs, files, queues, tables) in different sections. All items in the warehouse share the same security system and are billed to the same account.
Storage Account Naming Rules:
Storage Account Endpoints:
Each storage account has unique endpoints for each service:
Example for account "mystorageacct001":
Azure offers several types of storage accounts, each optimized for different scenarios:
What it is: The most common and recommended storage account type. Supports all storage services (blobs, files, queues, tables) with standard performance.
Why it exists: Provides a balance of features, performance, and cost for most scenarios. It's the default choice unless you have specific requirements for premium performance.
Performance: Standard (HDD-based)
Supported services: Blobs, Files, Queues, Tables
Redundancy options: LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS (all options)
Use cases: General-purpose storage, web applications, backups, archives
Detailed Example 1: Web Application Storage
Contoso runs an e-commerce website that needs to store:
Solution: Create one Standard General-Purpose v2 storage account
Benefits:
What it is: Premium storage account optimized for block blobs and append blobs with SSD-based storage for low latency and high transaction rates.
Why it exists: Some applications require consistently low latency (single-digit milliseconds) and high throughput. Standard storage uses HDDs which can't meet these requirements.
Performance: Premium (SSD-based)
Supported services: Block blobs, append blobs only
Redundancy options: LRS, ZRS only (no geo-redundancy)
Use cases: Interactive applications, IoT data, real-time analytics, media streaming
Detailed Example 2: IoT Data Ingestion
Fabrikam has 10,000 IoT devices sending telemetry data every second:
Solution: Create Premium Block Blob storage account
Benefits:
What it is: Premium storage account optimized for Azure Files with SSD-based storage for enterprise file shares requiring high performance.
Why it exists: Enterprise applications often require file shares with low latency and high IOPS that standard file shares can't provide.
Performance: Premium (SSD-based)
Supported services: Azure Files only
Redundancy options: LRS, ZRS only
Use cases: Enterprise file shares, databases, high-performance applications
Detailed Example 3: SQL Server File Shares
Northwind runs SQL Server on Azure VMs and needs shared storage for database files:
Solution: Create Premium File Share storage account
Benefits:
What it is: Premium storage account optimized for page blobs, primarily used for Azure VM disks (managed disks).
Why it exists: Virtual machine disks require high IOPS and low latency. Premium page blobs provide SSD-based storage for VM disks.
Performance: Premium (SSD-based)
Supported services: Page blobs only
Redundancy options: LRS, ZRS only
Use cases: Azure VM disks, databases requiring high IOPS
Note: Most users should use Azure Managed Disks instead of page blobs directly. Managed Disks provide better management and features.
| Feature | Standard v2 | Premium Block Blobs | Premium Files | Premium Page Blobs |
|---|---|---|---|---|
| Performance | Standard (HDD) | Premium (SSD) | Premium (SSD) | Premium (SSD) |
| Latency | 10-20ms | <10ms | <1ms | <10ms |
| IOPS | Up to 20,000 | Up to 100,000 | Up to 100,000 | Up to 80,000 |
| Blobs | ✅ Yes | ✅ Yes (block/append) | ❌ No | ✅ Yes (page only) |
| Files | ✅ Yes | ❌ No | ✅ Yes | ❌ No |
| Queues | ✅ Yes | ❌ No | ❌ No | ❌ No |
| Tables | ✅ Yes | ❌ No | ❌ No | ❌ No |
| Geo-redundancy | ✅ Yes | ❌ No | ❌ No | ❌ No |
| Cost | $ | $$$ | $$$ | $$$ |
| Use case | General purpose | High transactions | Enterprise files | VM disks |
⭐ Must Know (Critical Facts):
When to use each type:
What it is: Storage redundancy determines how many copies of your data Azure maintains and where those copies are located. Different redundancy options provide different levels of durability and availability.
Why it exists: Hardware fails, data centers experience outages, and natural disasters happen. Redundancy ensures your data remains available and durable even when failures occur. Different applications have different requirements for availability and cost.
Real-world analogy: Redundancy is like having backup copies of important documents. You might keep one copy at home (LRS), copies in different rooms (ZRS), a copy in a safe deposit box in another city (GRS), or copies in multiple cities with access to all of them (RA-GZRS).
What it is: LRS replicates your data three times within a single data center in the primary region. All three copies are in the same physical location.
How it works:
Durability: 99.999999999% (11 nines) over a year
Availability: 99.9% (standard), 99.99% (premium)
Cost: Lowest cost option (~$0.02/GB/month)
Protects against:
Does NOT protect against:
When to use:
Detailed Example 1: Application Logs
Scenario: Store application logs that are analyzed daily and deleted after 30 days.
Solution: LRS storage account
Reasoning:
What it is: ZRS replicates your data synchronously across three Azure availability zones in the primary region. Each availability zone is a separate physical location with independent power, cooling, and networking.
How it works:
Durability: 99.9999999999% (12 nines) over a year
Availability: 99.99% (standard), 99.999% (premium)
Cost: Medium (~$0.025/GB/month, 25% more than LRS)
Protects against:
Does NOT protect against:
When to use:
Detailed Example 2: E-Commerce Database
Scenario: E-commerce application database that must stay online 24/7.
Solution: ZRS storage account for database backups
Reasoning:
What it is: GRS replicates your data to a secondary region hundreds of miles away from the primary region. Data is replicated three times in the primary region (LRS) and three times in the secondary region (LRS).
How it works:
Durability: 99.99999999999999% (16 nines) over a year
Availability: 99.9% (standard), 99.99% (premium)
Cost: Higher (~$0.04/GB/month, 2x LRS cost)
Protects against:
Does NOT protect against:
When to use:
Detailed Example 3: Financial Records
Scenario: Store financial records that must be retained for 7 years and survive any disaster.
Solution: GRS storage account
Reasoning:
What it is: Same as GRS, but with read access to the secondary region. You can read data from the secondary region at any time, even when the primary region is available.
How it works:
Durability: 99.99999999999999% (16 nines) over a year
Availability: 99.99% (standard), 99.999% (premium)
Cost: Same as GRS (~$0.04/GB/month)
When to use:
Detailed Example 4: Global Content Delivery
Scenario: Serve product images to users worldwide with low latency.
Solution: RA-GRS storage account
Architecture:
Benefits:
What it is: Combines ZRS in the primary region with GRS to the secondary region. Data is replicated across three availability zones in the primary region and three times (LRS) in the secondary region.
How it works:
Durability: 99.99999999999999% (16 nines) over a year
Availability: 99.99% (standard), 99.999% (premium)
Cost: Highest (~$0.05/GB/month, 2.5x LRS cost)
Protects against:
When to use:
Detailed Example 5: Healthcare Patient Records
Scenario: Store electronic health records (EHR) that must be available 24/7 with maximum durability.
Solution: GZRS storage account
Reasoning:
What it is: Same as GZRS, but with read access to the secondary region.
When to use: Same as RA-GRS, but when you also need zone redundancy in the primary region.
| Redundancy | Copies | Locations | Durability (9s) | Availability | Cost | Use Case |
|---|---|---|---|---|---|---|
| LRS | 3 | 1 data center | 11 | 99.9% | $ | Non-critical, temporary |
| ZRS | 3 | 3 zones | 12 | 99.99% | $$ | Production, high availability |
| GRS | 6 | 2 regions | 16 | 99.9% | $$$ | Critical, disaster recovery |
| RA-GRS | 6 | 2 regions | 16 | 99.99% | $$$ | Critical + read distribution |
| GZRS | 6 | 3 zones + 1 region | 16 | 99.99% | $$$$ | Mission-critical |
| RA-GZRS | 6 | 3 zones + 1 region | 16 | 99.99% | $$$$ | Mission-critical + reads |
⭐ Must Know (Critical Facts):
Decision Framework:
Start: What are your requirements?
Can you afford to lose data if data center fails?
├─ Yes → LRS (cheapest)
└─ No → Continue
Need protection against regional disasters?
├─ No → ZRS (zone redundancy only)
└─ Yes → Continue
Need read access to secondary region?
├─ No → GRS or GZRS
└─ Yes → RA-GRS or RA-GZRS
Need zone redundancy in primary region?
├─ No → GRS or RA-GRS
└─ Yes → GZRS or RA-GZRS (most expensive, highest availability)
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Using LRS for critical production data
Mistake 2: Thinking GRS provides instant failover
Mistake 3: Not understanding replication lag
The problem: Applications need to store unstructured data like images, videos, documents, backups, and logs. Traditional file systems don't scale well to petabytes of data, and managing storage infrastructure is complex and expensive.
The solution: Azure Blob Storage is a massively scalable object storage service for unstructured data. It can store any type of text or binary data and scale to petabytes without managing any infrastructure.
Why it's tested: Blob storage is one of the most commonly used Azure services. The AZ-104 exam tests your ability to create containers, upload blobs, configure access tiers, and manage blob lifecycle.
What it is: Blob (Binary Large Object) Storage is designed for storing massive amounts of unstructured data. Each blob is stored in a container, and containers are stored in storage accounts.
Why it exists: Traditional file systems have limitations on file size, number of files, and scalability. Blob storage removes these limitations and provides HTTP/HTTPS access to data from anywhere in the world.
Real-world analogy: Blob storage is like a massive digital warehouse with unlimited shelves. You can store any type of item (file), organize items in boxes (containers), and access items from anywhere using their address (URL).
Blob Storage Hierarchy:
Storage Account (mystorageacct001)
└── Container (images)
├── Blob (product1.jpg)
├── Blob (product2.jpg)
└── Blob (logo.png)
└── Container (documents)
├── Blob (report.pdf)
└── Blob (invoice.docx)
What it is: Block blobs are optimized for uploading large amounts of data efficiently. Data is uploaded in blocks, and blocks are assembled into a blob.
How it works:
Use cases:
Detailed Example 1: Video Upload
Scenario: Upload a 10 GB video file to blob storage.
Process:
Benefits:
What it is: Append blobs are optimized for append operations. You can only add data to the end of an append blob, not modify existing data.
How it works:
Use cases:
Detailed Example 2: Application Logging
Scenario: Application writes logs continuously throughout the day.
Process:
Benefits:
What it is: Page blobs are optimized for random read/write operations. They're divided into 512-byte pages and are primarily used for Azure VM disks.
How it works:
Use cases:
Note: Most users should use Azure Managed Disks for VM disks rather than page blobs directly.
What it is: Access tiers allow you to optimize storage costs based on how frequently you access data. Different tiers have different storage costs and access costs.
What it is: Optimized for data that is accessed frequently.
Characteristics:
Use cases:
Detailed Example 1: E-Commerce Product Images
Scenario: Store product images for an e-commerce website.
Data characteristics:
Solution: Hot tier
Reasoning: Images are accessed constantly, hot tier provides best performance and lowest total cost.
What it is: Optimized for data that is infrequently accessed and stored for at least 30 days.
Characteristics:
Use cases:
Detailed Example 2: Monthly Backups
Scenario: Store monthly database backups that are rarely accessed.
Data characteristics:
Solution: Cool tier
Savings: 50% cost reduction compared to hot tier.
What it is: Optimized for data that is rarely accessed and stored for at least 90 days.
Characteristics:
Use cases:
What it is: Optimized for data that is rarely accessed and stored for at least 180 days. Data must be rehydrated before access.
Characteristics:
Rehydration:
Use cases:
Detailed Example 3: Financial Records Archive
Scenario: Store financial records for 7 years (regulatory requirement).
Data characteristics:
Solution: Archive tier
Comparison:
Savings: $18,480 (92% cost reduction) compared to hot tier.
| Tier | Storage Cost | Access Cost | Retrieval Time | Min Duration | Use Case |
|---|---|---|---|---|---|
| Hot | $$$ | $ | Immediate | None | Active data |
| Cool | $$ | $$ | Immediate | 30 days | Infrequent access |
| Cold | $ | $$$ | Immediate | 90 days | Rare access |
| Archive | $ | $$$$ | Hours | 180 days | Long-term archive |
What it is: Lifecycle management automatically transitions blobs between access tiers or deletes them based on rules you define.
Why it exists: Manually moving blobs between tiers is time-consuming and error-prone. Lifecycle management automates this based on age or last access time.
How it works:
Detailed Example 1: Automated Backup Lifecycle
Scenario: Manage backup retention automatically.
Requirements:
Lifecycle Policy:
{
"rules": [
{
"name": "move-to-cool",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["backups/"]
},
"actions": {
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 7
}
}
}
}
},
{
"name": "move-to-archive",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["backups/"]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 90
}
}
}
}
},
{
"name": "delete-old-backups",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["backups/"]
},
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 2555
}
}
}
}
}
]
}
Benefits:
⭐ Must Know (Critical Facts):
Decision Framework for Access Tiers:
How often is data accessed?
├─ Daily/Weekly → Hot tier
├─ Monthly → Cool tier
├─ Quarterly → Cold tier
└─ Rarely/Never → Archive tier
How long will data be stored?
├─ <30 days → Hot tier only
├─ 30-90 days → Hot or Cool
├─ 90-180 days → Hot, Cool, or Cold
└─ >180 days → Any tier including Archive
Can you wait hours for data retrieval?
├─ No → Hot, Cool, or Cold
└─ Yes → Archive tier acceptable
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Using hot tier for all data
Mistake 2: Not understanding archive tier rehydration
Mistake 3: Deleting cool/cold/archive blobs before minimum duration
🔗 Connections to Other Topics:
The problem: Hardware failures, data center outages, and regional disasters can cause data loss and service interruptions.
The solution: Azure Storage provides multiple redundancy options that replicate your data to protect against failures at different scales.
Why it's tested: Understanding redundancy options is critical for designing resilient storage solutions and is heavily tested on AZ-104.
What it is: Azure Storage redundancy determines how many copies of your data are maintained and where those copies are stored to protect against failures.
Why it exists: Different applications have different durability and availability requirements. A development environment might tolerate some data loss, while a production financial system cannot. Azure provides multiple redundancy options so you can choose the right balance of cost, durability, and availability for your needs.
Real-world analogy: Think of redundancy like backup strategies for important documents. You might keep one copy in your desk (LRS), copies in different filing cabinets in the same office (ZRS), or copies in a completely different office building across town (GRS). Each approach protects against different types of disasters.
How it works (Detailed step-by-step):
📊 Storage Redundancy Options Diagram:
graph TB
subgraph "Primary Region: East US"
subgraph "LRS - Single Zone"
LRS1[Copy 1]
LRS2[Copy 2]
LRS3[Copy 3]
end
subgraph "ZRS - Three Zones"
Z1[Zone 1<br/>Copy 1]
Z2[Zone 2<br/>Copy 2]
Z3[Zone 3<br/>Copy 3]
end
end
subgraph "Secondary Region: West US"
subgraph "GRS/GZRS Secondary"
SEC1[Copy 1]
SEC2[Copy 2]
SEC3[Copy 3]
end
end
LRS1 -.Synchronous.-> LRS2
LRS2 -.Synchronous.-> LRS3
Z1 -.Synchronous.-> Z2
Z2 -.Synchronous.-> Z3
Z3 -.Asynchronous<br/>Geo-Replication.-> SEC1
SEC1 -.Synchronous.-> SEC2
SEC2 -.Synchronous.-> SEC3
style LRS1 fill:#e1f5fe
style LRS2 fill:#e1f5fe
style LRS3 fill:#e1f5fe
style Z1 fill:#c8e6c9
style Z2 fill:#c8e6c9
style Z3 fill:#c8e6c9
style SEC1 fill:#fff3e0
style SEC2 fill:#fff3e0
style SEC3 fill:#fff3e0
See: diagrams/03_domain_2_storage_redundancy_overview.mmd
Diagram Explanation (detailed):
This diagram illustrates the three main categories of Azure Storage redundancy. On the left, Locally Redundant Storage (LRS) maintains three synchronous copies within availability zones in a single region (shown in blue). This protects against individual hardware failures but not against zone or region-level disasters. In the middle, Zone-Redundant Storage (ZRS) maintains three synchronous copies across three separate availability zones within the primary region (shown in green). Each zone is a physically separate data center with independent power, cooling, and networking, protecting against zone-level failures. On the right, Geo-Redundant Storage (GRS/GZRS) adds a secondary region (shown in orange) hundreds of miles away. Data is first replicated in the primary region (using LRS or ZRS), then asynchronously replicated to the secondary region where it's stored using LRS. The asynchronous replication means there's a small delay (typically under 15 minutes) between writes to primary and secondary regions. This protects against complete regional disasters but introduces a potential Recovery Point Objective (RPO) of up to 15 minutes.
Detailed Example 1: LRS for Development Environment
A software development team needs storage for their test environment where they store application logs, test data, and temporary build artifacts. They choose Locally Redundant Storage (LRS) for their storage account. Here's what happens: (1) When they upload a 100 MB log file, Azure immediately creates 3 copies within availability zones in the East US region. (2) The write operation completes in milliseconds because all copies are in the same region. (3) One day, a server rack experiences a power failure. Azure automatically serves data from one of the other two copies without any interruption. (4) The cost is minimal - only $0.018 per GB per month for hot tier storage. (5) If the entire East US region experiences an outage (rare but possible), their data would be unavailable until the region recovers. This is acceptable for a development environment where data can be regenerated and brief outages are tolerable. Total cost for 1 TB of storage: approximately $18/month.
Detailed Example 2: ZRS for Production Application
An e-commerce company runs a production web application that stores product images and customer uploads in Azure Blob Storage. They choose Zone-Redundant Storage (ZRS) for high availability. Here's the scenario: (1) When a customer uploads a product review photo (5 MB), Azure synchronously writes the data to three separate availability zones in the West Europe region. (2) Each zone is a physically separate data center with independent infrastructure. (3) During a planned maintenance event, Zone 1 is taken offline. The application continues serving images from Zones 2 and 3 without any downtime or performance degradation. (4) A few months later, Zone 2 experiences a cooling system failure and goes offline temporarily. The application still operates normally using Zones 1 and 3. (5) The cost is slightly higher than LRS - approximately $0.0225 per GB per month for hot tier. (6) The company achieves 99.9999999999% (12 nines) durability and 99.9% availability SLA. For 1 TB of storage, the cost is approximately $22.50/month - only $4.50 more than LRS but with significantly better availability.
Detailed Example 3: GZRS for Mission-Critical Financial Data
A financial services company stores transaction records and audit logs that must survive regional disasters. They choose Geo-Zone-Redundant Storage (GZRS) with Read-Access (RA-GZRS). Here's how it works: (1) When a transaction record is written (10 KB), Azure first synchronously replicates it across three availability zones in the primary region (East US 2) using ZRS. (2) The write operation completes and returns success to the application. (3) Within seconds to minutes, Azure asynchronously replicates the data to the paired secondary region (Central US) where it's stored using LRS (3 copies). (4) The application can read from either the primary region (for lowest latency) or the secondary region (for disaster recovery testing or geographic load distribution). (5) During a catastrophic hurricane that takes down the entire East US 2 region, the company initiates a failover to Central US. (6) After failover (typically 1-2 hours), Central US becomes the new primary region and the application resumes full read/write operations. (7) The RPO (Recovery Point Objective) is typically under 15 minutes, meaning they might lose up to 15 minutes of recent writes. (8) The cost is highest - approximately $0.045 per GB per month for hot tier. For 1 TB of storage, the cost is approximately $45/month, but this provides 99.99999999999999% (16 nines) durability and protection against regional disasters.
⭐ Must Know (Critical Facts):
When to use (Comprehensive):
Limitations & Constraints:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Assuming GRS provides instant failover
Mistake 2: Thinking RA-GRS allows writes to secondary region
Mistake 3: Believing ZRS protects against regional disasters
Mistake 4: Assuming all storage services support all redundancy options
🔗 Connections to Other Topics:
The problem: Storage accounts contain sensitive data that must be protected from unauthorized access while still allowing legitimate users and applications to access it.
The solution: Azure Storage provides multiple security mechanisms including access keys, Shared Access Signatures (SAS), Azure AD authentication, and network security controls.
Why it's tested: Security is a critical aspect of Azure administration and is heavily tested on AZ-104, especially SAS tokens and access control.
What it is: A Shared Access Signature (SAS) is a URI that grants restricted access rights to Azure Storage resources without exposing your account keys. It's a secure way to grant temporary, limited access to storage resources.
Why it exists: You often need to give clients access to storage resources without giving them your storage account keys (which would grant full access to everything). For example, a mobile app needs to upload photos to blob storage, or a partner needs to download specific files. SAS tokens solve this by providing time-limited, permission-specific access to exactly the resources needed.
Real-world analogy: Think of SAS tokens like temporary visitor badges at an office building. Instead of giving someone your employee badge (account key) which grants access to everything, you give them a visitor badge that only works for specific floors, during specific hours, and expires at the end of the day. If the badge is lost or stolen, it's only valid for a limited time and limited areas.
How it works (Detailed step-by-step):
📊 SAS Token Types and Flow Diagram:
graph TB
subgraph "SAS Token Types"
UD[User Delegation SAS<br/>Signed with Azure AD credentials<br/>Most secure]
SVC[Service SAS<br/>Signed with account key<br/>Container/blob/file/queue level]
ACC[Account SAS<br/>Signed with account key<br/>Account-wide access]
end
subgraph "SAS Creation Flow"
A[Administrator] -->|1. Creates SAS| B[Azure Storage]
B -->|2. Returns SAS URI| A
A -->|3. Shares SAS URI| C[Client Application]
end
subgraph "SAS Usage Flow"
C -->|4. Request with SAS| D[Azure Storage]
D -->|5. Validates| E{Valid?}
E -->|Yes| F[Grant Access]
E -->|No| G[403 Forbidden]
end
subgraph "Stored Access Policy"
SAP[Stored Access Policy<br/>on Container]
SAP -->|Defines| SAP1[Start Time]
SAP -->|Defines| SAP2[Expiry Time]
SAP -->|Defines| SAP3[Permissions]
SAP -->|Can be| SAP4[Modified/Revoked]
end
style UD fill:#c8e6c9
style SVC fill:#e1f5fe
style ACC fill:#fff3e0
style F fill:#c8e6c9
style G fill:#ffebee
See: diagrams/03_domain_2_sas_overview.mmd
Diagram Explanation (detailed):
This diagram illustrates the three types of SAS tokens and their lifecycle. At the top, we see User Delegation SAS (green) which is the most secure option because it's signed with Azure AD credentials instead of the account key. This means even if the SAS is compromised, the attacker doesn't have access to your account key. Service SAS (blue) is signed with the account key and provides access to specific services like blob containers or file shares. Account SAS (orange) is also signed with the account key but provides broader access across multiple services in the storage account.
The middle section shows the creation flow: (1) An administrator creates a SAS token by specifying permissions, expiry time, and resources. (2) Azure Storage generates a signed URI containing all these parameters plus a cryptographic signature. (3) The administrator shares this URI with the client application that needs access.
The bottom left shows the usage flow: (4) The client makes a request to Azure Storage including the SAS token in the URI. (5) Azure validates the token by checking the signature, expiry time, permissions, and IP restrictions. If valid, access is granted (green); if invalid, a 403 Forbidden error is returned (red).
The bottom right shows Stored Access Policies, which are optional but recommended. A stored access policy is defined on a container and specifies start time, expiry time, and permissions. When you create a SAS associated with a stored access policy, the SAS inherits these constraints. The key benefit is that you can modify or revoke the policy later, which immediately affects all SAS tokens associated with it. Without a stored access policy, the only way to revoke a SAS is to regenerate the account key, which breaks all SAS tokens and applications using that key.
Detailed Example 1: Mobile App Photo Upload with Service SAS
A photo-sharing mobile app needs to allow users to upload photos directly to Azure Blob Storage without routing through your web server. Here's how you implement this with SAS: (1) When a user wants to upload a photo, your web API generates a Service SAS token for a specific blob in the user's container. (2) The SAS grants only "write" permission (not read or delete) and expires in 1 hour. (3) The SAS is scoped to a specific blob path like /users/user123/photos/photo456.jpg. (4) Your API returns the SAS URI to the mobile app. (5) The mobile app uploads the photo directly to Azure Storage using the SAS URI, bypassing your web server entirely. (6) After 1 hour, the SAS expires automatically. If the user tries to use it again, they get a 403 Forbidden error. (7) This approach saves bandwidth on your web server and provides better performance since uploads go directly to Azure Storage. (8) Even if an attacker intercepts the SAS token, they can only write to that specific blob for 1 hour - they can't read other users' photos or delete anything.
Detailed Example 2: Partner File Download with Stored Access Policy
Your company needs to share monthly reports with a business partner. You want to give them access for 30 days but retain the ability to revoke access if needed. Here's the solution: (1) Create a blob container called "partner-reports" and upload the monthly report files. (2) Create a Stored Access Policy on the container named "partner-access" with: start time = today, expiry time = 30 days from now, permissions = read + list. (3) Generate a Service SAS token associated with this stored access policy. (4) Share the SAS URI with your partner. (5) The partner can list files in the container and download them for 30 days. (6) After 2 weeks, you discover a security concern and need to revoke access immediately. (7) You modify the stored access policy to set the expiry time to "now" (or delete the policy entirely). (8) Within 30 seconds, the partner's SAS token stops working - they get 403 Forbidden errors. (9) You didn't need to regenerate your storage account key, so all your other applications continue working normally. (10) This demonstrates the key advantage of stored access policies: you can revoke SAS tokens without regenerating account keys.
Detailed Example 3: User Delegation SAS for Maximum Security
A healthcare application stores patient medical records in blob storage and needs to provide secure, temporary access to doctors. Here's the most secure approach using User Delegation SAS: (1) The application uses Azure AD authentication (not account keys). (2) When Dr. Smith logs in with her Azure AD credentials, the application requests a user delegation key from Azure Storage. (3) The application creates a User Delegation SAS signed with this key (not the account key) that grants Dr. Smith read access to her patients' records for 8 hours. (4) Dr. Smith uses the SAS to access patient records throughout her shift. (5) The key advantage: even if the SAS token is compromised, the attacker doesn't have the storage account key. (6) The user delegation key automatically expires after 7 days maximum (usually set much shorter). (7) If Dr. Smith's Azure AD account is disabled or her permissions are revoked, new SAS tokens can't be generated. (8) This provides defense-in-depth: Azure AD controls who can generate SAS tokens, and the SAS tokens themselves are time-limited and permission-specific. (9) For compliance requirements (HIPAA, GDPR), this approach provides better audit trails since access is tied to Azure AD identities, not anonymous account keys.
⭐ Must Know (Critical Facts):
When to use (Comprehensive):
Limitations & Constraints:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Using Account SAS for everything
Mistake 2: Creating SAS tokens with very long expiry times (months/years)
Mistake 3: Thinking stored access policy immediately revokes SAS
Mistake 4: Believing you can audit who generated a SAS token
Mistake 5: Using ad hoc SAS when you might need to revoke access
🔗 Connections to Other Topics:
The problem: Organizations need shared file storage that can be accessed from multiple machines, supports standard file protocols (SMB/NFS), and integrates with existing identity systems.
The solution: Azure Files provides fully managed file shares in the cloud that are accessible via industry-standard SMB and NFS protocols.
Why it's tested: Azure Files is a key storage service for lift-and-shift scenarios and is frequently tested on AZ-104, especially identity-based authentication.
What it is: Azure Files offers fully managed file shares in the cloud that are accessible via the Server Message Block (SMB) protocol or Network File System (NFS) protocol. Azure file shares can be mounted concurrently by cloud or on-premises deployments.
Why it exists: Traditional file servers require hardware, maintenance, patching, and backup management. Organizations moving to the cloud need a way to replace on-premises file servers without rewriting applications or changing how users access files. Azure Files provides a cloud-native file share solution that works exactly like traditional file servers but without the infrastructure overhead.
Real-world analogy: Think of Azure Files like a network drive (like the H: drive at work) but hosted in the cloud instead of on a local file server. Users can map it as a drive letter, applications can access it using standard file paths, and it supports the same permissions and authentication as traditional file servers.
How it works (Detailed step-by-step):
📊 Azure Files Architecture Diagram:
graph TB
subgraph "Client Access"
WIN[Windows Client<br/>SMB 3.x]
LIN[Linux Client<br/>SMB 3.x or NFS 4.1]
APP[Applications<br/>Standard File I/O]
end
subgraph "Authentication Layer"
AD[On-premises AD DS]
AADDS[Azure AD Domain Services]
AADKERB[Azure AD Kerberos]
KEY[Storage Account Key]
end
subgraph "Azure Files Service"
SHARE[File Share<br/>SMB or NFS]
SNAP[Snapshots]
BACKUP[Azure Backup]
end
subgraph "Storage Backend"
STD[Standard Storage<br/>HDD-based]
PREM[Premium Storage<br/>SSD-based]
end
WIN -->|Mount| SHARE
LIN -->|Mount| SHARE
APP -->|File I/O| SHARE
AD -.Identity.-> SHARE
AADDS -.Identity.-> SHARE
AADKERB -.Identity.-> SHARE
KEY -.Fallback.-> SHARE
SHARE --> SNAP
SHARE --> BACKUP
SHARE --> STD
SHARE --> PREM
style WIN fill:#e1f5fe
style LIN fill:#e1f5fe
style SHARE fill:#c8e6c9
style AD fill:#fff3e0
style AADDS fill:#fff3e0
style AADKERB fill:#fff3e0
See: diagrams/03_domain_2_azure_files_architecture.mmd
Diagram Explanation (detailed):
This diagram illustrates the complete Azure Files architecture. At the top, we see three types of clients that can access Azure Files: Windows clients using SMB 3.x protocol (blue), Linux clients using either SMB 3.x or NFS 4.1 protocol (blue), and Applications using standard file I/O operations (blue). All three mount the file share and access it like a local or network drive.
In the middle, the Authentication Layer shows four options for authenticating to Azure Files. On-premises AD DS (orange) allows you to use your existing Active Directory credentials - users sign in with their domain accounts and access files with the same permissions they have on-premises. Azure AD Domain Services (orange) provides a managed domain controller in Azure for organizations that don't want to maintain on-premises domain controllers. Azure AD Kerberos (orange) is the newest option that allows hybrid identities (synced from on-premises AD to Azure AD) to authenticate without requiring network connectivity to domain controllers. Storage Account Key (orange) is the fallback option that provides full access but doesn't support identity-based permissions.
The Azure Files Service layer (green) shows the file share itself, which can be either SMB or NFS protocol. The service includes Snapshots for point-in-time recovery and Azure Backup for long-term retention and disaster recovery.
At the bottom, the Storage Backend shows two performance tiers: Standard Storage (HDD-based) for cost-effective general-purpose file shares, and Premium Storage (SSD-based) for high-performance workloads requiring low latency and high IOPS.
Detailed Example 1: Replacing On-Premises File Server with SMB Share
A company has an on-premises Windows file server hosting departmental shares (HR, Finance, Engineering). They want to migrate to Azure Files. Here's the process: (1) They create a Standard storage account in Azure with LRS redundancy. (2) They create three SMB file shares: "hr-share", "finance-share", and "engineering-share", each with a 1 TB quota. (3) They enable identity-based authentication using their on-premises Active Directory (AD DS). This requires running the AzFilesHybrid PowerShell module to domain-join the storage account. (4) They configure share-level permissions using Azure RBAC: HR group gets "Storage File Data SMB Share Contributor" on hr-share, Finance group on finance-share, etc. (5) They use Robocopy to migrate files from the on-premises server to Azure Files, preserving all ACLs and timestamps. (6) They configure file-level permissions (Windows ACLs) on folders and files, just like on the old file server. (7) Users map the Azure file shares as network drives using their domain credentials: net use H: \\storageaccount.file.core.windows.net\hr-share. (8) Users access files exactly as before - no training needed, no application changes required. (9) The company decommissions the old file server, saving hardware costs and eliminating maintenance overhead. (10) Azure handles all replication, patching, and high availability automatically.
Detailed Example 2: Linux Application with NFS Share
A software development team runs a Linux-based build system that needs shared storage for source code and build artifacts. They choose Azure Files with NFS protocol. Here's the implementation: (1) They create a Premium storage account (required for NFS) with ZRS redundancy for high availability. (2) They create an NFS 4.1 file share named "build-artifacts" with a 5 TB quota. (3) NFS shares don't support identity-based authentication, so they configure network security instead: they restrict access to specific virtual networks using service endpoints. (4) They mount the NFS share on their Linux build servers using standard mount command: sudo mount -t nfs storageaccount.file.core.windows.net:/storageaccount/build-artifacts /mnt/build. (5) They configure POSIX permissions on directories: build servers have read/write access, developer workstations have read-only access. (6) The build system writes compiled binaries and artifacts to the NFS share. (7) Developers access the artifacts from their workstations for testing and deployment. (8) The Premium SSD storage provides low latency (single-digit milliseconds) required for build performance. (9) They configure Azure Backup to take daily snapshots of the share for disaster recovery. (10) The solution scales to handle thousands of concurrent file operations during peak build times.
Detailed Example 3: Hybrid Cloud with Azure AD Kerberos
A healthcare organization has hybrid infrastructure with on-premises AD synced to Azure AD. They want remote workers to access file shares without VPN. Here's the solution: (1) They create a Standard storage account with GRS redundancy for disaster recovery. (2) They create an SMB file share named "patient-records" with a 10 TB quota. (3) They enable Azure AD Kerberos authentication on the storage account. This allows hybrid identities (users synced from on-premises AD to Azure AD) to authenticate. (4) They configure share-level permissions: "Healthcare-Staff" Azure AD group gets "Storage File Data SMB Share Contributor" role. (5) They configure file-level ACLs on folders: doctors have full access to their patients' folders, nurses have read-only access, billing staff have access only to billing documents. (6) Remote workers on Azure AD-joined laptops (no VPN) can mount the file share using their Azure AD credentials: net use P: \\storageaccount.file.core.windows.net\patient-records. (7) Azure AD issues Kerberos tickets for authentication - no need for network connectivity to on-premises domain controllers. (8) The solution provides secure access to sensitive patient data with full audit trails (Azure AD logs all authentication attempts). (9) If a user's Azure AD account is disabled, they immediately lose access to the file share. (10) The organization meets HIPAA compliance requirements with encryption at rest and in transit, identity-based access control, and comprehensive audit logging.
⭐ Must Know (Critical Facts):
When to use (Comprehensive):
Limitations & Constraints:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Trying to use NFS with Standard storage
Mistake 2: Expecting identity-based authentication with NFS
Mistake 3: Thinking storage account key provides identity-based permissions
Mistake 4: Assuming Azure Files works like Blob Storage
🔗 Connections to Other Topics:
Test yourself before moving on:
Try these from your practice test bundles:
If you scored below 70%:
[One-page summary of chapter - copy to your notes]
Storage Redundancy Options:
Blob Access Tiers:
SAS Token Types:
Azure Files Protocols:
Decision Points:
File: 04_domain_3_compute
What you'll learn:
Time to complete: 10-12 hours
Prerequisites: Chapter 0 (Fundamentals), Chapter 1 (Identities and Governance)
The problem: Organizations need compute resources to run applications, but managing physical servers is expensive, time-consuming, and inflexible.
The solution: Azure Virtual Machines provide on-demand, scalable compute resources without the overhead of physical hardware management.
Why it's tested: VMs are fundamental to Azure infrastructure and are heavily tested on AZ-104, especially availability options and disk management.
What it is: An Azure Virtual Machine (VM) is an on-demand, scalable computing resource that provides the flexibility of virtualization without having to buy and maintain physical hardware.
Why it exists: Organizations need compute resources for various workloads - web servers, application servers, databases, development environments, etc. Buying and maintaining physical servers requires significant capital investment, space, power, cooling, and ongoing maintenance. Azure VMs provide compute resources on-demand, paying only for what you use, with the ability to scale up or down as needed.
Real-world analogy: Think of Azure VMs like renting an apartment instead of buying a house. You get the space you need, pay monthly, can move to a bigger or smaller place easily, and don't worry about maintenance, repairs, or property taxes. The landlord (Azure) handles all the infrastructure.
How it works (Detailed step-by-step):
📊 VM Architecture Diagram:
graph TB
subgraph "VM Components"
VM[Virtual Machine]
OS[OS Disk<br/>Managed Disk]
DATA[Data Disks<br/>Optional]
NIC[Network Interface<br/>Private IP]
PIP[Public IP<br/>Optional]
NSG[Network Security Group<br/>Firewall Rules]
end
subgraph "Availability Options"
AS[Availability Set<br/>99.95% SLA]
AZ[Availability Zone<br/>99.99% SLA]
VMSS[VM Scale Set<br/>99.95% SLA]
end
subgraph "Storage Backend"
STD[Standard HDD<br/>Cost-effective]
STDSSD[Standard SSD<br/>Balanced]
PREMSSD[Premium SSD<br/>High performance]
ULTRA[Ultra Disk<br/>Extreme performance]
end
VM --> OS
VM --> DATA
VM --> NIC
NIC --> PIP
NIC --> NSG
VM -.Deployed in.-> AS
VM -.Deployed in.-> AZ
VM -.Deployed in.-> VMSS
OS --> STD
OS --> STDSSD
OS --> PREMSSD
DATA --> ULTRA
style VM fill:#c8e6c9
style OS fill:#e1f5fe
style NIC fill:#fff3e0
style AS fill:#f3e5f5
style AZ fill:#f3e5f5
style VMSS fill:#f3e5f5
See: diagrams/04_domain_3_vm_architecture.mmd
Diagram Explanation (detailed):
This diagram illustrates the complete architecture of an Azure Virtual Machine. At the center, the Virtual Machine (green) is the compute resource that runs your workload. Connected to it are several key components:
The OS Disk (blue) is a managed disk that contains the operating system and is required for every VM. It's typically 127 GB or larger depending on the OS. Data Disks (blue) are optional additional disks you can attach for application data, databases, or other storage needs. You can attach up to 64 data disks per VM depending on the VM size.
The Network Interface (orange) provides network connectivity and is assigned a private IP address from the virtual network subnet. Optionally, you can attach a Public IP (orange) to enable internet access to the VM. The Network Security Group (orange) acts as a firewall, controlling inbound and outbound traffic with rules based on source/destination IP, port, and protocol.
The middle section shows Availability Options (purple). An Availability Set provides 99.95% SLA by distributing VMs across multiple fault domains (separate racks) and update domains (for planned maintenance). Availability Zones provide 99.99% SLA by distributing VMs across physically separate datacenters within a region. VM Scale Sets provide 99.95% SLA and add auto-scaling capabilities.
The bottom section shows Storage Backend options. Standard HDD is the most cost-effective option for dev/test workloads. Standard SSD provides balanced performance for general-purpose workloads. Premium SSD offers high performance with low latency for production workloads. Ultra Disk provides extreme performance with sub-millisecond latency for the most demanding workloads like SAP HANA and SQL Server.
Detailed Example 1: Creating a Web Server VM
A company needs to deploy a web server to host their corporate website. Here's the complete process: (1) They navigate to Azure Portal and click "Create a resource" → "Virtual Machine". (2) They select the subscription and create a new resource group called "web-servers-rg". (3) They name the VM "web-vm-01" and select the region "East US". (4) For availability, they choose "Availability zone" and select "Zone 1" for 99.99% SLA. (5) They select the image "Windows Server 2022 Datacenter" from Azure Marketplace. (6) They choose VM size "Standard_D2s_v3" (2 vCPUs, 8 GB RAM) which is appropriate for a small web server. (7) They configure administrator credentials: username "webadmin" and a strong password. (8) For disks, they keep the default OS disk (127 GB Premium SSD) and add one data disk (256 GB Premium SSD) for website files. (9) For networking, they select an existing virtual network "web-vnet" and subnet "web-subnet". They enable a public IP address so the website is accessible from the internet. (10) They configure the Network Security Group to allow inbound traffic on ports 80 (HTTP) and 443 (HTTPS) from the internet, and port 3389 (RDP) from their office IP address only. (11) They enable Azure Backup with daily backups retained for 30 days. (12) They review the configuration and click "Create". Azure provisions the VM in about 5 minutes. (13) They connect via RDP, install IIS web server, configure the website on the data disk, and the site is live. Total monthly cost: approximately $70 for the VM + $20 for disks + $5 for backup = $95/month.
Detailed Example 2: Database Server with High Availability
A financial services company needs a SQL Server database with high availability. Here's their implementation: (1) They create two VMs in an Availability Set to achieve 99.95% SLA. (2) VM configuration: "Standard_E4s_v3" size (4 vCPUs, 32 GB RAM, optimized for memory-intensive workloads). (3) They select "SQL Server 2022 Enterprise on Windows Server 2022" image from Azure Marketplace. (4) For storage, they attach 4 Premium SSD data disks (1 TB each) and configure them in a storage pool for better performance. (5) They place both VMs in the same Availability Set but Azure automatically distributes them across different fault domains (separate racks) and update domains. (6) They configure SQL Server Always On Availability Groups between the two VMs for automatic failover. (7) They place an Azure Load Balancer in front of the VMs to route database connections to the active primary replica. (8) For security, they configure Network Security Groups to allow SQL Server traffic (port 1433) only from the application tier subnet, and RDP access only from a management subnet. (9) They enable Azure Disk Encryption on all disks to encrypt data at rest. (10) They configure automated backups using SQL Server native backup to Azure Blob Storage. (11) During a planned maintenance event, Azure updates one VM at a time (different update domains), so the database remains available. (12) If a hardware failure occurs in one fault domain, the other VM continues serving requests with automatic failover. Total monthly cost: approximately $600 per VM × 2 = $1,200 + $400 for disks + $50 for load balancer = $1,650/month.
Detailed Example 3: Development Environment with Cost Optimization
A software development team needs VMs for development and testing. Here's their cost-optimized approach: (1) They create VMs using "Standard_B2ms" size (2 vCPUs, 8 GB RAM) which is a burstable VM type - perfect for dev/test workloads that don't need consistent high performance. (2) They select "Ubuntu 20.04 LTS" image (free, no Windows licensing costs). (3) For disks, they use Standard SSD (not Premium) since dev/test doesn't require ultra-low latency. (4) They configure the VMs to automatically shut down at 7 PM every day using Azure DevTest Labs auto-shutdown feature. (5) They start the VMs manually when developers arrive in the morning. (6) On weekends, the VMs remain stopped (deallocated), so they only pay for storage, not compute. (7) They use Azure Spot VMs for non-critical test environments, getting up to 90% discount but accepting that Azure can evict the VMs with 30 seconds notice when capacity is needed. (8) They configure Azure Advisor to monitor for underutilized VMs and right-size them. (9) After 3 months, they discover one VM is consistently using only 10% CPU, so they downsize it to "Standard_B1ms" (1 vCPU, 2 GB RAM), cutting costs in half. (10) Result: Instead of paying $140/month per VM running 24/7, they pay approximately $50/month per VM (running only 10 hours/day, 5 days/week), saving 64% on compute costs.
⭐ Must Know (Critical Facts):
When to use (Comprehensive):
Limitations & Constraints:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Stopping a VM from the OS and expecting no charges
Mistake 2: Thinking Availability Sets protect against regional disasters
Mistake 3: Assuming all VM sizes are available in all regions and zones
Mistake 4: Using Standard HDD for production databases
🔗 Connections to Other Topics:
The problem: Applications need to scale dynamically based on demand, but manually creating and managing multiple VMs is time-consuming and error-prone.
The solution: Azure Virtual Machine Scale Sets automatically create and manage a group of load-balanced VMs that can scale in or out based on demand or schedule.
Why it's tested: VM Scale Sets are essential for building scalable, highly available applications and are frequently tested on AZ-104.
What it is: Azure Virtual Machine Scale Sets let you create and manage a group of load-balanced VMs that can automatically increase or decrease in number based on demand or a defined schedule.
Why it exists: Modern applications experience variable load - high traffic during business hours, low traffic at night; seasonal spikes during holidays; unpredictable viral events. Manually scaling by creating/deleting VMs is slow and inefficient. VM Scale Sets automate this process, ensuring you have the right number of VMs to handle current load while minimizing costs.
Real-world analogy: Think of VM Scale Sets like a restaurant that automatically adjusts its staff based on customer traffic. During lunch rush, more servers appear automatically. During slow periods, staff is reduced. You don't manually hire and fire people throughout the day - the system handles it automatically based on demand.
How it works (Detailed step-by-step):
⭐ Must Know (Critical Facts):
When to use (Comprehensive):
Limitations & Constraints:
💡 Tips for Understanding:
⚠️ Common Mistakes & Misconceptions:
Mistake 1: Setting minimum instances to 0
Mistake 2: Using very short cooldown periods
Mistake 3: Not configuring health probes
🔗 Connections to Other Topics:
The problem: Traditional VMs require OS management, patching, and configuration, adding overhead for containerized applications.
The solution: Azure provides multiple container services (ACI, Container Apps, AKS) that run containers without managing VMs.
Why it's tested: Containers are increasingly popular, and AZ-104 tests understanding of when to use each container service.
What it is: Azure Container Instances is the fastest and simplest way to run a container in Azure without managing VMs or orchestrators.
Why it exists: Sometimes you just need to run a single container or a small group of containers for a short time - batch jobs, CI/CD tasks, event-driven processing. Setting up a full Kubernetes cluster or managing VMs is overkill. ACI provides on-demand containers that start in seconds and bill per second.
Real-world analogy: ACI is like renting a car for a few hours from a car-sharing service. You don't buy the car, maintain it, or pay for it when you're not using it. You just grab it when needed, use it, and return it. Perfect for short-term, simple needs.
⭐ Must Know (Critical Facts):
What it is: Azure Container Apps is a fully managed serverless container service for building and deploying modern apps and microservices using containers.
Why it exists: Developers want to deploy containerized applications without managing Kubernetes clusters or infrastructure. Container Apps provides automatic scaling (including scale-to-zero), built-in load balancing, and integrated monitoring without the complexity of Kubernetes.
⭐ Must Know (Critical Facts):
What it is: Azure Container Registry is a managed Docker registry service for storing and managing private container images.
Why it exists: Public registries like Docker Hub are great for public images, but organizations need private registries for proprietary images with security, compliance, and performance requirements. ACR provides geo-replication, security scanning, and integration with Azure services.
⭐ Must Know (Critical Facts):
When to use each container service:
Try these from your practice test bundles:
File: 05_domain_4_networking
What you'll learn:
Time to complete: 8-10 hours
Prerequisites: Chapter 0 (Fundamentals), Chapter 3 (Compute)
What it is: An Azure Virtual Network (VNet) is a logically isolated network in Azure that provides secure communication between Azure resources, the internet, and on-premises networks.
Why it exists: Resources in the cloud need to communicate securely. VNets provide network isolation, IP address management, and connectivity options similar to traditional on-premises networks but with the scale and availability of Azure.
How it works:
⭐ Must Know:
What it is: NSGs are Azure firewalls that filter network traffic to and from Azure resources based on rules.
Why it exists: Every network needs security controls to allow legitimate traffic and block malicious traffic. NSGs provide stateful firewall capabilities at the subnet and network interface level.
How it works:
⭐ Must Know:
What it is: VNet peering connects two VNets, allowing resources to communicate using private IP addresses as if they were in the same network.
Why it exists: Organizations often have multiple VNets for different environments (dev, test, prod) or different applications. Peering enables secure communication between VNets without internet exposure.
⭐ Must Know:
What it is: Azure Bastion provides secure RDP/SSH connectivity to VMs directly from Azure Portal without exposing VMs to the internet.
Why it exists: Traditional VM access requires public IPs and open RDP/SSH ports, creating security risks. Bastion eliminates these risks by providing secure access through Azure Portal over SSL.
⭐ Must Know:
Service Endpoints:
Private Endpoints:
⭐ Must Know:
What it is: Azure Load Balancer distributes network traffic across multiple VMs to ensure high availability and reliability.
Why it exists: Single VMs are single points of failure. Load balancers distribute traffic across multiple VMs, ensuring applications remain available even if individual VMs fail.
⭐ Must Know:
What it is: Azure DNS hosts DNS domains and provides name resolution using Microsoft Azure infrastructure.
Why it exists: Every application needs DNS for name resolution. Azure DNS provides reliable, secure DNS hosting with global availability and integration with Azure services.
⭐ Must Know:
Try these from your practice test bundles:
File: 06_domain_5_monitoring
What you'll learn:
Time to complete: 6-8 hours
Prerequisites: All previous chapters
What it is: Azure Monitor is a comprehensive monitoring solution that collects, analyzes, and acts on telemetry from Azure and on-premises environments.
Why it exists: Modern applications generate massive amounts of telemetry data (metrics, logs, traces). Without proper monitoring, issues go undetected until users complain. Azure Monitor provides centralized monitoring, alerting, and diagnostics.
How it works:
⭐ Must Know:
Metrics:
Logs:
⭐ Must Know:
What it is: Azure Monitor alerts proactively notify you when conditions are met in your monitoring data.
How it works:
⭐ Must Know:
What it is: Action groups define what happens when an alert fires - who gets notified and what actions are taken.
⭐ Must Know:
What it is: Azure Backup provides simple, secure, and cost-effective solutions to back up and recover data from Microsoft Azure cloud.
Why it exists: Data loss can occur from accidental deletion, corruption, ransomware, or disasters. Azure Backup provides automated, reliable backup with long-term retention and easy recovery.
How it works:
⭐ Must Know:
What it is: Azure Backup for VMs provides application-consistent backups without impacting VM performance.
⭐ Must Know:
What it is: Azure Site Recovery (ASR) orchestrates replication, failover, and recovery of workloads to ensure business continuity during outages.
Why it exists: Disasters happen - datacenter failures, regional outages, ransomware attacks. ASR provides automated disaster recovery with minimal RTO (Recovery Time Objective) and RPO (Recovery Point Objective).
How it works:
⭐ Must Know:
What it is: Network Watcher provides tools to monitor, diagnose, and gain insights into network performance and health.
⭐ Must Know:
Try these from your practice test bundles:
File: 07_integration
What it tests: Understanding of VMs, networking, storage, monitoring, and security across multiple domains.
Common pattern:
How to approach:
What it tests: Understanding of networking, identity, and governance.
Common pattern:
What it tests: Understanding of compute, storage, and governance.
Common pattern:
How to recognize:
What they're testing:
How to answer:
How to recognize:
What they're testing:
How to answer:
How to recognize:
What they're testing:
How to answer:
Need full OS control?
├─ Yes → Virtual Machines
└─ No → Containers or PaaS
├─ Simple container? → Azure Container Instances
├─ Serverless containers? → Azure Container Apps
├─ Full orchestration? → Azure Kubernetes Service
└─ Web app only? → Azure App Service
What type of data?
├─ Files (SMB/NFS) → Azure Files
├─ Objects (REST API) → Blob Storage
├─ Disks (VMs) → Managed Disks
└─ Structured data → Azure SQL/Cosmos DB
Need to connect VNets?
├─ Same region → Regional VNet peering
├─ Different regions → Global VNet peering
└─ On-premises → VPN Gateway or ExpressRoute
File: 08_study_strategies
Pass 1: Understanding (Weeks 1-6)
Pass 2: Application (Week 7-8)
Pass 3: Reinforcement (Week 9-10)
Mnemonics for NSG Priority:
Mnemonics for Storage Redundancy:
Strategy:
Step 1: Read the scenario (30 seconds)
Step 2: Identify constraints (15 seconds)
Step 3: Eliminate wrong answers (30 seconds)
Step 4: Choose best answer (45 seconds)
When stuck:
⚠️ Never: Spend more than 3 minutes on one question initially
Trick 1: "All of the above" options
Trick 2: Similar-sounding services
Trick 3: Unnecessary complexity
Trick 4: Keyword traps
Day 7: Full Practice Test 1 (target: 60%+)
Day 6: Review mistakes, study weak areas
Day 5: Full Practice Test 2 (target: 70%+)
Day 4: Review mistakes, focus on patterns
Day 3: Domain-focused tests for weak domains
Day 2: Full Practice Test 3 (target: 75%+)
Day 1: Review cheat sheet, relax, early sleep
Do:
Don't:
File: 09_final_checklist
Go through this checklist and mark items you're confident about:
Domain 1: Identities and Governance
Domain 2: Storage
Domain 3: Compute
Domain 4: Networking
Domain 5: Monitoring
If you checked fewer than 80%: Review those specific chapters
Day 7: Full Practice Test 1
Day 6: Review Day
Day 5: Full Practice Test 2
Day 4: Focused Review
Day 3: Domain-Focused Tests
Day 2: Full Practice Test 3
Day 1: Light Review
Hour 1: Cheat Sheet Review
Hour 2: Chapter Summaries
Hour 3: Flagged Items
Don't: Try to learn new topics or cram
3 hours before exam:
At testing center:
When exam starts, immediately write down on provided materials:
Time Management:
Question Strategy:
Stay Calm:
✅ You've prepared thoroughly
✅ Trust your knowledge
✅ Read questions carefully
✅ Manage your time
✅ Stay calm and confident
Good luck on your AZ-104 exam!
File: 99_appendices
| Option | Copies | Location | Durability | Availability (Read) | Cost | Use Case |
|---|---|---|---|---|---|---|
| LRS | 3 | Single zone | 11 nines | 99.9% | $ | Dev/test, easily reconstructible data |
| ZRS | 3 | 3 zones in region | 12 nines | 99.9% | $$ | Production, zone-level protection |
| GRS | 6 | 2 regions (LRS each) | 16 nines | 99.9% | $$$ | Business-critical, regional protection |
| RA-GRS | 6 | 2 regions (LRS each) | 16 nines | 99.99% | $$$$ | Read from secondary, regional protection |
| GZRS | 6 | 2 regions (ZRS + LRS) | 16 nines | 99.9% | $$$$ | Mission-critical, zone + regional protection |
| RA-GZRS | 6 | 2 regions (ZRS + LRS) | 16 nines | 99.99% | $$$$$ | Best protection, read from secondary |
| Tier | Access Frequency | Storage Cost | Access Cost | Minimum Duration | Rehydration | Use Case |
|---|---|---|---|---|---|---|
| Hot | Frequent | Highest | Lowest | None | N/A | Active data, frequent access |
| Cool | Infrequent | 50% lower | Higher | 30 days | N/A | Backups, short-term archives |
| Cold | Rare | 70% lower | Higher | 90 days | N/A | Long-term backups |
| Archive | Very rare | 90% lower | Highest | 180 days | Hours | Compliance archives, rarely accessed |
| Option | SLA | Protection Level | Max VMs | Cost | Use Case |
|---|---|---|---|---|---|
| Single VM (Premium SSD) | 99.9% | None | 1 | $ | Single instance, Premium SSD required |
| Availability Set | 99.95% | Rack-level | 200 | $ | Same datacenter, fault/update domains |
| Availability Zone | 99.99% | Datacenter-level | Unlimited | $ | Cross-datacenter, best availability |
| VM Scale Set | 99.95% | Rack-level | 1,000 | $ | Auto-scaling, load-balanced |
| Priority | Name | Direction | Source | Destination | Port | Protocol | Action |
|---|---|---|---|---|---|---|---|
| 65000 | AllowVnetInBound | Inbound | VirtualNetwork | VirtualNetwork | Any | Any | Allow |
| 65001 | AllowAzureLoadBalancerInBound | Inbound | AzureLoadBalancer | Any | Any | Any | Allow |
| 65500 | DenyAllInBound | Inbound | Any | Any | Any | Any | Deny |
| 65000 | AllowVnetOutBound | Outbound | VirtualNetwork | VirtualNetwork | Any | Any | Allow |
| 65001 | AllowInternetOutBound | Outbound | Any | Internet | Any | Any | Allow |
| 65500 | DenyAllOutBound | Outbound | Any | Any | Any | Any | Deny |
| Feature | Basic | Standard |
|---|---|---|
| Backend pool size | Up to 300 | Up to 1,000 |
| Backend pool endpoints | Single VNet | Multiple VNets, VMs, Scale Sets, Availability Sets |
| Health probes | HTTP, TCP | HTTP, HTTPS, TCP |
| Availability zones | No | Yes |
| SLA | None | 99.99% |
| Secure by default | No | Yes (closed to inbound unless NSG allows) |
| Cost | Free | Paid (per rule + data processed) |
| Use case | Dev/test | Production |
| Type | Signed With | Scope | Revocation | Max Expiry | Use Case |
|---|---|---|---|---|---|
| User Delegation | Azure AD credentials | Blob/Data Lake only | Via Azure AD | 7 days | Most secure, identity-based |
| Service SAS | Account key | Container/blob/file/queue | Via stored access policy | Unlimited | Container-level access |
| Account SAS | Account key | Account-wide | Account key regeneration only | Unlimited | Cross-service access |
| Option | Identity Source | Network Requirement | Use Case |
|---|---|---|---|
| Storage Account Key | N/A (key-based) | None | Administrative access only |
| On-premises AD DS | On-premises Active Directory | Network connectivity to DC | Hybrid environments, existing AD |
| Azure AD DS | Azure AD Domain Services | None (managed DC in Azure) | Cloud-only, managed domain |
| Azure AD Kerberos | Azure AD (hybrid identities) | None (no DC connectivity needed) | Hybrid identities, no VPN required |
| Resource | Limit |
|---|---|
| VMs per subscription per region | 25,000 (default quota, can be increased) |
| VM cores per subscription per region | Varies by VM family (can be increased) |
| Data disks per VM | Up to 64 (depends on VM size) |
| Max disk size | 32 TiB (managed disk) |
| Max VM size | 416 vCPUs, 12 TB RAM (M-series) |
| Availability Set fault domains | 2-3 (depends on region) |
| Availability Set update domains | 5-20 (configurable) |
| VMs per Availability Set | 200 |
| VMs per Scale Set | 1,000 |
| Resource | Limit |
|---|---|
| Storage accounts per subscription per region | 250 (default) |
| Max storage account capacity | 5 PiB |
| Max blob size (block blob) | 190.7 TiB |
| Max blob size (page blob) | 8 TiB |
| Max file share size (Standard) | 100 TiB |
| Max file share size (Premium) | 100 TiB |
| Max file size | 4 TiB |
| Snapshots per blob | 200 |
| Snapshots per file share | 200 |
| SAS token max expiry | Unlimited (but short duration recommended) |
| User Delegation SAS max expiry | 7 days |
| Resource | Limit |
|---|---|
| VNets per subscription per region | 1,000 |
| Subnets per VNet | 3,000 |
| VNet peerings per VNet | 500 |
| Private IP addresses per VNet | 65,536 (depends on address space) |
| Public IP addresses per subscription | 1,000 (Standard SKU) |
| NSGs per subscription per region | 5,000 |
| NSG rules per NSG | 1,000 (inbound + outbound) |
| Application Security Groups per subscription | 3,000 |
| Load Balancers per subscription | 1,000 |
| Load Balancer rules per Load Balancer | 150 |
| Resource | Limit |
|---|---|
| Metric retention | 93 days |
| Log Analytics workspace retention | 30-730 days (configurable) |
| Log Analytics workspace data ingestion | 10 GB/day (free tier), unlimited (paid) |
| Alert rules per subscription | 5,000 |
| Action groups per subscription | 2,000 |
| Notifications per action group | 10 |
Formula: Usable IPs = 2^(32 - prefix) - 5
Examples:
Azure Reserved IPs (per subnet):
VM Cost = (VM size hourly rate) × (hours running) + (disk cost) + (bandwidth cost)
Storage Cost = (capacity GB) × (storage tier rate) + (operations cost) + (data transfer cost)
Example VM Cost:
Availability Set: Logical grouping of VMs that distributes them across fault domains and update domains for high availability (99.95% SLA).
Availability Zone: Physically separate datacenter within an Azure region with independent power, cooling, and networking (99.99% SLA).
Azure AD (Microsoft Entra ID): Cloud-based identity and access management service.
Azure Bastion: Secure RDP/SSH connectivity to VMs without exposing them to the internet.
Blob Storage: Object storage for unstructured data (files, images, videos, backups).
Burstable VM: VM type (B-series) that accumulates credits during low usage and bursts during high usage.
CIDR: Classless Inter-Domain Routing, notation for IP address ranges (e.g., 10.0.0.0/16).
Container: Lightweight, standalone executable package that includes everything needed to run an application.
Cool Tier: Blob storage tier for infrequently accessed data with 30-day minimum storage duration.
Data Disk: Additional disk attached to VM for application data (optional, up to 64 per VM).
Deallocated: VM state where compute resources are released and no compute charges apply (storage still charged).
Fault Domain: Group of VMs that share a common power source and network switch (rack-level isolation).
Flexible Orchestration: VM Scale Set mode that supports mixed VM types and full VM lifecycle control (recommended).
GRS (Geo-Redundant Storage): Storage redundancy that replicates data to a secondary region hundreds of miles away (16 nines durability).
Hot Tier: Blob storage tier for frequently accessed data with highest storage cost but lowest access cost.
KQL (Kusto Query Language): Query language used in Log Analytics to analyze log data.
LRS (Locally Redundant Storage): Storage redundancy that maintains 3 copies within a single zone (11 nines durability).
Log Analytics: Azure Monitor component for collecting and analyzing log data using KQL queries.
Managed Disk: Azure-managed storage for VM disks (recommended over unmanaged disks).
Metrics: Numerical time-series data collected by Azure Monitor (CPU %, memory, disk I/O).
NSG (Network Security Group): Azure firewall that filters network traffic based on rules with priorities.
NFS: Network File System protocol for Linux file shares (requires Premium storage).
OS Disk: Required disk containing the operating system for a VM (typically 127 GB+).
Premium SSD: High-performance SSD storage with low latency (<10ms) for production workloads.
Private Endpoint: Brings Azure service into your VNet with a private IP address for complete network isolation.
RBAC (Role-Based Access Control): Authorization system that manages access to Azure resources based on roles.
Recovery Services Vault: Storage location for Azure Backup data with geo-redundant storage by default.
RPO (Recovery Point Objective): Maximum acceptable data loss measured in time (e.g., 5 minutes).
RTO (Recovery Time Objective): Maximum acceptable downtime measured in time (e.g., 2 hours).
SAS (Shared Access Signature): URI that grants restricted access to Azure Storage resources without exposing account keys.
Service Endpoint: Extends VNet identity to Azure services, keeping traffic on Microsoft backbone network.
SMB: Server Message Block protocol for Windows file shares (supports identity-based authentication).
Standard SSD: Balanced performance SSD storage for general-purpose workloads.
Uniform Orchestration: VM Scale Set mode where all VMs must be identical (legacy, use Flexible instead).
Update Domain: Group of VMs that are updated together during planned maintenance.
VNet (Virtual Network): Logically isolated network in Azure for secure communication between resources.
VNet Peering: Connects two VNets allowing resources to communicate using private IP addresses.
ZRS (Zone-Redundant Storage): Storage redundancy that maintains 3 copies across 3 availability zones (12 nines durability).
Microsoft Learn:
Practice Resources:
Community Resources:
Exam Details:
Renewal:
Next Steps After AZ-104:
✅ You've completed a comprehensive study guide
✅ You understand all five exam domains
✅ You've practiced with realistic questions
✅ You know the decision frameworks
✅ You're prepared for success
Good luck on your AZ-104 exam! You've got this! 🎯