AZ-305 Study Plan

Begin with the exam’s design role

AZ-305 assesses design recommendations for Azure and hybrid solutions. It expects a candidate to connect business requirements to choices across compute, network, storage, monitoring and security. The current study guide describes advanced experience with IT operations, Azure administration, development and DevOps as useful background, but that profile is not a formal prerequisite to sit the exam.

The exam is not simply a service-name quiz. A scenario may present two technically possible solutions and ask which better meets a constraint such as recovery time, data protection, compliance, connectivity, scale or operational effort. A useful plan therefore needs product knowledge and practice explaining why one design fits while another misses a stated need.

Use the current English skills outline, measured as of April 17, 2026, as the organizing map. It assigns identity, governance and monitoring 25-30 percent; data storage 20-25 percent; business continuity 15-20 percent; and infrastructure 30-35 percent. Those are ranges, not guaranteed item counts. Localized exam versions may update later than English.

Take a four-domain diagnostic

Before building a calendar, work through one fresh design problem for each domain. Do not begin with a long exam simulation. The first task is to find the gaps. For every problem, write the requirement, your recommendation, the reason it meets the requirement and the strongest alternative you rejected.

For identity and governance, design access for a workload and an administrator. For data, choose a storage approach and protection strategy for a stated access pattern. For continuity, translate recovery time and recovery point objectives into backup, failover and availability choices. For infrastructure, choose compute, application architecture, migration or network options for the workload.

Score your diagnostic with a simple rubric: can you identify the primary constraint, choose a suitable design, explain the trade-off and identify an important dependency? A correct guess with no reasoning is a gap. A technically sound solution that ignores cost, compliance or recovery is also a gap. Record which step failed rather than just recording a percentage.

Keep examples original and vary the scenario. If you practiced a storage question about media files in one region, try a transactional database with a deletion recovery requirement in another. Repetition is useful when it tests the same principle under different details; memorizing one answer is not evidence that you can transfer the design.

Use a flexible eight-week sequence

An eight-week outline can organize preparation, but it is not a universal requirement. Candidates with current Azure architecture work may move more quickly through familiar domains. Candidates who have not designed hybrid networking, data platforms or recovery should extend those phases. Keep a week flexible for the weakest measured tasks instead of assuming each domain will take the same effort.

The schedule shows topic order, not a fixed number of daily hours. Choose a repeatable weekly routine around work and other obligations. A shorter block can cover a concept and one scenario. A longer block can compare architecture options and review an entire case. Track focused work and learning outputs, not time with a course window open.

Weeks 1 and 2: identity, governance and monitoring

Start by distinguishing authentication, identity management and authorization. For every access scenario, name the principal, target, operation and scope. Separate access to Azure resources from access to on-premises resources. Review approaches for managing secrets, certificates and keys, then consider how an organization governs identity over time.

Next, sketch management groups, subscriptions and resource groups for a fictional company with production and development teams. Add compliance requirements and a tagging strategy. Explain where a rule should apply and how exceptions should be handled. A tag can help classify and report; it is not by itself an enforcement control.

For monitoring, work from the question the organization needs to answer. Which logs are collected? Where are they routed? Which signals trigger an alert? Who responds? Separate platform health, resource metrics and application diagnostics. A monitoring design should produce actionable information without sending every signal to every team forever.

At the end of this phase, solve a scenario with a workload identity, a human support role and a compliance rule. Explain why each permission uses its scope and why a broad role would be unnecessary. Then add a logging requirement and identify the signal destination. This tests whether governance and operations fit the same architecture.

Weeks 3 and 4: data storage and integration

Classify data by shape and access pattern before choosing a service. For relational data, review service and compute tiers, scaling options and protection. For semi-structured or unstructured data, compare access frequency, performance, durability and cost. Do not choose a product because a prompt contains a familiar file extension; identify the application’s actual reads, writes and query needs.

Practice a decision table with columns for requirement, candidate service, benefit, constraint and unresolved question. A database choice can meet transaction needs but exceed the budget. A low-cost storage tier can increase retrieval time. A platform-managed database can reduce operations work but may not support every compatibility requirement.

Add protection to every data design. State what happens after accidental deletion, corruption, a regional outage and a service failure. Data durability, backup and high availability address related but distinct risks. Then draw how source data moves through integration and analytics. Include identity, network connectivity and data handling in the design, not only the processing service.

A useful exercise is to design a reporting platform for orders and product images. Orders need relational transactions and retention; images need durable object storage and access by the application; reports need an integration path that does not overload the production database. Explain the data flow and how each component is protected.

Week 5: business continuity

Write the recovery objectives before choosing a service. Recovery time objective is the acceptable time to restore service; recovery point objective is the acceptable amount of data loss. Those values drive backup frequency, replication, failover and test frequency. If the scenario gives no objective, identify what information the architect needs before claiming one design is sufficient.

