AZ-104: Azure Administrator — Study Guide

Structured Summary + Deep-Dive for Exam & Architecture Clarity

Primary service

• Azure Resource Manager

Official documentation

• azure / azure resource manager / management / overview

1. Azure Cloud Fundamentals – The Hierarchy

Azure is built in logical layers. Understanding this hierarchy is foundational for every Azure exam and real-world architecture.

Level 1: Resources (Smallest Unit)

Resources are the building blocks of Azure.

Examples

• Virtual Machines
• Storage Accounts
• Virtual Networks
• Databases
• App Services

Each resource

• Belongs to one resource group
• Exists in one region
• Has a resource provider type
• Is managed through ARM

Think of resources as individual cloud components providing

• Compute
• Storage
• Networking
• Security
• Identity
• Application hosting

Level 2: Resource Groups (Logical Containers)

A Resource Group (RG) is a logical container for resources.

Characteristics

• Resources can only belong to one resource group

Resource groups help organize by

• Lifecycle
• Environment (Dev/Test/Prod)
• Department
• Application
• Security boundary

Important behaviors

• Deleting a resource group deletes ALL contained resources
• RBAC can be applied at RG level
• Tags can be applied at RG level

Docs

• azure / azure resource manager / management / manage resource groups portal

Level 3: Subscriptions (Billing + Governance Boundary)

A subscription is

• A billing boundary
• A management boundary
• A security boundary (RBAC scope)
• A quota boundary

Key facts

• Resource groups live inside subscriptions
• Resources are billed per subscription

Organizations often use multiple subscriptions for

• Departments
• Cost separation
• Compliance
• Environments

Docs

• azure / cost management billing / manage / create subscription

2. What is Azure Resource Manager (ARM)?

Azure Resource Manager is

• The deployment and management service for Azure
• The control plane of Azure
• The orchestration layer

ARM does NOT directly manipulate resources.

Instead

• Client (Portal/CLI/PowerShell)
• → ARM
• → Resource Provider
• → Resource

3. How ARM Works Internally

When you create or modify a resource

You send a request via

• Azure Portal
• Azure CLI
• Azure PowerShell
• REST API

The request goes to ARM.

ARM routes the request to the appropriate Resource Provider.

The Resource Provider performs the operation.

4. Resource Providers (Critical Exam Concept)

Resource Providers (RPs) are services that manage specific resource types.

Examples

• Microsoft.Compute -> Virtual Machines
• Microsoft.Storage -> Storage Accounts
• Microsoft.Network -> VNets
• Microsoft.Web -> App Services

Each resource type belongs to a provider namespace

Example

• Microsoft.Storage/storageAccounts

Docs

• azure / azure resource manager / management / resource providers and types

5. Control Plane vs Data Plane

This distinction is essential.

Control Plane (ARM)

Operations like

• Create VM
• Delete Storage Account
• Modify Networking
• Assign RBAC

Managed via ARM.

Data Plane

Operations like

• Upload Blob
• Read File
• Insert Table Entity

Handled directly by the service endpoint.

ARM governs control plane only.

6. Azure Identity & Trust Model

Azure uses identity-centric security.

Identity service

• Microsoft Entra ID

Docs

• entra / fundamentals / what is entra

Tenant

A tenant is

• An identity boundary
• A directory of users, groups, service principals

Important

• A subscription can trust only ONE tenant
• A tenant can manage multiple subscriptions

This is the trust relationship.

How Access Is Controlled

• User logs in -> Authenticated via Entra ID
• Entra issues token -> Token sent to ARM
• ARM validates RBAC -> Routes request

If no RBAC role assignment

Access denied.

7. ARM Deployment Model

ARM enables

• Declarative deployments
• Infrastructure as Code (IaC)
• Repeatable deployments

Supported via

• ARM Templates (JSON)
• Bicep
• Terraform (via ARM APIs)

Example ARM template defines

• Resource
• Properties
• Dependencies
• Parameters

Docs

• azure / azure resource manager / templates / overview

8. Benefits of ARM Model

Before ARM, Azure used "classic" deployment model.

ARM improvements

• Role-based access control
• Resource tagging
• Resource grouping
• Template-based deployment
• Consistent API layer
• Dependency management
• Idempotent deployments

Classic model is deprecated.

9. Management Scope Hierarchy

Azure management hierarchy

• Tenant
• → Management Groups
• → Subscriptions
• → Resource Groups
• → Resources

RBAC can be applied at any level.

Docs

• azure / governance / management groups / overview
• 🔟 Governance Capabilities via ARM

ARM integrates with

• Azure RBAC
• Azure Policy
• Azure Blueprints
• Tags
• Locks

These operate through ARM control plane.

1️⃣1️⃣ Security Model Summary

Security flow

• User
• → Auth via Entra
• → Token issued
• → ARM validates
• → Resource provider executes

No direct subscription access without tenant trust.

1️⃣2️⃣ Common Exam Pitfalls

• Resource groups are billing boundaries → False
• Subscriptions can trust multiple tenants → False
• ARM directly manages data plane → False
• Resource providers must be registered → True
• Tenant = subscription → False
• Deleting resource group deletes contained resources → True

1️⃣3️⃣ Real-World Architecture Example

Scenario

Company has

• Tenant A
• → 5 Subscriptions
• → Dev, Test, Prod resource groups

Each subscription

• Linked to same tenant
• RBAC enforced
• Separate billing

ARM ensures

• Policy enforcement
• Deployment standardization
• Controlled access
• 1️⃣4️⃣ Mental Model for Mastery

Think in layers

• Identity (Tenant)
• → Governance (Management Groups)
• → Billing (Subscriptions)
• → Organization (Resource Groups)
• → Services (Resources)
• → Orchestration (ARM)
• → Execution (Resource Providers)
• 1️⃣5️⃣ Final Key Takeaways
• Resources are smallest unit
• Resource Groups organize resources
• Subscriptions handle billing and governance
• ARM is the orchestration/control plane
• Resource Providers execute operations
• Tenant controls identity trust
• Subscription trusts only one tenant

Understanding ARM is foundational for

• AZ-104
• AZ-204
• AZ-305
• Enterprise architecture
• Governance design

Structured Summary + Deep Technical Understanding

Primary services covered

• Azure Portal
• Azure Cloud Shell

Official documentation

• Azure Portal: https://learn.microsoft.com/azure/azure-portal/azure-portal-overview
• Cloud Shell: https://learn.microsoft.com/azure/cloud-shell/overview

1. What is the Azure Portal?

The Azure Portal is

• A web-based graphical user interface (GUI)
• Accessible at: https://portal.azure.com
• Used to create, manage, monitor Azure resources
• Built on top of Azure Resource Manager (ARM)

It is a control-plane interface for Azure.

Anything you do in the portal

• Create VM
• Delete Storage Account
• Assign RBAC
• Configure networking
• → Sends REST API calls to Azure Resource Manager
• → ARM forwards request to the correct Resource Provider

(From previous lesson: Portal → ARM → Resource Provider → Resource)

2. Key Portal Components

Home Dashboard

Displays

• Recently used resources
• Favorites
• Quick-create templates
• Marketplace suggestions

You can customize dashboards for

• CPU usage
• Memory metrics
• Alerts
• Resource tiles

This provides a “single pane of glass” view of your environment.

Navigation Menu (Hamburger Menu)

Core options

• Create a resource
• Dashboard
• All services
• Favorites
• Resource groups
• Subscriptions

Search Bar (Highly Used Feature)

Search allows

• Find services
• Find specific resources
• Find documentation
• Access marketplace
• View search history

Important for speed in production environments.

3. Creating a Resource via Portal (Example: Virtual Machine)

Example resource

• Azure Virtual Machines

When creating a VM

You configure

• Resource Group (mandatory)
• Region
• Availability options
• OS image
• VM size
• Authentication
• Networking
• Disks
• Tags

Important concept

Deploying a VM automatically deploys dependent resources, such as

• Network Interface (Microsoft.Network)
• Public IP
• Virtual Network
• Disk
• NSG (optional)

These dependencies are deployed via ARM and respective Resource Providers.

Example providers

• Microsoft.Compute
• Microsoft.Network
• Microsoft.Storage

This demonstrates ARM orchestration in action.

4. Resource Type Namespaces (Exam-Relevant)

Every Azure resource has a type format

• Microsoft.ProviderName/resourceType

Examples

• Microsoft.Compute/virtualMachines
• Microsoft.Network/networkInterfaces
• Microsoft.Storage/storageAccounts

Understanding this helps in

• ARM templates
• RBAC
• Azure Policy
• Troubleshooting

5. Azure Cloud Shell Overview

Cloud Shell is

• A browser-based shell
• Pre-authenticated to your Azure account
• Runs inside Azure
• No local installation required

Supports

• Bash (Azure CLI)
• PowerShell (Az module)

6. Bash vs PowerShell in Cloud Shell

Bash

Uses

• Azure CLI (az commands)

Example

• az vm list

Best for

• Cross-platform scripting
• DevOps pipelines
• Linux-style automation

PowerShell

Uses

• Azure PowerShell (Az module)

Example

• Get-AzVM

Best for

• Windows admins
• PowerShell-native automation
• Advanced scripting logic

Switching shells restarts session.

7. Cloud Shell Storage Options

Two options

Persistent Storage (Recommended for real work)

Mounts a storage account

• Saves scripts
• Persists files
• Keeps configurations

Backed by

• Azure Files

No Storage Account

Ephemeral session

• No file persistence
• Temporary environment
• Good for quick tests

8. Cloud Shell Capabilities

• Upload / Download files
• Multiple sessions
• Built-in code editor
• Web preview (for apps running in shell)
• Settings customization
• Documentation help

Cloud Shell environment includes

• Azure CLI
• PowerShell Az module
• Git
• Terraform
• kubectl
• Helm
• Docker tools
• Python
• Node.js

It is essentially a preconfigured DevOps environment.

9. Portal vs Cloud Shell

| Feature | Azure Portal | Cloud Shell |

| --- | --- | --- |

| Interface | GUI | CLI |

| Ease of use | Very easy | Moderate |

| Automation | Limited | Powerful |

| Scriptable | No | Yes |

| Good for beginners | Yes | Intermediate+ |

| DevOps use | Minimal | High |

🔟 Control Plane Integration

Both Portal and Cloud Shell

• Use REST APIs
• Talk to Azure Resource Manager
• Operate in control plane

They do NOT directly manipulate data plane operations (e.g., blob uploads via service endpoint).

1️⃣1️⃣ Security Model

When using Portal or Cloud Shell

Authentication handled by

• Microsoft Entra ID

Process

User login → Token issued → Token sent to ARM → RBAC evaluated → Operation allowed or denied.

Cloud Shell inherits your Entra authentication session.

1️⃣2️⃣ Real-World Usage Scenarios

Portal is ideal for

• Learning Azure
• One-off deployments
• Monitoring
• Troubleshooting
• Visual configuration

Cloud Shell is ideal for

• Automation
• Bulk operations
• CI/CD tasks
• Infrastructure scripting
• Advanced management
• 1️⃣3️⃣ Common Exam Pitfalls
• Cloud Shell runs locally → False
• Cloud Shell requires installation → False
• Portal interacts directly with resources → False (via ARM)
• VM deployment only creates 1 resource → False
• Cloud Shell automatically persists files → Only if storage mounted
• 1️⃣4️⃣ Architecture Insight

When you click “Create VM” in portal

• Portal UI
• → REST API call
• → Azure Resource Manager
• → Microsoft.Compute
• → Microsoft.Network
• → Microsoft.Storage
• → Deployment orchestration
• → Resource provisioning

This demonstrates

ARM dependency management.

1️⃣5️⃣ Key Takeaways

• Azure Portal = GUI management interface
• Cloud Shell = CLI inside browser
• Both use ARM
• VM deployments create multiple dependent resources
• Resource types follow Microsoft.Provider/resourceType pattern
• Cloud Shell supports Bash and PowerShell
• Persistent storage optional but recommended

Understanding these tools is foundational for

• AZ-104
• AZ-204
• AZ-900
• DevOps engineering
• Azure governance

Structured Summary + Deep Understanding

Primary tools

• Azure CLI
• Azure PowerShell

Official documentation

• Azure CLI: https://learn.microsoft.com/cli/azure/
• Azure PowerShell: https://learn.microsoft.com/powershell/azure/

1. What is Azure CLI?

Azure CLI is

• A cross-platform command-line tool
• Used to manage Azure resources
• Bash-style syntax
• Script-friendly

✔ Available in

• Cloud Shell
• Windows
• macOS
• Linux

Core command structure

• az <service> <resource> <action>

Example

• az vm create

Azure CLI interacts with

• → Azure Resource Manager (control plane)

2. What is Azure PowerShell?

Azure PowerShell is

• A collection of PowerShell cmdlets (Az module)
• Object-oriented
• Built on .NET
• Used to manage Azure resources

Cmdlet naming pattern

• Verb-AzNoun

Example

• New-AzVM

Like CLI, it interacts with

• → Azure Resource Manager (control plane)

3. CLI vs PowerShell – Core Differences

| Feature | Azure CLI | Azure PowerShell |

| --- | --- | --- |

| Syntax | Bash-style | PowerShell cmdlets |

| Output | JSON (default) | Objects |

| Scripting | Shell scripts | PowerShell scripts |

| Best For | DevOps/Linux users | Windows admins |

| Learning Curve | Simpler | More powerful (object model) |

Both are equally capable.

Choice = Preference + Team ecosystem.

4. Demonstration Breakdown

Example scenario

Create a Virtual Network.

Resource example

• Azure Virtual Network

5. Azure CLI Workflow Explained

Step 1: List Resource Groups

az group list

Default output: JSON array.

Step 2: Filter Output Using --query

Azure CLI supports JMESPath queries.

Example

• az group list --query "[].name"

This extracts only the name field.

Step 3: Change Output Format

Default = JSON

Better for scripting = TSV (tab-separated value)

az group list --query "[].name" --output tsv

Why?

Removes brackets and quotes.

Step 4: Save to Variable

rgcli=$(az group list --query "[].name" --output tsv)

Use variable later

• echo $rgcli

Step 5: Create Virtual Network

az network vnet create \

• -name VNetCLI \
• -resource-group $rgcli \
• -address-prefix 10.0.0.0/16

Command pattern

• az network vnet create
• ProvisioningState: Succeeded

6. Azure PowerShell Workflow Explained

Step 1: Get Resource Group

Get-AzResourceGroup

Returns PowerShell objects (not JSON).

Step 2: Save to Variable

$rgps = Get-AzResourceGroup

PowerShell stores full object.

Step 3: Access Object Properties

$rgps.ResourceGroupName

$rgps.Location

Object model advantage

You can drill into properties directly.

Step 4: Create Virtual Network

New-AzVirtualNetwork `

• Name VNetPS `
• ResourceGroupName $rgps.ResourceGroupName `
• Location $rgps.Location `
• AddressPrefix 10.1.0.0/16

ProvisioningState: Succeeded

7. Key Architectural Concept

Both CLI and PowerShell

• User Command
• → REST API call
• → Azure Resource Manager
• → Resource Provider (Microsoft.Network)
• → Resource Created

They are simply different interfaces to ARM.

8. Object-Oriented Advantage (PowerShell)

PowerShell returns structured objects.

Example

• $vm = Get-AzVM
• $vm.HardwareProfile.VmSize

You can chain and pipe objects

• Get-AzVM | Where-Object {$_.Location -eq "eastus"}

This makes PowerShell powerful for complex logic.

9. JSON Advantage (CLI)

CLI returns JSON by default.

Best for

• DevOps pipelines
• Automation systems

Integration with tools like

• jq
• Terraform
• Ansible

Example

• az vm list --output table

Supports formats

• json
• jsonc
• table
• tsv
• yaml
• 🔟 When to Use Each

Use Azure CLI When:

• Working in Linux
• Writing CI/CD pipelines
• Using Bash
• Automating DevOps workflows

Use Azure PowerShell When:

• Using Windows ecosystem
• Need object manipulation
• Writing complex automation
• Managing enterprise scripts

1️⃣1️⃣ Cloud Shell Integration

In

• Azure Cloud Shell

You can

• Run Azure CLI (Bash)
• Run Azure PowerShell (PowerShell)

Switching shells restarts session.

Cloud Shell is pre-authenticated.

1️⃣2️⃣ Authentication Model

Both tools authenticate via

• Microsoft Entra ID

Process

• Login
• → Token issued
• → Token passed to ARM
• → RBAC enforced
• → Action executed
• 1️⃣3️⃣ Common Exam Pitfalls
• CLI and PowerShell manage data plane directly → False
• PowerShell returns JSON → False
• CLI cannot be scripted → False
• Both use ARM → True
• PowerShell is better than CLI → False (preference-based)
• 1️⃣4️⃣ Advanced Automation Insight

For production automation

• Use variables
• Use output formatting
• Validate provisioning state
• Handle errors
• Use idempotent scripts

Example

Check before creating

CLI

• az network vnet show --name VNetCLI

PowerShell

• Get-AzVirtualNetwork -Name VNetPS
• 1️⃣5️⃣ Mental Model
• Portal = GUI
• CLI = Scriptable Bash interface
• PowerShell = Scriptable object-oriented interface

All communicate with ARM.

1️⃣6️⃣ Final Takeaways

• Azure CLI = Bash-style, JSON-based
• Azure PowerShell = Object-oriented cmdlets
• Both automate Azure
• Both integrate with Cloud Shell
• Both use ARM
• Preference depends on ecosystem

These tools are foundational for

• AZ-104
• AZ-204
• DevOps roles
• Automation engineering
• Enterprise scripting

