Microsoft AZ-305 Azure Solutions Architect Practical Preparation: Scenarios, Exercises, and Skills to Rehearse

 

Practical preparation for AZ-305 does not require building every Azure service. It requires rehearsing the decisions an Azure solutions architect makes: translating requirements into boundaries, selecting among plausible designs, exposing trade-offs, testing failure conditions, and validating the result with operational evidence. Microsoft’s current AZ-305 scope spans identity and governance, monitoring, data storage, business continuity, compute, networking, migration, integration, and application architecture, so exercises should deliberately cross service categories rather than isolate them.

The best lab is often a small one with a written architecture brief. Build enough of the environment to prove a design assumption, then inject a change: tighter recovery objectives, a second region, an external identity boundary, a private-connectivity requirement, a sudden increase in telemetry, or a workload that can no longer tolerate a chosen consistency model. The goal is not to collect screenshots. It is to learn which requirement moved the architecture and how you would prove the revised design works.

For AZ-305 practical architecture rehearsal, use the current AZ-305 blueprint as a constraint map rather than a product checklist. In the AZ-305 practical architecture rehearsal context, the April 17, 2026 English blueprint assigns 25-30% to identity, governance, and monitoring; 20-25% to data storage; 15-20% to business continuity; and 30-35% to infrastructure solutions. Use the AZ-305 exam page for ExamSnap’s exam context while practicing AZ-305 practical architecture rehearsal, but make every exercise translate requirements into a design, identify the trade-off that removes the nearest alternative, and define evidence that would verify the architecture. Treat AZ-305 practical architecture rehearsal as an architectural judgment exercise rather than a test of isolated Azure product recall.

Exercise 1: design an identity and governance hierarchy

Create a fictional organization with multiple business units, regions, environments, and compliance needs. Decide how tenants, management groups, subscriptions, resource groups, roles, policy, and naming or tagging standards should work together.

Treat Exercise 1: design an identity and governance hierarchy as a chain of cause and effect. The chain should make organizational hierarchy, tenant strategy, management groups, subscriptions, RBAC, policy, privileged access, and external identities explicit and should show where a wrong choice first changes the resulting state.

A useful rehearsal case is this: Build a fictional enterprise with a parent company, regulated subsidiary, development teams, and a newly acquired partner tenant. After that, deliberately break one assumption. Re-evaluate the design from the changed facts rather than trying to preserve your first answer, in this architecture exercise.

Troubleshooting should follow the same structure. Start with the expected evidence: architecture diagram, role assignments, policy scope, privileged-access workflow, external-user lifecycle, and escalation model. Do not compensate at a downstream layer for a defect that originates upstream; adding a broader role does not fix a scope model, adding another alert does not fix an unowned response process, and adding regional redundancy does not fix an undefined recovery requirement, in this architecture exercise. This sequence keeps remediation aligned with root cause.

For study, the measurable objective is to rehearse changing one boundary at a time and defend why the new design still limits privilege and supports governance. Explain both without answer options.

Exercise 2: build an observability architecture

Candidates often know the vocabulary here but still lose points because they cannot apply it under a constraint, in this architecture exercise. Design what application, infrastructure, security, and platform signals must be collected, where they should be analyzed, who needs access, and how alerts become action.

Introduce a requirement for long retention and a second requirement for fast operational troubleshooting. Compare whether the same data path should satisfy both purposes or whether separate tiers are more appropriate.

Exercise 3: choose a data platform from workload characteristics

Describe the data model, transaction pattern, read/write ratio, consistency needs, scale, region requirements, analytics needs, backup expectations, and cost constraints before naming a service.

Change the workload from relational transactions to globally distributed document reads and observe how the architecture decision changes.

For Exercise 3: choose a data platform from workload characteristics, build the decision around workload decomposition, relational versus nonrelational fit, object storage, analytical requirements, replication, encryption, and lifecycle. Write the requirement first, then identify the object or boundary the decision can actually change, in the section on Exercise 3: choose a data platform from workload characteristics. If your explanation depends on a slogan such as ‘always use the most resilient option’ or ‘the newest source should win,’ replace it with a conditional rule that names the assumptions that make the choice valid, in the section on Exercise 3: choose a data platform from workload characteristics.

