CertifyDeckCargando contenido…
The official Microsoft Certified: Power Platform Developer Associate syllabus, organized by domain. Check off each point as you review it.
Inicia sesión para guardar tu progreso entre sesiones.
Design the technical architecture
Before writing any code, a PL-400 developer needs to translate business requirements into concrete technical building blocks: is this a plug-in, a Power Automate flow, a PCF component, or an external integration? The technical architecture documents each piece, its dependencies, and the reasoning behind the choice, steering clear of over-engineering or fragile solutions.
Every component (plug-in, custom connector, Azure Function, app) needs an identity strategy: interactive users authenticate via OAuth/Microsoft Entra ID, while unattended processes rely on service principals or managed identities. Authorization then layers on top through Dataverse security roles that constrain what each component can read or write.
The PL-400 'low-code first' principle: before writing custom code, check whether business rules, Power Automate flows, views, or calculated columns already solve the requirement without it. Building a plug-in or a custom component is only justified when the platform has no native way to deliver that capability.
The same business logic can live in different layers: business rules (declarative, lightweight), client-side scripting (UI validation), server-side plug-ins (synchronous, transactional), or Power Automate (asynchronous orchestration). Picking the right layer affects performance, maintainability, and whether the logic also applies outside the UI.
Standard tables store data inside Dataverse; virtual tables surface external data as if it were native without duplicating it; elastic tables are built for high-volume, semi-structured data such as telemetry or logs; connectors reach external data on demand without modeling it as a table at all. The right choice depends on volume, latency, and whether you need relationships.
DLP policies can block a flow from combining connectors from different groups (say, SQL alongside HTTP), breaking integrations that already exist. Security roles, teams, business units, and row-level sharing determine which records a component can see or change at runtime — not just what the signed-in user can do.
Data loss prevention policies ↗Security concepts in Dataverse ↗
Candidates must choose between deterministic logic (business rules, plug-ins, strictly authored flows), which gives the same result every time, and non-deterministic logic (AI Builder prompts, generative orchestration), which interprets natural language and can vary. Copilot Studio defines three control layers - deterministic, hybrid, and AI harness - based on an action's risk, and generated content always requires human review.
Apply generative orchestration capabilities - Microsoft Copilot Studio | Microsoft Learn ↗Create a business rule in Microsoft Dataverse - Power Apps | Microsoft Learn ↗
Each Power Apps UX option fits a different scenario: code apps for React with Entra authentication and connectors; generative pages for building pages from natural language, only in model-driven apps; PCF for reusable field controls; web resources for simple HTML/JavaScript with no server-side code; and MCP app widgets for rendering a tool's JSON output inside a chat host like Microsoft 365 Copilot Chat.
Power Apps Code Apps: Features and Requirements - Power Apps | Microsoft Learn ↗Power Apps component framework overview in Microsoft Dataverse - Power Apps | Microsoft Learn ↗
Copilot Studio is the low-code SaaS platform, with connectors and topics, ideal for deploying agents quickly with Microsoft 365 integration. Foundry offers prompt agents (no-code, managed by Foundry) and hosted agents (your own code in a framework such as Agent Framework or LangGraph, run by Foundry); Copilot Studio can also connect an external Foundry agent or bring a Foundry model into a prompt.
What is Microsoft Foundry Agent Service? - Microsoft Foundry | Microsoft Learn ↗Process to build agents across your organization with Microsoft Foundry and Copilot Studio - Cloud Adoption Framework | Microsoft Learn ↗
Design solution components
Canvas components (reusable building blocks inside the low-code editor) and PCF code components (written in TypeScript) solve different problems: the former for UI/logic shared across canvas apps, the latter when you need full control of the DOM, better performance, or integration with external JS libraries — even inside model-driven apps.
A custom connector wraps a REST API — your own or a third party's — in an OpenAPI definition so Power Apps and Power Automate can consume it like any built-in connector. Designing one means deciding on authentication, which operations to expose, and how to group them so they don't collide with DLP policies.
Power Fx functions in Dataverse extend calculated columns with reusable logic; plug-ins run synchronous C# code in response to platform events; custom APIs define bespoke operations invocable as Web API messages, each with its own input/output contract.
Designing a flow instead of writing code makes sense when the logic is mostly cross-system orchestration — waiting, approving, notifying — rather than heavy computation. The design should account for error handling and concurrency, and decide which parts are better delegated to a plug-in or Azure Function instead of living inside the flow itself.
Outbound integrations typically use Service Endpoints/Webhooks or Azure Service Bus to notify external systems when a record changes; inbound integrations use the Web API, custom APIs, or connectors to let external systems write into Dataverse. The choice comes down to whether you need a synchronous response or looser decoupling.
Code apps are custom web apps built in a code-first IDE (for example React) that run as managed Power Platform apps: they authenticate with Microsoft Entra ID and reach Dataverse and connectors from your code. Use them when you need full control of the framework, not when a canvas app or model-driven app is enough. They don't support Power Platform Git integration or IP-based access restriction.
Power Apps Code Apps: Features and Requirements ↗Power Apps Code Apps Architecture for Development and Runtime ↗
The Dataverse MCP server is the key building block for agents that integrate with Power Platform: it exposes tools (query, create, update, describe schema) to MCP clients such as Copilot Studio, VS Code, or Claude, and always enforces the calling user's security roles and row-level security. In Copilot Studio, an agent is extended with tools (connectors, agent flows, MCP), authenticated with end-user or maker-provided credentials.
Connect to Dataverse with model context protocol (MCP) ↗Add tools to custom agents - Microsoft Copilot Studio ↗
The Monitor area of the Power Platform admin center measures the health of apps, flows, and agents from daily aggregated event logs, not real time; it needs tenant analytics and a managed environment to see recommendations and create alerts. Application Insights (Azure Monitor) receives telemetry exported from Power Platform/Dataverse in a standard schema, only for Managed Environments, requiring tenant and environment admin roles.
Monitor the health of your resources ↗Export data to Application Insights ↗
Implement application lifecycle management (ALM)
Dataverse solutions automatically track dependencies between components — for example, a plug-in that references a specific column. These dependencies prevent deleting or changing a component that something else relies on, and determine what must be included when exporting a solution so it works correctly in another environment.
Environment variables externalize values that change between environments — API URLs, keys, connection IDs — so the same component works in dev, test, and production without touching code. They're defined once in the solution and given a different value per environment, avoiding hardcoded configuration.
When multiple solutions — unmanaged and managed, from different publishers — modify the same component, Dataverse stacks them in layers, and only the active top layer determines the visible behavior. Understanding layering is essential for figuring out why a change 'isn't showing up' or conflicts with another solution.
Power Platform Pipelines automate solution deployment across environments (dev to test to prod) directly from the Power Platform interface, without manually wiring up Azure DevOps. They can be extended with custom stages or checks when the standard deployment flow doesn't cover a project's specific needs.
Power Platform Build Tools are Azure DevOps tasks (with GitHub Actions equivalents) that export, package, version, and import solutions automatically as part of a CI/CD pipeline, letting you enforce quality gates — solution checker, automated tests — before anything reaches production.