← Back to all projects

LEARN AZURE CLOUD DEEP DIVE

Learn Azure Cloud: From Zero to Cloud Architect

Goal: Deeply understand Microsoft Azure—from fundamental cloud concepts to building production-grade, multi-region, enterprise architectures through hands-on projects that produce real outcomes.

Why Azure Cloud Matters

Microsoft Azure is one of the world’s leading cloud platforms, consistently capturing 20-25% of the global cloud infrastructure market. Whether you’re deploying a simple web app or architecting a globally distributed enterprise system, understanding Azure deeply gives you the skills to build scalable, secure, and cost-effective solutions.

After completing these projects, you will:

  • Understand cloud computing fundamentals and why they exist
  • Deploy and manage compute, storage, and networking resources
  • Build serverless and containerized applications
  • Implement Infrastructure as Code with Bicep and Terraform
  • Design highly available, multi-region architectures
  • Secure your cloud resources following Zero Trust principles
  • Optimize costs while maintaining performance
  • Pass Azure certifications with practical knowledge

Core Concept Analysis

The Azure Resource Hierarchy

                    Azure AD Tenant
                         |
                  Management Groups
                         |
                   Subscriptions
                         |
                   Resource Groups
                         |
            +------------+------------+
            |            |            |
        Resources    Resources    Resources
        (VMs, DBs,   (Storage,   (Functions,
         VNets)      Key Vault)   App Services)

The Five Pillars of Azure Well-Architected Framework

  1. Reliability: Build for high availability and disaster recovery
  2. Security: Implement Zero Trust, identity management, and encryption
  3. Cost Optimization: Right-size resources, use reserved instances, monitor spending
  4. Operational Excellence: Automate deployments, monitor everything, iterate
  5. Performance Efficiency: Scale on demand, optimize for latency

Fundamental Azure Concepts

  1. Regions & Availability Zones
    • 60+ regions worldwide
    • Each region has multiple availability zones (physical datacenters)
    • Zone-redundant vs. locally redundant deployments
  2. Resource Management
    • ARM (Azure Resource Manager) - the control plane
    • Resource Groups - logical containers
    • Tags - for organization and cost tracking
    • RBAC - role-based access control
  3. Networking
    • Virtual Networks (VNets) - your private network in Azure
    • Subnets, NSGs (Network Security Groups)
    • Load Balancers, Application Gateway, Front Door
    • ExpressRoute, VPN Gateway for hybrid connectivity
  4. Identity
    • Microsoft Entra ID (formerly Azure AD)
    • Service Principals, Managed Identities
    • Conditional Access, MFA
  5. Compute Options
    • Virtual Machines - full control
    • App Services - managed web hosting
    • Functions - serverless
    • Container Instances, AKS - containers
  6. Storage Types
    • Blob Storage - unstructured data (images, files, backups)
    • Azure Files - managed file shares
    • Queue Storage - messaging
    • Table Storage - NoSQL key-value

Project List

Projects are ordered from foundational understanding to advanced enterprise architectures.

Project 1: Cloud Resource Explorer CLI

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Python
  • Alternative Programming Languages: Go, C#, PowerShell
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 1: Beginner
  • Knowledge Area: Azure Fundamentals / Resource Management
  • Software or Tool: Azure CLI, Azure SDK
  • Main Book: “Microsoft Azure Networking: The Definitive Guide” by Avinash Valiramani

What you’ll build: A CLI tool that authenticates with Azure, lists all subscriptions, resource groups, and resources across your account, displaying them in a tree structure with metadata (region, tags, costs).

Why it teaches Azure: Before you can build in Azure, you need to understand how resources are organized. This project forces you to work with the Azure SDK, understand authentication (service principals, managed identity), and see how the ARM hierarchy works.

Core challenges you’ll face:

  • Authenticating with Azure → maps to understanding service principals, RBAC, and token acquisition
  • Navigating the resource hierarchy → maps to subscriptions, resource groups, resources
  • Paginating API responses → maps to understanding ARM API conventions
  • Handling different resource types → maps to Azure resource providers and types

Key Concepts:

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic Python, understanding of REST APIs, Azure free account

Real world outcome:

$ ./azure-explorer

Authenticating with Azure...
✓ Logged in as: douglas@example.com

📦 Subscriptions found: 2

├── 🔷 Production (d4e5f6...)
│   ├── 📁 rg-webapp-prod (eastus)
│   │   ├── 🌐 app-service-prod (Microsoft.Web/sites)
│   │   ├── 🗄️ sql-db-prod (Microsoft.Sql/servers)
│   │   └── 🔐 kv-prod (Microsoft.KeyVault/vaults)
│   └── 📁 rg-monitoring (eastus)
│       └── 📊 log-analytics-prod (Microsoft.OperationalInsights/workspaces)
│
└── 🔷 Development (a1b2c3...)
    └── 📁 rg-dev (westus2)
        ├── 💻 vm-dev-01 (Microsoft.Compute/virtualMachines)
        └── 🌐 func-dev (Microsoft.Web/sites)

Total resources: 7
Estimated monthly cost: $234.56

Implementation Hints:

Authentication flow:

1. Use DefaultAzureCredential from azure-identity
   - Tries multiple auth methods: environment, managed identity, CLI, browser
2. Create ResourceManagementClient for ARM operations
3. Create SubscriptionClient to list subscriptions
4. For each subscription, list resource groups
5. For each resource group, list resources

Key Azure SDK packages:

  • azure-identity - Authentication
  • azure-mgmt-resource - Resource management
  • azure-mgmt-subscription - Subscription listing

Questions to answer as you build:

  • What’s the difference between a resource provider and resource type?
  • How does Azure handle pagination (nextLink)?
  • What permissions does your service principal need?
  • How do tags help organize resources?

Learning milestones:

  1. You authenticate successfully → You understand Azure identity and RBAC
  2. You list subscriptions and resources → You understand the ARM hierarchy
  3. You display resource metadata → You understand resource properties and tags
  4. You calculate costs → You understand Azure pricing APIs

Project 2: Static Website with CDN Pipeline

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Bicep
  • Alternative Programming Languages: Terraform, ARM JSON, Pulumi
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 1: Beginner
  • Knowledge Area: Storage / CDN / Infrastructure as Code
  • Software or Tool: Azure Blob Storage, Azure CDN, GitHub Actions
  • Main Book: “Azure Networking: Understand Key Concepts” by Jose Moreno & Adam Stuart

What you’ll build: A static website hosted on Azure Blob Storage with Azure CDN for global distribution, custom domain with HTTPS, and automated deployment via GitHub Actions—all defined in Bicep.

Why it teaches Azure: This is the “Hello World” of Azure IaC. You’ll understand storage accounts, static website hosting, CDN profiles, custom domains, and CI/CD—all the fundamentals needed for more complex projects.

Core challenges you’ll face:

  • Writing Bicep templates → maps to declarative infrastructure definition
  • Configuring static website hosting → maps to blob storage configuration
  • Setting up CDN with custom domain → maps to DNS, certificates, caching
  • Creating GitHub Actions pipeline → maps to CI/CD integration with Azure

Key Concepts:

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic HTML/CSS, Git, DNS concepts

Real world outcome:

# Deploy with a single command
$ az deployment sub create --location eastus --template-file main.bicep

# Or push to GitHub and watch it deploy automatically
$ git push origin main

# Visit your site
$ curl https://www.yoursite.com
<!DOCTYPE html>
<html>
  <head><title>My Azure Site</title></head>
  <body><h1>Hello from Azure CDN!</h1></body>
</html>

