The Microsoft AZ-305 exam is called Designing Microsoft Azure Infrastructure Solutions. Its current English skills outline took effect April 17, 2026, and covers identity/governance/monitoring, storage, business continuity, and infrastructure design. The exam is not a generic introduction to cloud computing. Candidates should have working familiarity with Azure administration, networking, identity, security, data platforms, and recovery concepts before expecting to reason confidently about architecture scenarios.

Begin with the distinction between an Azure administrator and an architect

An administrator is often concerned with whether a resource is running, correctly configured, monitored, and secure. An architect begins one level earlier: which resource or service belongs in the design, how should responsibilities be divided, and what failure modes or operating costs does the choice create? Both perspectives matter, but the second requires comparisons among plausible options rather than detailed recall of a single setup procedure.

Consider a team running an application that must remain available during server maintenance. An administrator might configure virtual-machine availability features competently. An architect must ask whether virtual machines are the right hosting model at all, whether a managed application platform would reduce the maintenance burden, how client traffic reaches the service, and what happens if the data layer fails. The right recommendation depends on application compatibility and staffing as much as on uptime targets.

This distinction also matters for credentials. The Microsoft Certified: Azure Solutions Architect Expert credential requires the Azure Administrator Associate certification in addition to passing AZ-305. Passing one exam does not by itself satisfy the complete expert pathway. A candidate without substantial administration experience should strengthen that foundation rather than trying to memorize architecture diagrams without understanding what the services do.

Choose a manageable foundation before tackling architecture

A useful starting point is to be able to describe an Azure tenant, subscriptions, management groups, resource groups, and regions without conflating their purposes. A tenant represents an identity boundary; subscriptions help divide billing, quotas, and resource organization; management groups can apply governance across subscriptions; and resource groups organize lifecycle management within subscriptions. The distinctions are not merely vocabulary because access and policy may be scoped differently at each level.

Next, understand how a request travels through a basic Azure workload. Draw a client, application, database, network boundary, identity provider, and monitoring system. Label which components are publicly reachable and which use private connectivity. Explain how the application authenticates to its data service and where secrets, certificates, and logs are stored. If you cannot trace these relationships, adding a second region or a more sophisticated network topology will only make the drawing harder to understand.

Administrative skills associated with the Microsoft AZ-104 exam make this foundation concrete. Candidates should recognize virtual networking, storage redundancy, resource access controls, compute options, monitoring, and operational recovery. That knowledge does not guarantee an architect-level answer, but it provides the operational reality against which design trade-offs can be evaluated.

Learn architecture by following one example from requirements to design

Imagine a midsize retailer launching an order-management application. Customers place orders online, warehouse staff retrieve them from several locations, and finance employees produce daily reports. The business asks for reliable service during regional maintenance, strict access to customer data, and manageable operating costs. Before considering Azure products, write down what is still missing: the permissible downtime, maximum acceptable data loss, expected transaction volume, geographical restrictions, and whether the team can maintain database servers.

The same question can support several defensible designs until these gaps are resolved. A managed database may reduce maintenance but still require a strategy for application compatibility and failover. A multi-region application might improve continuity but increase data replication and operational complexity. Private networking may reduce exposure yet require careful DNS and hybrid access arrangements for the warehouses. Architecture begins by obtaining those constraints rather than treating a favorite Azure service as the default answer.

Use a simple design note with three columns: requirement, candidate decision, and reason. Add a fourth column for the cost or limitation introduced. For example, “recover quickly from a regional disruption” may justify an additional deployment region, but that change raises questions about traffic routing, state synchronization, and failback. The note trains you to connect every technology choice to a stakeholder requirement.

Understand identity and governance as architectural boundaries

The first AZ-305 domain, identity, governance, and monitoring, accounts for 25–30 percent of the current skills outline. For our retailer, a warehouse employee and a finance analyst may use the same application but should not necessarily see the same records or administer the same cloud resources. Microsoft Entra ID, application authorization, managed identities, and Azure role-based access control address related but distinct parts of that problem.

Make sure you can explain the difference between granting a person access to an application and granting a workload permission to read a storage account. Then examine who should be allowed to alter the permissions and where the rights should be scoped. A system that successfully authenticates every user can still be insecure when its roles are broader than the work requires.

Governance adds a separate layer. A policy might limit regions or resource configurations, while tagging may help allocate costs to business units. Centralized policies must be planned with exception handling so that a legitimate deployment is not blocked without explanation. The practice of connecting Azure governance scope, policy, access, and cost illustrates why these controls are strongest when designed as a coherent operating system rather than several uncoordinated portal settings.

Monitoring deserves equal attention. The retailer must know whether failed checkouts reflect application errors, a database bottleneck, network latency, or a regional disruption. Different telemetry sources answer different questions. An architect decides which metrics and logs are needed, how they are routed and retained, and who acts on an alert. Collecting data without defining an operational response does not create useful observability.

