The Microsoft AZ-305 exam, Designing Microsoft Azure Infrastructure Solutions, remains a current requirement for Microsoft Certified: Azure Solutions Architect Expert. Its English skills outline was updated on April 17, 2026. Microsoft assesses design of identity, governance and monitoring; data storage; business continuity; and infrastructure solutions. Candidates should use the current official study guide to check the precise objectives before committing to a preparation plan, because an older course or practice set may describe a previous version of the exam.

There is also an important distinction between passing an exam and earning the expert credential. Microsoft currently requires the Azure Administrator Associate certification as a prerequisite to Azure Solutions Architect Expert. The architecture exam tests design judgment, while the administrator credential demonstrates the ability to implement and operate Azure resources. A candidate should plan for both requirements instead of assuming that an AZ-305 pass alone completes the certification pathway.

Confirm the credential pathway and the experience it assumes

The prerequisite is Microsoft Certified: Azure Administrator Associate, which is associated with the Microsoft AZ-104 exam. Azure administration knowledge is a foundation for architecture decisions: an architect who has never worked with subscriptions, virtual networks, storage accounts, role assignments, monitoring, or backup configurations may know the terminology but overlook operational consequences. Candidates who already hold the prerequisite can use their administration experience as the starting point for design exercises.

The two exam scopes should not be confused. AZ-104 emphasizes implementing and managing an Azure environment. AZ-305 asks which environment should be designed for a particular set of requirements and why. Consider an application that needs private database connectivity: the administrator must know how to configure the network path and access controls, while the architect must decide whether private endpoints, hybrid connectivity, address planning, DNS, and the chosen hosting model meet the application’s broader constraints.

Experienced architects coming from other clouds also need an Azure-specific baseline. General knowledge of high availability or identity is useful, but it does not automatically establish familiarity with Azure’s management-group hierarchy, subscription boundaries, Azure Policy, Microsoft Entra ID, virtual network peering, managed service options, and platform-specific recovery features. Targeted hands-on work closes those gaps more reliably than simply reading lists of products.

Study the four official design areas as one architecture

Microsoft’s April 2026 AZ-305 outline assigns approximately 25–30% to identity, governance, and monitoring; 20–25% to data storage; 15–20% to business continuity; and 30–35% to infrastructure solutions. These ranges identify exam emphasis, not isolated subjects that can be learned independently. An infrastructure decision can change data placement, identity flows, monitoring, cost, and disaster recovery at the same time.

Rather than memorizing each domain as an unrelated chapter, use a single hypothetical workload and examine it four ways. First, determine who may administer and use it, how the environment is governed, and how failures are observed. Next, identify the data model, transaction requirements, growth profile, and protection obligations. Then establish allowable downtime and data loss. Finally, select the hosting, integration, network, and deployment approaches that satisfy the preceding constraints.

This sequence reflects the most valuable habit in architectural work: requirements narrow the options before product preferences take over. A service that is excellent in general may not fit the specific business problem. Cloud architecture starts with constraints because requirements such as sovereignty, consistency, recoverability, and delegated ownership can eliminate otherwise attractive designs.

Design identity, governance, and monitoring around real ownership

Start identity design by distinguishing application users, workload identities, developers, operators, and privileged administrators. Authentication confirms a principal; authorization determines permitted actions. Azure role-based access control governs Azure resource operations, while an application or data service may have its own authorization system. Granting permission to deploy a database does not automatically justify reading the customer data within it. Architecture decisions should define these boundaries before teams accumulate broad permissions as shortcuts.

Managed identities can remove the need for reusable application secrets in supported scenarios, but the architect still decides which services a workload may call and how permissions are scoped. Microsoft Entra ID, Conditional Access, privileged-access workflows, and secrets management should be considered according to the identities and risks involved, not added as an indiscriminate checklist. An explicit account of who owns each access decision makes the design maintainable after deployment.

Governance begins with management groups, subscriptions, and resource groups that reflect stable differences in responsibility and policy. Azure Policy can audit or enforce requirements such as allowed regions and tagging, but overly broad restrictions can block legitimate deployments. A well-designed Azure landing zone provides shared identity, networking, security, and monitoring foundations while allowing workload teams appropriate autonomy. The goal is predictable onboarding with clear policy exceptions, not central approval of every routine configuration change.