# Check CDN distribution
$ az cdn endpoint show --name cdn-endpoint --profile-name cdn-profile --resource-group rg-website
{
  "hostName": "cdn-endpoint.azureedge.net",
  "originHostHeader": "storageaccount.blob.core.windows.net",
  "deliveryPolicy": { "rules": [...] },
  "customDomains": [{ "hostName": "www.yoursite.com" }]
}

Implementation Hints:

Bicep structure:

main.bicep
├── modules/
│   ├── storage.bicep      # Storage account + static web
│   ├── cdn.bicep          # CDN profile + endpoint
│   └── dns.bicep          # Custom domain setup
└── parameters/
    ├── dev.bicepparam
    └── prod.bicepparam

Key decisions to make:

  • Which CDN tier? (Standard Microsoft, Verizon, Akamai)
  • Caching rules for different file types?
  • How to purge CDN cache on deploy?
  • How to handle HTTPS certificate?

GitHub Actions workflow:

1. Login to Azure (OIDC or service principal)
2. Deploy Bicep template
3. Upload static files to blob storage
4. Purge CDN cache

Learning milestones:

  1. Bicep deploys successfully → You understand IaC basics
  2. Static site serves from blob → You understand storage configuration
  3. CDN accelerates delivery → You understand caching and edge distribution
  4. CI/CD auto-deploys → You understand Azure + GitHub integration

Project 3: Multi-Tier Web Application

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: C# (.NET)
  • Alternative Programming Languages: Python (Django/Flask), Node.js, Java (Spring Boot)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: App Services / Azure SQL / Networking
  • Software or Tool: Azure App Service, Azure SQL Database, Azure Key Vault
  • Main Book: “Designing Data-Intensive Applications” by Martin Kleppmann

What you’ll build: A three-tier web application with a frontend (App Service), backend API (App Service), and database (Azure SQL), with secure credential storage in Key Vault, VNet integration, and Application Insights monitoring.

Why it teaches Azure: This is the bread-and-butter of cloud applications. You’ll understand PaaS offerings, managed databases, secret management, network isolation, and observability—skills used in 90% of Azure projects.

Core challenges you’ll face:

  • Deploying App Services with slots → maps to blue-green deployments
  • Configuring VNet integration → maps to private networking
  • Securing secrets in Key Vault → maps to managed identity + secret references
  • Setting up Application Insights → maps to distributed tracing and metrics

Key Concepts:

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Project 1 & 2, basic web development, SQL fundamentals

Real world outcome:

# Your deployed application
$ curl https://myapp.azurewebsites.net/api/health
{
  "status": "healthy",
  "database": "connected",
  "timestamp": "2025-12-20T10:30:00Z"
}

# Application Insights query
$ az monitor app-insights query --app myapp-insights \
    --analytics-query "requests | where success == false | take 10"

# Slot swap for zero-downtime deployment
$ az webapp deployment slot swap \
    --name myapp --resource-group rg-app \
    --slot staging --target-slot production

# View Key Vault secrets (without exposing values)
$ az keyvault secret list --vault-name kv-myapp
[
  { "name": "SqlConnectionString", "enabled": true },
  { "name": "ApiKey", "enabled": true }
]

Implementation Hints:

Architecture:

                    Internet
                        |
                   [App Gateway]
                        |
        +---------------+---------------+
        |                               |
   [Frontend App]               [Backend API]
   (App Service)                (App Service)
        |                               |
        |       +-------+-------+       |
        +-------|  Azure SQL    |-------+
                |  (Private)    |
                +---------------+
                        |
                  [Key Vault]
                  (Managed Identity)

Key configurations:

  • App Service: VNet integration to access private SQL
  • Azure SQL: Private endpoint, no public access
  • Key Vault: Managed identity access, no hardcoded secrets
  • App Gateway: WAF rules, SSL termination

Questions to explore:

  • How does slot swap work internally?
  • What’s the difference between VNet integration and private endpoints?
  • How does Application Insights correlate distributed traces?
  • How do Key Vault references work without app code changes?

Learning milestones:

  1. App connects to SQL securely → You understand private networking
  2. Secrets never appear in config → You understand managed identity
  3. Slot swap deploys without downtime → You understand deployment patterns
  4. You can trace a request end-to-end → You understand observability

Project 4: Virtual Network Hub-and-Spoke

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Bicep
  • Alternative Programming Languages: Terraform, ARM JSON
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Networking / Security / Architecture
  • Software or Tool: Azure VNet, Azure Firewall, VPN Gateway
  • Main Book: “Azure Networking Handbook” by Toni Pasanen

What you’ll build: A hub-and-spoke network topology with a central hub containing shared services (Firewall, VPN Gateway, Bastion), and multiple spoke VNets for different workloads, with all traffic flowing through the hub.

Why it teaches Azure: Enterprise Azure deployments always use hub-and-spoke. This project forces you to understand VNet peering, User-Defined Routes (UDRs), Azure Firewall, and how to isolate workloads while sharing services.

Core challenges you’ll face:

  • Configuring VNet peering → maps to understanding address space planning
  • Routing all traffic through firewall → maps to UDRs and BGP
  • Setting up Azure Bastion → maps to secure administrative access
  • Implementing NSG rules → maps to micro-segmentation

Key Concepts:

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: Projects 1-3, strong networking fundamentals (TCP/IP, subnetting)

Real world outcome:

# View your network topology
$ az network watcher show-topology --resource-group rg-network

# Test connectivity through firewall
$ az network bastion ssh --name bastion-hub --resource-group rg-hub \
    --target-resource-id /subscriptions/.../vms/spoke-vm \
    --auth-type ssh-key --username azureuser

# View firewall logs
$ az monitor log-analytics query --workspace ws-hub \
    --analytics-query "AzureFirewallNetworkRules | where Action == 'Deny' | take 10"

# Verify routes
$ az network nic show-effective-route-table \
    --name vm-nic --resource-group rg-spoke-prod
[
  { "addressPrefix": "0.0.0.0/0", "nextHopType": "VirtualAppliance",
    "nextHopIpAddress": "10.0.1.4" }  // Firewall IP
]

Implementation Hints:

Network layout:

Hub VNet (10.0.0.0/16)
├── AzureFirewallSubnet (10.0.1.0/26)
├── GatewaySubnet (10.0.2.0/27)
├── AzureBastionSubnet (10.0.3.0/27)
└── SharedServicesSubnet (10.0.4.0/24)

Spoke-Prod VNet (10.1.0.0/16) -- peered to Hub
├── WebSubnet (10.1.1.0/24)
├── AppSubnet (10.1.2.0/24)
└── DataSubnet (10.1.3.0/24)

Spoke-Dev VNet (10.2.0.0/16) -- peered to Hub
└── DevSubnet (10.2.1.0/24)

Critical configurations:

  • VNet Peering: Allow gateway transit from hub, use remote gateways from spokes
  • UDR on spoke subnets: 0.0.0.0/0 → Firewall private IP
  • Azure Firewall: Network and application rules for allowed traffic
  • NSGs: Defense in depth, even with firewall

Questions to explore:

  • Why can’t spoke VNets communicate directly?
  • What happens if the firewall goes down?
  • How do you troubleshoot connectivity issues?
  • What’s the cost difference between Azure Firewall Standard and Premium?

Learning milestones:

  1. VNets are peered correctly → You understand virtual network interconnection
  2. All traffic routes through firewall → You understand UDRs and forced tunneling
  3. Bastion provides secure access → You understand jump box alternatives
  4. Firewall logs show traffic patterns → You understand network observability

