AZ-104 vs AZ-305: Azure Administration and Solutions Architecture Skills Compared

 

AZ-104 teaches you to operate Azure; AZ-305 teaches you to design Azure around requirements

AZ-104 and AZ-305 are closely related because architects depend on the same Azure services that administrators configure and operate. The difference is the level of responsibility. AZ-104 focuses on implementation, management, and monitoring of Azure identity and governance, storage, compute, virtual networking, and operational resources. AZ-305 focuses on designing Azure infrastructure solutions that satisfy business, security, availability, governance, continuity, and operational requirements.

That difference can be expressed as two recurring questions. The Azure administrator asks, “How do I configure, manage, secure, monitor, and troubleshoot this environment?” The Azure solutions architect asks, “Given these requirements and constraints, what should the environment look like, and why is this design appropriate?” One role is implementation-centered. The other is decision-centered.

As of September 2026, Microsoft’s current study guides reflect AZ-104 skills measured from April 17, 2026 and AZ-305 skills measured from April 17, 2026. Candidates should always use the current study guide for the date they plan to test because Microsoft updates exam objectives over time. The important career distinction, however, remains stable: administration is about running Azure effectively; architecture is about selecting and combining Azure capabilities into a coherent design.

AZ-104 develops the hands-on foundation that architecture depends on

An administrator needs to understand what Azure resources actually do after they are deployed. That includes identities, subscriptions, resource groups, policy, role-based access, storage, virtual machines, containers where relevant, virtual networks, name resolution, load balancing, backup, monitoring, and operational maintenance.

This work is full of details that architecture diagrams can hide. A design may say “use private connectivity,” but an administrator must implement address spaces, subnets, name resolution, route behavior, security rules, private endpoints, and monitoring. A design may say “use role-based access,” but the administrator must assign roles at the right scope, avoid excessive privilege, manage identities, and troubleshoot why a user or workload cannot perform an action.

That operational experience matters because poor designs often fail at the implementation layer. A theoretically elegant architecture can become difficult to run if it creates too many manual exceptions, inconsistent naming, fragmented monitoring, or complicated network dependencies. AZ-104 therefore gives future architects a valuable sense of operational friction.

AZ-305 starts with requirements rather than resources

Architecture should not begin with a favorite Azure service. It begins with requirements. What business capability is being built? What data is involved? What availability target is required? What recovery objectives exist? Which identities and organizations need access? What regulatory constraints apply? What existing systems must integrate? What costs are acceptable? What skills does the operations team have?

AZ-305 is designed around translating those inputs into Azure designs. That means evaluating alternatives and making trade-offs. A highly available design can cost more. A globally distributed architecture can improve latency while increasing data-governance complexity. A tightly segmented network can reduce risk while making operations and troubleshooting harder. A managed platform service can reduce infrastructure burden but may constrain configuration or migration options.

The architect’s responsibility is not to maximize every desirable property. It is to create a design that is balanced, explainable, supportable, and aligned with priorities.

Identity and governance show the difference clearly

In AZ-104, identity and governance are operational responsibilities. You need to manage users, groups, identities, roles, subscriptions, resource organization, policy, and access controls. You should understand scope and inheritance, know how to limit privilege, and be able to troubleshoot authorization problems.

In AZ-305, identity and governance are design inputs and design outputs. The architect may need to decide how subscriptions should be organized, how management groups should support policy, how administrative boundaries should be defined, where privileged roles should be limited, how workload identities should authenticate, and how governance should scale as more teams adopt Azure.

Consider a company with business units in several countries. An administrator may be asked to implement role assignments and policies after the structure is approved. An architect must decide whether the subscription model reflects business ownership, regulatory separation, lifecycle, billing, and operational responsibilities. The architect also needs to consider how centralized controls can coexist with application-team autonomy.

That is a recurring pattern across the two exams: AZ-104 works inside the model; AZ-305 helps define the model.

