Microsoft AZ-305: Designing Resilient Azure Infrastructure

AZ-305: Designing Microsoft Azure Infrastructure Solutions assesses architectural judgment across identity, governance, monitoring, data storage, continuity and infrastructure. Microsoft's April 17, 2026 guide targets experienced Azure professionals who translate business and technical constraints into designs aligned with the Azure Well-Architected Framework and Cloud Adoption Framework. The main question is not how to click through a deployment wizard; it is why one combination of services and boundaries fits the workload better than a competing option.

An architect must reason across teams. A database specialist may optimize consistency, a network engineer may prefer simple routing, a security lead may require private access, and finance may demand lower ongoing cost. A design only works when these needs are reconciled. Competence in Azure administration remains useful, but AZ-305 tests the larger decision that defines what the administrators should implement and how its success will be verified.

Convert business requirements into architectural constraints

Start by documenting important transactions, users, data flows, geographical needs, compliance obligations and acceptable failure. A statement such as "the application must be highly available" is incomplete until the team defines which functions must remain accessible, the tolerated interruption and how state should recover. Recovery time objective and recovery point objective answer different questions: one constrains how long a service can be unavailable, and the other how much recent data loss is tolerable. A design that meets one can still fail the other.

For a retailer, online browsing may tolerate short cached data while payment confirmation and inventory adjustment require authoritative transactions. The system should separate services according to those needs, then identify shared dependencies whose failure could affect several critical functions. A database deployed in a second region is not useful if identity, network configuration or a third-party payment provider cannot support failover. Include the end user's actual workflow in availability analysis instead of treating individual resources as the whole service.

Architectural decisions should have acceptance tests and owners. Record the reason for a region choice, which data may cross jurisdictions, why a workload needs private endpoints and what evidence will confirm the design. An approval artifact is not merely a diagram; it should document rejected alternatives, operational trade-offs, risk assumptions and a path to revisit the decision if the business changes. These practices keep complex Azure estates understandable across staff changes and incidents.

Design identity, governance and monitoring together

Microsoft Entra, RBAC, managed identities and privileged-access controls establish who can access or administer resources. Azure Policy can enforce resource constraints, and governance scopes organize accountability across subscriptions and management groups. An architecture that centralizes every system under one broad service identity may look simple initially but creates a powerful point of compromise. Distinguish duties and assign narrowly scoped roles that support actual operations and emergency recovery.

Monitoring architecture should be chosen before implementation. Determine which resources produce logs, where logs travel, how they are protected and which team receives actionable alerts. Operational telemetry, audit evidence and business transaction events may need different retention and access policies. For example, application developers may need performance traces but not full access to an HR-related security log. Azure logging architecture involves routing, cost, retention and use, not simply enabling all diagnostic settings indefinitely.

Secrets and encryption deserve a design decision rather than an afterthought. Azure Key Vault architecture requires selecting authentication, access control, network exposure and recovery. A key store's availability affects any dependent application; tightly scoped access should coexist with a documented recovery process. Threat modeling should consider data in transit, at rest, in telemetry and in backups. Controls that protect one point in the lifecycle cannot automatically be assumed to protect all the others.

Select data services according to workload and failure behavior

Azure SQL services, Azure Cosmos DB and other storage options differ in transaction behavior, data model, scaling, query requirements and operational responsibility. A relational order-processing workload may depend on strict transactional guarantees and reporting joins. A globally distributed document workload may require low-latency access at large scale, suitable partitioning and clear consistency choices. The correct answer depends on workload behavior, not a universal preference for one database brand.

An architect should investigate access patterns and cardinality. A document database partition key that places too many writes on one logical partition can limit throughput; a relational service with poorly planned maintenance may create availability problems. Storage account redundancy, lifecycle management and data retention also affect cost and recovery. Place frequently used data where applications can access it efficiently, while preserving legal and business requirements for archiving or deletion.

Data migration can be the highest-risk component of an otherwise straightforward move. Decide whether the service can tolerate a planned outage, whether dual writes are safe, and how data consistency will be proven after cutover. A transfer that moves every row but leaves application credentials or downstream reports broken is not a completed migration. Compare rehosting, replatforming and refactoring as distinct strategies, with operational evidence and rollback conditions for each.

