Microsoft AZ-104 and AZ-305: Shared Skills and Gaps

AZ-104 and AZ-305 sit close together in Microsoft’s Azure certification structure, but they do not test the same kind of thinking. AZ-104 is centered on implementing, managing, and monitoring an Azure environment. AZ-305 asks you to turn business and technical requirements into architecture decisions across identity, governance, monitoring, storage, business continuity, and infrastructure. As of October 3, 2026, both English exams use objectives last updated on April 17, 2026.

The relationship is practical as well as formal. Passing AZ-104 earns the Azure Administrator Associate credential, which Microsoft currently requires as the prerequisite certification for Azure Solutions Architect Expert; AZ-305 is the required expert-level exam. You can take the exams in either order, but the administration knowledge from AZ-104 gives the architecture work in AZ-305 a much firmer foundation.

The best way to think about progression is not “administrator first, architect second” as two isolated jobs. It is “operate the platform, then learn to design for constraints you have already seen.” The strongest AZ-305 candidates understand what an architecture choice looks like after deployment: how it is configured, monitored, governed, recovered, secured, and changed over time.

Identity and governance carry over, but the question changes

AZ-104 expects you to manage Microsoft Entra users and groups, assign Azure roles, work with scopes, implement Azure Policy, apply resource locks, manage subscriptions, and control costs. These tasks teach the mechanics of access and governance. The relationship between Microsoft Entra ID and Azure RBAC is especially important because many architecture decisions fail when directory administration and resource authorization are treated as the same thing.

AZ-305 takes those mechanics and asks where they belong in a design. Instead of “assign the correct role,” the question may be which scope should own a policy boundary, how management groups should separate responsibilities, how identity should work across subscriptions, or how a design reduces operational risk without creating unnecessary administrative overhead. You are expected to choose a structure that can survive growth and delegation.

A good bridge exercise is to take an AZ-104 task and add an architecture constraint. Configure RBAC at a resource group, then redesign the environment for multiple business units. Apply a policy, then decide whether it belongs at a subscription or management-group scope. The detailed mechanics of Azure Policy and Azure RBAC remain the same; what changes is the scale and the reason for choosing one control over another.

Networking moves from configuration to topology and tradeoffs

In AZ-104, you work directly with virtual networks, subnets, network security groups, DNS, routing, peering, load balancing, and connectivity. You should be able to build the network and diagnose why traffic does not flow. Hands-on experience with Azure virtual network peering is valuable because it exposes address-space planning, routing behavior, transitivity limits, and the practical consequences of design choices.

AZ-305 is more interested in why a topology is appropriate. A scenario may involve hub-and-spoke networking, private connectivity, hybrid traffic, regional resilience, centralized inspection, application delivery, or a requirement to minimize operational complexity. Several designs may technically work. Your job is to distinguish the one that fits the stated constraints rather than the one with the longest list of Azure services.

This is where administrator experience becomes architectural intuition. If you have configured NSGs, route tables, private endpoints, gateways, and peering, you understand the failure modes hidden behind a diagram. You know that address-space overlap is not a theoretical concern, that DNS design can break private connectivity, and that a centralized firewall can create both a strong control point and a dependency that must be designed for availability.

Storage knowledge becomes data-placement reasoning

AZ-104 asks you to configure storage accounts, access controls, firewalls, SAS, lifecycle policies, redundancy, Azure Files, and Blob Storage. You should understand what settings do and how to operate them. A strong administrator can explain the practical differences among redundancy choices and can apply Azure Storage redundancy to a real workload instead of treating the acronyms as flashcards.

AZ-305 broadens the decision. The architect must consider availability, durability, latency, regional requirements, access pattern, data sovereignty, recovery objectives, cost, and operational model. Choosing storage is not only a question of which service supports a feature. It is a question of how the data participates in the complete application and what happens when a component or region fails.

Practice by taking one workload and changing the recovery requirement. Start with a noncritical archive, then make it an operational store that must survive a zone failure, then make it a customer-facing workload with regional recovery objectives. The configuration skills stay useful, but the correct design changes because the business consequence changes.

Monitoring is a shared skill, but architects define what must be observable