Storage: administration focuses on configuration, architecture focuses on data characteristics

Azure offers multiple storage options, and administrators need to know how to deploy and secure them. That can include storage accounts, access controls, networking restrictions, redundancy settings, lifecycle management, encryption, and monitoring.

Architecture asks a different set of questions. What access pattern does the application have? Is the data structured, unstructured, relational, or analytical? What consistency, latency, throughput, retention, and durability characteristics matter? Does the data need regional or global distribution? What recovery point is acceptable? Are there sovereignty or compliance limits? How will cost grow as the dataset scales?

An architect might conclude that a particular storage approach is appropriate, but that recommendation is only credible if the architect understands the operational implications. A choice that requires complex identity, networking, replication, or backup processes must be supportable by the team that will run it.

This is why AZ-104 knowledge is not separate from architecture. Administration supplies the reality behind the design decision.

Compute: AZ-104 manages workloads, AZ-305 selects the operating model

AZ-104 candidates need to understand how Azure compute resources are deployed and maintained. Virtual machines, scale behavior, availability, images, extensions, containers, and related services become operational tasks. The administrator needs to know how compute interacts with storage, identity, networks, monitoring, and backup.

AZ-305 asks which compute approach fits the workload. Should the solution use virtual machines because the application requires operating-system control? Is a platform service preferable because it reduces infrastructure management? Would containers improve portability or deployment consistency? Does serverless execution match the event pattern? How much control does the organization need, and what operational burden can it support?

Architecture maturity means avoiding simplistic rules such as “managed services are always better” or “virtual machines are safer because we control them.” The correct choice depends on workload requirements, modernization goals, dependency constraints, team capabilities, cost, reliability, and security.

Networking: administrators implement paths; architects decide how connectivity should work

Networking is one of the strongest overlaps between AZ-104 and AZ-305. Administrators need to manage virtual networks, subnets, name resolution, security rules, connectivity, and monitoring. They must understand why a workload is or is not reachable and how Azure networking constructs influence traffic.

Architects decide how networks should be segmented, how on-premises environments should connect, how applications should be published, how private access should work, where security inspection belongs, how DNS should be designed, and how connectivity supports resilience and scale.

Suppose an organization has two data centers, several Azure regions, and hundreds of workloads. An AZ-104-level task might be to implement a virtual network peering or troubleshoot name resolution. An AZ-305-level task is to decide the broader connectivity model: hub-and-spoke, virtual WAN, regional segmentation, routing control, private endpoints, hybrid connectivity, and security inspection patterns.

The architect must understand the blast radius of that decision. Centralized connectivity can simplify control but create dependencies. Highly distributed networking can improve autonomy but increase complexity. The design should make those trade-offs explicit.

Monitoring and operations are not afterthoughts in either path

AZ-104 includes monitoring because operating a cloud environment requires visibility. Administrators need to collect and interpret metrics, logs, alerts, health information, and configuration state. They also need to know how to respond when resources are unhealthy.

AZ-305 must treat operability as a design requirement. A system that cannot be monitored, diagnosed, backed up, patched, or recovered is not well architected. The architect should define what telemetry is needed, how logs are retained, what alerts matter, how responsibilities are divided, and what operational tooling is realistic.

This is where hands-on administration strongly improves architecture. Administrators know what noisy alerts look like, how permissions complicate troubleshooting, how diagnostic settings can be inconsistent, and how small design decisions create operational toil. Architects with that experience are more likely to design systems that can actually be supported.

Business continuity separates configuration from design thinking

An administrator may configure backup, replication, failover tooling, and recovery procedures. The architect must first determine what level of continuity is required.

That means translating business impact into recovery objectives, identifying dependencies, deciding which components need redundancy, determining where data must be replicated, and understanding whether the application itself can tolerate failover. A multi-region design is not automatically resilient if identity, DNS, secrets, pipelines, or external dependencies remain single points of failure.

