Microsoft Certification Roadmap: Azure, AI, Data, Security, Power Platform, and Microsoft 365 Paths
Microsoft certification planning is harder in 2026 than it looks from a list of exam codes. The portfolio is broad, several familiar exams have retired, newer credentials increasingly reflect AI-assisted work, and the same Microsoft service can appear in multiple job roles. A cloud administrator may use Microsoft Entra ID, a security specialist may investigate the same identities, an architect may design the control plane around them, and an AI engineer may depend on those controls when deploying agents. The practical problem is therefore not “Which Microsoft exam comes next?” It is “Which work product do I want to own, and which credential best tests the decisions behind that work?”
That role-first question is the organizing principle for this roadmap. Microsoft Credentials now includes role-based certifications as well as narrower Applied Skills credentials, and there is no single ladder that everyone should climb. Azure infrastructure, security, AI, data, Power Platform, and Microsoft 365 each have their own center of gravity. They overlap, but they produce different evidence of competence. A useful plan chooses a destination, builds the prerequisite skills needed for that destination, and uses credentials as checkpoints rather than as substitutes for hands-on ability.
This distinction matters especially after the 2026 portfolio changes. MS-900 retired on March 31, DP-100 on June 1, AI-900 and AI-102 on June 30, PL-600 on June 30, AZ-204 on July 31, and AZ-500 on August 31. Those codes still appear in older articles, training plans, job descriptions, and search results, but they should not be treated as schedulable current exams. Current routes include newer credentials such as AI-901, AI-103, SC-500, AB-900, AB-410, and the incoming AB-400 transition for Power Platform development. The right roadmap has to account for that movement instead of pretending certification names never change.
A common planning mistake is to begin with a Microsoft product name. Someone sees Azure, Fabric, Copilot, Power Platform, or Microsoft 365 and assumes the relevant credential is the one with the closest label. In practice, Microsoft technologies are shared surfaces used by many roles. The better starting point is the system of decisions you expect to make at work.
An Azure administrator, for example, owns repeatable implementation and operation: subscriptions, resource governance, compute, storage, networking, monitoring, identity integration, and day-two maintenance. A solutions architect may work with the same services but is judged on requirements, trade-offs, resiliency, security, cost, migration, and lifecycle design. A security operations analyst consumes telemetry and manages detection and response. An identity administrator designs and operates authentication, authorization, Conditional Access, application access, and governance. A data engineer owns ingestion and transformation. An analytics engineer owns semantic and analytical assets. A Power BI analyst turns governed data into models and decisions. These are related domains, but they are not interchangeable.
Before selecting an exam, write a short role statement in the form: “I want to be responsible for ___, using ___, under constraints such as ___.” If the blank is “operating Azure resources,” the Azure administration route makes sense. If it is “designing cross-subscription and hybrid cloud solutions,” architecture becomes the destination. If it is “protecting cloud and AI workloads end to end,” the security engineering route is more relevant than collecting generic Azure badges. If it is “building agentic applications,” an AI engineering route is more coherent than a broad cloud fundamentals sequence.
Fundamentals-level certifications can be valuable, but they should solve a specific problem. Their strongest use is orientation: learning the vocabulary, service boundaries, responsibility models, economics, security concepts, and management structure of a platform before deeper role training. They are especially useful for career changers, technical sales professionals, managers, analysts, and early-career learners who need a structured way to build conceptual fluency.
They are less useful when treated as compulsory prerequisites for experienced practitioners. A systems engineer who already deploys Azure resources daily may gain more from an AZ-104-oriented skills review than from spending weeks relearning cloud definitions. A data professional who already builds Power BI models may reasonably begin with PL-300. A security analyst who already lives in SIEM and endpoint telemetry may not need to make SC-900 the center of the study plan.
The test is simple: does the fundamentals syllabus close a real knowledge gap that would otherwise slow later learning? If yes, use it. If no, skip directly to the role credential and fill individual foundation gaps as they appear. Fundamentals should reduce friction, not add ceremonial steps.
Azure has the broadest set of role boundaries in the Microsoft portfolio, so it is useful to think of it as several connected tracks rather than one cloud ladder. The Azure certification roadmap goes deeper into those branches, but the top-level distinction is straightforward: operators implement and maintain; network specialists design connectivity; architects make system-level trade-offs; DevOps engineers optimize the path from code to reliable operation.
AZ-900 remains an orientation credential for cloud concepts, Azure architecture and services, and management and governance. AZ-104 is the operational anchor for administrators. Its current skills emphasize identity and governance, storage, compute, virtual networking, and monitoring and maintenance, with practical expectations around the portal, command-line tooling, infrastructure templates, and foundational networking and operating-system concepts.
AZ-700 is not simply “more AZ-104 networking.” It goes deeper into network architecture and implementation: core virtual network design, hybrid connectivity, application delivery, private access, security controls, monitoring, resiliency, and troubleshooting. It makes sense for people whose work product is connectivity itself rather than general platform administration.
AZ-305 is the architecture destination for candidates who need to translate business requirements into designs across compute, networking, storage, monitoring, governance, and security. The important jump is from implementation correctness to design reasoning. An administrator may know how to configure a private endpoint; an architect must decide whether private connectivity is justified, how name resolution will work, what operational burden it creates, how it affects disaster recovery, and what alternative architecture would satisfy the same risk requirement.
AZ-204 retired on July 31, 2026, so Azure development should now be described as a skills domain rather than as an active exam route tied to that code. The development capabilities remain relevant: compute, storage, identity, APIs, messaging, observability, deployment, and secure integration. Those skills can feed naturally into AZ-400 for DevOps engineering, where the emphasis shifts to source control, pipelines, security and compliance, instrumentation, continuous delivery, and collaborative engineering systems.
Microsoft security is not one role wearing five different exam codes. The current path is better understood as a set of specializations that converge at architecture. The Microsoft security roadmap separates those roles in more detail.
SC-900 is the fundamentals orientation point. SC-200 is for security operations: incidents, hunting, detections, Microsoft Sentinel, Defender XDR, and the telemetry and investigation workflows around them. SC-300 is for identity and access: Entra identity lifecycle, authentication, authorization, Conditional Access, application integration, privileged access, and governance. SC-401 is centered on information security administration in Microsoft 365, covering Purview-based information protection and DLP, retention controls, insider-risk workflows, and related information-security alerting and activity review.
AZ-500 retired on August 31, 2026. Its old role as Azure Security Engineer should not be shown as a current exam. SC-500 is now the more relevant security-engineering direction for implementing end-to-end controls across identity, network, applications, data, compute, and AI workloads while monitoring posture with Microsoft security services. That is a broader control implementation perspective than the older Azure-only framing.
SC-100 sits at the architecture layer. It is most useful when the learner can already reason about identity, security operations, infrastructure, data, governance, compliance, Zero Trust, and increasingly AI risk as interacting systems. Jumping straight to architecture without depth in at least a few implementation domains often produces memorized principles without the ability to test whether a design is operable.
Microsoft’s 2026 AI portfolio makes role selection especially important because “AI professional” can mean radically different work. The Microsoft AI roadmap should be read as a branching map, not a sequence.
AI-901 is the current Azure AI Fundamentals exam after AI-900 retired. It is more technically grounded than many learners expect: conceptual understanding still matters, but candidates should be comfortable with basic Python syntax, Azure resources, and the way APIs, SDKs, and command-line tools appear in AI solution work.
AI-103 is the technical engineering route for developing AI applications and agents on Azure. It spans planning and managing AI solutions, generative AI, agentic patterns, computer vision, text analysis, and information extraction. The practical study implication is that prompt experimentation alone is not enough. Candidates need to understand deployment boundaries, model and service selection, identity, data access, evaluation, observability, content safety, and how an AI feature behaves inside a larger application lifecycle.
AB-100 targets architecture of agentic AI business solutions across Microsoft platforms. That makes it a system-design credential rather than simply a more difficult AI coding exam. AB-730 is aimed at business professionals who use generative AI, prompts, Copilot, agents, and content tools without building the underlying applications. AB-731 targets transformation leaders who evaluate AI opportunities, adoption, responsible AI, organizational readiness, and business value.
GitHub Copilot skills add another dimension. GH-300 validates responsible use of Copilot in software engineering, including features, data and architecture, prompt and context techniques, productivity, privacy, content exclusions, and safeguards. It complements an engineering path rather than replacing Azure application, AI, or DevOps skills.
The Microsoft data path is easiest to understand by focusing on the artifact each role is responsible for. The Fabric and data roadmap revolves around three especially useful anchors: PL-300, DP-600, and DP-700.
PL-300 is the Power BI Data Analyst route. The work product is a trustworthy analytical model and the reports or decisions built on it. Data preparation, modeling, DAX, visualization, analysis, security, and lifecycle management matter because the analyst must turn imperfect source data into reliable business meaning.
DP-600 is the Fabric Analytics Engineer route. It moves beyond report authoring into the design, creation, security, maintenance, and optimization of enterprise analytical assets such as semantic models, warehouses, and lakehouses. The role often sits between data engineering and BI, with responsibility for making curated data structures usable and governable at scale.
DP-700 is the Fabric Data Engineer route. Its center of gravity is ingestion, transformation, orchestration, architecture, monitoring, optimization, and secure data movement using technologies such as SQL, PySpark, and KQL. The key question is therefore not which exam is “advanced.” It is whether you want to own business-facing analysis, enterprise analytical assets, or the pipelines and platform mechanics that make data available.
Power Platform is undergoing a visible credential transition. A roadmap copied from 2024 or 2025 will now mislead learners because PL-200 and PL-600 are retired, while PL-400 is moving toward AB-400. The Power Platform roadmap explains how to interpret those legacy codes without pretending they remain the current destination.
PL-900 remains the foundation for Power Platform business value, environments, Power Apps, Power Automate, and Copilot Studio agents. AB-410 is a current Intelligent Applications Builder path focused on AI-powered Power Platform solutions, Dataverse, apps, flows, pages, Copilot, and business-process mapping. PL-300 remains relevant for the analytical branch through Power BI.
PL-400 is still in a transition window as of September 2026, with registration closing October 16 and registered candidates able to take it through October 30. AB-400 is the incoming Power Platform Developer exam. PL-600 and the old Solution Architect Expert credential retired June 30. Newer architecture and agent-oriented credentials exist, but they should not be described as direct one-for-one replacements because the role definitions are changing along with the platform.
The durable strategy is to learn platform concepts and solution responsibilities rather than overinvest in a retiring code. Dataverse design, ALM, security, automation, integration, extensibility, governance, and solution decomposition will remain useful even when the badge name changes.
Microsoft 365 credentials increasingly reflect the fact that modern workplace administration spans endpoints, tenant configuration, Copilot and agents, identity, information protection, and security operations. The Microsoft 365 roadmap is therefore role-first rather than product-first.
AB-900 is now the fundamentals credential for Microsoft 365 Copilot and agent administration after MS-900 retired. MD-102 focuses on endpoint administration using Intune, Windows Autopilot, Defender for Endpoint, Entra ID, PowerShell, Microsoft Graph, and Windows 365. MS-102 remains active as of September 20, 2026, but Microsoft has scheduled it to retire on November 30, 2026. Anyone building a long-term plan should therefore treat that route as transitional rather than as a permanent anchor.
Security work around Microsoft 365 increasingly branches into SC-300 for identity, SC-401 for information security and Purview, and SC-200 for security operations. This reflects the operational reality: managing a tenant, securing identities, governing sensitive information, and investigating incidents are different responsibilities even when they occur in the same Microsoft 365 environment.
Once a target role is clear, the most efficient roadmap looks for shared skills between adjacent credentials. Identity is a good example. Entra concepts appear in Azure administration, Microsoft 365, security, application access, Conditional Access, and architecture. Learning identity deeply once is more valuable than relearning a shallow version for every exam.
The same is true for networking. Virtual networks, DNS, private connectivity, load balancing, firewall policy, and hybrid connectivity matter to administrators, network specialists, security engineers, and architects. Observability crosses Azure operations, DevOps, security operations, and AI systems. Governance touches subscriptions, policy, data, security, Power Platform environments, and tenant administration.
Create a skill adjacency map with three columns: “must master for target role,” “shared supporting skill,” and “awareness only.” That prevents the common failure mode of studying every overlapping objective at equal depth. An AZ-305 learner may need deep architecture trade-off reasoning, strong operational Azure knowledge, and only awareness of specialized data-engineering internals. A security architect may need deep identity and threat-modeling knowledge, strong infrastructure and governance understanding, and awareness of highly specialized developer tooling. Depth should follow decision responsibility.
A certification path is strongest when each credential is separated by a period of applied work. That work can be professional, lab-based, or portfolio-based, but it should produce evidence that mirrors the role.
For Azure administration, evidence might include a governed multi-subscription lab, identity and RBAC design, repeatable infrastructure deployment, monitoring, backup, update management, and a documented recovery exercise. For architecture, the evidence should add requirements, alternatives, trade-offs, failure modes, cost assumptions, security controls, and operational ownership.
For security operations, build a small detection and investigation workflow: ingest telemetry, normalize it, write detections, triage incidents, document false positives, and run a simple hunt. For identity, design Conditional Access and lifecycle scenarios with break-glass considerations and governance. For data, implement a pipeline with lineage, quality checks, semantic modeling, and access controls. For AI, build an application or agent that includes evaluation, identity, data boundaries, safety controls, and observable failure handling rather than only a successful demo prompt.
The point is not to create an enormous portfolio for every exam. It is to make sure the badge corresponds to a capability you can explain under questioning.
Career changers often need more structure because they are building platform vocabulary and job-role context at the same time. A useful sequence is foundation, one operational role, then specialization.
Start with the fundamentals credential only if the platform is genuinely new. Next choose one role where you can build end-to-end competence: Azure administration, endpoint administration, data analysis, security operations, identity administration, or a similar operational surface. Spend enough time there to understand normal operations and failure modes. Then move toward architecture, advanced security, AI engineering, DevOps, data engineering, or another specialty.
Why not begin with the most senior credential? Because senior exams assume judgment formed by exposure to conflicting requirements. Architecture questions become much easier when you have seen deployment friction, permissions failures, monitoring gaps, quota issues, network asymmetry, policy conflicts, backup limitations, or data-quality problems. Without that operational context, candidates can memorize best-practice slogans without understanding when those practices collide.
Experienced practitioners should invert the process. Begin with a gap analysis against the current role blueprint. Mark each objective as “do regularly,” “understand but rarely do,” or “new.” If most objectives are already routine, skip broad preparatory credentials and focus on the specific gaps that prevent reliable performance.
A senior network engineer moving into Azure may not need a generic cloud fundamentals course, but may need concentrated work on Azure governance, identity, platform-native load balancing, private access patterns, and IaC. A Power BI specialist moving into Fabric may already have strong semantic modeling and DAX but need lakehouse, warehouse, Spark, orchestration, governance, and performance depth. A SOC analyst moving toward security architecture may need less incident-response practice and more identity architecture, cloud design, governance, risk translation, and control-system reasoning.
The certification is then a forcing function for breadth, not the entire learning experience.
When Microsoft retires an exam, the skill domain rarely disappears overnight. AZ-204 is retired, but Azure application development did not vanish. AZ-500 is retired, but workload security remains essential. PL-600 is retired, but solution architecture still matters. The lesson is to separate credential lifecycle from capability lifecycle.
If you already studied for a retired exam, do not discard the work. Map the old objectives to current role needs. Keep the durable skills, identify platform features that changed, and decide which current credential—if any—best represents the direction you want to continue. This is more productive than chasing a replacement solely because its code looks similar.
For new learners, avoid building a plan around an exam that is retired or within a very short retirement window. Use the retired code only as historical context when older resources or employer language still reference it.
A roadmap also needs an exit condition. The goal is not maximum badge count. Stop adding adjacent certifications when the next credential would provide less value than deeper project ownership, production experience, communication practice, or specialization.
A person with AZ-104, AZ-700, and strong infrastructure experience may gain more from designing and defending a multi-region architecture than from adding another fundamentals badge. A security professional with SC-200 and SC-300 may benefit more from integrating identity and SOC processes than from treating each exam as a disconnected trophy. A data professional with PL-300 and DP-600 may need real model governance, performance tuning, and stakeholder work more than another overlapping credential.
Use a simple threshold: the next certification should either open a new role boundary, formalize an important capability you already use, or force learning in a domain that materially improves your current work. If it does none of those, build experience instead.
The strongest Microsoft certification plan looks less like a staircase and more like an architecture diagram. It has a destination role, supporting capabilities, optional branches, transitional components, and dependencies. It changes when the platform or credential portfolio changes.
At the top level, Azure is the infrastructure and cloud-design family; Microsoft Security separates operations, identity, information protection, engineering, and architecture; AI separates technical builders, architects, business users, and transformation leaders; Fabric and data separate analysis, analytics engineering, and data engineering; Power Platform spans business solutions, automation, analytics, development, and newer agent-oriented roles; Microsoft 365 spans Copilot, endpoint, tenant, identity, information protection, and security operations.
Pick the path that matches the work you want to own. Use fundamentals where they genuinely reduce confusion. Build one operational core deeply enough to understand failures. Add specialized or architectural credentials only when you can connect them to real decisions. And re-check the live Microsoft credential catalog before scheduling, because in 2026 the portfolio is moving quickly enough that yesterday’s perfect ladder can become today’s retired exam list.
When several routes look plausible, evaluate them with operational questions rather than brand preference. For Azure administration, ask whether you want responsibility for resource lifecycle, access, networking, storage, compute, policy, monitoring, and platform maintenance. If the answer is yes, an administrator-centered route is coherent because it teaches the mechanics that many other Azure roles assume. If you mainly want to design connectivity, hybrid routing, private access, application delivery, and resilient network boundaries, networking is the more direct specialization. If your job is to translate requirements into cloud designs across multiple service families, architecture should be the destination, but only after you can reason about how those designs are actually operated.
For security, distinguish the evidence you want to produce. Security operations produces investigations, detections, hunts, incident decisions, and telemetry improvements. Identity administration produces authentication and authorization design, Conditional Access, application access, lifecycle controls, and governance. Information security administration produces classification, protection, retention, DLP, and risk-handling controls around data. Security engineering produces implemented controls around workloads and posture. Architecture produces the design rationale that coordinates all of those layers. Two people can both say “I work in Microsoft security” while needing completely different preparation.
For AI, ask whether you are expected to build systems, design systems, use AI productively in business work, or lead organizational adoption. A developer who needs to integrate models and agents into software should not substitute a business-user credential for engineering depth. A transformation leader does not need to prove the same implementation detail as an AI engineer, but does need to understand business value, governance, responsible AI, adoption risk, measurement, and operating-model implications. An architect must connect AI components to identity, data, integration, observability, safety, scalability, and cost. The credential should match the decision surface.
For data, identify where errors become your responsibility. If a misleading dashboard or poorly designed semantic model is your problem, the analyst and analytics-engineering paths matter. If unreliable ingestion, transformation, orchestration, or performance is your problem, data engineering is the stronger fit. If the business consumes the result through Power BI but the platform runs in Fabric, you may need skills from more than one track, yet still only one primary credential at a time.
For Power Platform and Microsoft 365, the same principle applies. Choose the role where you can explain not only what to configure but why a configuration is safe, supportable, and aligned with governance. The most useful credential is the one that exposes the gap between “I have clicked through this feature” and “I can own the outcome when it fails.”
A roadmap becomes actionable when it is converted into cycles. A practical six-month plan can use four repeating modes: baseline, build, operate, and review. During baseline, compare your skills against the current objective blueprint and identify weak prerequisites. During build, implement representative solutions rather than reading every service description in isolation. During operate, introduce failure, change, scale, access constraints, and recovery tasks. During review, explain the design aloud, write down trade-offs, and use exam-style questions only as a diagnostic for reasoning gaps.
For example, an Azure administrator path could begin with a governed subscription structure and identity model, then add compute, storage, virtual networking, monitoring, backup, and automation. The operating phase would deliberately break name resolution, permissions, routes, capacity, policy, and recovery assumptions. The review phase would ask why one control is preferable to another under cost, security, and operability constraints. That sequence produces much stronger readiness than a checklist of portal screenshots.
A security operations path can follow the same pattern with telemetry onboarding, detection rules, incident triage, investigation, automation, and hunting. The operating phase injects noisy signals, missing logs, stale identities, false positives, and conflicting evidence. An identity path can build users, groups, applications, Conditional Access, privileged access, and lifecycle workflows, then test emergency access, guest governance, service identities, and policy conflicts. A data path can build ingestion and models, then test schema change, late data, permissions, refresh failure, performance, lineage, and business-definition disputes.
Keep the certification exam in the review layer, not the center of the system. The exam gives you a bounded skills map and a date that forces consolidation. The real learning happens when you build and operate something that creates consequences for bad decisions.
A path is too broad when your weekly study jumps between unrelated technologies without a common work product. If Monday is Power BI modeling, Tuesday is Sentinel hunting, Wednesday is Kubernetes networking, Thursday is Copilot governance, and Friday is Power Automate, you may be collecting Microsoft topics rather than building a role. Breadth is valuable later; early breadth without a center creates shallow familiarity.
A path is too narrow when you can execute a task only in the happy path. An administrator who can deploy a virtual machine but cannot explain identity, networking, monitoring, backup, policy, or recovery around it is not yet operating at role depth. A data analyst who can write DAX but cannot reason about model grain, data quality, row-level security, refresh behavior, or stakeholder definitions is similarly narrow. An AI builder who can produce a successful prompt but cannot explain data boundaries, evaluation, safety, identity, observability, or failure handling has a demo skill rather than production readiness.
Use these signals to adjust the roadmap every few weeks. Add breadth when the role requires interacting systems. Add depth when you are relying on memorized procedures without understanding failure modes. That feedback loop is more useful than trying to follow a fixed certification ladder for a year while the platform, exams, and your own responsibilities are changing.
Popular posts
Recent Posts
