S068 · Azure Cloud — Identity, Storage, Networking, App Service

Module M07: Systems & Infrastructure · Session 68 of 130 · Track: SYS ☁️

What you'll be able to do after this session

• Explain Azure Cloud to a friend in one minute, out loud, no notes.
• Recognise it when you see it in real code / systems / papers.
• Complete the hands-on exercise at the end without looking up help.

Prerequisites

If you can't answer these in 30 seconds each, redo the linked session first:

• S066 — Kubernetes I — Pods, Deployments, Services

Pre-read (skim before the session)

• 🎥 Intuition (5–15 min) · Azure Fundamentals in 20 min (John Savill) — the shortest sharpest orientation to Azure's core surfaces.
• 🎥 Deep dive (30–60 min) · Azure Networking Master Class (John Savill) — VNets, subnets, NSGs, peering, from scratch in 90 min.
• 🎥 Hands-on demo (10–20 min) · Deploy a web app to Azure App Service (Microsoft Reactor) — click-and-code walk-through in ~15 min.
• 📖 Canonical article · Azure Docs — Fundamental concepts — official reference to subscriptions, resource groups, regions, and the shared responsibility model.
• 📖 Book chapter / tutorial · Microsoft Learn — Azure Administrator learning path — free, hands-on, aligns to AZ-104 exam.
• 📖 Engineering blog · Microsoft — Inside Azure Datacenter Architecture — Mark Russinovich's deep dive into how the platform is actually built.

(a) Intuition · 5 min

The one-paragraph mental model. Why this concept exists, what problem it solves, and the analogy that makes it stick.

In one sentence: The cloud you actually use.

The cloud is a rented data centre. Azure specifically is Microsoft's version, spread across ~60 regions worldwide, each with 2-3 availability zones (physically separate buildings on the same low-latency network). Instead of buying servers, you rent compute, storage, networking, identity, and higher-level services (databases, ML endpoints, event hubs) by the second. You never touch a physical machine, but you gain the ability to scale from 1 to 10 000 machines in minutes — and shrink back to zero when idle.

Four pillars carry 90% of what you'll do on Azure:

• Identity & access — Entra ID (formerly Azure AD): every resource is owned by a subscription, every action authenticated by a user/group/service-principal, every permission granted via RBAC roles. Understand this before anything else — misconfigured identity is the #1 cloud security incident.
• Storage — Blob Storage (S3 equivalent — object storage for files/backups/data-lake), Azure Files (SMB/NFS shares), Managed Disks (block storage attached to VMs), Cosmos DB (managed NoSQL). Choose based on access pattern and durability.
• Networking — VNet (your private IP address space), subnet, NSG (Network Security Group — stateful firewall), VNet peering, Private Endpoint (bring PaaS services into your VNet). Everything else runs inside this networking substrate.
• Compute — VMs (raw IaaS), App Service (managed PaaS for web apps), Container Apps / AKS (containers), Functions (serverless). Move up the stack when you don't want to manage the OS.

Forever-gotcha: A Resource Group is a lifecycle boundary, not a security boundary. Everything in a Resource Group can be deleted with one command; permissions on RG apply to everything in it. Design RG layout around "things that live and die together" and "who owns them", not around technical stacks.

(b) Visual walkthrough · 15 min

Diagrams, worked examples, step-by-step visuals.

Storage tier decision table:

Compute ladder — pick the highest rung you can afford to sit on:

Worked example — deploy a web app with a database, secured:

1. Create Resource Group rg-blog-prod in region centralindia.
2. Create VNet vnet-blog (10.20.0.0/16) with two subnets: snet-web and snet-db.
3. Deploy Azure App Service into snet-web via VNet integration.
4. Deploy Azure SQL DB with a Private Endpoint in snet-db — the DB has no public endpoint.
5. Create NSG on snet-db: allow inbound 1433 from snet-web only, deny everything else.
6. Store DB connection string in Key Vault and reference via App Service's Managed Identity.
7. Front it with Azure Front Door for CDN + WAF + global routing.
8. Turn on Log Analytics on both App Service and SQL; wire up alerts.

Each of those steps is 3-5 clicks in the portal or 3-5 lines in Bicep/Terraform.

(c) Hands-on · 20 min

Code you type and run. Not pseudo-code — real, runnable, copy-pasteable.

Two paths: (A) az CLI to spin up a small resource group with a web app + storage, (B) mirror as Bicep for repeatability. Requires az CLI installed and az login completed.

# ---- A) Provision via az CLI ----
RG=rg-learn-$(date +%s)
LOC=centralindia
APP=learn-app-$RANDOM
STOR=learnstor$RANDOM  # storage names lowercase, no dashes, globally unique
 
# 1) Resource group
az group create -n $RG -l $LOC
 
# 2) Storage account with a private blob container
az storage account create -n $STOR -g $RG -l $LOC --sku Standard_LRS --kind StorageV2
az storage container create --account-name $STOR -n uploads --auth-mode login
 
# 3) App Service plan (Linux, F1 free tier) + Web App with Python runtime
az appservice plan create -n plan-$APP -g $RG --sku F1 --is-linux
az webapp create -g $RG --plan plan-$APP -n $APP --runtime "PYTHON:3.12"
 
# 4) App settings (env vars visible to the app)
az webapp config appsettings set -g $RG -n $APP --settings   STORAGE_ACCOUNT=$STOR   FEATURE_FLAG=on
 
# 5) Enable system-assigned managed identity, grant it read on storage
PRINCIPAL=$(az webapp identity assign -g $RG -n $APP --query principalId -o tsv)
STORAGE_ID=$(az storage account show -n $STOR -g $RG --query id -o tsv)
az role assignment create --assignee $PRINCIPAL   --role "Storage Blob Data Reader" --scope $STORAGE_ID
 
