Microsoft Azure Certification Roadmap

An Azure certification roadmap should not be read as a staircase of exam codes. Azure work is organized around responsibilities: understanding the platform, operating it, designing network connectivity, building applications, securing workloads, automating delivery, and designing systems that satisfy business constraints. Those responsibilities overlap, but they are not sequential in the same way for every professional. A network engineer can enter the Azure path through connectivity. A systems administrator may begin with AZ-104. An experienced developer may focus on Azure application skills and then DevOps. An architect may need operational depth before attempting design-level study, even if the architect exam itself does not require a particular administrator exam as a prerequisite.

The 2026 portfolio also makes historical roadmaps unreliable. AZ-204 retired on July 31, 2026, and AZ-500 retired on August 31, 2026. Their skill domains remain important, but the exams are no longer current scheduling targets. AZ-900, AZ-104, AZ-700, AZ-305, AZ-400, and newer security routes remain relevant in their respective domains. The practical task is therefore to map durable Azure capabilities to current credentials rather than preserve an old sequence after the credential catalog changes.

This roadmap uses six lenses: platform orientation, administration, development, networking, security, and architecture. DevOps acts as a connective discipline across development and operations rather than a separate island. The goal is to help you choose the shortest path that produces the role depth you need.

AZ-900: use fundamentals to build the Azure mental model

AZ-900 is useful when Azure is new enough that service names, responsibility boundaries, subscription structure, regions, availability concepts, pricing, governance, and shared responsibility still feel fragmented. The current exam covers cloud concepts, Azure architecture and services, and Azure management and governance. Its real value is not memorizing a catalog of services. It is learning how the platform is organized so that later implementation decisions have context.

A productive AZ-900 study process should answer questions such as: What belongs to a tenant versus a subscription? How do resource groups help organize lifecycle and policy? What is the relationship between regions, availability zones, and resiliency? Which controls govern access, cost, policy, and compliance? How do IaaS, PaaS, and SaaS shift operational responsibility? Those questions form a mental model that makes later role-specific learning faster.

Experienced infrastructure or cloud practitioners should not automatically treat AZ-900 as mandatory. If you can already explain the control plane, resource hierarchy, identity integration, core service categories, governance, and cloud responsibility models, an AZ-104 gap analysis may be more efficient. Fundamentals are a diagnostic tool, not a toll gate.

AZ-104: the operational anchor for most infrastructure paths

AZ-104 is the most useful Azure anchor for professionals who need broad operational competence. Current skills effective April 17, 2026 cover identity and governance, storage, compute, virtual networking, and monitoring and maintenance. Microsoft also expects practical familiarity with PowerShell, Azure CLI, the Azure portal, ARM or Bicep concepts, Entra ID, and foundational operating-system, networking, server, and virtualization knowledge.

The important word is operational. An administrator is not merely someone who can deploy a resource. The role includes lifecycle management: provisioning, changing, securing, monitoring, backing up, restoring, troubleshooting, and removing resources within governance constraints. The exam is therefore best prepared for through a small but complete environment rather than disconnected demos.

Build a lab with a clear subscription and resource-group strategy, RBAC assignments, policy, tagging, virtual networks, subnets, network security controls, virtual machines or app services, storage, monitoring, alerts, backup, and automation. Then introduce failure. Remove a permission, break DNS, misconfigure a route, hit a quota, deny a deployment through policy, interrupt a backup assumption, or create a monitoring blind spot. The troubleshooting process turns static configuration knowledge into administrative judgment.

AZ-104 also creates valuable adjacency. It gives an aspiring architect the implementation depth needed to evaluate whether a design is operable. It gives a security specialist context for identity, networking, compute, storage, and policy. It gives a network specialist a realistic understanding of the surrounding platform. This is why the AZ-104-to-AZ-305 bridge is a skills progression even when the certification catalog does not impose a simple exam prerequisite chain.

Azure development after AZ-204: keep the capability, retire the scheduling advice

