​

Azure Fundamentals & Architecture

​

What You’ll Learn

• What cloud computing actually is (and why it exists)
• How Azure’s physical infrastructure works
• The shared responsibility model (who does what)
• How to choose between different service models
• Azure’s global architecture (regions, zones, datacenters)
• Core design principles (CAP theorem, availability, consistency)
• How to make architectural decisions confidently

​

Introduction: What is Cloud Computing?

​

The Problem Before Cloud Computing

Cost: $10,000+ per server
- Physical server (Dell, HP)
- Storage drives
- Networking equipment
- Cables, racks, power supplies

Timeline: 4-8 weeks to arrive

Options:
A) Your office closet
   - Risk: Power outage = website down
   - Risk: Fire, flood, theft
   - No backup power or cooling

B) Rent datacenter space ($500-2000/month)
   - Must sign long-term contract (1-3 years)
   - Must pay even if you shut down

Tasks:
- Install operating system (Windows/Linux)
- Configure networking
- Install web server software
- Set up databases
- Configure backups
- Set up monitoring

Skills needed: System administrator
Timeline: 1-2 weeks

Ongoing work:
- Apply security patches monthly
- Replace failed hardware
- Upgrade when traffic grows
- Monitor 24/7 for outages
- Handle backups manually

Cost: 1-2 full-time IT staff

1. Huge upfront cost ($10,000+ before you have any customers)
2. Slow (2+ months from idea to website)
3. Fixed capacity (bought 1 server, but what if you need 10? Or only need 0.5?)
4. Your problem if it breaks (hardware failure at 2 AM? You fix it)
5. Wasted money (server sitting idle 90% of time, but you paid full price)

​

The Cloud Solution

Cost: $0 upfront, pay ~$0.01/hour (~$7/month for small server)
Timeline: 5 minutes
Method: Click a few buttons in a web browser

Microsoft's responsibility:
- 300+ datacenters worldwide
- Backup power (generators + batteries)
- Physical security (guards, cameras, locks)
- Fire suppression, cooling systems
- Network connectivity
- Hardware replacement

Your cost: $0 (included in the hourly rate)

Available:
- Choose operating system from a menu
- Web server software pre-installed (if you want)
- Database already running (if you want)
- Automatic backups (if you want)
- Monitoring built-in

Timeline: Already done (part of the 5 minutes)

Microsoft handles:
- Security patches (automatic)
- Hardware failures (automatic replacement)
- Scaling (add more servers automatically)
- 24/7 monitoring (built-in)

Your time investment: Hours per month, not days per week

1. No upfront cost (pay only for what you use, like electricity)
2. Instant (5 minutes from idea to working website)
3. Flexible capacity (need more? Add instantly. Need less? Remove instantly)
4. Microsoft’s problem if hardware breaks (they replace it, you don’t even notice)
5. Save money (only pay when running; stop paying when not needed)

​

Real-World Analogy: Owning vs. Renting

• Buy the car ($30,000)
• Maintenance costs (oil, tires, repairs)
• Insurance
• Parking space
• Sits unused in driveway 90% of the time
• Your problem if it breaks

• Pay only when you need a ride
• No maintenance
• No insurance
• No parking
• If the car breaks, they send another one
• Scale instantly (need 10 cars for a wedding? Done)

​

What is Microsoft Azure?

1. A giant worldwide network of datacenters (300+ buildings full of computers)
2. Software that lets you rent those computers (by the hour, by the second)
3. Pre-built services (databases, networking, AI, etc.)
4. Tools to manage everything (web portal, command-line, APIs)

• On-demand: Get resources when you need them, instantly
• Self-service: No need to call Microsoft and wait
• Pay-as-you-go: Like electricity, pay only for what you use
• Elastic: Scale up and down automatically
• Managed: Microsoft maintains the physical infrastructure

​

Why Would YOU Use Azure? (Real Scenarios)

Challenge: Need a website, but have $0 for hardware
Solution:
- Azure free tier gives you free compute for 12 months
- Pay ~$20/month for a small website
- If startup fails, you stop paying (vs. $10,000 wasted on servers)
- If startup succeeds, scale to millions of users instantly

Challenge: Black Friday traffic is 100x normal days
Old way:
- Buy 100 servers for Black Friday ($500,000)
- Servers sit unused 364 days/year
- Still must pay for power, cooling, maintenance