Architecture also requires distinguishing high availability from disaster recovery. Redundant instances in one region can reduce local service interruption but may not address a regional outage. Cross-region replication may protect data but still require an application failover process. Backups may help recover from corruption but not meet a low recovery-time objective.

AZ-104 gives you the tools. AZ-305 asks you to assemble them around explicit resilience goals.

Security: administrators enforce controls, architects place trust boundaries

Security responsibilities overlap heavily. AZ-104 administrators implement access controls, network restrictions, identity protections, secure resource settings, and monitoring. They need to understand least privilege and the operational consequences of security configurations.

AZ-305 architects think in terms of trust boundaries, threat exposure, control placement, and end-to-end design. Which identities should be human, workload, or managed? Where should public exposure be eliminated? Which data paths need private connectivity? Where is encryption terminated? How does privileged administration occur? How will policy enforce standards across subscriptions?

A secure design is not a pile of individual security features. It is a coherent model that reduces unnecessary trust and makes control behavior predictable. Administrators then turn that model into working configuration.

Cost is part of architecture, but administration affects cost every day

AZ-305 requires cost-aware design because architecture determines major spending patterns. Region count, redundancy, data movement, service tier, retention, compute model, and scaling approach can all change cost substantially.

Administrators influence cost through operation. Unused resources, oversized virtual machines, excessive log retention, abandoned disks, uncontrolled snapshots, inefficient scaling, and test environments left running can produce waste even when the original design was sound.

The architect should therefore design for cost visibility and operational control. Tagging, budgets, ownership, scaling rules, lifecycle policies, and review processes should be part of the solution. Administrators provide the feedback loop that shows whether those controls work in practice.

AZ-104 is usually the stronger first step for hands-on cloud roles

If you are new to Azure operations, AZ-104 is usually the more practical starting point. The certification develops the skills needed to manage real Azure environments and teaches how identity, networking, compute, storage, governance, and monitoring interact.

Typical roles include cloud administrator, Azure administrator, infrastructure engineer, cloud operations engineer, systems administrator moving into Azure, and support engineers responsible for cloud resources. These roles benefit from being able to deploy, configure, diagnose, and maintain resources directly.

Even if your long-term goal is architecture, administration gives you valuable credibility. It is easier to evaluate design trade-offs when you have experienced operational consequences firsthand.

AZ-305 is better aligned to architecture and technical design responsibility

AZ-305 becomes relevant when your work shifts toward selecting patterns rather than merely implementing them. Solutions architects advise stakeholders, translate requirements into designs, compare services, document decisions, identify trade-offs, and align solutions with governance and architecture frameworks.

This role requires broad technical understanding, but also communication. An architect must explain why a design meets requirements and what risks remain. The design should be understandable to security teams, administrators, developers, business owners, and decision makers.

Typical responsibilities include architecture reviews, migration design, landing-zone decisions, identity and governance design, continuity planning, network topology, workload placement, cost optimization, and design governance.

The certifications are complementary rather than competitive

AZ-104 and AZ-305 solve different problems, so asking which is “better” misses the relationship. AZ-104 builds the operational substrate that good architecture depends on. AZ-305 teaches you to use that substrate deliberately.

A candidate can study AZ-305 without first earning AZ-104, but gaps in hands-on experience can make architectural choices feel theoretical. If you have never operated role assignments, network security groups, private endpoints, backups, monitoring, or virtual networks, it is harder to judge their operational complexity.

Likewise, an administrator can benefit from AZ-305 concepts even without changing job titles. Understanding why the environment was designed a certain way helps administrators troubleshoot more effectively and identify architectural weaknesses rather than only local configuration issues.

A realistic migration scenario shows the difference

Imagine an organization moving a legacy customer portal from two on-premises data centers to Azure. The application uses a relational database, file storage, scheduled jobs, Active Directory integration, and a third-party payment service.

