AZ-305: Designing Resilient, Governed Azure Architectures

Microsoft AZ-305, Designing Microsoft Azure Infrastructure Solutions, examines the judgment required to translate business requirements into a secure, resilient and supportable cloud architecture. The English-language objectives were updated April 17, 2026. For the associated Microsoft Certified: Azure Solutions Architect Expert credential, Microsoft currently requires both passing AZ-305 and holding the Azure Administrator Associate certification. This is not a substitute for AZ-104 administration knowledge; architecture decisions depend on understanding what operators can actually deploy, monitor and recover.

An architect must balance competing constraints. A business may demand very high availability, strict regional data residence, rapid deployment and low cost. It is rarely possible to maximize every objective without trade-offs. AZ-305 therefore assesses design areas such as identity and governance, monitoring, data storage, business continuity and infrastructure. The key skill is explaining why a combination of Azure capabilities meets a defined requirement, where it will fail and how the organization will maintain it over time.

Translate governance requirements into the resource hierarchy

The tenant, management group, subscription and resource group hierarchy shapes policy and ownership. A central platform team may establish mandatory controls at a broad scope while application teams deploy within more limited boundaries. Azure Policy evaluates defined configuration requirements, while RBAC determines which identities can perform resource operations. These mechanisms answer different questions. An RBAC role that permits creating storage does not guarantee the storage uses approved encryption or networking settings; policy may enforce selected configuration constraints separately.

Design access for people, automation and workloads with different needs. Human administrators may require time-bound elevated privileges; deployment pipelines need tightly scoped service identities; applications need runtime permissions to specific data. A broad subscription-level role is convenient but enlarges the consequence of compromise. Azure governance with Policy, RBAC and groups is meaningful when the architecture spells out who grants access, who approves exceptions and how inherited controls are tested.

Landing zones provide consistent subscriptions, networking, identities, security baselines and operational interfaces for teams adopting Azure. Azure landing zones at scale are not one fixed template that suits every organization. A multinational company with regulated subsidiaries may require distinct management boundaries, while a smaller enterprise may need a simpler set of subscriptions with centralized security. Design for eventual growth without making the first deployment unnecessarily complex.

Select identity patterns that preserve clear trust boundaries

Business applications may serve employees, external partners or customers. Their identities, lifecycle and access expectations differ. A multi-tenant application needs explicit tenant isolation and authorization checks; authentication through Microsoft Entra does not by itself prevent one customer's data from being accessed by another. Multi-tenant identity design should distinguish directory tenancy, application tenancy and authorization over individual data records.

Use managed identities and approved credential storage to reduce long-lived secrets where possible. However, an identity with excessive permissions is still an access-control failure. Map the exact data and management operations needed by each component, then assign roles accordingly. Review whether network isolation or private connectivity is required, and remember that a private IP address does not replace application authentication. Audit logs should enable investigators to connect consequential operations to traceable identities.

Availability also affects identity. A multi-region application may have redundant compute yet rely on a single external identity service or shared secret that cannot be accessed during a regional incident. Include authentication, token issuance, certificate rotation and recovery access in the business continuity design. Security architecture must remain usable during failures rather than assuming operators can always reach the usual management path.

Design network connectivity from traffic flows

Azure networking decisions begin with where traffic originates, where it must go, what latency is tolerable and which segments must remain separated. Hub-and-spoke topologies can centralize shared connectivity and inspection while allowing workload networks to be organized independently. Hub-and-spoke networking introduces dependencies such as route tables, shared firewall capacity and DNS forwarding. Peering alone does not create automatic transitive routing among all connected networks.

Hybrid connectivity options serve different purposes. A VPN over public networking may be economical for some workloads, while private connectivity services can provide other performance and operational characteristics. Neither removes the need for route planning, identity controls or resilient failover. Hybrid connectivity to Azure should be evaluated with actual traffic paths and dependency requirements, especially when on-premises applications access cloud databases or directory services.

Public application entry points also require design choices. Global routing, application gateways, network load balancers and content delivery services have different behavior and configuration boundaries. One service may support application-layer routing while another distributes transport-layer flows. Avoid assuming a single product meets every availability or security need. Analyze failure domains, health checks, TLS termination, web application filtering and operational ownership as part of the architecture.

Design storage for consistency, access and recovery

