AZ-305 — Designing Microsoft Azure Infrastructure Solutions

📅 Last Researched: May 2026 · 📖 Source: Microsoft Learn Official Study Guides

⚡ Strategy: You already work heavily with Azure — this guide focuses on exam-specific nuances, decision-tree logic, and the details Microsoft actually tests. Conceptual overviews are kept brief; depth is on the tricky parts.

Exam Overview & Strategy

AZ-305 is about architectural decision-making. You’re not asked how to configure — you’re asked which service to choose, why, and what the trade-offs are. Questions present a business requirement and ask which design meets it with the fewest compromises.

Questions	Pass Score	Duration	Updated	Prerequisite
40–60	700 / 1000	120 min	Apr 17, 2026	AZ-104 cert

AZ-104 (Admin)	AZ-305 (Architect)
“How do you configure X?”	“Which service should you use for Y?”
CLI commands, portal steps	Architectural trade-offs, cost/compliance
Single service deep dives	Cross-service integration patterns
Operations mindset	Design / architect mindset

Azure Well-Architected Framework (WAF) — Always in Context

Every AZ-305 design decision should be evaluated against WAF pillars:

• ⚡ Reliability — HA, DR, resilience, fault tolerance
• 🔒 Security — Zero trust, defense in depth, least privilege
• 💰 Cost Optimization — Right-sizing, reserved capacity, eliminating waste
• 🛠️ Operational Excellence — Automation, observability, DevOps
• 🚀 Performance Efficiency — Scaling, caching, right service selection

Domain 1 – Design Identity, Governance, and Monitoring Solutions (25–30%)

1.1 Design Identity and Access Management

• Choose between Entra ID, AD DS (on-prem), and Entra Domain Services
• Hybrid identity: password hash sync vs. pass-through auth vs. federation (ADFS)
• External identity: B2B (partner access) vs. B2C (customer-facing apps)
• Conditional Access: named locations, sign-in risk, device compliance
• PIM — just-in-time access, time-bound role assignments, approval workflows

	Entra ID	AD DS (on-prem)	Entra Domain Services
Protocol	REST / OAuth / OIDC	Kerberos / LDAP / NTLM	Kerberos / LDAP / NTLM
Managed	Fully managed	You manage	Fully managed
Use case	Cloud apps, SaaS	Legacy apps on-prem	Lift-and-shift needing Kerberos
Domain join	Entra Join	Traditional domain join	Classic domain join

Exam Rule

Partners/vendors → B2B (Entra External ID). Customers/consumers of your app → B2C (separate tenant).

Authorization & Secrets:

• RBAC = what an identity can do, scoped at management group / subscription / resource group / resource. ABAC adds conditions on top of RBAC (e.g., blob index tags) for finer-grained control.
• Managed identities (system-assigned vs. user-assigned) are the default answer whenever one Azure resource needs to authenticate to another without stored credentials.
• On-prem authorization: Entra Application Proxy publishes on-prem web apps without a VPN; Entra Domain Services serves legacy NTLM/Kerberos apps without standing up domain controllers.
• Key Vault: standard Vault (software-protected) vs. Managed HSM (dedicated FIPS 140-2 Level 3 hardware — needed for strict compliance/BYOK). Access via RBAC; integrate through managed identity, never hardcode secrets.
• Identity Governance: Catalog Owner is the least-privilege role for creating access packages, adding resources, and building access-package policies — prefer it over Catalog Creator (new catalogs only) or User Administrator (too broad, tenant-wide) whenever the requirement is scoped delegation.

Exam Tip

“Two Azure resources need to talk, no credentials should be stored” → managed identity, every time.

Key Vault: two protections, two threats

Soft delete recovers accidentally deleted vaults/objects within a retention window. Purge protection blocks permanent purge during that window even for someone with delete rights — it’s the defense against malicious/insider deletion. A requirement stating both “prevent accidental deletion” and “prevent deletion during a retention period” needs both enabled together; they answer different halves of the same question.

AKS RBAC — built-in roles (easy to mix up):