Choose data services for orders, product catalog, clickstream analytics, and media files that have different consistency and access patterns. Identify the actors, authoritative sources or control scopes, the state before the change, the intended state after the change, and the constraint that eliminates otherwise reasonable alternatives, in the section on Exercise 3: choose a data platform from workload characteristics. Then change one variable and solve it again. This second pass matters because AZ-305 scenarios often reward candidates who understand boundaries and side effects, not those who recognize the wording of a familiar example, in the section on Exercise 3: choose a data platform from workload characteristics.

For this topic, inspect decision matrix, throughput and latency assumptions, consistency requirement, replication/failover choice, access controls, and lifecycle policy. Decide in advance what would count as confirming evidence and what would falsify your design, in the section on Exercise 3: choose a data platform from workload characteristics. A green dashboard or successful deployment is not enough when the question is about identity, authority, relationship meaning, recovery, or governance, in this architecture exercise, in the section on Exercise 3: choose a data platform from workload characteristics. If the observed state differs from your prediction, trace backward through the sequence until you find the first assumption that failed; that turns troubleshooting into a method instead of random clicking, in the section on Exercise 3: choose a data platform from workload characteristics.

A practical mastery target for Exercise 3: choose a data platform from workload characteristics is to force each storage recommendation to cite workload characteristics and one rejected alternative with a concrete reason. Create a one-page note with four fields: requirement, decision, rejected alternative, and proof, in the section on Exercise 3: choose a data platform from workload characteristics. Add one counterexample that looks similar but should lead to a different choice, in this architecture exercise, in the section on Exercise 3: choose a data platform from workload characteristics. Revisit the note after at least a day and reconstruct it without looking, in the section on Exercise 3: choose a data platform from workload characteristics.

Exercise 4: design for regional failure

A durable mental model for Exercise 4: design for regional failure starts with variables, not vocabulary. The variables here are zone redundancy, regional replication, failover trigger, data consistency, DNS/traffic routing, dependency recovery, and runbook ownership. Put them on a small diagram or decision table so that scope and ownership stay visible, in this architecture exercise.

Consider the following working scenario: Design a web platform that must continue through a zone failure and restore service in a secondary region after a full regional outage. Before deciding anything, write two columns: facts supplied by the scenario and assumptions you are tempted to add, in this architecture exercise. Make the decision using only the facts that are actually present.

The evidence layer should be equally specific. Useful confirmation for Exercise 4: design for regional failure includes health probes, replication state, failover sequence, DNS/traffic-manager behavior, dependency readiness, and recovery validation.

A practical mastery test is whether you can practice drawing both the steady-state and failure-state architecture, including what remains unavailable during each transition. Then shorten it to three sentences without losing the decisive constraint.

Exercise 5: compare compute models

If the answer still feels like a slogan, push one level deeper and ask which state changes, which component decides, and what evidence appears, in this architecture exercise. Add a constraint that the team has limited platform operations capacity. Re-evaluate which option best reduces management burden without violating application requirements.

Treat Exercise 5: compare compute models as a chain of cause and effect. The chain should make VMs, containers, serverless, platform services, scale behavior, patching, startup time, state, networking, and operator skill explicit and should show where a wrong choice first changes the resulting state.

A useful rehearsal case is this: Compare hosting options for a legacy stateful service, a bursty event processor, and a containerized API with rapid deployment requirements. After that, deliberately break one assumption. Change a trust boundary, tighten an RTO, remove a region, alter a data access pattern, reduce available privilege, or change the operating owner, in this architecture exercise.

Troubleshooting should follow the same structure. Start with the expected evidence: deployment pipeline, autoscaling behavior, state handling, patch responsibility, network integration, and observability. If the outcome is wrong, test the earliest controllable layer first and move outward, in this architecture exercise. This sequence keeps remediation aligned with root cause.

For study, the measurable objective is to choose compute per workload and include operational responsibility as a first-class design constraint. Build two variants: one where the preferred mechanism is clearly correct and another where the same mechanism becomes wrong because a prerequisite disappears, in this architecture exercise. Explain both without answer options.

Exercise 6: design hybrid and private connectivity

Map address spaces, DNS, routing, private endpoints, firewalls, VPN or dedicated connectivity, and the trust boundaries between on-premises and Azure networks.

Introduce overlapping address space or a requirement that a platform service must never use a public endpoint. Redesign the path and state which operational dependencies change.

Exercise 7: perform an architecture review

