Last reviewed: May 2026
A scannable reference of architectural patterns the AZ-305 exam tests. Read top-to-bottom, or jump to a section.
Hybrid identity auth where password hashes must stay on-prem, with failover.
Azure AD Connect with Pass-through Authentication (PTA) and Password Hash Sync (PHS) enabled as a backup.
Why: PTA keeps hashes on-prem by validating against local AD. PHS provides authentication failover if the on-prem AD or Connect agent is unavailable.
Implement Zero Trust by enforcing granular access control based on user, location, device health, and risk.
Microsoft Entra Conditional Access policies combining Named Locations, device compliance (Intune), and sign-in risk (Identity Protection) with grant controls like MFA.
Why: Conditional Access is the enforcement engine for Zero Trust, evaluating multiple signals per request before granting access. A single policy cannot apply different controls to different conditions.
Enforce consistent policies (e.g., tagging, allowed regions) across dozens or hundreds of subscriptions.
A management group hierarchy with Azure Policy initiatives assigned at the root or parent management group level.
Why: Management Groups provide a governance scope above subscriptions, allowing policies to be inherited. Initiatives bundle multiple policies for simplified assignment.
Provide administrators with just-in-time (JIT) privileged access with approval workflows and auditing.
Microsoft Entra Privileged Identity Management (PIM) to make users eligible for roles instead of permanently active.
Why: PIM enforces least privilege by requiring users to activate roles for a time-limited period, with optional MFA, justification, and approval, creating a full audit trail.
Collect logs from all Azure resources across multiple subscriptions for centralized analysis and querying.
A single, centralized Log Analytics workspace with resource-context RBAC for access control.
Why: A centralized workspace enables cross-subscription queries, simplifies management, and avoids data duplication. Resource-context RBAC ensures users only query logs from resources they can access.
Azure resource (e.g., App Service, Function, VM) needs to securely access other Azure resources (Key Vault, SQL, Storage) without stored credentials.
Assign a managed identity (system- or user-assigned) to the compute resource and grant it RBAC roles on the target resources.
Why: Managed identities eliminate credential management (secrets, certificates), automatically handling token acquisition and rotation. Use user-assigned for sharing an identity across multiple resources.
Automatically remediate existing, non-compliant Azure resources identified by an Azure Policy.
Use a "DeployIfNotExists" or "Modify" policy effect. For existing resources, a remediation task must be created for the policy assignment, which requires a managed identity with sufficient permissions.
Why: Policies with these effects only apply to new/updated resources by default. A remediation task is required to scan and fix existing non-compliant resources.
Enforce required tags on all resources and automatically inherit tags (e.g., CostCenter) from the parent resource group.
Use an Azure Policy with a "Deny" effect for required tags and a separate policy with a "Modify" effect to inherit tags from the resource group if missing.
Why: Deny enforces compliance at creation. The Modify effect automates tag propagation, reducing manual effort and ensuring consistency.
Monitor a multi-tier or microservices application to trace transactions end-to-end and identify performance bottlenecks.
Instrument all services with Application Insights. Use the Application Map for visualizing dependencies and distributed tracing for end-to-end request analysis.
Why: Application Insights is the native APM solution that automatically correlates telemetry across components to provide a unified view of a transaction, pinpointing latency issues.
Govern access for external partners, including requests, approvals, time-limited access, and periodic reviews.
Microsoft Entra ID Governance entitlement management. Create access packages that bundle resources, define approval workflows, set expiration policies, and schedule access reviews.
Why: Provides a complete, automated lifecycle for external access, reducing administrative overhead and security risk compared to manual guest account management.
A managed service provider or central IT team needs to manage resources across multiple customer/departmental Azure AD tenants.
Azure Lighthouse. Onboard customer subscriptions to grant the managing tenant delegated access with specific RBAC roles.
Why: Lighthouse provides a single control plane for cross-tenant management without switching directories or managing guest accounts, while the customer retains full control and ownership.
Provide secure remote access to an on-premises web application for external users without a VPN or exposing the app to the internet.
Microsoft Entra Application Proxy.
Why: Application Proxy uses a lightweight on-premises connector that makes an outbound connection to Azure. It acts as a reverse proxy, allowing Entra ID pre-authentication and secure access without inbound firewall rules or a public IP on the application.
A globally distributed application requires a database with sub-10ms read/write latency, flexible schema, and 99.999% availability.
Azure Cosmos DB with multi-region writes enabled. Partition key should be chosen to distribute workload evenly.
Why: Cosmos DB is purpose-built for global distribution with turnkey multi-region writes, providing guaranteed low latency and the highest availability SLA. Other databases require manual replication and cannot match the write latency.
Ingest high-volume IoT telemetry into Cosmos DB, enabling efficient queries by device and automatic archival of old data.
Use `/deviceId` as the partition key. Configure TTL on the container to auto-delete old documents. Use Change Feed to capture data before deletion for archival to cold storage (e.g., Blob Storage).
Why: Partitioning by `deviceId` co-locates data for a single device, making queries efficient. TTL provides free, automatic deletion. Change Feed enables a reactive archival pipeline.
Select a cost-effective Azure SQL DB pricing model for a workload with unpredictable, bursty traffic and significant idle periods.
Use the vCore-based model with the Serverless compute tier.
Why: Serverless automatically scales compute based on demand and auto-pauses during idle periods, charging only for compute used per second. This is far more cost-effective for intermittent workloads than provisioned tiers.
A storage solution for a large-scale data analytics platform requiring a hierarchical namespace and directory-level ACLs.
Azure Data Lake Storage Gen2 (an account with hierarchical namespace enabled).
Why: ADLS Gen2 is optimized for big data analytics, combining object storage scalability with a true hierarchical file system and POSIX-compliant ACLs for granular security.
Choose storage redundancy based on tiered requirements: max durability with read access, DR-only, and in-region datacenter failure protection.
1. Max durability/read: RA-GZRS. 2. DR-only: GRS. 3. In-region: ZRS.
Why: Match the redundancy option to the specific RPO/RTO and access needs. RA-GZRS is the highest tier. GRS is for failover only. ZRS protects against datacenter failure within a region.
Query large structured data in a data warehouse and semi-structured data in a data lake using a unified analytics platform.
Azure Synapse Analytics. Use a dedicated SQL pool for the structured data and a serverless SQL pool for ad-hoc queries on the data lake.
Why: This hybrid approach optimizes both performance and cost. The dedicated pool provides high performance for the managed data warehouse, while the serverless pool provides pay-per-query access to raw data in the lake.
A caching solution for session state and product data requiring >100 GB of memory and high availability.
Azure Cache for Redis Enterprise or Premium tier with clustering enabled.
Why: Clustering in the Premium/Enterprise tiers allows the cache to scale beyond the memory limits of a single node by sharding data across multiple nodes, also improving throughput.
A database architecture for a SaaS application that isolates tenants while optimizing costs for many small, spiky workloads.
Azure SQL Elastic Pools. Group tenants into pools to share resources, with dedicated databases for large, "noisy neighbor" tenants.
Why: Elastic pools provide the cost benefits of resource sharing while enforcing per-database performance limits, offering a balance between the noisy-neighbor problem and the high cost of one-database-per-tenant.
Migrate a complex on-premises SQL Server database that uses features like SQL Agent, cross-database queries, and CLR to a PaaS service.
Azure SQL Managed Instance.
Why: SQL Managed Instance offers near-100% compatibility with the on-premises SQL Server engine, supporting instance-level features that Azure SQL Database does not. This is ideal for lift-and-shift with minimal code changes.
Ensure all data and customer-managed encryption keys remain within a specific geographic boundary (e.g., the EU).
Deploy all resources to regions within the boundary. Use an Azure Policy with the "Allowed locations" effect to enforce this. Store customer-managed keys (CMK) in an Azure Key Vault also located within the boundary.
Why: A combination of physical deployment location, policy-based enforcement, and key residency is required to meet strict data sovereignty regulations.
Discover, classify, and track lineage for data across a hybrid data estate (Azure, on-prem, other clouds).
Microsoft Purview.
Why: Purview provides a unified data governance solution with automated scanning, a business glossary, classification, and lineage tracking across a wide range of data sources.
Store data (e.g., financial records) in a non-erasable, non-modifiable (WORM) state for a defined retention period.
Azure Blob Storage with a time-based immutable policy on the container, which is then locked.
Why: Locked immutable policies prevent deletion or modification of blobs by any user, including administrators, until the retention period expires, meeting strict regulatory compliance requirements.
Design a DR solution for a web app (App Service + SQL DB) with an RPO of minutes and an RTO under an hour.
Azure SQL Database auto-failover group, a secondary App Service deployment, and Azure Front Door or Traffic Manager for routing.
Why: This pattern addresses DR for each tier. The SQL failover group handles data replication and failover. The pre-deployed App Service avoids deployment delays. A global router (Front Door/Traffic Manager) directs traffic to the active region.
The composite SLA of a serial application (A -> B -> C) is too low. How do you improve it?
Identify the component with the lowest individual SLA (the "weakest link") and make it redundant by deploying parallel instances (e.g., across regions or zones with a load balancer).
Why: Composite SLA for a serial chain is calculated by multiplying SLAs (SLA_A * SLA_B * SLA_C). Adding parallel instances to a component improves its effective SLA, which has the greatest positive impact on the composite.
Achieve the highest possible availability for VMs within a single Azure region.
Deploy multiple VMs across all available Availability Zones in the region.
Why: Availability Zones are physically separate datacenters with independent power, cooling, and networking. This protects against datacenter-level failures and provides the highest in-region SLA of 99.99%.
Provide a disaster recovery solution for on-premises VMware or Hyper-V virtual machines to Azure.
Azure Site Recovery (ASR). Configure replication to Azure, create recovery plans for orchestrated failover, and use test failovers for non-disruptive DR drills.
Why: ASR is the purpose-built Azure service for DR replication of on-prem (and Azure) VMs, providing continuous replication, orchestrated recovery, and isolated testing capabilities.
Achieve the highest in-region availability for Azure SQL Database with zero data loss (RPO=0) and read-scaling capability.
Use the Business Critical service tier with zone redundancy enabled.
Why: The Business Critical tier uses an Always On Availability Group with synchronous replication across multiple replicas, providing an RPO of 0. Zone redundancy places replicas in different AZs for a 99.995% SLA. It includes a readable secondary replica.
A global application must serve users from the nearest region and failover automatically and instantly.
Use an active-active deployment pattern across multiple regions with Azure Front Door for latency-based routing and health probe-based failover.
Why: Azure Front Door provides global anycast routing to the lowest-latency backend. Its health probes detect regional failures and automatically reroute traffic to healthy regions within seconds, enabling a seamless active-active architecture.
Back up stateful applications on AKS, including both Kubernetes object definitions and the persistent volume data.
Use Azure Backup for AKS.
Why: Azure Backup for AKS is the native solution that provides integrated, policy-based backup for both cluster state (etcd) and persistent volume data (via CSI snapshots) into a secure, centralized Backup Vault.
Protect backups from accidental or malicious deletion, including by administrators, for regulatory compliance.
Enable immutable vaults on the Azure Backup or Recovery Services vault.
Why: Immutability is a vault-level setting that ensures backup recovery points, once created, cannot be deleted by anyone before their expiration date, providing the highest level of backup protection.
An App Service Environment v3 (ASEv3) hosts a critical application in one region and requires a DR solution in another region.
Deploy a second ASEv3 in the DR region. Use Azure Front Door for global load balancing and failover. Replicate data using the appropriate technology (e.g., SQL auto-failover groups).
Why: ASEv3s are regional deployments. For DR, you must deploy a second ASE and use a global router like Front Door to manage traffic. ASR is not used for App Service DR.
Design a scalable network for an enterprise with centralized connectivity (ExpressRoute/VPN), shared services, and workload isolation.
A hub-and-spoke topology. The hub VNet contains the gateway, Azure Firewall, and other shared services. Spoke VNets contain application workloads and are peered to the hub.
Why: This is the standard, recommended enterprise pattern. It centralizes security and connectivity, reducing cost and complexity, while spokes provide strong workload isolation.
A global web application needs Layer 7 load balancing, a Web Application Firewall (WAF), SSL offloading, and URL-based routing.
Azure Front Door (Standard or Premium).
Why: Front Door is a modern cloud CDN and global load balancer that integrates these capabilities into a single service, providing better performance and simpler management than combining Traffic Manager with regional Application Gateways.
Design a production-grade AKS cluster for multiple teams with varying workload types (CPU, GPU, memory-intensive).
Use a dedicated system node pool and multiple user node pools with different VM SKUs (e.g., F-series for CPU, E-series for memory, N-series for GPU). Use the cluster autoscaler and enable the Standard/Premium tier for the uptime SLA.
Why: Multiple node pools allow matching the right hardware to the right workload for performance and cost-efficiency. Separating system pods improves stability. The Standard/Premium tier is required for a financially-backed SLA.
An event-driven serverless workflow requires execution times longer than the 10-minute limit of the Functions Consumption plan.
Use Azure Functions on a Premium plan or an App Service plan, or use Azure Durable Functions for orchestration.
Why: The Premium plan supports execution up to 60 minutes (default 30) and avoids cold starts. Durable Functions are ideal for orchestrating long-running, stateful workflows that may involve human interaction or long waits.
Choose a messaging service for a fan-out event notification system versus a reliable, ordered command processing system.
Use Azure Event Grid for fan-out, reactive eventing. Use Azure Service Bus Queues (with sessions for ordering) for reliable, transactional command processing.
Why: Event Grid is a lightweight, push-based event routing service optimized for reactive programming. Service Bus is a robust message broker with features like FIFO (sessions), dead-lettering, and transactions for enterprise messaging.
Expose an API running on a private VNet to external partners securely, with policies for rate limiting and authentication.
Deploy Azure API Management (APIM) in internal VNet mode, fronted by an Azure Application Gateway with WAF for public ingress.
Why: This pattern provides defense-in-depth. APIM in the VNet can access the private backend. The App Gateway terminates SSL, inspects traffic with WAF, and forwards it to the private APIM instance. APIM policies handle auth, rate limits, etc.
Connect hundreds of branch offices and VNets globally with automated, any-to-any connectivity.
Azure Virtual WAN.
Why: Virtual WAN is the managed Microsoft solution for large-scale, global transit networking. It automates complex routing and provides a unified hub for connecting VPN, ExpressRoute, and VNet spokes.
Run a large-scale, parallel batch job (e.g., CFD simulation) that requires thousands of cores and low-latency MPI communication.
Azure Batch with a pool of InfiniBand-enabled VMs (e.g., HB-series) using low-priority (Spot) pricing.
Why: Azure Batch is a job scheduler designed for HPC. InfiniBand-enabled VMs provide the high-throughput, low-latency RDMA networking required for MPI. Low-priority VMs drastically reduce cost for fault-tolerant workloads.
An application in a VNet needs to access PaaS services (SQL, Storage) without traffic traversing the public internet.
Create private endpoints for the PaaS services. This gives the service a private IP address within your VNet.
Why: Private Endpoints are the most secure method for private PaaS connectivity. They ensure traffic stays on the Microsoft backbone and allows you to disable the public endpoint of the PaaS service entirely.
Host a modern single-page application (SPA) with a serverless API backend, CI/CD integration, and a custom domain.
Azure Static Web Apps.
Why: This is a purpose-built, streamlined service for this exact pattern. It combines static content hosting, integrated Azure Functions for the API, GitHub/Azure DevOps integration, and managed custom domains with free SSL certificates.
Manage and apply governance (Azure Policy) to servers running on-premises and in other clouds (e.g., AWS) from Azure.
Install the Azure Arc agent on the non-Azure servers to project them as Azure Arc-enabled servers.
Why: Azure Arc extends the Azure control plane to any infrastructure. Once a server is Arc-enabled, it can be managed with Azure Policy, Monitor, Defender for Cloud, etc., just like a native Azure VM.
Incrementally migrate functionality from a legacy monolithic application to new microservices without a "big bang" cutover.
Apply the Strangler Fig pattern using a reverse proxy like Azure API Management or Application Gateway.
Why: The reverse proxy intercepts calls to the monolith and selectively routes traffic for specific features to the new microservices. Over time, the proxy "strangles" the monolith by redirecting more and more traffic until the old system can be retired.
VMs are in a VNet with forced tunneling (all internet traffic routed on-prem), but they cannot access Azure PaaS services.
Forced tunneling breaks direct access to Azure public endpoints. Use service endpoints or private endpoints for PaaS access. Alternatively, add UDRs for specific Azure service tags with a next hop of "Internet" to bypass the tunnel.
Why: PaaS services have public endpoints. Forced tunneling sends that traffic on-prem. You must create an exception path, either by making the PaaS service private (endpoints) or by creating specific route exceptions (UDRs with service tags).
A hub-spoke network needs to resolve on-premises DNS names from Azure, and Azure private DNS zones from on-premises.
Deploy Azure DNS Private Resolver in the hub VNet. Configure an inbound endpoint for on-prem to resolve Azure DNS, and an outbound endpoint with forwarding rulesets to resolve on-prem DNS from Azure.
Why: This is the modern, PaaS solution for hybrid DNS resolution, replacing the need to manage custom DNS server VMs. It integrates natively with private DNS zones and on-premises DNS forwarders.
Multiple VNets need a predictable, static public IP for all outbound traffic for whitelisting by external services.
In a hub-spoke topology, route all outbound traffic (0.0.0.0/0) from spokes through an Azure Firewall or NAT Gateway in the hub VNet.
Why: Centralizing egress in the hub ensures all outbound traffic uses the hub firewall/NAT Gateway's public IPs, simplifying management and external whitelisting. NAT Gateway is simpler for pure SNAT, while Firewall adds security inspection.
Process highly sensitive data in a way that it is encrypted even while in use in memory, protecting it from the cloud operator.
Use Azure Confidential Computing VMs (DCsv3/ECsv3-series) with Intel SGX or AMD SEV-SNP to run code in a hardware-based Trusted Execution Environment (TEE) or encrypted memory.
Why: Confidential Computing addresses the "data-in-use" pillar of security, which traditional encryption-at-rest and in-transit do not. It provides verifiable, hardware-level isolation.
A SaaS provider needs to expose their service, running in their VNet, to a customer in the customer's VNet, entirely over the Azure private network.
The provider creates an Azure Private Link Service on their Standard Load Balancer. The customer creates a Private Endpoint in their VNet that connects to the service.
Why: Private Link is the definitive pattern for secure, private, cross-tenant service exposure. It avoids public internet exposure, IP overlap issues, and complex VNet peering configurations.