Choose data services by asking how information is used

Data-storage design represents 20–25 percent of the current outline. Our retailer might need relational transactions for orders, unstructured storage for receipts, and a data-integration process for daily reporting. These requirements are not interchangeable. A relational service must support the transaction and query patterns of the application, while receipt storage may emphasize inexpensive retention, controlled access, and durability.

Start with the data’s shape and behavior: structured or unstructured, read-heavy or write-heavy, frequently accessed or archival, short-lived or regulated for long retention. Then compare available Azure offerings based on compatibility, operational overhead, scalability, resilience, and cost. Avoid assuming that a service with more features is always superior. A feature that adds no benefit to the workload may raise complexity or expense without improving the outcome.

For a database choice, explicitly discuss the administrator’s work after launch. Who applies software updates? Who handles backups and recovery? Can the application tolerate a service-tier limitation? What would migrating away from the chosen platform require? These questions turn a product comparison into a long-term operating decision. They also train the architect to explain why a cheaper initial deployment might cost more to support over several years.

Separate everyday availability from disaster recovery

Business-continuity design accounts for 15–20 percent of the current AZ-305 objectives. Beginners often treat availability zones, data replication, backups, and disaster recovery as interchangeable protections, but each responds to a different failure. Availability architecture may keep an application working through some component failures. Backups help recover specific data states. Disaster recovery addresses the steps and time needed to restore a service following a more disruptive event.

Ask the retailer how many minutes of transactions it could lose and how long order processing could stop. These lead to recovery point objective (RPO) and recovery time objective (RTO). If the business cannot tolerate much data loss, an infrequent backup strategy is unlikely to meet the requirement even when the backups are valid. If the application must resume quickly, data recovery alone is insufficient when compute, networking, and access controls still need to be rebuilt.

An architecture exercise should therefore include the order of recovery. Can the database recover without the application’s secrets and network configuration? Does a secondary region have the permissions required to run? Who initiates failover, and how is the restored service tested? Azure Backup and Azure Site Recovery address different categories of recovery, and neither eliminates the need for an application-specific continuity plan.

Explore compute and networking as part of the same workload

Infrastructure design has the largest weight range in the current outline, at 30–35 percent. For a new learner, the amount of product detail can feel overwhelming. Organize the choices around a few business questions instead: Is the application stateful? Can it run in a managed service? Does traffic require private connectivity? Does it need autoscaling? Which components should be deployed close together, and which require independence to survive failure?

For computing, contrast the operational responsibilities of virtual machines, managed web applications, containers, and serverless functions. For networking, work through route selection, connectivity from a branch office, network segmentation, secure application exposure, and DNS resolution. Do not choose a particular service simply because you used it in a training lab. Explain what it solves for the workload and the constraint that would make you reject it.

In our retailer example, warehouses might connect over existing private networks. A design that works for customers on the public internet might not automatically work for warehouse applications. Name resolution for private services, routing to on-premises systems, and the location of application dependencies must be understood together. A diagram that shows packet flow and DNS lookup is often more revealing than a list of cloud products.

Practice the design cycle before using timed assessments

Make small architecture decisions repeatedly. Choose a scenario, extract requirements, compare two or three approaches, sketch the winner, and identify its weakest assumption. Where a feature’s behavior is uncertain, test it in a carefully scoped Azure laboratory or consult the official Azure Architecture Center. Controlled experiments should have a clear objective and an exit plan; review costs and remove temporary resources so practical work does not create unwanted charges.

When you move to practice questions, record more than the answer. Write down which requirement eliminated each alternative, which term you misunderstood, and which Microsoft documentation clarified the decision. Revisit the scenario later without the original options. If you can still explain why a design is appropriate and where it fails, you are developing transferable understanding rather than memorizing answer patterns.

Be cautious with older AZ-305 courses and question collections. Microsoft’s English objectives were revised April 17, 2026, and legacy preparation materials may describe different groupings or outdated platform names. Compare the topic list of any course or book with the current issuer outline. Avoid claims that a certain number of mock exams or a particular number of study weeks will guarantee success; an experienced operator and a candidate new to Azure will need different preparation.

Recognize readiness by the questions you can answer independently

Before booking, try to explain an unfamiliar architecture scenario in plain language. Can you identify its hard requirements and missing facts, trace identity and network dependencies, select a storage and hosting model, and describe recovery and monitoring? Can you name a plausible alternative and the specific reason it falls short? These are stronger readiness signals than the ability to recall the position of a portal setting.

Finally, verify the current AZ-305 exam information, testing policies, and certification requirements directly with Microsoft. If you pass but have not yet earned the required Azure Administrator Associate certification, treat your exam result and expert credential status separately. A strong preparation process should leave you with more than exam knowledge: it should build the habit of turning unclear business requests into designs that other engineers can implement, test, and operate.