From Azure Administrator to Solutions Architect: How AZ-104 Skills Support the AZ-305 Path

 

The move from Azure administration to solutions architecture is not a simple promotion from one exam code to another. AZ-104 and AZ-305 overlap in services, but they ask different questions about those services. The administrator is expected to implement, operate, secure, monitor, and troubleshoot Azure resources. The architect is expected to translate requirements into designs, compare alternatives, manage trade-offs, and align solutions with security, reliability, performance, cost, governance, and organizational constraints.

That makes AZ-104 an excellent skills foundation for AZ-305 even when the journey is not a literal “pass AZ-104, then memorize AZ-305” sequence. Operational experience gives architecture decisions weight. Someone who has debugged identity, networking, storage, compute, policy, monitoring, backup, and deployment problems has seen how apparently small design choices create day-two consequences. The missing step is learning to turn that experience into explicit design reasoning.

Current AZ-104 skills effective April 17, 2026 cover identity and governance, storage, compute, virtual networking, and monitoring and maintenance. Current AZ-305 skills effective April 17, 2026 expect design across cloud and hybrid solutions, including compute, network, storage, monitoring, and security, while translating business requirements and using Azure Well-Architected Framework and Cloud Adoption Framework ideas. The bridge is therefore less about learning entirely new product categories and more about changing the level at which you reason about them.

Administration asks whether it works; architecture asks whether it should work this way

An administrator receives a defined environment and makes it operate correctly. An architect may need to decide what the environment should be before it exists. That changes the question type.

For networking, the administrator may create virtual networks, subnets, routes, private endpoints, load balancers, VPN connections, and security rules. The architect asks which connectivity pattern best satisfies latency, isolation, hybrid integration, resilience, operational skill, and cost requirements. A technically valid hub-and-spoke design is not automatically the right answer if it creates unnecessary centralization or management burden.

For storage, the administrator configures accounts, access, lifecycle, replication, and monitoring. The architect decides which storage pattern fits data durability, consistency, access, performance, region, compliance, recovery, and cost requirements. For compute, the administrator deploys and maintains resources. The architect compares virtual machines, managed app platforms, containers, serverless, and other services by operational control, scaling, portability, startup behavior, failure domains, and team capabilities.

The mechanisms transfer from AZ-104. The decision model is what AZ-305 adds.

Identity and governance: move from assignments to control architecture

AZ-104 teaches administrators to manage identities, access, subscriptions, resource groups, policy, and governance. Those are essential architecture inputs. The architect must decide how management groups, subscriptions, resource groups, RBAC, policy, and identity boundaries should reflect organizational structure and risk.

Suppose a company is entering three countries and must separate regulated workloads while keeping central platform operations. An administrative answer might describe creating subscriptions and assigning roles. An architectural answer explains why subscriptions are separated, which policies are inherited, where central services live, how platform teams receive access, how application teams are constrained, how logs are centralized, and how the design can accommodate future regions.

Governance design should avoid both extremes. Too little governance creates inconsistency, security gaps, cost sprawl, and support difficulty. Too much centralized control creates delivery bottlenecks and teams that work around the platform. The architect needs a model that makes compliant delivery easier than noncompliant delivery.

Networking: evolve from configuration to traffic and failure architecture

AZ-104 gives administrators broad virtual-networking competence. To move toward AZ-305, add deeper reasoning about traffic flow, private access, hybrid connectivity, DNS, application delivery, resilience, and operational ownership. AZ-700 material can be a useful specialization when networking is a major gap, but the architecture candidate does not need to turn every design into a network engineering project.

For each workload, draw traffic paths. Identify source, destination, DNS resolution, routing, inspection, authentication, encryption, load balancing, and failure behavior. Then ask what changes during regional failure or hybrid outage. If a service uses private endpoints, where is name resolution hosted? Can on-premises clients resolve and route correctly? What happens if central DNS or a firewall fails? Does the design create hidden dependencies that undermine the advertised availability?

Architecture is often the process of discovering that a “secure” design has become operationally fragile or that a “simple” design violates a control requirement. The right answer balances both.

Compute: move from resource management to workload placement

AZ-104 candidates learn to manage virtual machines and other compute resources. AZ-305 candidates need to decide which compute model fits the workload. That decision should begin with requirements rather than preference.

Virtual machines provide control but increase operating responsibility. Managed application platforms can reduce patching and infrastructure management but impose platform constraints. Containers can package applications consistently and support sophisticated deployment patterns, but orchestration adds complexity. Serverless functions can be efficient for event-driven workloads but have runtime, integration, latency, and observability considerations.