The AZ-305-oriented architect begins with requirements. What uptime is required? How much downtime is acceptable during migration? What are the recovery objectives? Can the application be modernized, or must it remain on virtual machines? Does the database need a managed service? How will identity integrate? Is private connectivity required? Which region or regions are appropriate? What data-residency rules apply? How will monitoring, backup, and security be handled?

The AZ-104-oriented administrator implements the chosen model. That may include subscriptions, resource groups, virtual networks, network security, identity assignments, virtual machines or platform resources, storage, monitoring, backup, policies, and operational access. During migration, the administrator validates connectivity, watches performance, troubleshoots access, and confirms that operational tooling works.

If the design creates unexpected DNS issues, excessive permissions, or unreliable backup, administration feeds evidence back into architecture. Mature cloud programs treat this as a loop rather than a one-time handoff.

A troubleshooting scenario shows why administrators need architecture awareness

Suppose an application is intermittently unavailable after a regional traffic-management change. An administrator might first inspect service health, backend status, routing, DNS, load-balancer health probes, network rules, and logs. That operational work is necessary.

Architecture awareness helps the administrator ask bigger questions. Was the application designed for active-active or active-passive operation? Are sessions stateful? Is the database writable in both regions? Does DNS TTL match the failover model? Are secrets and identities available regionally? Does the secondary environment have equivalent capacity? Is traffic being sent somewhere the application was never designed to support?

That is the point where AZ-104 and AZ-305 knowledge reinforce each other. The administrator can isolate the immediate failure while recognizing whether the real cause is design.

A design-review scenario shows why architects need administration awareness

Now reverse the situation. An architect proposes private endpoints for multiple platform services, centralized DNS, strict policy enforcement, and a hub network with shared inspection. The diagram is secure and elegant.

An administrator asks how DNS zones will be linked, who owns route tables, how exceptions are requested, how policy conflicts are resolved, how troubleshooting works when traffic crosses the inspection layer, how logs are retained, and what happens when a shared dependency fails. Those questions may reveal that the design needs clearer operational boundaries.

Good architects welcome that feedback. Architecture quality is partly measured by how well the environment can be operated under pressure.

Study AZ-104 through repeated operations

For AZ-104, reading should lead quickly to hands-on work. Create identities and role assignments, organize resources, configure policy, deploy storage and compute, build virtual networks, test connectivity, configure monitoring, and practice backup and recovery. Then deliberately break permissions, name resolution, routes, or service access and diagnose the result.

Keep a small operations notebook. For each lab, record the intended state, what you changed, how you verified it, what failed, and what evidence revealed the cause. That develops the habits of an administrator rather than the memory of a test taker.

Pay special attention to scope. Many Azure mistakes come from applying a correct concept at the wrong scope: a role assignment that is too broad, a policy at the wrong level, a network rule on the wrong subnet, a diagnostic setting missing one resource type. Operational precision matters.

Study AZ-305 through written decisions

For AZ-305, architecture diagrams are useful, but written reasoning is even more important. Take a requirement and list at least two viable designs. Compare them across availability, security, cost, operational complexity, performance, migration effort, governance, and team capability. Then choose one and explain why.

Practice with imperfect requirements. Real stakeholders rarely say, “We need active-active multi-region with a five-minute RPO.” They say, “The customer portal cannot go down during business hours.” Your job is to uncover what that actually means, quantify it, and design accordingly.

Architecture practice should also include rejection. Explain why a technically impressive option is unnecessary. Avoiding needless complexity is part of good design.

Which exam should you take first?

Choose AZ-104 first when you need hands-on Azure administration skills, are moving from on-premises systems into cloud operations, or do not yet have strong experience managing Azure resources. It gives you concrete knowledge that will make later architecture study more grounded.

Choose AZ-305 when you already understand Azure operations and your role increasingly involves solution design, requirements analysis, technical leadership, architecture reviews, or migration planning. If you find yourself deciding between services and documenting trade-offs more often than implementing standard resource configurations, architecture study is likely timely.

