← Back to Learning Portal

AZ-305 Exam Crash Course

Every domain, every concept — intensive review for Designing Microsoft Azure Infrastructure Solutions.

🚀 AZ-305 INTENSIVE CRASH COURSE

Every Domain, Every Concept — Pass on First Attempt

Exam: AZ-305 — Designing Microsoft Azure Infrastructure Solutions

Duration: 100 minutes | Questions: 40–60 (scenario + case studies) | Pass: 700/1000

Skills measured: April 17, 2026

Prerequisite: AZ-104 or equivalent

THE NORTH STAR: AZURE WELL-ARCHITECTED FRAMEWORK

Every AZ-305 answer must map to one or more of these five pillars:

Pillar	Design Question	Exam Trigger Words
--------	----------------	-------------------
Cost Optimization	Are we paying for what we need?	"minimize cost", "reduce spending", "TCO", "reserved instances"
Operational Excellence	Can we run and improve this reliably?	"IaC", "monitoring", "automation", "CI/CD", "runbooks"
Performance Efficiency	Does it scale and respond fast enough?	"latency", "throughput", "scaling", "caching", "CDN"
Reliability	Will it survive failure?	"SLA", "HA", "DR", "RTO", "RPO", "failover", "redundancy"
Security	Is data and access protected?	"encryption", "identity", "private endpoint", "least privilege", "compliance"

Architect Mindset Shift

Administrator	Architect
---------------	-----------
"How do I deploy this?"	"What is the RIGHT design given these constraints?"
Single correct config	Multiple valid options — choose BEST for scenario
Feature checklist	Trade-off analysis with justification

Decision Framework (Use on Every Case Study)

1. READ all requirements — highlight CONFLICTING constraints
2. IDENTIFY which WAF pillar each requirement maps to
3. LIST 3+ Azure service options
4. ELIMINATE options that violate a hard requirement
5. COMPARE remaining options on cost, complexity, SLA
6. SELECT best answer — justify with WAF pillar

DOMAIN 1 — DESIGN IDENTITY, GOVERNANCE, AND MONITORING SOLUTIONS (25–30%)

1.1 Microsoft Entra ID Architecture

Entra ID Fundamentals

Tenant = dedicated Entra ID instance for an organisation
Multiple Azure subscriptions link to ONE Entra ID tenant
Each subscription trusts exactly ONE tenant
Primary domain: *.onmicrosoft.com (can add custom verified domains)

Licence Tiers — EXAM CRITICAL

Feature	Free	P1	P2
---------	------	----	----
Basic identity & SSO	✅	✅	✅
Self-service password reset	❌	✅	✅
Conditional Access	❌	✅	✅
Dynamic groups	❌	✅	✅
Hybrid identity (Connect)	❌	✅	✅
PIM	❌	❌	✅
Identity Protection	❌	❌	✅
Access Reviews	❌	❌	✅
Entitlement Management	❌	❌	✅

🔑 Golden Rule: PIM, Identity Protection, Access Reviews → P2 required

Hybrid Identity Models

Model	Tool	When to Use
-------	------	-------------
Password Hash Sync (PHS)	Entra Connect	Default; simplest; cloud auth
Pass-Through Auth (PTA)	Entra Connect + PTA agents	Validate passwords on-prem; no hash in cloud
Federation (AD FS)	AD FS + Connect	Complex; legacy; third-party MFA integration
Cloud Sync	Entra Cloud Sync	Lightweight; multi-forest; no full Connect server

🔑 Exam tip: "Minimize on-premises footprint" → Cloud Sync or PHS. "Validate on-premises only" → PTA.

B2B vs B2C

Feature	B2B	B2C
---------	-----	-----
Audience	Partner/contractor employees	Consumer customers
Identity source	Partner's Entra ID / social	Local accounts, social, SAML
User object	Guest in your tenant	User in B2C directory
Use case	Collaborate with external orgs	Customer-facing apps

Managed Identities vs Service Principals

Feature	System-Assigned MI	User-Assigned MI	Service Principal
---------	-------------------	------------------	-------------------
Lifecycle	Tied to resource	Independent	App registration
Credentials	None (Azure-managed)	None	Secret or certificate
Sharing	1:1	1:many resources	1:1 per app
Best for	Single VM/App accessing KV	Multiple resources same perms	Non-Azure automation

1.2 Authentication and Authorization Design

Conditional Access Policy Components

IF (Assignments: users, groups, apps, locations, device state, risk level)
THEN (Access controls: grant, block, session)

Grant controls: Require MFA, require compliant device, require hybrid Entra joined, approved app, password change.

Session controls: Sign-in frequency, persistent browser session, app-enforced restrictions.

RBAC Design Patterns

Scope hierarchy (inheritance flows down):

Tenant Root Group
  └── Management Group
        └── Subscription
              └── Resource Group
                    └── Resource

Key built-in roles for architecture:

Role	Use Case
------	----------
Owner	Full control + manage access
Contributor	Create/manage resources, no RBAC
Reader	View only
User Access Administrator	Manage RBAC only
Security Admin	Security policies in Defender for Cloud

Custom roles: When built-in roles are too broad. Define Actions, NotActions, DataActions, AssignableScopes.

Privileged Identity Management (PIM)

Eligible = must activate (JIT) — does NOT grant access until activated
Active = permanent until removed
Activation: MFA, approval, justification, time-bound (max duration configurable)
Access Reviews: Periodic recertification of role assignments

🔑 Exam trap: "Just-in-time admin access with approval" → PIM eligible assignment, NOT direct RBAC

1.3 Governance at Scale

Management Groups

Organise subscriptions hierarchically (up to 6 levels deep)
Apply policies and RBAC at MG level — cascades to all child subscriptions
Tenant Root Group = top level; all subscriptions must be in exactly one MG tree

Design pattern — Enterprise structure:

Root MG
├── Platform MG (shared services: connectivity, identity, management)
│   ├── Connectivity subscription
│   ├── Identity subscription
│   └── Management subscription
├── Landing Zone MG (workload subscriptions)
│   ├── Production MG
│   │   ├── App1-Prod subscription
│   │   └── App2-Prod subscription
│   └── Non-Production MG
│       ├── Dev subscriptions
│       └── Test subscriptions
└── Sandbox MG (individual dev sandboxes)

Azure Policy

Effect	Behaviour
--------	-----------
Audit	Log non-compliance, allow creation
AuditIfNotExists	Audit if related resource missing
Deny	Block non-compliant creation
DeployIfNotExists	Deploy missing resource (needs MI on assignment)
Modify	Add/update tags or properties
Disabled	Policy exists but not evaluated

Initiatives = bundle of policies (e.g., "ISO 27001 compliance initiative")

🔑 Exam tip: "Automatically deploy diagnostic settings" → DeployIfNotExists with managed identity

Azure Blueprints

Package: Role assignments + Policy + ARM templates + Resource Groups
Versioned and repeatable landing zone deployment
Difference from Policy alone: Blueprints deploy infrastructure + governance together
Note: Azure Blueprints evolving — exam may reference Template Specs + Deployment Stacks as modern alternative

Subscription Design Strategies

Strategy	When
----------	------
One sub per environment	Simple; dev/test/prod isolation
One sub per workload	Strong blast-radius isolation
One sub per region	Data residency compliance
One sub per team	DevOps autonomy with policy guardrails

1.4 Monitoring and Logging Design

Azure Monitor Architecture

Resources → Diagnostic Settings → Log Analytics Workspace
         → Metrics → Metric Alerts
         → Activity Log → Activity Log Alerts

Log Analytics Workspace Design

Factor	Recommendation
--------	----------------
Data residency	Workspace in compliant region
Retention	30–730 days (cost increases after 31 days)
Commitment tiers	Save cost at predictable ingestion volumes
Multiple workspaces	Separate by compliance boundary or environment
Single workspace	Centralised SIEM; lower cost; cross-app correlation