Design infrastructure and network boundaries for the application

Compute choice involves managed services, VMs, containers, app hosting, throughput and operational expertise. Managed services reduce some responsibilities but do not eliminate application-level security, data protection or availability design. A heavily customized legacy workload may initially need a VM; a stateless frontend can benefit from managed scaling. Estimate peak usage, cold starts, background jobs and dependency limits before promising a service-level objective based only on platform advertising.

Network architecture must account for address spaces, segmentation, hybrid connectivity, routing and private access. Azure Private Link and service endpoints illustrate two ways to approach private connectivity; they should not be confused with constructs used by other cloud providers. In Azure, a private endpoint relies on appropriate DNS and routing. A peered network is not always a transit network, and firewall placement affects both inspection and latency. Test actual flows from the user's location to the final data service.

Application delivery services serve different protocols and requirements. A load balancer, application gateway, front-door service or CDN can improve reachability or resilience when selected appropriately, but each brings routing, certificate and health-probe considerations. Avoid chaining services merely to create a complicated architecture. A request path should remain explainable, with clear failure domains and observable dependencies so operators can identify where a transaction was delayed or rejected.

Plan business continuity and recovery as verified workflows

High availability and disaster recovery address related but different goals. Availability can depend on redundant instances within a region or zone; disaster recovery addresses the loss of a larger failure domain. Data replication, backup and application rebuild are separate controls. Replicated corruption can propagate to a standby just as successfully as legitimate updates, so backups with appropriate retention remain important even for a highly available database.

Recovery design must state dependency order. Domain resolution, identity providers, secrets, network routing and data may need to be restored before a service can accept useful work. A runbook that powers on a VM but does not restore an application configuration may meet a compute checklist while failing users. Test recovery under conditions representing the real incident, including reduced staff availability or an unavailable primary region. Measure observed recovery time and integrity rather than relying on a diagram.

Cost and resilience trade-offs should be explicit. Active-active deployments may reduce failover time but increase synchronization complexity and expense. A warm standby may be cheaper but requires reliable provisioning and careful capacity estimates. Small companies may choose a longer accepted recovery time for a low-criticality function; critical transactions may need stronger controls. The architect's role is to make that choice accountable and testable, not to maximize redundancy for every resource.

An architecture can meet individual service-level targets while a multi-service business transaction still fails. Consider an order system that writes to Azure SQL, retrieves a customer profile from Cosmos DB and publishes a confirmation event. Do not assume a single distributed transaction spans every component. Select an authoritative order record, make event publishing durable, and ensure downstream consumers can process duplicate messages safely. A temporary email outage should not normally cancel a confirmed purchase. The architect should document which operation is critical and which can complete eventually.

A regional recovery plan also requires a decision about which copy of data is authoritative. Test a situation where primary-region health declines, DNS still points to the former endpoint and replication is behind. Identify who can authorize secondary promotion, what amount of data loss is accepted, and how the team will verify order integrity before reopening traffic. An architecture becomes dependable when the human decision path and evidence are as clear as the resources in its diagram.

Explain and validate the final design

An AZ-305 case study should start with business requirements, candidate Azure services, current constraints and a set of proposed trade-offs. Explain why particular components are selected and which threats or failures remain. A reviewer should be able to trace each major architectural decision to a requirement and an operational test. If an alternative would work only with additional staffing or licensing, state that condition rather than pretending both options are equivalent.

Good preparation includes drawing several architectures for the same business process and testing them against changes: doubling the user population, losing an availability zone, adding stricter data residency, or introducing an untrusted partner network. Some designs fail through cost before they fail through throughput; others meet normal traffic but cannot be restored after accidental deletion. Practice explaining the consequence of one change at a time rather than memorizing a single reference diagram.

Microsoft's current AZ-305 study guide is the authoritative definition of assessed skills. Work with the Well-Architected pillars, cloud adoption decisions and actual platform limitations, keeping the difference between a recommendation and a guaranteed outcome clear. Strong Azure architecture is the ability to make choices that remain sensible when the workload grows, the organization changes or a predictable dependency fails.