Create a workload-placement worksheet. Record runtime requirements, state, scaling pattern, deployment frequency, network dependencies, compliance, latency, portability, team skills, operating-hours pattern, and tolerance for platform constraints. Compare at least two compute options. The architecture answer is the explanation, not merely the selected service.

Storage: reason from data behavior and recovery objectives

Administrators configure storage; architects decide storage architecture. Start with the data. Is it transactional or analytical? Structured or unstructured? Frequently accessed or archival? Mutable or append-only? What are the latency and throughput needs? How much data exists now and in three years? Which regions may store it? What recovery point and recovery time are required?

Then evaluate durability, replication, consistency, access patterns, network exposure, encryption, key management, backup, lifecycle, and cost. A more redundant option is not always automatically better if it creates unnecessary cost or does not solve application-level recovery. Conversely, a cheap design can be unacceptable if the business cannot recreate lost data.

Practice failure scenarios. What if the application deletes data accidentally? What if a region is unavailable? What if credentials are compromised? What if a storage tier change affects latency? Architecture should distinguish availability, durability, backup, replication, and recoverability rather than treating them as synonyms.

Monitoring: move from alerts to observability architecture

AZ-104 includes monitoring and maintenance. The architect should expand this into an observability design. Which signals are required to detect user impact? Which metrics indicate saturation or dependency failure? Which logs are needed for operations, security, and audit? How long should data be retained? Which alerts require immediate response and which should become trend analysis?

Good observability follows the workload, not the product list. An application may require user-experience monitoring, application traces, dependency calls, platform metrics, infrastructure logs, network telemetry, security events, and business transaction signals. The design should support incident diagnosis without collecting unlimited data at unlimited cost.

A useful exercise is to write an incident before designing monitoring. For example: checkout latency rises in one region, but compute utilization is normal. What telemetry would let the team isolate DNS, a downstream API, database throttling, network path, or application code? If the answer requires adding logs after the outage, the architecture was not observable enough.

Backup and recovery: move from configured jobs to business continuity

An administrator can confirm that backup jobs succeeded. An architect must prove that the business can recover. Start with workload-level RTO and RPO, not a list of backup features.

Map components and dependencies. Which data can be recreated? Which must be restored? Are backups stored in a failure domain independent of the production workload? How are secrets and infrastructure recovered? Does the application require coordinated recovery across databases, storage, and messaging? How long does DNS or traffic failover take? Who declares a disaster?

Run recovery exercises. A successful restore in a test environment exposes assumptions that dashboards cannot. Measure time. Document manual steps. Verify identity and networking. Validate data consistency. Architecture quality becomes visible during recovery.

Cost: architecture is responsible for economic behavior

AZ-104 candidates encounter cost management and resource sizing. AZ-305 candidates should reason about cost as a system property. A design can be technically excellent and financially unsustainable.

Estimate fixed and variable costs. Identify scale drivers. Understand whether high availability doubles or triples certain components. Consider data transfer, log ingestion, backups, idle capacity, licensing, managed-service premiums, and operational labor. Compare the cost of simplicity against the cost of platform management.

Cost optimization should not mean choosing the cheapest service. It means aligning spend with business value and risk. A critical system may justify expensive redundancy. A development environment may not. An architecture decision record should make that distinction explicit.

Security: move from control configuration to trust boundaries

Administrators implement RBAC, network controls, keys, secrets, encryption, and policy. Architects design the trust model. Identify actors, assets, entry points, data classifications, trust boundaries, administrative paths, and threat scenarios before choosing controls.

For a customer-facing application, separate user identity, workload identity, operator identity, and service-to-service identity. Decide where authentication happens, how authorization is enforced, how secrets are avoided or rotated, how administrative access is restricted, how data is protected, how network exposure is minimized, and which telemetry supports detection.

The security architecture should also account for failure and exception. How is emergency access handled? What happens if the identity provider is unavailable? How are privileged actions audited? Can one compromised service identity access every downstream system? Security controls that cannot be operated safely are incomplete.

Availability: count dependencies, not just zones

A common architecture mistake is to declare a system highly available because the main compute tier spans availability zones. The actual availability is determined by the weakest critical dependency.