AZ-104 includes Azure Monitor, alerts, diagnostics, metrics, logs, and operational troubleshooting. You need to configure the signals and respond when resources behave badly. Working with Azure Monitor alerts and action groups teaches you what telemetry is actually available and how alerts become operational actions.

AZ-305 moves one level up. The architect decides what the organization needs to observe, where logs should be collected, how monitoring should be centralized, what data retention is appropriate, and how the monitoring design supports security, reliability, and governance. An architecture that cannot explain how teams detect failure is incomplete even if the compute and network diagrams look polished.

A useful study habit is to add an observability section to every architecture case. State which signals matter, who receives them, how the design detects a regional or application failure, and what evidence is available after an incident. This forces you to connect architecture choices with day-two operations—the exact bridge between the two exams.

Business continuity is where the gap becomes most visible

AZ-104 includes backup and recovery tasks, but AZ-305 expects you to design business continuity from requirements such as recovery time objective, recovery point objective, regional failure, application dependency, and data consistency. Knowing how to configure a vault is different from deciding which workloads need replication, backup, failover, or a combination of controls.

Hands-on familiarity with Azure backup and recovery matters because it gives you realistic expectations about restore points, retention, recovery workflows, and operational testing. Architects who have never restored anything can easily design recovery plans that look reasonable on paper but are difficult to execute under pressure.

For study, take a three-tier application and write the recovery requirement for each tier. Then decide whether the whole application must fail over together or whether components can recover independently. Identify where data consistency constrains the plan. Finally, describe how administrators would test the recovery without creating unacceptable production risk. That exercise turns an architecture diagram into an operating design.

AZ-305 adds framework-level reasoning rather than replacing administration

The AZ-305 audience profile explicitly expects experience with Azure administration, development, and DevOps processes. That is a clue about the level of abstraction. The architect is not expected to forget implementation details; the architect is expected to understand enough detail to make decisions that other teams can execute. Reviewing AZ-305 Azure architecture should therefore feel like extending operating knowledge, not starting over with a separate vocabulary.

Architecture questions often contain competing virtues. One option may be cheaper, another simpler, another more resilient, and another more secure. The correct answer depends on the requirement that the scenario treats as non-negotiable. AZ-104 experience helps you estimate the real operational cost of each option; AZ-305 asks you to choose deliberately and explain the tradeoff.

Use Azure’s Well-Architected and Cloud Adoption ideas as lenses rather than slogans. For every design, ask how reliability, security, cost, operational excellence, and performance interact. Then ask how governance and organizational structure influence implementation. The goal is to make a design defensible, not merely technically possible.

The best progression is to turn administration labs into design cases

If you already hold AZ-104, do not throw away your lab environment when you begin AZ-305. Reuse it. Draw the architecture you built, list its assumptions, and then change those assumptions. Add a second region, stricter identity requirements, private connectivity, a regulatory boundary, or a much tighter recovery objective. Each change should force a design decision.

If you are studying both exams together, keep two columns in your notes: “implement” and “design.” Under identity, the implementation column might contain role assignments and policy configuration; the design column should contain scope strategy, separation of duties, and governance boundaries. Under networking, implementation contains routing and peering; design contains topology, hybrid connectivity, inspection, resilience, and cost.

The difference between the exams is therefore less about separate technology and more about altitude. AZ-104 teaches you to operate Azure correctly. AZ-305 expects you to use that operational understanding to make choices that remain workable when the environment becomes larger, more regulated, more failure-prone, or more expensive to change. Candidates who can move comfortably between those two levels are building exactly the skill set Microsoft’s Azure Solutions Architect Expert credential is intended to represent.

One practical mistake is to study AZ-305 as a service-selection exam after finishing AZ-104. That produces shallow architecture answers because it ignores organizational and operational constraints. When comparing two plausible Azure designs, write down who will operate each one, what permissions those operators need, how changes are deployed, how failures are detected, and how the solution is recovered. A design that is technically elegant but impossible for the team to run is usually the wrong architecture.

Also practice communicating a recommendation in one paragraph. State the requirement you are optimizing for, the Azure approach you would choose, the tradeoff you are accepting, and the operational consequence. That habit is useful for AZ-305 because it forces you to separate “this service can do it” from “this is the most appropriate design under the stated constraints.” It also exposes weak reasoning faster than another round of flashcards.

• Category: All Certifications Certifications