Structured Summary + Deep Technical Understanding

Primary service

• Azure Resource Manager

Official documentation

• azure / azure resource manager / templates / overview

1. What Are ARM Templates?

ARM Templates are

• JSON files
• Used for Infrastructure as Code (IaC)
• Declarative deployment model
• Processed by Azure Resource Manager

They define what your infrastructure should look like — not how to build it step-by-step.

High-Level Flow

ARM Template (JSON)

→ Submitted to Azure Resource Manager

→ ARM validates against schema

→ ARM identifies required Resource Providers

→ Resources deployed

Example resource types

• Microsoft.Compute/virtualMachines
• Microsoft.Network/virtualNetworks
• Microsoft.Storage/storageAccounts

2. Why Use ARM Templates?

Core Benefits

• Repeatable deployments
• Consistent environments
• Automation-ready
• Faster recovery
• Reduced manual errors
• Version-controlled infrastructure

Real-World Use Case

Hub-and-Spoke Network Topology

Instead of manually building

• VNets
• Subnets
• NSGs
• Route tables
• Peering
• You codify it once -> deploy everywhere.

Dev/Test/Prod can use same template.

3. Deployment Scopes

ARM Templates can deploy at

• Resource Group scope (most common)
• Subscription scope
• Management Group scope
• Tenant scope

Most basic examples use Resource Group scope.

Docs

• azure / azure resource manager / templates / deploy to resource group

4. ARM Template Structure (Critical for Exams)

An ARM template contains structured sections.

1. $schema (Mandatory)

Defines

• Template schema version
• Validation rules
• IntelliSense behavior

Example

"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#"

Important

• Date = schema version
• deploymentTemplate = resource group scope

2. contentVersion (Mandatory)

Example

• "contentVersion": "1.0.0.0"

Purpose

• Manual template versioning
• Rarely used heavily in real-world
• Git usually handles versioning

3. parameters (Optional but Powerful)

Used to

• Pass values at deployment time
• Make templates reusable
• Customize per environment

Example

• "parameters": {
• "environmentName": {
• "type": "string"
• }
• }

Use cases

• Dev -> dev-webapp
• Test -> test-webapp
• Prod -> prod-webapp

Same template, different inputs.

Parameter File Example

Separate file

• {
• "parameters": {
• "environmentName": {
• "value": "dev"
• }
• }
• }

Used in CI/CD pipelines.

5. Built-in vs User-Defined Functions

ARM supports

Built-in Functions

Examples

• resourceGroup()
• subscription()
• concat()
• parameters()
• variables()
• uniqueString()

Docs

• azure / azure resource manager / templates / template functions

User-Defined Functions (Optional Section)

Used when

• Complex logic needed
• Combining multiple built-in functions

Defined under

• "functions": []

Less common in basic deployments.

6. Variables Section

Variables

• Reusable values
• Reduce repetition
• Improve readability

Example

• "variables": {
• "location": "eastus"
• }

Or dynamic

• "variables": {
• "storageAccountName": "[concat('stor', uniqueString(resourceGroup().id))]"
• }

Variables improve

• Maintainability
• Template clarity

7. Resources Section (Core of Template)

This is the most important section.

Defines

• Resource type
• API version
• Name
• Location
• Properties
• Dependencies

Example

• "resources": [
• {
• "type": "Microsoft.Storage/storageAccounts",
• "apiVersion": "2022-09-01",
• "name": "[parameters('storageName')]",
• "location": "[resourceGroup().location]",
• "properties": {}
• }
• ]

Multiple resources can be deployed in one template.

Dependency Management

ARM automatically

• Detects dependencies
• Orders deployment

Or you can explicitly define

• "dependsOn": []

8. Outputs Section (Optional but Useful)

Used to

• Return values after deployment
• Feed values into pipelines
• Chain deployments

Example

• "outputs": {
• "storageAccountName": {
• "type": "string",
• "value": "[variables('storageAccountName')]"
• }
• }

Common in

• CI/CD
• Automation
• DevOps workflows

9. Deployment Modes

Two deployment modes

Incremental (Default)

Adds/updates resources defined in template

Does NOT delete unspecified resources

Complete

Deletes resources not defined in template

⚠ Complete mode can remove resources.

Docs

• azure / azure resource manager / templates / deployment modes
• 🔟 Declarative vs Imperative Model

ARM Templates are Declarative.

You define

Desired state.

ARM figures out

Execution order.

Unlike

• Azure CLI scripts -> Imperative (step-by-step).
• 1️⃣1️⃣ ARM vs Bicep
• ARM = JSON (verbose)
• Bicep = Simplified DSL that compiles to ARM

Modern best practice

Use Bicep instead of raw ARM.

Docs

• azure / azure resource manager / bicep / overview
• 1️⃣2️⃣ Common Exam Pitfalls
• ARM Templates are imperative → False
• Schema section is optional → False
• Parameters are mandatory → False
• Resources section optional → False
• Outputs required → False
• ARM Templates manage data plane → False
• 1️⃣3️⃣ Real-World Deployment Example

Scenario

Deploy

• VNet
• Subnets
• VM
• NSG
• Storage account

All defined in

Single ARM template.

Benefits

• One-click deployment
• Dev/Test/Prod reuse
• Disaster recovery ready
• Git-controlled infrastructure
• 1️⃣4️⃣ Infrastructure as Code (IaC) Philosophy

Advantages

• Version control
• Auditable changes
• CI/CD integration
• Reduced configuration drift
• Faster environment recreation
• 1️⃣5️⃣ Mental Model

Think of ARM template as

Blueprint of infrastructure.

You define

• Inputs (parameters)
• Internal logic (variables/functions)
• Resources
• Outputs

ARM enforces structure via schema.

1️⃣6️⃣ Final Key Takeaways

• ARM Templates = JSON Infrastructure as Code
• Declarative model
• Repeatable deployments
• Schema validates template
• Parameters enable reuse
• Resources define infrastructure
• Outputs enable automation
• Deployable at multiple scopes

ARM templates are foundational for

• AZ-104
• AZ-204
• AZ-305
• DevOps
• Cloud architecture

Structured Summary + Deep Technical Understanding

Primary service

• Azure Resource Manager

Official documentation

ARM templates overview: https://learn.microsoft.com/azure/azure-resource-manager/templates/overview

Deploy templates in portal: https://learn.microsoft.com/azure/azure-resource-manager/templates/deploy-portal

Quickstart templates: https://learn.microsoft.com/azure/azure-resource-manager/templates/template-samples

1. Core Concept: Everything in Azure Uses ARM Templates

Even when you deploy resources using

• Azure Portal
• Azure CLI
• Azure PowerShell

Behind the scenes

• An ARM template is generated
• Azure Resource Manager processes it
• Resource Providers deploy the resources

The portal is simply a GUI for generating ARM templates.

2. Exporting a Deployment as an ARM Template

During Deployment (Before Create)

When creating a resource (e.g., Web App)

• Go to Create Resource
• Fill configuration
• Go to Review + Create
• Select Download a template for automation

This shows

• The exact ARM template Azure will use
• Parameters and resource definitions
• Dependencies

This is extremely useful for

• Learning ARM structure
• Converting manual deployments to Infrastructure as Code
• Creating reusable templates

After Deployment (Existing Resources)

You can export ARM templates from completed deployments.

Steps

• Go to Resource Group
• Select Deployments
• Open a deployment
• Select Template

This shows the full template used for that deployment.

Important use case

• Reverse engineer existing infrastructure
• Standardize legacy environments
• Create reusable templates from production

3. Deploying a Custom ARM Template in Portal

You can manually deploy ARM templates from the portal.

Search for

• "Deploy a custom template"

This opens

• Template editor
• Quickstart templates
• Upload template option

4. Using Quickstart Templates

Azure provides public templates via

• Azure Quickstart Templates

Repository

• github.com / Azure / azure quickstart templates

Benefits

• Prebuilt production-ready templates
• Complex deployments (e.g., hub-spoke, AKS, multi-tier apps)
• Learning resource

5. Building an ARM Template Using Portal Editor

In the demonstration

• Start with blank template
• Add resource -> Virtual Network
• Add resource -> Virtual Machine
• Add resource -> Storage Account
• Link VM to existing VNet in template

The editor

• Automatically generates resource blocks
• Adds required variables
• Creates dependent resources (NIC, disk, etc.)
• Handles dependencies

This demonstrates

ARM handles dependency resolution automatically.

6. Example Resources Generated

When adding a VM, the template automatically included

• Virtual Network
• Network Interface
• Storage Account
• VM resource
• Variables for naming
• OS configuration parameters

This illustrates

Deploying one “simple” resource often creates multiple dependent resources.

7. Template Deployment Flow

After clicking Create

• Portal
• → ARM Template generated
• → Azure Resource Manager
• → Resource Providers
• → Deployment orchestrated
• ProvisioningState = Succeeded

8. Template Components Observed in Demo

The generated template contained

• $schema
• contentVersion
• parameters
• variables
• resources

Demonstrating real-world template structure.

9. Key Capabilities Demonstrated

• Export template before deployment
• Export template after deployment
• Use template editor
• Add multiple resources
• Link resources within template
• Deploy template via portal

🔟 Why This Is Important

ARM templates allow

• Standardized infrastructure
• Dev/Test/Prod parity
• Disaster recovery redeployment
• CI/CD automation
• Governance consistency
• 1️⃣1️⃣ Deployment Modes Reminder

ARM supports

• Incremental (default)
• Adds/updates defined resources
• Does not delete others
• Complete
• Removes resources not in template
• Use carefully

Docs

• azure / azure resource manager / templates / deployment modes
• 1️⃣2️⃣ ARM Templates in CI/CD

Common pipeline pattern

• Git repository
• → ARM template
• → Azure DevOps / GitHub Actions
• → ARM deployment task
• → Infrastructure provisioned

Outputs from template can feed into

• Subsequent pipeline steps
• Application deployments
• 1️⃣3️⃣ Real-World Example

Instead of manually creating

• VNet
• VM
• Storage account
• NIC
• NSG

You define them once in a template.

Then

• Deploy to Dev
• Deploy to Test
• Deploy to Prod

Same template, different parameter files.

1️⃣4️⃣ Common Exam Pitfalls

• ARM templates are only used in CLI → False
• Portal doesn’t use ARM → False
• Templates can’t be exported → False
• Templates only deploy one resource → False
• Dependencies must always be manually defined → Not always (ARM resolves automatically)

1️⃣5️⃣ Mental Model

Think of ARM templates as

Blueprints.

Portal = Blueprint generator

CLI = Blueprint executor

PowerShell = Blueprint executor

ARM = Construction manager

Resource Providers = Construction teams

1️⃣6️⃣ Final Key Takeaways

• Everything in Azure is ARM-driven
• Portal generates ARM templates behind the scenes
• You can export templates before and after deployment
• Templates allow repeatable infrastructure
• Multiple resources can be deployed together
• ARM resolves dependencies automatically
• Custom templates can be deployed directly from portal

ARM templates are foundational for

• AZ-104
• AZ-204
• AZ-305
• DevOps engineering
• Enterprise cloud architecture

Structured Summary + Deep Technical Understanding

Primary services involved

• Azure Bicep
• Azure Resource Manager
• Azure Cloud Shell

Official Documentation

• Bicep overview: https://learn.microsoft.com/azure/azure-resource-manager/bicep/overview

Bicep syntax reference: https://learn.microsoft.com/azure/azure-resource-manager/bicep/file

Deploy Bicep with PowerShell: https://learn.microsoft.com/azure/azure-resource-manager/bicep/deploy-powershell

Deploy Bicep with CLI: https://learn.microsoft.com/azure/azure-resource-manager/bicep/deploy-cli

1. What Is Azure Bicep?

Azure Bicep is

• A domain-specific language (DSL) for deploying Azure resources
• A cleaner alternative to ARM JSON templates
• An abstraction layer over ARM templates
• Infrastructure as Code (IaC)

It simplifies writing Azure deployments.

2. Why Bicep Was Created

Problem with ARM templates

• JSON is verbose
• Difficult to read
• Hard to maintain at scale
• Nested brackets and quotes become messy

Example reality

• ARM JSON = machine-friendly
• Bicep = human-friendly

Bicep dramatically reduces

• Boilerplate
• Syntax clutter
• Complexity

3. Bicep vs ARM – Architecture Flow

ARM Workflow

Write ARM template (JSON)

Deploy template

ARM processes request

Resource Providers deploy resources

Bicep Workflow

Write Bicep file

Bicep compiles to ARM template

ARM processes template

Resource Providers deploy resources

Important

• 🚨 Bicep does NOT replace ARM
• 🚨 Bicep compiles into ARM JSON
• 🚨 ARM is still the engine

4. Bicep File Structure (From Demo)

The sample Bicep file included

• param location string = resourceGroup().location
• param webAppName string
• resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {

...

}

resource webApp 'Microsoft.Web/sites@2022-03-01' = {

...

}

Key components observed

• Parameters
• Variables
• Resources
• Symbolic names
• Built-in functions

5. Understanding Key Bicep Concepts

Parameters

Used to pass values at deployment time.

Example

• param location string = resourceGroup().location

Meaning

• Type = string
• Default = resource group location
• Uses built-in ARM function

If no default is provided

Deployment will prompt user.

Built-in Functions

Example used

• resourceGroup().location

This retrieves

• The location of the resource group
• Makes template portable across regions

Docs

• azure / azure resource manager / bicep / bicep functions resource

Symbolic Names (Very Important)

Example

resource appServicePlan ...

appServicePlan is NOT the deployed name.

It is

• A symbolic reference inside the template
• Used for linking resources

Example reference

• serverFarmId: appServicePlan.id

This means

Take the ID of that resource after deployment and assign it here.

This is how dependencies are managed cleanly in Bicep.

6. Quotation Rules Explained

In the demo

• name: webAppName
• location: location

No quotes because

• They reference parameters/variables

But

• name: 'HardCodedName'

Uses quotes because it's a literal string.

7. Handling Global Uniqueness (Web App Name Error)

Web App names must be globally unique.

Initial issue

Hardcoded

• name: 'AwesomeApp'

Error occurred

Website with given name already exists.

Solution

Create parameter

• param webAppName string

Now deployment prompts for unique name.

This makes template

• Reusable
• Environment-independent
• Production-ready

8. Deploying Bicep with PowerShell

Used in demo

• New-AzResourceGroupDeployment `
• ResourceGroupName $rg.ResourceGroupName `
• TemplateFile deploy.bicep

Deployment flow

• Bicep file
• → Compiled to ARM JSON
• → Sent to Azure Resource Manager
• → Resources deployed

9. Verifying Compilation

After deployment

• Resource Group
• → Deployments
• → Select deployment
• → Template

You see

• ARM JSON template

This confirms

• Bicep compiled into ARM
• ARM executed the deployment
• 🔟 Advantages of Azure Bicep
• | Feature | Benefit |
• | --- | --- |
• | Cleaner syntax | Easier to read |
• | Native Azure support | No external engine |
• | Symbolic names | Automatic dependency handling |
• | Modular design | Reusable components |
• | Built-in functions | Dynamic values |

| Full ARM parity | Can do everything ARM can |

1️⃣1️⃣ Advanced Capabilities (Beyond Demo)

Bicep also supports

• Modules (reusable template blocks)
• Loops (for deploying multiple resources)
• Conditions (deploy only if true)
• Existing resource references
• Secure parameters

Example loop

resource storageAccounts 'Microsoft.Storage/storageAccounts@2022-09-01' = [for i in range(0,3): {

name: 'storage${i}'

...

}]

1️⃣2️⃣ Where Bicep Fits in DevOps

Typical workflow

• Git Repository
• → Bicep files
• → CI/CD pipeline
• → Bicep compiled
• → ARM deployment
• → Azure infrastructure

Common tools

• Azure DevOps
• GitHub Actions
• Azure CLI
• PowerShell
• 1️⃣3️⃣ Exam-Relevant Points
• Bicep is GA (Generally Available)
• Bicep compiles to ARM JSON
• ARM remains underlying engine
• Symbolic names manage dependencies
• Parameters improve reusability
• Bicep supports same scopes as ARM (resource group, subscription, etc.)
• 1️⃣4️⃣ Bicep vs ARM Quick Comparison
• | ARM JSON | Bicep |
• | --- | --- |
• | Verbose | Concise |
• | Complex nesting | Clean structure |
• | Harder to maintain | Easier to refactor |
• | JSON syntax | Declarative DSL |
• | Native engine | Compiles to ARM |
• 1️⃣5️⃣ Mental Model

Think of Bicep as