For many professionals, the natural sequence is administration first and architecture second. The value of that sequence is not a certification ladder for its own sake. It is that operating Azure teaches you what design choices feel like in production.

The real progression is from “make it work” to “make the right thing work”

AZ-104 teaches you how to make Azure resources function securely and reliably in day-to-day operations. AZ-305 teaches you how to decide which resources, patterns, and boundaries should exist in the first place.

The administrator’s success is visible in healthy, governed, supportable services. The architect’s success is visible in a design that meets requirements without unnecessary complexity and can be implemented and operated by real teams.

If your career is moving toward Azure operations, AZ-104 is the stronger fit. If it is moving toward Azure solution design, AZ-305 is the stronger fit. If you want to become an excellent architect, learn both ways of thinking: understand the platform deeply enough to operate it, and understand the business well enough to design it deliberately.

Landing zones are a useful way to see the role boundary

A landing zone is not just a collection of Azure resources. It is an operating and governance foundation that determines how future workloads will be organized, connected, secured, monitored, and delegated. That makes it a particularly good example of the relationship between administration and architecture.

An architect may define the management-group hierarchy, subscription strategy, identity boundaries, network topology, policy approach, centralized services, logging model, and workload onboarding pattern. Those decisions need to reflect the organization’s size, regulatory obligations, operating model, and degree of centralization. A company with a small platform team and a handful of workloads should not automatically copy the same model used by a multinational enterprise with hundreds of application teams.

Administrators then make the landing zone real. They create and manage the structures, implement policy, configure role assignments, deploy shared networking, validate logging, handle exceptions, and troubleshoot workload onboarding. This operational work quickly exposes architectural weaknesses. If every new workload needs manual routing exceptions, if policy assignments conflict unpredictably, or if central teams become bottlenecks for basic changes, the landing zone may be technically sound but operationally poor.

The lesson for AZ-305 candidates is to design for repeatability and ownership. The lesson for AZ-104 candidates is to understand the intent behind the shared platform so that implementation does not drift into a set of unrelated fixes.

Hybrid connectivity requires both implementation precision and architectural restraint

Many Azure environments remain hybrid for years. Connecting on-premises networks to Azure therefore becomes another strong comparison point. At the administration level, you need to understand address spaces, gateways, routing, DNS, connectivity state, security rules, and monitoring. Misconfigured prefixes or asymmetric routes can break access even when every individual component appears healthy.

At the architecture level, the first question is not “VPN or ExpressRoute?” It is what connectivity characteristics are required. How much bandwidth is needed? What latency is acceptable? How critical is the connection? Is encryption required over the provider path? How many sites connect? Is there a need for redundant circuits? Which traffic should traverse the hybrid link, and which should remain local to the cloud? How will route propagation interact with firewalls and regional hubs?

Overdesign is a real risk. An architect may propose multiple redundant connectivity layers for a workload whose business impact does not justify the complexity. Underdesign is equally risky when a critical application depends on a single unmanaged path. AZ-305 teaches you to make that decision explicit. AZ-104 teaches you to keep the chosen design operating.

Data protection decisions are broader than selecting a backup feature

Administrators configure backup, retention, vaults, permissions, and restore operations. They also need to monitor jobs, investigate failures, and prove that data can be recovered. These are AZ-104-style responsibilities.

Architecture asks what failure the organization is trying to survive. Accidental deletion, ransomware, application corruption, regional outage, operator error, and long-term retention are different problems. A single backup configuration may not address all of them. The architect needs to consider recovery time, recovery point, immutability, cross-region protection, identity separation, testing, and dependency recovery.

A classic design mistake is to specify replication and call it backup. Replication can copy corruption quickly. Another is to retain backups but never test restoration. The operational and architectural views meet when recovery exercises reveal whether the design assumptions are true.

