AZ-305 Master Guide 2026

What AZ-305 asks you to design

AZ-305 is a role-based exam about architecture decisions across Azure and hybrid environments. Microsoft describes the role as advising stakeholders, translating requirements into designs, and working with developers, administrators, security engineers, and data engineers. A strong candidate connects service selection to business constraints such as recovery objectives, security boundaries, operating model, and cost. Merely recognizing a product name is not enough when several services could satisfy the broad requirement.

The exam is organized around four weighted areas: identity, governance, and monitoring at 25-30%; data storage at 20-25%; business continuity at 15-20%; and infrastructure at 30-35%. These ranges describe relative emphasis. They are not exact question counts, and the upper ends do not add to a fixed blueprint total. Use them to allocate review time while still preparing across every listed skill.

How the current outline is organized

Identity, governance, and monitoring combines logging, authentication, authorization, secrets, management hierarchy, compliance, and identity governance. The breadth matters. An architecture decision may start with who signs in, but it also needs to address which resources are visible, how policy is applied, where operational events are routed, and how a team detects failures. Practice tracing data and permissions through the entire design rather than memorizing isolated service names.

Data storage covers relational data, semi-structured and unstructured data, and integration or analysis. Candidates should compare service fit, performance, scale, protection, and durability. Business continuity covers backup, recovery, and high availability for compute, databases, and storage. Infrastructure brings together compute, applications, migrations, and networks. A case can cross these areas: migration changes network paths, identity boundaries, recovery design, and data handling at the same time.

Format, score, and the limits of public information

Microsoft says most of its exams typically contain 40-60 questions, but the count varies and is not a published AZ-305 guarantee. Role-based exams can use case studies and may include labs. Microsoft does not publish an exam-specific lab list in advance. The general duration policy gives 100 minutes of exam time and 120 minutes of seat time when labs are absent, or 120 minutes of exam time and 140 minutes of seat time when labs may be present. The booked appointment and launch instructions are the practical source for a candidate’s sitting.

The published passing threshold is 700 on a 1,000-point scale. That does not mean Microsoft promises that 70 percent of raw responses is sufficient. No public conversion table gives a fixed number of correct answers. Treat the score as the decision result, then use domain feedback to guide further study. The exam page also links a free practice assessment and sandbox, which are useful for understanding question style and navigation but are not a substitute for architecture practice.

A sensible route through preparation

Start by reading the current skills guide from top to bottom and marking each task as familiar, explainable with reference, or unfamiliar. For an unfamiliar item, identify the decision it represents. “Recommend a solution for routing logs,” for example, asks what must be observed, where the records should go, which team needs them, and how long they must remain available. This turns a long product list into a set of design problems you can rehearse.

Use a scenario notebook with four columns: requirement, design choice, rejected alternative, and verification. A requirement might say that an application must survive a zone failure while meeting a specified recovery time. Your choice should name the architecture pattern and the assumptions it depends on. The rejected alternative shows that you understand the trade-off. Verification identifies the measurement or test that would prove the design works. This format exposes missing reasoning better than copying notes.

How to think like an architect in a scenario

Read constraints before selecting a service. Separate mandatory requirements from preferences, then identify measurable targets such as latency, recovery time, data loss tolerance, access scope, and operational ownership. If a question says data must remain available during a regional outage, a design that only protects against a local hardware failure does not meet the requirement. If a team cannot operate a complex platform, a technically capable but operationally unrealistic design may also be a poor fit.

Compare candidates against the same criteria. Ask whether the design meets the required availability, protects data, supports growth, can be monitored, and fits the organization’s operating model. Explicitly notice assumptions the prompt does not grant. Do not add a second region, premium service tier, or a new identity system simply because it sounds more resilient. Architecture answers are usually strongest when every component serves a stated constraint.

Credential, renewal, and study resources

Passing AZ-305 does not alone award Azure Solutions Architect Expert. Microsoft lists Azure Administrator Associate as a required certification as well as AZ-305. This distinction separates exam eligibility from credential completion: the certification page does not say that Azure Administrator Associate is needed merely to book AZ-305, but it is required to earn the Expert credential. Candidates should plan the sequence around the credential requirement and their existing certifications.

Microsoft describes role-based certifications as renewable through a free online assessment on Microsoft Learn. Renewal timing and the active assessment should be checked on the credential profile because maintenance windows can change. For study, begin with the official AZ-305 skills guide, then use its linked Azure documentation, Architecture Center, Cloud Adoption Framework, and Well-Architected guidance to investigate unfamiliar decisions. Use the official practice assessment as a diagnostic, not as a complete syllabus.

Identity, governance, and monitoring: connect the controls

