Microsoft AZ-104 to Microsoft AZ-305: Admin to Architect

The move from Azure administration to solutions architecture is not a simple promotion from one exam code to another. Microsoft AZ-104 and AZ-305 overlap in services, but they ask different questions about those services. Administrators implement and operate Azure resources. Architects translate business and technical requirements into designs, compare alternatives, and explain the consequences of those choices.

That is why the Azure Administrator Associate is the prerequisite certification for the Azure Solutions Architect Expert. Operational experience gives architecture decisions weight. Someone who has troubleshot identity, networking, storage, compute, monitoring, and recovery has already seen how design choices behave after deployment.

The transition is therefore less about learning an entirely new catalog of Azure services and more about changing the level of reasoning. AZ-104 asks whether you can configure and manage the environment. AZ-305 asks why the environment should be designed that way in the first place.

Administration proves mechanics; architecture explains trade-offs

An administrator is often given an environment that already exists. The work is to deploy resources correctly, maintain service health, control access, troubleshoot failures, and apply the organization’s policies. An architect may need to decide the shape of that environment before anything is deployed.

That difference changes the answer style. An administrator can explain how to configure a private endpoint. An architect must decide whether private access is required, how DNS will work, what the hybrid path looks like, which teams own the dependencies, and what failure mode the design introduces.

The same applies to compute, storage, monitoring, and recovery. Architecture is not “more services.” It is explicit reasoning about requirements, alternatives, constraints, consequences, and ownership.

A good practice is to take one AZ-104 task and ask an architectural question before it. Before creating a route table, ask why traffic must follow that path. Before choosing a storage tier, ask which access pattern justifies it. Before enabling backup, ask what the business is trying to recover from and within what time. This habit converts configuration knowledge into design reasoning.

Identity and governance move from assignment to control architecture

AZ-104 teaches administrators to work with Microsoft Entra identities, Azure RBAC, subscriptions, resource groups, policy, locks, and governance controls. AZ-305 expects you to turn those mechanisms into an organizational design.

Consider a company with several business units, multiple regions, and regulated workloads. The architecture question is not merely how to create subscriptions and role assignments. You need to decide how management groups, subscriptions, policy inheritance, platform ownership, application-team access, logging, and cost boundaries should reflect the organization.

Strong governance avoids two extremes. Too little control produces inconsistency, security gaps, and cost sprawl. Too much centralization slows delivery and encourages teams to work around the platform. The architect’s job is to make compliant delivery the easiest path.

Administrators who already understand scope and inheritance have a strong foundation because they know what the controls actually do when applied.

Architecture also has to account for change. A governance model should be able to add a new subscription, region, or business unit without requiring the organization to redesign every policy and role assignment manually. Reusable landing-zone patterns, naming, policy inheritance, and clear ownership make growth easier to manage.

Networking becomes traffic, dependency, and failure architecture

AZ-104 gives candidates working knowledge of virtual networks, subnets, peering, network security groups, private endpoints, routes, DNS, load balancing, and hybrid connectivity. AZ-305 requires those mechanisms to be assembled into a defensible network design.

For each workload, draw the path from source to destination. Identify DNS resolution, routing, inspection, authentication, private access, load balancing, and failover behavior. Then ask what happens during a regional outage, a firewall failure, a DNS failure, or loss of an on-premises circuit.

The AZ-104 virtual networking foundation is worth revisiting if routing and DNS are weak areas. Candidates who need deeper specialization can also use the updated Azure network engineering.

The architect does not need to turn every solution into a networking project, but weak network reasoning creates fragile cloud architecture very quickly.

Pay special attention to shared dependencies. A highly available application can still depend on one DNS path, one central firewall, one ExpressRoute circuit, or one on-premises identity service. Architecture should surface those dependencies before they become incident surprises.

Compute decisions should begin with workload behavior

Administrators deploy and manage virtual machines, scale sets, App Service, container services, and related compute. Architects decide which compute model is appropriate for the workload and for the team that will support it.

Virtual machines provide control but increase operating responsibility. Managed application platforms reduce infrastructure work but impose platform boundaries. Containers provide portability and deployment flexibility but can introduce orchestration complexity. Serverless functions can be efficient for event-driven workloads but bring runtime and integration considerations.

A useful architecture worksheet records runtime requirements, state, scaling pattern, deployment frequency, network dependencies, compliance, latency, portability, operating-hours pattern, and team skills. Compare at least two technically valid options and state why one better satisfies the requirements.

