Microsoft AZ-305: Practical Architecture Exercises

Microsoft AZ-305 tests architecture judgment, so practical preparation should produce design decisions rather than deployment screenshots. The most useful exercises begin with business requirements, force you to choose among plausible Azure patterns, and then change a constraint to see whether the design still holds.

On October 6, 2026, AZ-305 remains current, with Microsoft’s April 17, 2026 skills blueprint. The exercises below focus on the architect’s responsibility to translate requirements into designs across identity, governance, monitoring, data, compute, networking, integration, and business continuity.

Translate requirements into architecture

Architecture review should include the strongest credible alternative, not a deliberately weak option. Explain what the rejected design would do well, which requirement it fails, and what operational consequence follows from the selected design. That comparison is where architecture judgment becomes visible.

Exercise 1: turn prose into architecture constraints

A scenario may mention availability, regulatory boundaries, recovery objectives, latency, operational staffing, and cost without labeling them as architecture requirements. Take a one-page business brief and rewrite it into functional requirements, quality attributes, hard constraints, assumptions, and unresolved questions before naming a service.

Review exercise 1: turn prose into architecture constraints by writing down the intended outcome, the control that owns it, and the first piece of evidence you would inspect if it failed. The evidence is a requirement table that makes conflicts visible—for example, aggressive recovery objectives against a low-cost constraint—before the design hides them. Then alter one condition in the scenario and compare the new decision with the original so the note captures reasoning rather than recall.

Exercise 2: design the control plane

Identity, subscription structure, management groups, Azure Policy, RBAC, tagging, and monitoring define the control plane that workloads inherit. Design governance for two business units with different deployment freedom, then justify which controls belong at tenant, management-group, subscription, resource-group, or resource scope.

Azure Policy, locks, and resource governance expose the difference between preventive controls and operational ownership. Apply a location or configuration rule, protect a critical resource from accidental deletion, and then explain which control enforces compliance, which protects against change, and which administrator remains responsible for the workload.

Choose data, compute, and integration patterns

Data exercises should include a workload whose access pattern changes over time. Start with a regional transactional service, then add global reads, stricter residency requirements, or an analytical consumer. Revisit consistency, replication, partitioning, backup, and integration choices. The exercise shows whether the original design was driven by data behavior or merely by familiarity with one Azure database.

Exercise 3: choose a data architecture

Data design is a tradeoff among data model, consistency, scale, query pattern, availability, security, recovery, and integration needs. Given transactional, document, and analytical workloads, choose storage/database patterns and explain why the alternatives create unnecessary complexity or fail a requirement.

Your result should state partitioning or scaling assumptions, backup/recovery expectations, and the monitoring signal that would reveal the choice is failing.

Exercise 4: choose compute from workload behavior

Virtual machines, containers, App Service, functions, and other compute options differ in control, elasticity, operations, deployment model, and runtime constraints. Re-design the same application twice: once for a small operations team that prioritizes managed services and once for a regulated environment that requires more platform control.

The point is not to identify one universally best service; it is to show which requirement changes the compute decision and what operational burden follows.

Design connectivity and resilience

Network exercises should follow traffic end to end. Draw user, application, data, management, and hybrid paths; include DNS, routing, private access, filtering, and inspection. Then introduce an asymmetric route or name-resolution failure. The design is stronger when you can identify where the path breaks without immediately changing a firewall or assuming every private-connectivity problem is a routing problem.

Continuity exercises should include recovery authority and return-to-normal operations. Define who declares a disaster, which dependencies recover first, how data consistency is validated, when traffic moves, and how failback is performed. A secondary environment coming online is not the end of recovery if the organization cannot prove that users are receiving correct service and that normal operations can be restored safely.

Exercise 5: design network boundaries and flows

Architecture questions often hide the network requirement inside phrases such as private access, hybrid connectivity, segmentation, inbound protection, or global reach. Draw the traffic path for users, application tiers, data services, management traffic, and on-premises dependencies, then identify where name resolution, routing, filtering, and inspection occur.

