Azure = Microsoft's cloud computing platform
Offers 200+ services across multiple categories.

Key Service Categories:
┌─────────────────────────────────────────────┐
│  Compute      → VMs, App Service, Functions │
│  Networking   → VNet, Load Balancer, CDN    │
│  Storage      → Blob, File, Queue, Table    │
│  Database     → Azure SQL, Cosmos DB        │
│  AI / ML      → Cognitive Services, ML      │
│  DevOps       → Pipelines, Repos, Boards    │
│  Security     → Azure AD, Key Vault, RBAC   │
└─────────────────────────────────────────────┘

Service Models:
- IaaS → Infrastructure (VMs, VNet, Storage)
- PaaS → Platform (App Service, Azure SQL)
- SaaS → Software (Microsoft 365, Dynamics)

Azure Geography:
- Regions (60+) → Availability Zones (3 per region)
- Resource Groups → logical containers
- Subscriptions → billing boundary
- Management Groups → organize subscriptions

Hierarchy:
Management Group > Subscription > Resource Group > Resource

Shared Responsibility Model:

                IaaS        PaaS        SaaS
┌──────────┬───────────┬───────────┬───────────┐
│ Data     │ You       │ You       │ You       │
│ App      │ You       │ You       │ Provider  │
│ Runtime  │ You       │ Provider  │ Provider  │
│ OS       │ You       │ Provider  │ Provider  │
│ Server   │ Provider  │ Provider  │ Provider  │
│ Network  │ Provider  │ Provider  │ Provider  │
│ Storage  │ Provider  │ Provider  │ Provider  │
└──────────┴───────────┴───────────┴───────────┘

Azure Examples:
IaaS → Virtual Machines, Virtual Network, Disks
  You manage: OS, runtime, app, data
  Azure manages: physical hardware, networking

PaaS → App Service, Azure SQL Database, Functions
  You manage: app code, data
  Azure manages: OS, patching, scaling, infra

SaaS → Microsoft 365, Dynamics 365, Power BI
  You manage: data, user configuration
  Azure manages: everything else

When to use:
IaaS → legacy apps, full control needed, custom OS
PaaS → web apps, APIs, focus on code not infra
SaaS → productivity tools, CRM, email

Three compute options, three different use cases:

┌─────────────────┬──────────────┬──────────────┐
│   Azure VMs     │ App Service  │  Functions   │
├─────────────────┼──────────────┼──────────────┤
│ IaaS            │ PaaS         │ Serverless   │
│ Full OS control │ Managed      │ Event-driven │
│ You patch OS    │ Auto-patched │ No server    │
│ Always running  │ Always on    │ On-demand    │
│ Pay per hour    │ Pay per plan │ Pay per exec │
└─────────────────┴──────────────┴──────────────┘

When to use VMs:
- Legacy applications that need specific OS
- Custom software installations
- Full control over environment
- Lift-and-shift migrations

When to use App Service:
- Web apps and APIs
- No need to manage infrastructure
- Built-in CI/CD, SSL, custom domains
- Auto-scaling without VM management

When to use Azure Functions:
- Event-driven processing (file upload, queue msg)
- Scheduled tasks (cron jobs)
- Microservices with sporadic traffic
- Pay only when code runs (cost-efficient)

Cost comparison (approximate):
VM (B2s):     ~₹3,000/month (always running)
App Service:  ~₹5,000/month (Basic plan)
Functions:    ~₹0 to ₹500/month (consumption)

VNet = your private network in Azure
Think of it as your own data center network in the cloud.

Key Components:
┌─────────────────────────────────────────┐
│              VNet (10.0.0.0/16)         │
│  ┌──────────────┐  ┌──────────────┐    │
│  │ Subnet A     │  │ Subnet B     │    │
│  │ 10.0.1.0/24  │  │ 10.0.2.0/24  │    │
│  │ [Web VMs]    │  │ [DB VMs]     │    │
│  │ NSG: Allow   │  │ NSG: Deny    │    │
│  │ HTTP/HTTPS   │  │ public       │    │
│  └──────────────┘  └──────────────┘    │
└─────────────────────────────────────────┘

