1. Azure Fundamentals

The global infrastructure and the governance hierarchy (management groups, subscriptions, resource groups) that every Azure deployment is built on - plus the mental model that makes the rest of the platform predictable.

What Azure is

Microsoft Azure is Microsoft's public cloud: on-demand compute, storage, networking, databases, data, and AI services delivered from Microsoft-operated regions, consumed over Microsoft's global network, and billed by usage. Its distinctive strengths for enterprises are deep Microsoft ecosystem integration (Entra ID / Active Directory, Windows Server, SQL Server, Microsoft 365), strong hybrid tooling (Azure Arc, Azure Stack, ExpressRoute), and a mature governance model (management groups, Azure Policy, landing zones). If you come from traditional Windows/SQL/AD infrastructure, much of Azure will feel familiar; the biggest early shift is the resource hierarchy and that identity lives in Entra ID, separate from Azure resource access (RBAC).

Azure global infrastructure

The governance hierarchy

• Microsoft Entra tenant - the identity boundary (users, groups, apps). One tenant can hold many subscriptions. Identity (Entra) is separate from resource access (Azure RBAC) - a crucial distinction (section 2).
• Management groups - a hierarchy above subscriptions for applying RBAC and Azure Policy at scale (e.g. a Platform MG and a Landing Zones MG under the root). Can nest.
• Subscriptions - the unit of billing, quota/limits, and deployment. Also a strong isolation and blast-radius boundary. Large enterprises use many subscriptions (per app/environment/BU).
• Resource groups - a lifecycle/management container for resources that share a lifecycle; RBAC, locks, and deletion apply at this level. A resource belongs to exactly one RG.
• Azure Resource Manager (ARM) - the control-plane API/service for all deployments and management; ARM templates and Bicep are its native IaC languages.

The Azure mental model

ARM, Bicep, and the tools

Azure Policy and resource locks

• Azure Policy - define, assign, and enforce rules (deny, audit, deployIfNotExists, modify) at MG/subscription/RG scope, inheriting down. Common: allowed regions, allowed SKUs, require tags, deny public IPs/public storage, require diagnostic settings. Initiatives bundle policies (e.g. a regulatory baseline).
• Resource locks - CanNotDelete or ReadOnly locks on a subscription/RG/resource to prevent accidental deletion/changes (e.g. lock the hub network and prod databases).

Tags