Project 5: Event-Driven Serverless Pipeline

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Python
  • Alternative Programming Languages: C#, JavaScript/TypeScript, Java
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Serverless / Event-Driven Architecture
  • Software or Tool: Azure Functions, Event Grid, Service Bus, Cosmos DB
  • Main Book: “Designing Data-Intensive Applications” by Martin Kleppmann

What you’ll build: An event-driven image processing pipeline: images uploaded to Blob Storage trigger a Function that resizes them, publishes events to Event Grid, which triggers another Function to store metadata in Cosmos DB and send notifications via Service Bus.

Why it teaches Azure: Serverless and event-driven architectures are fundamental to modern cloud applications. This project teaches you how Azure services communicate asynchronously, how to handle at-least-once delivery, and how to build resilient, scalable systems.

Core challenges you’ll face:

  • Blob trigger Functions → maps to understanding trigger bindings
  • Event Grid subscriptions → maps to pub/sub patterns
  • Service Bus queues → maps to reliable messaging with dead-letter queues
  • Cosmos DB modeling → maps to NoSQL design patterns

Key Concepts:

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Projects 1-3, understanding of async programming

Real world outcome:

# Upload an image
$ az storage blob upload --account-name stgimages \
    --container-name uploads --name photo.jpg --file ./photo.jpg

# Watch the pipeline execute
$ func azure functionapp logstream func-imageprocessor
[10:30:01] BlobTrigger: Processing photo.jpg (2.5MB)
[10:30:02] Resizing to thumbnail (200x200), medium (800x600)
[10:30:03] Publishing ImageProcessed event to Event Grid
[10:30:04] Thumbnails saved to container: thumbnails

# Query processed images in Cosmos DB
$ az cosmosdb sql query --account-name cosmos-images \
    --database-name imagedb --container-name metadata \
    --query "SELECT * FROM c WHERE c.status = 'processed'"
{
  "Documents": [
    {
      "id": "photo.jpg",
      "originalSize": 2500000,
      "thumbnailUrl": "https://stgimages.../thumbnail_photo.jpg",
      "processedAt": "2025-12-20T10:30:04Z",
      "status": "processed"
    }
  ]
}

# Check dead-letter queue for failed messages
$ az servicebus queue show --name notifications-dlq \
    --namespace-name sb-images --resource-group rg-images

Implementation Hints:

Event flow:

[Blob Storage]
     | (Blob Created Event)
     v
[Azure Function: ImageProcessor]
     | (Resize, create thumbnails)
     v
[Event Grid: ImageProcessed]
     |
     +---> [Function: MetadataWriter] --> [Cosmos DB]
     |
     +---> [Function: Notifier] --> [Service Bus Queue]
                                         |
                                         v
                                   [Consumer App]

Key configurations:

  • Function bindings: BlobTrigger, EventGridOutput, ServiceBusOutput
  • Event Grid: Custom topic with multiple subscriptions
  • Service Bus: Sessions for ordering, dead-letter for failures
  • Cosmos DB: Partition key strategy for scale

Questions to explore:

  • How do you handle poison messages (repeated failures)?
  • What happens if Cosmos DB is temporarily unavailable?
  • How do you ensure exactly-once processing?
  • How does Event Grid retry failed deliveries?

Learning milestones:

  1. Blob trigger fires reliably → You understand event bindings
  2. Events fan out to multiple consumers → You understand pub/sub
  3. Failed messages go to dead-letter → You understand resilient messaging
  4. Cosmos DB scales with load → You understand serverless databases

Project 6: Container-Based Microservices (AKS)

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Go
  • Alternative Programming Languages: C#, Python, Java
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Containers / Kubernetes / DevOps
  • Software or Tool: Azure Kubernetes Service (AKS), Azure Container Registry, Helm
  • Main Book: “Kubernetes in Action” by Marko Lukša

What you’ll build: A microservices-based e-commerce backend with multiple services (product catalog, inventory, orders) running on AKS, with service mesh (Istio or Linkerd), GitOps deployment (Flux), and Azure-native integrations.

Why it teaches Azure: Kubernetes is the de facto standard for container orchestration. AKS is Azure’s managed Kubernetes offering. This project teaches you how to deploy, scale, and operate production Kubernetes workloads with Azure-specific integrations.

Core challenges you’ll face:

  • Setting up AKS with proper networking → maps to CNI, Azure VNet integration
  • Implementing GitOps with Flux → maps to declarative deployments
  • Configuring service mesh → maps to observability, traffic management
  • Azure integrations → maps to Workload Identity, Key Vault CSI, Azure Monitor

Key Concepts:

Difficulty: Advanced Time estimate: 1 month Prerequisites: Projects 1-5, Docker fundamentals, basic Kubernetes knowledge

Real world outcome:

# Check cluster status
$ kubectl get nodes
NAME                                STATUS   ROLES   AGE   VERSION
aks-systempool-12345678-vmss000000  Ready    agent   10d   v1.28.3
aks-userpool-12345678-vmss000000    Ready    agent   10d   v1.28.3

# View deployed services
$ kubectl get pods -n ecommerce
NAME                              READY   STATUS    RESTARTS
product-catalog-7f8d6c5b4-x2j9k   2/2     Running   0
inventory-5c8f9d7a3-m4n7p         2/2     Running   0
orders-9a3c7e5b2-k8l2q            2/2     Running   0

# GitOps: Push to deploy
$ git push origin main
# Flux automatically syncs changes to cluster

# View service mesh dashboard
$ istioctl dashboard kiali
# Opens browser with traffic visualization

# Query Azure Monitor for container insights
$ az monitor log-analytics query --workspace ws-aks \
    --analytics-query "ContainerLog | where LogEntry contains 'error' | take 20"

Implementation Hints:

Architecture:

                    [Azure Front Door]
                           |
                    [Ingress Controller]
                           |
        +------------------+------------------+
        |                  |                  |
[Product Catalog]    [Inventory]        [Orders]
   (Go svc)          (Go svc)          (Go svc)
        |                  |                  |
        +--------+---------+--------+---------+
                 |                  |
           [Azure SQL]        [Cosmos DB]
                 |
           [Key Vault]
        (via Workload Identity)

Key AKS configurations:

  • Node pools: System pool (AKS components) + User pool (workloads)
  • Networking: Azure CNI for VNet integration
  • Identity: Workload Identity for Azure service access
  • Secrets: Key Vault CSI driver
  • Monitoring: Container Insights + Prometheus

GitOps structure:

clusters/
├── production/
│   ├── flux-system/
│   ├── infrastructure/
│   │   ├── istio/
│   │   └── cert-manager/
│   └── apps/
│       ├── product-catalog/
│       ├── inventory/
│       └── orders/
└── staging/
    └── ...

Learning milestones:

  1. AKS cluster is production-ready → You understand managed Kubernetes
  2. GitOps deploys automatically → You understand declarative operations
  3. Service mesh shows traffic flows → You understand observability at scale
  4. Workload Identity eliminates secrets → You understand cloud-native security

Project 7: Identity Platform with Entra ID

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: C#
  • Alternative Programming Languages: Python, Node.js, Java
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Identity / Security / OAuth/OIDC
  • Software or Tool: Microsoft Entra ID, MSAL, Microsoft Graph
  • Main Book: “Identity and Access Management: Business Performance Through Connected Intelligence” by Ertem Osmanoglu

What you’ll build: A multi-tenant SaaS application with Entra ID integration: user sign-in (OIDC), API protection (OAuth 2.0), role-based access, Conditional Access policies, and B2B guest user access.

Why it teaches Azure: Identity is the new perimeter. Every Azure application needs authentication and authorization. This project teaches you how Entra ID works, how to protect APIs, implement RBAC, and design for multi-tenancy.