Map every required dependency: identity, DNS, network appliances, data stores, messaging, secrets, external APIs, monitoring, and deployment systems. Determine which are zonal, regional, or global. Check whether redundant compute instances still depend on a single database, one firewall, one on-premises circuit, or one manual operational process.

Then distinguish service availability from business continuity. Multi-zone design protects against certain failures. Regional disaster recovery addresses a different set. Backup protects against data loss but may not meet low RTO. The architect should be precise about what each mechanism solves.

Reliability: design for change as well as failure

Most outages are not dramatic hardware failures. They come from change: deployments, configuration, dependency updates, certificate expiry, permission changes, quota, schema changes, or unexpected traffic. Architecture should make change safer.

Use infrastructure as code, staged deployment, health checks, feature flags where appropriate, backward-compatible interfaces, deployment rings, and rollback or forward-fix strategies. Reduce blast radius. Separate failure domains. Make observability part of release criteria.

AZ-104 operations experience is valuable here because administrators see change failures directly. The architect’s job is to design systems and processes that make those failures less likely and easier to recover from.

Migration: architecture begins before the target Azure design

Many AZ-305 scenarios involve existing systems. The architect must understand the current environment, constraints, dependencies, data gravity, operational processes, and business timelines before choosing a target design.

Avoid jumping directly to replatforming. Classify workloads. Some may be retired, replaced, retained, rehosted temporarily, replatformed, or refactored. A migration path should account for identity, networking, data transfer, downtime, testing, rollback, licensing, team skills, and coexistence with on-premises systems.

A beautiful target architecture can still fail if the migration path is unrealistic. Include transition states in the design.

The AZ-104 lab becomes an AZ-305 case study

One of the best ways to bridge the exams is to reuse an administrator lab. Take an environment you can already operate and turn it into an architecture exercise.

Document the current state. Add business requirements: 99.9 or 99.99 availability, defined RTO/RPO, sensitive data, two geographic user populations, a budget ceiling, and a small operations team. Identify weaknesses. Propose a revised design. Compare two alternatives. Estimate cost. Draw identity and network boundaries. Define monitoring and recovery. Write migration steps.

Then implement enough of the preferred design to discover hidden assumptions. Architecture improves when it is tested by operation.

Use architecture decision records to change your thinking

An architecture decision record is a short document that captures context, decision, alternatives, and consequences. It is a powerful AZ-104-to-AZ-305 bridge because administrators often make decisions implicitly while architects must make them explicit.

Write records for network topology, compute platform, data store, identity pattern, logging, backup, deployment, and regional strategy. For each, state the requirement that drives the choice. Name at least one rejected alternative and why it was rejected. Record negative consequences of the selected option as well as benefits.

If every decision has only advantages, the analysis is incomplete. Real architecture involves trade-offs.

Scenario: private endpoints everywhere create an outage

A team adopts a rule that every Azure PaaS service must use private endpoints. The security goal is understandable: reduce public exposure. After implementation, development teams experience intermittent access failures, on-premises clients resolve the wrong addresses, and disaster-recovery testing reveals that DNS dependencies are tied to one region.

The administrator can troubleshoot private DNS zones, links, routes, and endpoint configuration. The architect must step back. Which services truly require private access? What is the DNS architecture? How do hybrid clients resolve names? Where are central dependencies? How will regional failover work? What operational skill does the organization have?

The lesson is not that private endpoints are bad. It is that a security mechanism becomes an architecture when it is applied at scale. Its dependencies and failure modes must be designed.

Scenario: the cheapest compute option increases operational cost

A team chooses virtual machines because the hourly price appears lower than a managed platform. Months later, engineers spend significant time patching operating systems, maintaining autoscaling scripts, managing certificates, and troubleshooting deployment drift. The nominal infrastructure savings are smaller than the operational cost.

An AZ-305-style analysis compares total cost of ownership, not only resource price. Managed services can cost more per unit while reducing labor, failure risk, and time to change. Conversely, a managed platform can become expensive or restrictive for a workload that needs custom runtime control.

The correct decision depends on workload and team. Architecture makes the economic assumptions visible.

Scenario: backup is green but recovery is impossible within the RTO

A database shows successful nightly backups. The business requires a two-hour recovery time. During a disaster test, restore takes four hours, application configuration must be rebuilt manually, DNS changes take additional time, and the team cannot find the latest secret configuration.

The administrator has a successful backup operation; the architecture does not meet continuity requirements. The fix may include faster restore mechanisms, infrastructure as code, configuration backup, tested runbooks, staged replicas, or a different resilience strategy.

