Microsoft AZ-305: Readiness Matrix

Microsoft AZ-305 readiness is the ability to turn constraints into defensible Azure architecture, not the ability to name a service for every keyword. The current exam spans identity/governance/monitoring, data storage, business continuity, and infrastructure design. A useful matrix therefore scores evidence across those architectural responsibilities and the tradeoffs that connect them.

The Microsoft AZ-305 exam remains current on October 6, 2026, using the English blueprint updated April 17, 2026. Use the matrix to identify weak decision patterns, then build targeted scenarios rather than rereading the entire objective list.

Requirements, governance, and operations

Architecture readiness also includes knowing what evidence is missing. If a scenario leaves scale, residency, recovery, or operational ownership ambiguous, state the assumption you are making and how a different assumption would change the design. That discipline prevents an answer from sounding certain when the requirement is actually incomplete.

Operational feasibility belongs in the matrix. A design may meet security and availability requirements but still be too complex for the team that will run it. Include deployment ownership, incident response, change control, and monitoring burden when scoring a solution. Architects are responsible for systems that can be operated, not only for diagrams that look complete.

Readiness level 1: extract requirements

You can separate functional requirements, quality attributes, hard constraints, assumptions, existing-state facts, and stakeholder preferences. Given a one-page business scenario, produce a requirement table before naming Azure services and identify at least one conflict between objectives such as cost, recovery, latency, or control.

If product names appear before constraints, this level needs work.

Use the matrix to identify systemic weaknesses. Several wrong answers about data, networking, and recovery may all come from one deeper problem: requirements are not being translated into quality attributes before services are selected. Fixing the upstream reasoning can improve several domains at once.

Readiness level 2: design identity and governance

You can choose administrative boundaries, RBAC scope, policy inheritance, exception paths, privileged access, and resource organization from ownership and compliance needs. Rework a multi-team Azure environment so delegation and policy remain understandable after one team reorganizes.

Identity and governance readiness means being able to place delegation and policy at durable scopes. Azure governance controls help distinguish RBAC, Policy, resource locks, and hierarchy decisions so administrative convenience does not become the only reason for a broad scope.

Readiness level 3: design monitoring and operations

You can identify service objectives, required telemetry, diagnostic destinations, alerts, dashboards, action owners, and evidence retention before deployment. For one critical workload, state what signal represents customer impact and how operators distinguish platform health from application or dependency failure.

Review Azure Monitor and Log Analytics observability if your monitoring plan is still a list of metrics without decisions.

Data, compute, and network design

Review cross-domain dependencies as well as individual scores. A weak identity-and-governance model can invalidate an otherwise good infrastructure design; poor observability can make a resilient architecture impossible to operate; unrealistic recovery assumptions can change data and compute choices. The final readiness question is whether the pieces remain coherent when you evaluate the architecture as one system.

Readiness level 4: design data storage

You can choose storage and database patterns from data shape, consistency, latency, scale, security, availability, integration, and recovery requirements. Take one dataset and change its access pattern or consistency requirement; explain why the architecture should or should not change.

If the answer does not mention data behavior, it is probably service-driven rather than requirement-driven.

Track improvement by decision pattern, not by raw percentage alone.

Readiness level 5: design compute and integration

You can compare virtual machines, containers, managed web platforms, serverless patterns, and integration styles using deployment, scaling, control, runtime, failure, and coupling requirements. Redesign a synchronous application for background processing or fan-out events and explain how retry, ordering, duplicate handling, and observability change.

A good answer identifies which requirement changed the compute or integration choice. A useful readiness level 5: design compute and integration summary therefore records why the choice fits the AZ-305 readiness requirement and which assumption would trigger a redesign.

Readiness level 6: design network boundaries

You can map traffic flows, DNS, routing, private access, hybrid connectivity, segmentation, inspection, application delivery, and administrative paths. Draw the packet path for user, application, data, and management traffic and identify where trust or routing changes.

This exposes hidden dependencies that a generic hub-spoke diagram can conceal.