Core challenges you’ll face:

  • Implementing OIDC authentication → maps to ID tokens, claims
  • Protecting APIs with OAuth 2.0 → maps to access tokens, scopes
  • Multi-tenant app registration → maps to consent, tenant isolation
  • Conditional Access → maps to Zero Trust policies

Key Concepts:

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1-3, understanding of OAuth 2.0/OIDC

Real world outcome:

# User signs in via browser
# Redirect to: https://login.microsoftonline.com/common/oauth2/v2.0/authorize

# Application receives ID token with claims
{
  "aud": "your-app-client-id",
  "iss": "https://login.microsoftonline.com/{tenant-id}/v2.0",
  "sub": "user-object-id",
  "name": "Douglas Costa",
  "email": "douglas@example.com",
  "roles": ["Admin", "Reader"]
}

# API validates access token
$ curl -H "Authorization: Bearer eyJ0eX..." \
    https://api.yourapp.com/protected/data
{
  "data": "secret information",
  "user": "douglas@example.com"
}

# View sign-in logs
$ az ad audit-sign-in list --filter "userPrincipalName eq 'douglas@example.com'"

# Conditional Access blocks risky sign-in
$ curl ... # From suspicious location
HTTP 403: Sign-in blocked by Conditional Access policy

Implementation Hints:

Token flow:

[User Browser]
      |
      | 1. /authorize (OIDC)
      v
[Entra ID Login]
      |
      | 2. ID Token + Auth Code
      v
[Your Web App]
      |
      | 3. Exchange code for Access Token
      v
[Entra ID Token Endpoint]
      |
      | 4. Access Token + Refresh Token
      v
[Your API] (validates Access Token)

App Registration setup:

  • Application (client) ID
  • Supported account types: Multi-tenant
  • Redirect URIs: Web, SPA
  • API permissions: Microsoft Graph (User.Read, etc.)
  • Expose an API: Define scopes for your API
  • App roles: Define roles for RBAC

Key decisions:

  • Authorization Code Flow (web) vs. PKCE (SPA/mobile)?
  • Which Microsoft Graph permissions do you need?
  • How to handle token refresh?
  • How to implement tenant isolation?

Learning milestones:

  1. Users sign in successfully → You understand OIDC
  2. API rejects invalid tokens → You understand JWT validation
  3. Roles control access → You understand RBAC
  4. Conditional Access enforces policy → You understand Zero Trust

Project 8: Disaster Recovery & High Availability

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Bicep
  • Alternative Programming Languages: Terraform, ARM JSON
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: Architecture / Reliability / Business Continuity
  • Software or Tool: Azure Site Recovery, Traffic Manager, Azure SQL Geo-Replication
  • Main Book: “Designing Data-Intensive Applications” by Martin Kleppmann

What you’ll build: A multi-region active-passive deployment with automatic failover: primary region serves traffic, secondary region has warm replicas, Azure Site Recovery for VMs, geo-replicated SQL, and Traffic Manager for DNS-based failover.

Why it teaches Azure: High availability and disaster recovery are non-negotiable for production systems. This project teaches you how to design for failures at every level—VMs, databases, and entire regions—while meeting RPO/RTO requirements.

Core challenges you’ll face:

  • Configuring Azure Site Recovery → maps to VM replication, recovery plans
  • SQL geo-replication → maps to async replication, failover groups
  • Traffic Manager failover → maps to DNS TTL, health probes
  • Testing disaster recovery → maps to DR drills, runbooks

Key Concepts:

Difficulty: Expert Time estimate: 2-3 weeks Prerequisites: Projects 1-4, understanding of RTO/RPO concepts

Real world outcome:

# Normal operation - traffic to primary
$ dig myapp.trafficmanager.net
;; ANSWER SECTION:
myapp.trafficmanager.net. 60 IN CNAME myapp-eastus.azurewebsites.net.

# Simulate primary region failure
$ az webapp stop --name myapp-eastus --resource-group rg-primary

# Traffic Manager detects failure, fails over
$ dig myapp.trafficmanager.net
;; ANSWER SECTION:
myapp.trafficmanager.net. 60 IN CNAME myapp-westus.azurewebsites.net.

# SQL failover group status
$ az sql failover-group show --name fg-myapp \
    --server sql-primary --resource-group rg-primary
{
  "replicationRole": "Secondary",  // Was Primary
  "replicationState": "CATCH_UP"
}

# Trigger planned failover for DR drill
$ az sql failover-group set-primary --name fg-myapp \
    --server sql-secondary --resource-group rg-secondary

Implementation Hints:

Multi-region architecture:

         [Traffic Manager]
         (Priority routing)
               |
       +-------+-------+
       |               |
   [East US]       [West US]
   (Primary)      (Secondary)
       |               |
[App Service]    [App Service]
[Azure SQL]  --> [SQL Geo-Rep]
[Storage]    --> [RA-GRS]
[Key Vault]  --> [Replicated]

Key decisions:

  • RPO (Recovery Point Objective): How much data loss is acceptable?
  • RTO (Recovery Time Objective): How fast must you recover?
  • Active-passive vs. active-active?
  • Automated failover vs. manual?

Testing checklist:

  1. Verify replication lag (seconds? minutes?)
  2. Test failover time (DNS propagation)
  3. Verify application works in secondary region
  4. Test failback to primary
  5. Document runbook for operators

Learning milestones:

  1. Replication is healthy → You understand async replication
  2. Failover completes successfully → You understand recovery automation
  3. Application works in secondary → You understand stateless design
  4. DR drill passes → You understand operational readiness

Project 9: Cost Management & FinOps Dashboard

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Python
  • Alternative Programming Languages: PowerShell, C#, Go
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: FinOps / Cost Optimization / Data Analysis
  • Software or Tool: Azure Cost Management, Power BI, Azure Data Explorer
  • Main Book: “Cloud FinOps” by J.R. Storment & Mike Fuller

What you’ll build: A cost analytics dashboard that pulls data from Azure Cost Management APIs, identifies cost anomalies, recommends optimizations (right-sizing, reserved instances), and sends alerts when budgets are exceeded.

Why it teaches Azure: Cloud costs can spiral out of control. This project teaches you how to monitor spending, identify waste, implement cost governance, and communicate cost insights to stakeholders—essential FinOps skills.

Core challenges you’ll face:

  • Querying Cost Management APIs → maps to usage details, cost data
  • Detecting anomalies → maps to statistical analysis, trends
  • Generating recommendations → maps to Azure Advisor integration
  • Building visualizations → maps to Power BI, dashboards

Key Concepts:

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Projects 1-2, basic data analysis, understanding of Azure pricing

Real world outcome:

# Daily cost summary
$ ./finops-dashboard summary --days 30
Azure Cost Summary (Last 30 Days)
==================================
Total Spend: $12,456.78
Daily Average: $415.23
Projected Monthly: $12,872.00

Top 5 Services:
  1. Virtual Machines     $5,234.00  (42%)
  2. Azure SQL Database   $2,100.00  (17%)
  3. Storage              $1,500.00  (12%)
  4. App Service          $1,200.00  (10%)
  5. Kubernetes Service   $900.00    (7%)

# Optimization recommendations
$ ./finops-dashboard recommendations
Cost Optimization Opportunities
================================
1. [HIGH] VM right-sizing: vm-prod-02
   Current: Standard_D8s_v3 ($280/month)
   Recommended: Standard_D4s_v3 ($140/month)
   Savings: $140/month (50%)
   Reason: Average CPU utilization 15%

