AZ-305: Designing Azure Infrastructure Solutions

Cloud architecture is a series of connected decisions under constraints. A solution might offer excellent regional resilience yet have an identity model that permits excessive administrative access; it might meet a latency objective but store regulated data in the wrong location; or it might recover quickly while costing far more than the business can sustain. Exam AZ-305, Designing Microsoft Azure Infrastructure Solutions, evaluates how an architect balances such requirements across identity, governance, storage, business continuity and infrastructure.

Microsoft's April 17, 2026 blueprint defines four skill groups: design identity/governance/monitoring, design data storage, design business continuity, and design infrastructure. It is an active exam associated with the Azure Solutions Architect Expert credential. Passing AZ-305 alone is not sufficient to earn that expert certification: Microsoft also requires the Azure Administrator Associate certification. This relationship matters when evaluating study pathways and should not be flattened into a claim that one exam independently grants the entire expert credential.

Translate stakeholder requirements into testable designs

A strong architecture begins with explicit requirements rather than with a product list. Separate business outcomes from design assumptions: acceptable downtime, recovery-point objectives, data residency, user populations, growth, latency, budget and the security consequences of failure. Some needs conflict. Keeping every dataset replicated globally may reduce certain recovery risks while violating residence restrictions or creating unnecessary expense. The architect must explain the trade-off and document the chosen exception-handling process.

The Azure Well-Architected Framework helps evaluate reliability, security, operational excellence, performance efficiency and cost optimization. The Cloud Adoption Framework addresses wider organizational adoption and governance concerns. These frameworks guide questions; they do not mechanically select one Azure service for every workload. For a public transaction API, an architect should compare availability targets, expected throughput, dependency failure modes and monitoring before recommending a region, compute design or load-balancing service.

A decision record should preserve why a solution was selected and what evidence would cause reconsideration. If an application must serve customers from multiple regions, specify how users reach the appropriate instance, where data is authoritative and how failover affects consistency. If compliance requires approval before new resource deployment, decide how Azure Policy, management scopes and release processes enforce it. Azure landing zones at scale are relevant because subscription organization and shared guardrails determine whether individual workload teams can deliver consistent outcomes.

Design identity, authorization and governance

Architecture must distinguish human identities, workloads, administrators and partners. Microsoft Entra provides identity capabilities, while Azure RBAC governs resource-management access and individual services may require their own data-plane authorization. A business user who may view an application should not gain infrastructure deployment rights, and a workload that reads one secret should not receive broad subscription administration. Plan privileged access, emergency recovery and periodic access review alongside ordinary sign-in flows.

The design of multi-tenant identity in Azure becomes important when an application serves users or organizations beyond its home directory. Identity architecture affects consent, administration, token audience and separation of tenant data. A successful external login does not answer whether that identity should read a particular customer's records. Authorize the resource itself, record trust boundaries and test failures when the caller has legitimate authentication but insufficient business permission.

Governance encompasses policy, subscription hierarchy, resource organization, encryption and secret management. Azure Policy and RBAC at governance scope illustrates how architecture establishes enforceable constraints instead of relying solely on procedural instructions. Tags can improve cost allocation and ownership reporting, but they are not protection controls. Architect for visibility: specify which logs and metrics are needed to prove that administrative changes, risky access and service failures are being detected in the intended control plane.

Choose storage to match consistency and access patterns

Data architecture starts with shape, query behavior and correctness requirements. A relational transactional system needs different guarantees from an image repository or an event stream. Azure SQL Database, Azure Database for PostgreSQL, Cosmos DB, Blob Storage, Azure Files and analytic platforms solve overlapping but distinct problems. Consider transaction boundaries, indexing, scale, network security, geography, durability, backup and the skills of the operating team. A familiar product can be appropriate when it fits requirements; novelty alone is not a justification.

Azure storage for high-scale applications requires examining access frequency, throughput, lifecycle and application data contracts. A globally distributed database can improve geographic responsiveness but may complicate consistency and conflict resolution. An object store is excellent for immutable documents but should not automatically become a substitute for transactional relationships. An architecture may combine data services, yet each additional service introduces synchronization and operational boundaries that need owners.

