Microsoft AZ-305: Skills the Exam Really Tests

AZ-305 validates the design side of Microsoft Azure infrastructure architecture. The AZ-305 exam is current in 2026 and was updated on April 17. Microsoft organizes the blueprint around identity, governance, and monitoring; data storage; business continuity; and infrastructure design.

The exam is not a configuration test. It assumes that candidates already understand Azure administration well enough to recommend architecture choices and explain their tradeoffs. A strong answer usually starts with business and technical requirements, then chooses a design that balances security, reliability, performance, cost, governance, and operations.

Azure administration should already be operationally comfortable

Microsoft requires the Azure Administrator Associate certification for the Azure Solutions Architect Expert credential. That prerequisite is meaningful because architects need to understand how the resources they design are actually deployed and operated.

The AZ-104 exam is the clearest adjacent foundation. If you still struggle with virtual networks, storage, compute, identity, monitoring, or resource governance at administrator level, close those gaps before trying to reason about enterprise-scale design.

Identity, governance, and monitoring form one design problem

The current blueprint gives substantial weight to identity, governance, and monitoring. Those topics belong together because an architecture needs to define who can act, what policies constrain resources, and what evidence shows the environment remains healthy and compliant.

Practice organization-wide design rather than single-resource permissions. Use management groups, subscriptions, Azure Policy, role-based access, privileged administration, monitoring, and logging to create an operating boundary that can scale across teams. The Azure Policy and RBAC is useful because governance and authorization solve different problems even when both restrict behavior.

Add scale to governance practice. Design for ten subscriptions and then for one hundred. Decide what should be inherited through management groups, what belongs in subscription policy, how role assignments avoid accidental privilege, and how naming, tags, budgets, and monitoring help operators understand ownership.

Governance should enable delivery, not only restrict it. A useful architecture provides safe defaults and reusable landing-zone patterns so teams do not need to negotiate the same identity, logging, and policy decisions for every new workload.

Data storage decisions are architecture decisions

AZ-305 expects candidates to recommend storage and database solutions according to data shape, access pattern, durability, performance, availability, security, and lifecycle. The correct answer is rarely “choose the most scalable service” without reference to the workload.

Create a matrix for structured versus unstructured data, transactional versus analytical use, access frequency, latency, geographic distribution, consistency, backup, retention, and regulatory needs. Then compare Azure Storage, managed relational databases, globally distributed databases, and analytical options against those requirements.

Practice separating operational data from analytical copies. A transactional workload may need low-latency writes and strong consistency, while reporting may benefit from a warehouse or replicated analytical store. An architect should avoid forcing one database to satisfy incompatible requirements simply to reduce the number of services.

Data lifecycle matters too. Define backup, retention, archival, deletion, and restore testing before choosing the service tier. Storage cost and recovery behavior often become visible only after the system has accumulated months or years of data.

Business continuity starts with recovery objectives

High availability and disaster recovery should be driven by recovery-time and recovery-point objectives, not by habit. Practice translating a business statement such as “orders cannot be lost and service must recover within thirty minutes” into replication, backup, failover, regional, and operational requirements.

The existing AZ-305 architecture preparation is useful context, but architecture study should go further by comparing the cost and complexity of different continuity designs. Not every workload justifies multi-Region active-active operation.

Include dependency mapping in continuity design. An application can have replicated compute but still fail because identity, DNS, secrets, data, or an external service is unavailable. Write the dependencies in recovery order and decide which components must recover together to satisfy the business objective.

Test the plan through a tabletop scenario. Assume a region is unavailable and walk through detection, decision authority, failover, data validation, user communication, and restoration. Architecture quality improves when recovery can be explained as an operating procedure rather than a diagram.

Network design should preserve both reachability and control

The AZ-700 exam marks the deeper Azure networking branch. AZ-305 candidates do not need network-specialist depth in every feature, but they must be able to recommend topologies, hybrid connectivity, private access, load balancing, DNS, routing, and security patterns that fit the architecture.