2. [MEDIUM] Reserved Instances: SQL Database
   Current: Pay-as-you-go ($2,100/month)
   With 1-year RI: $1,470/month
   Savings: $630/month (30%)

3. [LOW] Delete unused disks
   5 unattached disks: $45/month

# Anomaly alert
$ ./finops-dashboard check-anomalies
⚠️ ANOMALY DETECTED
  Service: Azure Functions
  Date: 2025-12-19
  Expected: $5.00
  Actual: $150.00
  Increase: 2900%
  Possible cause: Infinite loop in BlobTrigger function

Implementation Hints:

Data pipeline:

[Cost Management API]
       |
       | (Daily export or API pull)
       v
[Azure Data Explorer / Storage]
       |
       | (Analysis, aggregation)
       v
[Python Analytics Engine]
       |
       +---> [Power BI Dashboard]
       |
       +---> [Alert System] --> [Email/Teams/Slack]

Key metrics to track:

  • Cost by service, resource group, tag
  • Cost trend (daily, weekly, monthly)
  • Budget vs. actual spend
  • Reserved Instance utilization
  • Advisor recommendations count

Anomaly detection approaches:

  • Simple: Compare to 7-day moving average
  • Statistical: Z-score above threshold
  • ML: Time-series forecasting

Learning milestones:

  1. Cost data is extracted correctly → You understand Azure billing APIs
  2. Dashboard shows spending trends → You understand cost visualization
  3. Recommendations are accurate → You understand optimization patterns
  4. Alerts fire on anomalies → You understand proactive cost governance

Project 10: Infrastructure as Code Testing Framework

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Python
  • Alternative Programming Languages: Go, PowerShell
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: DevOps / Testing / Infrastructure as Code
  • Software or Tool: Bicep, Terraform, Azure Policy, OPA
  • Main Book: “Terraform: Up & Running” by Yevgeniy Brikman

What you’ll build: A testing framework for IaC templates (Bicep/Terraform) that validates templates before deployment: syntax checking, security scanning, policy compliance (Azure Policy, OPA), cost estimation, and integration tests that deploy to a sandbox.

Why it teaches Azure: “Infrastructure as Code” without testing is just “Infrastructure as Hope.” This project teaches you how to shift security and compliance left, catch misconfigurations before deployment, and implement IaC best practices.

Core challenges you’ll face:

  • Parsing and validating templates → maps to Bicep/Terraform syntax
  • Implementing policy checks → maps to Azure Policy, Open Policy Agent
  • Estimating deployment costs → maps to Azure Pricing API
  • Running integration tests → maps to ephemeral environments

Key Concepts:

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 2 and 6, strong IaC experience

Real world outcome:

# Run the IaC testing pipeline
$ ./iac-test validate --template ./infra/main.bicep

IaC Validation Report
======================

✅ Syntax Check: PASSED
   - No syntax errors found
   - All module references valid

⚠️ Security Scan: 2 WARNINGS
   1. Storage account allows public access (line 45)
      Recommendation: Set allowBlobPublicAccess: false

   2. SQL server firewall allows 0.0.0.0/0 (line 78)
      Recommendation: Restrict to specific IP ranges

❌ Policy Compliance: 1 FAILURE
   1. DENY: Storage account must use CMK encryption
      Policy: org-require-cmk-encryption
      Resource: storageAccount (line 40)

💰 Cost Estimate:
   Monthly: $1,234.00
   Breakdown:
   - Virtual Machines: $800.00
   - SQL Database: $300.00
   - Storage: $134.00

🧪 Integration Test: SKIPPED (policy failure)
   Would deploy to: rg-sandbox-test-12345

Overall: FAILED (fix policy violations to proceed)

Implementation Hints:

Testing pipeline stages:

[Bicep/Terraform Template]
           |
           v
   1. [Syntax Validation]
           |
           v
   2. [Security Scanning]
       (checkov, tfsec)
           |
           v
   3. [Policy Evaluation]
       (Azure Policy, OPA)
           |
           v
   4. [Cost Estimation]
       (Azure Pricing API)
           |
           v
   5. [Integration Test]
       (Deploy to sandbox)
           |
           v
   6. [Cleanup]
       (Destroy sandbox)

Security rules to implement:

  • No public storage accounts
  • No open SSH/RDP ports
  • Encryption at rest required
  • Managed identity preferred over keys
  • Tags required (environment, owner, cost-center)

OPA policy example structure:

package azure.security

deny[msg] {
    resource := input.resources[_]
    resource.type == "Microsoft.Storage/storageAccounts"
    resource.properties.allowBlobPublicAccess == true
    msg := "Storage accounts must not allow public blob access"
}

Learning milestones:

  1. Syntax validation catches errors → You understand IaC parsing
  2. Security scanner finds vulnerabilities → You understand shift-left security
  3. Policy enforcement blocks non-compliant resources → You understand governance
  4. Integration tests verify actual deployment → You understand IaC confidence

Project 11: AI-Powered Chat Application

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Python
  • Alternative Programming Languages: C#, TypeScript
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 3: Advanced
  • Knowledge Area: AI / Cognitive Services / RAG
  • Software or Tool: Azure OpenAI, Azure AI Search, Cosmos DB
  • Main Book: “AI Engineering” by Chip Huyen

What you’ll build: A RAG (Retrieval Augmented Generation) chatbot that answers questions about your company’s documentation: documents are indexed in Azure AI Search, embeddings stored in Cosmos DB, and Azure OpenAI provides intelligent responses with citations.

Why it teaches Azure: AI is the future, and Azure has first-party OpenAI integration. This project teaches you how to build production AI applications with proper architecture: vector search, prompt engineering, response grounding, and content safety.

Core challenges you’ll face:

  • Chunking and embedding documents → maps to text preprocessing, embeddings
  • Semantic search with AI Search → maps to vector indexes, hybrid search
  • Prompt engineering → maps to system prompts, context injection
  • Response grounding → maps to citation, hallucination prevention

Key Concepts:

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1-5, understanding of LLMs

Real world outcome:

# Index your documentation
$ ./rag-chat index --source ./docs/*.md
Indexing 150 documents...
Chunking: 1,247 chunks created
Embedding: Using text-embedding-ada-002
Uploading to Azure AI Search...
✅ Index 'company-docs' updated with 1,247 vectors

# Start the chat
$ ./rag-chat query "How do I request time off?"

🔍 Searching knowledge base...
   Found 5 relevant chunks (similarity > 0.85)

💬 Azure OpenAI Response:
To request time off, follow these steps:

1. Log into the HR Portal at hr.company.com
2. Click "Time Off" → "New Request"
3. Select your leave type (PTO, Sick, Personal)
4. Choose your dates and submit

Your manager will receive an automatic notification and has
48 hours to approve. [Source: hr-policies.md, section 3.2]

📚 Sources:
  - hr-policies.md (chunk 45): "Time off requests must be..."
  - employee-handbook.md (chunk 12): "PTO accrual rates are..."

Implementation Hints:

RAG architecture:

[User Question]
      |
      v
[Embedding Model]
(text-embedding-ada-002)
      |
      v
[Azure AI Search]
(Vector similarity search)
      |
      | Top K relevant chunks
      v
[Prompt Construction]
System: You are a helpful assistant...
Context: {retrieved_chunks}
Question: {user_question}
      |
      v
[Azure OpenAI GPT-4]
      |
      v
[Response + Citations]

Key design decisions:

  • Chunk size: 500-1000 tokens optimal
  • Overlap: 100-200 tokens for context continuity
  • Top K: 3-5 chunks typically sufficient
  • Model: GPT-4 Turbo for quality, GPT-3.5 for cost

Prompt template structure:

System: You are a helpful assistant answering questions about
company policies. Use ONLY the provided context to answer.
If the context doesn't contain the answer, say "I don't know."
Always cite your sources.

Context:
{chunk_1}
{chunk_2}
...

User: {question}

Learning milestones:

  1. Documents are chunked and embedded → You understand preprocessing
  2. Search returns relevant chunks → You understand vector similarity
  3. GPT provides grounded answers → You understand RAG pattern
  4. Citations are accurate → You understand hallucination prevention

Project 12: Zero Trust Security Implementation

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Bicep
  • Alternative Programming Languages: Terraform, PowerShell
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: Security / Identity / Networking
  • Software or Tool: Microsoft Defender for Cloud, Sentinel, Private Link
  • Main Book: “Cybersecurity Ops with bash” by Paul Troncone & Carl Albing

What you’ll build: A fully locked-down Azure environment implementing Zero Trust principles: no public endpoints, all traffic through Private Link, just-in-time VM access, Privileged Identity Management, Microsoft Sentinel for SIEM, and Defender for Cloud for posture management.

Why it teaches Azure: Security is not optional. This project teaches you how to implement defense-in-depth, eliminate the traditional network perimeter, and build an environment that assumes breach and verifies every request.

Core challenges you’ll face:

  • Eliminating public endpoints → maps to Private Link, service endpoints
  • Implementing just-in-time access → maps to PIM, JIT VM access
  • Configuring SIEM → maps to Sentinel, log collection, analytics rules
  • Security posture management → maps to Defender for Cloud, Secure Score

Key Concepts:

Difficulty: Expert Time estimate: 1 month Prerequisites: Projects 4, 7, and 8, security certifications helpful

Real world outcome:

# Verify no public endpoints
$ az network private-endpoint list --resource-group rg-production
[
  { "name": "pe-sql", "privateLinkServiceConnections": [...] },
  { "name": "pe-storage", "privateLinkServiceConnections": [...] },
  { "name": "pe-keyvault", "privateLinkServiceConnections": [...] }
]

# Request JIT VM access
$ az security jit-policy initiate \
    --resource-group rg-production \
    --vm-name vm-admin \
    --ports 22
{
  "status": "Approved",
  "requestTime": "2025-12-20T10:00:00Z",
  "endTime": "2025-12-20T13:00:00Z"  // 3 hours
}

# View Secure Score
$ az security secure-score show --name "default"
{
  "displayName": "Azure Secure Score",
  "currentScore": 85,
  "maxScore": 100,
  "percentageScore": 0.85
}

# Sentinel alert
$ az sentinel alert-rule list --workspace-name sentinel-ws
[
  {
    "displayName": "Suspicious login from new country",
    "severity": "High",
    "tactics": ["InitialAccess"],
    "query": "SigninLogs | where ResultType == 0 | ..."
  }
]

Implementation Hints:

Zero Trust architecture:

[Internet Users]
       |
       | (HTTPS only)
       v
[Azure Front Door + WAF]
       |
       | (Private endpoint)
       v
[App Service] ←── [Managed Identity] ──→ [Key Vault]
       |                                 (Private endpoint)
       | (Private endpoint)
       v
[Azure SQL]
(Private endpoint, no public access)

[Admins]
   |
   | (Entra ID + MFA + Conditional Access)
   v
[PIM: Activate role] → [JIT: Request VM access]
   |
   v
[Azure Bastion] → [VM]

Security controls checklist:

  • All storage accounts: Private endpoint only
  • All PaaS services: Private endpoint only
  • No public IPs on VMs
  • JIT access required for all VMs
  • PIM for all privileged roles
  • Conditional Access: MFA required
  • Sentinel: Collect all logs
  • Defender for Cloud: All plans enabled

Learning milestones:

  1. No resources have public endpoints → You understand Private Link
  2. Access requires approval → You understand JIT/PIM
  3. Sentinel detects threats → You understand SIEM
  4. Secure Score is 85%+ → You understand security posture

Project 13: Hybrid Cloud with Azure Arc

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Bicep
  • Alternative Programming Languages: Terraform, PowerShell
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 4: Expert
  • Knowledge Area: Hybrid Cloud / Arc / Multi-Cloud
  • Software or Tool: Azure Arc, Arc-enabled Servers, Arc-enabled Kubernetes
  • Main Book: “Hybrid Cloud for Architects” by Alok Shrivastwa

What you’ll build: A hybrid cloud environment where on-premises servers (or AWS/GCP resources) are managed through Azure: Arc-enabled servers with Azure Policy, Arc-enabled Kubernetes clusters, and Azure Monitor for unified observability.

Why it teaches Azure: Most enterprises have hybrid or multi-cloud environments. This project teaches you how to extend Azure management plane to resources anywhere, enabling consistent governance, security, and operations.

Core challenges you’ll face:

  • Onboarding servers to Arc → maps to Connected Machine agent
  • Applying Azure Policy to non-Azure resources → maps to policy compliance
  • Arc-enabled Kubernetes → maps to GitOps, cluster extensions
  • Unified monitoring → maps to Azure Monitor agent, Log Analytics

Key Concepts:

Difficulty: Expert Time estimate: 1 month Prerequisites: Projects 4, 6, and 12, on-premises infrastructure access

Real world outcome:

# View Arc-enabled servers
$ az connectedmachine list
[
  {
    "name": "on-prem-server-01",
    "status": "Connected",
    "osType": "Linux",
    "location": "eastus",  // Azure region for management
    "privateLinkScopeResourceId": "/subscriptions/.../privateLinkScopes/arc-pls"
  },
  {
    "name": "aws-server-01",
    "status": "Connected",
    "osType": "Windows",
    "tags": { "environment": "production", "cloud": "aws" }
  }
]

# Check policy compliance across hybrid estate
$ az policy state list --filter "complianceState eq 'NonCompliant'"
[
  {
    "resourceId": ".../Microsoft.HybridCompute/machines/on-prem-server-02",
    "policyDefinitionName": "deploy-azure-monitor-agent",
    "complianceState": "NonCompliant"
  }
]

# Arc-enabled Kubernetes clusters
$ az connectedk8s list
[
  {
    "name": "k8s-on-prem",
    "connectivityStatus": "Connected",
    "kubernetesVersion": "1.28.2",
    "totalNodeCount": 5
  }
]

# Query logs from all servers (Azure + hybrid)
$ az monitor log-analytics query --workspace ws-central \
    --analytics-query "Heartbeat | summarize count() by Computer, _ResourceId"

Implementation Hints:

Hybrid architecture:

[Azure]                           [On-Premises / Other Cloud]
   |                                        |
   |         +--- Secure Connection ---+    |
   |         |    (ExpressRoute/VPN/   |    |
   |         |     Public Internet)    |    |
   v         v                         v    v
[Azure Resource Manager]          [Connected Machine Agent]
[Azure Policy]                    [Azure Monitor Agent]
[Azure Monitor]                   [Arc-enabled K8s Agent]
   |                                        |
   +------------- Unified View -------------+

Onboarding process:

  1. Generate service principal for Arc
  2. Install Connected Machine agent on servers
  3. Register with Azure (resource in chosen region)
  4. Apply Azure Policy for configuration
  5. Install Azure Monitor agent for logs/metrics

Use cases to implement:

  • Azure Update Manager for patching
  • Azure Defender for hybrid security
  • Azure Policy for compliance
  • GitOps for Arc-enabled Kubernetes

Learning milestones:

  1. Servers appear in Azure portal → You understand Arc onboarding
  2. Policies apply to hybrid resources → You understand unified governance
  3. Logs flow to Azure Monitor → You understand hybrid observability
  4. GitOps deploys to Arc K8s → You understand hybrid Kubernetes

Project 14: Platform Engineering Landing Zone

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Bicep
  • Alternative Programming Languages: Terraform
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 5: Master
  • Knowledge Area: Platform Engineering / Governance / Enterprise Scale
  • Software or Tool: Azure Landing Zones, Management Groups, Azure DevOps
  • Main Book: “Fundamentals of Software Architecture” by Mark Richards & Neal Ford

What you’ll build: An enterprise-scale Azure landing zone with management group hierarchy, subscription vending, centralized logging, policy-driven governance, and a self-service portal for development teams to request environments.

Why it teaches Azure: This is how large enterprises operate Azure. This project teaches you how to design scalable, governed, and automated cloud foundations that enable teams to move fast while maintaining security and compliance.

Core challenges you’ll face:

  • Designing management group hierarchy → maps to organizational structure
  • Implementing subscription vending → maps to self-service automation
  • Centralized logging and monitoring → maps to observability at scale
  • Policy-driven governance → maps to guardrails vs. gates

Key Concepts:

Difficulty: Master Time estimate: 1-2 months Prerequisites: All previous projects, enterprise architecture experience

Real world outcome:

# Management group hierarchy
$ az account management-group list --query "[].{Name:name, DisplayName:displayName}"
[
  { "Name": "mg-organization", "DisplayName": "Organization" },
  { "Name": "mg-platform", "DisplayName": "Platform" },
  { "Name": "mg-landing-zones", "DisplayName": "Landing Zones" },
  { "Name": "mg-corp", "DisplayName": "Corp (Internal)" },
  { "Name": "mg-online", "DisplayName": "Online (External)" },
  { "Name": "mg-sandbox", "DisplayName": "Sandbox" }
]

# Self-service subscription request
$ ./subscription-vending request \
    --team "Team Alpha" \
    --environment "Production" \
    --workload-type "webapp"

Subscription Request: SUB-2025-12-001
======================================
Status: Approved (Auto)
Subscription Name: sub-alpha-prod-webapp
Management Group: mg-corp
Budget: $5,000/month
Policies Applied:
  - Require tags (owner, cost-center, environment)
  - Deny public storage accounts
  - Require CMK encryption
  - Enable Defender for Cloud

Network: Spoke VNet created, peered to Hub
  Address Space: 10.50.0.0/16

Deployment Complete: https://portal.azure.com/#@.../subscriptions/abc123

# Policy compliance dashboard
$ az policy state summarize \
    --management-group mg-landing-zones
{
  "results": {
    "resourcesWithPolicies": 1547,
    "compliant": 1489,
    "nonCompliant": 58,
    "compliancePercentage": 96.25
  }
}

Implementation Hints:

Landing zone architecture:

                    [Root Management Group]
                            |
        +-------------------+-------------------+
        |                                       |
   [Platform]                           [Landing Zones]
   - Connectivity                              |
   - Identity                    +-------------+-------------+
   - Management                  |             |             |
                               [Corp]      [Online]     [Sandbox]
                                 |             |             |
                            [Subscriptions per workload]

Subscription vending automation:

1. Team submits request (ServiceNow, GitHub Issue, etc.)
2. Approval workflow (auto-approve sandbox, manual for prod)
3. Bicep deploys:
   - New subscription (or claim from pool)
   - Move to correct management group
   - Apply baseline policies
   - Create spoke VNet, peer to hub
   - Grant team RBAC
   - Register with central monitoring
4. Notify team with access details

Policy layers:

  • Root: Security baselines (Defender, logging)
  • Platform: Connectivity requirements
  • Landing Zones: Workload-specific (PCI, HIPAA)
  • Subscription: Team-specific exemptions

Learning milestones:

  1. MG hierarchy reflects organization → You understand governance structure
  2. Subscriptions are vended automatically → You understand platform automation
  3. Policy prevents non-compliant resources → You understand guardrails
  4. Teams self-serve without bottlenecks → You understand platform engineering

Project 15: Full-Stack DevOps Pipeline

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: YAML (Azure Pipelines)
  • Alternative Programming Languages: GitHub Actions, GitLab CI
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: DevOps / CI/CD / Automation
  • Software or Tool: Azure DevOps, GitHub Actions, Azure Container Registry
  • Main Book: “Continuous Delivery” by Jez Humble & David Farley

What you’ll build: An end-to-end DevOps pipeline: code commit triggers build → unit tests → security scanning → container build → push to ACR → deploy to AKS staging → integration tests → approval gate → deploy to production → smoke tests.

Why it teaches Azure: DevOps is how modern software gets delivered. This project teaches you how to automate everything from commit to production with proper quality gates, security checks, and rollback capabilities.

Core challenges you’ll face:

  • Multi-stage pipeline design → maps to stages, jobs, dependencies
  • Security scanning integration → maps to SAST, container scanning
  • Environment approvals → maps to governance, change management
  • Deployment strategies → maps to blue-green, canary, rolling

Key Concepts:

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 6 and 10, Git proficiency

Real world outcome:

# Push code, watch pipeline
$ git push origin feature/new-feature

# Pipeline execution
Pipeline: myapp-ci-cd
========================================
✅ Stage: Build (2m 15s)
   ├── ✅ Restore dependencies
   ├── ✅ Build application
   └── ✅ Run unit tests (245 passed, 0 failed)

✅ Stage: Security Scan (3m 42s)
   ├── ✅ SAST scan (0 critical, 2 medium, 5 low)
   ├── ✅ Dependency check (0 vulnerable packages)
   └── ✅ Container scan (0 CVEs in base image)

✅ Stage: Build Container (1m 30s)
   └── ✅ Push to ACR: myacr.azurecr.io/myapp:build-1234

✅ Stage: Deploy Staging (4m 20s)
   ├── ✅ Deploy to AKS staging
   ├── ✅ Run integration tests (42 passed)
   └── ✅ Run load test (p95 < 200ms ✓)

⏳ Stage: Deploy Production
   └── ⏳ Waiting for approval...

[Approvers: @platform-team]
[Approve] [Reject]

# After approval
✅ Stage: Deploy Production (5m 10s)
   ├── ✅ Canary deployment (10% traffic)
   ├── ✅ Monitor error rate (< 1% ✓)
   ├── ✅ Full rollout (100% traffic)
   └── ✅ Smoke tests passed

Pipeline: SUCCESS (18m 27s)

Implementation Hints:

Pipeline stages:

stages:
  - stage: Build
    jobs:
      - job: BuildAndTest
        steps:
          - task: DotNetCoreCLI@2  # Build
          - task: DotNetCoreCLI@2  # Test
          - task: PublishTestResults@2

  - stage: Security
    dependsOn: Build
    jobs:
      - job: SAST
      - job: ContainerScan
      - job: DependencyCheck

  - stage: Staging
    dependsOn: Security
    jobs:
      - deployment: DeployStaging
        environment: staging
        strategy:
          runOnce:
            deploy:
              steps: ...

  - stage: Production
    dependsOn: Staging
    jobs:
      - deployment: DeployProduction
        environment: production  # Has approval gate
        strategy:
          canary:
            increments: [10, 50, 100]

Key integrations:

  • Azure Container Registry for images
  • Azure Key Vault for secrets
  • Azure Monitor for deployment health
  • Slack/Teams for notifications

Deployment strategies:

  • Rolling: Replace pods gradually
  • Blue-Green: Switch between two environments
  • Canary: Route percentage of traffic

Learning milestones:

  1. Pipeline triggers on push → You understand CI triggers
  2. Security scanning blocks bad code → You understand DevSecOps
  3. Approval gates control production → You understand governance
  4. Canary catches regressions → You understand progressive delivery

Project Comparison Table

Project Difficulty Time Depth of Understanding Fun Factor
1. Cloud Resource Explorer Beginner Weekend ⭐⭐ ⭐⭐⭐
2. Static Website + CDN Beginner Weekend ⭐⭐ ⭐⭐⭐⭐
3. Multi-Tier Web App Intermediate 1-2 weeks ⭐⭐⭐ ⭐⭐⭐
4. Hub-and-Spoke Network Advanced 1-2 weeks ⭐⭐⭐⭐ ⭐⭐⭐
5. Serverless Pipeline Intermediate 1-2 weeks ⭐⭐⭐ ⭐⭐⭐⭐
6. AKS Microservices Advanced 1 month ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
7. Entra ID Identity Platform Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐
8. Disaster Recovery Expert 2-3 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐
9. FinOps Dashboard Intermediate 1-2 weeks ⭐⭐⭐ ⭐⭐⭐⭐
10. IaC Testing Framework Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐
11. AI-Powered Chat (RAG) Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
12. Zero Trust Security Expert 1 month ⭐⭐⭐⭐⭐ ⭐⭐⭐
13. Hybrid Cloud (Arc) Expert 1 month ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
14. Landing Zone Platform Master 1-2 months ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
15. DevOps Pipeline Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐

If you’re completely new to Azure:

Start with: Project 1 (Resource Explorer) → Project 2 (Static Website) → Project 3 (Multi-Tier App)

This path gives you foundational understanding of Azure’s resource model, IaC basics, and PaaS offerings.

If you’re a developer wanting to build apps:

Start with: Project 3 (Multi-Tier App) → Project 5 (Serverless) → Project 11 (AI Chat)

This path focuses on application development patterns without deep infrastructure concerns.

If you’re an infrastructure/ops person:

Start with: Project 4 (Networking) → Project 8 (DR) → Project 12 (Security) → Project 14 (Landing Zone)

This path builds enterprise infrastructure skills progressively.

If you’re preparing for Azure certifications:

  • AZ-900 (Fundamentals): Projects 1-3
  • AZ-104 (Administrator): Projects 3, 4, 8, 9
  • AZ-305 (Architect): Projects 4, 8, 12, 14
  • AZ-400 (DevOps): Projects 10, 15

Final Capstone Project: Enterprise Cloud Platform

Following the same pattern, this is the culminating project that applies everything learned.

  • File: LEARN_AZURE_CLOUD_DEEP_DIVE.md
  • Main Programming Language: Bicep
  • Alternative Programming Languages: Terraform, Pulumi
  • Coolness Level: Level 5: Pure Magic
  • Business Potential: 5. The “Industry Disruptor”
  • Difficulty: Level 5: Master
  • Knowledge Area: Full Platform Engineering
  • Software or Tool: All Azure Services
  • Main Book: “Cloud Architecture Patterns” by Bill Wilder + “Designing Data-Intensive Applications” by Martin Kleppmann

What you’ll build: A complete enterprise cloud platform combining all previous projects:

  • Landing zone with management groups and subscription vending (Project 14)
  • Hub-and-spoke networking with Zero Trust (Projects 4 & 12)
  • Multi-region, highly available deployment (Project 8)
  • Containerized microservices on AKS (Project 6)
  • Event-driven integrations (Project 5)
  • AI-powered features (Project 11)
  • Full CI/CD automation (Project 15)
  • FinOps governance (Project 9)
  • Hybrid connectivity (Project 13)

Why this is the capstone: This is what enterprise Azure looks like. Building this proves you can architect, implement, secure, and operate production cloud infrastructure at scale.

Core challenges you’ll face:

  • Integration complexity → bringing all pieces together
  • Trade-off decisions → cost vs. reliability vs. performance
  • Operational readiness → monitoring, alerting, runbooks
  • Team enablement → documentation, training, self-service

Real world outcome:

┌─────────────────────────────────────────────────────────────────────────┐
│                    ENTERPRISE CLOUD PLATFORM                            │
│                                                                         │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │                    Management Layer                               │  │
│  │  [Azure DevOps]  [Cost Dashboard]  [Security Center]  [Sentinel]  │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│                                                                         │
│  ┌─────────────────────────────────────────────────────────────────────┐│
│  │                    Platform (Hub)                                   ││
│  │  [Firewall]  [Bastion]  [DNS]  [VPN/ExpressRoute]  [Arc Gateway]   ││
│  └─────────────────────────────────────────────────────────────────────┘│
│                              │                                          │
│          ┌───────────────────┼───────────────────┐                      │
│          │                   │                   │                      │
│  ┌───────┴───────┐   ┌───────┴───────┐   ┌───────┴───────┐              │
│  │ Corp Workloads│   │Online Workload│   │   AI Platform │              │
│  │ (Internal)    │   │ (External)    │   │               │              │
│  │               │   │               │   │               │              │
│  │ [AKS Cluster] │   │ [App Service] │   │[Azure OpenAI] │              │
│  │ [Azure SQL]   │   │ [Cosmos DB]   │   │[AI Search]    │              │
│  │ [Functions]   │   │ [Front Door]  │   │[Functions]    │              │
│  └───────────────┘   └───────────────┘   └───────────────┘              │
│                                                                         │
│  ┌─────────────────────────────────────────────────────────────────────┐│
│  │                    DR Region (Passive)                              ││
│  │  [Replicated Resources]  [Site Recovery]  [Geo-Replicated Storage] ││
│  └─────────────────────────────────────────────────────────────────────┘│
│                                                                         │
│  ┌─────────────────────────────────────────────────────────────────────┐│
│  │                    Hybrid (On-Premises)                             ││
│  │  [Arc-enabled Servers]  [Arc-enabled K8s]  [ExpressRoute]          ││
│  └─────────────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────────────┘

Learning milestones:

  1. Platform deploys end-to-end → You’ve mastered IaC at scale
  2. Teams self-serve subscriptions → You’ve built a platform product
  3. DR failover succeeds → You’ve proven reliability
  4. Secure Score > 90% → You’ve implemented Zero Trust
  5. Monthly costs are optimized → You’ve mastered FinOps

Summary

# Project Main Language
1 Cloud Resource Explorer CLI Python
2 Static Website with CDN Pipeline Bicep
3 Multi-Tier Web Application C# (.NET)
4 Virtual Network Hub-and-Spoke Bicep
5 Event-Driven Serverless Pipeline Python
6 Container-Based Microservices (AKS) Go
7 Identity Platform with Entra ID C#
8 Disaster Recovery & High Availability Bicep
9 Cost Management & FinOps Dashboard Python
10 Infrastructure as Code Testing Framework Python
11 AI-Powered Chat Application (RAG) Python
12 Zero Trust Security Implementation Bicep
13 Hybrid Cloud with Azure Arc Bicep
14 Platform Engineering Landing Zone Bicep
15 Full-Stack DevOps Pipeline YAML (Azure Pipelines)
Capstone Enterprise Cloud Platform Bicep

Additional Resources

Official Documentation

Certifications

Community Resources

Books (from your library)

  • “Designing Data-Intensive Applications” by Martin Kleppmann - for distributed systems concepts
  • “The DevOps Handbook” by Gene Kim et al. - for DevOps practices
  • “Clean Architecture” by Robert C. Martin - for application architecture
  • “Fundamentals of Software Architecture” by Mark Richards & Neal Ford - for architectural thinking

Generated for your Azure Cloud learning journey. Start with the fundamentals, build progressively, and you’ll have enterprise-grade Azure skills.