Alert Design

Alert Type	Source	Use Case
------------	--------	----------
Metric alert	Platform metrics	CPU > 80%, storage capacity
Log alert	KQL query on logs	Custom conditions, complex logic
Activity log alert	Control plane	RBAC changes, resource deletion
Smart detector	Application Insights	AI-detected anomalies

Application Insights Design

Workspace-based (recommended): Linked to Log Analytics workspace
Instrumentation key → Connection string (modern SDK)
Distributed tracing: Correlate requests across microservices
Availability tests: External ping from multiple regions

Diagnostic Settings — EXAM CRITICAL

Must be explicitly enabled per resource
Send to: Log Analytics, Storage Account, Event Hub, Partner solution
Categories: Administrative, Security, ServiceHealth, Alert, Recommendation, Policy, Autoscale, ResourceHealth

🔑 Golden Rule: "Centralised logging for all resources" → Diagnostic settings + Log Analytics + Azure Policy DeployIfNotExists

1.5 Domain 1 Case Studies

Case Study: Multi-Tenant SaaS Identity

Scenario: B2B SaaS serving 5,000 enterprise customers, each with own Entra ID tenant, SSO required, strict data isolation.

Answer pattern: Multi-tenant app registration + B2B collaboration + row-level security by tenant ID in database.

Case Study: Governance at Scale

Scenario: 200 subscriptions, inconsistent tagging, need ISO 27001 compliance, minimise manual audit.

Answer pattern: Management group hierarchy + Policy initiative (Audit/Deny for tags, DeployIfNotExists for diagnostics) + Blueprint for new subscriptions.

Case Study: Hybrid Identity Migration

Scenario: 50,000 users, 24-hour migration window, minimise on-prem footprint.

Answer pattern: PHS via Entra Connect (staged migration) OR Cloud Sync for multi-forest. Enable Seamless SSO. Conditional Access with MFA for cloud apps.

1.6 Domain 1 Quick Reference

Requirement	Solution
-------------	----------
JIT privileged access	PIM eligible assignments
External partner access	B2B guest users
Consumer app authentication	Entra External ID (B2C)
App-to-Azure auth without secrets	Managed Identity
Enforce resource tagging	Azure Policy (Deny or Modify)
Deploy compliant landing zone	Blueprint / Template Spec
Centralised audit logs	Log Analytics + diagnostic settings
Least privilege for dev team	Custom RBAC role scoped to RG

DOMAIN 2 — DESIGN DATA STORAGE SOLUTIONS (20–25%)

2.1 Azure SQL Family — The Big Three

Comparison Matrix — EXAM CRITICAL

Feature	Azure SQL Database	SQL Managed Instance	SQL on VM
---------	-------------------	---------------------	-----------
Compatibility	Most T-SQL	~100% SQL Server	100%
VNet integration	Private Endpoint	Native VNet deploy	Full control
SQL Agent	❌	✅	✅
Cross-DB queries	Elastic query	✅ (same instance)	✅
CLR, linked servers	Limited	✅	✅
Maintenance	Fully managed	Fully managed	You manage
Cost (similar size)	Lowest	Medium	Lowest compute, highest ops
Best for	New cloud-native apps	Lift-and-shift SQL Server	Full SQL Server features

🔑 Golden Rule: "Near 100% compatibility with on-prem SQL Server" → Managed Instance

"Minimize operational overhead for new app" → SQL Database

"Need SQL Server Reporting Services or exotic features" → SQL on VM

SQL Database Tiers

Tier	Use Case	Billing
------	----------	---------
General Purpose	Most workloads	vCore or DTU
Business Critical	Low latency, high IO	vCore, local SSD
Hyperscale	Auto-scaling storage (up to 100 TB)	vCore

Elastic Pools

Share resources across multiple databases
When: Many databases with unpredictable, bursty usage
Not when: Single database with consistent high load

SQL Database HA/DR

Feature	RPO	RTO	Use Case
---------	-----	-----	----------
Automatic backups	~5 min (point-in-time)	Hours	Default protection
Active Geo-Replication	Seconds	Minutes (manual failover)	Read scale + DR
Auto-Failover Group	Seconds	1–5 min (automatic)	DR with automatic failover
Zone-redundant	Zone failure	Automatic	Same-region HA

Managed Instance Key Features

Deployed inside a VNet (dedicated subnet required)
Failover groups for cross-region DR
Linked server to on-premises via VPN/ER
Maintenance window selection

2.2 Azure Cosmos DB

API Options

API	Wire Protocol	Best For
-----	-------------	----------
NoSQL (native)	Cosmos DB	Greenfield, full feature set
MongoDB	MongoDB	MongoDB migration
Cassandra	Cassandra	Wide-column, IoT
Gremlin	Gremlin	Graph data
Table	Azure Tables	Key-value migration

Consistency Levels — EXAM CRITICAL (ordered strongest → weakest)

Level	Guarantees	Latency	Throughput	Cost
-------	-----------	---------	------------	------
Strong	Linearizability	Highest	Lowest RU	Highest
Bounded Staleness	Consistent prefix + lag bound	High	Medium	High
Session	Consistent within session	Medium	Good	Medium
Consistent Prefix	Reads see writes in order	Lower	Better	Lower
Eventual	No ordering guarantee	Lowest	Highest RU	Lowest

🔑 Exam tip: "Global distribution with lowest latency reads" → Session or Eventual. "Financial transactions, no stale reads" → Strong.

Partition Key Design

Choose wisely — cannot change after creation
High cardinality (many distinct values)
Even distribution of requests and storage
Hot partition = single partition getting disproportionate traffic

Throughput Models

Model	When
-------	------
Provisioned (manual)	Predictable workload
Provisioned (autoscale)	Variable, bounded peaks
Serverless	Dev/test, intermittent traffic

Multi-Region Writes

Single-write region: Lower cost, higher write latency from distant clients
Multi-write (multi-master): Conflict resolution via Last-Writer-Wins (LWW) by default

2.3 Storage Accounts

Performance Tiers

Tier	Media	Use Case
------	-------	----------
Standard	HDD	General purpose, cost-effective
Premium	SSD	Low latency, high IOPS (Page blobs, Disks)

Replication Options — EXAM CRITICAL

Option	Copies	Regions	Read Access	SLA
--------	--------	---------	-------------	-----
LRS	3	1 datacenter	No	99.9%
ZRS	3	3 zones	No	99.99%
GRS	6	2 regions	No (secondary)	99.99%
GZRS	6	2 regions, zonal primary	No	99.99%
RA-GRS	6	2 regions	Yes (secondary)	99.99%
RA-GZRS	6	2 regions, zonal primary	Yes	99.99%

🔑 Golden Rule: "Protect against zone failure" → ZRS. "Protect against regional disaster" → GRS/GZRS. "Read from secondary during outage" → RA-GRS.

Access Tiers (Blob)

Tier	Cost	Min storage duration	Use Case
------	------	-------------------	----------
Hot	Highest storage, lowest access	—	Frequent access
Cool	Lower storage, higher access	30 days	Infrequent (30+ days)
Cold	Lower than Cool	90 days	Rare access
Archive	Lowest	180 days	Long-term retention

ADLS Gen2

Hierarchical namespace enabled on storage account
Combines blob storage scalability with file system semantics
Use for: Data lakes, big data analytics (Synapse, Databricks)
POSIX-like ACLs for fine-grained access

Lifecycle Management Policies

Automate tier transitions (Hot → Cool → Archive)
Automate deletion based on age
Cost optimization pillar — exam favourite

2.4 Analytics and Data Platform

Azure Synapse Analytics