AZ-204 historically represented Azure application development: compute solutions, storage, security, monitoring, service integration, APIs, SDKs, eventing, messaging, and deployment. The exam retired on July 31, 2026, so a current roadmap should not tell a learner to schedule it. However, abandoning the skill domain would be equally wrong. Azure still needs developers who can build secure, observable, resilient applications using platform services.

Treat the retired AZ-204 blueprint as a historical capability map, not a current credential target. A developer should still be able to decide between compute options, manage application identity, access secrets safely, use storage appropriately, design asynchronous integration, handle failure, instrument code, and deploy through controlled pipelines. The learning objective is production behavior, not an expired badge.

For current credential planning, developers should look at the role they are moving toward. If the destination is DevOps engineering, AZ-400 remains a current route. If the work centers on AI applications and agents, AI-103 may be more relevant. If the work is Power Platform extensibility, the PL-400 to AB-400 transition matters. If the goal is architecture, development experience becomes one input into AZ-305-level design reasoning rather than an exam requirement.

Microsoft AI-200 (Azure AI Cloud Developer Associate) is now a relevant certification for developers building back-end AI cloud solutions: Azure containers, data services, messaging and events, identity, monitoring, and troubleshooting. It covers a specific AI-connected development role rather than every topic in the retired AZ-204 outline. Compare that responsibility with AZ-400 DevOps and AI-103 Foundry agent development before choosing an exam.

AZ-400: connect development and operations through a delivery system

AZ-400 is best understood as an operating-model exam. Current skills effective July 27, 2026 emphasize processes and communications, source control, build and release pipelines, security and compliance, instrumentation, and continuous delivery using both GitHub and Azure DevOps. The subject is not just YAML syntax or clicking through a pipeline designer. It is the system that moves a change from idea to reliable production behavior.

Candidates should be able to reason about branch and repository strategies, artifact flow, secrets and identity, environment promotion, approvals, policy, test stages, infrastructure deployment, rollback, telemetry, feedback loops, dependency risk, and collaboration. A pipeline that succeeds technically can still be badly designed if it bypasses controls, produces unreproducible artifacts, has weak observability, or makes recovery difficult.

A strong lab creates a repeatable application delivery path with infrastructure as code, automated testing, environment separation, security checks, deployment strategy, and monitoring. Then challenge the design. What happens if a secret rotates? If a deployment is partially successful? If a schema change is not backward compatible? If a dependency is compromised? If production telemetry shows latency only after a release? Those questions are closer to DevOps engineering than memorizing task names.

AZ-700: choose it when connectivity is the work product

AZ-700 current skills effective July 27, 2026 focus on Azure networking design and implementation: core network infrastructure, hybrid connectivity, application delivery, private access, network security, monitoring, resiliency, and troubleshooting. It is a specialization because network behavior cuts across every workload while requiring its own depth.

The clearest readiness signal is responsibility. If you are expected to design address spaces, route flows, DNS behavior, hybrid connectivity, private service access, load-balancing patterns, ingress and egress controls, firewall integration, resiliency, and network observability, AZ-700 is aligned. If networking is only one small part of a broader administrator role, AZ-104 depth may be enough initially.

Networking study should be topology driven. Draw flows before configuring them. For every design, identify source, destination, name resolution, routing decision, security enforcement points, failure domains, health signals, and recovery behavior. Add hybrid scenarios because Azure networking becomes more demanding when on-premises routes, DNS, identity, firewalls, and asymmetric paths interact.

Troubleshooting is especially important. A packet can fail because of DNS, a route, a security group, a firewall policy, a platform route, a private endpoint configuration, peering, VPN or ExpressRoute behavior, application health, or a dependency outside Azure. The candidate who can isolate the failing layer has deeper network competence than someone who remembers a service feature list.

Security after AZ-500: move from an Azure-only label to end-to-end control engineering

AZ-500 retired on August 31, 2026. That means “Azure Security Engineer Associate” should not appear as an active exam target in an October 2026 roadmap. The underlying responsibility—securing cloud workloads—remains central. Microsoft’s current direction includes SC-500 for implementing end-to-end security controls across cloud and AI workloads.