• High-level language (like C#)
• ARM JSON as compiled IL
• Azure Resource Manager as runtime engine
• You write Bicep -> Azure runs ARM.
• 1️⃣6️⃣ Final Key Takeaways
• Azure Bicep simplifies ARM template authoring
• It is NOT a replacement engine
• It compiles into ARM templates
• Symbolic names enable clean resource linking
• Parameters enable reusable deployments
• Default values improve portability
• All Azure deployments ultimately use ARM

Structured Summary + Deep Technical Understanding

Primary technologies involved

• Azure Bicep
• Azure Resource Manager
• Azure Cloud Shell

Official Documentation

Bicep CLI reference: https://learn.microsoft.com/azure/azure-resource-manager/bicep/bicep-cli

Decompile ARM to Bicep: https://learn.microsoft.com/azure/azure-resource-manager/bicep/decompile

Deploy Bicep with Azure CLI: https://learn.microsoft.com/azure/azure-resource-manager/bicep/deploy-cli

Deploy Bicep with PowerShell: https://learn.microsoft.com/azure/azure-resource-manager/bicep/deploy-powershell

1. Big Picture: Why Migrate from ARM to Bicep?

We already know

• ARM JSON
• → Talks to Azure Resource Manager
• → Talks to Resource Providers
• → Deploys resources

Bicep is

• A higher-level language
• Easier to read and write
• Fully compatible with ARM
• Automatically compiled into ARM JSON

So migration = converting existing ARM templates into cleaner Bicep files.

2. Key Tool: Azure Bicep CLI

Inside Cloud Shell (Bash)

• az bicep help

Important commands

• | Command | Purpose |
• | --- | --- |
• | build | Convert Bicep -> ARM JSON |
• | decompile | Convert ARM JSON -> Bicep |

These two commands enable full round-trip conversion.

3. Bicep → ARM (Build Command)

Command used

• az bicep build --file deploy.bicep --outfile test.json

What happens

• deploy.bicep
• → Compiled
• → test.json (ARM template generated)

This JSON file is exactly what Azure uses during deployment.

Important

• This happens automatically during normal Bicep deployment
• You can run it manually for inspection/debugging

4. Inspecting the Generated ARM Template

The generated JSON includes

• $schema
• contentVersion
• parameters
• variables
• resources

Example components seen

• Location parameter with default
• WebAppName parameter
• SKU variable
• LinuxFxVersion variable
• Microsoft.Web/serverfarms resource
• Microsoft.Web/sites resource

This confirms

Bicep preserves full ARM template structure.

5. ARM → Bicep (Decompile Command)

Command used

• az bicep decompile --file test.json

Output

• test.bicep

Important warning displayed

• ⚠ "Best effort decompilation"

Meaning

• Complex templates may not convert perfectly
• Manual cleanup/refactoring may be needed
• Especially true for advanced nested templates

Docs explicitly state decompilation is not guaranteed to be 100% clean.

6. Why Decompilation Might Need Refactoring

Possible issues in complex templates

• Nested deployments
• Linked templates
• Copy loops
• Advanced conditions
• Expressions rewritten awkwardly
• Redundant variables

After decompile

• Always review file
• Simplify expressions
• Replace hardcoded values with parameters
• Improve readability

7. Full Migration Workflow (From Demo)

Step 1 — Start with Bicep

• Step 2 — Build -> JSON
• Step 3 — Decompile JSON -> Bicep

Step 4 — Deploy new Bicep file

Deployment command used

• az deployment group create \
• -name DemoDeployment \
• -resource-group $rgName \
• -template-file test.bicep

This proves

• Decompilation result is fully deployable
• Round-trip conversion works

8. Verifying Deployment

Command used

• az resource list --resource-group $rgName --output table

Result showed

• App Service Plan
• Web App
• Cloud Shell storage account

Deployment state

• ProvisioningState = Succeeded

9. What This Demonstrates Architecturally

Bicep is NOT a separate deployment engine.

It always becomes

• Bicep
• → ARM JSON
• → Azure Resource Manager
• → Resource Providers
• → Resources

Even decompiled Bicep will go through ARM when deployed.

🔟 When Should You Migrate?

You should migrate ARM to Bicep if

• Templates are large and hard to maintain
• Teams struggle with JSON readability
• You want modular architecture
• You want easier parameter management
• You want better developer experience
• 1️⃣1️⃣ Enterprise Migration Strategy

Real-world approach

• Export existing ARM templates
• Decompile to Bicep

Refactor Bicep

• Extract modules
• Simplify parameters
• Improve naming
• Store in Git
• Integrate into CI/CD
• Retire legacy ARM JSON
• 1️⃣2️⃣ Advanced Migration Tips
• Use Modules

Break large templates into reusable modules

• module webApp './webapp.bicep' = {
• name: 'webAppDeployment'
• params: {

...

}

}

• Replace Hardcoded Values

Convert

• name: 'mywebapp'

Into

• param webAppName string
• name: webAppName
• Use Secure Parameters
• @secure()
• param adminPassword string
• 1️⃣3️⃣ Migration Caveats
• | Scenario | Risk |
• | --- | --- |
• | Linked templates | May require manual restructuring |
• | Copy loops | Might not convert cleanly |
• | Nested deployments | Often need cleanup |
• | Old API versions | Should be upgraded |

Always test in dev before production rollout.

1️⃣4️⃣ Bicep CLI Build vs Deploy

Important distinction

• Build
• Only compiles Bicep -> JSON
• No resources deployed
• Deploy
• Compiles AND deploys

Example deploy via CLI

• az deployment group create \
• -resource-group myRG \
• -template-file main.bicep

No need to manually build first.

1️⃣5️⃣ Mental Model

Think of migration like this

• ARM JSON = Assembly language
• Bicep = C#
• Decompile = reverse-engineering assembly back into C#

It works, but it may need cleanup.

1️⃣6️⃣ Key Exam Points

• Bicep build converts to ARM JSON
• Bicep decompile converts JSON to Bicep
• Decompile is best-effort only
• Bicep fully supports all ARM features
• Deployment scopes include resource group, subscription, management group
• Underlying engine is always Azure Resource Manager

1️⃣7️⃣ Final Takeaways

• Migrating to Bicep improves maintainability
• Bicep is production-ready (GA)
• ARM knowledge is still required
• Decompile helps accelerate migration
• Always review converted templates
• Round-trip conversion works
• Azure still deploys using ARM internally

Exam Tips: Azure Administration

Structured Summary + Deep Understanding for Exam Readiness

Primary services covered

• Azure Resource Manager
• Azure Portal
• Azure Cloud Shell
• Azure CLI
• Azure PowerShell
• Azure Bicep
• Microsoft Entra ID

Official documentation

• ARM overview: https://learn.microsoft.com/azure/azure-resource-manager/management/overview

Azure Portal overview: https://learn.microsoft.com/azure/azure-portal/azure-portal-overview

Azure CLI: https://learn.microsoft.com/cli/azure/

Azure PowerShell: https://learn.microsoft.com/powershell/azure/

ARM templates: https://learn.microsoft.com/azure/azure-resource-manager/templates/overview

Bicep overview: https://learn.microsoft.com/azure/azure-resource-manager/bicep/overview

1. Azure Core Hierarchy (Critical for Exams)

Understand this structure clearly

• Resources -> Resource Groups → Subscriptions

Resources

Examples

• Virtual Machines
• Storage Accounts
• Virtual Networks

They are

• Azure-managed services
• The smallest deployable unit
• Always deployed into a resource group

Resource Groups

Logical container for resources

Used for lifecycle management

Used for access control (RBAC scope)

Used for grouping by environment (Dev/Test/Prod)

Important

Resources cannot exist outside a resource group.

Subscriptions

Contain resource groups

Act as billing boundary

Used for cost management

Provide quota limits

Exam trap

A subscription can have many resource groups.

A resource group cannot span subscriptions.

2. Azure Resource Manager (ARM) Architecture

All management operations flow through

• Azure Resource Manager

How it works

• User sends request (Portal / CLI / PowerShell)
• Request hits ARM REST API
• ARM forwards to Resource Provider
• Resource Provider performs action

Example

• Creating a VM -> ARM → Microsoft.Compute → VM deployed

Key Exam Concept

• ARM is the control plane
• Resource Providers handle resource-specific logic

3. Authentication & Identity

Authentication uses

• Microsoft Entra ID

When you log into

• Azure Portal
• Cloud Shell
• CLI
• PowerShell

You authenticate with Entra ID.

Important

• Subscription trusts ONE tenant
• Tenant can manage multiple subscriptions
• Access control enforced via RBAC

4. Azure Portal vs Cloud Shell

Azure Portal

Azure Portal

Web-based GUI

Uses ARM under the hood

Automatically generates ARM templates

Good for manual deployments

Azure Cloud Shell

Azure Cloud Shell

Built-in terminal in portal

Supports

• Bash (Azure CLI)
• PowerShell (Az module)
• Pre-authenticated using Entra ID
• No local installation needed

Exam tip

Cloud Shell already has Azure CLI and PowerShell installed.

5. Azure CLI vs Azure PowerShell

Azure CLI

Azure CLI

Bash-style syntax

Cross-platform

Uses az commands

Outputs JSON by default

Great for automation

Example

• az vm create

Azure PowerShell

Azure PowerShell

Uses Az module

Object-oriented

Strong integration with PowerShell scripting

Better for Windows admins

Example

• New-AzVM

Exam tip

Both use ARM under the hood.

Difference = syntax + scripting model.

6. ARM Templates – Exam Essentials

Mandatory properties

• | Property | Purpose |
• | --- | --- |
• | $schema | Defines template rules |
• | contentVersion | Template version |
• | resources | What gets deployed |

Optional properties

• | Property | Purpose |
• | --- | --- |
• | parameters | Input values |
• | variables | Store reusable values |
• | outputs | Return deployment values |
• | functions | Create custom logic |

Important exam point

ARM templates are JSON-based Infrastructure as Code.

7. QuickStart Templates

Azure provides ready-made templates via

• Azure QuickStart Templates (GitHub repository)

Used for

• Learning
• Complex deployments
• Production reference designs

8. Azure Bicep – Simplified IaC

Azure Bicep

Key facts

• Declarative DSL
• Easier than ARM JSON
• Compiles to ARM
• Fully supported (GA)
• Same capabilities as ARM

Workflow

• Bicep
• → Compiled to ARM JSON
• → ARM executes deployment

Exam trap

Bicep does NOT replace ARM.

ARM remains the deployment engine.

9. Migrating ARM to Bicep

Conversion methods

• az bicep build (Bicep → JSON)
• az bicep decompile (JSON → Bicep)

Important

Decompile is best-effort.

Manual refactoring may be required.

🔟 Automation & Scripting

Azure administration can be done without Portal

• Azure CLI locally
• Azure PowerShell locally
• CI/CD pipelines
• ARM templates
• Bicep templates

Portal is optional. ARM is mandatory.

1️⃣1️⃣ Exam-Focused Mental Models

Think in Layers

User

→ REST API

→ Azure Resource Manager

→ Resource Provider

→ Resource

Think in Scopes

Management Group

→ Subscription

→ Resource Group

→ Resource

Think in Deployment Models

Manual (Portal)

Scripted (CLI / PowerShell)

Declarative (ARM / Bicep)

1️⃣2️⃣ High-Probability Exam Questions

Expect scenarios like

• Where does billing occur? (Subscription)
• What manages resources? (Azure Resource Manager)
• What authenticates users? (Microsoft Entra ID)
• What converts Bicep to JSON? (Bicep compiler)
• Can Bicep deploy without ARM? (No)
• Can resources exist outside a resource group? (No)
• What tool supports scripting automation? (CLI & PowerShell)
• 1️⃣3️⃣ Final Takeaways
• Resources live inside Resource Groups
• Resource Groups live inside Subscriptions
• ARM manages all Azure deployments
• Authentication uses Entra ID
• Portal, CLI, PowerShell all call ARM
• ARM templates are JSON-based IaC
• Bicep simplifies ARM authoring
• Bicep compiles to ARM
• Decompile helps migrate ARM → Bicep
• Automation is key for real-world Azure administration

Structured Summary + Deep Understanding for Exam & Real-World Azure Administration

Primary services involved

• Azure Subscription
• Azure Portal
• Azure Resource Manager
• Microsoft Entra ID

Official documentation

Subscriptions overview: https://learn.microsoft.com/azure/cost-management-billing/manage/subscriptions

Azure subscription limits & quotas: https://learn.microsoft.com/azure/azure-resource-manager/management/azure-subscription-service-limits

Cost Management overview: https://learn.microsoft.com/azure/cost-management-billing/cost-management-billing-overview

Enterprise Agreement: https://learn.microsoft.com/azure/cost-management-billing/manage/ea-overview

1. What Is an Azure Subscription?

An Azure subscription is

• A billing boundary
• A governance boundary
• A quota boundary
• A deployment scope boundary

It contains

• Resource Groups
• Resources (VMs, VNets, Storage, etc.)

Important

Resource Groups cost nothing.

Resources may incur costs.

Costs accumulate at the subscription level.

2. Subscription Hierarchy (Exam Critical)

Azure hierarchy

• Tenant (Entra ID)
• → Subscription
• → Resource Group
• → Resource

Tenant

Managed by

• Microsoft Entra ID
• Holds identities (users, groups, service principals)
• A subscription trusts ONE tenant
• A tenant can manage multiple subscriptions

3. Why Use Multiple Subscriptions?

Subscriptions help with

• Billing Segmentation

Example

• Marketing subscription
• Engineering subscription

Each team sees its own cost breakdown.

• Environment Isolation

Common pattern

• Prod subscription
• Dev subscription
• Staging subscription

Benefits

• Billing isolation
• RBAC isolation
• Policy isolation
• Risk containment
• Compliance & Governance

Subscriptions allow

• Separate Azure Policy enforcement
• Separate RBAC assignments
• Separate regulatory zones
• Regional Segmentation

Example

• US subscription
• Europe subscription

Used for

• Regulatory compliance
• Business segmentation
• Cost allocation

4. Subscription Offers (Billing Models)

Common subscription types

Pay-As-You-Go

Pay monthly based on usage

Most common model

Enterprise Agreement (EA)

Large organizations

Commit annual spend upfront

Discounted pricing

Free Trial

Limited credits

Time-limited

For learning/testing

Azure for Students

Free credits

No credit card required

Cloud Solution Provider (CSP)

Partner-managed subscription

• Partner designs & manages solution
• Billing through partner

Docs

• azure / cost management billing / manage / subscription offers

5. Subscription as Governance Scope

Subscriptions define scope for

• RBAC role assignments
• Azure Policy
• ARM/Bicep deployments
• Resource limits
• Budgets & alerts

Deployment scope example

• az deployment sub create

This deploys at subscription level.

6. Managing Subscriptions in Azure Portal

In

• Azure Portal

Navigate to

• Subscriptions -> Select subscription

You can manage

• Billing summary
• Cost analysis
• Budgets
• Alerts
• Resource usage
• Partner information

7. Cost Management Capabilities

Under subscription

• Cost Analysis
• Historical spending
• Resource breakdown
• Filtering by resource group
• Budgets

Set threshold alerts

• Email notifications
• Automation triggers
• Cost Alerts
• Prevent unexpected overspend

8. Quotas & Limits (Very Important for Exams)

Cloud is NOT unlimited.

Each subscription has

• Compute limits
• Networking limits
• Storage limits
• Regional quotas

Example

• vCPU quota per region
• Public IP limit
• NSG rule limit

Docs

• azure / azure resource manager / management / azure subscription service limits

Many quotas are adjustable.

You can request increases.

Exam trap

Subscription limits ≠ Azure global limits.

9. Subscription Naming Strategies

Common enterprise naming patterns

• Environment-Based
• Contoso-Prod
• Contoso-Dev
• Contoso-Test
• Department-Based
• Contoso-Marketing
• Contoso-Engineering
• Region-Based
• Contoso-US
• Contoso-EU
• Hybrid Naming
• Contoso-Prod-US
• Contoso-Dev-EU

Purpose

• Governance clarity
• Billing clarity
• Compliance separation
• 🔟 Subscription vs Resource Group (Common Confusion)
• | Feature | Subscription | Resource Group |
• | --- | --- | --- |
• | Billing boundary | Yes | No |
• | Governance boundary | Yes | Yes |
• | Can contain resource groups | Yes | No |
• | Can span subscriptions | No | No |

| Can move resources across? | No (must move RG) | Yes (within subscription) |

Important

Resources cannot exist outside a subscription.

1️⃣1️⃣ Security & Roles at Subscription Level

Roles can be assigned at

• Subscription scope
• Resource group scope
• Resource scope

Example

Billing admin for Marketing subscription only.

Identity relationship

• Tenant
• → Grants roles
• → On subscription
• 1️⃣2️⃣ Real-World Enterprise Design Pattern

Large enterprise might use

• Management Group
• → Corp
• → Prod Subscriptions
• → Dev Subscriptions
• → Department Subscriptions

This allows

• Policy inheritance
• Cost roll-up
• Central governance
• 1️⃣3️⃣ High-Probability Exam Topics

Expect questions on

• What defines billing boundary? (Subscription)
• Where are quotas enforced? (Subscription)
• Can one tenant manage multiple subscriptions? (Yes)
• Can one subscription trust multiple tenants? (No)
• Do resource groups incur cost? (No)
• Where do you set budgets? (Subscription level)
• Can quotas be increased? (Yes, request increase)
• 1️⃣4️⃣ Mental Model for Exams

Think of subscription as

• 💰 Billing wallet
• 🛡 Governance boundary
• 📦 Container of resource groups
• ⚖ Quota enforcer
• 1️⃣5️⃣ Final Key Takeaways
• Subscription = billing + governance + quota boundary
• Subscriptions belong to ONE Entra ID tenant
• Tenant can manage multiple subscriptions
• Multiple subscription offers exist (EA, Pay-As-You-Go, CSP, etc.)
• Subscriptions support budgets and cost tracking
• Quotas limit resource creation
• Subscription segmentation improves governance
• Subscription is deployment scope for ARM & Bicep

Understanding Azure Storage Accounts – Structured Summary + Deep Dive

Primary service

• Azure Storage Account

A Storage Account is the top-level storage container resource in Azure.

All Azure storage services live inside a storage account.

Think of it as

The control plane container for multiple storage services.

1. Storage Account = Multi-Service Platform

A single storage account can host multiple subservices

• | Subservice | Purpose | Typical Use Case |
• | --- | --- | --- |

| Blob | Object storage | Media files, backups, logs |

| Files | Managed SMB/NFS file shares | Lift-and-shift apps |

| Queues | Message storage | Microservices messaging |

| Tables | NoSQL key-value store | Lightweight structured data |

📦 Azure Blob Storage

Azure Blob Storage

Object storage service.

Used for

• Images
• Videos (MP4)
• Audio (MP3)
• Logs
• Backups
• Data lake storage
• VHD files

Types

• Block blobs
• Page blobs
• Append blobs

Docs

• azure / storage / blobs / storage blobs introduction
• 📁 Azure Files
• Azure Files

Managed file shares in the cloud.

Protocols

• SMB
• NFS

Benefits

• Fully managed
• Highly available
• No on-prem file server management

Docs

• azure / storage / files / storage files introduction
• 📨 Azure Queue Storage
• Azure Queue Storage

Message-based storage system.

Common in

• Microservices architectures
• Decoupled systems
• Event-driven apps

Pattern

• Publisher -> Queue → Consumer

Docs

• azure / storage / queues / storage queues introduction
• 🗄 Azure Table Storage
• Azure Table Storage

NoSQL key-value store.

Used for

• Semi-structured data
• Lightweight structured storage
• Fast lookup workloads

Docs

• azure / storage / tables / table storage overview

2. Storage Account Endpoint Structure

Each subservice has its own endpoint

• <storageaccount>.blob.core.windows.net
• <storageaccount>.file.core.windows.net
• <storageaccount>.queue.core.windows.net
• <storageaccount>.table.core.windows.net

Pattern

• <account-name>.<service>.core.windows.net

Storage account name

• Globally unique
• 3–24 characters
• Lowercase letters and numbers only

3. Storage Account Configuration Components

When creating a storage account, you choose

1. Account Type

Most common

• General Purpose v2 (GPv2)

Other types

• BlobStorage (legacy)
• Premium (low latency)

Docs

• azure / storage / common / storage account overview

2. Performance Tier

| Tier | Description |

| --- | --- |

| Standard | HDD-backed (most workloads) |

| Premium | SSD-backed (high IOPS, low latency) |

Premium options

• Premium Blob
• Premium Files
• Premium Page blobs

3. Replication (Redundancy)

This is a CRITICAL exam concept.

Azure global structure

• Geography -> Region → Availability Zones → Datacenters

Storage redundancy determines

Where your copies live.

🟢 LRS – Locally Redundant Storage

3 copies in

• Single availability zone
• Single region
• If zone fails -> data lost

Lowest cost option.

🟡 ZRS – Zone-Redundant Storage

3 copies across

• Multiple availability zones
• Same region

Protects against zone failure.

🔵 GRS – Geo-Redundant Storage

3 copies in

• Primary region

3 copies in

• Secondary region

Asynchronous replication.

Protects against regional failure.

🟣 GZRS – Geo-Zone-Redundant Storage

3 copies across zones in

• Primary region

3 copies in

• Secondary region

Highest durability without read access.

🔴 RA-GZRS – Read Access Geo-Zone Redundant Storage

Same as GZRS

Read access to secondary region.

Used for

• Global read scaling
• Disaster recovery readiness

Docs

• azure / storage / common / storage redundancy

4. Access Tier (Blob Storage Only)

Applies to

Blob storage only.

Options

• | Tier | Use Case | Cost |
• | --- | --- | --- |

| Hot | Frequent access | Higher storage, lower access |

| Cool | Infrequent access | Lower storage, higher access |

| Archive | Rare access | Lowest storage, highest retrieval |

Important

Archive tier

• Requires rehydration
• Can take hours to restore

Docs

• azure / storage / blobs / access tiers overview

5. Storage Account Security Features

Access Keys

Each storage account provides

• 2 access keys
• Root-level access

Best practice

Use Azure AD authentication instead of keys when possible.

🔒 Encryption

Data encrypted at rest by default

Uses Microsoft-managed keys

Can use customer-managed keys (CMK)

Docs

• azure / storage / common / storage service encryption
• 🌐 Networking

Options

• Public endpoint
• Private endpoint
• Firewall rules
• VNet service endpoints

6. Data Protection Options

Optional features

• Soft delete (blobs, containers)
• Versioning
• Point-in-time restore
• Immutable storage (WORM)

Docs

• azure / storage / blobs / data protection overview

7. Storage Account Architecture View

Inside portal after deployment

• Essentials
• Performance
• Replication
• Account kind
• Data storage
• Containers (Blob)
• File shares
• Queues
• Tables
• Security + networking
• Access keys
• Networking
• Encryption
• Settings
• Endpoints
• Configuration
• Tags

8. High-Level Design Considerations

When designing storage

• Required durability level
• Cost sensitivity
• Read scalability needs
• Disaster recovery requirements
• Access frequency
• Performance needs
• Security model

9. Durability Comparison (Important for Exams)

| Option | Region Protection | Zone Protection | Secondary Read |

| --- | --- | --- | --- |

| LRS | ❌ | ❌ | ❌ |

| ZRS | ❌ | ✅ | ❌ |

| GRS | ✅ | ❌ | ❌ |

| GZRS | ✅ | ✅ | ❌ |

| RA-GZRS | ✅ | ✅ | ✅ |

🔟 Common Exam Pitfalls

• Storage account name not globally unique → deployment fails
• Archive tier supports instant access → False
• ZRS protects against region failure → False
• LRS stores only 1 copy → False (stores 3)
• GRS provides automatic failover → False (manual failover unless configured)
• Access tier applies to all storage types → False (Blob only)

11. Real-World Architecture Patterns

Web App + Blob Storage

Static content stored in blob.

Microservices + Queue

Decoupled messaging.

Lift-and-Shift File Server

Azure Files replaces on-prem server.

Big Data

Blob Storage + Data Lake.

12. Conceptual Model

Think of storage account as

• Control layer
• ↓
• Replication engine
• ↓
• Performance tier
• ↓
• Subservices
• ↓
• Access endpoints

13. Storage Creation Flow (Portal Summary)

Choose resource group

Enter globally unique name

Select region

Choose performance (Standard/Premium)

Select replication (LRS/ZRS/GRS/GZRS/RA-GZRS)

Choose default access tier (Hot/Cool)

Configure networking

Configure data protection

Review and deploy

14. Summary in One Sentence

A storage account is a globally unique, highly durable, configurable storage platform that hosts multiple storage services and allows you to choose performance, redundancy, and cost characteristics at deployment time.

Conceptualizing Azure Blob Storage – Structured Summary + Deep Dive

Primary service

• Azure Blob Storage

Azure Blob Storage is an object-based storage service that lives inside an Azure Storage Account.

1. What Is Azure Blob Storage?

Blob Storage is

• A subservice of a Storage Account
• Object-based storage (not traditional file system)

Accessible over

• HTTP / HTTPS
• REST APIs
• SDKs

Think of it as

A massively scalable object store for unstructured data.

Official docs

• azure / storage / blobs / storage blobs introduction

2. Blob Storage Architecture

Blob Storage has 3 main components

• Storage Account
• └── Blob Service
• └── Containers
• └── Blobs

Storage Account

Top-level resource.

Controls

• Performance tier
• Replication
• Networking
• Security
• Default access tier

Blob Service

The object storage engine inside the storage account.

Containers

Logical grouping of blobs.

Equivalent to

• “Bucket” (AWS S3 conceptually)

Access control can be applied at container level.

Blobs

The actual stored data objects.

Examples

• Images
• Videos
• Text files
• Logs
• Backups
• VHD files

3. Flat Namespace (Important Concept)

Blob Storage is

• ❌ NOT a true hierarchical file system
• A flat object store

Folders are

• Virtual
• Just prefixes in the blob name

Example

• images/2026/photo1.jpg

Internally

This is just a blob name with prefix.

4. Types of Blobs

Azure supports 3 blob types

• 🟦 Block Blobs

Most common.

Used for

• Images
• Videos
• Documents
• Backups
• Data lake workloads

Optimized for

• Streaming
• Upload/download
• 🟨 Append Blobs

Optimized for

• Logging
• Append-only operations

Used in

• Diagnostics logs
• Audit trails
• 🟪 Page Blobs

Used for

• Random read/write workloads
• Virtual machine disks (VHD files)

Docs

• azure / storage / blobs / storage blobs overview

5. Access Tiers (Cost Optimization)

Blob storage supports multiple access tiers.

Critical for exam + cost optimization.

| Tier | Storage Cost | Access Cost | Minimum Retention |

| --- | --- | --- | --- |

| Hot | High | Low | None |

| Cool | Lower | Higher | 30 days |

| Cold | Even Lower | Higher | 90 days |

| Archive | Lowest | Highest | 180 days |

Hot Tier

Frequently accessed data

Default for most accounts

❄ Cool Tier

Infrequent access

Minimum 30-day retention

🧊 Cold Tier

Rarely accessed

Minimum 90-day retention

📦 Archive Tier

Rarely accessed long-term storage

Requires rehydration

Retrieval can take hours

Important

Archive tier is offline storage.

Docs

• azure / storage / blobs / access tiers overview

6. Storage Tier Cost Logic

Cost trade-off

Storage cost

• Hot -> High
• Archive -> Lowest

Access cost

• Hot -> Low
• Archive -> Highest

You optimize based on

Frequency of access.

7. Blob Versioning

Blob Versioning protects against

• Accidental overwrite
• Accidental deletion
• Regulatory compliance requirements

When enabled

• Every write operation creates a new version
• Each version gets a unique Version ID
• Only one current version exists
• Old versions remain stored

Important behavior

Promoting an old version

• Creates a new copy
• Does NOT revert in place

This increases storage usage.

Docs

• azure / storage / blobs / versioning overview

8. Lifecycle Management

Because versioning increases cost

You can configure lifecycle policies to

• Delete older versions after X days
• Move blobs between tiers automatically
• Archive old data

Docs

• azure / storage / blobs / lifecycle management overview

9. Upload Configuration Options (Portal)

When uploading blobs, you can configure

• Blob type (Block / Page / Append)
• Access tier
• Encryption
• Metadata
• Tags
• Retention policies

Important

Default tier comes from storage account settings.

🔟 Security & Access

Blob Storage supports

• Azure AD authentication
• Access keys
• Shared Access Signatures (SAS)
• Private endpoints
• Firewall rules

Best practice

Avoid using account keys for production apps.

Docs

• azure / storage / blobs / security recommendations

11. Public Endpoint Structure

Blob endpoint format

• <storageaccount>.blob.core.windows.net / <container> / <blob>

Example

• mystorage.blob.core.windows.net / images / photo1.jpg

12. High Availability & Durability

Blob durability depends on storage account redundancy

• LRS
• ZRS
• GRS
• GZRS
• RA-GZRS

Durability

• Up to 16 nines (99.99999999999999%)

13. Real-World Use Cases

Web Applications

Store static content.

Media Streaming

Store video files as block blobs.

VM Image Library

Store VHD files as page blobs.

Logging Platform

Store logs as append blobs.

Backup & Archiving

Archive tier for long-term retention.

14. Exam-Focused Pitfalls

• Blob storage is hierarchical → False
• Archive tier allows instant access → False
• Versioning replaces old version → False (creates new copy)
• Cool tier cheaper retrieval than hot → False
• Only one current version allowed → True

15. Mental Model Summary

Blob Storage =

Object store

Flat namespace

Tiered pricing

Versioning

Lifecycle policies

HTTP-based access

16. Deployment Workflow Summary

Create Storage Account

Open Blob service

Create Container

Upload blobs

Configure access tier

Enable versioning

Configure lifecycle rules

Final Conceptual Summary

Azure Blob Storage is a highly scalable, object-based storage system optimized for unstructured data with tiered cost management, versioning, and lifecycle automation.

Configuring Object Replication in Azure Blob Storage – Structured Summary + Deep Dive

Primary services involved

• Azure Blob Storage
• Azure Storage Account

1. What Is Object Replication?

Object replication is a feature that

• Asynchronously copies block blobs
• From a source storage account
• To a destination storage account
• Based on a replication policy

It is used for

• Reducing read latency
• Regional data distribution
• Data processing in multiple regions
• Cost optimization strategies

Official documentation

• azure / storage / blobs / object replication overview

2. Core Requirements (Very Important)

For object replication to work

✔ On Source Storage Account

• Blob versioning must be enabled
• Blob change feed must be enabled

✔ On Destination Storage Account

• Blob versioning must be enabled
• Change feed NOT required
• Why?
• Blob change feed tracks create/update/delete events
• Versioning ensures consistent replication of blob states

Docs

• Versioning: https://learn.microsoft.com/azure/storage/blobs/versioning-overview
• Change feed: https://learn.microsoft.com/azure/storage/blobs/storage-blob-change-feed

3. Architecture Concept

Source Storage Account (Region A)

└── Source Container

└── Block Blobs

↓ (Asynchronous replication policy)

Destination Storage Account (Region B)

└── Destination Container

└── Replicated Block Blobs

Important

• Replication is asynchronous
• Only block blobs are supported
• Page blobs and append blobs are NOT supported

4. Where Replication Can Occur

Object replication supports

• Same region
• Cross-region
• Cross-subscription
• Cross–Microsoft Entra ID tenants

Cross-tenant requires explicit configuration.

5. Why Use Object Replication?

1. Minimize Latency

If users are far from Region A

Replicate to Region B closer to them.

Reduces

• Read latency
• Cross-region bandwidth usage

2. Data Distribution

You can

• Process data in one region
• Replicate to another region
• Run analytics there

3. Regional Processing

Support

• Multi-region applications
• Regional compliance needs

4. Cost Optimization

You can

• Replicate data
• Move replicated copy to archive tier
• Reduce storage costs for secondary workloads

6. Replication Policy Details

When creating a replication rule, you must define

• Source container
• Destination container
• Prefix filter (optional)
• Copy scope

Prefix Filtering (Important Concept)

Blob storage uses flat namespace.

Folders are just prefixes.

Example

• awesomefolder/file3.txt

Internally

• Blob name = awesomefolder/file3.txt

If you configure prefix filter

• awesomefolder/

Only blobs with that prefix are replicated.

This enables

Selective replication.

Copy Scope Options

You can choose

• Everything
• Only new objects
• Custom time-based configuration

7. Important Behavior Notes

• Replication is asynchronous
• Replication delay depends on workload
• Only block blobs supported
• Replication respects versions
• Destination blobs are read-only copies

8. Versioning Interaction

Since versioning is enabled

• Each blob version is replicated
• Updates generate new versions
• Delete operations are tracked

This ensures

Consistency between source and destination.

9. Replication vs Redundancy (Common Confusion)

Do NOT confuse

• Storage account redundancy (LRS/ZRS/GRS)
• with

Object replication.

Difference

• | Feature | Redundancy | Object Replication |
• | --- | --- | --- |
• | Automatic | Yes | No (policy-based) |
• | Whole account | Yes | Per container |
• | Region control | Limited | Full control |
• | Filtering | No | Yes (prefix) |

Object replication gives

Granular control.

🔟 Demonstration Summary

Steps performed

• Enabled versioning (source + destination)
• Enabled change feed (source only)
• Created source container
• Created destination container
• Uploaded blobs to source
• Created replication policy
• Added prefix filter
• Verified replicated blob in destination

Only blobs matching prefix were replicated.

11. Replication Monitoring

You can view

• Objects copied from this account
• Objects copied into this account
• Replication policy status

Each storage account shows

Inbound and outbound replication rules.

12. Real-World Scenarios

🌍 Multi-Region SaaS App

Users in US and Europe

Replicate to both regions.

Analytics Pipeline

Raw data in Region A

Replicate to Region B for ML processing.

🏛 Compliance

Primary region + regulated secondary region.

💰 Cost Optimization

Primary hot tier

Replicate + archive secondary.

13. Limitations & Considerations

Only block blobs supported

Requires versioning

Requires change feed (source)

Replication policy per container

Destination must exist

Cross-tenant requires permissions

Asynchronous (not instant)

14. Security Considerations

Use RBAC instead of access keys

Configure private endpoints if needed

Control cross-tenant replication carefully

Replicated blobs inherit access controls

15. Exam-Relevant Concepts

• Change feed required on destination → False
• Versioning required on both accounts → True
• Object replication is synchronous → False
• Supports append blobs → False
• Supports cross-region replication → True
• Can filter by prefix → True

16. Conceptual Summary

Object replication =

Controlled, policy-driven, asynchronous copying of block blobs between storage accounts with version awareness and optional prefix filtering.

17. Mental Model

Think of it as

Event-driven blob mirroring powered by change feed.

Configuring Blob Lifecycle Management – Structured Summary + Deep Dive

Primary service

• Azure Blob Storage

Lifecycle management is an automation feature in Azure Blob Storage that:

Automatically moves blobs between access tiers

Or deletes them

Based on age or conditions

It is primarily used for

• Cost optimization
• Operational efficiency
• Automated data governance

Official documentation

• azure / storage / blobs / lifecycle management overview

1. Why Lifecycle Management Exists

By default

• Blobs inherit the storage account’s default access tier (often Hot)
• Over time, large volumes of data accumulate
• Storage costs increase

Not all data needs to remain in the Hot tier.

Lifecycle management solves this by

• Automatically tiering data
• Reducing manual intervention
• Lowering long-term storage costs

2. Access Tier Recap

Blob tiers

| Tier | Storage Cost | Access Cost | Best For |

| --- | --- | --- | --- |

| Hot | High | Low | Frequent access |

| Cool | Lower | Higher | 30+ days infrequent |

| Cold | Even lower | Higher | 90+ days rare |

| Archive | Lowest | Highest | 180+ days very rare |

Lifecycle policies move blobs between these tiers automatically.

Docs

• azure / storage / blobs / access tiers overview

3. What Lifecycle Management Can Do

Lifecycle rules can

• Move blobs from Hot -> Cool
• Move blobs from Cool -> Cold
• Move blobs from Cold -> Archive
• Delete blobs after certain time
• Delete previous versions
• Delete snapshots

It uses

IF–THEN logic.

Example

• If last modified > 30 days
• Then move to Cool tier

4. Lifecycle Rule Structure

Lifecycle rules consist of

• Scope
• Conditions
• Actions
• Filters (optional)

1. Scope

You can apply rule to

• All blobs in storage account
• Specific containers
• Specific prefixes (folders)

2. Conditions (IF)

Conditions can be based on

• Days since last modified
• Days since creation
• Blob type
• Blob version
• Snapshot age

Example

• Last modified > 30 days

3. Actions (THEN)

Actions include

• Move to Cool
• Move to Cold
• Move to Archive
• Delete blob
• Delete version

4. Filters

Because Blob Storage uses a flat namespace

Folders are prefixes.

Example

• awesomecontainer01/awesomefolder01/

This matches blobs with that prefix.

This allows

Granular lifecycle control.

5. Demonstration Summary

Steps performed

• Open storage account
• Navigate to Lifecycle Management
• Add new rule
• Limit blobs using filter
• Apply to specific container + folder prefix

Set condition

• Last modified > 30 days

Action

• Move to Cool tier
• Save rule

After 30 days

• Blobs matching prefix automatically move from Hot -> Cool.

6. Real-World Lifecycle Example

A common enterprise policy

• Day 0–30 -> Hot
• Day 30–90 -> Cool
• Day 90–180 -> Cold
• Day 180+ -> Archive
• Day 365+ -> Delete

This balances

Performance + Cost.

7. Cost Optimization Impact

Without lifecycle management

All blobs stay in Hot tier.

Hot tier = highest storage cost.

Lifecycle management

• Gradually reduces storage costs
• Minimizes admin overhead
• Enforces retention automatically

8. Versioning + Lifecycle

If versioning is enabled

Lifecycle rules can

• Delete old versions after X days
• Move older versions to Archive

Important

Old versions accumulate storage cost.

Docs

• azure / storage / blobs / versioning overview

9. Blob Types Supported

Lifecycle policies apply to

• Block blobs
• Append blobs
• Base blobs
• Snapshots
• Versions

You can choose which types the rule applies to.

🔟 Important Behavior Notes

Rules run once per day

Changes are not instant

Archive tier requires rehydration

Early deletion fees apply

• Cool -> 30 days minimum
• Cold -> 90 days minimum
• Archive -> 180 days minimum

If moved too early, you still pay minimum duration fee.

11. JSON-Based Policy (Advanced Concept)

Lifecycle policies are stored as JSON policies internally.

Example structure

• {
• "rules": [
• {
• "enabled": true,
• "name": "move-to-cool",
• "type": "Lifecycle",
• "definition": {
• "filters": {...},
• "actions": {...}
• }
• }
• ]
• }

This enables

Infrastructure-as-code automation.

Docs

• azure / storage / blobs / lifecycle management policy configure

12. Lifecycle vs Manual Tiering

| Manual | Lifecycle |

| --- | --- |

| Labor-intensive | Automated |

| Error-prone | Policy-driven |

| Hard to scale | Scales automatically |

Lifecycle management is preferred for production.

13. Governance & Compliance Use Cases

Lifecycle helps

• Enforce retention periods
• Meet regulatory compliance
• Automate deletion of expired data
• Reduce legal risk

Often combined with

• Blob versioning
• Soft delete
• Immutable storage

14. Common Exam Pitfalls

• Lifecycle works instantly → False
• Applies to all storage services → False (Blob only)
• Archive tier instantly accessible → False
• Folders are real directories → False (prefix only)
• Can delete versions automatically → True

15. Design Best Practices

• Keep default tier = Hot
• Use lifecycle for aging
• Define clear retention strategy
• Combine with version cleanup
• Test policy in non-production first

16. Conceptual Model

Blob Lifecycle Management =

Automated tiering engine

Age-based policies

Cost optimization mechanism

Governance enforcement tool

Final Summary

Blob lifecycle management is an automation framework in Azure Blob Storage that moves or deletes data based on defined rules to optimize cost and enforce retention policies over time.

Securing Storage Accounts – Structured Summary + Deep Dive

Primary service

• Azure Storage

This lesson explains how to secure Azure Storage Accounts at multiple layers:

Encryption (data at rest & in transit)

Authentication (who can access)

Authorization (what they can do)

Key management & SAS governance

Official documentation

• azure / storage / common / storage security guide

1. Security Goals for Storage Accounts

Regardless of the service used (Blobs, Files, Queues, Tables), the objectives are:

• Protect data at rest
• Protect data in transit
• Control access (least privilege)
• Enable key rotation
• Support compliance & governance

2. Encryption in Azure Storage

A. Encryption at Rest (Default)

Azure Storage automatically uses

• Storage Service Encryption (SSE)
• 256-bit AES encryption
• Enabled by default
• No extra configuration required

Docs

• azure / storage / common / storage service encryption

B. Microsoft-Managed Keys (MMK)

Default option.

Azure

• Generates
• Rotates
• Manages
• Protects keys

Best for

• Simplicity
• Most production workloads

C. Customer-Managed Keys (CMK)

You can bring your own encryption keys.

Requires

• Key stored in
• Azure Key Vault
• User-assigned managed identity

Key permissions

• Get
• WrapKey
• UnwrapKey

Benefits

• Regulatory compliance
• Full control over key lifecycle
• Ability to revoke access instantly

Docs

• azure / storage / common / customer managed keys overview

D. Infrastructure Encryption

Optional second layer of encryption.

Adds

• Double encryption at infrastructure level
• Extra compliance assurance

Important

• ⚠ Must be enabled at storage account creation
• ⚠ Cannot be changed later

3. Encryption in Transit

Setting: Secure transfer required

When enabled

• Only HTTPS allowed
• ❌ HTTP blocked

This prevents

• Man-in-the-middle attacks
• Plain-text data transmission

Recommended: Always enabled (default).

Docs

• azure / storage / common / storage require secure transfer

4. Authentication Layers Explained

There are two distinct layers

1. Management Plane

Controls

• Storage account settings
• Configuration
• Networking
• Key settings

Managed via

• Azure RBAC

2. Data Plane

Controls

• Blob access
• File access
• Queue messages
• Table entities

Can use

• Access Keys
• SAS
• Microsoft Entra ID

Understanding this distinction is critical for exams.

5. Access Keys

Every storage account includes

• Key1
• Key2

Characteristics

• Full root-level access
• Covers management + data plane
• Unlimited permissions

Use case

• Legacy apps
• Simplified connection strings

Risk

• ❗ Too much privilege
• ❗ Hard to audit

Key Rotation Strategy

Use dual-key model

• App uses Key1
• Switch app to Key2
• Regenerate Key1
• Repeat cycle

If you regenerate without switching

Application breaks immediately.

Docs

• azure / storage / common / storage account keys manage

6. Shared Access Signatures (SAS)

SAS provides

• Limited access
• Time-bound access
• Permission-scoped access

Instead of giving full access key, you generate a token.

SAS Levels

1. Account-level SAS

Grants access to

• Multiple services
• Entire storage account

2. Service-level SAS

Grants access to

• Specific container
• Specific service (Blob, File, etc.)

3. Object-level SAS

Grants access to

• Single blob

SAS Controls

You can restrict

• Start time
• Expiry time
• Permissions (Read, Write, Delete, List, etc.)
• IP address range
• Allowed protocols (HTTPS only recommended)

Docs

• azure / storage / common / storage sas overview

7. User Delegation SAS (More Secure)

Instead of signing with account key

Use

• Microsoft Entra identity

This is called

• User Delegation SAS

Benefits

• No storage account keys required
• Azure RBAC enforced
• Better security model

Recommended for modern architectures.

8. Stored Access Policies

Stored Access Policies allow

• Centralized management of SAS tokens
• Modify or revoke multiple SAS tokens at once

How it works

• Create policy on container
• Attach SAS tokens to that policy
• Modify policy -> affects all attached SAS tokens

This solves

Problem of "unrevokable" SAS tokens.

Docs

• azure / storage / blobs / security recommendations

9. Disabling Key-Based Access

You can disable

• Storage account key access

Then only allow

• Microsoft Entra ID authentication

This enforces stronger identity-based access control.

Recommended for enterprise security.

🔟 Security Architecture Summary

Azure Storage Security Stack

• Layer 1: Encryption at Rest (SSE)
• Layer 2: Encryption in Transit (HTTPS)
• Layer 3: Authentication (Keys / SAS / Entra ID)
• Layer 4: Authorization (RBAC / Policies)
• Layer 5: Key Rotation & Governance

11. Best Practice Recommendations

• Keep Secure transfer enabled
• Use Microsoft Entra ID over access keys
• Prefer User Delegation SAS
• Rotate access keys regularly
• Use Stored Access Policies
• Use CMK if compliance requires
• Disable key access in enterprise environments

12. Common Exam Pitfalls

• Access keys provide limited access → False
• SAS can be time-restricted → True
• Infrastructure encryption can be changed later → False
• Encryption at rest must be manually enabled → False
• You can revoke SAS by deleting policy → True

13. Real-World Security Model Example

Enterprise secure design

• CMK with Azure Key Vault
• Infrastructure encryption enabled
• Secure transfer required
• Key access disabled
• RBAC enforced
• User Delegation SAS for temporary sharing
• Lifecycle management for old data
• Access logs enabled

14. Deep Concept: Why Keys Are Risky

Access keys

• Bypass RBAC
• Grant full control
• Hard to audit
• Often embedded in code

Modern recommendation

Move toward

• Identity-based authentication (Entra ID + RBAC)

15. Complete Security Flow Example

User authenticates via Entra ID

RBAC determines permissions

Blob request over HTTPS

Data encrypted at rest

Optional CMK used

Optional infrastructure encryption applied

This provides end-to-end protection.

Final Summary

Securing Azure Storage involves

• Automatic encryption at rest
• Enforced HTTPS in transit
• Strong identity-based authentication
• Limited-scope SAS tokens
• Key rotation strategies
• Optional customer-managed encryption keys
• Stored access policies for centralized governance

It is a layered security model combining encryption, identity, and access control.

Configuring Azure Files – Structured Summary + Deep Dive

Primary service

• Azure Files

Azure Files is a fully managed cloud file share service built on top of:

Azure Storage

It provides

• SMB (Server Message Block)
• NFS (Network File System)

access to file shares hosted in Azure.

Official documentation

• azure / storage / files / storage files introduction

1. What is Azure Files?

Azure Files is

• A managed file-sharing service
• Hosted in a storage account
• Accessible over SMB or NFS
• Cross-platform (Windows, Linux, macOS)

Unlike Azure Blob Storage

• Blob = object storage (flat namespace)
• Azure Files = real hierarchical file system

Azure Files supports

• True folders
• File permissions
• NTFS/SMB metadata
• POSIX-style structure (for Linux NFS)

2. Architecture Overview

Azure Files hierarchy

• Storage Account
• → File Service
• → File Shares
• → Folders
• → Files

You can have

• Multiple file shares per storage account
• Each share has its own structure
• Each share has its own endpoint

Endpoint example

• \storageaccountname.file.core.windows.net\sharename

3. SMB vs NFS

Azure Files supports

• SMB (Common)
• Windows native
• NTFS permissions
• Azure AD / AD DS integration
• Most enterprise scenarios
• NFS
• Linux workloads
• POSIX permissions
• Requires Premium file shares

Docs

• azure / storage / files / storage files active directory overview

4. Storage Account Requirements

Azure Files can be hosted in

• General Purpose v2 (Standard)
• Premium FileStorage accounts (for high performance)

Premium required for

• NFS
• Low-latency workloads
• High IOPS

5. Performance Tiers (Standard Accounts)

Standard file shares offer multiple tiers

• | Tier | Best For |
• | --- | --- |
• | Transaction Optimized | Transaction-heavy workloads |
• | Hot | General purpose file sharing |
• | Cool | Archival-like, lower performance |

Important

⚠ These tiers are NOT the same as Blob storage access tiers

⚠ Lifecycle management is NOT supported for file shares

Docs

• azure / storage / files / storage files planning

6. Quota Configuration

Each file share allows

• Configurable size limit (e.g., 100 GB)
• Helps prevent runaway growth
• Enforces cost control

Quota can be modified after creation.

7. Demonstration Summary

Steps performed

• Navigate to Storage Account
• Go to File Shares
• Create new file share
• Select tier (Transaction Optimized)
• Configure quota
• Upload files
• Create directory
• Connect via Windows
• Mount share as drive (Z:)

Connection script

• Uses Storage Account Key
• Mounts persistent SMB drive
• Maps network location

After mounting

• Files visible in Windows Explorer
• Changes sync bidirectionally

8. Authentication Options

Azure Files supports

1. Storage Account Key

Simple

Full access

Less secure

2. Active Directory (AD DS)

Domain-based authentication

NTFS ACLs supported

3. Microsoft Entra ID

Identity-based access

Modern cloud authentication

Recommended

Use AD DS or Entra ID in enterprise environments.

Docs

• azure / storage / files / storage files identity auth active directory enable

9. How Mounting Works (Windows Example)

PowerShell script performs

• Connectivity test to port 445
• Mounts SMB share
• Creates persistent drive mapping

Drive appears under

• "This PC" -> Network Locations

This behaves exactly like

Traditional on-prem file share.

🔟 Key Differences: Azure Files vs Blob Storage

| Feature | Azure Files | Blob Storage |

| --- | --- | --- |

| Structure | Hierarchical | Flat namespace |

| Protocol | SMB/NFS | HTTP/HTTPS |

| Mountable | Yes | No |

| NTFS Permissions | Yes | No |

| Lifecycle Management | No | Yes |

| Best For | Lift-and-shift file servers | Object storage |

11. Common Use Cases

• Lift-and-shift file servers
• Shared application storage
• User home directories
• Azure Virtual Desktop profiles
• Hybrid file server via Azure File Sync

12. Azure File Sync (Important Concept)

Azure File Sync allows

• On-prem Windows Server
• Sync to Azure file share
• Cache hot data locally
• Tier cold data to cloud

This enables

Hybrid file architecture.

Docs

• azure / storage / file sync / file sync introduction

13. Security Considerations

Best practices

• Enable Secure Transfer
• Use identity-based authentication
• Restrict network access via Private Endpoint
• Disable public access if not required
• Use RBAC

Azure Files supports

• NTFS ACLs (SMB)
• POSIX permissions (NFS)
• Encryption at rest (default)
• Encryption in transit (SMB 3.x)

14. Cost Considerations

Costs based on

• Provisioned size (quota)
• Transactions
• Data stored
• Tier selected
• Outbound data transfer

Premium file shares

• Provisioned capacity model
• Higher cost
• Higher performance

15. Enterprise Design Pattern

Typical enterprise architecture

• Users -> SMB mount → Azure Files
• VMs -> Shared config storage
• App Servers -> Shared file repository
• On-Prem -> Azure File Sync → Azure Files

16. Limitations to Know

⚠ Lifecycle management not supported

⚠ NFS requires Premium

⚠ Port 445 must be open (SMB)

⚠ Some ISPs block port 445

⚠ Not ideal for ultra-high IOPS workloads unless Premium

17. Common Exam Pitfalls

• Azure Files = object storage → False
• Supports true folders → True
• Lifecycle supported → False
• SMB supported → True
• NFS supported on Standard → False

18. When to Choose Azure Files

Choose Azure Files if

• You need traditional file system semantics
• You want lift-and-shift file server
• Applications expect SMB
• You need NTFS permissions

Choose Blob if

• You need object storage
• HTTP-based access
• Massive unstructured storage
• Lifecycle automation
• Final Summary

Azure Files is a managed cloud file-sharing service that

• Runs inside a storage account
• Provides SMB/NFS connectivity
• Offers real hierarchical file systems
• Supports identity-based authentication
• Enables hybrid and cloud-native file sharing
• Integrates seamlessly with Windows and Linux

It is the cloud equivalent of a traditional file server, but fully managed and scalable.

Managing Azure Files – Snapshots & Soft Delete (Structured Summary + Deep Dive)

Primary service

• Azure Files

Azure Files provides built-in data protection features

1. File Share Snapshots

2. Soft Delete

These protect against

• Accidental deletion
• Unwanted modifications
• Operational mistakes
• Certain disaster scenarios

Official documentation

• azure / storage / files / storage files data protection overview

1. What Is a Snapshot?

A snapshot is

A read-only, point-in-time copy of data.

Snapshots are common across

• Virtual machines
• Databases
• Storage systems

In Azure Files

• Snapshot captures the entire file share
• It is read-only
• It is incremental
• It can be mounted or restored

Docs

• azure / storage / files / storage snapshots files

2. Azure File Share Snapshots

When you create a snapshot

• Azure stores only changes since the previous snapshot
• This reduces storage costs
• Snapshots remain within the same storage account
• Key Characteristics
• | Feature | Behavior |
• | --- | --- |
• | Scope | Entire file share |
• | Access | Read-only |
• | Storage | Incremental |
• | Restore | Entire share or individual files |
• | Billing | Charged for changed blocks only |

3. Why Snapshots Are Useful

• Version Control

Recover earlier file versions.

• Disaster Recovery

Restore after corruption or ransomware.

• Backup Support

Can be used for retention policies.

• Safe Change Rollback

Take snapshot before major updates.

4. Snapshot Restore Options

When restoring

• Overwrite original file
• Restore as new file
• Browse and copy specific data

Important

Snapshots protect at share level — not granular file retention policy.

5. Demonstration Summary – Snapshots

Steps performed

• Open file share
• Navigate to Snapshots
• Click Add Snapshot
• Snapshot created (incremental)
• Modify file on Windows server
• Restore file from snapshot
• Original content restored

Key takeaway

Snapshots allow precise point-in-time recovery.

6. What Is Soft Delete?

Soft Delete protects

Entire file shares from accidental deletion.

When enabled

• Deleted file shares are retained
• Data recoverable for configured period
• Retention period: 1–365 days

Docs

• azure / storage / files / storage files prevent file share deletion

7. Important Soft Delete Behavior

| Feature | Behavior |

| --- | --- |

| Scope | Entire file share |

| Protects | Share deletion |

| Does NOT protect | Individual file deletions |

| Default | Enabled |

| Retention | Configurable (1–365 days) |

Very important

• ⚠ Soft delete does NOT protect individual files
• ⚠ Only protects deleted shares

8. Demonstration Summary – Soft Delete

Steps performed

• Confirm soft delete enabled
• Attempt delete
• Removed resource lock (Azure Backup lock)
• Deleted file share
• Toggled "Show deleted shares"
• Restored share via Undelete
• Share status returned to Active

Key takeaway

Soft delete provides full share recovery.

9. Soft Delete vs Snapshot

| Feature | Snapshots | Soft Delete |

| --- | --- | --- |

| Protects modified files | Yes | No |

| Protects deleted shares | No | Yes |

| Scope | Share state | Share existence |

| Retention control | Manual | Configurable |

| Incremental | Yes | N/A |

Best practice

Use BOTH together.

🔟 Resource Lock Behavior (Important Detail)

When soft delete enabled

• Azure Backup integration may create locks
• You must remove lock before deleting share

Locks protect against accidental deletion.

This is part of

Defense-in-depth.

11. Cost Considerations

Snapshots

Charged for changed data only

Incremental billing

Frequent changes increase cost

Soft Delete

Deleted share data still stored during retention

Storage billed until permanently deleted

12. Enterprise Protection Strategy

Enterprise-grade Azure Files protection

• Soft delete enabled
• Daily snapshots
• Azure Backup configured
• Immutable storage where required
• RBAC access control

Docs

• azure / backup / backup azure files

13. Advanced Concept: Snapshot Internals

Snapshots are

• Metadata pointers
• Block-level differential storage
• Stored in same storage account
• Not separate full copy

This makes them

• Fast
• Storage efficient

14. Ransomware Protection Strategy

If ransomware modifies files

• Snapshot taken prior to infection
• Restore entire share or affected files
• Recover to safe state

Snapshots act as rollback mechanism.

15. Limitations to Understand

⚠ Snapshots are not cross-region

⚠ Soft delete does not protect files

⚠ Snapshots must be manually managed

⚠ Premium shares also support snapshots

⚠ No lifecycle automation like Blob tiering

16. Real-World Use Cases

• Pre-deployment safe point
• Patch rollback
• File corruption recovery
• Accidental overwrite recovery
• Accidental share deletion recovery

17. Common Exam Pitfalls

• Soft delete protects files → False
• Snapshots are full copies → False
• Snapshots are read-only → True
• Soft delete is enabled by default → True
• Snapshots are incremental → True

18. Recommended Best Practice Design

Minimum production configuration

• Soft delete enabled (30+ days)
• Automated snapshot schedule
• Azure Backup vault integration
• Private endpoint access
• RBAC enforcement
• Monitoring enabled
• Final Summary

Azure Files data protection includes

Snapshots

→ Point-in-time, incremental, read-only copies of file shares

→ Restore files or full share

Soft Delete

→ Protects against accidental share deletion

→ Retains deleted shares for configurable period

Together, they provide layered protection for file share workloads.

Providing Access to Azure Files – Identity-Based Authentication (Structured Summary + Deep Dive)

Primary service

• Azure Files

Identity-based authentication allows Azure Files to integrate with directory services such as:

Microsoft Entra ID

Active Directory Domain Services (AD DS)

Microsoft Entra Domain Services

Instead of using

• Storage account keys
• SAS tokens

This provides enterprise-grade access control.

Official documentation

• azure / storage / files / storage files active directory overview

1. Why Use Identity-Based Authentication?

Traditional methods (Access Keys / SAS)

• ❌ Full account-level access
• ❌ Hard to audit
• ❌ Not user-specific
• ❌ Poor least-privilege enforcement

Identity-based authentication provides

• Per-user authentication
• Kerberos support
• RBAC enforcement
• Familiar Windows admin model
• Integration with LDAP/Kerberos apps
• Auditability

2. What Identity-Based Authentication Controls

Important distinction

Identity-based authentication controls

• Share-level access

It does NOT replace

• ❗ File-level NTFS ACLs
• ❗ Directory-level permissions

You still must configure

• Windows Access Control Lists (ACLs)

Think of it as

• Layer 1: Share access (Azure RBAC)
• Layer 2: File/folder permissions (NTFS ACL)

3. Identity Options for Azure Files

Azure Files supports three identity models

1. Active Directory Domain Services (AD DS)

Traditional on-premises domain.

Best for

• Hybrid environments
• Lift-and-shift scenarios
• Existing Windows infrastructure

Requires

• Domain-joined storage account
• Service principal setup
• SPN configuration

Docs

• azure / storage / files / storage files identity ad ds enable

2. Microsoft Entra Domain Services

Managed domain service.

Best for

• Cloud-first deployments
• No on-prem domain controllers
• Simplified domain management

Prerequisite

Entra Domain Services must already be deployed.

Docs

• azure / storage / files / storage files identity auth domain services enable

3. Microsoft Entra Kerberos

Modern cloud-native approach.

Best for

• Hybrid Azure AD-joined devices
• Cloud-first identity strategy

Requires

• Entra ID application registration
• Kerberos ticket issuance
• Explicit permission grants

Docs

• azure / storage / files / storage files identity auth azure ad enable

4. Share-Level RBAC Roles

When identity-based authentication is enabled, you manage access via

Azure RBAC roles.

Key built-in roles

• | Role | Permission |
• | --- | --- |
• | Storage File Data SMB Share Reader | Read-only |
• | Storage File Data SMB Share Contributor | Read/write |

| Storage File Data SMB Share Elevated Contributor | Full control |

| Storage File Data SMB Share Owner | Full management |

These apply at

• File share scope
• Storage account scope
• Resource group scope

Docs

• azure / storage / files / storage files identity auth azure ad enable

5. How Authentication Flow Changes

Without Identity-Based Auth

Mount script uses

• Storage account name
• Access key (as password)

Example concept

• net use Z: \storageaccount.file.core.windows.net\share

This uses root-level credentials.

With Identity-Based Auth

Mount script

• Uses domain credentials
• Uses Kerberos ticket
• No access key required

Security benefit

• No shared secrets
• Identity-bound access
• Better auditing

6. Access Control Layers Explained

Layer 1: Share-Level Authorization

Controlled via

• Azure RBAC

Determines

• Can user connect to share?

Layer 2: File-Level Permissions

Controlled via

• NTFS ACLs

Determines

• Can user read/write specific files?

Example

• User may connect to share
• But denied access to specific folder

7. ACL (Access Control List) Concept

An ACL defines

• Users
• Groups
• Computer accounts
• Security principals

And their permissions

• Read
• Write
• Modify
• Full Control

ACLs can be

• Backed up
• Restored
• Managed via File Explorer

8. Demonstration Summary

Steps shown

• Open file share
• Click "Identity-based access"

Choose identity source

• AD DS
• Entra Domain Services
• Entra Kerberos
• Enable configuration
• Assign RBAC roles
• Mount using identity instead of key

Key observation

Mount script no longer requires storage account key.

9. Security Architecture Comparison

| Feature | Access Keys | Identity-Based |

| --- | --- | --- |

| User-specific | ❌ | ✔ |

| Auditable | ❌ | ✔ |

| Kerberos | ❌ | ✔ |

| Least privilege | ❌ | ✔ |

| Recommended | ❌ | ✔ |

Enterprise best practice

• Disable storage key access
• Use Entra ID + RBAC
• 🔟 Hybrid Architecture Scenario

Common enterprise pattern

• On-Prem AD
• ↓
• Azure AD Connect
• ↓
• Microsoft Entra ID
• ↓
• Azure Files (Kerberos auth)

This allows

• Seamless authentication
• Same credentials
• Hybrid identity

11. Important Limitations

⚠ Identity-based auth applies only to SMB (not NFS)

⚠ NFS uses network-based controls

⚠ Must configure NTFS permissions separately

⚠ Requires proper DNS resolution

⚠ Port 445 must be open

12. Common Exam Pitfalls

• Identity-based auth replaces NTFS → False
• Access keys are more secure → False
• RBAC controls file-level ACL → False
• Identity-based works for SMB → True
• Custom roles allowed → True

13. Enterprise Best Practice Design

Secure Azure Files design

• Identity-based authentication enabled
• Azure RBAC assigned at share level
• NTFS ACLs configured properly
• Storage account key access disabled
• Private endpoints enabled
• Monitoring + logging enabled

14. Deep Concept: Why This Matters

Traditional file servers

• Rely on Kerberos
• Use NTFS permissions
• Use domain groups

Azure Files identity-based auth allows

Lift-and-shift without redesigning access model.

It bridges

Cloud storage + legacy enterprise authentication.

15. When to Use Each Identity Type

| Scenario | Best Option |

| --- | --- |

| Hybrid enterprise | AD DS |

| Cloud-only domain | Entra Domain Services |

| Modern cloud-native | Entra Kerberos |

Final Summary

Identity-based authentication for Azure Files

• Replaces shared secrets with user-based auth
• Integrates with AD / Entra ID
• Enables RBAC share-level control
• Still requires NTFS ACL configuration
• Improves security, auditability, and governance

It is the recommended enterprise-grade method for securing Azure file shares.

Storage Utilities – Azure Storage Explorer & AzCopy (Structured Summary + Deep Dive)

Azure provides powerful utilities to manage

• Azure Storage

including

• Blob Storage
• Azure Files
• Queues
• Tables

The two primary tools are

1. Azure Storage Explorer (GUI)

2. AzCopy (CLI)

There is also a lightweight portal tool called Storage Browser.

1. Storage Browser (Portal-Based Tool)

Built into Azure Portal.

Features

• View containers
• View file shares
• Basic upload/download
• Simple management

Limitations

• ❌ Limited performance
• ❌ Not ideal for bulk operations
• ❌ Limited automation

Best for

• Quick inspection
• Small operations
• Troubleshooting

2. Azure Storage Explorer (GUI Tool)

Official tool

• Azure Storage Explorer

Documentation

• azure / storage / common / storage explorer

Supported OS

• Windows
• macOS
• Linux

What Storage Explorer Does

• Connect to subscriptions
• Connect to individual storage accounts
• Upload/download blobs
• Manage file shares
• Generate SAS tokens
• Create snapshots
• Manage access policies
• Copy/clone containers
• View queues & tables

It uses

• AzCopy internally for data transfer

So it is

GUI wrapper over AzCopy.

Connection Methods

You can connect via

• Azure subscription (Entra login)
• Connection string
• SAS URL
• Storage account name + key

Best practice

Use Microsoft Entra ID authentication when possible.

Key Capabilities Demonstrated

In the lesson

• Connected via account name + key
• Viewed blob containers
• Uploaded/downloaded blobs
• Managed file shares
• Created snapshots
• Generated SAS
• Managed stored access policies

It mirrors portal functionality — but more powerful.

3. AzCopy (Command Line Tool)

Official tool

• AzCopy

Documentation

• azure / storage / common / storage use azcopy v10

AzCopy is

• High-performance CLI tool
• Optimized for bulk transfers
• Scriptable
• Automation-friendly
• Cross-platform

Why Use AzCopy?

Best for

• Large data migrations
• Backup operations
• Automation scripts
• CI/CD pipelines
• DevOps workflows
• Scheduled jobs

4. AzCopy Authentication Methods

You can authenticate using

1. Microsoft Entra ID (Recommended)

Command

• azcopy login

Prompts

• Browser authentication
• Device code login

Best practice: use identity-based authentication.

2. SAS Token

Used for temporary scoped access.

Example

• azcopy copy "source" "destination?SAS"

3. Account Key

Provides full access.

Less secure.

5. AzCopy Common Commands

Create Container

azcopy make "https://account.blob.core.windows.net/container"

Upload File

azcopy copy "localfile.txt" "https://account.blob.core.windows.net/container"

Download File

azcopy copy "https://account.blob.core.windows.net/container/file" "localpath"

Sync (Very Powerful)

azcopy sync "source" "destination"

Sync supports

• Incremental updates
• Efficient delta transfers

6. AzCopy Performance Features

AzCopy includes

• Parallel transfers
• Resume support
• Chunked uploads
• Large file support (TB-scale)
• High-throughput optimization

It is designed for

Enterprise-scale data movement.

7. Storage Explorer vs AzCopy

| Feature | Storage Explorer | AzCopy |

| --- | --- | --- |

| Interface | GUI | CLI |

| Best For | Interactive use | Automation |

| Bulk Transfer | Yes | Excellent |

| Scriptable | No | Yes |

| Uses AzCopy internally | Yes | Native |

| DevOps Friendly | Limited | Excellent |

8. Security Considerations

When using these tools

• Prefer Entra ID login
• Avoid hardcoding access keys
• Use SAS for limited sharing
• Rotate keys regularly
• Restrict network access

9. Where These Tools Fit in Architecture

Developer Workflow

• Local machine -> AzCopy → Blob container

Migration Scenario

• On-prem server -> AzCopy → Azure Storage

Admin Management

• Storage Explorer -> Manage blobs/files visually

CI/CD Pipeline

• Pipeline script -> AzCopy → Upload artifacts

🔟 Enterprise Data Migration Pattern

Large migration example

• On-prem file server
• ↓
• AzCopy recursive upload
• ↓
• Azure Blob or Azure Files
• ↓
• Validate integrity

AzCopy supports

• Recursive copy
• Filtering
• Pattern matching
• Log output

11. Advanced AzCopy Capabilities

• Cross-account copy
• Cross-region copy
• Cross-tenant copy
• Resume failed transfers
• Generate transfer logs

You can copy directly

• Azure -> Azure

Without downloading locally.

12. Common Exam Pitfalls

• Storage Explorer is required → False
• AzCopy supports Entra login → True
• AzCopy only works on Windows → False
• Storage Explorer uses AzCopy internally → True
• Portal is best for bulk data migration → False

13. When to Use Each Tool

Use Storage Explorer when

• You need a visual interface
• You are browsing data
• You need quick management

Use AzCopy when

• You are migrating TBs of data
• You need automation
• You need CI/CD integration
• You want performance

14. Best Practice Recommendations

• Use Entra ID authentication
• Add AzCopy to system PATH
• Store credentials securely
• Use SAS for temporary access
• Log and monitor transfers
• Test transfers before production migration

15. Real-World Enterprise Example

Scenario

Company migrating 50 TB to Azure.

Solution

• Install AzCopy
• Authenticate with Entra ID
• Run recursive copy
• Monitor logs
• Validate checksums

This is far superior to manual upload.

Final Summary

Azure Storage Utilities include

Storage Browser (basic portal tool)

Azure Storage Explorer (GUI client)

AzCopy (high-performance CLI tool)

Storage Explorer uses AzCopy under the hood.

AzCopy is preferred for

• Automation
• Large transfers
• Enterprise workloads

Together, they provide both user-friendly and scriptable methods for managing Azure Storage.

Exam Tips: Azure Storage – Structured Review + Deep Understanding

Primary service

• Azure Storage

This summary consolidates the most exam-relevant Azure Storage concepts, design principles, and architecture insights.

Official documentation hub

• azure / storage

1. Storage Account Fundamentals

A storage account is a top-level Azure resource that hosts multiple storage services:

Blob Storage

Azure Files

Queues

Tables

It defines

• Performance tier
• Redundancy model
• Security settings
• Networking rules
• Lifecycle configuration

2. Performance Tiers

Standard (General Purpose v2 – Default)

Most common

Cost-effective

Supports all services

Required for lifecycle management

Recommended for most workloads

Premium

Low latency

High IOPS

SSD-backed

Used for

• Premium Blob
• Premium Files
• High-performance scenarios

Docs

• azure / storage / common / storage account overview

3. Redundancy Options (Critical Exam Topic)

Redundancy determines durability and availability.

LRS (Locally Redundant Storage)

3 copies

Same availability zone

Cheapest option

No zone or region protection

ZRS (Zone-Redundant Storage)

Copies across availability zones

Survives zone failure

GRS (Geo-Redundant Storage)

Replicates to secondary region

3 copies in primary + 3 in secondary

GZRS (Geo-Zone-Redundant Storage)

ZRS in primary region

LRS in secondary region

Highest durability

RA-GZRS (Read-Access GZRS)

Same as GZRS

Secondary region readable

Docs

• azure / storage / common / storage redundancy

4. Azure Blob Storage (Object Storage)

Primary service

• Azure Blob Storage

Structure

• Storage Account
• → Blob Service
• → Container
• → Blob

Important

• Flat namespace
• “Folders” = prefixes
• Object-based storage
• HTTP/HTTPS access

5. Object Replication (Blob Replication)

Requirements

• Versioning enabled on source & destination
• Change feed enabled on source
• Replication policy configured

Facts

• Asynchronous
• Source can replicate to up to 2 destinations
• Can filter via prefix
• Cross-region, cross-subscription, cross-tenant supported

Docs

• azure / storage / blobs / object replication overview

6. Blob Lifecycle Management

Requires

• General Purpose v2 account

Supported blob types

• Block blobs
• Append blobs
• Base blobs
• Snapshots
• Versions

Uses

• IF–THEN logic

Supports

• Move to Cool
• Move to Cold
• Move to Archive
• Delete

Filters

• Prefix
• Blob index tags
• Last modified time
• Creation time
• Last access time

Docs

• azure / storage / blobs / lifecycle management overview

7. Storage Security Model

Security layers

Encryption at Rest

Default

• Storage Service Encryption (AES-256)

Management Plane vs Data Plane

Management Plane

Storage account configuration

Controlled by Azure RBAC

Data Plane

Blobs

Files

Queues

Tables

Controlled by

• Access Keys
• SAS
• Entra ID

Access Keys

Full control

Two keys (rotation model)

Not least privilege

Shared Access Signature (SAS)

Scoped access

Time-limited

IP restricted

Protocol restricted

Microsoft Entra Authentication

Role-based access control

More secure

Recommended over keys

Docs

• azure / storage / common / storage auth overview

8. Azure Files Overview

Primary service

• Azure Files

Key characteristics

• Managed SMB/NFS file share
• True hierarchical file system
• Supports Windows, Linux, macOS
• Can mount as network drive

Unlike Blob

• Real file system
• NTFS permissions
• POSIX (NFS) support

Docs

• azure / storage / files / storage files introduction

9. Azure Files Protection

Snapshots

Entire share

Read-only

Incremental

Restore individual files or full share

Soft Delete

Protects deleted shares

Retention: 1–365 days

Does NOT protect individual file deletions

Docs

• azure / storage / files / storage files data protection overview
• 🔟 Identity-Based Authentication (Azure Files)

Options

• AD DS
• Entra Domain Services
• Entra Kerberos

Important

• Controls share-level access
• ❗ Does NOT replace NTFS ACL

Two layers

• Share-level RBAC
• File-level NTFS permissions

Docs

• azure / storage / files / storage files active directory overview
• 1️⃣1️⃣ Storage Utilities

Azure Storage Explorer (GUI)

Azure Storage Explorer

Visual interface

Uses AzCopy under the hood

Manage containers, shares, snapshots

AzCopy (CLI)

AzCopy

High-performance data transfer

Scriptable

Entra authentication supported

Used for automation and migration

Difference

• Storage Explorer = GUI
• AzCopy = Automation & scripting

Docs

• azure / storage / common / storage use azcopy v10
• 1️⃣2️⃣ Common Exam Pitfalls
• Soft delete protects individual files → False
• Snapshots are full copies → False
• Blob folders are real directories → False
• Lifecycle works on all storage types → False (Blob only)
• Identity-based auth replaces NTFS → False
• Access keys provide least privilege → False
• 1️⃣3️⃣ High-Yield Design Patterns for Exam
• Cost Optimization Pattern
• GPv2 account
• Lifecycle policies
• Cool -> Archive movement
• High Availability Pattern
• RA-GZRS
• Cross-region read access
• Secure Enterprise Pattern
• Entra ID authentication
• RBAC
• Disable key access
• Private endpoints
• Hybrid File Server Pattern
• Azure Files + AD DS
• NTFS ACLs
• Snapshots + Soft Delete
• 1️⃣4️⃣ Mental Model for Exam

Think in layers

• Storage Account
• → Performance
• → Redundancy
• → Security
• → Lifecycle
• → Data Protection
• → Identity
• → Utilities

Each exam question typically touches 2–3 of these layers simultaneously.

Final Takeaway

For exam success, master

• Storage account architecture
• Redundancy models
• Blob lifecycle + replication
• Management vs data plane security
• Azure Files authentication & protection
• Storage Explorer vs AzCopy differences

Azure Storage questions often test

Design decisions, not just definitions.

Azure App Service Plan — simplified, structured summary

What is an App Service Plan?

An Azure App Service Plan is the underlying compute + networking layer that runs your applications (like web apps, APIs, mobile backends).

Think of it like

• VMs + networking + scaling rules = App Service Plan
• Your App Services (apps) run on top of this plan
• Key concepts (easy mental model)
• Plan = infrastructure
• App = code running on that infrastructure
• Multiple apps can run on one App Service Plan (share resources).
• Pricing tiers (very important for exams)

The pricing tier determines

• VM size (CPU, RAM)
• Number of instances
• Features (autoscale, backups, networking, etc.)

Common tiers

• Free / Shared
• Multi-tenant, limited resources
• No SLA
• Basic
• Dedicated compute (but limited features)
• Standard
• Autoscaling, staging slots, backups
• Premium (v2/v3)
• Better performance, scaling, networking
• Isolated (App Service Environment)
• Fully isolated network + compute (single tenant)
• Types of hosting environments

1. Shared (Multi-tenant)

Apps share compute + network with other customers

Cheapest option

Lower performance/isolation

2. Dedicated

Dedicated VM compute for your apps

Network still shared

Most common production setup

3. Isolated (Single-tenant)

Dedicated compute and networking

Runs inside your VNet

Used for

• compliance
• security-sensitive apps
• enterprise workloads
• Region scope
• App Service Plan is tied to a single Azure region

Apps must be deployed in the same region as the plan

Scaling concepts (very important 🔥)

1. Scale UP (Vertical scaling)

Change pricing tier / VM size

Example

• S1 -> P1V3

Adds

• more CPU
• more RAM
• more storage
• more features

👉 Used when

• app needs more power per instance

2. Scale OUT (Horizontal scaling)

Increase number of instances

Example

• 1 instance -> 5 instances

Options

• Manual scaling
• Rule-based (CPU %, schedule, etc.)
• Automatic (Premium tiers)

👉 Used when

• traffic increases
• need high availability
• Important features by tier (exam focus)
• | Feature | Standard | Premium | Isolated |
• | --- | --- | --- | --- |
• | Autoscale | ✅ | ✅ | ✅ |
• | Staging slots | ✅ | ✅ | ✅ |
• | VNet integration | Limited | Advanced | Full |
• | Zone redundancy | ❌/Limited | ✅ | ✅ |
• | Private networking | ❌ | Partial | ✅ |
• Demo flow (what actually happened)
• Created App Service Plan
• Name: asp-prod-01
• OS: Linux
• Tier: Standard (S1)
• Explored pricing tiers
• Compared CPU, memory, features
• Reviewed scaling
• Scale UP -> change tier (more power)
• Scale OUT -> increase instances
• Observed limits
• Max instances (e.g., 10 for Standard)
• Policies can restrict scaling options
• Real-world decision factors

When choosing a plan, consider

• Compute
• CPU/memory needs
• workload type (light vs heavy)
• Traffic
• expected users
• need for autoscaling
• Networking
• public vs private access
• VNet integration required?
• Compliance/Security
• need isolation -> use Isolated tier
• Key exam takeaways 🚀
• App Service Plan = compute + scaling + networking
• Apps don’t define infrastructure, plans do
• Scale UP = bigger machine
• Scale OUT = more machines
• Multiple apps can share one plan
• Pricing tier controls features + performance
• Isolated tier = full network + compute isolation
• Reference documentation (for deeper study)
• Azure App Service overview and plans
• en us / azure / app service / overview hosting plans
• App Service scaling (up vs out)
• en us / azure / app service / manage scale up
• Autoscale rules and configuration
• en us / azure / azure monitor / autoscale / autoscale get started
• App Service Environment (Isolated tier)
• en us / azure / app service / environment / intro
• Quick revision cheat sheet (30 sec)
• Plan = infrastructure
• App = runs on plan

Tiers = Free → Basic → Standard → Premium → Isolated

Scale UP = change tier

Scale OUT = increase instances

Region-bound

Multiple apps can share plan

Isolated = single tenant + VNet

Azure App Service — simplified, structured summary

What is Azure App Service?

Azure App Service is a fully managed PaaS (Platform-as-a-Service) offering used to host:

Web apps (HTTP-based)

APIs

Mobile backends

Function apps

Containerized applications

👉 You focus on code, Azure manages

• infrastructure
• scaling
• patching
• load balancing
• Core architecture (easy mental model)
• App Service Plan -> infrastructure (VMs + scaling)
• App Service -> your app running on that infrastructure
• Multiple App Services can run on the same plan
• High availability design (very common pattern)
• Deploy multiple App Service instances

Azure automatically

• load balances traffic
• distributes across instances

👉 This ensures

• high availability
• fault tolerance
• scalability
• Under the hood (important for deep understanding)

1. Azure Resource Manager (ARM)

Receives deployment requests

Sends them to internal Azure services

2. Geo-controller

Global orchestrator

Decides

• where apps are deployed
• which region/scale unit to use

3. Scale unit (key concept 🔥)

A cluster of worker nodes (VMs)

Can host many App Services

Includes

• compute resources
• front-end proxy/load balancer

👉 Think of it as

• “a pool of servers running your apps”
• Scale unit components
• Worker nodes -> run your app code
• Front-end proxy -> routes traffic to workers
• Shared infrastructure -> depending on plan type
• Hosting models (very important for exam)

1. Multi-tenant (Shared / Dedicated plans)

Shared

Apps share compute + network with other customers

Cheapest, lowest isolation

Dedicated

Dedicated compute (your VM instances)

Still shares network layer

• Most common production setup

2. Single-tenant (Isolated / App Service Environment)

Dedicated compute + networking

Runs inside your VNet

No sharing with other customers

👉 Used for

• financial institutions
• strict compliance
• high-security workloads
• Networking capabilities

1. VNet Integration

App connects outbound to resources in a VNet

Example

• connect to database in private subnet

2. Private Endpoint

Enables inbound private access

App becomes accessible via private IP

3. Public endpoint (default)

App is internet-accessible

Can restrict using firewall rules

Security (important 🔐)

App Service has a public endpoint by default

You can

• restrict access via IP rules
• use Private Endpoint for private access only
• combine with VNet + firewall
• Multi-app & multi-subscription flexibility
• Multiple apps -> same plan
• Multiple plans -> same subscription
• Multiple subscriptions -> same tenant
• Even cross-tenant scenarios possible
• Very flexible architecture
• Load balancing (built-in)
• Automatic load balancing across instances
• No need to configure manually
• Containers support

App Service can

• pull images from registries (like ACR)
• run containerized apps
• Key exam takeaways 🚀
• App Service = PaaS hosting for web apps
• Runs on App Service Plan

Uses

• geo-controller
• scale units
• worker nodes

Supports

• multi-tenant (shared/dedicated)
• single-tenant (isolated)

Built-in

• load balancing
• scaling

Networking

• VNet integration (outbound)
• Private Endpoint (inbound)
• Default = public internet access
• Reference documentation (official)
• Azure App Service overview
• en us / azure / app service / overview
• App Service architecture & scaling
• en us / azure / app service / overview hosting plans
• Networking features (VNet, private endpoints)
• en us / azure / app service / networking features
• App Service Environment (isolated hosting)
• en us / azure / app service / environment / intro
• Quick revision cheat sheet (30 sec)
• App Service = PaaS for apps
• Plan = infrastructure
• Scale unit = cluster of servers
• Geo-controller = global orchestrator
• Multi-tenant = shared infra
• Isolated = dedicated infra + VNet
• Built-in load balancing
• Public by default -> secure with private endpoints

Here’s a clean, structured summary + deeper explanation of your transcript so you can quickly review and also build strong conceptual understanding.

📘 Azure App Service – Summary + Deep Dive

(Based on your transcript: )

🚀 1. What is Azure App Service?

Azure App Service is a Platform as a Service (PaaS) offering used to host web applications, APIs, and backend services.

Key idea

You deploy code, Azure manages

• Infrastructure
• OS patching
• Scaling
• Load balancing
• You focus on application, not servers.
• 🧱 2. Core Components

App Service

The actual web app instance

Runs your code (Python, .NET, Node.js, Java, PHP)

App Service Plan

Defines compute + networking resources

Includes

• CPU
• Memory
• Scaling limits
• Pricing tier

👉 Think

• App Service = Application
• App Service Plan = Infrastructure
• 🌐 3. Default Behavior

Every app gets a public URL

• <app name>.azurewebsites.net
• Must be globally unique
• 🧰 4. Supported Deployment Types

When creating an app, you can choose

• Code (most common) -> deploy source code
• Docker container -> run containerized apps
• Static web app -> frontend hosting
• ⚙️ 5. Key Features (Important for Exams + Real Use)
• 🧩 Managed Infrastructure
• No server management
• Fully abstracted (PaaS)
• 📈 Auto Scaling

Scale

• Up -> bigger VM (more CPU/RAM)
• Out -> more instances
• 🟢 High Availability
• Multiple instances -> load balanced automatically
• Built-in redundancy
• 🔄 Deployment Slots (VERY IMPORTANT)

Example

• production
• staging

Use cases

• Test new version safely
• Swap without downtime
• Rollback instantly
• 🔗 Integration Capabilities
• Microsoft Entra ID (authentication)
• Virtual Network (access backend services)
• On-prem systems (hybrid connectivity)
• 🔌 6. Networking Explained (Important Concept)

Default

• Public internet access

Integration (not hosting inside VNet)

• App Service can access resources inside VNet

Example

• App -> VM → Database

Advanced

• App Service Environment (ASE)
• Fully isolated inside VNet (not covered in basic exam)
• 🛠️ 7. Deployment Options

From portal or CI/CD

• GitHub Actions
• Azure DevOps
• Local Git
• Bitbucket
• External repositories
• 🧪 8. Demo Flow (What Happens Practically)
• Create Web App

Choose

• Runtime (Python, etc.)
• OS (Linux/Windows)
• Region
• App Service Plan auto-created
• Deploy app
• Access via URL

Manage via

• Deployment Center
• Scaling
• Networking
• Certificates

9. Key Concepts for Deep Understanding

Why App Service?

Problem it solves

No need to manage

• VMs
• OS updates
• Load balancers

App Service vs VM

| Feature | App Service | Virtual Machine |

| --- | --- | --- |

| Management | Fully managed | You manage OS |

| Scaling | Built-in | Manual |

| Use case | Web apps | Full control workloads |

App Service vs Containers

| Feature | App Service | Containers |

| --- | --- | --- |

| Simplicity | High | Medium |

| Flexibility | Limited | High |

| Best for | Standard apps | Microservices |

📚 10. Reference Documentation

For deeper study

Microsoft Docs

• en us / azure / app service

Deployment

• en us / azure / app service / deploy continuous deployment

Scaling

• en us / azure / app service / manage scale up

Networking

• en us / azure / app service / networking features
• 🧾 11. Quick Revision Cheat Sheet
• App Service = PaaS for web apps
• App Service Plan = compute + pricing
• Default -> public endpoint
• Supports multiple runtimes

Key features

• Scaling
• High availability
• Deployment slots
• CI/CD integration

Can integrate with

• VNet
• Entra ID
• No server management required

Describing Containers in Azure (and the ACR demo) — clean review summary

Core container concepts (non-Azure specific)

Dockerfile: the “recipe” that defines

• your app code
• dependencies/libraries
• runtime/config instructions needed to run it

Container image: the built artifact produced from the Dockerfile (a portable “package”). It’s not running yet—it’s like a VM image/template.

Container registry: a repository for storing and versioning images (e.g., Docker Hub, or Azure Container Registry).

Container host/runtime: where images are pulled and started as running containers (e.g., Docker host, Kubernetes, Azure services).

Why containers exist (the “works on my machine” problem)

Before containers: apps often failed elsewhere due to missing dependencies or config drift.

With containers: the image carries the dependencies + runtime expectations, so it runs consistently across environments.

What the Azure demo did (step-by-step, conceptually)

1. Create an Azure Container Registry (ACR)

ACR is Azure’s managed private registry: <registryname>.azurecr.io

Picked a pricing tier (Standard in the demo).

Chose networking defaults (public endpoint in the demo, but private is possible).

Important security note from the demo

Enabled Admin user (access keys) to simplify authentication for the lab. In real environments, you typically avoid admin user and prefer Entra ID/RBAC (more below). (Microsoft Learn)

2. Pull sample app code (Git clone)

Cloned a repo containing

• Python app (Flask)
• requirements.txt
• Dockerfile

3. Review the Dockerfile (what it’s doing)

Typical pattern shown

• Base image: python:3.8-slim
• WORKDIR /app
• COPY app + requirements into the container filesystem
• pip install -r requirements.txt
• EXPOSE 80
• CMD runs the Flask app

4. Build + push the image using ACR Tasks (no local Docker build needed)

Used az acr build to

• send the source context to ACR
• build remotely (ACR Tasks)
• push the resulting image into the registry

This is a common “cloud build” workflow and is part of ACR Tasks capabilities. (Microsoft Learn)

5. Verify the image exists in ACR repositories

After the build, the ACR Repositories blade shows something like

• sample/hostnameapp
• tag v1

6. Run a quick test execution from ACR

Used az acr run to run a container “on demand” (good for quick validation)

In the portal, this appears under Tasks → Runs (build run + run command history)

Deeper understanding & “exam-worthy” details

ACR authentication options (what to use when)

Common methods (best practice order in many orgs)

• Microsoft Entra ID + Azure RBAC (recommended for users/automation)
• Managed Identity (best for Azure resources pulling/pushing without secrets)
• Service principal (CI/CD scenarios where MI isn’t possible)
• Admin user (username/password) (easy for labs; generally avoid in production)

The “push/pull using Docker CLI” walkthrough shows ACR sign-in patterns and discusses authentication approaches. (Microsoft Learn)

RBAC roles you’ll see a lot

AcrPull: pull images

AcrPush: push + pull

Owner/Contributor: broader management (use sparingly)

These built-in roles are central to securing ACR access.

ACR Tasks vs local Docker build

Why ACR Tasks (az acr build) is useful

Build happens in Azure (repeatable environment)

No need for Docker installed on your machine/agent

Logs are captured, and runs are tracked

Fits CI/CD patterns well (Microsoft Learn)

Networking hardening (big in real projects)

Two common patterns

• Public endpoint (simple; restrict with firewall rules where possible)

Private Link / private endpoint (preferred in enterprise): access ACR privately from VNets, block public network access (Microsoft Learn)

Where you run the image after it’s in ACR

Once images are in ACR, you typically run them on

• AKS (Kubernetes)
• Azure Container Instances (ACI)
• App Service (Web App for Containers)
• other container platforms

Example: ACI can pull images from ACR as part of its workflow. (Microsoft Learn)

Quick mental model to remember

• Dockerfile -> Image → Registry → Host → Running container

In Azure demo terms

Dockerfile/code → built by ACR Tasks → stored in ACR → validated via az acr run → then typically deployed to AKS/ACI/App Service

Structured Summary + Deep Technical Understanding

Primary service

• Azure Virtual Machines

Related services

• Azure Virtual Network
• Azure Managed Disks
• Azure Network Security Group
• Azure Migrate

Official documentation

• VM overview: https://learn.microsoft.com/azure/virtual-machines/overview
• VM sizes: https://learn.microsoft.com/azure/virtual-machines/sizes
• Managed disks: https://learn.microsoft.com/azure/virtual-machines/managed-disks-overview
• Availability options: https://learn.microsoft.com/azure/virtual-machines/availability

1. What Is an Azure Virtual Machine?

An Azure VM is

• Infrastructure as a Service (IaaS) compute
• A cloud-hosted virtualized server
• Built on Azure’s hypervisor platform (based on Hyper-V)
• Deployed into an Azure Virtual Network

It replaces on-prem hypervisor solutions like

• VMware
• Hyper-V
• Physical servers

Key difference from on-prem

You manage

• OS
• Applications
• Configuration

Azure manages

• Physical hardware
• Hypervisor layer
• Datacenter infrastructure

2. VM Core Architecture Components

A VM consists of several associated resources

Compute Resource

The VM itself (CPU + Memory)

Operating System Image

Examples

• Ubuntu
• Red Hat
• Windows Server
• CentOS

Marketplace provides ready-made images.

Storage (Disks)

Modern Azure uses

• Azure Managed Disks

Types

• OS Disk
• Data Disks
• Premium SSD
• Standard SSD
• Standard HDD

Important

Managed disks replaced unmanaged disks (which used storage accounts + page blobs).

Networking

VM networking includes

• Network Interface (NIC)
• Private IP
• Optional Public IP
• Subnet
• Virtual Network

Security controlled by

• Azure Network Security Group

3. Common VM Use Cases

• Domain Controllers (Active Directory)

Run AD DS in VMs.

• Web Servers

Apache

Nginx

IIS

• Database Servers

MySQL

MariaDB

SQL Server

• Network Appliances

Firewalls

VPN appliances

Load balancers

• N-tier Architecture

Deploy

• Frontend in one subnet
• Application tier in another
• Database tier in another

4. VM Deployment Properties (Exam Important)

When deploying a VM, you configure

• | Property | Purpose |
• | --- | --- |
• | Name | Logical resource name |
• | Region | Azure datacenter location |
• | Availability | Zone / Set / None |
• | Size | CPU, Memory, Network |
• | Image | OS selection |
• | Disks | OS + Data disks |
• | Networking | VNet + Subnet + IP |
• | Authentication | SSH / Password / RDP |

5. VM Families Explained

Choosing the correct VM family is critical.

General Purpose

Balanced CPU-to-memory

Use cases

• Dev/Test
• Small web apps
• Light workloads

Compute Optimized

High CPU-to-memory

Use cases

• Web servers
• Batch processing
• Network appliances

Memory Optimized

High memory-to-CPU

Use cases

• Relational databases
• Caching
• In-memory analytics

Storage Optimized

High disk throughput

Use cases

• OLTP databases
• Big data
• Data warehousing

GPU

Graphics acceleration

Use cases

• Video rendering
• AI training
• Deep learning
• Game servers

HPC (High Performance Compute)

Maximum performance

Use cases

• Scientific computing
• Geophysics
• Advanced simulations

Docs

• azure / virtual machines / sizes

6. Availability Options (Important for High Availability)

During deployment you can choose

• No infrastructure redundancy
• Availability Set
• Availability Zone
• VM Scale Set

Note

Not all regions support Availability Zones.

Docs

• azure / virtual machines / availability

7. Deployment Walkthrough Summary (Demo Recap)

Steps performed

• Create Virtual Machine
• Choose Ubuntu 20.04 LTS
• Select VM size (2 vCPU, 8GB RAM)
• Configure authentication (password)
• Select disk type (Premium SSD)

Auto-create

• Virtual Network
• Subnet
• Public IP
• NIC
• Review + Create
• Deploy

After deployment

• VM is running
• Public and Private IP assigned
• SSH connectivity available
• Disk and networking configurable

8. Post-Deployment Management Options

After creation, you can

• Start / Stop VM
• Restart VM
• Resize VM
• Change disk size
• Modify networking
• Add data disks
• Configure NSG rules
• Connect via SSH or RDP

Important

Stopping VM without deallocating still incurs compute charges.

9. VM Networking Concepts

If VM has

• Public IP -> Accessible over internet
• Private IP only -> Internal access only

NSG rules control inbound traffic

• SSH (22)
• HTTP (80)
• HTTPS (443)
• RDP (3389)
• 🔟 Migration to Azure

Existing workloads can be migrated using

• Azure Migrate

Supports

• VMware
• Hyper-V
• Physical servers

Docs

• azure / migrate / migrate services overview
• 1️⃣1️⃣ Cost Considerations

VM pricing depends on

• VM size
• Disk type
• Region
• Running vs stopped
• Public IP
• Network egress

Exam Tip

Compute cost stops only when VM is deallocated.

1️⃣2️⃣ Key Exam Concepts to Remember

• Azure VMs are IaaS
• Managed disks are default
• VM deployed inside a VNet
• VM requires NIC
• VM size determines CPU & memory
• VM families optimized for workloads
• Availability Zones increase resiliency
• Public IP enables internet access
• NSGs control traffic
• Azure manages hypervisor

1️⃣3️⃣ Mental Model

Think of Azure VM as

• Cloud-based server rack
• → Hypervisor managed by Azure
• → You manage OS and applications

It’s your datacenter server — just hosted in Azure.

1️⃣4️⃣ Final Takeaways

• Azure VMs provide flexible IaaS compute
• Multiple VM families for workload optimization
• Networking and storage are separate Azure resources
• Managed disks simplify storage
• Public IP enables remote connectivity
• Availability options improve uptime
• Azure Migrate helps lift-and-shift
• VM management continues after deployment

Structured Summary + Deep Technical Understanding

Primary service

• Azure Virtual Machines

Related services

• Azure Virtual Network
• Azure Network Security Group
• Azure Managed Disks
• Nginx

Official documentation

• VM management overview: https://learn.microsoft.com/azure/virtual-machines/manage-vm
• Resize VM: https://learn.microsoft.com/azure/virtual-machines/sizes/resize-vm

NSG rules: https://learn.microsoft.com/azure/virtual-network/network-security-groups-overview

Move resources: https://learn.microsoft.com/azure/azure-resource-manager/management/move-resource-group-and-subscription

1. VM Management Overview

Once a VM is deployed, administrators must manage it just like on-premise servers.

Common VM management operations include

• Authentication and remote access
• Resizing compute resources
• Managing networking
• Managing storage disks
• Installing applications/services
• Diagnostics and monitoring
• Moving resources between environments

These operations are similar to on-prem virtualization platforms like VMware or Hyper-V but are performed through Azure management tools.

2. Authentication and Remote Access

To manage a VM you must connect to it.

Linux VM

Connection method

• ssh username@public-ip

Uses

• SSH keys (recommended)
• Password authentication
• Windows VM

Connection method

• RDP (Remote Desktop Protocol)

Port

• 3389

Important concept

Remote access requires the correct inbound network rules.

3. VM Networking Management

Each VM is connected to

• Virtual Network
• Subnet
• Network Interface (NIC)
• Optional Public IP

Traffic filtering is controlled using

• Azure Network Security Group

Example NSG rules

• | Service | Port |
• | --- | --- |
• | SSH | 22 |
• | HTTP | 80 |
• | HTTPS | 443 |
• | RDP | 3389 |

Example

Allow SSH rule to connect to Linux VM.

4. VM Storage Components

Azure VMs use

• Azure Managed Disks

Disk types attached to VM

• OS Disk

Contains the operating system.

Temporary Disk

Ephemeral disk used for temporary storage.

Data Disk

Used for application data or databases.

Important exam concept

Temporary disk data is lost during host migration or restart.

Docs

• azure / virtual machines / managed disks overview

5. Resizing a Virtual Machine

One common management task is resizing the VM.

Reasons to resize

• Increase CPU
• Increase RAM
• Reduce cost
• Handle increased workload

Resize options depend on

• Region capacity
• VM size family
• Current VM state
• Important Behavior

Resizing may require

• VM restart
• Temporary downtime
• Stopping the VM to access more size options

Example impact

Running services may become unavailable temporarily.

Docs

• azure / virtual machines / sizes / resize vm

6. VM Deployment Using Azure CLI (Demo)

VM was created using

• az vm create

Key parameters used

• VM name
• Resource group
• OS image
• Security configuration
• SSH key authentication

Example concept

If an incorrect image name is used, Azure CLI returns a list of supported images.

7. SSH Authentication Using Key-Based Access

After VM creation

SSH keys are generated automatically.

Connection command

• ssh <public-ip>

Authentication happens using the stored private key in Cloud Shell.

Key advantage

More secure than passwords.

8. Installing Applications on the VM

After connecting via SSH

Example commands used

• sudo apt update
• sudo apt install nginx -y

This installs

• Nginx

To verify service status

• sudo systemctl status nginx

9. Allowing Web Traffic to the VM

To access the web server

An inbound NSG rule must allow HTTP.

Rule created

• Port: 80
• Protocol: TCP
• Source: Any (for demo purposes)

Once rule applied

Access via browser

• <public ip>

The Nginx default page confirms the web server is running.

🔟 VM Connectivity Troubleshooting

If SSH fails

Check

1. NSG rule allows port 22

2. VM is running

3. Public IP exists

4. VM not currently resizing

5. Correct username and key

Example issue shown in demo

SSH failed temporarily because VM was resizing.

1️⃣1️⃣ Moving a Virtual Machine

Azure supports moving resources between

• Resource Groups
• Subscriptions
• Regions (with restrictions)

Important limitation shown

VM with Trusted Launch enabled cannot be moved across regions.

Trusted Launch provides

• Secure Boot
• vTPM protection
• Integrity validation

Docs

• azure / virtual machines / trusted launch
• Moving Between Resource Groups

Supported operation.

Steps

1. Select VM and related resources

2. Choose Move → Move to another resource group

3. Validate dependencies

4. Complete move operation

1️⃣2️⃣ VM Architecture Overview

Typical architecture

• VM
• │
• ├─ Managed OS Disk
• ├─ Data Disk(s)
• ├─ NIC
• │ ├─ Private IP
• │ └─ Optional Public IP
• │
• └─ Network Security Group

VM runs inside

• Azure Virtual Network
• 1️⃣3️⃣ Diagnostics and Monitoring

VM diagnostic features include

• Boot diagnostics
• Performance metrics
• Activity logs
• Guest-level diagnostics

These help administrators troubleshoot

• Boot failures
• Network connectivity
• Resource usage
• Application issues

Docs

• azure / virtual machines / boot diagnostics
• 1️⃣4️⃣ Key Exam Concepts

Important concepts to remember

• VM resizing may require restart
• SSH/RDP requires NSG rule
• Managed disks store VM data
• Temp disk data is not persistent
• NSG controls inbound traffic
• VM can be resized for performance or cost optimization
• Resource moves may have restrictions
• Trusted Launch prevents some migration operations
• 1️⃣5️⃣ Mental Model

Think of Azure VM management as

Cloud version of managing a physical server

• Connect remotely
• Install software
• Adjust hardware resources
• Configure networking
• Secure access

But Azure handles the underlying infrastructure.

1️⃣6️⃣ Final Takeaways

• Azure VMs require ongoing management after deployment
• SSH or RDP enables remote administration
• NSGs control traffic access
• VM resizing helps scale workloads
• Applications can be installed directly on the VM
• Storage consists of OS, temp, and data disks
• Moving VMs has platform limitations
• Trusted Launch improves security but limits mobility

Managing Azure VM disks — summary (easy to review)

1. What an Azure “disk” is

An Azure VM uses virtual hard disks (VHDs) presented to the guest OS as block devices.

The common disk categories you manage on a VM:

OS disk: holds the operating system.

Temporary disk: ephemeral storage (not durable; used for swap/temp depending on OS and config).

Data disks: durable disks you attach for app/data (databases, file shares, logs, etc.).

2. Managed vs. unmanaged disks (important exam + real-world difference)

Managed disks (modern/default): Azure manages the underlying storage accounts and durability/availability aspects for you. You manage a first-class resource called Disk (RBAC, snapshots, backup integration, etc.).

Unmanaged disks (legacy/classic): VHDs live in a storage account you manage, increasing operational overhead and making scaling/availability management more DIY. (Most environments should avoid new unmanaged designs today.)

Managed disk types and the ability to change disk performance tiers are documented under Azure Disk Storage. (Microsoft Learn)

3. Disk performance tiers (what to choose and why)

Azure Disk Storage offers tiers optimized for different workloads:

Ultra Disk: highest performance/lowest latency (heavy OLTP, extremely IO-sensitive workloads). (Microsoft Learn)

Premium SSD / Premium SSD v2: production performance workloads. (Microsoft Learn)

Standard SSD: dev/test, web servers, lighter enterprise workloads. (Microsoft Learn)

Standard HDD: lowest cost; backup/non-critical workloads. (Microsoft Learn)

Key constraint: disk throughput/IOPS can be limited by VM size, so “fast disk + small VM” may still bottleneck (common gotcha for databases).

What the demo actually did (step-by-step, conceptually)

A) Create a managed disk resource