The first domain is not a collection of unrelated administrative labels. It asks you to design how people and workloads authenticate, what actions they may take, how the environment is organized, and how operators observe it. For a scenario, draw the trust boundary before naming a product. Mark the human users, applications, resources, administrators, and any on-premises systems. Then ask which identity source is authoritative, how authentication is protected, and whether authorization applies to the management plane, the data plane, or both. A design that gives an application broad subscription permissions when it only needs to read a dataset has failed the least-privilege requirement even if the app can function.

Governance decisions should follow the organization’s ownership and policy model. A subscription boundary can separate billing, access, or workload environments; a resource group can group related resources for management; and a management group can help apply governance across subscriptions. The best hierarchy depends on delegated administration and compliance boundaries. Tags can add searchable metadata, but they do not replace access control or policy. When given several business units, environments, and regulatory boundaries, identify which dimensions need isolation and which only need consistent metadata. Choose the simplest structure that enforces the stated responsibilities.

Monitoring design starts with the operational questions. Which failures must an operator detect? Which logs are required for investigation or audit? Which team should receive each signal, and what retention or analysis needs apply? Separate collection from routing and alerting in your reasoning. A log destination may centralize records, while an alert rule turns a measured condition into an action. Do not assume that collecting every possible signal produces useful observability. A design should preserve evidence needed for operations and compliance while keeping ownership and response paths clear.

Data storage: begin with the shape and use of the data

For relational workloads, identify whether the application needs transactions, relational queries, predictable latency, elastic capacity, or compatibility with an existing database engine. The outline expects recommendations about where relational data should live, the service and compute tier, scalability, and protection. These are linked choices. A service that simplifies operations may fit a team with limited database administration capacity; a design that depends on a specific engine feature may narrow the choices. State the requirement that makes one option fit before comparing tiers.

Semi-structured and unstructured data call for a different analysis. Consider how the data is accessed, whether it is object-like or document-like, how it is partitioned, what consistency or query patterns matter, and how much durability and performance the workload needs. Avoid selecting a storage product only because the prompt says “large volume.” Volume alone does not reveal access frequency, latency, structure, or protection objectives. When the scenario describes analytics, separate the ingestion or integration path from the store that serves application transactions.

Data integration and analysis are also part of the current storage domain. Work backward from consumers: an operational application, reporting workflow, or analytical system may need different transformations and timing. Ask whether data moves in batches or in response to events, how failures are retried, and how the destination should be protected. For an exam scenario, do not introduce a complex pipeline unless the requirements need it. A design should account for movement and use of data, not merely name a database.

Business continuity: distinguish backup, recovery, and availability

High availability, backup, and disaster recovery solve related but different problems. Availability keeps a service usable through specified failures. Backup preserves recoverable copies that can be restored after deletion, corruption, or another loss event. Disaster recovery coordinates restoration or failover after a larger disruption. A solution can have redundant compute and still lack a suitable recovery copy; it can have backups and still take too long to restore service. When evaluating an answer, identify the failure it is designed to withstand and the recovery objective it can meet.

Translate recovery time objective into the maximum acceptable service interruption and recovery point objective into the acceptable amount of data loss. A strict target can require additional replication, standby capacity, or operational steps, each with cost and complexity. Do not assume a secondary region automatically meets a target: data replication mode, application dependencies, identity, DNS or routing, and operator procedures all affect recovery. The study guide expects recommendations across compute, databases, and unstructured data, so practice how protection differs by workload rather than memorizing one generic backup answer.

A usable continuity plan also needs evidence that restoration works. Ask how frequently a recovery path is tested, who decides to fail over, what consistency checks are performed, and how the system returns to normal operation. These operational details matter because a diagram can show a secondary environment without showing whether anyone can use it under pressure. On the exam, focus first on the published requirement and service constraints; then reject options that protect against the wrong failure or leave a critical dependency out of the recovery path.

Infrastructure: combine compute, application, network, and migration

The infrastructure domain has the largest published weight range, 30-35%, and spans compute, application architecture, migration, and networking. The candidate should choose a compute pattern from workload behavior. A continuously running service, a short event-triggered task, and a scheduled batch job have different scaling, execution, and operational needs. A virtual machine can provide operating-system control; a container can package an application consistently; a serverless option can reduce infrastructure management for an event-driven task. None is universally superior. Ask about state, runtime, control needs, scaling pattern, and support responsibilities.

Application architecture tasks include messaging, event-driven designs, API integration, caching, configuration management, and automated deployment. For a queue or event pattern, consider whether the producer and consumer need to operate independently and how the application handles delay, retries, duplicate delivery, or processing failure. Caching can reduce repeated reads or improve response time, but it introduces expiration and invalidation decisions. Configuration should be managed so that environment-specific settings and secrets are handled deliberately rather than embedded in application code.

