Microsoft AZ-104 vs AZ-305: Key Differences
AZ-104 and AZ-305 both live in the Azure infrastructure world, but they test different kinds of judgment. AZ-104 is about implementing, managing, and monitoring Azure environments. AZ-305 is about designing infrastructure solutions that satisfy business, security, resilience, governance, and operational requirements. The overlap is substantial because architects need to understand administration, but the perspective changes.
As of October 3, 2026, AZ-104 covers identities and governance, storage, compute, networking, and monitoring. AZ-305 focuses on designing identity and governance, data storage, business continuity, and infrastructure solutions. To earn Azure Solutions Architect Expert, candidates need the Azure Administrator Associate prerequisite as well as AZ-305; the two requirements validate operational grounding and architecture design at different levels.
The simplest distinction is implementation versus design. AZ-104 asks, “Can you operate Azure correctly?” AZ-305 asks, “Can you choose an architecture that will continue to work under the organization’s constraints?” Understanding that difference prevents candidates from studying the two exams as if one were merely a harder version of the other.
Azure administrators are responsible for environments that already exist and environments that are being built. They create resources, configure permissions, manage storage, deploy compute, connect networks, monitor health, and keep governance aligned with organizational rules. The exam therefore rewards precision about settings, dependencies, and operational sequences.
Identity and governance illustrate the style. You need to understand Microsoft Entra ID and Azure RBAC, subscriptions, management groups, resource groups, locks, tags, and policy behavior well enough to configure them correctly. A scenario can hinge on scope inheritance or on the difference between who can change a resource and what configurations are permitted.
Administration also means troubleshooting. When a VM cannot reach a service or a user cannot access a storage account, AZ-104 expects you to work through the relevant layers. That operational habit becomes valuable later in architecture because you learn where elegant diagrams tend to fail in real deployments.
An architect should not begin by selecting a service. The first questions are about availability, recovery objectives, data characteristics, security, compliance, scale, latency, cost, operational capability, and existing dependencies. AZ-305 tests whether you can translate those constraints into an Azure design.
That often means several answers are technically possible. The correct choice is the one that fits the requirement with the least unnecessary complexity. Architecture questions reward tradeoff reasoning: managed service versus more control, regional redundancy versus cost, private connectivity versus public endpoints, active-active versus active-passive, or centralized governance versus team autonomy.
The exam also expects the architect to consider how the design will be run. A solution that a team cannot monitor, patch, recover, or govern is not a strong architecture even if its individual components are technically valid.
AZ-104 asks you to implement governance controls. AZ-305 asks you to design the governance structure. For example, an administrator may assign roles, create policies, and organize resources. An architect decides how management groups, subscriptions, policy initiatives, identity boundaries, and delegated administration should be structured across the organization.
The difference between Azure Policy and Azure RBAC matters in both exams. AZ-104 emphasizes correct configuration and scope. AZ-305 adds the question of where those controls belong in a governance model and how they support security, compliance, and operating autonomy.
A useful study exercise is to take an AZ-104 task and elevate it one level. If the task is “assign access to this resource group,” the architecture question becomes “how should access be delegated across dozens of subscriptions while minimizing standing privilege and administrative overhead?”
AZ-104 networking requires competence with virtual networks, subnets, DNS, routing, network security groups, load balancing, peering, private connectivity, and monitoring. You should be able to configure and troubleshoot paths. Hands-on work with Azure virtual network peering is a good example because it exposes address planning, route behavior, and connectivity assumptions.
AZ-305 asks how those building blocks should form an enterprise topology. The architect has to choose hub-and-spoke or other patterns, determine regional strategy, plan hybrid connectivity, segment workloads, place shared services, and decide where inspection or private access belongs. The question is not merely how to create a route; it is which traffic should be allowed to exist.
Even a familiar component such as Azure Load Balancer becomes an architectural choice when availability zones, scale, application protocols, global distribution, and failure behavior are part of the requirement.
AZ-104 expects you to manage storage accounts, access methods, redundancy, lifecycle settings, file shares, data movement, and related controls. You need to understand what the settings do and how they affect availability, performance, security, and cost.
AZ-305 uses those details to design data storage and business continuity. Azure storage redundancy is no longer just a list of options; it is a tradeoff between failure domains, recovery expectations, read access, replication behavior, and budget. Similar reasoning applies to databases, backups, replication, and disaster-recovery architecture.
Study recovery time objective and recovery point objective as design constraints. An architect should be able to connect those numbers to replication, backup frequency, regional strategy, and operational testing. An administrator then needs to implement the chosen design correctly.
AZ-104 covers virtual machines, scale sets, containers, App Service, and supporting configuration. You should know how to deploy, resize, secure, update, and monitor compute. The operational question is whether the workload is healthy and manageable.
AZ-305 asks which compute model best fits the application. A VM may provide control but create patching responsibility. A platform service can reduce operational load but impose constraints. Containers can increase portability but require a mature operating model. Architecture is the art of choosing the appropriate responsibility boundary.
When you compare services, include the team as part of the design. A theoretically elegant platform that the organization cannot operate safely is a poor answer. AZ-305 repeatedly rewards architectures that align technology with the people and processes that will support it.
AZ-104 expects you to configure monitoring, alerts, logs, and operational visibility. AZ-305 expects observability to be designed into the solution. That includes deciding which signals matter, where they are collected, how long they are retained, who responds, and how monitoring supports availability and security objectives.
The same distinction applies to resource organization. Azure resource groups are an administrative construct, but their boundaries affect deployment, access, lifecycle, and operational ownership. Architecture turns apparently simple platform features into governance decisions.
A good comparison lab is to deploy a small workload as an administrator, then write an architecture review for it. Identify single points of failure, privileged paths, recovery assumptions, monitoring gaps, scaling limits, and cost risks. That exercise teaches the mental shift between the exams.
Microsoft allows candidates to take AZ-305 before AZ-104, but the Azure Solutions Architect Expert credential requires the active Azure Administrator Associate prerequisite. That is more than a bureaucratic relationship. It reflects the expectation that an Azure architect understands the platform at an operational level.
If you are new to Azure infrastructure, AZ-104 is usually the stronger starting point. If you already administer Azure confidently and spend increasing time on design reviews, migration planning, resilience, or platform standards, AZ-305 is the natural next step. Experienced architects can study the exams in either order, but gaps in administration often surface quickly during AZ-305 preparation.
AZ-104 and AZ-305 are complementary because good architecture and good administration reinforce each other. One teaches you how Azure behaves when you operate it; the other teaches you how to shape that behavior into a design that can survive growth, failure, governance, and change.
A powerful preparation method is to use one workload for both exams. Deploy a small web application with identity, storage, networking, monitoring, and backup. First approach it as an AZ-104 administrator: create the resources, configure access, connect the network, deploy compute, set alerts, and verify recovery.
Then step away from the portal and review the same workload as an AZ-305 architect. Ask whether the regional design meets availability targets, whether identity and subscription boundaries scale to several teams, whether the storage choice meets durability and cost requirements, whether recovery objectives are explicit, and whether the chosen compute model creates unnecessary operational burden.
The second pass usually reveals that technically correct administration does not automatically produce a strong architecture. It also shows the reverse: an architecture diagram is incomplete until someone can implement, monitor, and recover the design. Practicing both views makes the relationship between AZ-104 and AZ-305 much more concrete.
Cost is another place where the level changes. AZ-104 candidates should understand how configuration choices affect consumption and how to monitor resources. AZ-305 candidates need to make cost part of the design itself: whether redundancy is justified, whether a managed service reduces operational expense, whether reserved capacity fits predictable demand, and whether the architecture can scale without producing an avoidable cost spike.
During practice, add a budget constraint to one of your designs. If your architecture changes dramatically, explain why. If it does not change at all, check whether you are treating cost as an afterthought rather than a real requirement.