Take one of your own diagrams and argue against it from the perspective of a security lead, finance lead, operations engineer, and application owner. Record which assumptions each person exposes.

For Exercise 7: perform an architecture review, build the decision around requirements coverage, assumptions, single points of failure, security boundaries, operational ownership, cost, scalability, and recovery. Write the requirement first, then identify the object or boundary the decision can actually change, in the section on Exercise 7: perform an architecture review. If your explanation depends on a slogan such as ‘always use the most resilient option’ or ‘the newest source should win,’ replace it with a conditional rule that names the assumptions that make the choice valid, in the section on Exercise 7: perform an architecture review.

Review a proposed reference design that looks technically sound but has no documented RTO, no owner for alerts, and broad subscription-level contributor access. Identify the actors, authoritative sources or control scopes, the state before the change, the intended state after the change, and the constraint that eliminates otherwise reasonable alternatives, in the section on Exercise 7: perform an architecture review. Then change one variable and solve it again. This second pass matters because AZ-305 scenarios often reward candidates who understand boundaries and side effects, not those who recognize the wording of a familiar example, in the section on Exercise 7: perform an architecture review.

For this topic, inspect requirements-to-component matrix, risk register, role assignments, policy scope, recovery tests, cost estimates, and unresolved assumptions. Decide in advance what would count as confirming evidence and what would falsify your design, in the section on Exercise 7: perform an architecture review. A green dashboard or successful deployment is not enough when the question is about identity, authority, relationship meaning, recovery, or governance, in this architecture exercise, in the section on Exercise 7: perform an architecture review. If the observed state differs from your prediction, trace backward through the sequence until you find the first assumption that failed; that turns troubleshooting into a method instead of random clicking, in the section on Exercise 7: perform an architecture review.

A practical mastery target for Exercise 7: perform an architecture review is to practice finding omissions, not only wrong components; architecture quality often depends on what the diagram forgot to show. Create a one-page note with four fields: requirement, decision, rejected alternative, and proof, in the section on Exercise 7: perform an architecture review. Add one counterexample that looks similar but should lead to a different choice, in this architecture exercise, in the section on Exercise 7: perform an architecture review. Revisit the note after at least a day and reconstruct it without looking, in the section on Exercise 7: perform an architecture review.

Exercise 8: practice concise design justification

A durable mental model for Exercise 8: practice concise design justification starts with variables, not vocabulary. The variables here are requirement, chosen design, rejected alternative, trade-off, risk, mitigation, and verification. Ask which input is authoritative, which boundary contains the change, which dependency can invalidate the design, and what the downstream process expects, in this architecture exercise.

Consider the following working scenario: Explain in five sentences why a private endpoint plus centralized DNS design is preferred over public endpoints restricted only by IP rules for a regulated workload.

The evidence layer should be equally specific. Useful confirmation for Exercise 8: practice concise design justification includes concise decision record, explicit constraint, rejected option, measurable outcome, and test method.

A practical mastery test is whether you can rehearse short defensible explanations so time pressure does not turn a correct design into vague feature listing.

Turn architecture exercises into deliberate AZ-305 practice

Final perspective on practical architecture rehearsal

Integrated Azure architecture exercise

Integrated scenario: A software company is rebuilding a customer platform for global scale and asks you to design identity, governance, data, compute, connectivity, monitoring, and regional recovery as one architecture. Begin with a requirements sheet instead of a service diagram. Then map those requirements to design domains.

Use an architecture exercise protocol

Write every practical exercise as a one-page brief with seven fields: business outcome, hard constraints, quality attributes, existing environment, proposed design, rejected alternative, and verification plan. The brief should be complete before implementation begins. This prevents the lab from becoming a sequence of portal clicks and forces you to decide what the environment is supposed to prove. If a design cannot be explained clearly on paper, building it usually adds activity without resolving the architectural uncertainty.

After implementation, compare evidence with the prediction. For networking, inspect route and connectivity behavior; for identity, effective permissions and sign-in or access evidence; for monitoring, data arrival, alert routing, and retention; for continuity, failover behavior and measured recovery; for data, latency, replication, consistency, and backup outcomes. Record unexpected observations as design feedback rather than treating a successful deployment as proof that every requirement is satisfied.

Inject failures instead of only proving the happy path