Migration design begins with assessment. Inventory servers, applications, databases, dependencies, and data before choosing a move method. A rehost can preserve more of the current operating model while moving quickly, but it may retain operational work the organization hoped to remove. A platform migration can reduce that burden, but may require application changes and testing. The right recommendation depends on downtime tolerance, compatibility, compliance, dependencies, and the target operating model. For a database or unstructured-data move, include transfer, validation, cutover, and rollback in the plan.

Network choices likewise start with communication requirements. Draw which systems need to reach which services, whether the path is public or private, how on-premises connectivity is established, and where filtering or inspection belongs. Optimize for the stated performance and security needs without adding a network appliance or connection type that solves no stated problem. For load balancing and routing, identify whether the requirement concerns distributing requests, selecting a path, handling regional traffic, or exposing an application. Those needs can sound similar while calling for different layers of the design.

Worked scenario: modernize a customer order service

Imagine a retailer runs an order application on virtual machines in its own data center. The application writes relational order records, stores invoices as files, calls an inventory service, and must remain usable during a facility outage. The prompt adds two constraints: the operations team is small, and a short period of degraded service is acceptable while data loss must remain limited. This is deliberately a multi-domain design problem. Before selecting cloud services, list what must continue working, which information is authoritative, what interruption is tolerated, and who will operate the result.

First, map the application’s dependencies. The order service needs identity to reach its data, network connectivity to call inventory, and a route for customers to reach its endpoint. A move of only the virtual machines would not address how invoices are protected or how the database recovers. Inventory the application and its dependencies, then decide whether a staged rehost is a useful transition or whether a database or application change is required to meet the long-term operating objective. Keep the migration plan explicit about data synchronization, validation, cutover, and rollback.

Next, separate the relational records from invoice objects. Select storage according to transaction and access patterns, then design the protection and recovery mechanisms for each type. Determine how much data may be lost and how quickly service must return. If the business objective allows some interruption, a simpler restore path may be preferable to maintaining a costly active deployment in another location. If it does not, the architecture must supply a tested failover path. The scenario does not state exact regional capabilities, so a sound response names the needed behavior and verifies that the chosen configuration provides it.

Then decide how the application is exposed and monitored. Trace the request from the customer entry point to the application, from the application to its data, and from the application to inventory. Define the boundary between public traffic and internal service traffic. Identify logs and health signals that the small operations team can act on. Alerts should map to an owner and a response, not merely generate notifications. Store credentials or keys through an appropriate managed mechanism and grant workloads only the permissions they need.

Finally, compare the design with alternatives. Keeping every component on virtual machines may reduce initial change but could retain patching and scaling work. Moving everything to a new application architecture could improve some operational characteristics but increase migration risk and retraining. A staged approach can let the team move one bounded component, validate data and monitoring, then proceed. The exam is testing whether you make the requirements visible and choose trade-offs consistently, not whether you invent the most elaborate cloud diagram.

A focused six-week study sequence

A six-week plan is a planning example, not a required number of study hours. In week one, take the official practice assessment if available and review every skill in the current guide. Record unfamiliar tasks as design decisions, not just terms. In week two, focus on identity, governance, and monitoring. Draw a resource hierarchy for a fictional organization, identify user and workload identities, and sketch how logs reach an operator. Explain why each permission is scoped as it is.

In week three, study relational, semi-structured, and unstructured data decisions. For each scenario, note data shape, access pattern, performance target, scaling need, protection requirement, and integration path. In week four, compare availability, backup, and disaster recovery across compute, database, and storage scenarios. Write recovery objectives before selecting a design. In week five, work through compute, application architecture, migration, and networking. Use dependency diagrams to connect choices across domains.

Use the final week for mixed scenarios and review. Take another practice assessment or revisit missed questions after a delay. For each miss, classify the cause: misunderstood requirement, service confusion, forgotten constraint, or rushed reading. Rework the scenario from scratch and state why the strongest alternative fails. Set aside a short session for exam navigation in the sandbox and review the appointment instructions. If a domain remains weak, spend time on the exact objective rather than rereading all notes.

Using official materials without mistaking them for the whole exam

The study guide is the authoritative map of skills measured, not a complete catalog of every possible scenario. Its task bullets illustrate how Microsoft assesses the skill, and related topics may also appear. Start with that guide, follow its links into Azure documentation for service behavior, and use the Architecture Center and the Cloud Adoption and Well-Architected Frameworks to practice discussing trade-offs. Do not use an old course outline as the only map when the current English guide is dated April 17, 2026.

The free practice assessment gives examples of wording and question style and can help identify gaps. Microsoft cautions that it is not the same as the live exam and does not represent its length or complexity. The sandbox teaches interface mechanics. Both are preparation tools with defined limits. Pair them with scenario reasoning and practical experience where available. Avoid memorizing supposed live items or claiming that a third-party mock reproduces Microsoft’s protected content.