This shift is conceptually useful. Real cloud security is not limited to one resource provider. It crosses identity, network, compute, applications, data, posture management, monitoring, and AI workloads. Security engineering therefore requires the ability to connect controls rather than configure them as isolated features.

A good Azure security study path builds on administrator or equivalent platform competence. You should understand where identity is evaluated, how workload identities differ from human identities, how network boundaries affect exposure, how secrets and keys are managed, how platform policy enforces configuration, how logs become detections, how vulnerabilities and posture are surfaced, and how recovery interacts with security.

The Microsoft cloud security path is useful if your role spans identity, operations, engineering, and architecture, because those responsibilities now map to different current credentials rather than one Azure security exam.

AZ-305: architecture is a change in the type of question

AZ-305 current skills effective April 17, 2026 focus on designing cloud and hybrid solutions across compute, networking, storage, monitoring, and security while translating business requirements into architecture. Microsoft frames the role around Azure Well-Architected Framework and Cloud Adoption Framework concepts, which is appropriate because architecture is about balancing quality attributes and organizational constraints.

The exam should feel different from an administrator exam. Instead of asking “Can this be configured?” architecture asks “Which design best satisfies these requirements, and what does it cost us in complexity, risk, operations, or flexibility?” Two technically valid designs can differ dramatically in availability, blast radius, recovery time, security exposure, cost predictability, deployment speed, and governance burden.

Architecture preparation should therefore use written scenarios. Give yourself a workload with user geography, data sensitivity, latency requirements, recovery objectives, compliance constraints, expected growth, team capabilities, integration dependencies, and cost limits. Produce at least two designs. For each, write the trade-offs, failure modes, operational ownership, migration path, observability plan, and reasons for rejecting the alternative. That exercise builds the decision muscle AZ-305 is trying to measure.

Administrator to architect: what transfers and what does not

Operational skill transfers strongly into architecture. An administrator who has debugged RBAC, routing, DNS, backup, policy, quota, monitoring, and deployment issues has seen the consequences of design choices. That experience makes architecture less abstract. However, operational excellence does not automatically produce architectural competence.

The gap is explicit trade-off reasoning. Administrators often optimize for making the current environment work. Architects must optimize a system across time and stakeholders. They need to ask how the design behaves during growth, failure, migration, audit, cost pressure, team turnover, and changing requirements. They must document assumptions and expose the consequences of each choice.

For example, an administrator may know how to configure availability zones. An architect must decide whether zonal design meets the workload’s recovery objectives, whether dependencies are also resilient, whether state is replicated correctly, what happens during regional failure, and whether the business will pay for the additional redundancy. Administration supplies the mechanisms; architecture supplies the reasoning model.

Networking to architecture: avoid treating topology as an isolated diagram

AZ-700 skills can be excellent preparation for architecture because network decisions influence security, reliability, performance, and cost. But architecture requires moving beyond a topology diagram. Connectivity is a system of dependencies and operational choices.

A hub-and-spoke design, for example, is not automatically “best practice.” It may centralize controls and connectivity, but it also creates routing, scale, ownership, and failure-domain considerations. Private endpoints reduce public exposure, but they introduce DNS and operational complexity. Global load balancing can improve availability, but state, data consistency, failover testing, and cost must also be solved.

The architecture candidate should therefore use network knowledge to illuminate trade-offs, not to dominate every design. Sometimes a simpler managed service with fewer network controls produces a more reliable and supportable system. Sometimes strict isolation is required. The right answer follows requirements.

Development to architecture: learn to see the application lifecycle

Developers bring valuable depth to architecture when they understand application behavior: dependencies, state, concurrency, failure handling, deployment, telemetry, data access, and change frequency. The architectural leap is to treat those behaviors as design inputs.

A stateless service may be easy to scale, but downstream state stores can become bottlenecks. Event-driven integration can reduce coupling, but it introduces delivery semantics, idempotency, ordering, dead-letter handling, observability, and operational replay concerns. Managed identity reduces secret handling, but identity boundaries and permissions still need design. Caching can improve latency, but invalidation and consistency become part of correctness.