Subnets → divide VNet into segments
NSGs (Network Security Groups) → firewall rules
  - Inbound/outbound rules
  - Allow or deny traffic by port, IP, protocol

VNet Peering → connect two VNets
  - Traffic stays on Azure backbone (private)
  - Can peer across regions (global peering)

VPN Gateway → connect on-premises to Azure
  - Site-to-Site VPN (office to Azure)
  - Point-to-Site VPN (laptop to Azure)

ExpressRoute → dedicated private connection
  - Does NOT go over public internet
  - Higher bandwidth, lower latency
  - Used by enterprises (banks, large IT companies)

How VMs communicate:
- Same VNet → automatic (by private IP)
- Different VNets → need peering or VPN
- Internet → need public IP or NAT Gateway

Two different load balancing services:

Azure Load Balancer (Layer 4 — TCP/UDP):
┌─────────────────────────────────────────┐
│ Works at transport layer (TCP/UDP)      │
│ Does NOT inspect HTTP content           │
│ Fast, low-latency                       │
│ Use for: non-HTTP traffic, internal LB  │
│ Example: distribute TCP traffic to VMs  │
└─────────────────────────────────────────┘

Application Gateway (Layer 7 — HTTP/HTTPS):
┌─────────────────────────────────────────┐
│ Works at application layer (HTTP/HTTPS) │
│ CAN inspect HTTP headers, URLs, cookies │
│ Features:                               │
│   - URL-based routing (/api → backend)  │
│   - SSL termination (offload HTTPS)     │
│   - Web Application Firewall (WAF)      │
│   - Cookie-based session affinity       │
│   - WebSocket support                   │
│ Use for: web apps, APIs, microservices  │
└─────────────────────────────────────────┘

When to use which:
Load Balancer → internal services, TCP/UDP, VMs
App Gateway → web apps, need WAF, URL routing

Azure Front Door → global HTTP load balancing
  - CDN + WAF + global routing
  - For multi-region applications

Azure Storage Account provides 4 services:

1. Blob Storage (Binary Large Objects)
   - Unstructured data: files, images, videos, backups
   - Types: Block blobs, Append blobs, Page blobs
   - Containers organize blobs (like folders)

2. Table Storage
   - NoSQL key-value store
   - Cheap, fast for simple structured data
   - No complex queries (use Cosmos DB instead)

3. Queue Storage
   - Message queue for async processing
   - Max message size: 64 KB
   - Used for decoupling services

4. File Storage (Azure Files)
   - SMB file shares in the cloud
   - Mount as network drive on Windows/Linux
   - Replace on-premises file servers

Access Tiers (Blob Storage):
┌──────────┬────────────┬──────────────────┐
│ Tier     │ Cost       │ Use Case         │
├──────────┼────────────┼──────────────────┤
│ Hot      │ High store │ Frequent access  │
│          │ Low access │ Active data      │
├──────────┼────────────┼──────────────────┤
│ Cool     │ Low store  │ Infrequent       │
│          │ High access│ 30+ days old     │
├──────────┼────────────┼──────────────────┤
│ Archive  │ Lowest     │ Rarely accessed  │
│          │ Highest    │ 180+ days old    │
│          │ access     │ Hours to retrieve│
└──────────┴────────────┴──────────────────┘

Redundancy Options:
LRS → 3 copies in one data center
ZRS → 3 copies across availability zones
GRS → 6 copies across two regions
RA-GRS → GRS + read access to secondary

Two database services, very different use cases:

Azure SQL Database:
┌─────────────────────────────────────────┐
│ Relational database (SQL Server in cloud)│
│ Structured data with schemas            │
│ ACID transactions                       │
│ Complex JOINs and queries               │
│ Single-region (with geo-replication)    │
│ Best for: ERP, CRM, financial apps      │
└─────────────────────────────────────────┘