That practice turns administrator familiarity with compute into architecture judgment.

Do not ignore operational staffing. A team that can manage Kubernetes confidently may accept complexity that would be inappropriate for a small operations group. A managed platform can be the stronger architecture when it reduces undifferentiated maintenance and lets the team spend more time on the application itself.

Storage design begins with data behavior and recovery objectives

AZ-104 candidates configure storage accounts, access, redundancy, lifecycle, networking, and monitoring. AZ-305 candidates need to decide which storage architecture fits the data and the required failure behavior.

Start with the data model. Is the workload relational, document-oriented, file-based, object-based, or analytical? How often is the data read and written? Is it mutable or append-only? What are the latency and throughput requirements? Which regions may hold the data?

Then add recovery and durability. What data loss is acceptable? How quickly must the service recover? Does the workload need backup, replication, versioning, or regional failover? Those mechanisms solve different problems and should not be treated as interchangeable. The updated Azure storage types and workload fit is useful when you need to strengthen the workload-to-storage decision before moving into architecture scenarios.

Cost also belongs here. Storage capacity, transactions, replication, access tiers, backup, and data movement can all change the economic profile. The architect should model not only where data lives today but how growth and retrieval patterns change the cost over time.

Observability and business continuity need workload-level design

An administrator can configure alerts, diagnostic settings, backup policies, and restore operations. An architect needs to define what the workload must prove during normal operation and how it will recover when something fails.

Observability should begin with user outcomes. Which signals indicate that the service is healthy? Which logs support troubleshooting, audit, or security? How long should data be retained? Which alerts require immediate action and which are better suited to trend analysis?

Business continuity design should begin with recovery time and recovery point objectives. Map every critical dependency: identity, DNS, networking, compute, data, messaging, secrets, external services, and operational access. A multi-zone application can still have a single point of failure if one critical dependency is regional or manually operated.

Architecture quality becomes visible during recovery exercises. If the restore works but DNS, identity, secrets, or application configuration cannot be rebuilt within the required time, the design has not met the business requirement.

Runbooks should be part of the design. A recovery strategy that exists only in a diagram is incomplete. The team needs clear steps, required privileges, decision points, communication ownership, and a repeatable way to verify that service has actually returned for users.

Security, cost, and operations are design constraints, not afterthoughts

Architects must account for trust boundaries, administrative access, data sensitivity, network exposure, key management, privileged roles, monitoring, and exception handling. The correct control depends on the risk and the workload rather than on a universal rule such as “use private endpoints everywhere.”

Cost needs the same discipline. The cheapest resource price can produce a more expensive system if it increases operational labor, creates excessive data movement, or requires complex custom automation. Managed services can cost more per unit but reduce patching, deployment drift, and support burden.

Team skill is also an architecture input. A technically elegant design can fail if only one specialist understands how to operate it. The architect is responsible for a system the organization can actually run, not the system that looks most impressive on a diagram.

These trade-offs are where administrator experience becomes especially valuable because operators see the downstream cost of complexity directly.

Architecture decision records help make these trade-offs explicit. Write down the requirement, selected option, alternatives considered, benefits, disadvantages, cost implications, and operational consequences. This creates a record the team can revisit when assumptions change.

Turn an AZ-104 lab into an AZ-305 case study

One of the most effective bridges is to reuse an environment you can already operate. Add business requirements such as two geographic user populations, sensitive data, a defined RTO and RPO, a budget ceiling, and a small operations team.

Then redesign the environment. Compare at least two network patterns, compute options, and storage choices. Write short architecture decision records that capture context, selected option, rejected alternative, benefits, disadvantages, cost implications, and operational consequences.

Implement enough of the preferred design to test your assumptions. If the architecture becomes difficult to operate, document why. If private access creates DNS dependencies, make them explicit. If redundancy increases cost, quantify it. Architecture improves when operational reality tests the design. The Azure certification roadmap can help identify whether networking, security, or another adjacent domain deserves additional study before AZ-305.

The final transition is a change in habit: before implementing a solution, ask what this choice makes easier, what it makes harder, how it fails, how it is observed, how it recovers, who owns it, and how cost changes as the workload grows. When those questions become automatic, AZ-104 operational skill has begun to turn into AZ-305 architecture judgment.