Monitoring must cover the behavior the business needs to observe. Azure Monitor, logs, metrics, and alerts are useful only when the architecture identifies critical signals and assigns response ownership. A dashboard that reports virtual-machine CPU usage may miss a failed customer transaction or an exhausted message queue. Define service-level indicators, diagnostic requirements, alert routing, retention, and audit needs with the application and security teams, then confirm that the chosen Azure services can produce the required evidence.

Choose data stores from transaction and access patterns

Data-platform selection should begin with the shape of the information and the operations that must remain correct. A relational workload with joins, constraints, and transactional requirements may suit Azure SQL services. A globally distributed document application may suit Cosmos DB when its partition key, consistency model, and request patterns have been designed carefully. Documents, backups, media, and large raw analytical files may belong in Azure Storage rather than a transactional database. None of those choices is universally best.

The most important questions are concrete. What must change atomically? Which queries dominate read traffic? Does the workload require low latency in several regions? What happens if a region becomes unavailable? How does data classification affect replication and residency? Which team owns backup and restoration? An Azure Cosmos DB architecture built around a poor partition key can perform badly even when the service’s global features are attractive. Conversely, selecting a relational database solely because the team knows SQL can burden a highly distributed, document-oriented workload with unnecessary compromises.

Architects should also distinguish operational data from analytics. A data lake or analytical copy can support aggregation and historical reporting without forcing complex analysis against a transaction-critical database. But every new copy introduces movement, protection, retention, cost, and possible inconsistency. The design should identify authoritative sources and how downstream consumers receive updates, including what happens when an integration fails or runs behind schedule.

Turn RTO and RPO into testable continuity designs

Recovery time objective (RTO) defines the maximum acceptable interruption to a business capability. Recovery point objective (RPO) defines the maximum tolerable data loss, generally expressed as time. These are business decisions that should be negotiated before selecting availability zones, backup policies, or a second region. If stakeholders demand near-immediate recovery, the architecture may need standby capacity, automated routing changes, and data-replication mechanisms that a low-cost backup-only design cannot provide.

High availability and disaster recovery solve different problems. Multiple healthy application instances may protect against a single compute failure; availability zones may reduce exposure to a zonal failure; a regional disaster may require a separate recovery environment. Replication can propagate accidental deletion or corruption, so it is not a substitute for recoverable historical backups. The architect must decide which failure modes matter and which protections address each one.

A continuity plan built around RTO and RPO also needs a runbook and a test. Time the full path from incident declaration through traffic redirection, identity, network, data validation, application checks, and business approval. A restored database is not sufficient if the application cannot authenticate, resolve private names, or complete its primary business transaction. Document the observed recovery result and redesign any dependency that prevents meeting the agreed objective.

Compare compute, integration, and networking as operating models

For a web API with standard hosting needs, Azure App Service may reduce infrastructure administration. Azure Functions may fit event-driven tasks whose execution and scaling behavior suit a serverless model. Azure Kubernetes Service can be appropriate when the workload needs Kubernetes orchestration, custom controllers, advanced container policies, or specialized deployment patterns, but the team still manages significant cluster and workload responsibilities. Virtual machines may remain necessary for legacy operating-system dependencies or software that cannot fit managed runtimes.

The distinction is not simply modern versus old. Every service moves the boundary between Microsoft’s responsibilities and the customer’s responsibilities. Before choosing, compare operating-system control, supported runtimes, latency, scaling behavior, startup sensitivity, storage integration, deployment frequency, upgrade responsibility, observability, network requirements, and team expertise. A platform that is technically capable but poorly understood by its operators can create risk that a design diagram does not reveal.

Networking starts with communication flows rather than a default topology. List user-to-application, application-to-data, Azure-to-on-premises, administration, and third-party paths. Identify bandwidth, latency, routing, DNS, private access, inspection, and failure requirements for each. A hub-and-spoke design may centralize shared connectivity and security, but it also creates routing and shared-service dependencies. For an application with few private network requirements, a simpler arrangement may be easier to operate. A design is justified by the traffic and control model, not by the familiarity of its diagram.