Resilience and tradeoffs

Communication is part of readiness. Another architect should be able to understand the decision, its constraints, its owner, and the condition that would trigger review. If the design can only be defended by saying it is a best practice, the tradeoff has not been explained clearly enough.

One final readiness check is whether the architecture can be explained without relying on the original diagram. State the requirement, selected pattern, major dependency, operational owner, and review trigger in plain language. If that explanation is unclear, the design may still be hiding assumptions behind service names.

Readiness level 7: design business continuity

Business-continuity readiness should show that you can translate RTO, RPO, dependency order, regional failure, backup, restore, failover, and failback into one recovery model. AZ-305 business continuity and disaster recovery is most useful when it keeps redundancy and recoverability separate.

Readiness means you can describe who declares failure, what recovers first, and how the organization proves the plan works.

Readiness level 8: defend tradeoffs

You can identify the strongest credible alternative, state why it loses under the scenario’s priorities, and explain the operational consequences of the chosen design. Present the same architecture to a cost owner, security engineer, and operations lead; each should understand the decision in terms relevant to their responsibility.

If the justification is only ‘best practice,’ the tradeoff is not explicit enough.

Adapt the architecture when assumptions change

Use one complete architecture as a recurring test case. Change data residency, traffic, team skills, recovery targets, or cost constraints and mark which decisions are affected. The point is not to redraw everything, but to prove that you understand which design choices depend on which assumptions.

Use changed assumptions deliberately. Increase traffic, tighten residency, shorten RTO, reduce staff, or add a legacy dependency and identify which decisions must move. Readiness is strong when those changes can be traced to specific architecture choices instead of forcing a complete redesign.

Readiness level 9: revise cross-domain dependencies when constraints change

You can update a design coherently when one assumption changes without rebuilding everything from scratch or contradicting earlier decisions. Change region availability, data residency, team skills, traffic, recovery target, or cost ceiling and identify which architecture decisions are affected.

That adaptability is the strongest readiness signal because real architecture work is revision under constraints, not one perfect diagram.

Cross-domain dependencies deserve their own review. Weak governance can invalidate an otherwise sound workload design; poor observability can make a resilient system impossible to operate; unrealistic recovery assumptions can change data and compute choices. The final architecture has to remain coherent when all domains are considered together.

Architecture readiness is strongest when you can explain which decisions remain stable after a requirement changes and which dependencies must be revisited. That distinction prevents every new constraint from triggering a full redesign.

Use the final readiness review to change one cross-domain constraint at a time. Tighten data residency, reduce the operations team, shorten the recovery objective, require private connectivity, or add a new integration dependency. Identify which data, compute, network, identity, monitoring, and governance decisions move as a result and which remain valid. This exercise is useful because architecture questions often look like service selection while actually testing dependency reasoning. The strongest readiness signal is being able to revise only the affected decisions and explain why the rest of the design still holds.

Score architecture readiness from evidence

Score the matrix with evidence, not confidence. A domain is not “strong” because you recently watched a module or can recognize service names. Mark it strong only when you can solve a changed scenario, identify the strongest alternative, state a failure mode, and name the operational signal that would validate the design. This makes the matrix harder to satisfy, but much more useful for deciding where the next study session should go.

Use the matrix after each full practice set rather than after every isolated question. Look for repeated decision failures across different wording, then change the next study task to target that pattern. One recurring ownership or tradeoff error is more important than several unrelated factual misses because it will affect many architecture scenarios.

Readiness should include explanation under pressure. Take one architecture and present it in two minutes: requirement, selected pattern, strongest alternative, principal risk, and the signal that would make you revisit the design. If the explanation depends on a long product list, the architecture is probably not yet organized around decisions.

Use the score to choose the next architecture exercise, not to create a confidence grade. A weak data-domain score may reflect poor requirement translation rather than lack of product knowledge; a weak resilience score may come from failing to connect dependencies and recovery order. The matrix is useful when it changes the next practice task and makes the root reasoning gap visible.