Role	Grants
Azure Kubernetes Service Contributor Role	View/modify Kubernetes RBAC roles and role bindings inside the cluster — the least-privilege answer when a user must manage AKS RBAC
AKS Cluster Admin Role	Lists cluster admin kubeconfig credentials only
AKS Cluster User Role	Lists user kubeconfig credentials only
AKS RBAC Writer	Read/write Kubernetes objects — cannot modify roles/bindings

1.2 Design Governance Solutions

• Management group hierarchy and policy inheritance

• Azure Policy at scale — initiative assignments, remediation tasks

• Tagging strategy for cost allocation and resource organization

• Azure Cost Management: budgets, cost alerts, Advisor recommendations

• Landing Zone design (CAF) — platform and application landing zones

• Platform landing zone: Centralized shared services — identity, connectivity, management

• Application landing zone: Subscriptions for individual workloads/apps

• Hub-spoke: Hub = shared services (firewall, DNS, VPN/ER); Spokes = workload VNets

• Policies with DeployIfNotExists or Modify require a managed identity for remediation tasks

Compliance & Identity Governance:

• Microsoft Defender for Cloud — Secure Score and the regulatory compliance dashboard for continuous posture management.
• Entra ID Governance: access reviews (recurring recertification), entitlement management (time-bound access packages), Lifecycle Workflows (automate joiner/mover/leaver).

Policy vs. RBAC

Azure Policy = what configuration is allowed (deny, audit, append, deployIfNotExists). RBAC = who can act. Different questions — often tested together in the same scenario.

Policy vs. Blueprints: Azure Policy evaluates allow/deny against resource properties, both at deployment time and continuously against existing resources — it governs whether a change is allowed. Azure Blueprints is a package of artifacts (resource groups, ARM templates, role assignments, policy/initiative assignments) that reproduces a standard environment pattern — a policy can be one artifact inside a blueprint. Blueprints define what gets built; Policy governs what’s allowed to exist.

Tagging strategy: when a requirement stacks case-insensitive tag enforcement + blocking resource creation on missing/invalid tags + automatic inheritance from resource group to child resources, Azure Policy is the only mechanism giving pre-creation enforcement, ongoing compliance, and inheritance all at once — ARM templates and Automation runbooks can’t do all three together.

1.3 Design Monitoring Solutions

• Azure Monitor: Metrics, Logs, Traces, Changes
• Diagnostic settings route platform logs/metrics to: Log Analytics workspace (central cross-subscription query), Storage account (cheapest long-term retention), Event Hub (real-time streaming to a SIEM/third-party), or a partner solution.
• Application Insights: APM, distributed tracing, availability tests
• Network Watcher: network-layer diagnostics (NSG flow logs, connection troubleshoot)
• Microsoft Sentinel: SIEM/SOAR for security monitoring
• Azure Service Health (platform-wide) vs. Resource Health (your specific resource)

Exam Trap

Platform metrics and Activity Log entries are emitted automatically at no cost — but nothing reaches a Log Analytics workspace without an explicit diagnostic setting. “Why isn’t data showing up in my workspace?” almost always means no diagnostic setting was configured.

Default answer: start with a single workspace — the exam wants you to justify additional workspaces, not assume you need them. Ingestion volume alone isn’t a reason to split. Split only when one of these applies:

Criterion	When to split
Entra tenant boundary	One workspace per tenant — most sources can only send to a workspace in the same tenant
Region/residency	Regulatory requirements pin data to a geography
Data ownership	Separate business units need clearly separated data
Split billing	Workspaces in different subscriptions bill different cost centers
Differing retention	Different retention requirements across resources writing to the same table
Commitment tier	≥100 GB/day ingestion → consolidate into a dedicated cluster (can span multiple workspaces) to hit a discount tier
Legacy agent limit	The (Linux legacy) Log Analytics agent can only connect to one workspace — Azure Monitor Agent is needed for multi-workspace
Access control	Default resource-context RBAC inherits from resource permissions; switch to “require workspace permissions” for centralized, explicit access control