Azure Cosmos DB:
┌─────────────────────────────────────────┐
│ NoSQL, globally distributed             │
│ Multi-model (multiple APIs)             │
│ Single-digit millisecond latency        │
│ Automatic multi-region replication      │
│ 5 consistency levels                    │
│ Best for: IoT, gaming, global apps      │
└─────────────────────────────────────────┘

Cosmos DB APIs:
- SQL API (document, JSON) ← most popular
- MongoDB API (MongoDB compatible)
- Cassandra API (wide-column)
- Gremlin API (graph database)
- Table API (key-value, replaces Table Storage)

Decision guide:
Need ACID + complex queries → Azure SQL
Need global distribution → Cosmos DB
Need schema flexibility → Cosmos DB
Need relational integrity → Azure SQL
Budget-conscious → Azure SQL (cheaper)
Multi-region low latency → Cosmos DB

Azure AD (now Microsoft Entra ID) = cloud identity service

What it does:
- Authentication → "Who are you?" (verify identity)
- Authorization → "What can you do?" (permissions)

Key Features:
┌─────────────────────────────────────────┐
│ SSO (Single Sign-On)                    │
│   → One login for all apps              │
│                                         │
│ MFA (Multi-Factor Authentication)       │
│   → Password + phone/app verification   │
│                                         │
│ Conditional Access                      │
│   → Rules: "If location=unknown,        │
│     require MFA"                        │
│                                         │
│ Service Principals                      │
│   → App identities (not human users)    │
│   → Used for CI/CD, automation          │
│                                         │
│ Managed Identities                      │
│   → Azure resources authenticate to     │
│     other Azure resources (no passwords)│
└─────────────────────────────────────────┘

Azure AD vs On-Premises AD:
On-Prem AD → LDAP, Kerberos, domain-joined PCs
Azure AD → OAuth 2.0, SAML, cloud apps
Azure AD Connect → syncs on-prem AD to Azure AD
  (hybrid identity for enterprises)

Azure DevOps = suite of development tools

5 Services:
┌─────────────────────────────────────────┐
│ Boards    → Work tracking (like Jira)   │
│ Repos     → Git repositories            │
│ Pipelines → CI/CD automation            │
│ Test Plans→ Manual/automated testing    │
│ Artifacts → Package management (npm,    │
│             NuGet, Maven)               │
└─────────────────────────────────────────┘

CI/CD Pipeline (YAML example):
trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '18.x'

  - script: npm ci
    displayName: 'Install dependencies'

  - script: npm run build
    displayName: 'Build'

  - script: npm test
    displayName: 'Run tests'

  - task: AzureWebApp@1
    inputs:
      azureSubscription: 'my-subscription'
      appName: 'my-web-app'
      package: '$(System.DefaultWorkingDirectory)'

Azure DevOps vs GitHub Actions:
- Azure DevOps → enterprise, full ALM suite
- GitHub Actions → open source, GitHub-native
- Both support YAML pipelines
- Many Indian enterprises use Azure DevOps

RBAC = Role-Based Access Control
Controls WHO can do WHAT on WHICH resources.

Built-in Roles:
┌──────────────┬──────────────────────────┐
│ Owner        │ Full access + can assign │
│              │ roles to others          │
├──────────────┼──────────────────────────┤
│ Contributor  │ Full access but CANNOT   │
│              │ assign roles             │
├──────────────┼──────────────────────────┤
│ Reader       │ View only, no changes    │
└──────────────┴──────────────────────────┘

Scope Hierarchy (roles inherit downward):
Management Group
  └── Subscription
       └── Resource Group
            └── Resource

Example:
"Reader" at Subscription level
  → can view ALL resource groups and resources

"Contributor" at Resource Group level
  → can modify resources in THAT group only

Custom Roles:
{
  "Name": "VM Operator",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action"
  ],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/{sub-id}"]
}

Principle of Least Privilege:
→ Give minimum permissions needed
→ Use Reader by default
→ Elevate only when required
→ Review access regularly