Microsoft AZ-305: A Hands-On Study Plan

AZ-305 is Microsoft’s current Designing Microsoft Azure Infrastructure Solutions exam. The AZ-305 exam was updated on April 17, 2026 and measures identity, governance and monitoring; data storage; business continuity; and infrastructure design.

A hands-on plan should not treat the exam like an administrator lab course. The purpose of the labs is to make architectural tradeoffs visible. You should deploy enough Azure resources to understand behavior, then spend most of the time deciding which pattern fits a requirement and how the design changes when security, recovery, scale, cost, or operational constraints move.

Week 1: rebuild the AZ-104 foundation

The AZ-104 exam represents the operational foundation behind the architect credential. Review subscriptions, resource groups, identity, storage, compute, networking, monitoring, and governance until basic administration no longer slows architectural reasoning.

Build one small application and deploy it yourself. If you cannot explain how the resources are configured and monitored, you will struggle to recommend them under more complex enterprise requirements.

Week 2: design identity and governance across subscriptions

Create a management-group hierarchy, several subscriptions, RBAC assignments, Azure Policy definitions or initiatives, budgets, and a monitoring baseline. Decide what should be inherited and what should remain subscription-specific.

The internal Azure Policy and RBAC article is useful because policy and authorization solve different problems. Your design should explain both who can act and which configurations the platform permits.

Include privileged access and emergency administration. Architecture should distinguish routine roles from break-glass access and should log exceptional use clearly enough for later review.

Also define resource ownership through tags or organizational standards. Governance works better when cost, security, and operations teams can identify who is responsible for a resource without searching project documentation.

Week 3: compare data-storage architectures

Create a decision matrix for object storage, relational databases, globally distributed data, analytics, caching, and backup. Use one sample application and redesign the data layer for low latency, global distribution, strict consistency, analytical reporting, or long-term retention.

Do not deploy every service. Deploy enough to observe behavior, then practice recommendation. Architecture questions are often about choosing the least complex service that still meets the functional and nonfunctional requirements.

Add backup and restore to every storage choice. The primary service may be highly available while the organization still needs point-in-time recovery from corruption, accidental deletion, or application error.

Compare operational skill as well. A technically flexible database can be the wrong recommendation if it requires expertise the team does not have and a managed alternative satisfies the same business requirements.

Week 4: build a continuity plan from RTO and RPO

Define recovery-time and recovery-point objectives before choosing replication or backup. Draw application dependencies in recovery order: identity, DNS, network, secrets, compute, data, monitoring, and external services.

Run a tabletop exercise in which a zone or region becomes unavailable. Decide who triggers failover, what data state is acceptable, how users reconnect, and what evidence confirms recovery. This makes continuity operational rather than theoretical.

Add backup retention and accidental-deletion scenarios. High availability cannot recover a record that an application corrupted or a user deleted incorrectly. Continuity design needs both service resilience and recoverable historical state.

Measure recovery dependencies as well. A database may restore quickly while DNS, certificates, identity, or application configuration delays the actual return of service. End-to-end RTO should reflect the user outcome.

Week 5: deepen network architecture

The AZ-700 exam marks the deeper networking branch. For AZ-305, practice hub-spoke or virtual WAN concepts, hybrid connectivity, load balancing, private endpoints, DNS, routing, and inspection at the level needed to choose an enterprise pattern.

Draw the packet path for a private application from on-premises or another network to an Azure service. Label DNS resolution, route decisions, gateways, firewall or security controls, and failover. If the path is ambiguous, the design is not ready.

Add private DNS and one PaaS private endpoint to the lab. Test from a spoke, from another network, and from an on-premises-style location. This reveals how routing and name resolution must be designed together.

Then add one centralized inspection point and measure the new dependency. Architecture should explain what happens if the firewall or hub path is unavailable, not only how traffic flows when everything is healthy.

Week 6: compare compute and application-hosting models