Security and recoverability must apply to every dataset, not just the primary database. Storage encryption is a baseline but does not resolve authorization, credential handling or audit requirements. Retention rules can conflict with deletion requests; replication may copy corrupt data as efficiently as good data; backup restore tests may expose schema compatibility problems. Specify which controls protect against accidental change, service outage, ransomware and regional events. Understand where managed service responsibility ends and customer responsibility begins.

A retailer illustrates why recovery must be measured end-to-end. The web interface may fail over to another region in minutes while its payment provider, inventory feed or identity dependency remains inaccessible. Declaring success when the login page responds would hide the inability to place an order. Define a business transaction that must complete during failover, measure its actual recovery time and check which orders or messages are delayed or missing. If active-active writes can conflict, specify which component resolves them and how staff will reconcile inconsistent records after the event.

Architecture records should also address disaster recovery exercises that intentionally avoid a full production outage. A staged regional test can validate DNS, routing, application secrets, replicated data and emergency roles. Document both the tested limits and what remains an assumption. That evidence gives stakeholders a more trustworthy reliability statement than a diagram showing two regions connected by a line.

Engineer business continuity as a system property

Recovery design needs explicit recovery-time and recovery-point objectives. Active-active services, warm standby and backup-and-restore patterns offer different cost and complexity. A globally available front end cannot hide the fact that a single-region identity or database dependency still causes a prolonged outage. Trace the complete path from the client through routing, application, queues, data, secrets and observability. Identify the components whose failure causes business impact even if their individual uptime looks excellent.

Azure disaster recovery across regions is relevant to choosing replication and failover patterns. Do not assume the mere existence of a paired region provides automated restoration of every service. For some workloads, a failover may require traffic-routing changes or an application consistency plan. Disaster recovery also requires people: authority to declare an incident, a runbook that matches actual permissions and practice in restoring service under degraded conditions.

Define tests against the business outcome, not only against a successful infrastructure API call. Restore a representative database copy into an isolated environment, verify application behavior and confirm what data is missing relative to the permitted recovery point. Test how monitoring reports a failed dependency and how customers receive an accurate status. Highly available Azure application design helps connect component redundancy to tested end-to-end service continuity.

Design compute, networking and observability together

Compute choice must account for packaging, scaling, runtime control and operational burden. Virtual machines offer control but increase patching and configuration responsibilities; App Service and container platforms manage more of the hosting substrate while imposing their own service constraints. An architect should compare resource fit, statefulness, startup behavior, deployment complexity and cost. The choice of Azure compute for enterprise workloads is meaningful when the paragraph explains these actual differences rather than offering a generic link list.

Network architecture covers address planning, peering, hybrid links, private access, routing, firewalls and load balancing. A private endpoint changes how a client reaches a particular service but must work with DNS and authentication. A hub-and-spoke network provides organizational advantages while creating shared connectivity dependencies. Latency-sensitive applications should be assessed across a realistic path that includes data-store location and identity. Design also for future change: overlapping address spaces and hard-coded endpoint addresses can make migrations unnecessarily costly.

Observability needs to be designed before incidents occur. Plan meaningful application, network, platform and security signals; document log destinations and retention, define alert ownership and set actionable thresholds. Monitoring a VM host alone may miss an application dependency failure, while unrestricted collection of sensitive request data can create a privacy problem. Cost-aware Azure architecture treats telemetry costs, capacity commitments and service choices as part of the solution rather than a report generated after implementation.

Prepare for the architect's reasoning task

A useful AZ-305 exercise begins with a case study: a regulated commerce application with regional customers, seasonal peaks, strict user isolation and a recovery objective. Create two alternative architectures and compare their identity boundaries, data locations, monitoring, resilience, operations and expected expense. List the assumptions that could invalidate each choice. An architecture is stronger when it makes failure scenarios and trade-offs explicit rather than drawing many service icons connected by arrows.

The related Azure Administrator AZ-104 role is especially important because Microsoft requires Azure Administrator Associate for the expert certification. Administrators implement and troubleshoot many of the resources an architect selects. An AZ-305 candidate should therefore understand operational feasibility and coordinate with those teams rather than design an idealized system that cannot be maintained with the organization's available tools and permissions.

Microsoft's April 2026 skills guide should be the benchmark for current domain coverage at this checkpoint. Certification details and Azure service capabilities can change, so check the applicable language and provider status again before publication or booking. Preparation succeeds when the candidate can justify why a solution uses a certain identity model, storage tier, failure domain or monitoring approach and explain which requirement or risk would cause that choice to change.