ExpertCheat Sheet
AZ-305
AZ-305AZ-305 Cheat Sheet 2026: Azure Solutions Architect Expert Reference
A structured design reference for AZ-305 candidates — identity, governance, compute, storage, networking, and business continuity patterns with exam trigger phrases.
ExpertMinds Editorial·14 January 2026·9 min read
The AZ-305 tests architectural judgment, not service knowledge. Every question describes a requirement — cost, compliance, availability, scalability, operational overhead — and asks which design best satisfies it. The wrong answers are usually architecturally valid but don't satisfy all the stated constraints. Read every requirement before evaluating answers.
Key fact:40–60 questions · 120 minutes · Pass score 700/1000. Case study questions appear — read the entire case before answering any question in that set.
Identity & Access Design
| Pattern | Use when | Key service |
|---|---|---|
| B2B collaboration | Partner organisations need access to your apps | Entra ID External Identities (guest users) |
| B2C identity | Customers sign in with social or local accounts | Azure AD B2C — separate tenant |
| Managed Identity | Azure service needs to access other Azure services without credentials | System-assigned or user-assigned Managed Identity |
| Service Principal | Application or script needs Azure resource access | App registration + client secret or certificate |
| Privileged Identity Management | Just-in-time admin access with approval workflow | Azure PIM — reduces standing access |
| Conditional Access | Grant/block access based on conditions (location, device, risk) | Entra ID Conditional Access policies |
Governance & Compliance Design
| Requirement | Design choice | Reason |
|---|---|---|
| Enforce allowed VM sizes across subscriptions | Azure Policy with Deny effect | Policy applies at scope; prevents non-compliant deployments |
| Standardise new environment setup | Azure Blueprints (or Bicep/Terraform templates) | Repeatable, auditable environment scaffolding |
| Manage 50+ subscriptions centrally | Management Groups + Azure Policy at MG level | Policies and RBAC inherited by child subscriptions |
| Audit resource changes over time | Azure Resource Graph + Activity Log + Azure Monitor | Queryable change history |
| Cost allocation across departments | Resource tags + Azure Cost Management | Tags enable per-department reporting |
Compute Design Decisions
| Scenario | Best compute choice | Key reason |
|---|---|---|
| Migrate existing app with no code changes | Azure VMs (IaaS) | Lift-and-shift; full OS control |
| Web app — no infrastructure management | Azure App Service | PaaS; auto-scale; deployment slots |
| Containerised microservices at scale | AKS | Kubernetes orchestration; complex networking |
| Simple container, quick startup, no cluster | Azure Container Instances | Serverless containers; no cluster management |
| Event-driven short tasks | Azure Functions (Consumption plan) | Pay per execution; auto-scale to zero |
| Functions needing VNet integration or premium compute | Azure Functions (Premium plan) | VNet integration; no cold starts |
| High performance computing / GPU workloads | Azure VMs — H-series or N-series | Specialised hardware |
Tip:App Service vs Azure Functions: App Service is for continuously running web apps. Functions are for event-triggered, short-lived code. If a question says "runs 24/7" — App Service. If it says "triggered by event, runs briefly" — Functions.
Storage Design Decisions
| Requirement | Design | Key detail |
|---|---|---|
| Highest durability for critical data | GRS or GZRS | 6 copies across 2 regions; 99.99999999999999% durability |
| Archive data accessed once a year | Blob Archive tier | Lowest cost; retrieval takes hours; min 180-day retention |
| Shared file access from multiple VMs | Azure Files (SMB) | Managed file share; supports AD auth |
| High-throughput analytics on structured data | Azure Data Lake Storage Gen2 | Hierarchical namespace; Parquet/CSV; integrates with Synapse |
| Immutable storage for compliance | Blob Storage with Immutability Policy (WORM) | Write once, read many; cannot be deleted or modified |
Database Design Decisions
| Requirement | Best choice | Key differentiator |
|---|---|---|
| Relational workload, minimal management | Azure SQL Database | Fully managed; vCore or DTU pricing |
| SQL with instance-level features (CLR, linked servers) | Azure SQL Managed Instance | Near 100% SQL Server compatibility |
| Relational + global distribution + horizontal scale | Azure Cosmos DB (API for PostgreSQL / Citus) | Distributed Postgres — not single-node Cosmos DB |
| Multi-model NoSQL — global, low latency, any scale | Azure Cosmos DB | Choose API: SQL, Mongo, Cassandra, Gremlin, Table |
| Cosmos DB consistency: strong vs eventual | Strong = highest consistency, higher latency/cost; Eventual = lowest latency, may see stale reads | Bounded Staleness and Session are the most commonly used |
| In-memory caching layer | Azure Cache for Redis | "reduce database load", "session cache", "leaderboard" |
Practice AZ-305 architecture scenarios
Design questions have no single right answer until you apply all stated constraints. Practice choosing between architecturally valid options.
Networking Design Patterns
| Pattern | Design | Use case |
|---|---|---|
| Hub-and-spoke topology | Central hub VNet (shared services) + spoke VNets (workloads) connected via peering | Enterprise network with centralised security and routing |
| Private connectivity to PaaS | Private Endpoint + Private DNS Zone | Access Storage, SQL, Key Vault over VNet; no public internet |
| Hybrid connectivity — internet | Azure VPN Gateway (site-to-site or point-to-site) | On-premises to Azure over encrypted tunnel |
| Hybrid connectivity — dedicated | ExpressRoute | Private circuit; consistent bandwidth; compliance-driven |
| Centralised firewall inspection | Azure Firewall in hub VNet + UDR to force traffic through it | All east-west and internet-bound traffic inspected |
| Global HTTP load balancing with WAF | Azure Front Door | Global anycast; SSL offload; WAF; caching |
Business Continuity & Disaster Recovery
| Requirement | Design | Key metric |
|---|---|---|
| RTO minutes, RPO near-zero | Availability Zones — active-active in same region | Azure SLA 99.99%; synchronous replication |
| RTO hours, cross-region failover | Azure Site Recovery | Replication to secondary region; orchestrated failover |
| VM backup with retention | Azure Backup (Recovery Services Vault) | Daily/weekly/monthly/yearly retention; soft delete |
| SQL DB point-in-time restore | Azure SQL built-in backup — 1–35 days PITR | No separate Backup service needed for SQL |
| Zero-downtime deployments | App Service Deployment Slots + swap | Blue-green deployment; instant rollback |
Key fact:RTO = Recovery Time Objective (how long to restore service). RPO = Recovery Point Objective (how much data loss is acceptable). Lower both = higher cost. The exam will give you RTO/RPO targets — design to meet them exactly, not to over-engineer.
Ready to Practice the full AZ-305?
Graded results, exam simulation, and detailed guidance on every question.