AZ-104 to AZ-305: Admin to Architect

AZ-104 and AZ-305 are closely related because the Microsoft Certified: Azure Solutions Architect Expert credential requires an active Azure Administrator Associate certification in addition to passing AZ-305. But the exams validate different kinds of thinking. AZ-104 asks whether you can implement and operate Azure resources; AZ-305 asks whether you can design the overall solution and justify architectural tradeoffs.

The AZ-104 exam builds operational fluency across identity, governance, storage, compute, networking, monitoring, and backup. Those skills matter because a solution architect who has never administered Azure can easily design systems that are difficult to deploy, secure, observe, or recover.

The AZ-305 exam moves that knowledge into design. Microsoft currently measures identity, governance, monitoring, data storage, business continuity, and infrastructure architecture, with the English exam last updated in April 2026. You can sit AZ-305 before AZ-104, but the Expert certification is awarded only when both requirements are satisfied.

AZ-104 teaches what Azure feels like to operate

Administration is where abstract cloud concepts become operational details. You create resources, assign access, configure networks, manage storage, deploy compute, monitor health, protect data, and troubleshoot unexpected behavior. The administrator sees how small configuration choices affect reliability and support burden.

The practical coverage in AZ-104 is most useful when every topic becomes a lab. Create the resource, inspect its defaults, change a control, observe the effect, and learn how to prove what happened.

This operating experience becomes architectural intuition later. You are less likely to propose a design that is elegant on a diagram but difficult to manage in production.

AZ-305 starts with requirements instead of configuration tasks

An architect receives business and technical constraints: availability targets, recovery objectives, data residency, identity requirements, integration needs, performance expectations, budget, and operational maturity. The task is to translate those requirements into a coherent Azure design.

The current AZ-305 design domains show why memorizing service names is insufficient. Multiple Azure services can solve a problem, but the architect must select the option that best fits the constraints and explain what is sacrificed.

Study architecture by changing requirements. A single-region internal application, a regulated multi-region service, and a latency-sensitive global platform may use completely different patterns even when their basic business function is similar.

Identity and governance grow from implementation into design boundaries

AZ-104 expects you to manage users, groups, subscriptions, governance controls, and access assignments. AZ-305 expects you to decide how identity and governance should be structured across the solution so teams can operate safely without creating unnecessary friction.

The distinction between Azure Policy and Azure RBAC is central. RBAC answers who can perform actions; Policy evaluates or enforces resource conditions. Architects need both controls and must decide the scope at which each belongs.

A useful exercise is to design a multi-subscription environment with central guardrails, workload ownership, privileged access, and exceptions. Then implement a small version of it and see which assumptions survive contact with real permissions.

Networking changes from configuring subnets to designing connectivity

AZ-104 covers virtual networks, subnets, name resolution, network security groups, load balancing, routing, and connectivity. AZ-305 asks how those components should be combined across regions, environments, on-premises networks, and application tiers.

The thinking behind Azure networking design helps because architecture decisions depend on address space, routing domains, security boundaries, DNS behavior, inspection, latency, and future expansion.

Do not study network architecture only as diagrams. Build a hub-and-spoke or segmented environment, then introduce a route error, DNS failure, or policy conflict and observe how difficult the design is to troubleshoot.

Storage decisions depend on access, durability and recovery needs

Administrators configure storage accounts, redundancy, access controls, lifecycle rules, and data protection. Architects decide which storage technology and redundancy model fit the workload’s data shape, latency, availability, compliance, and cost requirements.

The options in Azure storage redundancy are a good design exercise because higher replication is not automatically correct. The architect must understand failure domains, recovery needs, regional strategy, application behavior, and budget.

For study, take one dataset and design three storage solutions: low-cost archival, high-availability application data, and a globally distributed read workload. Explain why each choice differs.

Compute choices reveal the architect’s tradeoff discipline

AZ-104 teaches you to deploy and manage virtual machines, containers, and application resources. AZ-305 asks which compute model should be used in the first place. Control, portability, scaling, operational burden, deployment frequency, state, and networking requirements all influence the answer.

The contrast in Azure VMs and managed web applications demonstrates the tradeoff. More control can also mean more patching, capacity planning, security hardening, and operational responsibility.