Workspace Strategy	When to Use	Trade-off
Centralized (one workspace)	SMB, unified ops team	Data sovereignty concerns, noisy neighbors
Decentralized (per-team/region)	Large orgs, compliance	Higher cost, fragmented queries
Hybrid	Regulated industries	Balance of both

Exam Tip

“Logs must stay in EU” or data sovereignty requirements → separate workspace per region.

Logging solution quick-answers:

Need	Answer	Why
Log IP traffic entering/leaving a VNet	Virtual network flow logs	Activity Log = control-plane only; App Insights = app telemetry
Live-stream App Service log events	az webapp log tail	log show is static config, not live
Debug/trace-level App Service logging	Verbose diagnostic level	Error/Warning/Information tiers exclude debug/trace
Immutable, 5-yr retention, high-speed-access logs	Premium Blob Storage + Immutable Storage (legal hold)	Archive/Cool tiers fail the “high-speed access” requirement

Domain 2 – Design Data Storage Solutions (20–25%)

2.1 Design Storage Accounts

Service	Use Case
Blob Storage	Unstructured data: images, videos, backups, logs
ADLS Gen2	Big data analytics (Hadoop/Spark) — Blob + hierarchical namespace
Azure Files	SMB/NFS file shares, lift-and-shift file servers
Azure Queues	Simple message queuing, decoupling
Azure Tables	NoSQL key-value store, simple structured data
Azure Disks	VM OS and data disks

Exam Tip

Access tiers (Hot/Cool/Cold/Archive) trade cost against retrieval latency — Archive is cheapest but takes hours to rehydrate. Redundancy (LRS < ZRS < GRS < GZRS, plus RA- read-access variants) trades cost against durability/RPO. Match both to actual access pattern and recovery requirement, not just the lowest price. Azure NetApp Files covers high-performance enterprise file workloads beyond what Azure Files offers.

ADLS Gen2: ACLs vs. RBAC

Default ACLs on a parent folder auto-apply to new child files/folders created under it; access ACLs only affect the object they’re set on directly. For ACLs to actually be the enforcement mechanism, users must not also hold Reader/Contributor/Owner RBAC roles — those grant blanket access that bypasses ACL evaluation entirely for reads.

2.2 Design Relational Database Solutions

Scenario	Service
New cloud-native app, no special SQL features	Azure SQL Database (single DB)
Multiple DBs with variable/unpredictable load	Elastic Pool
Need SQL Agent, cross-DB queries, CLR, Service Broker	SQL Managed Instance
Full OS access, custom SQL install, third-party tools	SQL Server on Azure VM
Very large database (100 TB+), rapid scaling	Hyperscale tier

Exam Rule

SQL Agent jobs, linked servers, CLR, MSDTC → SQL Managed Instance. Everything else → consider SQL Database first.

Compute Tiers:

• DTU-based: simple, bundled compute + storage — easiest to reason about for small/predictable workloads.
• vCore-based: Provisioned (steady workload) vs. Serverless (auto-pauses, auto-scales — best for intermittent workloads).
• Hyperscale: independent of database size, built for very large or fast-growing databases needing fast backup/restore.

Scalability: read replicas offload read traffic; elastic pools share resources across many variable-usage databases; sharding/partitioning scales horizontally — a shard is one SQL DB holding one or more shardlets grouped by a shardlet key (e.g., tenant ID), with a separate shard-map-manager database tracking the mapping.

Data Protection: TDE encrypts at rest by default. Always Encrypted protects specific columns even from DBAs. PITR (point-in-time restore) plus long-term retention and geo-restore cover recovery.

2.3 Design NoSQL / Cosmos DB Solutions

• Cosmos DB APIs: NoSQL (document), MongoDB, Cassandra, Table, Gremlin (graph)
• Request Units (RUs) — currency for Cosmos DB throughput
• Partition key selection — determines data distribution and hot partition risk
• Multi-region writes for global active-active

The 5 Consistency Levels (memorize these):