A lab becomes architectural when it includes failure. Disable a dependency, remove a route, break a credential, exceed a threshold, revoke an identity, or simulate region loss. Before the test, write which component should detect the failure, which control should limit impact, who should receive the signal, and what recovery sequence should follow. After the test, compare the observed blast radius and recovery time with the design objective.

Failure injection also exposes hidden operational cost. A design may be highly available yet require manual steps no team owns; a private network may be secure yet impossible to troubleshoot with the chosen telemetry; a data platform may meet performance goals yet violate the recovery objective. Those findings are exactly the trade-offs AZ-305 preparation should surface. The purpose of hands-on work is not to prove Azure can deploy a resource; it is to prove your architecture assumptions survive contact with operations.

A four-exercise architecture rehearsal sequence

Exercise one should focus on boundaries. Design a multi-subscription environment for a regulated company, identify tenant and management boundaries, assign least-privilege access, and decide where policy should inherit. Do not build everything. Draw the hierarchy, implement one representative control, and verify effective scope. Then change one assumption by adding an acquired tenant or partner identity. Record which parts of the original design must change and which remain valid.

Exercise two should focus on data and continuity. Choose a workload with explicit consistency, latency, durability, RTO, and RPO requirements. Compare at least two data-platform patterns and explain why one loses. Then simulate a failure or use documented behavior to walk through recovery. Measure which requirement is satisfied by replication, which by backup, which by application design, and who owns failover. This prevents the common mistake of treating ‘high availability’ as a single feature rather than a set of behaviors.

Exercise three should focus on hybrid networking and security. Connect a fictional on-premises environment to Azure, define route and name-resolution expectations, and specify which traffic must remain private. Add a requirement for controlled internet egress or an inspection layer. Draw packet paths for normal and failed conditions, then identify the telemetry needed to distinguish a routing problem from a name-resolution, firewall, or identity problem. The important output is the troubleshooting model, not the number of resources deployed.

Exercise four should focus on observability and operations. Define service-level questions first, then choose what metrics, logs, traces, activity records, and security signals answer them. Specify collection, routing, retention, access, alert conditions, and ownership. Inject one signal failure or a fivefold increase in telemetry volume. Decide whether the architecture still meets cost, retention, and response objectives. This turns monitoring into part of the design rather than a post-deployment checkbox.

After each exercise, write a short design defense containing the requirement, selected design, rejected alternative, trade-off, failure behavior, and verification evidence. Revisit it several days later and challenge one assumption without rebuilding the entire lab. The repetition should be in the reasoning method, not in the architecture. By the end of the sequence, you should have four materially different cases that train the same professional habit: translate requirements into a design you can defend and verify.

For focused follow-up, use AZ-305 exam page, AZ-305 readiness matrix, and cloud lab guide. Keep those references secondary to the requirement-driven reasoning in the article.

How to review a lab like an architect

After a hands-on exercise, do not end at ‘deployment succeeded.’ Compare the environment with the original brief and ask whether every requirement has evidence. If the requirement was least privilege, inspect effective access. If it was private connectivity, trace the actual path and name-resolution behavior. If it was a recovery objective, measure or reason through the end-to-end restoration sequence. If it was monitoring, confirm that the expected signal arrives, an alert routes correctly, and the responder has enough context to act.

Then review the rejected alternative. Many labs teach only the selected path, which can create the impression that the chosen service is universally correct. Build or reason through the nearest alternative and identify the requirement that causes it to lose. A public endpoint might be simpler but violate the trust boundary; a different data platform might scale well but fail a consistency requirement; active-active regional design might exceed the business need and budget. Architecture skill grows from these comparisons.

Document assumptions that the lab quietly made for you. Templates often preselect regions, network ranges, identities, or default monitoring. Write those assumptions explicitly and decide whether they are part of the requirement or merely implementation convenience. Change one of them and predict the effect. This practice is especially useful for AZ-305 because scenario questions often turn on an assumption that a candidate unconsciously imports from familiar deployments.

Inspect operational ownership. Who approves an access request? Who responds to an alert? Who rotates a secret? Who owns a failed backup? Who can authorize a policy exception? A technical architecture with no operating model is incomplete. Add the owner and escalation path to the diagram or design record. If two teams both assume the other is responsible, that ambiguity is a design defect even if every Azure resource is configured correctly.