Dedicated SQL pool (formerly SQL DW): MPP, petabyte scale, batch analytics
Serverless SQL pool: Pay-per-query on Data Lake files
Spark pools: Big data processing
Pipelines: ETL/ELT orchestration

When Synapse vs Databricks

Factor	Synapse	Databricks
--------	---------	------------
SQL analytics	Native (dedicated pool)	Delta Lake + SQL
Spark	Supported	Best-in-class
Microsoft integration	Native	Good (Azure)
ML	Via Azure ML integration	Built-in MLflow
Best for	Enterprise data warehouse	Data engineering + ML

Azure Data Explorer (ADX/Kusto)

Time-series and log analytics at massive scale
KQL query language
Use for: IoT telemetry, application logs, security analytics
Not for: Transactional OLTP workloads

2.5 Data Protection and Compliance

Encryption

Layer	Option
-------	--------
At-rest (platform)	Microsoft-managed keys (default)
At-rest (customer)	Customer-managed keys (CMK) via Key Vault
In-transit	TLS 1.2+ (enforced by default on most services)
Double encryption	Infrastructure + CMK (selected services)

Backup Design

Service	Backup mechanism
---------	-----------------
SQL Database	Automatic (7–35 days), long-term retention to storage
SQL MI	Automated backup to blob
VMs	Azure Backup (Recovery Services Vault)
Files	Azure Backup or snapshots
Cosmos DB	Periodic backup (continuous in newer tiers)

Data Residency

Choose region at deployment — data stays in region (with exceptions for geo-replication)
Sovereign clouds: Azure Government, Azure China
Policy: Deny deployments outside allowed regions

2.6 Domain 2 Case Studies

Case Study: E-Commerce Data Platform

Requirements: <100ms product search, 7-year sales history, 1M concurrent users on Black Friday, reduce storage cost 40%.

Answer pattern:

Product catalog → Cosmos DB (Session consistency, autoscale)
Sales history → Synapse + Archive tier for old data
User profiles → SQL Database (General Purpose, zone-redundant)
Black Friday → Cosmos autoscale + CDN for static content + App Service scale-out

Case Study: IoT Telemetry

Requirements: 10 billion events/day, 30-day retention, ad-hoc queries, minimize cost.

Answer pattern: Event Hubs (ingestion) → ADX (hot analytics) → Data Lake Archive (cold storage) → lifecycle policy to Archive tier.

Case Study: SQL Server Migration

Requirements: 50 SQL Server databases, minimal downtime, linked servers, SQL Agent jobs.

Answer pattern: Azure Migrate assessment → SQL Managed Instance (compatibility) → Transactional Replication or DMS for migration → failover group for DR.

2.7 Domain 2 Quick Reference

Requirement	Solution
-------------	----------
Global low-latency reads, flexible schema	Cosmos DB
Relational, ACID, managed	SQL Database
Lift-and-shift SQL Server	Managed Instance
Petabyte analytics	Synapse dedicated pool
Data lake	ADLS Gen2
Time-series at scale	Azure Data Explorer
Zone failure protection (storage)	ZRS
Regional DR (storage)	GRS or GZRS
Minimize storage cost (infrequent access)	Cool/Archive + lifecycle policies

DOMAIN 3 — DESIGN BUSINESS CONTINUITY SOLUTIONS (15–20%)

3.1 RTO and RPO — Foundation Concepts

Metric	Definition	Question It Answers
--------	------------	---------------------
RPO (Recovery Point Objective)	Maximum acceptable data loss	"How much data can we afford to lose?"
RTO (Recovery Time Objective)	Maximum acceptable downtime	"How fast must we be back online?"

DR Strategy Spectrum (cost ↑, RTO ↓)

Backup & Restore ──→ Pilot Light ──→ Warm Standby ──→ Hot Standby ──→ Active-Active
   (hours/days)        (hours)         (minutes)        (minutes)      (seconds)
   Lowest cost                                    Highest cost/complexity

Strategy	RTO	RPO	Cost	Description
----------	-----	-----	------	-------------
Backup & Restore	Hours–days	Hours	$	Restore from backup when disaster occurs
Pilot Light	Hours	Minutes	$$	Core services running at minimal scale in DR region
Warm Standby	Minutes	Minutes	$$$	Scaled-down full environment, ready to scale up
Hot Standby	Minutes	Seconds	$$$$	Full environment running, manual failover
Active-Active	Seconds	Near-zero	$$$$$	Both regions serving traffic simultaneously

🔑 Exam tip: "Minimize cost for dev/test DR" → Backup & Restore. "RPO < 15 min, RTO < 1 hour for production" → Warm Standby or Hot Standby with ASR.

3.2 Azure Site Recovery (ASR)

What ASR Replicates

Azure VMs (VMware, Hyper-V, physical via Mobility Service)
On-premises to Azure
Azure region to Azure region

ASR Components

Component	Purpose
-----------	---------
Recovery Services Vault	Central container for ASR, Backup
Replication Policy	RPO threshold, recovery points retention
Failover	Test (non-disruptive), Planned, Unplanned
Failback	Return to primary after disaster resolved

ASR Failover Types

Type	When	Impact
------	------	--------
Test	Validate DR plan	No impact on production
Planned	Expected outage (maintenance)	Minimal — graceful
Unplanned	Disaster	Immediate failover to DR region

ASR + SQL

Not a replacement for SQL-native DR (failover groups, geo-replication)
Use ASR for VM-level replication; use SQL failover groups for database-level DR

3.3 Backup Architecture

Recovery Services Vault Design

One vault per region (typical) or per compliance boundary
Soft delete (14-day mandatory retention for new vaults)
Cross-region restore (backup data geo-redundant)
Immutable vaults: WORM — cannot delete/modify backups (ransomware protection)

Azure Backup Scope

Workload	Backup Type
----------	-------------
Azure VMs	Full VM or disk-level
SQL in VM	Full, differential, log (app-consistent)
Azure Files	Share-level backup
SAP HANA in VM	Database-aware backup
On-premises	MARS agent or DPM/MABS

Backup Policy Design

Factor	Recommendation
--------	----------------
Daily backup	Standard for most workloads
Retention	30 days daily, 12 months weekly, 7 years monthly (compliance)
GFS strategy	Grandfather-Father-Son for long-term retention
Cross-region	GRS vault storage for regional disaster

3.4 High Availability Patterns

Availability Sets vs Availability Zones

Feature	Availability Set	Availability Zone
---------	-----------------	-------------------
Protects against	Rack/hardware failure within DC	Entire datacenter failure
SLA (single VM)	99.9%	99.99%
Latency between instances	Low (same DC)	Higher (cross-DC in region)
Use with	Legacy apps, no zone support	Modern zone-redundant services
Free	Yes (no extra charge for AS)	Zone IP may have cost

🔑 Golden Rule: "99.99% SLA for VMs" → Availability Zones (2+ zones). "Legacy app, no code changes" → Availability Set.

Zone-Redundant Services (PaaS)

SQL Database (zone-redundant configuration)
Storage (ZRS, GZRS)
App Service (zone-redundant plan)
Load Balancer (Standard, zonal)
Application Gateway v2 (zone-redundant)

Load Balancing for HA

Service	Layer	Scope	Use Case
---------	-------	-------	----------
Azure Load Balancer	L4 (TCP/UDP)	Regional	VM scale sets, internal/external
Application Gateway	L7 (HTTP/S)	Regional	Web apps, SSL termination, WAF
Azure Front Door	L7	Global	Global distribution, WAF, failover
Traffic Manager	DNS	Global	DNS-based failover (not proxy)

Traffic Manager Routing Methods

Method	Behaviour
--------	-----------
Priority	Primary/backup failover
Weighted	Traffic distribution by weight
Performance	Route to lowest latency
Geographic	Route by user location
Subnet	Route by source IP range
Multi-value	Return multiple healthy endpoints