1. Strong — linearizability, highest read consistency, highest latency
2. Bounded Staleness — lag by K operations or T time
3. Session — consistent within a session (default, most popular)
4. Consistent Prefix — never see out-of-order writes
5. Eventual — lowest latency, highest throughput, no ordering guarantees

Use Case	Recommended Consistency
Financial transactions requiring accuracy	Strong
Shopping cart, user session	Session (default)
Social media likes, IoT telemetry	Eventual
Global reads with acceptable lag	Bounded Staleness

Exam Trap

“Session” is the default and best for most apps. “Strong” consistency kills performance across multi-region deployments — avoid unless truly required.

Backup for self-service restore: Continuous backup mode allows self-service restore to any point in the last 30 days, no support ticket. Periodic backup mode has a minimum 1-hour granularity and requires a support ticket to restore. “Restore to any point in time, self-service” always resolves to continuous backup.

2.4 Design Data Integration Solutions

Service	What It Is	Use When	Why
Azure Data Factory (ADF)	Cloud ETL/ELT orchestration	Move/orchestrate data across 90+ sources (on-prem, SaaS, cloud); hybrid scenarios	Low-code pipeline orchestration; self-hosted Integration Runtime reaches on-prem without opening firewall ports. Delegates heavy compute to Spark/SQL/Databricks — Mapping Data Flows are the exception, running on ADF-managed Spark.
Azure Synapse Analytics	Unified workspace: dedicated SQL pool (DW), serverless SQL pool (query the lake, no infra), Spark pools, Pipelines (ADF engine), Power BI/Purview integration	Need DW + big-data processing + orchestration in one workspace; “single pane of glass,” enterprise DW modernization	Consolidates what would otherwise be separate ADF + Databricks + SQL DW resources. Serverless SQL pool = T-SQL over lake files, billed per query, nothing to provision.
Azure Data Explorer (ADX)	Fully managed analytics for log/telemetry/time-series data, queried in KQL	Near-real-time, ad-hoc exploration of huge volumes of semi-structured/streaming data — logs, metrics, IoT telemetry, security/audit trails	Purpose-built for append-heavy, timestamped data with sub-second queries over billions of rows. Not for transactional/relational workloads. Available standalone or as a Data Explorer pool inside Synapse.
Azure Databricks	Managed Apache Spark + collaborative notebooks, Delta Lake, MLflow	Advanced data engineering + ML/data-science collaboration, Spark transforms beyond what ADF Data Flows offer	Best tooling for the full ML lifecycle; fits a team already fluent in notebooks/Spark.
Azure Stream Analytics	Real-time stream processing, SQL-like query language	Simple, continuous windowed filtering/aggregation on streaming data	Low-code, fully managed, no cluster to size — a job just sits between an input (Event Hubs/IoT Hub/Blob) and an output (Power BI, Storage, ADX, Functions, Synapse).
Power BI	Visualization/reporting	Dashboards, self-service BI for business users	Connects live (DirectQuery) or imports from Synapse SQL, ADX, Cosmos DB, etc. — the serving/visualization layer, not a compute engine.
Microsoft Purview	Data governance/catalog/lineage	Discover, classify, and track lineage of data across ADF, Synapse, ADLS, on-prem sources	Automated scanning + classification + end-to-end lineage map — the governance layer sitting over everything else in this table.

Service	Model	Ordering	Retention	Best For
Event Hubs	Streaming	By partition	Up to 90 days	Telemetry, log ingestion, Kafka
Service Bus (Queue)	Queue	FIFO per session, transactional	Up to 14 days	Ordered/transactional messaging, dead-lettering, duplicate detection
Service Bus (Topic)	Pub/Sub	FIFO per session	Up to 14 days	One message → multiple subscribers, with filtering
Event Grid	Pub/Sub	No	Up to 24 hours	Reactive event routing, serverless
Storage Queue	Queue	Best-effort	7 days	Simple, high-volume (>80 GB), lowest-cost queue

Memory Hook

Grid = event happened (react) · Hubs = event stream (ingest) · Service Bus = message (process, order matters).

