Microsoft AZ-305: Infrastructure Design

Microsoft AZ-305 is an architecture exam, which means many questions are not asking whether an Azure service can technically do something. They are asking which design best satisfies a set of constraints: availability, security, governance, performance, cost, operations, migration, data requirements, and business continuity. Infrastructure design is therefore a tradeoff discipline rather than a product catalog.

As of October 6, 2026, Microsoft AZ-305 remains current. The current English blueprint was updated on April 17, 2026 and covers identity, governance and monitoring; data storage; business continuity; and infrastructure design. The sections below focus on the infrastructure-design mindset that ties those areas together.

Start by separating requirements from preferences

Architecture scenarios often contain many details, but only a few are true constraints. A preferred technology is not the same as a regulatory requirement. A desire for simplicity is not equivalent to a hard recovery-time objective. Before selecting services, classify each statement as mandatory, preferred, contextual, or irrelevant.

This simple step prevents overengineering. If the requirement is global HTTP distribution with Web Application Firewall and low-latency routing, the architecture should be driven by those constraints. If the requirement is private regional access to a backend, the solution space is different. Service selection comes after the constraint map.

Add a decision hierarchy. Regulatory and contractual requirements usually outrank cost optimization; recovery objectives can outrank deployment simplicity; data residency can remove otherwise attractive global services from consideration. When multiple constraints conflict, identify which one is non-negotiable and which can be traded. This mirrors real architecture reviews where the best technical design may not be the best business design.

Design compute around workload behavior

Virtual machines, virtual machine scale sets, App Service, Container Apps, AKS, Functions, and batch-oriented services each impose different operational models. The architecture decision should consider control, scaling behavior, deployment model, state, networking, maintenance responsibility, and team capability.

A useful practice is to solve the same application three ways and explain what the organization gains and gives up. This reveals whether you understand managed-service tradeoffs rather than simply matching keywords to products.

Include operational maturity in the tradeoff. A team that cannot operate Kubernetes reliably may be better served by a managed application platform even if AKS offers more control. Conversely, workloads with specialized networking, scheduling, or platform requirements may justify the additional operational burden. Architecture is partly about matching technology to organizational capability.

Finally, include deployment and maintenance cadence in the compute decision. A workload that changes several times a day benefits from different platform characteristics than a stable legacy application with rare releases. Consider blue-green or rolling deployment needs, image or runtime maintenance, configuration ownership, and rollback expectations. These operational details often distinguish two technically valid compute options.

Treat networking as an architecture boundary

Virtual networks, peering, hubs, private endpoints, gateways, routing, load balancing, global delivery, firewalls, and DNS determine how workloads communicate and where trust boundaries exist. Network design should show which traffic is public, private, inspected, centralized, or segmented.

Architects should be able to trace a request from client to service and back. If the design includes private endpoints, explain the DNS behavior. If it includes a central hub, explain route ownership and the effect of inspection. If the design spans regions, explain how failover and name resolution behave.

Consider egress and dependency control as well as ingress. Many architectures secure incoming traffic carefully but allow broad outbound access that creates data-exfiltration or dependency risks. Define how workloads reach package repositories, APIs, SaaS services, and on-premises systems. Then decide which outbound paths require inspection, private connectivity, or policy enforcement.

Choose data services from access and resilience requirements

Storage decisions are not separate from infrastructure design. Relational versus nonrelational needs, consistency, latency, scale, analytics patterns, backup, replication, and data residency can determine the broader application architecture. The correct choice is rarely ‘the most scalable service’; it is the service whose guarantees match the workload.

Create a decision table that compares transaction shape, query pattern, global distribution, schema flexibility, high availability, recovery, encryption, and operational overhead. Then change one requirement and see whether the preferred design still holds.

Think about operational recovery alongside normal access. A globally distributed database may meet latency goals but complicate consistency and recovery decisions. A simple relational service may be easier to protect and operate for a transactional workload. Include backup, point-in-time restore, replication, failover testing, and ownership of schema changes in the design record.

Use messaging and integration to reduce coupling