3.5 SQL Database DR Deep Dive

Geo-Replication vs Failover Groups

Feature	Active Geo-Replication	Auto-Failover Group
---------	----------------------	---------------------
Failover	Manual	Automatic
Listener endpoint	No	Yes (read-write FQDN)
Grace period	N/A	Configurable (prevent flapping)
Databases	Individual	Grouped
Best for	Read scale-out + manual DR	Production DR with auto-failover

SQL MI Failover Groups

Instance-level failover (entire MI fails over)
DNS endpoint automatically updates
Supports cross-region DR

3.6 Network Resilience

Multi-Region Architecture Patterns

Pattern 1: Active-Passive
  Primary Region (active) ──replication──→ DR Region (standby)
  Traffic Manager priority routing

Pattern 2: Active-Active
  Region A ←──Traffic Manager (weighted/performance)──→ Region B
  Both serve traffic; Cosmos DB multi-write or SQL geo-replication

ExpressRoute + VPN for Resilience

Primary: ExpressRoute (dedicated, SLA 99.95%)
Secondary: Site-to-Site VPN (backup path)
BGP: ER preferred; automatic failover to VPN if ER fails

3.7 Domain 3 Case Studies

Case Study: Financial Services DR

Requirements: RPO 5 min, RTO 15 min, PCI-DSS, zero data loss for transactions, 40% cost cap on DR.

Answer pattern:

SQL: Auto-failover groups (RPO ~seconds, automatic)
VMs: ASR warm standby in paired region
Storage: GZRS with RA read access
Network: ER primary + VPN backup
NOT active-active (cost prohibitive for this budget)

Case Study: Dev/Test DR

Requirements: Recover within 24 hours, minimize cost, data loss up to 24 hours acceptable.

Answer pattern: Azure Backup with daily snapshots, GRS vault, no ASR (too expensive for dev/test). Document restore runbook.

Case Study: Global Web Application

Requirements: 99.99% uptime, users worldwide, automatic regional failover.

Answer pattern: Front Door (global L7) + App Service in 2+ regions + Cosmos DB multi-region writes + Traffic Manager as DNS backup.

3.8 Domain 3 Quick Reference

Requirement	Solution
-------------	----------
Cheapest DR	Backup & Restore
RPO minutes, controlled failover	ASR warm standby
Automatic SQL DR	Auto-failover group
VM HA within region	Availability Zones
Global automatic failover	Front Door + multi-region deployment
Ransomware-protected backups	Immutable vault
DNS-based global routing	Traffic Manager
Test DR without impact	ASR test failover

DOMAIN 4 — DESIGN INFRASTRUCTURE SOLUTIONS (30–35%)

4.1 Compute Selection — The Decision Tree

What is the workload?
├── Web/API (stateless)
│   ├── Simple, no containers → App Service
│   ├── Containers, orchestration needed → AKS or Container Apps
│   └── Full OS control → VMs / VMSS
├── Background/batch → Azure Functions (consumption) or Batch
├── Event-driven → Functions + Event Grid
├── Legacy monolith → VMs (lift-and-shift) or MI (database)
└── HPC/GPU → VMs (NC/ND series) or Azure Batch

Compute Comparison Matrix — EXAM CRITICAL

Service	Management	Scaling	Cost Model	Best For
---------	-----------	---------	------------	----------
App Service	PaaS	Manual/auto scale	Plan-based	Web apps, APIs, simple deploy
Azure Functions	Serverless	Event-driven	Per-execution	Microservices, triggers
AKS	Managed K8s	Cluster autoscaler, HPA	Node pool VMs	Containers, microservices
Container Apps	Serverless containers	KEDA-based	Per-use	Simple container workloads
VM / VMSS	IaaS	Manual/VMSS auto	Per-VM-hour	Full control, legacy
Azure Batch	Managed batch	Auto-scale nodes	Per-node	HPC, parallel processing

🔑 Golden Rule: "Minimize operational overhead" → PaaS (App Service, Functions). "Kubernetes expertise, complex microservices" → AKS. "Legacy app, no code changes" → VMs.

App Service Plans

Tier	Features
------	----------
Free/Shared	Dev/test only, no SLA
Basic	Manual scale, no slots
Standard	Auto-scale, deployment slots, daily backup
Premium v3	Zone redundancy, more instances, VNet integration
Isolated	App Service Environment (ASE), full network isolation

VM Scale Sets (VMSS)

Identical VMs, auto-scale based on metrics or schedule
Orchestration modes: Uniform (identical) vs Flexible (individual VM management)
Integrate with Load Balancer or App Gateway
Spot instances in VMSS for cost savings (evictable workloads)

Azure Kubernetes Service (AKS)

Component	Design Decision
-----------	----------------
Node pools	System pool (critical addons) + user pools (workloads)
Networking	Azure CNI (VNet IPs) vs Kubenet (overlay)
Ingress	App Routing addon, NGINX, or App Gateway Ingress Controller
Identity	Workload Identity (recommended over pod-managed identity)
Security	Azure Policy for AKS, Defender for Containers

4.2 Networking Architecture

Hub-and-Spoke Topology

                    ┌─────────────────────┐
                    │    Hub VNet         │
                    │  ┌───────────────┐  │
                    │  │ Azure Firewall│  │
                    │  │ VPN/ER Gateway│  │
                    │  │ DNS Private   │  │
                    │  │ Resolver      │  │
                    │  └───────────────┘  │
                    └──────────┬──────────┘
                               │ Peering
              ┌────────────────┼────────────────┐
              │                │                │
        ┌─────▼─────┐   ┌─────▼─────┐   ┌─────▼─────┐
        │ Spoke 1   │   │ Spoke 2   │   │ Spoke 3   │
        │ (Prod)    │   │ (Dev)     │   │ (Shared)  │
        └───────────┘   └───────────┘   └───────────┘

Key principles:

All peering is non-transitive — spoke-to-spoke via hub
UDRs force traffic through Azure Firewall in hub
Shared services (DNS, firewall, gateway) in hub only
Gateway transit: Spokes use hub's VPN/ER gateway

Virtual WAN vs Hub-and-Spoke

Factor	Hub-and-Spoke (manual)	Virtual WAN
--------	----------------------	-------------
Scale	2–10 hubs manageable	10+ sites, global
Management	Per-VNet peering, UDRs	Centralised hub management
Branch connectivity	VPN to each hub	Built-in VPN/SD-WAN to vWAN hub
Mesh routing	Manual UDRs	Automatic any-to-any
Cost	Lower for small deployments	Higher base, scales better
Best for	Single region, <10 spokes	Multi-region, many branches

🔑 Exam tip: "50 branch offices across 6 continents" → Virtual WAN. "Single region, 5 VNets" → Hub-and-spoke.

Hybrid Connectivity

Option	Bandwidth	Latency	SLA	Encryption	Cost
--------	-----------	---------	-----	------------	------
Site-to-Site VPN	Up to 1.25 Gbps	Variable (internet)	99.9%	IPsec (built-in)	$
ExpressRoute	50 Mbps–100 Gbps	Consistent, low	99.95%	Not by default (MACsec optional)	$$$$
ExpressRoute + VPN	ER primary, VPN backup	Best of both	99.95%+	VPN encrypted	$$$$
Virtual WAN VPN	Per-site VPN to vWAN	Good	99.9%	IPsec	$$ (at scale)

Private Access to Azure PaaS

Feature	Private Endpoint	Service Endpoint
---------	-----------------	------------------
IP address	Private IP from your VNet	Public IP (filtered by VNet)
On-premises access	Yes (via ExpressRoute/VPN + DNS)	No
Data exfiltration protection	Yes (traffic stays on Microsoft backbone)	Partial
Cost	Per endpoint hourly + data	Free
DNS required	Private DNS zone for privatelink	No