Review cost and lifecycle. Identify which components scale with traffic, telemetry volume, retention, data growth, or regional redundancy. Determine whether the chosen design remains reasonable under expected growth. Then decide how the environment is patched, upgraded, retired, or migrated. AZ-305 preparation should teach you to think beyond the initial deployment because architecture decisions create long-term operational obligations.

Finally, remove one component or control and explain the consequence. Remove the second region, the private endpoint, the central policy assignment, or the diagnostic setting. Which requirement fails first? This reverse test reveals whether every architectural element has a reason. If nothing important changes, the component may be unnecessary. If the impact is severe but you cannot explain why, revisit the dependency model until the role of that component is clear.

Practical exercise edge cases

When a lab works only because you used an owner-level account, repeat the critical step with the least privilege the scenario requires. Identify the exact management-plane and data-plane permissions involved. This turns identity from an invisible prerequisite into an architectural decision and reveals when a lab guide grants more access than a real design should permit.

When networking works by default, remove the default path. Introduce a private endpoint, custom route, DNS dependency, or firewall control and predict packet flow before testing. Use failure evidence to distinguish route, name-resolution, security-policy, and application problems. The exercise becomes much more valuable when you can explain where traffic stops and why rather than simply observing that a connection failed.

When a regional design claims resilience, test state. Ask what happens to sessions, queues, writes, background jobs, secrets, and dependencies during failover. An architecture diagram that duplicates compute but ignores data state or operational sequencing may not meet the recovery objective. Record what must be synchronized, what can be recreated, and what requires explicit failover or recovery action.

When telemetry appears complete, disable one diagnostic setting or exceed a threshold. Determine how the team notices the visibility gap. Monitoring architecture should include evidence that monitoring itself is functioning, especially for security or compliance signals. This exercise exposes designs that assume telemetry is always available and helps connect observability with governance.

When a lab is finished, estimate the ongoing operational workload it creates. Count rotating credentials, policy exceptions, backup checks, failover tests, alert rules, patch responsibilities, and capacity decisions. If the exercise cannot identify who owns these tasks, add an operating model before declaring the architecture complete. Practical preparation should reveal long-term obligations, not just deployment steps.

Keep an evidence notebook for practical work. For each exercise, capture only the observations that prove or disprove an architectural assumption: effective access, route behavior, failover result, recovery timing, log arrival, alert delivery, replication state, or policy enforcement. Avoid turning the notebook into a screenshot collection. The value is the link between requirement, expected observation, actual observation, and design conclusion. Over time, this creates a reusable set of architecture experiments and makes it easier to recognize when a future scenario requires a different test rather than another generic lab.

Treat documentation lookup as part of the exercise rather than as a substitute for reasoning. Before searching, write the specific behavior you need to confirm: a limit, failover characteristic, routing rule, consistency model, or identity capability. After checking the reference, update the design only if the verified behavior changes a requirement or trade-off. This practice mirrors real architecture work and prevents broad browsing from turning a focused lab into passive reading.

Keep each exercise small enough that you can repeat the reasoning after the environment is gone. If the lesson depends on remembering a particular portal screen, it is fragile. Preserve the requirement, architecture diagram, failure tested, and evidence observed so the same design logic can be rehearsed later without rebuilding every resource.

As a final check, explain the lab to someone who cannot see the environment. If the architecture, trade-off, and verification still make sense from the written brief alone, the exercise has produced transferable design knowledge rather than temporary familiarity with one deployment.

Write down what changed and why; that short reflection is part of the practical exercise, not an optional afterthought.

Run one integrated reference-architecture rehearsal

After completing smaller AZ-305 labs, combine them into one reference architecture instead of leaving the skills isolated. Use a realistic workload with a public or private entry point, application tier, data tier, identity boundary, observability, governance controls, backup, and regional recovery. Define the business requirements before selecting services.

Then rehearse changes. Tighten RTO, require private connectivity, introduce a data-residency rule, add a legacy dependency, or reduce the operating budget. For each change, redraw only the parts that should change and explain why the rest of the architecture remains valid. This reveals whether you understand dependency boundaries or merely know several Azure patterns independently.

Finish by writing the operational proof for the design: route and DNS tests, effective permissions, policy compliance, health signals, recovery timing, backup restore evidence, and cost assumptions. A reference architecture that can be explained, broken, observed, and revised is stronger preparation than a collection of successful portal exercises.