A useful design exercise is to draw the expected packet path for a private application that spans on-premises and Azure. Include name resolution, routing, gateways, inspection, private endpoints, and failover. If you cannot explain the path, it is difficult to defend the architecture.

Design DNS alongside connectivity. Private endpoints, hybrid resolution, custom DNS servers, and split-horizon requirements can make name resolution part of the critical path. An architecture diagram that shows private links but ignores DNS is incomplete.

Also decide where inspection belongs. Centralized firewalls can simplify governance but may create cost, latency, or failure concentration. Distributed controls can improve local autonomy but increase management complexity. The right answer depends on traffic patterns, organizational ownership, and security requirements.

Security should be designed across identity, network, workload, and data

Architects need to recommend security controls without turning the design into a collection of products. Start with attack paths and trust boundaries. Decide how identity is protected, where network exposure is reduced, how secrets are stored, how workloads are hardened, and what telemetry supports detection and response.

The retired AZ-500 exam still provides useful historical Azure security context, but new candidates should not treat it as an active certification target. Where deeper current cloud and AI security engineering is needed, SC-500 is the modern role boundary.

Compute design is really about workload behavior

Virtual machines, containers, serverless platforms, managed application services, and Kubernetes can all host applications, but they offer different operational models. Ask how much control the team needs, how applications scale, how state is handled, how releases occur, and what skills the organization can support.

Architecture is strongest when it removes unnecessary operations. A managed service can be better than a flexible VM if the business does not benefit from controlling the operating system. Conversely, specialized workloads may justify more control despite the extra maintenance.

Add deployment frequency and state to compute decisions. Stateless web APIs that change often may benefit from managed or container platforms, while stateful or specialized workloads may need different hosting. Architecture should reduce friction for the way the application actually evolves.

Capacity planning is also a design concern. Decide whether scaling is reactive or scheduled, whether instances can be ephemeral, how quotas affect growth, and what happens when a region or zone loses capacity. Resilience and scale should be designed together.

Architecture should expose operational responsibilities

A design diagram is incomplete if nobody knows who monitors, patches, backs up, approves changes, or responds to incidents. Practice adding owners, support boundaries, escalation paths, and observability to every major component.

This is where architecture connects to the Azure Well-Architected Framework and Cloud Adoption Framework. The architect is not only choosing resources; they are designing a system that people can govern and operate consistently after the project team moves on.

Use a RACI-style annotation on one practice diagram. Mark who owns identity, network, data, backups, monitoring, cost, security findings, and application release. The architecture often reveals hidden dependencies when two teams believe the other is responsible for the same control.

This is especially important in hybrid environments, where Azure and on-premises responsibilities cross boundaries. A technically sound design can still fail operationally if no team owns the connector, DNS path, certificate, or recovery procedure.

Operational ownership should also include cost accountability. Teams need to know who reviews budgets, scaling assumptions, reservations, and unexpected consumption so architecture decisions remain economically sustainable after launch.

Case-study reasoning is more important than memorizing products

Take one scenario and write the requirements in three columns: mandatory, preferred, and implied. Then eliminate design options that violate a mandatory requirement before comparing cost or convenience. This prevents a familiar Azure service from pulling you toward an answer that does not satisfy the business case.

The Microsoft certification inventory can help you map related roles, but AZ-305 preparation should remain requirement-driven. The architect earns credibility by making tradeoffs explicit and designing for the whole solution rather than optimizing one service in isolation.

Create decision records for practice scenarios. Write the requirement, chosen design, alternatives, tradeoffs, and the condition that would make you revisit the decision. This mirrors real architecture work and forces you to justify recommendations instead of selecting a service because it is familiar.

A good final review is to revisit old labs and ask an architect-level question about each one: should this service exist, at this scale, in this region, under this identity model, with this recovery plan? That shift from configuration to design is the core of AZ-305.

If two Azure services both satisfy the functional requirement, compare them on operations, governance, recovery, cost, and organizational skill. The exam often distinguishes architects by how well they handle those nonfunctional constraints.

• Category: All Certifications Certifications