Microsoft AZ-305: Making Defensible Azure Architecture Decisions

AZ-305 is about architectural judgment rather than the memory of every Azure setting. Microsoft expects solution architects to translate requirements into cloud and hybrid designs covering identity, governance, monitoring, storage, business continuity and infrastructure. Its April 17, 2026 skills outline remains the relevant current reference as of this writing. The most valuable preparation begins with explicit constraints: the workload's service levels, data sensitivity, regulatory boundaries, operational skills and cost tolerance. A technology choice is credible when the architect can show which requirement it satisfies, which risks remain and what evidence would justify revisiting the decision.

Start with nonfunctional requirements that can be tested

Architecture documents often begin with a list of attractive services. AZ-305 cases demand the opposite direction: define measurable needs first. How much downtime is acceptable? What recovery point could the business tolerate? Are users distributed geographically? Must data stay in a particular jurisdiction? What is the team's ability to operate containers or maintain specialized databases? Latency, availability, cost and compliance can conflict, so the architect needs to document priorities and tradeoffs rather than promise all objectives at minimal expense.

A payments platform may require strong auditability and low-latency transaction processing, while a marketing analytics system accepts delayed updates to reduce expense. Both use Azure but should not share a universal architecture diagram. Record assumptions and dependencies so new information can change the design rationally. Explicit well-architected tradeoffs connect reliability, security, performance, operational excellence and cost to business decisions and accepted risks. A solution without measurable acceptance criteria cannot be convincingly reviewed after implementation.

Identity and governance should follow data ownership

Authentication, authorization, resource hierarchy and policy define what people and workloads may do. Azure RBAC manages resource actions; Microsoft Entra identity services manage directory and sign-in concerns; data services may have their own granular authorization model. An architect should recommend where the principal of least privilege is enforced and which administrative duties must be segregated. Management groups and subscriptions provide governance scope, not an excuse to grant a central operations identity every permission by default.

Suppose several business units share a data platform but must keep customer records separated. Subscription-level boundaries, encryption, data access policy and audit logging may all contribute to isolation. A single security group is not sufficient if a shared application identity can query every dataset. Design how service identities are rotated or revoked, how secrets are managed and how exceptions are approved. Identity and governance design becomes more useful when it addresses real ownership and incident scenarios, including what happens after an employee changes teams or a third-party integration is compromised.

Monitoring architecture must answer operational questions

A logging strategy should state which incidents the organization must investigate and how quickly. Centralization can aid correlation across subscriptions, but it also creates cost and privacy considerations. Decide which metrics, resource logs, application traces and security events are needed, how long they are retained and who may access them. A system can be running according to its infrastructure metrics while its customers cannot complete a purchase. Observability therefore includes end-user outcomes and application-level indicators, not just machine performance.

Consider a multi-region API with an identity provider and a downstream database. A latency spike might originate in token acquisition, routing, database throttling or an application release. Build correlation across those dependencies and alert on measurable user impact. Provide the operations team with runbooks and escalation ownership, not an unlabeled data lake of diagnostic events. These concerns overlap with Azure monitoring, but the architect's task is to choose a cross-workload design that still works when several teams and regions are involved.

Data platforms should reflect access and consistency needs

Relational databases, document stores, object storage and analytical systems have distinct strengths and constraints. Azure SQL supports relational transactions and SQL-based workloads. Azure Cosmos DB can provide a globally distributed document data model with important partitioning and consistency tradeoffs. Blob Storage fits object workloads, while analytics platforms may depend on lake or warehouse structures. Architecture questions should not be answered by choosing the most modern service. Start with query patterns, transaction rules, scale characteristics, latency and the team's skills.

For a global catalog with frequent location-specific reads, distributed document data may be appropriate. For orders requiring complex transactional integrity, a relational design might simplify correctness. Separate operational and reporting paths when heavy analytical queries would otherwise disrupt customer operations. Consider backup, encryption, data residency and migration effort. The relevance of Azure storage architecture choices lies in explaining the constraints behind the decision. The specialist DP-300 and DP-420 paths explore operation and development of particular data services; AZ-305 expects the broader design tradeoff.