🔑 Golden Rule: "Access PaaS from on-premises over private network" → Private Endpoint + Private DNS Zone linked to on-prem DNS.

Azure Firewall

SKU	Throughput	Features
-----	-----------	----------
Standard	30 Gbps	Stateful, FQDN filtering, threat intel
Premium	100 Gbps	+ IDPS, TLS inspection, URL filtering

Rule processing order: DNAT → Network → Application → Default Deny

DNS Design

Scenario	Solution
----------	----------
Private name resolution in VNet	Azure Private DNS Zones
Hybrid DNS (on-prem + Azure)	DNS Private Resolver (inbound/outbound endpoints)
Global DNS failover	Traffic Manager or Front Door
Custom domain for App Service	CNAME to *.azurewebsites.net or A record to IP

4.3 Migration Strategies

The 6 R's of Migration

Strategy	Description	Azure Service
----------	-------------	---------------
Rehost (lift-and-shift)	Move as-is	Azure Migrate → VMs
Refactor (replatform)	Minor changes for cloud	App Service, Container Apps
Rearchitect	Significant redesign	Microservices on AKS, serverless
Rebuild	New cloud-native app	Functions, Cosmos DB
Replace	SaaS alternative	Dynamics 365, SAP on Azure
Retire	Decommission	—

Azure Migrate Workflow

1. Create Migrate project
2. Discover (appliance scans on-prem)
3. Assess (right-sizing, cost estimate, readiness)
4. Replicate (agentless or agent-based)
5. Test migration (non-production)
6. Migrate (planned cutover)
7. Cut over DNS / connection strings

Database Migration Tools

Tool	Use Case
------	----------
Azure Database Migration Service (DMS)	Online migration with minimal downtime
Transactional Replication	SQL Server → Azure SQL (continuous sync)
BACPAC export/import	Small databases, offline
Cosmos DB Data Migration Tool	Import to Cosmos DB

4.4 Application Architecture Patterns

Microservices on AKS

Internet → Front Door / App Gateway → AKS Ingress
                                        ├── Service A (pods)
                                        ├── Service B (pods)
                                        └── Service C (pods)
                                              ├── Cosmos DB
                                              ├── Service Bus
                                              └── Redis Cache

Event-Driven Architecture

Service	Purpose	When
---------	---------	------
Event Grid	Event routing (push)	React to Azure resource changes, custom events
Event Hubs	Event streaming (ingestion)	High-throughput telemetry, Kafka-compatible
Service Bus	Enterprise messaging	Queues, topics, transactions, ordering

🔑 Exam tip: "React to blob upload" → Event Grid. "Millions of IoT events/sec" → Event Hubs. "Order processing with guaranteed delivery" → Service Bus.

Caching

Service	Use Case
---------	----------
Azure Cache for Redis	Session state, output cache, pub/sub, data cache
CDN (Front Door, Azure CDN)	Static content, global distribution
App Service built-in cache	Simple output caching

4.5 Infrastructure as Code and Automation

ARM Templates vs Bicep vs Terraform

Tool	Type	Best For
------	------	----------
ARM (JSON)	Declarative, Azure-native	Legacy, full Azure coverage
Bicep	Declarative, transpiles to ARM	Modern Azure IaC (recommended)
Terraform	Multi-cloud declarative	Hybrid/multi-cloud environments

Azure Deployment Environments

Self-service environment creation for dev teams
Templates + policies for compliant environments

4.6 Domain 4 Case Studies

Case Study: Global Enterprise Network

Requirements: 50 branches, 3 regions, centralised security inspection, branch-to-branch communication, minimise operational overhead.

Answer pattern: Virtual WAN with 3 hubs (US, EU, APAC) + Azure Firewall in each hub + VPN connections from branches + optional ER for HQ.

Case Study: Monolith Migration

Requirements: Java monolith, 500 GB SQL DB, 99.95% SLA, 6-month timeline, team has no container experience.

Answer pattern: Rehost to VMs (or App Service if supported) + SQL Managed Instance + ASR for DR + Azure Migrate for assessment. NOT AKS (team skill gap).

Case Study: Microservices Greenfield

Requirements: New API platform, auto-scale, CI/CD, independent deployments, global users.

Answer pattern: AKS + Azure Container Registry + Front Door + Cosmos DB (Session consistency) + Service Bus + Application Insights + Azure DevOps pipelines.

Case Study: Seasonal Workload

Requirements: 10x traffic spike for 2 weeks/year, minimize cost rest of year.

Answer pattern: VMSS with auto-scale rules (scale out before season) + Spot instances for batch processing + Azure Functions for event processing + Schedule-based scale (Azure Automation).

4.7 Domain 4 Quick Reference

Requirement	Solution
-------------	----------
Simple web app, minimal ops	App Service
Container orchestration	AKS
Serverless event processing	Azure Functions + Event Grid
Legacy app, no changes	VMs via Azure Migrate
Global L7 load balancing + WAF	Azure Front Door
Regional L7 with WAF	Application Gateway v2
L4 load balancing	Azure Load Balancer
Centralised network security	Hub-spoke + Azure Firewall
Many branch offices	Virtual WAN
Private PaaS access from on-prem	Private Endpoint + DNS Private Resolver
Lift-and-shift VMs	Azure Migrate + ASR
SQL Server migration (compatible)	Managed Instance + DMS

1.7 Entra ID Connect Sizing and Staging

Staging Mode

Second Connect server in staging — does not export/sync
Used for: upgrades, disaster recovery of Connect server
Switch to active during maintenance

Sizing Guidelines

Users	Connect Server	SQL DB
-------	---------------	--------
<10K	4 vCPU, 16 GB RAM	4 vCPU, 16 GB
10K–50K	8 vCPU, 32 GB RAM	8 vCPU, 32 GB
50K–100K	16 vCPU, 64 GB RAM	16 vCPU, 64 GB

Filtering

Group-based: Sync only selected groups (minimize cloud objects)
OU-based: Sync specific OUs only
Attribute-based: Filter by attribute values (e.g., department)

1.8 Cost Management and FinOps

Cost Management Tools

Tool	Purpose
------	---------
Cost Analysis	Visualise spending by service, RG, tag
Budgets	Alert when spending exceeds threshold
Cost Alerts	Email/SMS when anomaly detected
Advisor	Right-sizing recommendations
Pricing Calculator	Pre-deployment cost estimate
TCO Calculator	On-prem vs Azure comparison

Reservation Strategy

Commitment	Savings	Best For
------------	---------	----------
1-year RI	~30%	Predictable baseline
3-year RI	~55%	Stable production workloads
Savings Plan (compute)	~30-55%	Flexible across VM families/regions
Spot VMs	Up to 90%	Batch, dev/test, fault-tolerant

2.8 Data Integration Patterns

ETL vs ELT

Pattern	Flow	When
---------	------	------
ETL	Extract → Transform → Load	Traditional DW, complex transforms
ELT	Extract → Load → Transform	Data Lake, big data (transform in-place)

Azure Data Factory

Orchestration service for data movement and transformation
90+ connectors (on-prem and cloud)
Managed VNet Integration for private data sources
Use with: Synapse Pipelines (Synapse includes ADF capabilities)

Change Data Capture (CDC)

Track changes in source database for near-real-time sync
SQL Server CDC → Event Hubs → Stream Analytics → Synapse

3.9 Chaos Engineering and Testing

Azure Chaos Studio

Inject faults to test resilience
Experiments: VM shutdown, network latency, pod failure
Pair with: Monitoring alerts to validate detection

DR Testing Schedule

