Microsoft AZ-305: Designing Azure Infrastructure Around Constraints

The AZ-305 Designing Microsoft Azure Infrastructure Solutions exam assesses whether a candidate can turn business constraints into coherent cloud and hybrid architecture decisions. Microsoft's April 2026 guide groups the material into identity, governance and monitoring; data storage; business continuity; and infrastructure design. The candidate should understand networking, virtualization, security, data platforms, disaster recovery and operations well enough to compare options rather than simply name Azure products. Among Microsoft certifications, AZ-305 is associated with the Solutions Architect Expert pathway and complements hands-on administrative knowledge such as AZ-104.

Architecture questions are rarely answered by finding the feature with the longest list of capabilities. The best design depends on recovery objectives, data sensitivity, application behavior, operational staffing, cost and integration with systems already in place. For instance, a globally distributed application may need low-latency reads in several regions but have strict rules about where authoritative data is written. Choosing a replicated database without deciding on consistency, failure handling and permitted regions leaves the hard work undone. AZ-305 rewards a design rationale in which each service choice is linked to a requirement and an acknowledged limitation.

Establish identity, governance and operational boundaries

An Azure landing zone creates an organized foundation for subscriptions, network connectivity, security and policy. Management groups can provide hierarchy across subscriptions, while resource groups serve a more local lifecycle purpose. An organization may separate production from experiments, business units or regulated workloads for different reasons. The article on designing Azure landing zones is relevant because good architecture starts with governance decisions that influence every later deployment. A single massive subscription may simplify initial provisioning while complicating access and cost attribution as teams multiply.

Identity design should distinguish sign-in, privilege and service authorization. Microsoft Entra ID may authenticate people and applications, but Azure RBAC determines access to resource-management actions, and services can enforce additional data-plane permissions. A workload that retrieves sensitive content needs access limited to the required data, not simply a subscription-wide administrator role. Privileged access policies, managed identities and monitoring of role assignments reduce the chance that a single compromised credential controls too much of the environment. The design must also account for how access is revoked and how emergency administration is handled.

Governance requirements should be translated into effective controls rather than labels. A policy can deny certain resource configurations or audit compliance; a tag supports classification and reporting; a resource lock can reduce accidental deletion under particular conditions. None substitutes completely for the others. The guide to Azure identity and governance architecture helps connect these concepts to inherited scopes and operational ownership. An architect should also ask who can modify policies, which exceptions are legitimate and how teams prove that an exception was removed when no longer needed.

Monitoring belongs in architecture, not only operations. Decide which application outcomes, infrastructure signals and security events must be observable, how logs are routed and what retention is justified. Centralizing all data indefinitely can increase cost and privacy exposure, while insufficient observability makes recovery impossible to explain. Metrics and logs answer different questions; an availability figure alone does not describe which dependency failed. Architects should define service-level objectives and incident responsibilities before choosing dashboards. The monitoring design must support decisions during an outage, not merely look comprehensive in a demonstration.

Choose storage and integration by data behavior

Relational databases, globally distributed document stores and object storage solve different kinds of problems. A transactional system may demand strong consistency and complex relational queries, while a media platform needs durable unstructured objects with appropriate access patterns. Data shape is only one criterion: durability, replication, latency, query cost, compliance location and recovery behavior matter as well. The article on choosing Azure data storage provides context for why a service should be recommended only after its workload constraints are understood.

Redundancy requires precise language. Locally redundant storage copies data within a region, whereas regional or geographic replication options have different fault-tolerance, access and recovery characteristics. A secondary location may not be immediately writable and data replicated asynchronously may lag behind the primary. None of these options automatically restores a corrupted application record. The discussion of Azure Storage redundancy choices is relevant when executives equate “replicated” with “backed up.” Architecture should distinguish a failure-domain strategy from point-in-time data restoration.

Data integration also affects architecture. Batch movement, event-driven processing, streaming and direct APIs have different freshness and reliability requirements. A billing workflow that must produce a verifiable transaction result needs stronger failure and duplicate-handling controls than a noncritical nightly analytics feed. Queues can decouple components but create eventual consistency and retry obligations. An architect should know whether downstream consumers tolerate delayed data, whether ordered processing matters and how a failed message will be isolated. Selecting a messaging product is only the beginning of reliable integration design.

