Power Platform Developer: From PL-400 to AB-400
Microsoft Power Platform Developer Associate now uses the AB-400 exam for new registrations. PL-400 registration closed on October 16, 2026; candidates who registered in time can take their existing PL-400 appointment only through October 30, 2026. This is a transition in the same developer credential, not an invitation for new candidates to book the old exam. The useful question in October 2026 is how to prepare for AB-400: Extending Microsoft Power Platform Solutions with Code and AI, while still using older PL-400 development material where it overlaps.
On this page
- What changed in October 2026
- Read the four current objective areas
- Learn Dataverse as an application boundary
- Practice developer extensibility, not just drag-and-drop
- Implement a secure integration
- Treat AI agents as governed components
- Use a practical preparation cycle
- Register and interpret results correctly
What changed in October 2026
Microsoft moved new registrations from PL-400 to AB-400 on October 16, 2026. Registered PL-400 candidates have a final examination window ending October 30. If you are starting now, check AB-400 availability and Microsoft’s official scheduling page rather than following old PL-400 booking steps. The credential remains Power Platform Developer Associate, but the active blueprint emphasizes extending solutions with code, integrations, workflow expressions and AI-enabled features. Old course material can teach useful Dataverse and custom-code concepts; it is not a substitute for an AB-400-specific objective map.
Read the four current objective areas
The current AB-400 domains are: build Microsoft Power Platform solutions (15–20%), extend the user experience (25–30%), extend Microsoft Power Platform (35–40%), and develop integrations (10–15%). These percentages describe the official exam blueprint, not a guarantee about the question format you will encounter. Build your study tracker from the AB-400 study guide. For each objective, record evidence from a working solution you have built and debugged. Avoid allocating time according to an older PL-400 section list or overemphasizing Power BI dashboards, which are not one of the four new domain labels.
Learn Dataverse as an application boundary
Create a small business case—such as equipment checkout or service-request tracking—with a clear Dataverse table model. Define relationships, choice values, alternate keys where appropriate, business rules, security roles and column restrictions. Document who can read, create, update and delete each record type. Test the result using distinct ordinary and privileged identities. A model that only works under an administrator account hides permissions defects. Demonstrate a change to the model and trace its effect on model-driven apps, automated flows and integration contracts.
Practice developer extensibility, not just drag-and-drop
Build a Power Apps component framework (PCF) control that solves a specific usability problem; explain its manifest, data inputs, lifecycle and accessible interaction. Use Power Fx for client logic that belongs there, and use appropriate Dataverse plugin or custom API techniques when server-side validation and controlled transactions are necessary. A simple exercise might reject an invalid equipment return even when the request bypasses a canvas app. Log failures safely, test the behavior with a non-admin role and explain why the chosen extension point is more reliable than a client-only rule.
Implement a secure integration
Connect the solution to an external service through a supported connector or REST API. Design authentication, request validation, pagination, throttling, retries and handling of a temporarily unavailable dependency. Distinguish a user permission problem from a provider failure. Use managed identities or platform-supported credentials where available rather than exposing API keys in an app screen or prompt. Prepare a reproducible test where the integration rejects unauthorized callers but allows an approved workflow to recover from a transient timeout.
Treat AI agents as governed components
AB-400 includes AI-assisted development and agentic functionality in the wider developer context. An agent that can search documentation may be low risk; an agent that can change a customer record or trigger a payment requires strongly enforced tool permissions and often human confirmation. Build a bounded task with a permitted tool, an untrusted data source and a clear refusal or escalation route. Check how prompt injection or an incorrect retrieved instruction is handled by application code and downstream authorization. Log tool calls and outcomes without storing secrets in model conversations.
Use a practical preparation cycle
Begin with the official objective matrix and a diagnostic, then prioritize the gaps that block independent implementation. Build a solution, break one component deliberately, recover it, and explain the evidence behind the fix. Practice exporting and importing solutions between development and test environments. Check for unmanaged dependencies, environment-specific connections and secret exposure before promotion. Use Microsoft Learn and official documentation for changing platform behavior; use practice questions as a learning diagnostic, not as leaked-answer memorization.
Register and interpret results correctly
Schedule the active AB-400 exam using your Microsoft Learn credential profile. Confirm regional fees, languages, accommodations, identity requirements and available test delivery options on the live provider page; do not infer them from an older article. After the exam, use the official score report and certification profile for the outcome. Passing a credential can document assessed skills, but employers still evaluate production experience, maintainability, security judgment and collaboration. A stronger portfolio includes the working solution, test evidence and a concise explanation of your design tradeoffs.