Test Type	Frequency	Tool
-----------	-----------	------
Backup restore validation	Monthly	Azure Backup test restore
ASR test failover	Quarterly	ASR test failover
Full DR drill	Annually	Runbook execution
Game day	Bi-annually	Chaos Studio + DR combined

4.8 SAP on Azure

SAP Certification

Specific VM sizes certified for SAP HANA and NetWeaver
M-series (memory-optimized) for HANA
Use Azure Center for SAP Solutions for deployment guidance

SAP HA on Azure

Component	HA Solution
-----------	------------
SAP HANA	HANA System Replication + Azure NetApp Files
SAP App Server	Availability Set or Zone across VMs
ASCS/ERS	Pacemaker cluster with Azure Fence Agent

4.9 SAP and Oracle Workloads

Oracle on Azure

Oracle DB on VM (fully supported)
Oracle@Azure (partner solution — collocated Exadata)
Migration: Oracle Data Guard → Azure VM

Design Considerations

Licence mobility via Azure Hybrid Benefit
Ultra SSD for database storage (high IOPS)
Proximity Placement Groups for low latency between app and DB tiers

WELL-ARCHITECTED FRAMEWORK — DEEP DIVE

Cost Optimization Checklist

[ ] Right-size VMs (use Azure Advisor)
[ ] Reserved Instances / Savings Plans for predictable workloads
[ ] Spot VMs for fault-tolerant/batch workloads
[ ] Storage lifecycle policies (Hot → Cool → Archive)
[ ] Shut down dev/test environments outside business hours
[ ] Use serverless where possible (Functions, Container Apps)
[ ] Azure Hybrid Benefit for Windows/SQL licences
[ ] Choose appropriate SQL tier (don't over-provision Business Critical)

Operational Excellence Checklist

[ ] Infrastructure as Code (Bicep/Terraform)
[ ] CI/CD pipelines (Azure DevOps, GitHub Actions)
[ ] Centralised monitoring (Log Analytics, App Insights)
[ ] Automated patching (Update Management, automatic for PaaS)
[ ] Runbooks for common operations (Azure Automation)
[ ] Resource tagging strategy (cost allocation, ownership)

Performance Efficiency Checklist

[ ] CDN for static content
[ ] Redis cache for hot data
[ ] Auto-scale rules (CPU, memory, queue depth, schedule)
[ ] Appropriate database tier and indexing
[ ] Cosmos DB partition key design
[ ] Proximity placement (deploy in user-nearest region)

Reliability Checklist

[ ] Availability Zones for 99.99% SLA
[ ] Auto-failover groups for SQL
[ ] ASR for VM DR
[ ] GRS/GZRS for storage
[ ] Health probes on load balancers
[ ] Circuit breaker pattern for microservices
[ ] Chaos testing (Azure Chaos Studio)

Security Checklist

[ ] Managed identities (no secrets in code)
[ ] Private Endpoints for PaaS
[ ] NSGs + Azure Firewall (defence in depth)
[ ] Encryption at-rest (CMK for sensitive data)
[ ] RBAC least privilege
[ ] Defender for Cloud enabled
[ ] Key Vault for secrets management

CROSS-DOMAIN ARCHITECTURE PATTERNS

Pattern: N-Tier Web Application

Front Door (WAF) → App Gateway → App Service (multiple instances)
                                      ├── SQL Database (zone-redundant)
                                      ├── Redis Cache
                                      └── Storage Account (GRS)
Monitoring: App Insights → Log Analytics → Alerts
Identity: Managed Identity for all service-to-service auth

Pattern: Landing Zone (Enterprise Scale)

Management Groups → Policy (Deny public IP, require tags)
                 → Blueprint (deploy hub VNet, Log Analytics, Automation)
Hub VNet → Azure Firewall, VPN/ER Gateway, DNS Private Resolver
Spoke VNets → Workload subscriptions (peered to hub)
Identity → Entra ID PIM for admin, Conditional Access for users

Pattern: Data Platform

Event Hubs (ingestion) → Stream Analytics (real-time)
                      → ADLS Gen2 (raw zone)
                      → Synapse (curated/analytics zone)
                      → Power BI (visualisation)
Governance: Purview for data catalog and lineage

Pattern: Multi-Region Active-Active

Front Door (global anycast)
    ├── Region A: App Service + Cosmos DB (write region)
    └── Region B: App Service + Cosmos DB (write region)
Traffic Manager (DNS failover backup)
Cosmos DB: Multi-region writes, Session consistency

EXAM QUESTION TYPE STRATEGIES

Type 1: "Choose the best service" (most common)

1. Read scenario — underline HARD requirements (compliance, SLA, latency)
2. Eliminate services that cannot meet hard requirements
3. Compare remaining on WAF pillars mentioned in question
4. Pick the BEST (not just valid) answer

Type 2: Case Study (multi-question set)

1. Read entire case study FIRST — don't jump to questions
2. Note the company name, existing environment, constraints
3. Answers in later questions may depend on earlier decisions
4. Budget/time constraints are usually the tiebreaker

Type 3: "Choose two/three" (multiple select)

1. Each correct answer must be independently valid
2. Don't stop at first good answer — find ALL that apply
3. Wrong answers often violate a single hard requirement

Type 4: Drag-and-drop / ordering

1. Migration steps: Assess → Replicate → Test → Migrate → Cutover
2. Policy hierarchy: MG → Subscription → RG → Resource
3. Failover: Detect → Decide → Failover → Validate → Failback

SERVICE LIMITS AND NUMBERS TO MEMORISE

Item	Value
------	-------
VNet peering	Non-transitive; max 500 peerings per VNet
Subscription limit	5 reserved IPs per subnet
ExpressRoute SLA	99.95% (with Premium for 99.99% multi-path)
VPN Gateway SLA	99.9%
App Service SLA (Standard+)	99.95%
VM SLA (single, no AZ)	99.9%
VM SLA (2+ AZ)	99.99%
SQL Database SLA (zone-redundant)	99.99%
Storage SLA (GRS)	99.99% (read: 99.9% for RA-GRS)
Cosmos DB SLA	99.999% (multi-region)
Management Group depth	6 levels
Azure Policy JSON size	1 MB per policy definition
ASR RPO	As low as 30 seconds (with crash-consistent)
Backup soft delete	14 days (mandatory for new vaults)

FINAL REVIEW CHECKLIST

Before exam day, confirm you can answer:

[ ] When to choose SQL DB vs MI vs VM?
[ ] Hub-spoke vs Virtual WAN decision criteria?
[ ] Cosmos DB consistency levels and when to use each?
[ ] DR strategy for given RTO/RPO requirements?
[ ] Private Endpoint vs Service Endpoint?
[ ] ExpressRoute vs VPN vs ER+VPN?
[ ] Availability Zones vs Availability Sets?
[ ] App Service vs AKS vs VMs for a given workload?
[ ] Storage replication options (LRS/ZRS/GRS/GZRS)?
[ ] Azure Policy effects and when to use DeployIfNotExists?
[ ] Hybrid identity: PHS vs PTA vs Federation?
[ ] Load balancing: LB vs AppGW vs Front Door vs Traffic Manager?
[ ] Map any scenario to a WAF pillar justification?

*AZ-305 Crash Course — aligned with April 17, 2026 skills measured. Pair with [AZ-305-Architect-Sprint-Protocol.md](AZ-305-Architect-Sprint-Protocol.md) for decision matrices and [AZ-305-PRACTICE-EXAM-1.md](AZ-305-PRACTICE-EXAM-1.md) for timed practice.*

APPENDIX SECTION 1: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 1: Design Pattern Notes

Pattern 1: Apply WAF pillar mapping to every service selection
Trade-off 1: Document cost vs reliability for each tier choice
Exam tip 1: Read ALL case study requirements before answering Q1

APPENDIX SECTION 2: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 2: Design Pattern Notes

Pattern 2: Apply WAF pillar mapping to every service selection
Trade-off 2: Document cost vs reliability for each tier choice
Exam tip 2: Read ALL case study requirements before answering Q1

APPENDIX SECTION 3: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 3: Design Pattern Notes

Pattern 3: Apply WAF pillar mapping to every service selection
Trade-off 3: Document cost vs reliability for each tier choice
Exam tip 3: Read ALL case study requirements before answering Q1

APPENDIX SECTION 4: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 4: Design Pattern Notes

Pattern 4: Apply WAF pillar mapping to every service selection
Trade-off 4: Document cost vs reliability for each tier choice
Exam tip 4: Read ALL case study requirements before answering Q1

APPENDIX SECTION 5: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 5: Design Pattern Notes

Pattern 5: Apply WAF pillar mapping to every service selection
Trade-off 5: Document cost vs reliability for each tier choice
Exam tip 5: Read ALL case study requirements before answering Q1

APPENDIX SECTION 6: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 6: Design Pattern Notes

Pattern 6: Apply WAF pillar mapping to every service selection
Trade-off 6: Document cost vs reliability for each tier choice
Exam tip 6: Read ALL case study requirements before answering Q1

APPENDIX SECTION 7: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 7: Design Pattern Notes

Pattern 7: Apply WAF pillar mapping to every service selection
Trade-off 7: Document cost vs reliability for each tier choice
Exam tip 7: Read ALL case study requirements before answering Q1

APPENDIX SECTION 8: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 8: Design Pattern Notes

Pattern 8: Apply WAF pillar mapping to every service selection
Trade-off 8: Document cost vs reliability for each tier choice
Exam tip 8: Read ALL case study requirements before answering Q1

APPENDIX SECTION 9: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 9: Design Pattern Notes

Pattern 9: Apply WAF pillar mapping to every service selection
Trade-off 9: Document cost vs reliability for each tier choice
Exam tip 9: Read ALL case study requirements before answering Q1

APPENDIX SECTION 10: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 10: Design Pattern Notes

Pattern 10: Apply WAF pillar mapping to every service selection
Trade-off 10: Document cost vs reliability for each tier choice
Exam tip 10: Read ALL case study requirements before answering Q1

APPENDIX SECTION 11: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 11: Design Pattern Notes

Pattern 11: Apply WAF pillar mapping to every service selection
Trade-off 11: Document cost vs reliability for each tier choice
Exam tip 11: Read ALL case study requirements before answering Q1

APPENDIX SECTION 12: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 12: Design Pattern Notes

Pattern 12: Apply WAF pillar mapping to every service selection
Trade-off 12: Document cost vs reliability for each tier choice
Exam tip 12: Read ALL case study requirements before answering Q1

APPENDIX SECTION 13: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 13: Design Pattern Notes

Pattern 13: Apply WAF pillar mapping to every service selection
Trade-off 13: Document cost vs reliability for each tier choice
Exam tip 13: Read ALL case study requirements before answering Q1

APPENDIX SECTION 14: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 14: Design Pattern Notes

Pattern 14: Apply WAF pillar mapping to every service selection
Trade-off 14: Document cost vs reliability for each tier choice
Exam tip 14: Read ALL case study requirements before answering Q1

APPENDIX SECTION 15: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 15: Design Pattern Notes

Pattern 15: Apply WAF pillar mapping to every service selection
Trade-off 15: Document cost vs reliability for each tier choice
Exam tip 15: Read ALL case study requirements before answering Q1

APPENDIX SECTION 16: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 16: Design Pattern Notes

Pattern 16: Apply WAF pillar mapping to every service selection
Trade-off 16: Document cost vs reliability for each tier choice
Exam tip 16: Read ALL case study requirements before answering Q1

APPENDIX SECTION 17: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 17: Design Pattern Notes

Pattern 17: Apply WAF pillar mapping to every service selection
Trade-off 17: Document cost vs reliability for each tier choice
Exam tip 17: Read ALL case study requirements before answering Q1

APPENDIX SECTION 18: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 18: Design Pattern Notes

Pattern 18: Apply WAF pillar mapping to every service selection
Trade-off 18: Document cost vs reliability for each tier choice
Exam tip 18: Read ALL case study requirements before answering Q1

APPENDIX SECTION 19: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 19: Design Pattern Notes

Pattern 19: Apply WAF pillar mapping to every service selection
Trade-off 19: Document cost vs reliability for each tier choice
Exam tip 19: Read ALL case study requirements before answering Q1

APPENDIX SECTION 20: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 20: Design Pattern Notes

Pattern 20: Apply WAF pillar mapping to every service selection
Trade-off 20: Document cost vs reliability for each tier choice
Exam tip 20: Read ALL case study requirements before answering Q1

APPENDIX SECTION 21: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 21: Design Pattern Notes

Pattern 21: Apply WAF pillar mapping to every service selection
Trade-off 21: Document cost vs reliability for each tier choice
Exam tip 21: Read ALL case study requirements before answering Q1

APPENDIX SECTION 22: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 22: Design Pattern Notes

Pattern 22: Apply WAF pillar mapping to every service selection
Trade-off 22: Document cost vs reliability for each tier choice
Exam tip 22: Read ALL case study requirements before answering Q1

APPENDIX SECTION 23: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 23: Design Pattern Notes

Pattern 23: Apply WAF pillar mapping to every service selection
Trade-off 23: Document cost vs reliability for each tier choice
Exam tip 23: Read ALL case study requirements before answering Q1

APPENDIX SECTION 24: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 24: Design Pattern Notes

Pattern 24: Apply WAF pillar mapping to every service selection
Trade-off 24: Document cost vs reliability for each tier choice
Exam tip 24: Read ALL case study requirements before answering Q1

APPENDIX SECTION 25: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 25: Design Pattern Notes

Pattern 25: Apply WAF pillar mapping to every service selection
Trade-off 25: Document cost vs reliability for each tier choice
Exam tip 25: Read ALL case study requirements before answering Q1

APPENDIX SECTION 26: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 26: Design Pattern Notes

Pattern 26: Apply WAF pillar mapping to every service selection
Trade-off 26: Document cost vs reliability for each tier choice
Exam tip 26: Read ALL case study requirements before answering Q1

APPENDIX SECTION 27: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 27: Design Pattern Notes

Pattern 27: Apply WAF pillar mapping to every service selection
Trade-off 27: Document cost vs reliability for each tier choice
Exam tip 27: Read ALL case study requirements before answering Q1

APPENDIX SECTION 28: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 28: Design Pattern Notes

Pattern 28: Apply WAF pillar mapping to every service selection
Trade-off 28: Document cost vs reliability for each tier choice
Exam tip 28: Read ALL case study requirements before answering Q1

APPENDIX SECTION 29: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 29: Design Pattern Notes

Pattern 29: Apply WAF pillar mapping to every service selection
Trade-off 29: Document cost vs reliability for each tier choice
Exam tip 29: Read ALL case study requirements before answering Q1

APPENDIX SECTION 30: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 30: Design Pattern Notes

Pattern 30: Apply WAF pillar mapping to every service selection
Trade-off 30: Document cost vs reliability for each tier choice
Exam tip 30: Read ALL case study requirements before answering Q1

APPENDIX SECTION 31: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 31: Design Pattern Notes

Pattern 31: Apply WAF pillar mapping to every service selection
Trade-off 31: Document cost vs reliability for each tier choice
Exam tip 31: Read ALL case study requirements before answering Q1

APPENDIX SECTION 32: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 32: Design Pattern Notes

Pattern 32: Apply WAF pillar mapping to every service selection
Trade-off 32: Document cost vs reliability for each tier choice
Exam tip 32: Read ALL case study requirements before answering Q1

APPENDIX SECTION 33: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 33: Design Pattern Notes

Pattern 33: Apply WAF pillar mapping to every service selection
Trade-off 33: Document cost vs reliability for each tier choice
Exam tip 33: Read ALL case study requirements before answering Q1

APPENDIX SECTION 34: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 34: Design Pattern Notes

Pattern 34: Apply WAF pillar mapping to every service selection
Trade-off 34: Document cost vs reliability for each tier choice
Exam tip 34: Read ALL case study requirements before answering Q1

APPENDIX SECTION 35: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 35: Design Pattern Notes

Pattern 35: Apply WAF pillar mapping to every service selection
Trade-off 35: Document cost vs reliability for each tier choice
Exam tip 35: Read ALL case study requirements before answering Q1

APPENDIX SECTION 36: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 36: Design Pattern Notes

Pattern 36: Apply WAF pillar mapping to every service selection
Trade-off 36: Document cost vs reliability for each tier choice
Exam tip 36: Read ALL case study requirements before answering Q1

APPENDIX SECTION 37: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 37: Design Pattern Notes

Pattern 37: Apply WAF pillar mapping to every service selection
Trade-off 37: Document cost vs reliability for each tier choice
Exam tip 37: Read ALL case study requirements before answering Q1

APPENDIX SECTION 38: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 38: Design Pattern Notes

Pattern 38: Apply WAF pillar mapping to every service selection
Trade-off 38: Document cost vs reliability for each tier choice
Exam tip 38: Read ALL case study requirements before answering Q1

APPENDIX SECTION 39: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 39: Design Pattern Notes

Pattern 39: Apply WAF pillar mapping to every service selection
Trade-off 39: Document cost vs reliability for each tier choice
Exam tip 39: Read ALL case study requirements before answering Q1

APPENDIX SECTION 40: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 40: Design Pattern Notes

Pattern 40: Apply WAF pillar mapping to every service selection
Trade-off 40: Document cost vs reliability for each tier choice
Exam tip 40: Read ALL case study requirements before answering Q1

APPENDIX SECTION 41: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 41: Design Pattern Notes

Pattern 41: Apply WAF pillar mapping to every service selection
Trade-off 41: Document cost vs reliability for each tier choice
Exam tip 41: Read ALL case study requirements before answering Q1

APPENDIX SECTION 42: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 42: Design Pattern Notes

Pattern 42: Apply WAF pillar mapping to every service selection
Trade-off 42: Document cost vs reliability for each tier choice
Exam tip 42: Read ALL case study requirements before answering Q1

APPENDIX SECTION 43: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 43: Design Pattern Notes

Pattern 43: Apply WAF pillar mapping to every service selection
Trade-off 43: Document cost vs reliability for each tier choice
Exam tip 43: Read ALL case study requirements before answering Q1

APPENDIX SECTION 44: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 44: Design Pattern Notes

Pattern 44: Apply WAF pillar mapping to every service selection
Trade-off 44: Document cost vs reliability for each tier choice
Exam tip 44: Read ALL case study requirements before answering Q1

APPENDIX SECTION 45: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 45: Design Pattern Notes

Pattern 45: Apply WAF pillar mapping to every service selection
Trade-off 45: Document cost vs reliability for each tier choice
Exam tip 45: Read ALL case study requirements before answering Q1

APPENDIX SECTION 46: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 46: Design Pattern Notes

Pattern 46: Apply WAF pillar mapping to every service selection
Trade-off 46: Document cost vs reliability for each tier choice
Exam tip 46: Read ALL case study requirements before answering Q1

APPENDIX SECTION 47: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 47: Design Pattern Notes

Pattern 47: Apply WAF pillar mapping to every service selection
Trade-off 47: Document cost vs reliability for each tier choice
Exam tip 47: Read ALL case study requirements before answering Q1

APPENDIX SECTION 48: Additional Architecture Deep Dive

APPENDIX A — EXPANDED CASE STUDY WALKTHROUGHS

Case Study Walkthrough 1: Contoso Manufacturing

Background: Contoso has 3 on-premises datacenters, 15,000 employees, running SAP and custom .NET apps. Moving to Azure over 18 months. Budget: \/year cloud spend cap.

Requirements matrix:

Req ID	Requirement	WAF Pillar	Hard/Soft
--------	-------------	------------	-----------
R1	99.95% SLA for production	Reliability	Hard
R2	SAP HANA certified infrastructure	Reliability	Hard
R3	Reduce TCO 25% vs on-prem	Cost	Hard
R4	EU data residency for EU users	Security	Hard
R5	Minimize app code changes	Operational Excellence	Soft
R6	Self-service dev environments	Operational Excellence	Soft

Q1: SAP HANA deployment?

A) SQL Database → Wrong (not SAP certified)
B) M-series VM with HANA + ANF → Correct
C) SAP on App Service → Wrong (not supported)
D) Cosmos DB → Wrong (not relational SAP)