Azure way:
- Run 1 server normally ($100/month = $1,200/year)
- Auto-scale to 100 servers for Black Friday (1 day)
- Cost for Black Friday: $100 × 100 servers × 1 day ≈ $330
- Total yearly cost: $1,200 + $330 = $1,530 (vs. $500,000)

Challenge: Users in US, Europe, and Asia need fast access
Old way:
- Build datacenters in 3 continents ($5+ million)
- Hire staff in each location
- Network them together

Azure way:
- Deploy to 3 Azure regions with a few clicks
- Microsoft already has datacenters there
- Global network already built
- Cost: ~$300/month (vs. $5 million)

​

Key Cloud Concepts (Explained Simply)

A virtual machine is a software-based computer running on physical hardware. Think of it like this: Microsoft has a massive physical server. Using virtualization software, they split that one physical server into 10 “virtual” servers. Each virtual server thinks it’s a real computer with its own CPU, memory, and storage. Analogy: It’s like splitting a large house into 10 separate apartments. Each apartment has its own kitchen, bathroom, and living space, even though they’re all in the same building.

A computer designed to run 24/7, serving requests from other computers. Your laptop is a client (makes requests), a server responds to requests. Example: When you visit a website, your browser (client) sends a request to a web server, which sends back the web page.

A building full of servers, networking equipment, power systems, and cooling systems. Azure has 300+ datacenters worldwide. Analogy: Like a massive parking garage, but instead of cars, it’s filled with thousands of computers running 24/7.

The ability to run programs and process data. Measured in CPU cores (like having multiple workers) and RAM (like having a larger desk to work on).

Where data is permanently saved. Like a hard drive, but in the cloud. Types you’ll learn:

• Blob Storage: For files (images, videos, documents)
• Disk Storage: For virtual machine hard drives
• Database Storage: For structured data (customer info, orders)

How computers talk to each other. In Azure, you’ll create virtual networks (like a private network in the cloud).

​

Cloud Economics: The Financial “Why”

​

CAPEX vs. OPEX

​

Total Cost of Ownership (TCO)

1. Power & Cooling: Electricity isn’t free. Servers need lots of it, and 24/7 HVAC.
2. Floor Space: The rent for the room where the server sits.
3. IT Labor: Salary of people to rack servers, replace failed drives, and manage the physical network.
4. Opportunity Cost: The time your engineer spends fixing hardware is time they aren’t building features that make you money.

[!IMPORTANT] Pro Insight: The Agility Premium You aren’t just paying for a computer; you’re paying for the ability to get 1,000 computers in 5 minutes. This “agility” allows businesses to experiment and fail fast without losing millions in hardware.

​

How Azure Actually Works (Behind the Scenes)

​

The Physical Layer

Azure Datacenter (East US Region):
├── Building
│   ├── Size: 20-40 acres (equivalent to 15-30 football fields)
│   ├── Power: 10-20 megawatts (enough for a small city)
│   ├── Backup power: Diesel generators + UPS batteries
│   ├── Cooling: Massive HVAC systems (servers get HOT)
│   └── Security: Guards, cameras, biometric access
│
├── Server Racks (thousands of them)
│   └── Each rack contains:
│       ├── 40-50 servers (each server = powerful computer)
│       ├── Networking switches
│       ├── Power distribution units
│       └── Total: 50,000-80,000 servers per datacenter
│
└── Your Virtual Machine
    └── Actually runs on: 1 slice of 1 server
        ├── Your VM shares physical server with ~10 other VMs
        ├── Hypervisor software keeps them isolated
        └── You never know (or care) which physical server

1. You click “Create VM” in Azure portal
2. Azure’s software (called the fabric controller):
   • Finds a physical server with available capacity
   • Might be in any rack in the datacenter
   • Allocates portion of CPU/RAM to your VM
3. Hypervisor (Microsoft Hyper-V):
   • Creates a virtual machine on that physical server
   • Gives your VM 2 vCPUs, 4 GB RAM (or whatever you requested)
   • Ensures your VM is isolated from other VMs on same server
4. Your VM boots up:
   • Installs the operating system you chose
   • Connects to the virtual network you specified
   • Assigns an IP address
   • Ready to use in 2-5 minutes

​

The Virtualization Layer

• 64 CPU cores
• 512 GB RAM
• 10 TB storage