This is exactly why AZ-305 reasoning is not a collection of Azure features. It connects technical mechanisms to business outcomes.

Scenario: global users expose a data-residency conflict

A SaaS application needs low latency in Europe, North America, and Asia, but customer records for one regulated market must remain in-region. A simple global active-active design may violate residency requirements; a simple regional silo may hurt user experience and complicate operations.

The architect must decompose data. Which data is regulated? Which can be replicated globally? Can identity and metadata be global while sensitive records remain regional? How will requests be routed? How will analytics work? What happens during failover? Which support staff can access the data?

AZ-104 skills help implement subscriptions, networks, storage, access, and monitoring. AZ-305 asks the candidate to reconcile the requirements into a defensible design.

Know when AZ-700 depth would strengthen the path

Not every aspiring architect needs AZ-700 certification, but architects with weak networking should deepen that domain. Warning signs include difficulty tracing traffic, weak DNS knowledge, uncertainty around hybrid routing, inability to explain private endpoint behavior, or treating firewalls as magic boxes.

Use the Azure certification roadmap to decide whether a networking specialization fits your role. Even without taking AZ-700, architecture candidates should be able to reason confidently about connectivity and failure.

Know when security specialization would strengthen the path

Similarly, architecture candidates should deepen security if they rely on generic phrases such as “use Zero Trust” without being able to translate them into identity, privilege, network, application, data, monitoring, and governance controls.

SC-300, SC-500, SC-100, and adjacent security study can fill different gaps. The goal is not to collect every security exam. It is to make sure your architecture decisions are grounded in real control mechanisms and threat models.

A 12-week bridge plan from AZ-104 skills to AZ-305 thinking

Weeks one and two: inventory your operational experience. Identify weak domains in identity, networking, storage, compute, monitoring, backup, and governance. Close the most serious implementation gaps.

Weeks three and four: create architecture decision records for your existing lab. Force every resource choice to have a requirement and an alternative.

Weeks five and six: add reliability and recovery. Define RTO/RPO, failure domains, backup, failover, observability, and change strategy. Run at least one recovery exercise.

Weeks seven and eight: add security and governance. Draw trust boundaries, administrative paths, data classifications, policy inheritance, and logging. Threat-model the system.

Weeks nine and ten: create two new case studies with different constraints—for example, a regulated hybrid workload and a global web application. Compare design alternatives instead of implementing everything.

Weeks eleven and twelve: use exam-style scenarios to diagnose reasoning gaps. For every missed question, write why the preferred option fits the stated requirement and why the alternatives fail. Do not merely memorize the answer pattern.

Readiness signals for AZ-305

You are moving toward architecture readiness when you can take a vague requirement and turn it into measurable quality attributes; compare two technically valid solutions; identify hidden dependencies; reason about recovery, cost, security, and operations; document consequences; and change your recommendation when requirements change.

You are not ready if every answer is “use the most managed service,” “use private endpoints,” “use availability zones,” or another universal slogan. Those can be excellent choices in the right context. Architecture skill is knowing when the context makes them appropriate.

AZ-104 is the foundation because consequences teach architecture

The strongest link between AZ-104 and AZ-305 is not exam content overlap. It is operational consequence. Administrators learn what breaks, what is difficult to support, where permissions fail, how network assumptions collapse, what monitoring misses, and how recovery actually behaves. Architects turn those lessons into designs that reduce risk before deployment.

Use your AZ-104 skills as evidence, not as a checklist. For each administrative capability, ask what architecture decision created the need for it and how a different design would change operations. When you can answer that consistently, you are no longer just operating Azure—you are reasoning about why the Azure system is shaped the way it is.

Learn to convert vague business statements into architecture requirements

Many architecture mistakes begin before a service is selected because the requirement itself is imprecise. “The application must be highly available” is not enough. Ask what amount of downtime is acceptable, which business functions are critical, whether planned maintenance counts, which geographic failures matter, how data loss is measured, and what user experience is required during degradation.

“The system must be secure” is similarly weak. Clarify the data classification, user populations, administrator model, regulatory obligations, allowed network exposure, authentication requirements, logging, incident response, and recovery expectations. “The solution must be cheap” should become a budget range, growth assumption, and willingness to trade operational labor against service cost.

Practice rewriting requirements into measurable statements. This makes service selection easier because you are comparing options against evidence instead of preference.

Use Well-Architected ideas as trade-off prompts, not slogans

