AZ-305 Exam Domains
The current AZ-305 outline assigns 25-30% to identity, governance and monitoring; 20-25% to data storage; 15-20% to business continuity; and 30-35% to infrastructure.
- It tests design recommendations across cloud and hybrid workloads, including security, data, recovery, compute, application architecture, migration and networking.
On this page8 sections
Current AZ-305 weightings
The AZ-305 study guide lists four skill domains, measured on the English exam as of April 17, 2026. Each percentage is a range. The ranges describe relative exam emphasis; they do not guarantee an exact item count or a fixed number of questions in every session.
| Domain | Weight range | Design focus |
|---|---|---|
| Design identity, governance, and monitoring solutions | 25-30% | Authentication, authorization, governance, logging and monitoring |
| Design data storage solutions | 20-25% | Relational, semi-structured and unstructured data, integration and analytics |
| Design business continuity solutions | 15-20% | Backup, disaster recovery and high availability |
| Design infrastructure solutions | 30-35% | Compute, application architecture, migration and networking |
Infrastructure is the largest single domain by published range, but the other three together form most of the exam. Do not spend nearly all your time on virtual machines and networks. Identity and governance, data design and continuity each have their own objectives and require distinct reasoning.
The English exam outline is updated first. Microsoft says localized exam versions are generally updated about eight weeks later, though timing can vary. If you plan to test in another language near an update, use the skills outline and date applicable to the offered language. A page translation or an older study guide may lag the English version.
Identity, governance and monitoring: 25-30%
This domain asks you to design authentication, identity management and authorization for Azure and on-premises resources. It also covers how to manage secrets, certificates and keys. Governance tasks include structuring management groups, subscriptions and resource groups; choosing tagging strategies; managing compliance; and designing identity governance. Logging and monitoring objectives include selecting solutions for logs, routing and monitoring.
A useful way to reason through access scenarios is to identify the principal, target resource, required action and scope. A workload identity that reads objects in one storage account has a different authorization need from an administrator who deploys resources across a subscription. The design should give enough access to complete the task while containing accidental or malicious changes.
For governance, start with business boundaries: billing, ownership, compliance, environment and operations. A management-group hierarchy can apply policy across subscriptions; a resource group organizes related resources; tags support classification and reporting but do not enforce settings by themselves. The right design depends on who needs to manage what and where a rule must apply.
Monitoring design begins with the signal and its destination. Decide which logs or metrics matter, where they should be routed and who will respond to an alert. A platform health event is different from application latency; the design should observe the condition that matches the requirement. Logging every signal without retention, access or routing decisions can create cost and noise without improving response.
Data storage: 20-25%
The data domain covers relational storage, semi-structured and unstructured data, data integration and data analysis. For relational data, objectives include choosing a service and service or compute tier, planning scalability and protecting data. For other data, the guide asks you to balance features, performance and cost while selecting protection and durability. It also includes data integration and analytics recommendations.
Start with the data shape and workload. Relational data has defined relationships and may require transactions, constraints or structured queries. Semi-structured data can include records with flexible fields. Unstructured data may include files or media. These categories do not dictate one service in every case; access patterns, consistency, query needs and operational burden matter too.
Then identify read and write patterns, data growth, latency, availability and cost constraints. A database tier that handles current throughput may not meet peak demand or future scaling needs. Data protection should align with recovery objectives, not just storage redundancy. Integration and analysis need a flow from source systems to processing and reporting, with security and governance across each step.
A design answer should explain its trade-off. A highly available database may cost more. A cheaper storage tier may have different access latency. A managed service can reduce operations work but may impose feature or compatibility constraints. If an application needs relational transactions and a known schema, a document store is not automatically simpler just because its data is JSON.
Business continuity: 15-20%
This domain includes backup and disaster recovery for Azure and hybrid workloads, as well as high availability for compute, relational data and semi-structured or unstructured data. Microsoft emphasizes recovery objectives. The design needs to reflect how much data loss and service interruption the business can accept.
Recovery time objective (RTO) describes how long recovery may take. Recovery point objective (RPO) describes how much recent data the organization can afford to lose. These objectives guide choices such as backup frequency, replication, failover architecture and restore procedures. A system that can be restored from last week’s backup may be insufficient when the business can lose only a few minutes of data.
Separate high availability from backup. Redundancy can keep a service running through a component or zone failure, but it may replicate corruption or deletion. A backup provides a recovery point, but a restore can take time. Disaster recovery may involve failover to another region, while backup protects against a different set of failures. A sound design states which risk each control addresses.
For hybrid workloads, account for dependencies outside Azure: identity, connectivity, DNS, data movement and operational ownership. A recovery plan that restores compute but not credentials or network reachability may fail in practice. Test the recovery sequence and note which teams or decisions are required.
Infrastructure: 30-35%
Infrastructure design includes compute, application architecture, migrations and network solutions. Compute objectives cover selecting components for workload requirements and recommending virtual-machine, container, serverless or batch-processing designs. Application architecture includes messaging, event-driven patterns, API integration, caching, configuration management and automated deployment.
Migration tasks ask you to evaluate on-premises servers, data and applications; use the Cloud Adoption Framework for Azure; and recommend migration paths for IaaS, PaaS, databases and unstructured data. Networking includes connectivity to the internet and on-premises networks, performance and security optimization, and load balancing and routing.
Start infrastructure design with workload characteristics. A long-running stateful service, bursty event handler and scheduled batch job may need different compute. Application architecture should account for coupling, message delivery, retries, throughput and latency. A cache can reduce repeated reads but adds invalidation and consistency decisions. Automated deployment can improve repeatability but must fit the organization’s release controls.
Migration questions often test whether the existing environment can move as-is or needs modernization. Inventory dependencies and operating constraints first. A database migration may require compatibility assessment and a cutover plan; an application migration may need refactoring for platform services. Network design must preserve connectivity and security during the transition, not only after it.
How the weights should guide study
Use the ranges to allocate attention, not to calculate an exact number of questions. If you have 20 study sessions, infrastructure may warrant somewhat more sessions than a smaller domain, but the number should reflect your baseline. A candidate with strong networking and compute experience may need more work in data protection; another may need to build identity and governance from the ground up.
Build a matrix with the four domains and their tasks. For each task, mark whether you can explain the service choice, apply it to a scenario and describe an alternative’s limitation. A topic is not ready merely because its name is familiar. The exam asks for recommendations, so the candidate must connect a requirement to a design.
Use a diagnostic scenario in each domain. For identity, design access for a workload and a human administrator separately. For data, choose storage and protection for an access pattern. For continuity, map RTO and RPO to backup and failover. For infrastructure, choose a compute and network design for the workload. Record the decision and the constraint that drove it.
After review, revisit domains according to errors rather than following the percentage ranges mechanically. If practice exposes repeated confusion in data protection, spend more time there even though its range is below infrastructure. If you already design networks at work, short maintenance sessions may be enough while you strengthen application architecture or migration planning.
Original weighting example
Suppose a learner has 12 study blocks. The domain ranges do not translate into exact question counts, but can inform an initial plan: four blocks for infrastructure, three for identity and governance, three for data storage, and two for business continuity. After a diagnostic, the learner finds a serious RPO/RTO gap and a strong compute background. Shifting one infrastructure block to continuity is a reasoned adjustment, not a violation of the blueprint.
This allocation is an example, not an official Microsoft schedule. It gives the largest domain slightly more initial time while preserving coverage across every domain. The diagnostic then personalizes the plan. A candidate with a different background should use different allocations.
Keep the outline current
Microsoft updates role-based exams to reflect the skills required for the role. The current AZ-305 English skills outline is measured as of April 17, 2026. Use that version’s task list when building a study plan. The outline says its bullets illustrate how skills are assessed and that related topics may also appear, so do not treat examples as a complete list of every possible scenario.
Most questions cover generally available features, although commonly used preview features may appear. Learn the stable design principles and the current service capabilities. Avoid overfocusing on a single preview feature or a prep provider’s predicted item list. If a localized version has not yet caught up to the English update, confirm which language and skills guide apply to your appointment.
Common questions
What are the AZ-305 domains?
Identity, governance and monitoring; data storage; business continuity; and infrastructure.
Which domain has the largest weight?
Infrastructure at 30-35 percent. The exact item count varies and is not published.
When was the current English outline updated?
Skills measured as of April 17, 2026.
Do domain percentages give exact question counts?
No. They are weight ranges, and Microsoft does not publish a fixed AZ-305 item count.
Can I study only the largest domains?
That leaves the other objectives uncovered. Use the weights to prioritize, but prepare across all four domains.