Do not study architecture as a catalog of Azure services. Study it as a set of failure and change problems. That produces designs that remain understandable when the workload moves beyond the happy path.

Security to architecture: model control objectives before services

Security architecture becomes much clearer when control objectives come before product names. Start with what must be protected, from whom, under which regulatory or business requirement, and how success will be observed. Then map controls across identity, network, application, data, compute, monitoring, and recovery.

For example, “protect sensitive data” is too vague. A stronger requirement states which data classification is involved, who may access it, under what conditions, how access is authenticated and authorized, how data is encrypted, how exfiltration is reduced, what events are monitored, how keys are governed, how retention works, and what incident response must be possible. Once the objective is explicit, Azure and Microsoft security services can be selected rationally.

This is also why a security engineer and an architect need overlapping but different depth. The engineer must implement and validate controls. The architect must decide which controls belong in the design and how they interact with business and operational constraints.

Build a roadmap around four evidence levels

A useful way to sequence Azure learning is to require four levels of evidence before moving upward: explain, implement, troubleshoot, and design.

At the explain level, you can describe what a service or control does and where it fits. At implement, you can configure it correctly in a representative environment. At troubleshoot, you can isolate failures and understand dependencies. At design, you can compare alternatives against requirements and defend the trade-offs.

AZ-900 is mostly an explain-level credential. AZ-104 and AZ-700 require substantial implementation and troubleshooting. Security engineering and DevOps similarly depend on operational competence. AZ-305 is dominated by the design level, but design quality depends on the lower levels being credible.

Use this model as a personal gate. If you are rushing toward architecture but cannot troubleshoot the core services in your proposed designs, slow down. If you are an experienced operator who can already implement and troubleshoot but struggle to compare architectures formally, add scenario design work rather than repeating basic configuration labs.

A sample path for infrastructure professionals

An infrastructure professional new to Azure can reasonably start with AZ-900 if the platform vocabulary is unfamiliar, then move to AZ-104 as the operational anchor. From there, specialize according to responsibility. Choose AZ-700 if network architecture and hybrid connectivity dominate the job. Move toward SC-500 and adjacent security credentials if protecting workloads is the primary responsibility. Move toward AZ-305 if the role requires solution design across service families.

The sequence is not about collecting all four exams. Many professionals should stop after AZ-104 and one specialization, then build deeper experience. Architecture is most valuable when the role genuinely includes requirements, design ownership, and cross-team trade-offs.

A sample path for developers and platform engineers

Because AZ-204 is retired, developers should build Azure application skills directly through projects and current role requirements rather than chase the old exam. If the goal is reliable software delivery, AZ-400 can provide a current certification target while projects supply the application depth.

A strong project might include an API or event-driven service, managed identity, data storage, asynchronous integration, infrastructure as code, CI/CD, security scanning, deployment strategy, telemetry, alerting, and a documented rollback process. This single system exercises far more durable Azure engineering capability than a disconnected set of feature labs.

Developers moving into architecture should add explicit cost, reliability, governance, network, security, and recovery decisions. Platform engineers moving into DevOps should add source-control governance, pipeline design, policy, observability, and developer experience concerns.

A sample path for security professionals

Security professionals should select the entry point based on existing depth. A SOC analyst may already have strong detection and incident skills but need Azure platform and identity context. An identity administrator may have deep Entra knowledge but less network and workload-security experience. A cloud engineer may know Azure resources well but need structured control and threat reasoning.

Build enough AZ-104-level platform understanding to interpret resources, identity, networking, and monitoring, then pursue the security specialization that matches your role. Use SC-300 for identity, SC-200 for operations, SC-500 for security control engineering, and SC-100 when your responsibility becomes architecture. Do not treat those exams as mandatory sequential prerequisites; treat them as different views of the security system.

How to decide your next Azure credential

Before booking an exam, ask five questions. First, what production outcome will this credential help me own? Second, which current skills in the blueprint are genuinely new to me? Third, can I build and troubleshoot representative scenarios, not just recognize terminology? Fourth, is the exam active and stable enough that the plan will still make sense on the intended test date? Fifth, would a project or deeper experience produce more value than another adjacent badge?