2.5 Data & Analytics Platform — Choosing Between Similar Services

The head-to-head pairs that are easy to mix up on the exam:

Decision	Pick…	…When	Not the Other, Because
ADF vs. Synapse Pipelines	Standalone ADF	Only orchestration/ETL is needed, no integrated SQL/Spark workspace	Synapse Pipelines is the same ADF engine embedded in Synapse — no benefit, just workspace overhead
ADF vs. Synapse Pipelines	Synapse (Pipelines)	Pipelines + DW/Spark + Power BI need to live in one workspace (“unified analytics” in the question)	Standalone ADF can’t run dedicated/serverless SQL or Spark pools itself
ADX vs. Stream Analytics	ADX	Analysts need ad-hoc, ever-changing KQL queries across historical + streaming log/telemetry data	Stream Analytics runs one fixed continuous query — not built for exploration
ADX vs. Stream Analytics	Stream Analytics	Simple, known-in-advance transform (filter/aggregate/window) piping Event Hubs → a sink	ADX is overkill/costlier for a straight-through streaming ETL job
ADX vs. Synapse (SQL/Spark)	ADX	Time-series/log data, need sub-second queries on huge append-only datasets	Synapse SQL/Spark target structured/semi-structured relational & big-data analytics, not tuned for ADX-scale time-series
Databricks vs. Synapse Spark pools	Databricks	Team needs the full ML lifecycle (MLflow), cross-workspace notebook collaboration, or is already standardized on it	Synapse Spark’s ML tooling is lighter
Databricks vs. Synapse Spark pools	Synapse Spark pools	The Spark transform step should live inside the same workspace as your pipelines/SQL pools	Avoids standing up a separate Databricks resource for one step in a Synapse pipeline
Dedicated vs. Serverless SQL pool	Dedicated	Predictable, high-concurrency enterprise DW workload needing reserved performance (DWUs)	Serverless bills per TB scanned — unpredictable cost at constant high concurrency
Dedicated vs. Serverless SQL pool	Serverless	Ad-hoc/exploratory queries directly against lake files, low/unpredictable usage	Nothing to provision or pay for when idle — wins on “minimize cost” for sporadic querying

How they chain together (typical end-to-end flow):

INGEST                        STORE              PROCESS / TRANSFORM              SERVE / ANALYZE          VISUALIZE
Event Hubs / IoT Hub      →                  →   Stream Analytics (real-time)  →  ADX or Synapse SQL   →   Power BI
ADF (batch: on-prem,      →   ADLS Gen2     →   Databricks / Synapse Spark /      (curated "gold" layer)
SaaS, other clouds)           ("bronze")        ADF Data Flows (batch,
                                                 "bronze → silver → gold")
                                                           ↑
                                       Purview scans, classifies, and tracks lineage across all of the above

Mapping Scenarios to Answers

• “Nightly load from on-prem SQL Server into a cloud DW” → ADF (self-hosted IR) → ADLS Gen2 → Synapse dedicated SQL pool
• “Real-time IoT telemetry, analysts need flexible ad-hoc queries” → IoT Hub → ADX → Power BI
• “Simple real-time alert when a sensor crosses a threshold” → Event Hubs → Stream Analytics → Functions/Power BI
• “Data scientists need notebooks + ML models on large datasets” → ADLS Gen2 → Databricks (Delta Lake)
• “Occasional queries against lake files, no infra budget” → ADLS Gen2 → Synapse serverless SQL pool → Power BI
• “Need governance/lineage across ADF, Synapse, and on-prem” → Purview

Domain 3 – Design Business Continuity Solutions (15–20%)

3.1 Design for High Availability

• SLA targets and composite SLA calculation
• Availability Zones for zone-redundant services
• Regional pairs — used for GRS storage and some service replication

Exam Trap

Availability Set protects against rack-level hardware failure within one datacenter (fault/update domains). Availability Zone protects against loss of an entire datacenter, using physically separate facilities in a region, and gives a higher SLA — prefer Zones whenever the region supports them.

Exam Tip