Your diagram should expose transitive-routing assumptions, single points of failure, and trust boundaries before a product choice makes them harder to see. Those five items make the exercise 5: design network boundaries and flows review more valuable than copied documentation because they explain how the decision operates.

Exercise 6: select an integration pattern

Integration design should start with coupling, delivery guarantees, ordering, throughput, retries, and consumer independence. Messaging and event-driven architecture becomes relevant when a queue, topic, or event stream improves resilience or decouples producers and consumers; it should not be chosen simply because asynchronous services appear in the scenario.

Record how retries, poison messages, duplicate handling, observability, and ownership work instead of stopping at the service name.

Exercise 7: design for business continuity

A design is incomplete until it explains what happens when a region, service, dependency, or data copy becomes unavailable. AZ-305 business continuity and disaster recovery separates availability from recoverability by tying redundancy, replication, backup, failover, and restore procedures to explicit RTO and RPO targets.

Evidence should include failure triggers, recovery authority, data-loss expectations, and how the organization proves that the runbook works. For this exercise 7: design for business continuity checklist, define what proves the control is working, what proves it is not, and which neighboring layer should be investigated next.

Validate observability and defend the tradeoff

Add one cost constraint to the final architecture review. Compare whether the selected redundancy, managed-service choice, data movement, or observability design still meets the business requirement at the expected scale. Cost should not override correctness, but it should be visible as one of the tradeoffs the architect is expected to defend.

Observability belongs in every exercise, not only the monitoring one. For each major component, identify the signal that proves health, the alert that indicates user impact, and the evidence required to distinguish platform failure from workload failure. A design that cannot be operated or diagnosed is incomplete.

Finish one architecture lab by presenting the design to an imaginary operations team. Explain which signals prove availability, which alerts indicate user impact, which manual steps remain, and what the team should do when one dependency fails. If the design cannot be operated without the original architect, the exercise has exposed an ownership or observability gap that should be corrected before the architecture is considered complete.

Exercise 8: build observability into the design

An architect should define what must be visible before the system is deployed. Azure Monitor and Log Analytics observability is not an afterthought; telemetry design determines whether operators can confirm service health, detect degradation, and investigate dependencies. For each critical component, identify health metrics, logs, traces, alerts, diagnostic settings, retention needs, and who acts on the signal.

A good design avoids both blind spots and indiscriminate logging that creates cost without improving decisions.

Exercise 9: defend the tradeoff

The final practice should resemble an architecture review: present the selected design, the strongest rejected alternative, the assumptions that would change the decision, and the evidence required after deployment. Map the result to the responsibilities behind Microsoft Certified: Azure Solutions Architect Expert, not merely to a list of Azure services.

If you can defend the tradeoff under questioning and revise it when a constraint changes, you are practicing the skill AZ-305 is meant to measure.

Run the exercises with changing constraints rather than fixed answers. If the first design assumes one region, change the recovery target. If it assumes public endpoints, add a private-connectivity requirement. If it assumes a large operations team, reduce staffing. The value of the exercise is seeing which decisions are stable and which depend on assumptions that may change.

Repeat one exercise with a deliberately constrained operations team. A design that depends on constant manual failover, frequent exception handling, or deep specialist intervention may be technically correct but operationally unrealistic. Architecture choices should reflect who will run the system after handoff, because managed services, automation, observability, and simpler failure modes can matter as much as feature breadth.

Use a short decision record after every exercise: requirement, selected pattern, strongest alternative, tradeoff, failure signal, and review trigger. The record forces the exercise to produce an architecture decision rather than a diagram. It also makes later comparison easier when a changed requirement causes only one part of the design to move.

Finish the architecture exercises with a review in which two options are both technically valid. Compare them on recovery behavior, operational burden, identity dependencies, network path, observability, and the team that must support the design after handoff. Then introduce a changed constraint—such as a shorter RTO, stricter residency requirement, or smaller operations team—and explain which decision changes and which remains intact. The goal is to show that the architecture follows requirements and quality attributes rather than a preferred Azure service.