If the answer to the first question is vague, the roadmap is probably too credential-driven. If most of the blueprint is already routine, focus on targeted gaps. If you cannot troubleshoot, add labs. If the exam is retired or near retirement, move the learning objective to a current credential or project. If another badge would only repeat what you already know, stop and deepen the work.

Scenario: the administrator who wants architecture too early

Consider an administrator who has six months of Azure experience and can deploy common resources but has not yet operated a meaningful environment through change or failure. AZ-305 may look attractive because architecture sounds senior, but the immediate learning problem is not exam difficulty. It is lack of consequence history. Without experience debugging permissions, network paths, backup behavior, quota, policy, monitoring, and service limits, architecture trade-offs remain theoretical.

The better plan is to deepen AZ-104-level work before moving fully into architecture study. Build a workload with clear recovery objectives. Add policy and RBAC. Use infrastructure as code. Implement monitoring and backup. Perform a restore. Change a network design and observe downstream effects. Rotate credentials. Test a regional or zonal dependency assumption. Document operational ownership. Once those mechanisms are familiar, begin producing architecture decision records that compare alternatives. The learner is then using AZ-305 to organize design reasoning rather than using it to compensate for missing operations depth.

Scenario: the network engineer entering Azure

A senior network engineer may have the opposite problem. Routing, segmentation, VPN, BGP, DNS, firewalls, and load balancing are already strong, so a long fundamentals sequence could waste time. The gap is Azure-specific control-plane behavior, identity and governance, platform networking abstractions, private access patterns, and how managed services change network assumptions.

A sensible route is a targeted Azure foundation review followed by enough AZ-104 material to understand subscriptions, resources, identity, policy, monitoring, and common service dependencies. Then AZ-700 becomes the specialization anchor. Study hybrid flows, private endpoints, DNS resolution, hub-and-spoke and Virtual WAN trade-offs, application delivery, resiliency, and troubleshooting. If the career goal later becomes architecture, expand from network correctness to whole-system concerns such as state, data, compute, observability, cost, governance, and recovery.

This example shows why experience changes the optimal sequence. The network engineer should not pretend to be a beginner, but should also not assume traditional networking knowledge maps one-to-one onto Azure’s managed-service behavior.

Scenario: the developer whose old AZ-204 plan is obsolete

A developer may have started an AZ-204 study plan early in 2026 and now discover that the exam retired. The worst response is to throw away the learning. The second-worst response is to keep pursuing the exam as though it were still available. The productive response is to map completed study into durable engineering capabilities.

List the Azure application skills already learned: compute choices, identity, secrets, storage, messaging, eventing, APIs, observability, deployment, and integration. Build a production-shaped application that uses several of them together. Then choose the current destination. For DevOps engineering, AZ-400 can formalize the delivery, collaboration, security, and instrumentation layer. For AI applications, AI-103 may fit if the work centers on Azure AI and agents. For architecture, use the project as the basis for design trade-off exercises. The retired exam becomes historical scaffolding, not a dead end.

Scenario: the security specialist deciding between SC-300, SC-200, SC-500, and SC-100

A professional moving into cloud security may see four current security credentials and assume they should be taken in numerical order. That would confuse code ordering with role progression. The choice should follow the security function.

If the daily work is identity lifecycle, authentication, Conditional Access, application access, privileged access, and governance, SC-300 is the most direct. If the work is incidents, detections, threat hunting, Sentinel, Defender XDR, and telemetry, SC-200 is the operational anchor. If the work is implementing controls across cloud and AI workloads, SC-500 better matches security engineering. If the responsibility is designing security strategy and architecture across identity, operations, infrastructure, data, AI, governance, and compliance, SC-100 is the architecture destination.

A security architect may ultimately benefit from all of those knowledge areas, but the learning order should follow weak domains. Someone with ten years in SOC operations but little identity depth might pair SC-300 study with architecture preparation. An identity specialist may need SC-200-style telemetry and incident context. The credential map is a way to expose blind spots, not a fixed conveyor belt.