Application integration also deserves architectural attention. Queue-based buffering can decouple workloads that experience different demand rates, while synchronous calls may be appropriate when the user needs an immediate result. Retry behavior, idempotency, message ordering, secret handling, observability, and downstream limits matter in both cases. A workload is not resilient merely because it uses a managed queue or serverless function; it becomes resilient when its failure behavior has been designed and tested.

Practice architecture decisions with a measurable case study

Consider a hypothetical company moving a customer-ordering application to Azure. It requires regional data residency, private access to its payment records, seasonal traffic scaling, a clearly defined recovery objective, and a small operations team. Start by separating hard constraints from preferences. Data residency and the approved recovery limits constrain the solution. The desire for a familiar VM deployment may be negotiable. Ask which components must be operational during an outage, which data must remain consistent, and which external payment or identity dependencies could defeat the recovery design.

Next, compare candidate architectures rather than selecting services immediately. A managed web tier could reduce patching for the small team, while a specialized workload component might retain virtual-machine requirements. A relational order database could preserve transaction behavior, with documents and exports handled separately. Private endpoints could satisfy certain data access requirements, but DNS and routing must be designed for both ordinary operation and failover. A standby region might improve recovery yet add replication cost and residency complexity. Record why each option satisfies or violates a specific requirement.

Finally, identify how the design would be proved. Run load tests for seasonal demand, verify unauthorized principals cannot access the data plane, simulate a component failure, measure failover duration, and validate the estimated cost under normal and peak traffic. This turns a case study from a list of product names into a chain of evidence. Even when an exam question does not provide every number, the candidate should recognize which missing fact would change the answer.

Build a preparation cycle around decisions and errors

Use Microsoft’s current AZ-305 study guide as the source for the exam objectives, and map each objective to a design exercise. After reading an official learning module, explain the decision to someone else or write a short architecture record: the requirement, the candidates, the tradeoff, the selected approach, and the assumption that would trigger reconsideration. If a topic depends on a behavior you have never configured, perform a small hands-on experiment and record the result rather than assuming a diagram proves it works.

Practice questions are most valuable when used diagnostically. For every missed scenario, identify whether the error came from missing service knowledge, overlooking a nonfunctional constraint, misunderstanding a dependency, or choosing an unnecessarily complex design. Review the relevant official documentation, then attempt a different scenario with the same underlying concept. Repeating the same question until the wording is familiar measures recall of that question, not architecture judgment.

Give special attention to the distinctions the exam repeatedly relies on: management-group policy versus workload autonomy, authentication versus authorization, relational transactions versus distributed documents, backup versus replication, high availability versus disaster recovery, managed hosting versus operating-system control, and design selection versus implementation. Those comparisons are more durable than trying to memorize a universal answer for every Azure service.

As the exam approaches, verify the current study-guide date again, then rehearse reading long scenarios for constraints before inspecting answers. Time pressure is easier to manage when a candidate has a consistent reasoning process: extract requirements, reject options that violate hard constraints, compare remaining tradeoffs, and select the answer with the best fit. There is no guarantee that one study schedule or practice score predicts a pass; readiness is better demonstrated by explaining why competing options are wrong.

Use certification preparation to become a better architecture reviewer

AZ-305 preparation is most valuable when it changes how a professional evaluates designs. Strong architects identify the decisions that cannot easily be reversed, bring business stakeholders into discussions of recovery and cost, expose identity and network dependencies before deployment, and document the assumptions behind each choice. They know that an architecture is not finished when the diagram looks complete; it is finished when the requirements can be traced to controls, services, and tests.

For the certification pathway, confirm the Azure Administrator Associate prerequisite, study the April 2026 AZ-305 skills measured, and practice making and validating tradeoffs in complete scenarios. For the professional role, carry that same discipline into design reviews: start with what the workload must accomplish, identify its constraints, select the simplest architecture that satisfies them, and test the risks that matter most. That reasoning is the difference between recognizing Azure services and designing an Azure solution.