Q2: Network topology for 3 regions?

A) Flat VNet peering mesh → Wrong (non-transitive, unmanageable)
B) Virtual WAN with 3 regional hubs + Azure Firewall → Correct
C) Single hub-spoke in US only → Wrong (EU residency)
D) Public IPs for all services → Wrong (security)

Q3: Dev environment provisioning?

A) Manual portal creation → Wrong (doesn't scale)
B) Azure Deployment Environments with Policy guardrails → Correct
C) Unlimited Owner access for all devs → Wrong (security)
D) Separate Azure tenant per dev → Wrong (cost/complexity)

Supplemental Topic 48: Design Pattern Notes

Pattern 48: Apply WAF pillar mapping to every service selection
Trade-off 48: Document cost vs reliability for each tier choice
Exam tip 48: Read ALL case study requirements before answering Q1

APPENDIX SECTION 49: Additional Architecture Deep Dive

Case Study Walkthrough 2: Fabrikam Healthcare

Background: Fabrikam runs a patient portal (5M users), HIPAA compliant, US-only data residency.

Architecture decisions:

1. Identity: Entra External ID (B2C) for patients; workforce Entra ID P2 for staff
2. Data: SQL Database with TDE + Always Encrypted for PHI columns
3. Network: Private Endpoints for all PaaS; no public endpoints
4. Monitoring: Log Analytics with 6-year retention (HIPAA audit)
5. DR: Auto-failover group to paired US region; RPO < 1 hour