Use VMs, App Service, Container Apps, Functions, or Kubernetes as examples and compare control, scale, deployment, state, networking, operations, and team skill. The architect should understand what operational responsibility the organization accepts with each choice.

Build one containerized application on a managed platform, then redesign it for Kubernetes only if the requirement justifies the extra control. This makes the cost of flexibility visible instead of treating Kubernetes as automatically more advanced.

Include deployment method and recovery in the comparison. A platform that scales easily but requires an unfamiliar release process may not be the best choice for the organization today.

State which responsibilities the cloud provider owns and which remain with the team for each compute option. That operational boundary is often the deciding architectural factor.

Week 7: add security architecture without using retired exam status incorrectly

The AZ-500 exam is retired, so use it only as historical skill context. Current Azure security architecture should be informed by identity, workload protection, network exposure, Key Vault, encryption, posture management, logging, and the modern SC-500 role where deeper security engineering is required.

For each workload component, identify the identity, network boundary, secret or key dependency, data sensitivity, and security evidence. This creates a coherent threat model rather than a collection of security services.

Practice secure administration separately from workload security. Privileged users may need just-in-time or tightly scoped access, while applications need managed identities and narrowly defined resource permissions. Those are different identity problems.

Add a security-monitoring path to every architecture. Decide where posture findings, platform logs, application telemetry, and security alerts are reviewed and which team owns remediation.

Week 8: conduct Well-Architected reviews

Review the same architecture for reliability, security, cost optimization, operational excellence, and performance. Record one risk and one recommended improvement for each area.

The existing AZ-305 architecture preparation can support review, but your own design notes are more valuable because they force you to defend tradeoffs instead of recognizing diagrams.

Run the review after changing one assumption such as doubling traffic or introducing a regulatory requirement. Note which recommendations remain valid and which must change. Good architecture adapts without being rebuilt from zero.

Keep the final risk register small and prioritized. Three material risks with owners and mitigations are more useful than a long list of generic concerns no team will act on.

Final practice: convert technical facts into recommendations

Take scenario questions and write the recommendation before looking at the answer choices. State the requirement, recommended pattern, why it fits, and what tradeoff it introduces. Then compare your reasoning with the options.

This technique prevents familiar Azure services from pulling you toward technically valid but contextually wrong answers. The architect is evaluated on the quality of the recommendation, not on the number of products remembered.

Use one architecture that contains a deliberate conflict, such as a low-cost requirement paired with strict recovery objectives. Write two viable designs and identify which requirement is more important. Architecture questions become much easier when you are comfortable stating that no option optimizes everything.

Finish each practice decision with the operational consequence. If you recommend a managed service, say what burden it removes; if you recommend a custom or highly controlled platform, say what new responsibility the organization accepts.

Exam week: use current Microsoft Learn as the scope authority.

Recheck the April 17, 2026 study guide, practice assessment, and role requirements. Focus on weak decisions rather than adding new services. If a topic is current but unfamiliar, build one small comparison or architecture note instead of a large new lab.

The Microsoft certification inventory can help with internal navigation. Your final AZ-305 preparation should remain anchored to current Microsoft objectives and the ability to translate business requirements into defensible Azure designs.

Recreate one architecture diagram from memory and annotate every major requirement it satisfies. If a resource exists without a requirement, challenge whether it belongs.

Finish by explaining the design to a non-specialist. Architects are expected to advise stakeholders, so clarity is part of the skill being validated.

Avoid treating every Azure service update as exam-critical. Use the official skills outline to decide whether a product change affects the design areas currently assessed. This keeps final-week preparation focused while still respecting the fast pace of the platform.

Your final confidence check should be simple: given a business requirement, can you identify the architectural decision, name two plausible options, and explain the tradeoff without opening the portal? If yes, you are practicing the right skill.

Do one final architecture case from a blank page and identify the requirement that justifies every major Azure component. Then state the main residual risk and the team that owns it. This combines technical design with governance and operational accountability.

That final explanation is the architect-level readiness test.

• Category: All Certifications Certifications