Tags are key/value metadata on resources, resource groups, and subscriptions - used for cost attribution (they flow into Cost Management and billing exports), organization, and automation. Tags are not inherited by default (a resource does not automatically get its RG's tags), though Azure Policy can enforce/inherit them.

Designing the hierarchy & landing zones

2. Identity and Access Management

Microsoft Entra ID and Azure RBAC - the two different systems that decide who exists and who can do what - plus managed identities, PIM, Conditional Access, and a troubleshooting model. This is where most Azure access issues and security incidents originate.

Entra ID roles vs Azure RBAC roles (the critical distinction)

Principals (who can be granted access)

Managed identities: system- vs user-assigned

Azure RBAC: roles and scope

• Built-in roles - Owner (full + manage access), Contributor (full except manage access), Reader, plus hundreds of granular roles (e.g. Virtual Machine Contributor, Storage Blob Data Reader). Prefer the narrowest built-in role.
• Custom roles - compose specific actions/dataActions when no built-in role fits without over-granting.
• Role assignment = role + principal + scope. Scope is MG / subscription / RG / resource; assignments inherit downward and are additive.
• Deny assignments - explicitly block actions regardless of role (used by Azure-managed features like Blueprints/managed apps); evaluated before allows.
• Control-plane vs data-plane - some roles govern management (create/delete a storage account) vs data (read blobs). A Contributor on a storage account can't necessarily read the blobs without a data role - a frequent surprise.

Privileged Identity Management & Conditional Access

Real RBAC / identity scenarios

Common Azure IAM mistakes

Azure access troubleshooting mental model

When access fails (or unexpectedly works), walk the layers in order:

az role assignment list --assignee <objectId> --all -o table
az account show     # which tenant/subscription am I in?
az provider show -n Microsoft.Sql --query registrationState

3. Networking Deep Dive

Virtual Networks, NSGs vs Azure Firewall, Private Endpoint vs Service Endpoint, hub-and-spoke, hybrid connectivity, and Private DNS - plus the traffic-flow reasoning you need to design and debug real Azure networks.

Virtual Network and CIDR planning

• A VNet is regional with one or more address spaces; subnets partition it. Azure reserves 5 IPs per subnet (first 4 + last).
• Some services want dedicated/delegated subnets (Azure Firewall needs AzureFirewallSubnet, gateways need GatewaySubnet, Bastion needs AzureBastionSubnet, App Gateway its own subnet). Plan these in advance.
• CIDRs must not overlap with peered VNets or on-premises. Overlap is the #1 cause of hybrid that "connects but won't route."
• Plan generously: leave room for growth, gateway/firewall/bastion subnets, and AKS (which consumes many IPs with Azure CNI).

Network Security Groups & Application Security Groups

• NSG - stateful allow/deny rules on source/dest, port, protocol, evaluated by priority (lower wins). Attach to a subnet and/or a NIC; both apply. Default rules allow intra-VNet and deny inbound from internet.
• Application Security Group (ASG) - a named group of NICs you reference in NSG rules instead of IPs, so rules read "web-asg → db-asg on 1433" and update automatically as VMs scale.
• Service tags - Microsoft-maintained IP groups (e.g. Storage, Sql, AzureMonitor, Internet) you use in rules instead of hardcoding ranges.

Routes, UDRs, and internet egress

• System routes handle intra-VNet, peering, and a default route to the internet. User Defined Routes (UDRs) in a route table override them - e.g. force 0.0.0.0/0 through the Azure Firewall (forced tunneling / centralized egress).
• NAT Gateway - the recommended way to give a subnet scalable, stable outbound internet (SNAT) without per-VM public IPs. Outbound only.
• Public IPs (Standard SKU, zone-redundant) for inbound-facing resources; avoid on workload VMs - use a load balancer / Bastion / firewall instead.
• Default outbound access is being retired - new VMs should have an explicit outbound method (NAT Gateway, LB outbound rule, or firewall). Don't rely on implicit outbound.

Azure Firewall & Firewall Manager

Azure Firewall is a managed, highly-available, stateful network firewall (Standard/Premium; Premium adds TLS inspection, IDPS, URL filtering). Placed in the hub VNet with spoke UDRs pointing at it, it centralizes egress control (FQDN + network rules), DNAT for inbound, and logging. Firewall Manager centrally manages firewall policies across hubs (incl. Virtual WAN secured hubs).

Private Endpoint vs Service Endpoint (the constant confusion)

VNet peering & hub-and-spoke

• VNet peering (regional or global) connects two VNets privately over the backbone. Crucially, peering is not transitive: spoke A peered to hub H and spoke B peered to H cannot reach each other unless you route through a hub appliance (Azure Firewall/NVA) with UDRs and "allow forwarded traffic".
• Hub-and-spoke - a central hub VNet (firewall, gateways, DNS, Bastion) peered to workload spokes; spokes route egress and cross-spoke traffic through the hub firewall.
• Virtual WAN - a Microsoft-managed hub-and-spoke at scale (managed hubs, integrated firewall, any-to-any transit, branch/VPN/ExpressRoute) - use it instead of hand-built hubs for large/global topologies.

Hybrid connectivity: VPN Gateway and ExpressRoute

ExpressRoute Global Reach connects on-prem sites to each other through Azure. Common pattern: ExpressRoute primary + VPN backup. Gateway SKU determines bandwidth and features - size it deliberately (a frequent bottleneck).

Azure DNS & Private DNS

• Azure DNS public zones for internet-facing names; Private DNS zones for internal resolution, linked to VNets (with optional auto-registration).
• Private Endpoints depend on Private DNS zones resolving the privatelink.* FQDNs to the private IPs.
• Azure DNS Private Resolver - a managed resolver for hybrid DNS (inbound/outbound endpoints + forwarding rulesets) so on-prem can resolve Azure private names and vice-versa, without running DNS VMs.

How traffic flows in Azure

1. Destination inside the VNet (or a peered VNet)? Routes over the backbone - only NSG rules apply.
2. Outside? The effective route table (system + UDRs) picks the next hop: internet (via NAT Gateway / public IP), the firewall/NVA (if a UDR forces it), the VPN/ExpressRoute gateway, or a peering.
3. NSGs (subnet + NIC, by priority) must allow it - remember default deny-inbound-from-internet.
4. For private PaaS: Private Endpoint + correct Private DNS resolution, or Service Endpoint with the public FQDN.

Debugging is almost always: what do effective routes say? what do effective NSG rules say (both directions)? does DNS resolve to the right (private) IP?

Reference diagrams

Hub-and-spoke with centralized egress

Private Endpoint pattern

Network Watcher

Networking troubleshooting

Azure networking gotchas

4. Compute Deep Dive

Azure Virtual Machines (series, disks, placement, HA), Scale Sets, Spot, images, and the managed/serverless options (App Service, Functions, Container Apps) - how to choose, place, scale, and operate compute on Azure.

VM series and families

Availability Zones, Availability Sets, and Scale Sets

Spot VMs and dedicated hosts

Images, Compute Gallery, and managed disks

• Marketplace/platform images and custom images; the Azure Compute Gallery versions and replicates images across regions for scale.
• Managed disks: Standard HDD, Standard SSD, Premium SSD, Premium SSD v2 (independently tunable IOPS/throughput/size), and Ultra Disk (highest performance, sub-ms). Ephemeral OS disks live on the host (fast, free, but lost on deallocate - stateless only).
• Snapshots and disk encryption (platform-managed keys, customer-managed keys via Key Vault, or Azure Disk Encryption/host-based).

Access and management

• Azure Bastion - browser-based RDP/SSH to VMs with no public IP and no exposed 3389/22, gated by RBAC. The secure default for admin access.
• Serial console + boot diagnostics for out-of-band recovery.
• VM extensions (Custom Script, DSC), Run Command for ad-hoc commands, Azure Monitor Agent for telemetry.
• Update Manager for patch orchestration; Azure Arc to manage on-prem/other-cloud servers with the same tooling (policy, monitoring, extensions).

App Service, Functions, Container Apps

Choosing VM families by workload

Operational guidance

5. Storage Deep Dive

Managed Disks, Blob Storage, Azure Files, and NetApp Files - their performance, redundancy (LRS/ZRS/GRS/GZRS), tiers, and the decision of which to use for databases, shared filesystems, backups, archives, and data lakes. Plus Azure Backup and Site Recovery.

Managed Disks

Blob Storage

• A storage account holds blob containers (plus optionally Files/Queues/Tables). Blobs come in access tiers: Hot (frequent), Cool (~30-day), Cold (~90-day), Archive (offline, cheapest, must be rehydrated before reading - hours).
• Lifecycle management auto-moves/deletes blobs by age/access; versioning + soft delete protect against accidental change/delete; immutable storage (time-based/legal hold) gives WORM compliance; object replication copies between accounts/regions.
• Data Lake Storage Gen2 = a storage account with hierarchical namespace enabled (real directories, POSIX ACLs) for analytics - covered in section 11.
• Access: prefer Entra ID + RBAC data roles + managed identity. SAS tokens (account/service/user-delegation) grant scoped, time-boxed access; stored access policies let you revoke them. Storage account keys are all-powerful - avoid distributing them.

Redundancy: LRS, ZRS, GRS, GZRS

Azure Files, File Sync, and NetApp Files

• Azure Files - managed SMB and NFS shares (Standard on HDD, Premium on SSD). Mount from VMs, on-prem, or containers. Identity-based auth (Entra/AD) for SMB.
• Azure File Sync - cache Azure Files on on-prem Windows servers with cloud tiering (hybrid file access).
• Azure NetApp Files - high-performance, low-latency enterprise NAS (NFS/SMB) for demanding workloads: SAP, HPC, large shared filesystems, and Oracle datafiles over NFS. Separate service, higher performance/cost.

Azure Backup and Azure Site Recovery

When to use which

Storage gotchas

6. Database Services Deep Dive

Azure's database portfolio - Azure SQL (Database / Managed Instance / on VM), PostgreSQL, MySQL, Cosmos DB, Cache for Redis, and the analytics stores - what each manages, how HA/DR/backup/patching differ, how to choose, and what changes for a DBA coming from SQL Server or Oracle.

The portfolio at a glance

Service deep dives

Database service decision table

Connectivity & security

• Private Endpoint (or VNet injection for MI/Flexible Server) is the production default - disable public network access. Plan the Private DNS zone (privatelink.database.windows.net, etc.).
• Entra authentication + managed identity - apps authenticate to Azure SQL/Postgres/MySQL via Entra tokens (no passwords in config). Prefer this over SQL logins.
• Encryption: TDE (transparent data encryption, on by default; customer-managed keys via Key Vault), Always Encrypted for column-level protection from even DBAs, TLS in transit.
• Microsoft Defender for SQL - vulnerability assessment + threat detection; Query Performance Insight + automatic tuning for performance.

How HA, DR, backup, and patching differ

Azure database gotchas for Oracle DBAs

Enterprise examples

7. Load Balancing and Traffic Management

The four Azure load-balancing services - Load Balancer (L4), Application Gateway (L7 regional), Front Door (L7 global), and Traffic Manager (DNS) - when to use each, how they are assembled, and how to debug the classic unhealthy-backend and DNS failures.

The four load-balancing services

When to use which

Application Gateway anatomy + WAF

• Components: frontend IP, listener (port/protocol + cert), rules (path/host routing), HTTP settings (backend port/protocol, cookie affinity, probe), backend pool (VMSS/NICs/App Service/IPs), health probe, and WAF policy.
• SSL: termination at the gateway (offload) or end-to-end (re-encrypt to backend). Manage certs via Key Vault integration.
• WAF - OWASP core rule set + custom rules, geo/rate limiting; run in Detection mode first, then Prevention.

Front Door

Front Door is the global L7 entry point: anycast frontend, edge TLS + caching/CDN, WAF at the edge, and health-based global routing/failover across regional backends. Use it for internet-facing apps that need low latency worldwide and automatic region failover. Managed certificates auto-provision once DNS points at the Front Door endpoint.

Load balancing troubleshooting

az network application-gateway show-backend-health -g RG -n APPGW -o table

8. Security Deep Dive

Defense in depth on Azure: identity (Entra, PIM, Conditional Access), governance (Azure Policy, locks), network (NSG, Firewall, Private Link, DDoS), data (Key Vault, encryption), and detection (Defender for Cloud, Sentinel) - plus how to secure subscriptions, storage, VMs, and databases, ending in a production checklist.

Azure shared responsibility model

Microsoft secures the infrastructure (physical, host, network fabric, and managed-service internals). You own: identity and access (Entra + RBAC), data classification and access, network exposure and firewall, key management choices, workload/OS security (IaaS/AKS nodes), secure configuration, and monitoring/response. The higher up the managed stack (VM → AKS → Azure SQL → App Service/Functions), the more Microsoft handles - but data, identity, and configuration always remain yours.

The control layers

Key Vault, Managed HSM, and encryption

• Key Vault - store keys, secrets, and certificates; workloads read them via managed identity + RBAC (or access policies). Managed HSM for FIPS 140-2 Level 3 single-tenant HSM keys.
• Encryption at rest - on by default (platform keys); use customer-managed keys (CMK) in Key Vault for storage/disks/databases where you need key control and the "disable key" switch.
• Always Encrypted / TDE for databases; TLS everywhere in transit.
• Turn on Key Vault soft-delete + purge protection so keys/secrets can't be permanently destroyed by mistake or malice.

Defender for Cloud & Sentinel

How to secure specific things

Production Azure security checklist

• Human access via groups; MFA enforced via Conditional Access; risky sign-ins blocked (Identity Protection).
• Privileged roles (Owner, User Access Admin, Global Admin) eligible via PIM, not permanent; approvals + audit on.
• Two protected, monitored break-glass accounts (excluded from lock-out policies, alerted on every sign-in).
• No basic Owner/Contributor at subscription/MG for daily work; least-privilege built-in roles at RG/resource.
• Workloads use managed identities; app secrets minimized, rotated, and in Key Vault.
• Preventive Azure Policy: deny public IPs, deny public blob access, allowed regions/SKUs, require diagnostic settings + tags.
• Resource locks (CanNotDelete) on hub network, Key Vault, and production data.
• Databases and PaaS on Private Endpoints; public network access disabled; no public database endpoints.
• Public HTTP behind Front Door/App Gateway + WAF; DDoS Protection on public frontends; backends private.
• Sensitive data encrypted with CMK in Key Vault (soft delete + purge protection on).
• Diagnostic settings + Activity Log centralized to a Log Analytics workspace; Sentinel ingesting.
• Defender for Cloud plans enabled across the management group; secure score tracked.
• Alerts on RBAC/PIM changes, new app secrets, public exposure, Key Vault access anomalies.
• Budgets + quotas as guardrails; consistent tags for attribution.
• Backups immutable (vault soft-delete/immutability); DR tested incl. CMK key availability in the DR region.

Common security mistakes

9. Observability, Monitoring, and Operations

Azure Monitor (metrics, logs, alerts), Log Analytics + KQL, Application Insights, and the operations tooling - what to monitor per service, how to build useful alerts without noise, and how to centralize logs across subscriptions.

The observability stack

What to monitor per area

Building useful alerts

• Alert on symptoms users feel (5xx, unhealthy backends, DB down, latency), not only causes.
• Use appropriate aggregation (avg/percentile) and an evaluation window + frequency to avoid flapping.
• Use log alerts (KQL) for things metrics can't express; metric alerts for fast numeric thresholds; activity-log alerts for governance events.
• Route by severity via action groups: Sev0/1 → page; Sev2/3 → ticket/Teams; info → dashboard.
• Consider dynamic thresholds (ML baselines) for noisy signals, and Resource Health alerts for platform issues.

Example alerts to implement

Centralizing logs across subscriptions

Use a shared Log Analytics workspace (in the management subscription) and enforce diagnostic settings across all resources via Azure Policy (deployIfNotExists) so every subscription sends logs there. Route the Activity Log too, and connect the workspace to Sentinel for security analytics. This gives cross-subscription visibility and satisfies retention/compliance without per-resource setup.

# KQL: top VMs by CPU over the last hour
InsightsMetrics
| where Namespace == "Processor" and Name == "UtilizationPercentage"
| summarize avg(Val) by Computer, bin(TimeGenerated, 5m)
| top 20 by avg_Val desc

Operations tooling

• Update Manager for OS patch orchestration/compliance; Change Tracking & Inventory for drift; Automation Account for runbooks.
• Azure Arc to bring on-prem/other-cloud servers, Kubernetes, and data services under the same monitoring, policy, and update tooling.
• Defender for Cloud recommendations and Advisor for security/reliability/cost/performance guidance; Cost Management exports for spend (section 14).

10. Containers, Kubernetes, and Cloud Native

AKS, Container Apps, and the serverless / event-driven building blocks (Functions, Event Grid, Service Bus, Event Hubs, Logic Apps) - when to use each, how networking and identity work for containers, and reference patterns.

The cloud-native services

AKS deep dive

• Node pools: a system node pool (runs cluster-critical pods) and one or more user node pools (your workloads). Use Spot user pools for fault-tolerant work; scale per pool; virtual nodes (ACI) for burst.
• Networking: Azure CNI (pods get VNet IPs - plan a big subnet; CNI Overlay reduces IP usage) vs kubenet (legacy). Private clusters keep the API server private.
• Ingress: the Application Gateway Ingress Controller (AGIC) or the managed App Routing add-on / Gateway API provisions an App Gateway or LB; a Service type=LoadBalancer creates an Azure Load Balancer.
• Identity: Microsoft Entra Workload Identity federates a Kubernetes service account to a managed identity so pods get Entra tokens with no secrets. Use Entra + Azure RBAC for cluster access, plus Kubernetes RBAC.
• Security/ops: Defender for Containers, image scanning in ACR, Azure Policy for AKS (Gatekeeper), Container Insights for monitoring.

AKS vs Container Apps vs Functions vs VMs

Networking & identity for containers

• Networking - AKS/Container Apps deploy into a VNet subnet; use private endpoints for dependencies (ACR, Key Vault, databases), Private DNS, and NSGs. Internal ingress + Private Link for private platforms.
• Identity - Entra Workload Identity (AKS) / managed identity (Container Apps, Functions, App Service) for keyless access to Key Vault, storage, databases.
• Supply chain - scan images in ACR (Defender), sign/verify, restrict pull to the workload identity; Azure Policy for AKS to enforce baselines.
• Monitoring - Container Insights (AKS), built-in metrics/logs for Container Apps/Functions; App Insights for app-level tracing.

Messaging & events

Architecture patterns

• Microservices on AKS - deployments behind AGIC/Gateway ingress, HPA/KEDA autoscaling, optional service mesh, Workload Identity, ACR + a deployment pipeline.
• Microservices on Container Apps - each service a container, internal ingress + Dapr for service-to-service, KEDA scaling, managed identity - minimal ops.
• Serverless function on a Blob event - as diagrammed; image/ETL/validation.
• Event-driven architecture - Event Grid + Functions/Container Apps + Service Bus + Event Hubs for decoupled, resilient pipelines.
• Private container platform - private AKS/Container Apps in a spoke VNet, internal ingress, private endpoints to ACR/Key Vault/DB, no public endpoints.

Troubleshooting

11. Analytics, Data, and Integration

The Azure data stack - Microsoft Fabric and Synapse, Data Factory, Data Lake Storage Gen2, Databricks, Event Hubs and Stream Analytics, Data Explorer, Purview governance, and Power BI - with the common lake/warehouse/streaming patterns.

The services

The Fabric / OneLake model (mental model)

Common data patterns

Governance with Purview

Microsoft Purview provides a unified catalog, automated classification (PII/sensitive), lineage, and data access policies across Azure data sources, on-prem, and (increasingly) multicloud - so a growing lake stays governed instead of a "data swamp." Combine with Private Endpoints around data services, storage/lake ACLs, and column/row-level security in the warehouse for sensitive data.

Reference architecture: lakehouse + BI

12. AI, ML, and Generative AI on Azure

Azure AI Foundry, Azure OpenAI, Azure AI Search, the pretrained AI services, and Azure Machine Learning - plus vector search across Cosmos DB / PostgreSQL, the enterprise RAG patterns, and the governance guardrails that separate a demo from something you can run on real data.

Azure AI Foundry & Azure OpenAI

Azure AI Search (the retrieval layer)

Azure AI Search is the managed retrieval engine for RAG: it indexes your content and supports keyword, vector, and hybrid search plus semantic ranking. Integrated vectorization and indexers can chunk, embed, and index content from Blob/ADLS/SQL/Cosmos automatically. It is the most common grounding store for Azure OpenAI RAG.

Applied AI services & Azure ML

Vector search options

RAG architecture on Azure

Enterprise patterns

Governance and security for GenAI

• Serving layer, always - agents/LLMs call a governed API (App Service/Function) that enforces authN/authZ, rate limits, input/output validation, and logging. They do not touch data stores directly.
• Security-trimmed retrieval - filter retrieved context to what the requesting user may see (document/row/column) so RAG cannot leak across users.
• Private & perimetered - use Private Endpoints for Azure OpenAI, AI Search, storage, and databases; keep model/data traffic off the internet.
• Credential hygiene - secrets in Key Vault, access via managed identity; the model never sees raw credentials.
• Auditability - log prompts, retrieved document IDs, and responses (per privacy rules); use Content Safety and groundedness checks.
• Responsible AI - evaluate quality/safety in prompt flow, monitor deployed models, and require human review for consequential outputs.

Warnings (read before connecting AI to enterprise data)

13. Migration and Disaster Recovery

Getting workloads into Azure (VMs, databases, data) and keeping them recoverable - Azure Migrate, Site Recovery, Backup, Database Migration Service - plus DR patterns by tier and how RTO/RPO drive architecture and cost.

Migration tooling

Database migration paths

DR patterns

Building blocks: Azure SQL failover groups / geo-replication or Cosmos multi-region (data); GZRS/GRS storage and object replication (objects); Azure Site Recovery for VM replication; Availability Zones for in-region HA and region pairs for DR; and Front Door / Traffic Manager for traffic failover.

RTO and RPO

• RTO - how long you can be down → drives standby readiness and automation.
• RPO - how much data you can lose → drives replication mode (sync HA vs async geo-replication vs backup interval).
• Zero data loss needs synchronous replication (zone-redundant HA, Business Critical, or a sync AG) and low latency; GRS/geo-replication are async (an RPO applies). Verify the network and trade-offs.

Architecture examples

• On-prem VM → Azure: Azure Migrate server migration.
• SQL Server → Azure: DMS / Managed Instance link, cut over at low lag.
• Oracle → Azure: self-managed on VM (Data Guard) or Oracle DB@Azure; SSMA if converting to SQL/Postgres.
• Cross-region DR (app): Front Door + warm tier + storage replication.
• Cross-region DR (database): failover groups / geo-replication / Cosmos multi-region.
• Backup-based DR: Azure Backup with cross-region restore; rebuild on demand.
• ASR pattern: replicate IaaS VMs to the paired region, fail over with recovery plans.

DR testing

• Geo-secondary / ASR replication within RPO; failover rehearsed.
• CMK keys present and usable in the DR region.
• App tier can start and connect in DR; config points to DR endpoints.
• Front Door / Traffic Manager failover tested and time-measured.
• Object data (GZRS/GRS or replicated) within RPO.
• Capacity available in DR; runbook / recovery plan current.

14. Cost Management and Governance

How Azure charges, the tools to track and cap spend (Cost Management, budgets, exports), the discount levers (Reservations, Savings Plan, Hybrid Benefit, Spot), and the governance model - ending in a monthly cost-review checklist.

Pricing basics

Cost tracking tools

Discounts

• Reserved Instances (RIs) - 1/3-year commitment to specific VM families/regions (or other services) for a big discount on steady state.
• Savings Plan for Compute - a 1/3-year hourly-spend commitment that flexes across VM families/regions (more flexible than RIs, sometimes smaller discount).
• Azure Hybrid Benefit - apply existing Windows Server / SQL Server licenses to Azure - often the single biggest saving for a Microsoft shop.
• Spot VMs - 60-90% off for interruptible workloads.
• Dev/Test pricing - reduced rates for non-production under Dev/Test subscriptions.

Governance model

Governance is enforced through the same primitives as security: the management-group hierarchy and subscriptions (isolation + attribution), Azure Policy (restrict regions/SKUs, require tags, deny public exposure), budgets + quotas, resource locks, and tags - all deployed as a landing zone in code. This keeps spend controlled and attributable by design.

Cost optimization examples

Monthly Azure cost review checklist

• Review Cost Management month-over-month by subscription, service, and tag; investigate spikes.
• Check each budget: which subscriptions/RGs/tags are over or trending over target.
• Act on Advisor right-sizing and idle-resource recommendations.
• Confirm non-prod auto-shutdown ran (nothing running 24x7 by accident).
• Find and delete unused managed disks, orphaned snapshots, and idle VMs.
• Release unassociated public IPs (Standard IPs bill when idle).
• Review RI / Savings Plan coverage and utilization; buy/adjust; confirm Hybrid Benefit applied.
• Log Analytics: top ingestion sources; add filters / Basic Logs; check retention.
• Storage: lifecycle rules moving cold data to cool/archive; review redundancy choices.
• Right-size Azure SQL / databases vs. utilization; serverless auto-pause where suitable.
• Review App Gateway / Azure Firewall sizing and consolidation.
• Review egress / inter-region charges; co-locate chatty services; use private access.
• Confirm every resource is tagged (cost-center/env/owner) for attribution.
• Validate quotas still reflect intent; check for anomalous new spend by service.

15. Enterprise Architecture Patterns

Reference blueprints for real Azure deployments. Each card gives the business case, services, traffic flow, and the security / HA / DR / monitoring / cost / risk dimensions so you can adapt rather than start from a blank page.

Foundational three-tier (reference backbone)

Pattern library

16. Troubleshooting Guides

A runbook catalog for the failures you will actually hit. Each entry lists symptoms, likely causes, checks (with portal path, CLI, and PowerShell where useful), fixes, and prevention. Deeper versions of some live in their service sections; this is the consolidated index.

Compute & access

az network watcher test-ip-flow -g RG --vm VM --direction Inbound --protocol TCP --local IP:22 --remote SRC:0
az vm boot-diagnostics get-boot-log -g RG -n VM

Storage

Network

Load balancing & databases

Identity

Serverless & AKS

Monitoring

17. Azure CLI, PowerShell, Bicep, ARM & Terraform

Practical, copy-friendly automation: CLI/PowerShell setup and tenant/subscription selection, managed identity, Bicep vs ARM vs Terraform, clean examples for VNet, VM, storage, RBAC, and alerts - plus state, structure, and CI/CD practices.

Azure CLI and PowerShell setup

# Azure CLI
az login                                  # interactive
az account list -o table                   # subscriptions you can see
az account set --subscription "Prod-01"    # select subscription
az account show                            # confirm tenant + subscription

# Azure PowerShell
Connect-AzAccount
Set-AzContext -Subscription "Prod-01"
Get-AzContext

Auth & managed identity (no secrets)

# On an Azure resource with a managed identity, tools authenticate automatically:
az login --identity                        # system-assigned MI
az login --identity --username <clientId>   # user-assigned MI

# CI/CD: use OIDC workload identity federation (no client secret)
# - create an app registration + federated credential for the pipeline
# - the pipeline exchanges its OIDC token for an Azure token; nothing to store

Common commands

# Resource groups & providers
az group create -n rg-app-prod -l eastus2
az provider register --namespace Microsoft.Sql

# Compute
az vm list -o table
az vm create -g rg-app-prod -n web1 --image Ubuntu2204 --public-ip-address "" --size Standard_D2s_v5

# Storage
az storage account create -g rg-app-prod -n stappprod01 --sku Standard_ZRS --allow-blob-public-access false
az storage blob upload-batch -d container -s ./data --auth-mode login

# RBAC
az role assignment create --assignee-object-id <objId> --role "Storage Blob Data Reader" --scope <resourceId>
az role assignment list --assignee <objId> --all -o table

# Logs (KQL)
az monitor log-analytics query -w <workspaceId> --analytics-query "AzureActivity | take 20"

Bicep vs ARM vs Terraform

Create a VNet + subnet + NSG

// Bicep: network.bicep
resource vnet 'Microsoft.Network/virtualNetworks@2023-11-01' = {
  name: 'vnet-app'
  location: resourceGroup().location
  properties: {
    addressSpace: { addressPrefixes: [ '10.10.0.0/20' ] }
    subnets: [
      {
        name: 'snet-app'
        properties: {
          addressPrefix: '10.10.1.0/24'
          networkSecurityGroup: { id: nsg.id }
          privateEndpointNetworkPolicies: 'Disabled'
        }
      }
    ]
  }
}
resource nsg 'Microsoft.Network/networkSecurityGroups@2023-11-01' = {
  name: 'nsg-app'
  location: resourceGroup().location
}

# Terraform: network.tf
resource "azurerm_virtual_network" "vnet" {
  name                = "vnet-app"
  resource_group_name = azurerm_resource_group.app.name
  location            = azurerm_resource_group.app.location
  address_space       = ["10.10.0.0/20"]
}
resource "azurerm_subnet" "app" {
  name                 = "snet-app"
  resource_group_name  = azurerm_resource_group.app.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = ["10.10.1.0/24"]
}

Create a VM (no public IP)

# Terraform: a Linux VM with a system-assigned managed identity, no public IP
resource "azurerm_linux_virtual_machine" "app" {
  name                = "vm-app-1"
  resource_group_name = azurerm_resource_group.app.name
  location            = azurerm_resource_group.app.location
  size                = "Standard_D2s_v5"
  admin_username      = "azureuser"
  network_interface_ids = [azurerm_network_interface.app.id]
  identity { type = "SystemAssigned" }
  admin_ssh_key { username = "azureuser"  public_key = file("~/.ssh/id_rsa.pub") }
  os_disk { caching = "ReadWrite"  storage_account_type = "Premium_LRS" }
  source_image_reference { publisher = "Canonical"  offer = "0001-com-ubuntu-server-jammy"  sku = "22_04-lts-gen2"  version = "latest" }
}

Create a hardened storage account

resource "azurerm_storage_account" "data" {
  name                            = "stappdataprod01"
  resource_group_name             = azurerm_resource_group.app.name
  location                        = azurerm_resource_group.app.location
  account_tier                    = "Standard"
  account_replication_type        = "ZRS"
  allow_nested_items_to_be_public = false        # no public blob access
  shared_access_key_enabled       = false        # force Entra auth
  min_tls_version                 = "TLS1_2"
  blob_properties { versioning_enabled = true  delete_retention_policy { days = 30 } }
}

Create an RBAC assignment

# Least-privilege: data role on one storage account, to a GROUP
resource "azurerm_role_assignment" "blob_read" {
  scope                = azurerm_storage_account.data.id
  role_definition_name = "Storage Blob Data Reader"
  principal_id         = azuread_group.app_team.object_id
}

Create a metric alert

resource "azurerm_monitor_action_group" "ops" {
  name                = "ops-email"
  resource_group_name = azurerm_resource_group.app.name
  short_name          = "ops"
  email_receiver { name = "oncall"  email_address = "oncall@example.com" }
}
resource "azurerm_monitor_metric_alert" "cpu" {
  name                = "vm-cpu-high"
  resource_group_name = azurerm_resource_group.app.name
  scopes              = [azurerm_linux_virtual_machine.app.id]
  criteria {
    metric_namespace = "Microsoft.Compute/virtualMachines"
    metric_name      = "Percentage CPU"
    aggregation      = "Average"
    operator         = "GreaterThan"
    threshold        = 85
  }
  window_size = "PT5M"  frequency = "PT1M"
  action { action_group_id = azurerm_monitor_action_group.ops.id }
}

State, structure, and CI/CD

• Remote, locked state (Terraform): an Azure storage account backend (blob) with blob leasing for locking and versioning on. Never keep prod state on a laptop; never commit state (it holds secrets).
• Modular structure: reusable modules (network, compute, data, rbac, monitoring) composed per environment.
• Environment separation: separate state per env (workspaces or separate backends/keys) driven by dev.tfvars / prod.tfvars; separate subscriptions and ideally separate deployer identities/pipelines.
• CI/CD: run plan/apply (or Bicep what-if/deploy) in GitHub Actions or Azure DevOps using OIDC workload identity federation (no secret). Gate apply with approvals; run plan/what-if on PRs.
• No secrets in code: reference Key Vault by name; keep secret tfvars out of git.

azure-infra/
  modules/
    network/   compute/   data/   rbac/   monitoring/
  envs/
    dev/    main.tf  dev.tfvars   backend.tf
    prod/   main.tf  prod.tfvars  backend.tf
  .github/workflows/  or  azure-pipelines.yml
  README.md

18. Azure Well-Architected Framework

The five pillars Microsoft uses to review a workload - Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency. Written for real architecture reviews: what each means, the services that support it, examples, mistakes, and a review checklist.

19. Learning Path

A structured route from Azure fundamentals to enterprise-grade architecture, security, and AI - aimed at people coming from traditional infrastructure or another cloud. Each level lists what to learn, why, hands-on labs, common mistakes, and the outcome you should reach.

Beginner

Intermediate

Advanced

Certification checkpoints (optional)