Build separate plans for compute, databases and unstructured data. A VM image, a database backup and a file recovery process do not have identical restore steps. Include dependencies such as identity, secrets, DNS, network routes and application configuration. A restored server that cannot reach its database is not a recovered application.

Compare high availability with disaster recovery. Availability helps a workload continue during a failure within its design boundary. Disaster recovery restores service after a larger disruption, often with a different region or environment. Backup supports recovery to an earlier state. Replication may copy deletion or corruption, so it cannot automatically replace backup.

For practice, give a fictional service an RTO of one hour and an RPO of 15 minutes. Ask what backup cadence, replication behavior and failover procedure could meet the objectives, then list the assumptions. Change the RPO to one day and see which choices become unnecessary. The exercise trains you to let requirements determine architecture.

Weeks 6 and 7: infrastructure and connected designs

Compare VM, container, serverless and batch compute against workload behavior. Look at control, scaling, startup time, operating responsibility and dependencies. For application architecture, practice choosing messaging, event-driven integration, API integration, caching, configuration management and automated deployment based on coupling, throughput and failure behavior.

Migration work begins with assessment. Inventory servers, applications, data, dependencies and constraints. Decide what can move to IaaS, what fits PaaS and what needs modification. For databases and unstructured data, include compatibility, transfer time, cutover, validation and rollback considerations. A migration path has to work during transition as well as at the destination.

Networking should be traced end to end. Identify how Azure resources reach the internet, on-premises systems and one another. Review performance, security, load balancing and routing requirements. A private endpoint may need DNS configuration; a hub design may simplify connectivity but add shared failure and operations considerations. State which traffic must be allowed and which should remain private.

In the final mixed phase, combine domains. A new application might need private access to data, identity governance for administrators, zone-level availability, regional disaster recovery, logging and a deployment pipeline. Draw the components and dependencies, then check each requirement. A design that meets a single objective can still fail the whole scenario.

Weekly review and error log

After each study block, close the material and recall the design principle in your own words. Then answer a new scenario. If you cannot explain the difference between a backup and replication without notes, return to the concept. If you can explain it but choose the wrong option, practice reading the requirement and mapping it to the control.

Use an error log with four fields: scenario constraint, chosen answer, missed factor and next action. An entry might read: 'File recovery after deletion; chose geo-replication; replication can copy deletion; compare backup retention and point-in-time recovery in a fresh file scenario.' That note gives the next session a purpose.

Return to difficult concepts after a delay. Immediate rereading can feel fluent without producing recall. On the next review, reconstruct the design without notes and explain why an alternative fails. If the same error returns, simplify the scenario and learn the underlying service distinction before doing another timed case.

Mix old and new domains once the foundations are in place. An identity issue inside a migration case should not be solved as an isolated identity flashcard. The goal is to see how architecture choices affect security, operations and continuity together.

Timed practice and readiness

Microsoft does not publish a fixed AZ-305 question count, and labs may be present without exam-specific advance notice. Practice using the policy’s possible duration rather than assuming a precise item mix. Work through timed scenarios and track whether you can identify constraints, choose a design and explain trade-offs without spending too long on one uncertain detail.

A strong readiness signal is repeatable reasoning across all four domains. You can map business requirements to architecture, distinguish adjacent controls, explain cost or operational consequences and spot missing assumptions. Practice percentages can help track a question set, but Microsoft’s 700 scaled pass score is not a raw-percentage conversion.

Use a full practice assessment as a checkpoint, not a verdict. Review every miss and correct guess. If the result is weak in one domain, select specific tasks from the study guide and work on them. If performance varies widely between attempts, focus on consistency and reading the whole scenario before you schedule.

Leave a final review window for cross-domain comparisons and rest. Do not try to learn every Azure service in the last few days. Revisit your error log, explain key distinctions aloud and solve a small number of fresh cases. Make sure your appointment profile, language and exam date match your plan.

Example of a diagnostic-led adjustment

Ravi has worked with virtual networks and VMs but has not designed enterprise data platforms. The diagnostic shows strong infrastructure decisions and weak data protection and identity governance. The domain weights suggest infrastructure remains important, but Ravi should shift study time toward storage protection, database scaling and governance while maintaining infrastructure with mixed scenarios.

After two weeks, Ravi solves a data scenario about database availability but still recommends replication for accidental deletion. The next study task should compare failover and backup under deletion, corruption and regional outage cases. Another general practice test would show the gap again; a targeted contrast exercise can repair it.

A different candidate with strong storage experience and weaker hybrid networking would adjust the plan differently. The official weighting is common to both candidates, but individual study time should reflect what each can already do and which tasks remain uncertain.