Queues, topics, events, APIs, and workflow services matter when they reduce coupling or improve resilience. Messaging and event-driven architecture should be selected from delivery guarantees, latency, ordering, fan-out, and failure behavior rather than from familiarity with a service name.

Do not introduce messaging because ‘microservices use events.’ Use it when the business and technical requirements justify decoupling, buffering, fan-out, or independent scaling. Architecture answers are stronger when the mechanism is tied directly to the failure mode or dependency it solves.

Consider idempotency, duplicate delivery, ordering, poison messages, retries, and dead-letter handling when asynchronous design is selected. Messaging improves decoupling, but it also introduces new failure modes that the architecture has to manage. A good design states how consumers recover when messages are delayed, repeated, or cannot be processed.

Make availability an explicit design dimension

High availability depends on more than deploying two instances. The design must consider failure domains, zones, regions, state, dependencies, health checks, routing, data replication, and operational recovery. A redundant frontend with a single regional database may still fail the business requirement.

Map the availability target to every critical dependency. Then ask what happens during compute failure, zone failure, region failure, data corruption, and operator error. This reveals whether the design is actually resilient or merely distributed.

Distinguish availability from disaster recovery. Zone redundancy may protect against a datacenter failure inside a region, while regional recovery addresses a different failure class. Backups protect against corruption or deletion but do not automatically provide low downtime. Map each control to the failure it mitigates so that you do not stack expensive redundancy without knowing which business risk it addresses.

Availability reviews should include planned maintenance and deployment events, not only failures. Ask whether upgrades, scaling operations, certificate rotation, or infrastructure changes can interrupt service. Designing for maintainability often changes instance count, deployment pattern, or traffic-management choices even when the headline availability target stays the same.

Design recovery from business objectives

Business continuity requires explicit RTO and RPO targets rather than generic backup language. Business continuity and disaster recovery become architecture decisions when redundancy, replication, backup, failover, and recovery testing are tied to those business objectives.

Build recovery designs backwards from the maximum acceptable downtime and data loss. Decide which workloads need active redundancy, which can restore from backup, how traffic fails over, how data is replicated, and how the organization validates the plan. The cheapest architecture may be acceptable for one workload and unacceptable for another.

Include dependencies in recovery sequencing. Restoring an application before identity, networking, secrets, or data services are available may not restore the business process. Write a recovery order for critical components and identify which dependencies must be validated before traffic is returned. This turns recovery from a feature checklist into an executable architecture.

Include governance and observability in the architecture

Subscriptions, management groups, policy, roles, tagging, logging, monitoring, alerts, cost controls, and resource organization affect whether a design can be operated safely at scale. Architects who ignore governance often create systems that work technically but become inconsistent, expensive, or difficult to audit.

Every architecture diagram should include where telemetry goes, how teams gain access, how standards are enforced, and which signals indicate service health. These are not implementation details; they are part of the design’s operational viability.

Cost governance also belongs here. Tagging, budgets, reservations or savings strategies, autoscaling boundaries, retention settings, and resource standards influence whether the architecture remains sustainable. Cost is not a final optimization pass; it can affect service tier, region count, redundancy model, and data-retention design from the beginning.

Practice tradeoff explanations, not service-name recall

For each architecture exercise, write a short decision record: requirement, chosen option, rejected alternative, reason, and operational consequence. This trains the exact skill that difficult AZ-305 scenarios demand—choosing between plausible solutions.

When two answers appear technically possible, return to the constraint that differentiates them. The strongest preparation is not memorizing the largest number of Azure services. It is learning to identify the requirement that earns a particular architecture and to explain why a simpler or more complex alternative is less appropriate.

Use architecture decision records that are short enough to maintain. A good record names the context, decision, alternatives, consequences, and conditions that would cause the decision to be revisited. This teaches you to communicate architecture, which is as important as choosing services. AZ-305 scenarios often reward the design that best satisfies stated constraints, not the design with the most features.

Add a failure review to each decision record. Ask what happens if the selected region fails, the identity provider is unavailable, a dependency becomes rate-limited, or a cost assumption changes. The purpose is not to make every solution survive every imaginable event; it is to understand where the architecture is intentionally resilient and where residual risk remains. That awareness makes design tradeoffs much more precise.