Trap answers:

B2B for patients → Wrong (B2B is for partner employees)
Service Endpoints for PHI → Insufficient (no on-prem, but PE is still best practice)
GRS to EU region → Violates US residency requirement

Supplemental Topic 49: Design Pattern Notes

Pattern 49: Apply WAF pillar mapping to every service selection
Trade-off 49: Document cost vs reliability for each tier choice
Exam tip 49: Read ALL case study requirements before answering Q1

APPENDIX SECTION 50: Additional Architecture Deep Dive

Case Study Walkthrough 3: Adventure Works E-Commerce

Black Friday: 50x normal traffic, 2-hour peak, \ revenue at risk per hour of downtime.

Scale strategy:

1. Pre-scale App Service instances 24h before (scheduled scale rule)
2. Cosmos DB autoscale max RU increased for peak
3. Front Door caches static assets (product images)
4. Redis cache for session and hot product data
5. SQL read replicas for order history queries
6. Queue-based order processing (Service Bus) for async fulfillment

Cost optimization post-peak:

Scale down to baseline after 48 hours
Cosmos autoscale reduces RU automatically
Spot VMs for batch order processing reports

Supplemental Topic 50: Design Pattern Notes

Pattern 50: Apply WAF pillar mapping to every service selection
Trade-off 50: Document cost vs reliability for each tier choice
Exam tip 50: Read ALL case study requirements before answering Q1