The Azure Well-Architected Framework is useful because it forces attention to reliability, security, cost optimization, operational excellence, and performance efficiency. The mistake is to treat the pillars as independent checkboxes. Improvements in one area can create pressure in another.

Adding redundancy can improve reliability but increase cost and deployment complexity. Aggressive caching can improve performance but complicate consistency. Tight network isolation can improve exposure control but make operations and recovery harder. Extensive telemetry can improve observability but increase cost and potentially capture sensitive data.

For every major design decision, ask which quality attributes improve, which become harder, and what compensating controls are required. That is much closer to real architecture than selecting a service because a reference diagram used it.

Cloud Adoption Framework thinking adds organizational reality

Architecture is not only workload design. Enterprise Azure environments need landing zones, identity, policy, connectivity, management, security, platform ownership, and operating processes. A workload design that ignores those foundations may not be deployable in the real organization.

When preparing for AZ-305, place at least some case studies inside an enterprise context. Assume central platform teams own networking and policy. Application teams have limited subscription rights. Security requires centralized logs. Finance requires tagging and chargeback. The company has an on-premises estate and a staged migration program.

Now ask whether the workload design fits the platform. Does it require exceptions? Who approves them? Does the network pattern align with enterprise connectivity? Can the monitoring integrate with central operations? Architecture must fit the organizational system as well as the technical system.

Communication is part of architecture competence

An architect who cannot communicate trade-offs will struggle even with strong technical knowledge. Practice explaining the same decision to different audiences. A network engineer may need route and DNS detail. A security team needs trust boundaries and evidence. Finance needs cost drivers. An application team needs deployment constraints. Executives need risk, value, and options.

Use one-page decision summaries. State the problem, recommendation, key assumptions, major benefits, major risks, cost implications, and unresolved decisions. Keep diagrams focused on the question they are meant to answer. A diagram containing every Azure icon is rarely a good communication artifact.

This skill also improves exam reasoning because it forces you to identify the requirement that actually matters in a scenario.

Build a dependency graph for every critical workload

List the components required for a user transaction to succeed, then connect their dependencies. Include identity, DNS, networking, certificates, secrets, compute, data, messaging, external APIs, and configuration services. Mark each dependency by failure domain and ownership.

This exercise often reveals hidden single points of failure. A multi-region application may depend on one region’s database, one on-premises identity service, one network appliance, or one manually managed certificate. It also reveals organizational dependencies: perhaps failover requires a person with a specific privileged role who is not on call.

Use the graph to design monitoring and recovery. If a dependency is critical, what signal proves it is healthy? If it fails, what does the application do? If recovery is manual, who performs it and how is access guaranteed during a crisis?

Add capacity and quota to architecture scenarios

Cloud resources feel elastic, but real systems encounter subscription quotas, service limits, regional capacity, API throttling, connection limits, and scaling delays. Administrators often discover these during incidents; architects should consider them earlier.

For a growth scenario, estimate resource counts, throughput, connections, addresses, route limits, storage transactions, or other relevant dimensions. Identify which limits are soft and which require architectural change. Plan capacity requests before peak events. Avoid designs where one central component becomes a scale choke point.

This is another way AZ-104 experience strengthens architecture: operational incidents reveal constraints that reference diagrams often omit.

Treat operational skill as an architecture requirement

A technically elegant design can fail if the team cannot operate it. Kubernetes, complex network virtualization, custom automation, or sophisticated multi-region data patterns may be appropriate, but only when the organization has the skills, monitoring, deployment discipline, and support model to manage them.

Include team capability in architecture decisions. A simpler managed platform with clear operational tooling can be safer than a theoretically flexible system that only one specialist understands. Conversely, a highly experienced platform team may justify a more complex design to achieve scale or control.

Architecture is responsible for the system people can actually run, not the system that looks most impressive in a diagram.

The final bridge is to explain consequences before implementation

An administrator often learns consequences after implementation: a route breaks traffic, a policy blocks deployment, a backup takes too long, or a permission creates exposure. An architect’s job is to anticipate as many of those consequences as possible before the organization pays for them.

That is the real AZ-104-to-AZ-305 transition. Keep the operational mechanics, but start asking earlier questions. What will this choice make easier? What will it make harder? What new dependency does it create? How will it fail? How will we observe it? How will we recover? Who will own it? How will cost change as usage grows?

When those questions become automatic, Azure architecture stops being a collection of best-practice diagrams and becomes disciplined engineering judgment.