“Protect against both Azure maintenance activity and datacenter-level failure” → Availability Sets + Availability Zones together — two separate mechanisms addressing two separate failure scopes, often the correct answer to a “select two” question rather than a substitute for each other.

• VM Scale Sets provide elastic HA plus autoscale — prefer over a manually managed VM fleet.

Load Balancing & Routing — ask two questions: regional or global? Layer 4 or Layer 7?

Service	Scope	Layer	Best For
Load Balancer (Standard)	Regional	L4 (TCP/UDP)	Fast in-region TCP/UDP balancing
Application Gateway	Regional	L7 (HTTP/S)	Web traffic, URL routing, WAF
Traffic Manager	Global	DNS-based	Global routing, non-HTTP, DNS failover
Front Door	Global	L7 (HTTP/S)	Global HTTP acceleration, CDN, WAF

Data Tier HA:

• SQL: auto-failover groups for cross-region failover, zone-redundant configuration for in-region HA.
• Cosmos DB: multi-region writes for the highest HA tier.

Composite SLA Formulas:

Serial (AND):   SLA_A × SLA_B  →  99.9% × 99.9% = 99.8%
Parallel (OR):  1 − (1 − SLA_A) × (1 − SLA_B)  →  1 − (0.001 × 0.001) = 99.9999%

Exam Tip

Two serial dependencies → composite SLA is always lower than the weakest individual SLA. Redundant (parallel) copies dramatically increase availability.

3.2 Design for Disaster Recovery

• RTO (Recovery Time Objective) — max acceptable downtime
• RPO (Recovery Point Objective) — max acceptable data loss
• Azure Site Recovery (ASR): VM replication — Azure-to-Azure, on-prem-to-Azure
• Azure Backup: point-in-time recovery for VMs, SQL, blobs, files

Exam Trap

Every business-continuity question traces back to RTO and RPO first — identify those two numbers before picking a service. Azure Backup restores a point in time; Azure Site Recovery fails over a live environment. Don’t reach for ASR when the scenario only needs point-in-time restore.

	Azure Site Recovery	Azure Backup
Purpose	DR — replicate whole workload	Backup — restore individual items
RPO	As low as 30 seconds (VMs)	Depends on policy (daily, hourly)
Fails over	Entire VM/workload	Individual files, databases, VMs
Cost driver	Replication + storage	Storage only

DR Pattern	RTO	RPO	Cost
Backup and restore	Hours	Hours	Lowest
Pilot light	10s of minutes	Minutes	Low
Warm standby	Minutes	Seconds	Medium
Active-active	Near zero	Near zero	Highest

DR architecture considerations, easy to overlook:

• Region pairs aren’t symmetric for every service — some VM SKUs or storage types may not be available in the paired region, so don’t assume platform-assisted replication covers everything.
• Plan Key Vault DR explicitly — replicate certificates/secrets/keys to the DR region, or the failover site can’t decrypt anything.
• Primary and DR VNet CIDR ranges must not overlap, or peering/routing between them becomes impossible.
• Residency-constrained workloads that can’t replicate cross-region: lean on Availability Zones + in-region backup/restore, and plan to restore after the primary region recovers rather than failing over cross-region.

3.3 Design Backup Solutions

• Azure Backup supports: VMs, SQL Server in VMs, Azure Files, SAP HANA, Azure Blobs
• Recovery Services Vault vs. Backup Vault (newer — for Blobs, Disks, PostgreSQL)
• Immutable vaults — prevent backup deletion (compliance)
• Long-term retention policies (years/decades for compliance)

Unstructured Data Protection:

• Blob soft delete and versioning protect against accidental deletion/overwrite.
• GRS/GZRS replication protects against regional/zone loss.
• Immutable storage (time-based retention or legal hold) at the container level — required for compliance and ransomware protection, distinct from immutable vaults above.

Domain 4 – Design Infrastructure Solutions (30–35% — Largest Domain)

4.1 Design Compute Solutions