Compute and network decisions have to agree

The choice between virtual machines, App Service, containers and serverless workloads changes scaling, configuration control and operating burden. Network design must support whichever model is chosen. Private endpoints, hybrid connectivity, routing, DNS, outbound access and application delivery all affect reliability and security. A service that is isolated for security but cannot reach its required data sources is not a successful secure design. Conversely, allowing unrestricted public access to repair connectivity defeats the original control objective.

Imagine an application needing secure access from a corporate data center to an Azure database while serving internet customers. The architect may separate public ingress from private backend connectivity, choose an appropriate hybrid connection and design DNS to direct internal traffic correctly. Availability zones and geographic replication cannot be evaluated independently of network paths and client failover behavior. Compute architecture choices and network architecture decisions belong together because a change in one can invalidate assumptions about the other.

Business continuity means designing for the actual failure

High availability protects against certain component failures, while disaster recovery addresses broader outages. Neither guarantees that a business process resumes correctly. Recovery time objective and recovery point objective are different commitments. Geo-replication, backup and restore, zone redundancy and application-level retries solve different portions of the problem. The architect must understand failure domains and test the assumptions against operational constraints. A second region is not useful if identity, DNS or external integration still relies on the failed site.

A retailer might tolerate a few minutes of degraded browsing but not lose confirmed orders. The design could separate catalog availability from order integrity, with different recovery patterns and transaction guarantees. Test regional evacuation, data reconciliation, dependency readiness and the time for users to resume a complete workflow. An untested secondary deployment is only a proposed capability. Designing for continuity and recovery should lead to a documented exercise that exposes hidden single points of failure rather than to a diagram showing two regions and a reassuring arrow.

Migration designs must acknowledge operational constraints

A migration from on-premises infrastructure is not only a question of copying virtual machines. Dependencies, licensing, latency, security controls, identity assumptions and data movement determine feasible sequences. Refactoring can improve long-term operations but may exceed the organization's risk appetite during a critical deadline. A staged migration may be more defensible, with temporary hybrid connectivity and measurable readiness gates. Decide which workloads can move unchanged and which depend on services that cannot yet be replicated or replaced.

Suppose an accounting application uses a shared database, legacy file paths and nightly jobs. Migrating the application tier without the data access and batch dependencies can produce failures that did not appear in a static inventory. Plan cutover, coexistence, rollback and reconciliation in business terms. The architect must also specify the operating model after migration: who patches resources, reviews access and funds ongoing consumption? Such decisions connect migration design with ownership and financial sustainability, not merely with the number of workloads moved.

A separate exercise should test how architectural responsibility changes with service abstractions. Managed services reduce tasks such as guest patching, but they do not eliminate configuration, authorization, application compatibility or data recovery responsibilities. Architects need to identify which operations Microsoft manages and which remain the customer's duty for each selected service. The same applies to budget: an inexpensive development architecture can become costly under production traffic, diagnostic retention, cross-region transfer or overprovisioned capacity. Include a realistic cost model and a plan to observe actual usage after rollout. A recommendation that meets performance requirements at impossible cost is not a feasible architecture, even if every individual product is technically supported.

Prepare by defending a tradeoff under changing facts

Work through a case study in several rounds. Begin with an Azure design meeting a fixed budget, an RPO, an RTO, data residency and expected peak traffic. Then introduce a new constraint, such as tighter regional availability or an inability to operate Kubernetes. Explain which part of the design must change and what additional cost or complexity follows. This exercise develops the core skill AZ-305 assesses: recommending and defending a solution under competing priorities.

AZ-104 provides implementation literacy for resources the architect recommends; AZ-700 adds network engineering specialization; AZ-400 addresses release processes that make the design maintainable. For AZ-305, know enough of each to recognize interactions without substituting any one specialist exam for architecture judgment. Success means producing a design that others can implement, observe, secure and recover—not simply naming all the Azure services that might appear in an enterprise diagram.