Data security extends from identity through transport, encryption, network exposure and retention. A database that supports private connectivity may require DNS and route changes for every application that accesses it. Encryption at rest protects against certain threats while leaving application authorization as a separate concern. Secrets and keys need owners, rotation strategies and recovery considerations. A design is incomplete if it includes a secure database but relies on public administrative credentials embedded in the application's deployment pipeline. Architectural boundaries should make it clear which identities operate the system and which merely consume data.

Design continuity around what users must recover

Business continuity begins with recovery time and recovery point objectives. Recovery time concerns acceptable interruption; recovery point concerns acceptable data loss. Different business processes may require different commitments, and stronger targets generally demand additional cost or complexity. An architect should not recommend multi-region active-active infrastructure without assessing whether the application can handle conflicting writes, user-session state and distributed dependencies. A replicated web tier cannot preserve service if its only database, identity provider or payment gateway is unreachable.

Backup and disaster recovery strategies protect against different failure classes. A backup can restore from a previous state after accidental deletion or corruption, while an alternate-region architecture may keep a service running through a regional incident. Both require tests. A successful backup operation does not prove the application can be rebuilt within its recovery target, and a regional failover drill that ignores external DNS or certificate dependencies is incomplete. The article on Azure Site Recovery architecture illustrates the need to match recovery mechanisms to specific workloads and their dependency maps.

High availability in one region is also different from geographic disaster recovery. Availability zones can reduce exposure to certain datacenter-level failures, but a region-wide event demands another strategy. Failover introduces questions of application consistency, routing updates and how or when traffic returns to the primary location. A storage tier that appears resilient at the infrastructure level may still expose clients to stale application data during switchover. The design should state what the users will see and which operations remain safe, not just where servers will run.

Operational testing turns these claims into evidence. Simulate an availability-zone problem, restore a representative dataset, fail over a nonproduction application and measure the actual result. Include human tasks such as approval to fail over and communication to affected teams. An automated script can recover compute resources while leaving credentials or application configuration incorrect. Document recovery priorities so teams do not bring up a low-value reporting service before a critical customer-facing dependency. The best architecture is one the organization can realistically operate during a stressful incident.

Place compute and networking in a manageable platform design

Compute selection reflects the degree of control the application requires. Virtual machines provide flexible operating-system access but demand patching and scaling oversight; managed application services can reduce some administration while constraining runtime customization; Kubernetes can support complex container orchestration but adds platform skill requirements. The Azure infrastructure architecture choices become clearer when the question is framed around deployment frequency, availability, state, compliance and staff capability. Picking the most sophisticated platform without an operational need can create unnecessary failure modes.

Networking decisions define how applications cross trust and availability boundaries. A hub-and-spoke design, peering, private endpoints, gateways and firewalls each have appropriate use cases. DNS, routing, traffic inspection and service access must work together. If a private endpoint is deployed but the application still resolves a public address, network reachability may fail or violate the intended isolation model. Similarly, a firewall policy that permits the required port cannot repair an incorrect next hop. Architects should map the end-to-end route rather than list network controls independently.

A sound design balances cost with operational reliability. Autoscaling can reduce idle capacity while preserving responsiveness if limits and warm-up behavior fit the workload. Reserving excessive capacity can hide performance inefficiency, while choosing the lowest-cost configuration may increase outages or recovery time. Review cost estimates, service limits and likely growth, then document why the selected option meets the business constraints. Architecture reviews benefit from explicit alternatives: what is gained by a managed database, what is surrendered by a self-hosted one and what would trigger a decision to revisit the design?

Prepare for AZ-305 by writing short architecture decisions against realistic scenarios. For each, state requirements, assumptions, alternatives, selected services, failure behavior, security boundaries, cost and validation approach. Then challenge the design with a region failure, an unauthorized access attempt or a sudden growth in demand. The official objectives provide the coverage checklist, but the skill being assessed is reasoned design. An architect who can explain both why an option fits and when it would be wrong has prepared for more than an exam: they have developed a way to make cloud systems accountable to business requirements.