Scenario	Service
Lift-and-shift, full OS control	Azure VMs
Web/API app, no OS management	Azure App Service
Web app + full network isolation or compliance mandate	App Service Environment (ASE / Isolated tier) — only App Service option deployed into your VNet with dedicated hosts
Microservices, event-driven, serverless containers	Azure Container Apps
Full Kubernetes control	AKS
Short-lived event-driven functions	Azure Functions
Functions + VNet integration, no cold starts, or >10 min runtime	Functions Premium plan — Consumption plan can’t do VNet or long executions
Single container, quick burst, no orchestration	Container Instances (ACI) — simplest/cheapest container option; also used for AKS virtual-node burst
Batch processing jobs	Azure Batch
Migrate VMware workloads without re-platforming	Azure VMware Solution — runs vSphere natively in Azure
ML training, GPU workloads	Azure ML + N-series / Spot VMs

• Spot VMs: Fault-tolerant, interruptible workloads (ML training, batch, rendering)
• Azure Dedicated Hosts: Compliance/licensing requirements
• Proximity Placement Groups: Ultra-low latency between VMs

Decision Ladder

VM (IaaS, full control/legacy) → AKS (orchestration/microservices at scale) → App Service / Container Apps (PaaS, less ops overhead) → Functions (serverless, event-driven, pay-per-execution). Start from the right and only move left when the scenario demands more control.

SLA Quick Rules

Single premium-SSD VM = 99.9% · Availability Set = 99.95% · Availability Zones = 99.99%. Need 99.99% → zones (or zone-redundant PaaS).

Functions Consumption plan hard limit

Default timeout is 5 minutes, extendable to a 10-minute max. Any process exceeding that ceiling — even in a supported language — cannot run on Consumption; it needs Premium/Dedicated or a different compute service entirely. Don’t assume a process qualifies just because the language is supported.

Rollback speed

Deployment slots (App Service) swap back near-instantly after a bad release — faster than Front Door/Traffic Manager/DNS-based rollback, which depends on TTL/cache propagation.

4.2 Design Network Solutions

• Hub-spoke vs. Virtual WAN (vWAN) — vWAN is a managed hub, auto-connects spokes
• Azure Firewall: stateful L3-L7, FQDN filtering, threat intelligence
• Private Link Service — expose your service to others via private endpoint
• DNS architecture: Azure DNS zones, Private DNS zones, DNS forwarding

Private Link vs. VNet peering

Private Link is the answer when your own service must be reachable privately by other tenants/customers at scale, isolated from the public internet — VNet peering requires per-VNet/tenant configuration and doesn’t scale to arbitrary external consumers.

Network Security — Defense in Depth (outer to inner):

1. DDoS Protection (edge)
2. Azure Firewall / NVA (hub)
3. NSG (subnet/NIC)
4. Application Gateway + WAF (app layer)
5. Private Endpoints (PaaS access)
6. Encryption in transit (TLS)

	Hub-Spoke (Custom)	Virtual WAN
Hub management	You manage hub VNet, firewall, routing	Microsoft managed
Any-to-any transit	Requires UDRs + NVA/firewall	Built-in
Best for	Custom NVA, complex routing	Large-scale, simplified management
Branch connectivity	Manual VPN/ExpressRoute setup	Automated

4.3 Design Application Architecture

• API Management (APIM): gateway, rate limiting, transformation, developer portal
• Event-driven: Event Grid + Functions, Event Hubs + Stream Analytics
• Messaging choice mirrors the data-integration decision (see Domain 2.4) — pick by ordering guarantee, throughput, and whether it’s a discrete event, a stream, or a work item
• Azure Cache for Redis: distributed cache, session state, pub/sub, sub-ms reads. Standard+ tier for SLA; Premium for VNet integration, persistence, or clustering.
• Azure App Configuration (feature flags, centralized settings) and Key Vault (secrets) are used together, not interchangeably
• Logic Apps: workflow/integration with connectors, low-code, B2B. Keyword: “integrate SaaS systems,” “no custom code.”
• Functions vs. Logic Apps: code-first (devs writing code) → Functions; connector-driven, designer-first workflow → Logic Apps.
• Automation Runbooks: scheduled ops tasks (start/stop VMs, patching) — ops automation, not application logic.
• Deployment patterns: blue/green, canary, rolling