In the portal:

Create Managed Disk

Pick region, size (GB), and tier (Premium/Standard/etc.)

Choose redundancy (commonly LRS for many single-region patterns; higher redundancy depends on scenario)

Review encryption settings (platform-managed by default; CMK optional)

Disk tiers and management are covered in Azure Disk Storage docs. (Microsoft Learn)

B) Attach the disk to an existing VM

Portal path (typical):

VM → Disks → Attach existing disk (or create+attach)

Attaching makes the disk visible to the guest OS, but the disk is empty/unformatted, so the OS won’t “use” it until you partition + format + mount it.

C) Initialize the disk inside Linux (partition, format, mount)

Typical Linux workflow:

Identify the new device (often /dev/sdc, /dev/sdd, etc.)

Partition it

Create a filesystem

Mount it to a directory (optionally persist via /etc/fstab)

Microsoft’s Linux VM guidance shows the exact idea (use lsblk, partition, mkfs, mount). (Microsoft Learn)

Example commands (your transcript used parted + mkfs.xfs, which is very common):

lsblk

Partition (example with parted; replace /dev/sdd with your new disk)

sudo parted /dev/sdd --script mklabel gpt mkpart primary 0% 100%

Format (XFS example)

sudo mkfs.xfs -f /dev/sdd1