Structured databases, object stores and shared file systems meet different data and transaction needs. A high-throughput analytics pipeline may prioritize scalable ingestion, while a customer account database needs transactional consistency and well-understood recovery guarantees. Storage throughput limits, access patterns and regional availability affect the choice. Storage design for high-scale Azure applications connects these requirements to practical performance and cost trade-offs.

Replication should be described precisely. Multiple copies can protect against hardware, zone or region failures depending on the selected configuration, but they may not defend against an application deleting valid data. Backup, point-in-time restoration, retention and immutability may be needed for logical corruption or malicious modification. A regional failover strategy also has consequences for replication lag and application consistency. Set measurable recovery point and time objectives instead of promising "zero downtime" without evidence.

Data governance adds classification, residency and retention requirements. Encrypting storage at rest protects one exposure path but does not make content inaccessible to overprivileged applications. Key management, audit trails and controlled administrator access remain necessary. Assess the lifetime of copies made for development and analytics because a safe production database can still be undermined by a poorly governed export.

Design availability and disaster recovery end to end

Availability zones, regional redundancy, load balancing and application-level retry logic protect against different failure types. A service spread across zones may still depend on a single database or external API. Highly available Azure applications require analyzing the entire request path, including identity, networking, data consistency and client behavior. Adding VM replicas without changing a single-point database dependency rarely delivers the promised reliability.

Disaster recovery considers what happens when a complete region or major dependency is unavailable. Azure disaster recovery with paired regions helps frame region choice, but not every workload or service has identical replication and failover behavior. Some data may be lost within the recovery point objective; some services may require manual activation. Test how clients find the recovered endpoint and how credentials and configuration are restored, not only whether replicas exist.

The Azure Well-Architected Framework encourages evaluating reliability, security, cost, operational excellence and performance together. These dimensions interact. Aggressive multi-region redundancy can improve certain recovery scenarios while increasing deployment cost and operational complexity. A cost-sensitive internal tool may accept longer recovery time than a payment authorization service. Architecture review should document the decision, its rationale and the measurable conditions under which it should be revisited.

An architecture review should distinguish resilience from the mechanics of recovery. Imagine a global application whose customer profiles are stored in one region and whose static content is delivered worldwide. Replicating web front ends may keep pages reachable during a regional failure, but account changes can still fail if the primary database is inaccessible. The design decision is whether to invest in multi-region data architecture, accept a defined period of read-only operation or make the application unavailable until a controlled restore completes. Each option changes write consistency, testing effort, cost and customer expectations. Document what the application does when the primary region fails, and test that behavior under a realistic loss of connectivity rather than merely disabling one healthy instance.

Requirements can also conflict within the same organization. A regulated analytics team might need data stored in an approved geography, while operational dashboards need rapid access by global staff. Choose processing locations and replication boundaries according to actual residency obligations; do not equate a resource's assigned Azure region with the movement of every derived dataset or application log. Architecture decisions must account for backups, telemetry exports and third-party integrations. A useful design record identifies the authoritative data owner, retention requirement, permitted access identities, recovery target and evidence the proposed solution satisfies those conditions. This level of specificity is what separates a defensible AZ-305 recommendation from a generic catalogue of cloud services.

Incorporate operations and economics into architecture

A solution is not complete because a diagram has correct service names. Teams need deployment automation, monitoring, ownership, incident response and maintenance paths. Metrics and logs should be selected according to service-level objectives, not collected only because a platform makes them available. Alerting on every transient event may overwhelm operators; alerting only on infrastructure uptime may miss customer-facing transaction failures. Architecture should establish which signals represent meaningful degradation and who acts on them.

Cost-aware Azure architecture treats financial responsibility as a design constraint. Storage tiers, data-transfer paths, standby capacity and database scaling can dominate expenditure. A seemingly cheap component may impose high egress or management costs. Estimate cost with representative workload assumptions and include changes under failure conditions. Chargeback or tagging can support accountability, but neither substitutes for optimization of an inefficient design.

Use a scenario-based preparation method: describe an organization with multiple offices, a regulated customer database, a public API and a defined recovery target. Propose at least two architectures, comparing identity isolation, network paths, storage consistency, failover, monitoring and price. Identify what evidence would verify the chosen design. AZ-305 candidates should be able to defend a choice under constraints and explain its failure modes, not simply list products that could appear on an architecture diagram.