Architects should prefer the simplest platform that satisfies the requirements, not the service that exposes the most knobs.

Business continuity turns backups into recovery architecture

AZ-104 includes backup and monitoring tasks, but AZ-305 requires you to design business continuity around recovery time, recovery point, regional failure, data replication, application dependencies, and testing. A backup is only useful if the organization can restore the right data quickly enough.

The operational techniques in Azure backup and recovery should therefore be connected to architecture decisions. What is protected, where is it stored, how often is it captured, and what sequence is required to restore the service?

Practice a recovery scenario on paper and in Azure. Identify dependencies that must return first, permissions required during recovery, DNS or networking changes, and the evidence that proves the service is usable.

Monitoring moves from alerts to observability requirements

An administrator configures metrics, logs, alerts, diagnostics, and backup monitoring. An architect decides what the system must expose so operators can measure service health, investigate incidents, understand dependencies, and meet business objectives.

The mechanics of Azure Monitor alerts are only the beginning. Good observability also requires meaningful signals, ownership, escalation, retention, dashboards, and enough context to distinguish infrastructure failure from application failure.

When designing, write the operational questions first: how will we know users are affected, which metric proves capacity is exhausted, and what log reveals an authorization failure?

The administrator-to-architect move also changes how you treat defaults. AZ-104 study often teaches what Azure creates by default and how to configure it. AZ-305 requires you to decide whether those defaults are acceptable for the business requirement. Default redundancy, network exposure, retention, scaling, or authentication may be fine for one workload and unacceptable for another.

Migration scenarios are especially valuable because they force architecture decisions to interact with existing constraints. A workload may have fixed IP dependencies, legacy authentication, large data-transfer requirements, maintenance windows, or licensing limitations. The best Azure service on a blank diagram may not be the safest migration destination when those realities are included.

Architecture documentation should include operations explicitly. For every major component, identify who owns it, what normal health looks like, what failure looks like, how it is restored, and what change process applies. This keeps the design from becoming a static picture that the operations team has to reinterpret later.

During AZ-305 practice, explain why the rejected options are wrong under the stated constraints. Microsoft architecture questions often include several technically possible answers. The distinction usually comes from cost, governance, recovery, management overhead, scale, or integration requirements rather than raw feature support.

Cost governance is another place where administrator and architect thinking meet. AZ-104 candidates should understand tags, budgets, resource organization, and operational controls. AZ-305 candidates need to decide how cost ownership, scaling, service selection, and lifecycle policies are designed so spending remains visible and attributable as the environment grows.

A useful architecture exercise is to take a working AZ-104 lab and write a design decision record for it. State the requirement, chosen service, rejected alternatives, security boundary, recovery expectation, monitoring requirement, and cost assumption. This turns configuration knowledge into the kind of reasoning AZ-305 is designed to measure.

Keep the operational feedback loop open after the design is implemented. Architects learn from incidents, capacity problems, unexpected bills, and difficult deployments. Those lessons should influence the next design rather than remaining isolated inside the operations team.

A second useful bridge is to review an Azure environment from two viewpoints. First, act as the administrator and list the tasks required to keep it healthy: permissions, patching, backups, alerts, capacity, network changes, and incident response. Then act as the architect and ask which design decisions created that operating burden. This exposes whether complexity is justified by a requirement or simply accumulated through configuration choices.

Architecture practice should also include explicit nonfunctional requirements. Availability, recoverability, security, maintainability, performance, and cost often compete. For example, adding regional redundancy may improve resilience while increasing replication cost and operational complexity. A candidate who can state that tradeoff clearly is doing more than recalling Azure features; that candidate is reasoning at the level AZ-305 expects.

The move from administrator to architect is a change in question type

AZ-104 questions often ask how to implement or troubleshoot a requirement. AZ-305 questions more often ask which design best satisfies a set of competing requirements. The underlying Azure knowledge overlaps, but the mental task is different.

That is why the strongest progression is not to finish AZ-104 and immediately memorize another service list. Revisit the resources you administered and ask design questions about them: why this service, why this region, why this redundancy model, why this identity boundary, and what would change if the requirement changed?

When you can connect those decisions to operational consequences, you have made the real shift from administration to architecture. The Expert certification then reflects a broader responsibility rather than simply two passed exams.

• Category: All Certifications Certifications