Create mount point + mount

sudo mkdir -p /datadrive

sudo mount /dev/sdd1 /datadrive

Verify

lsblk

The architecture-center guide demonstrates the same lifecycle: discover disk → partition → create filesystem → mount. (Microsoft Learn)

Important troubleshooting insight from the demo

“Permission denied (publickey)” when SSH’ing

That happened because the VM was created with SSH key auth, but the user tried to connect without the right private key (or from an environment that didn’t have it available).

Common fixes:

Use the correct private key (best).

Or reset credentials / re-inject SSH keys using supported Azure mechanisms (commonly via VM agent/extension tooling). A Microsoft sample shows using the VMAccess extension to add/modify users/keys on Ubuntu. (Microsoft Learn)

If reset operations fail, a frequent root cause is VM agent / extension health (walinuxagent, extension failures, etc.). (Microsoft Learn)

Deeper understanding + best practices (exam-friendly)

1. Plan disks around the workload

Databases: isolate data/log/temp onto separate disks when needed; pick Premium/Ultra when latency matters.

Apps/logs: standard SSD often fine for many internal apps.

“Cheap storage” for non-critical: standard HDD.

2. Mount persistence

Mounting is temporary across reboot unless you add an /etc/fstab entry (Linux). In production, always validate:

correct UUID/label usage

boot doesn’t hang if disk missing (use nofail where appropriate)

3. Security & encryption posture

Storage encryption at rest is typically on by default for Azure-managed storage; for stricter compliance, consider customer-managed keys (CMK) (often with Key Vault) for disks depending on requirements. (Microsoft Learn)

4. “Shared disk” is a special case

You saw a “shared disk” toggle in the UI. Shared disks are for cluster-style scenarios (multiple VMs attaching to the same disk) and come with design constraints—don’t enable it unless you’re implementing a supported clustering pattern.

Reference documentation (official / primary)

Azure Disk Storage overview and disk types/performance tiers (Microsoft Learn)

Linux VM guidance showing data-disk partition/format/mount workflow (Microsoft Learn)

VMAccess extension sample (adds/modifies users/SSH keys on Ubuntu) (Microsoft Learn)

Troubleshooting reset/password/agent/extension issues (Microsoft Q&A) (Microsoft Learn)