APIM Tier	VNet Integration	Notes
Consumption	No (serverless)	Pay-per-call, no developer portal
Developer	External/Internal	Full features, not for production
Basic / Standard	External	Production, limited throughput
Premium	External/Internal	Multi-region, high throughput

4.4 Design Migrations

Process: Discover → Assess → Migrate — Azure Migrate is the umbrella hub.

Tool	Use When	Why
Azure Migrate: Discovery & Assessment	Inventory on-prem servers, dependency mapping, right-size + cost estimate	Always the first step; agentless for VMware/Hyper-V
Azure Migrate: Server Migration	Move VMs (VMware, Hyper-V, physical) to Azure	Replication-based lift-and-shift with test migration
Data Migration Assistant (DMA)	Assess SQL Server for compatibility/blockers	Assessment tool — finds issues before migrating
Database Migration Service (DMS)	Execute SQL/DB migration, esp. online/minimal downtime	The mover. Keyword: “minimal downtime migration.”
SQL Server Migration Assistant (SSMA)	Migrate Oracle/DB2/MySQL/Sybase → SQL	Heterogeneous (cross-engine) migrations
App Service Migration Assistant	Web apps (IIS) → App Service	Purpose-built web-app migration tool
Storage Migration Service	File servers → Azure Files	Managed migration for Windows file servers

Exam Rule

SQL target selection (Azure SQL Database vs. Managed Instance vs. SQL on VM) is covered in Domain 2.2 — the same decision logic applies whether you’re designing new or migrating existing.

Data transfer methods:

Method	Use When	Why
Azure Data Box	TBs–PBs with limited/slow bandwidth, offline transfer	Physical appliance shipped to you. Keywords: “40+ TB,” “limited bandwidth,” “one-time bulk.”
AzCopy	Scriptable online copy of blobs/files	CLI, good for GBs–low TBs over decent bandwidth
Storage Mover	Migrate on-prem file shares (SMB/NFS) → Azure Files/Blob at scale	Managed, minimizes admin vs. scripting AzCopy
Azure Data Factory	Ongoing/scheduled data pipelines with transformation	ETL, not one-time lift. Keyword: “recurring,” “transform.”
Import/Export service	Ship your own drives (smaller than Data Box scenarios)	Legacy option; Data Box usually wins now

CAF methodologies (7, in order): four foundational/sequential — Strategy → Plan → Ready → Adopt (Migrate/Innovate) — plus three operational/continuous — Govern, Secure, Manage — running in parallel once workloads are live. Adopt is the phase containing both migration and innovation (cloud-native build) work. Expect questions asking which phase a described activity belongs to.

The 8 Rs: Rehost (lift-and-shift, fast/low-risk, no code changes) → Replatform (lift-tinker-shift — minor changes to use platform services, e.g. SQL Server → SQL Managed Instance) → Refactor (restructure code for performance/maintainability without changing external behavior) → Rearchitect (redesign to use cloud-native services fully) → Rebuild (legacy app, limited functionality, near-end-of-support, codebase too complex/costly to refactor — start over) → Replace (adopt ready-made SaaS instead) → Retire (decommission — obsolete/redundant/superseded) → Retain (leave on-premises — compliance/latency/technical blockers make migration impractical now). Map scenario constraints — time, budget, app dependencies — to the right R.

Exam pattern: “business-critical, limited functionality, tech nearing end-of-support, new features slow/error-prone, codebase complex and hard to support” → Rebuild (not Refactor — codebase is described as too complex to safely refactor; not Rehost — the tech’s short remaining viable lifespan doesn’t justify lift-and-shift).

Verify before the exam

This reflects an April 2026-era count (7 methodologies, 8 Rs) — Microsoft has restructured CAF and the migration-strategy list more than once. Re-verify the current phase/strategy list against Microsoft Learn close to your exam date rather than treating these numbers as fixed.