Build an Azure architecture notebook before AZ-305

One practical bridge from operational certifications to architecture is an architecture notebook. For every meaningful Azure service or pattern you use, record six things: the problem it solves, the dependencies it creates, common failure modes, security implications, cost behavior, and operational ownership. Then add at least one alternative and the requirement that would cause you to choose it instead.

For a storage design, compare redundancy options, access patterns, lifecycle management, network exposure, identity, encryption, recovery, and performance. For compute, compare virtual machines, app platforms, containers, and serverless options by control, scale, deployment, observability, startup behavior, network integration, and operational burden. For databases, capture consistency, throughput, availability, backup, geo-replication, cost, and application coupling. For networking, capture routing, DNS, security enforcement, hybrid dependencies, latency, resilience, and troubleshooting complexity.

This notebook changes study from “Which Azure service has feature X?” to “Which design satisfies this workload, and what new risks does it introduce?” That shift is the essence of the architect path.

Use practice questions only after you can explain the mechanism

Exam-style questions are useful for exposing gaps, but they should come after you can explain the underlying system. If a question asks about private connectivity and you are guessing based on keywords, the right response is not more question volume. Rebuild the network flow, identify DNS and route behavior, locate enforcement points, and test the scenario. If a question asks about recovery, write the workload’s RTO and RPO, map dependencies, and identify what actually needs replication or restore.

Azure infrastructure skills now connect architecture, governance, operations, and recovery

Azure certification planning is strongest when candidates stop treating administration, architecture, networking, security, and DevOps as isolated tracks. A production platform needs all of them. Governance begins with resource hierarchy and policy: Azure Policy at scale shows how management groups, initiatives, assignments, exemptions, remediation, and policy-as-code turn organizational requirements into enforceable platform behavior.

Networking then determines how workloads actually communicate. Azure networking design patterns connect hub-spoke or Virtual WAN choices with routing, DNS, ingress, egress, and recovery behavior. Security controls sit inside that design rather than beside it: Azure Firewall and web application protection address different traffic layers, while Private Link and private endpoints change how platform services are reached and how DNS must be designed.

Identity and secrets are another shared infrastructure concern. Key Vault and managed identities demonstrate why production Azure design should prefer workload identity over embedded credentials and use secret storage only where a secret genuinely has to exist. That principle appears across AZ-104, architecture work, security roles, and automated delivery.

Resilience is the point where design assumptions are tested. Azure resilience and disaster-recovery patterns start with business RTO and RPO requirements, then map them to zones, regions, replication, backups, traffic failover, dependency recovery, and drills. Cost has to be evaluated alongside those reliability choices, which is why Azure cost governance for architects focuses on trade-offs rather than simple cost cutting.

Finally, the platform needs an operating model. Azure Monitor and Log Analytics provide the evidence needed to detect failure and validate recovery, while Bicep and infrastructure as code make infrastructure repeatable and reviewable. Candidates who can connect those layers are better prepared for the transition from administrator-level tasks into architecture and DevOps responsibilities.

The best readiness signal is not a high score on repeated questions. It is the ability to explain why the correct design works, why plausible alternatives fail the stated requirements, and what operational consequences remain. Use questions as diagnostic instrumentation for that reasoning.

The durable Azure roadmap is role-first and failure-aware

Azure changes too quickly for a roadmap built only from exam codes. The durable structure is a set of roles and capability layers. AZ-900 orients. AZ-104 anchors broad operation. AZ-700 specializes in connectivity. AZ-400 connects software change to reliable delivery. Current Microsoft security credentials replace the old AZ-500 scheduling path with more explicit identity, operations, control-engineering, and architecture roles. AZ-305 tests design judgment across the platform. Azure development remains essential even though AZ-204 is retired.

Choose the credential that matches the responsibility you want next. Build the associated system. Break it. Troubleshoot it. Write down the trade-offs. When you can move from explanation to implementation to failure analysis to design, the certification becomes evidence of a capability you actually own rather than a sequence number on a roadmap.