Physical Server (64 cores, 512 GB RAM)
├── VM 1: 2 cores, 4 GB RAM (Your web server)
├── VM 2: 4 cores, 16 GB RAM (Someone else's database)
├── VM 3: 2 cores, 4 GB RAM (Another customer's app)
├── VM 4: 8 cores, 32 GB RAM (Another customer's server)
├── ... (20+ more VMs)
└── Hypervisor manages them all, keeps them isolated

Result:
- You pay only for 2 cores and 4 GB RAM
- Microsoft sells the same physical server to 30 customers
- Everyone gets their own isolated "computer"
- Much cheaper for you, more profitable for Microsoft (win-win)

• The hypervisor provides hardware-level isolation
• You cannot access another VM’s memory or data
• It’s like living in an apartment building:
  • You share the building with neighbors
  • But you can’t access their apartment
  • You can’t hear their conversations (proper isolation)
  • You have your own key (security)

[!TIP] Jargon Alert: Data Residency The physical location where your data is stored. Some countries (like Germany or China) have strict laws requiring citizen data to never leave the country’s borders. Azure lets you choose which region stores your data.

[!WARNING] Gotcha: Region Availability Not all Azure services are available in all regions. Always check the “Azure Products by Region” page before architecting a solution, especially for newer services.

​

Management Architecture: Azure Resource Manager (ARM)

​

The Management Plane vs. Data Plane

1. Management Plane (ARM): This is the “control room.” It’s where you create, update, and delete resources. When you change a VM’s size or update a firewall rule, you are talking to the Management Plane.
2. Data Plane: This is the “resource itself.” It’s the traffic flowing through your VM, the queries hitting your database, or the files being uploaded to storage.

[!IMPORTANT] Pro Tip: Partitioning Failure A failure in the Management Plane means you cannot change things (e.g., you can’t create a new VM). However, your existing resources (the Data Plane) usually continue to run unaffected.

​

How ARM Works

1. Consistent API: Whether you use the Portal or a script, they all talk to the same ARM API (management.azure.com).
2. Authentication: ARM checks who you are (Entra ID).
3. Authorization: ARM checks what you can do (RBAC).
4. Resource Providers: ARM forwards the request to the specific service (e.g., Microsoft.Compute for VMs).

​

Why Professionals Love ARM

• Declarative Templates: You describe what you want (e.g., “I want a Linux VM with 4GB RAM”) rather than how to build it step-by-step.
• Idempotency: You can run the same deployment 100 times. If the resource already exists and matches your description, ARM does nothing. If it’s missing, ARM creates it.
• Resource Groups: Logical containers that allow you to manage the lifecycle of an entire application as a single unit.

​

1. The Shared Responsibility Model

​

Why This Model Exists

• Building structure (walls, roof, foundation)
• Building systems (heating, plumbing, electricity)
• Common areas (hallways, elevators)
• Building security (locks on main entrance)

• What’s inside your apartment (furniture, belongings)
• Locking your own door
• Who you let in
• What you do inside

​

The Critical Question: “If Something Goes Wrong, Who Fixes It?”

• Who fixes it? Microsoft
• Why? It’s their hardware in their datacenter
• What do you do? Nothing. Azure automatically moves your VM to another server. You might not even notice.

• Who fixes it? YOU
• Why? You wrote the application code with the vulnerability
• What does Microsoft do? Nothing. Your code, your problem.

• Who fixes it? Depends on the service!
  • IaaS (VM): YOU must install the patch
  • PaaS (App Service): Microsoft installs it automatically
  • SaaS (Office 365): Microsoft handles everything

​

The Three Service Models (IaaS, PaaS, SaaS)

​

IaaS (Infrastructure as a Service)

Landlord provides:
- Building (datacenter)
- Walls and roof (server hardware)
- Utilities hookups (network connectivity)

You provide:
- All furniture (operating system)
- Decorations (applications)
- Everything inside (data)
- Your own locks (firewall rules)

Microsoft Manages:
✓ Physical datacenter (building, power, cooling)
✓ Physical network (cables, routers, switches)
✓ Physical hosts (the actual server hardware)
✓ Hypervisor (software that runs virtual machines)

You Manage:
✓ Operating System (Windows/Linux)
✓ Applications (web servers, databases, your code)
✓ Data (everything you store)
✓ Network configuration (NSGs, firewall rules)
✓ Identity and access (who can log in)
✓ Patching and updates (YOU must install security patches)

Company has 10-year-old accounting software
- Only runs on Windows Server 2012 R2
- Uses specific printer drivers
- Requires 32-bit DLL files

Solution: Azure VM running Windows Server 2012 R2
Why: PaaS doesn't support custom OS versions
Trade-off: Company must manage security patches themselves

Landlord provides:
- Building (datacenter)
- Furniture (operating system)
- Appliances (runtime: Node.js, .NET, Python)
- Maintenance (automatic OS updates)
- Utilities included (scaling, load balancing)

You provide:
- Your belongings (your application code)
- Your data
- Who has keys (access control)

Microsoft Manages:
✓ Everything in IaaS +
✓ Operating System (you never see it)
✓ Middleware/Runtime (Node.js, .NET, Python, Java)
✓ Patching and updates (automatic, zero downtime)
✓ Scaling infrastructure (add more servers automatically)
✓ Load balancing (distribute traffic)
✓ High availability (automatically replicate across zones)

You Manage:
✓ Applications (your code)
✓ Data (what you store)
✓ Network configuration (firewall rules, VNet integration)
✓ Identity and access (who can access your app/data)

Startup building a web application
- Team of 3 developers
- No system administrators
- Need to ship features fast
- Traffic is unpredictable

Solution: Azure App Service (PaaS)
Benefits:
- Deploy code in 5 minutes (vs. 2 hours to set up a VM)
- Microsoft handles OS patches (saves 10 hours/month)
- Automatic scaling (handles traffic spikes without manual intervention)
- Built-in monitoring and logging
- Cost: $50-100/month (vs. $200/month for VM + admin time)

Trade-off: Can't install custom OS-level software, but they don't need to

Hotel provides:
- Building (datacenter)
- Furniture (operating system)
- Appliances (application runtime)
- Room service (the actual application)
- Cleaning (updates, maintenance)
- Everything

You provide:
- Your luggage (your data)
- Who stays in room (user access)

Microsoft Manages:
✓ Everything except:

You Manage:
✓ Data (emails, documents, your content)
✓ User access (who has an account)
✓ Devices (what devices can access)
✓ Information protection (data classification, DLP policies)

Company needs email for 100 employees

Old way (self-hosted Exchange):
- Buy Exchange Server license ($700)
- Buy server hardware ($5,000)
- Hire IT admin ($60,000/year salary)
- Install, configure, maintain
- Total: $65,700 first year + ongoing costs

SaaS way (Microsoft 365):
- $6/user/month × 100 users = $600/month
- Total: $7,200/year
- Zero maintenance
- Zero infrastructure
- Automatic updates
- Includes Word, Excel, OneDrive, Teams

Savings: $58,500 first year

​

Choosing the Right Service Model: Decision Tree

Question 1: Does a SaaS solution exist for your need?
├─ Yes (email, CRM, etc.) → Use SaaS
│   └─ Example: Microsoft 365, Salesforce
│
└─ No (custom application) → Continue to Question 2

Question 2: Do you need to control the operating system?
├─ Yes (legacy app, custom drivers, specific OS version)
│   └─ Use IaaS (Virtual Machines)
│       └─ Example: Old accounting software, SAP installation
│
└─ No (modern application) → Continue to Question 3

Question 3: Is your application modern (web app, API, microservice)?
├─ Yes → Use PaaS (App Service, Functions, Containers)
│   └─ Benefits: Faster, cheaper, less maintenance
│
└─ No (not sure, complex requirements) → Start with IaaS, migrate to PaaS later
    └─ You can always move VM workloads to PaaS when ready

​

Real-World Example: E-Commerce Application

Company deployed web app on App Service
Assumed "PaaS = secure"
Never implemented input validation
SQL injection vulnerability exploited
Database compromised

Root Cause: Application security is YOUR responsibility, always

​

Best Practice: RACI Matrix

​

2. Azure Global Infrastructure

​

The Hierarchy: Geography → Region → Availability Zone

​

Geography

• United States
• Europe
• Asia Pacific
• Australia
• Government (US Gov, China)

• GDPR compliance requires data to stay in EU geography
• Healthcare data must stay in specific regions
• Government workloads require sovereign clouds

​

Region

• Minimum 3 datacenters per region (for AZ support)
• Separated by at least 300 miles from paired region
• Connected via Microsoft’s private backbone (not public internet)

• East US (Virginia)
• West Europe (Netherlands)
• Southeast Asia (Singapore)
• Australia East (New South Wales)

​

Regional Pairs

1. Sequential Updates: During platform updates, only one region in a pair is updated at a time
2. Prioritized Recovery: In a massive outage, one region from each pair gets priority
3. Data Residency: Pairs are in the same geography (compliance requirement)
4. Replication: Some services automatically replicate to paired region (GRS storage)

​

When a Region Goes Dark: Failure Scenarios

​

1. How You Find Out: Azure Service Health

• Azure Status: The public page showing the status of all services globally. (The “Is the cloud broken?” page).
• Service Health: A personalized dashboard showing only the issues affecting your resources.
• Resource Health: A deep dive into why a specific resource (like your VM) is unavailable.

​

2. The Architectural Response

• Active-Passive (Failover): Your app runs in Region A. You have a “sleeping” copy in Region B. If A fails, you wake up B and point traffic there.
• Active-Active (Multi-Region): Your app runs in both Region A and B simultaneously. If A fails, traffic just shifts to B with zero downtime.

​

3. What Microsoft Does

​

Availability Zones (AZs)

• Minimum 3 AZs per supported region
• Independent power, cooling, and networking
• Connected via high-speed private fiber (<2ms latency)
• Fault isolated: Failure in one AZ doesn’t affect others

• ✅ Virtual Machines (zone-redundant or zonal)
• ✅ Managed Disks (zone-redundant storage)
• ✅ Azure SQL Database (zone-redundant)
• ✅ AKS (Azure Kubernetes Service)
• ✅ Load Balancers (zone-redundant)

• Single VM (Premium SSD): 99.9% uptime
• VMs across 2+ AZs: 99.99% uptime
• VMs across regions: 99.999% uptime (if you architect correctly)

​

Sovereign Clouds

​

3. Physical Infrastructure Deep Dive

​

Datacenter Architecture

• 50,000 - 80,000 servers per datacenter
• 10-20 MW power capacity per datacenter
• 20-40 acres of space
• PUE (Power Usage Effectiveness): ~1.18 (industry-leading efficiency)

​

Scale and Numbers

​

Power and Cooling

Primary Power Source
    ↓
Utility Grid (99.9% uptime)
    ↓ (if failure)
Diesel Generators (activate in <10 seconds)
    ↓ (while generators start)
UPS Systems (battery backup for 5-10 minutes)

• Free cooling: Using outside air when temperature permits (60-70% of the time)
• Adiabatic cooling: Evaporative cooling using water mist
• Two-phase immersion cooling: Servers submerged in liquid (experimental)
• Project Natick: Underwater datacenters (better cooling, renewable energy)

​

Security Layers

Layer 1: Perimeter
- 10-foot walls with barbed wire
- Security guards 24/7
- Vehicle barriers

Layer 2: Facility Entry
- Biometric access (hand geometry scanners)
- Security checkpoints
- Man-traps (doors that prevent tailgating)

Layer 3: Datacenter Floor
- Additional biometric authentication
- Video surveillance
- Motion detectors

Layer 4: Server Racks
- Locked racks
- Individual server lockdown
- Tamper-evident seals

Layer 5: Data Destruction
- Drives are shredded (not resold)
- Multi-step data destruction process
- Certificates of destruction

​

4. Design Principles: CAP Theorem

​

CAP Theorem Explained

​

The Fundamental Truth

​

CP Systems: Consistency + Partition Tolerance

Write Operation Flow:

1. Client writes to Primary Replica
2. Primary writes to transaction log
3. Primary replicates to Secondary Replicas (synchronous)
4. Waits for acknowledgment from majority (quorum)
5. Only then commits transaction
6. Returns success to client

If Network Partition Occurs:
❌ Can't reach secondaries
❌ Transaction is BLOCKED
❌ Client receives error
✅ System remains consistent

• Banking transactions (wrong balance = business failure)
• Inventory management (can’t oversell items)
• Booking systems (seats, tickets, hotel rooms)
• Any scenario where correctness > availability

• Azure SQL Database
• PostgreSQL/MySQL
• SQL Managed Instance

​

AP Systems: Availability + Partition Tolerance

Write Operation Flow (Eventual Consistency):

1. Client writes to nearest region
2. Region acknowledges IMMEDIATELY (<10ms)
3. Asynchronous replication to other regions
4. Client continues (doesn't wait)

If Network Partition Occurs:
✅ All regions continue operating independently
✅ Each region serves requests
⚠️  Data temporarily inconsistent
✅ When partition heals, data converges

• Social media feeds (brief staleness OK)
• Product catalogs (price updates can be delayed)
• User profiles (minor delays acceptable)
• Telemetry/analytics data

• Cosmos DB (Eventual/Session consistency)
• Azure Cache for Redis (replication is async)
• Table Storage

​

Cosmos DB: Five Consistency Levels

User A updates profile picture
  → Sees new picture immediately
User B viewing User A's profile
  → Sees new picture within 100-500ms

Messages: A → B → C
✅ You might see: A or A,B or A,B,C
❌ You'll never see: B,A or C,B,A

​

Real-World Decision Framework

Question 1: Can stale data cause correctness issues?
├─ Yes → Strong or Bounded Staleness
└─ No → Session, Consistent Prefix, or Eventual

Question 2: Must users see their own writes immediately?
├─ Yes → Session or stronger
└─ No → Consistent Prefix or Eventual

Question 3: Must events be ordered?
├─ Yes → Consistent Prefix or stronger
└─ No → Eventual

Question 4: Geographic distribution?
├─ Single region → Strong (low latency cost)
├─ Multi-region, high traffic → Session
└─ Multi-region, highest traffic → Eventual

​

Example: E-Commerce Architecture

Product Catalog:
Service: Cosmos DB
Consistency: Eventual
Why: High read volume, slight staleness OK
SLA: 99.99% availability

Shopping Cart:
Service: Cosmos DB
Consistency: Session
Why: User must see their own cart immediately
SLA: 99.99% availability

Inventory (during checkout):
Service: Cosmos DB
Consistency: Bounded Staleness (5 seconds)
Why: Can tolerate small overselling window
SLA: 99.99% availability

Order Processing:
Service: Azure SQL
Consistency: Strong (ACID)
Why: Financial correctness required
SLA: 99.995% availability

Analytics Dashboard:
Service: Synapse Analytics
Consistency: Eventual
Why: Approximate data sufficient for reports
SLA: 99.9% availability

​

5. The Principle of Least Privilege

​

Why Least Privilege Matters

❌ Attacker has subscription-wide access
❌ Can delete ALL resources
❌ Can exfiltrate ALL data
❌ Can create backdoor admin accounts
❌ Blast radius: ENTIRE SUBSCRIPTION

Recovery: Days to weeks
Cost: Millions

✅ Attacker limited to dev resources
✅ Cannot access production
✅ Cannot delete subscription
✅ Blast radius: Single resource group

Recovery: Hours
Cost: Minimal

​

Azure RBAC Fundamentals

​

Built-in Roles

Owner
├── All permissions
├── Can assign roles to others
├── Full control
└── Use: Very few users (subscription admins)

Contributor
├── Create, modify, delete resources
├── CANNOT assign roles
├── Cannot manage access
└── Use: Developers in dev/test

Reader
├── View resources only
├── Cannot modify
├── Cannot view secrets
└── Use: Auditors, stakeholders

Specialized Roles:
├── Virtual Machine Contributor (VMs only)
├── Storage Blob Data Contributor (blob data only)
├── Key Vault Secrets Officer (secrets only)
└── SQL DB Contributor (databases only)

​

Scope Hierarchy

Management Group (highest level)
  ↓ inherits permissions
Subscription
  ↓ inherits permissions
Resource Group
  ↓ inherits permissions
Resource (lowest level)

Permissions accumulate downward
Child scopes inherit parent permissions
Cannot override parent (only add)

User Alice:
- Reader at Subscription level
- Contributor at "Dev" Resource Group level

Result:
✅ Can view all resources in subscription
✅ Can modify resources in Dev RG only
❌ Cannot modify resources in Prod RG

​

6. Hands-On Lab: Deploy Your First Resource

​

Lab Prerequisites

• Azure account (free tier works)
• Azure CLI installed (or use Azure Cloud Shell)
• Basic command-line knowledge

​

Step 1: Create a Resource Group

1. Navigate to portal.azure.com
2. Search for “Resource Groups”
3. Click ”+ Create”
4. Fill in:
   • Subscription: Your subscription
   • Resource group: rg-demo-dev
   • Region: East US
5. Click “Review + Create” → “Create”

az group create \
  --name rg-demo-dev \
  --location eastus \
  --tags Environment=Dev Project=Demo

​

Step 2: Deploy an App Service

# Create App Service Plan (hosting environment)
az appservice plan create \
  --name plan-demo-dev \
  --resource-group rg-demo-dev \
  --sku F1 \
  --is-linux

# Create Web App
az webapp create \
  --name webapp-demo-${RANDOM} \
  --resource-group rg-demo-dev \
  --plan plan-demo-dev \
  --runtime "NODE|18-lts"

# Deploy sample code
az webapp deployment source config \
  --name webapp-demo-${RANDOM} \
  --resource-group rg-demo-dev \
  --repo-url https://github.com/Azure-Samples/nodejs-docs-hello-world \
  --branch master \
  --manual-integration

# Get the URL
az webapp show \
  --name webapp-demo-${RANDOM} \
  --resource-group rg-demo-dev \
  --query defaultHostName \
  --output tsv

​

Step 3: Verify Deployment

​

Step 4: View Logs

# Stream live logs
az webapp log tail \
  --name webapp-demo-${RANDOM} \
  --resource-group rg-demo-dev

​

Step 5: Clean Up

# Delete everything
az group delete \
  --name rg-demo-dev \
  --yes \
  --no-wait

​

7. Interview Questions

​

Beginner Level

​

Intermediate Level

Architecture:
1. Azure Front Door (global load balancer)
   └─> Multiple regions (active-active)

2. Per-region deployment:
   - Azure Application Gateway (regional LB)
   - App Service with Availability Zones
   - Azure SQL with zone-redundancy
   - Redis Cache (zone-redundant)

3. Data layer:
   - Azure SQL with geo-replication
   - Blob Storage with GRS (geo-redundant)

4. Monitoring:
   - Application Insights (distributed tracing)
   - Azure Monitor (alerts)

SLA Calculation:
- App Service (AZ): 99.95%
- Azure SQL (zone-redundant): 99.995%
- Combined: 99.945% ≈ 4.8 hours downtime/year

​

Advanced Level

1. Architecture:
   - Cosmos DB with multi-region writes
   - Session consistency per region
   - Conflict resolution policy (Last Write Wins or Custom)

2. During Partition:
   - US region serves US users independently
   - EU region serves EU users independently
   - Writes go to local region (no cross-region dependency)

3. When Partition Heals:
   - Cosmos DB automatically reconciles conflicts
   - Use LWW (Last Write Wins) for simple cases
   - Use custom merge logic for complex scenarios

4. Trade-offs:
   ✅ Always available (no downtime)
   ⚠️  Eventual consistency (conflicts possible)
   ✅ Low latency (local writes)
   ❌ Higher cost (multi-region writes)

5. Alternative (CP approach):
   - Use Azure SQL with readable secondaries
   - Accept downtime during partition
   - Manual failover when needed
   ✅ Strong consistency
   ❌ Downtime during partition

Layer 1: RBAC (Principle of Least Privilege)
- Developers: Contributor on Dev RG only
- Ops: Contributor on Prod (with conditions)
- No one has Owner except 2-3 admins

Layer 2: Resource Locks
- Apply CanNotDelete lock on production RGs
- Apply ReadOnly lock on critical resources
- Locks require Owner role to remove

Layer 3: Azure Policy
- Deny deletion during business hours
- Require approval for prod changes
- Enforce tagging (Environment=Production)

Layer 4: Privileged Identity Management (PIM)
- Just-in-Time access elevation
- Time-limited (2-4 hours)
- Approval workflow required
- All actions audited

Layer 5: Monitoring & Alerts
- Alert on any deletion in production
- Alert on role assignments
- Log Analytics query: AzureActivity | where OperationName contains "Delete"

Layer 6: Backup & Recovery
- Azure Backup for VMs (daily)
- Soft delete for SQL/Cosmos (30 days)
- GRS storage (geo-replicated)
- Test restore procedures monthly

Layer 7: Infrastructure as Code
- All resources in Terraform/Bicep
- Can recreate environment from code
- Version controlled in Git

​

8. Key Takeaways

​

Next Steps

• Azure Active Directory deep dive
• RBAC implementation strategies
• Conditional Access policies
• Privileged Identity Management
• Managed Identities for secure service authentication