Candidates studying both exams should practice a recovery scenario from end to end. Decide what the business requires, choose a design, implement protection, simulate failure, restore, measure the result, and compare it with the target. That exercise teaches more than memorizing product feature tables.

Architecture decisions should be reversible where practical

One advanced habit that separates strong architects from product enthusiasts is attention to reversibility. Some decisions are easy to change later; others create deep migration cost. Choosing a resource tag format is relatively easy to revise. Choosing a tightly coupled proprietary data architecture, a global network topology, or an identity model can be much harder.

AZ-305 preparation should include asking, “If this assumption is wrong in two years, how expensive is the change?” That does not mean avoiding managed Azure services. It means understanding commitment. A service can be an excellent choice even when it increases platform dependence if the benefits outweigh the future switching cost.

Administrators provide important evidence here because they know where the environment has accumulated hidden coupling. Scripts, policies, monitoring rules, permissions, deployment pipelines, DNS, and operational runbooks can make a seemingly simple service change much larger than an architecture diagram suggests.

Common preparation mistake: treating AZ-305 as memorizing which service wins

Architecture questions are tempting to study as product-selection flashcards: use one service for scenario A, another for scenario B. That approach breaks down when multiple services are technically possible. The real skill is identifying the requirement that differentiates them.

When comparing options, state the decision criteria explicitly. Is the main constraint latency, control, operational effort, compatibility, recovery, data residency, scale, or cost? If the requirement changes, the answer may change. This reasoning is far more durable than remembering a list of “best services.”

For AZ-104, the equivalent mistake is memorizing portal steps without understanding resource relationships. Interfaces change. Operational concepts remain. Know what the resource needs, how it authenticates, where it gets network connectivity, how it is monitored, and which scope controls it.

Build a joint portfolio project if you want to move from administration to architecture

A strong transition project begins with a fictional or real workload and carries it through both roles. Write a short requirement set for an internal application: number of users, availability target, data sensitivity, expected growth, on-premises integration, recovery needs, and budget constraints. Design the Azure solution as an architect. Document alternatives and trade-offs.

Then implement a small version as an administrator. Configure identity, network segmentation, compute or platform services, storage, monitoring, policy, backup, and operational access. Introduce failures and recover. Record where the design was easy to implement and where it created unexpected complexity.

Finally, revise the architecture based on operational evidence. Perhaps centralized routing created unnecessary dependencies. Perhaps a managed identity simplified secrets. Perhaps monitoring was too fragmented. Perhaps backup met retention but not restoration-time goals. That feedback loop is exactly what mature cloud engineering looks like.

The exercise also gives you useful material for interviews. Instead of saying you “know architecture,” you can explain a requirement, the alternatives you considered, why you chose one, how you implemented it, what failed, and what you changed. That demonstrates both AZ-104 and AZ-305 ways of thinking.

Practice the handoff between an administrator and an architect

One of the best combined labs is to write a short architecture decision and then implement enough of it to discover whether the decision was realistic. Start with a requirement such as a two-region application that must survive a regional outage, use private data access, support centralized identity, and keep operating costs controlled. In the AZ-305 role, define the major design choices: identity boundaries, regional topology, storage or data protection approach, business-continuity pattern, network connectivity, monitoring, and the reasons behind each choice.

Then switch to the AZ-104 role. Deploy a reduced version of the design or map each design element to an administrative task. Create the resource organization, permissions, networking, compute, storage, monitoring, and recovery settings. Record which design assumptions created operational complexity. Perhaps the proposed network requires DNS work that the design did not mention, or the recovery strategy depends on permissions and automation that were never assigned.

Finally switch back to architecture and revise the decision. This loop teaches a skill that neither exam should be studied without: designs must be operable. AZ-305 candidates become better architects when they understand what administrators must maintain, while AZ-104 candidates become better administrators when they understand why resources were organized in a particular way. In real Azure teams, the most valuable boundary is not where one job ends and the other begins; it is the quality of the handoff between architectural intent and daily operations.