# 6) Deploy a tiny app
mkdir /tmp/az-app && cd /tmp/az-app
cat > app.py <<'EOF'
from flask import Flask
import os
app = Flask(__name__)
@app.get("/")
def hi():
    return f"hello from {os.getenv('WEBSITE_INSTANCE_ID','local')} · flag={os.getenv('FEATURE_FLAG','off')}
"
EOF
cat > requirements.txt <<'EOF'
flask==3.0.0
gunicorn==22.0.0
EOF
zip app.zip app.py requirements.txt
az webapp deploy -g $RG -n $APP --src-path app.zip --type zip
 
# 7) Test
curl https://$APP.azurewebsites.net/
 
# 8) Tear it all down
az group delete -n $RG --yes --no-wait

Checklist — what to observe:

1. az group create returns a JSON blob; every resource you make lives under this RG. Deleting the RG deletes everything — this is your safety net.
2. Storage names are globally unique (like DNS); if learnstor12345 is taken you'll get an error.
3. The managed identity means your app never needs to store a key or password to read blobs — Azure handles auth transparently. This is the modern "no secrets in code" pattern.
4. App settings (step 4) become environment variables at runtime; changing them restarts the app automatically.
5. In portal: Monitor → Log Analytics shows structured logs from App Service; Diagnose and solve problems runs guided troubleshooting.

Try this modification (Bicep): convert the above to main.bicep and deploy with az deployment group create --template-file main.bicep -g $RG. Bicep is Azure's native IaC (transpiles to ARM JSON). This gives you review-able, reproducible infra — same result, next time takes 30 seconds not 5 minutes of clicking. We'll cover this properly in the next session.

(d) Production reality · 10 min

How this shows up in real systems, gotchas, war stories, common bugs.

War story #1 — the exposed storage account. A team created a blob container as "Public read" for "just this one dashboard image". A month later, an attacker enumerated the account and found backups from other containers made public by copy-paste. Millions of user records leaked. Rule: storage accounts default to private; use Private Endpoints + SAS tokens with short expiry when you need to share.

War story #2 — the run-away subscription. A junior dev spun up an 8-VM cluster to test something, forgot about it, and left it running over the weekend. Monday: ₹3 lakh Azure bill. Fixes: Azure Cost Management alerts, auto-shutdown on VMs (az vm auto-shutdown), Policy that denies expensive SKUs in dev subscriptions, tag-based ownership so you can find "whose VM is this?".

War story #3 — the identity blast radius. A misconfigured service principal had Contributor on the whole subscription. When its cert was compromised, the attacker deleted every RG. Rule: least-privilege RBAC (Reader first, then narrow scopes); Just-In-Time access via Privileged Identity Management (PIM); short-lived credentials via managed identities always preferred over long-lived secrets.

Common gotchas & how top teams handle them:

• Region asymmetry. Not every service exists in every region; new features roll out to US East first. Pin regions in your architecture and check the availability matrix.
• Zone-redundant storage. ZRS/GZRS cost more but survive an entire zone loss. LRS is cheap and single-zone — fine for logs, dangerous for critical data.
• App Service cold starts. Consumption / free tiers cold-start after inactivity. Real production runs on P1v3+ or uses Always On.
• Networking pitfalls. VNet peering isn't transitive (A↔B, B↔C ≠ A↔C). Use Virtual WAN or Hub-and-Spoke topologies at scale.
• Backup ≠ high availability. Azure SQL is highly available inside a region, but region-loss recovery needs geo-replication + tested failover drills.
• Terraform state on Azure. Store remote state in an Azure Storage container with locking (blob lease). Local state = merge conflicts + drift disasters.
• Cost governance: enforce tags via Azure Policy, use Budgets with action-groups (auto-email at 80%, auto-page at 100%). Big shops save 30-50% just by right-sizing SKUs and killing zombie resources monthly.

Microsoft's own Azure Well-Architected Framework (5 pillars: reliability, security, cost, operational excellence, performance) is the canonical checklist — read it before designing anything real.

(e) Quiz + exercise · 10 min

1. Explain the hierarchy Tenant → Subscription → Resource Group → Resource in one sentence each.
2. When would you pick App Service vs AKS vs Functions?
3. What's the difference between a Storage Account, a Blob container, and Managed Disks?
4. Why is a managed identity better than storing a client secret in App Settings?
5. Give one thing that a Resource Group is and one thing it is not.

Stretch problem (connects to S062 — Load Balancers): Azure has four+ load-balancing services: Load Balancer (L4), Application Gateway (L7 regional + WAF), Front Door (L7 global CDN + WAF), Traffic Manager (DNS-based global routing). Pick the right one for each scenario: (a) global consumer web app with active-active regions, (b) internal microservice within a VNet, (c) legacy TCP protocol between two subnets, (d) HTTP API with path-based routing to 4 backends inside one region. Justify each in one line.

Explain-out-loud test

If you can't teach these 3 things to a friend without notes, redo the session:

1. What is Azure Cloud? (one sentence, no jargon)
2. When would you use it? (one concrete example)
3. When would you NOT use it? (one anti-pattern)

What comes next

• Next session (S069): Infrastructure as Code — Terraform / Bicep Basics
• Previous (S067): Kubernetes II — ConfigMaps, Secrets, HPA, Network Policies
• Hub: The 6-Month Learning Plan

Part of a 130-session evergreen learning series. Session structure: (a) intuition · (b) visual walkthrough · (c) hands-on · (d) production reality · (e) quiz + exercise. Duration: 60 minutes.