CertifyDeckCargando contenido…
El temario oficial de Microsoft Certified: Power Platform Developer Associate, organizado por dominio. Marca cada punto según lo vayas repasando.
Inicia sesión para guardar tu progreso entre sesiones.
Design the technical architecture
Antes de escribir código, un desarrollador PL-400 debe traducir requisitos de negocio en componentes técnicos concretos: ¿esto es un plug-in, un flujo de Power Automate, un componente PCF o una integración externa? La arquitectura técnica documenta cada pieza, sus dependencias y el motivo de la elección, evitando sobre-ingeniería o soluciones frágiles.
Cada componente (plug-in, conector personalizado, Azure Function, app) necesita una estrategia de identidad: usuarios interactivos vía OAuth/Microsoft Entra ID, o procesos desatendidos vía entidades de servicio o managed identities. La autorización se combina con roles de seguridad de Dataverse para limitar qué puede leer o escribir cada componente.
El principio "low-code primero" del PL-400: antes de programar, evalúa si reglas de negocio, flujos de Power Automate, vistas o columnas calculadas ya resuelven el requisito sin código. Escribir un plug-in o componente personalizado solo se justifica cuando la plataforma no ofrece esa capacidad de forma nativa.
La misma lógica de negocio se puede implementar en distintas capas: reglas de negocio (declarativas, ligeras), scripting cliente (validaciones de UI), plug-ins server-side (síncronos, transaccionales) o Power Automate (asíncrono, orquestación). Elegir la capa correcta afecta rendimiento, capacidad de mantenimiento y si la lógica se aplica también fuera de la interfaz.
Standard tables almacenan datos dentro de Dataverse; virtual tables exponen datos externos como si fueran nativos sin duplicarlos; elastic tables están pensadas para volúmenes altos y datos semi-estructurados (telemetría, logs); los conectores acceden a datos externos bajo demanda sin modelarlos como tabla. La elección depende de volumen, latencia y necesidad de relaciones.
Las políticas DLP pueden bloquear que un flujo combine conectores de distintos grupos (por ejemplo, SQL con HTTP), rompiendo integraciones ya construidas. Los roles de seguridad, equipos, unidades de negocio y el uso compartido de filas determinan qué registros puede ver o modificar un componente en tiempo de ejecución, no solo el usuario.
Data loss prevention policies ↗Security concepts in Dataverse ↗
Hay que elegir entre lógica determinista (reglas de negocio, plug-ins, flujos estrictos), que da el mismo resultado cada vez, y lógica no determinista (prompts de AI Builder, orquestación generativa), que interpreta lenguaje natural y puede variar. Copilot Studio define tres capas de control -determinista, híbrida y AI harness- según el riesgo de la acción, y el contenido generado siempre exige revisión humana.
Apply generative orchestration capabilities - Microsoft Copilot Studio | Microsoft Learn ↗Create a business rule in Microsoft Dataverse - Power Apps | Microsoft Learn ↗
Cada opción de interfaz de Power Apps encaja con un escenario distinto: code apps para React con autenticación de Entra y conectores; páginas generativas para crear páginas por lenguaje natural, solo en apps basadas en modelos; PCF para controles de campo reutilizables; recursos web para HTML/JavaScript simple sin código de servidor; y widgets de MCP app para mostrar el JSON de una herramienta dentro de un chat como 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 es la plataforma SaaS de bajo código, con conectores y temas, ideal para desplegar agentes rápido con integración en Microsoft 365. Foundry ofrece agentes de tipo prompt (sin código, administrados por Foundry) y agentes hospedados (código propio en un framework como Agent Framework o LangGraph, ejecutado por Foundry); Copilot Studio también puede conectar un agente externo de Foundry o traer un modelo de Foundry a un 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
Los componentes canvas (bloques reutilizables dentro del editor low-code) y los componentes PCF (code components, escritos en TypeScript) resuelven necesidades distintas: los primeros para lógica/UI reutilizable entre apps canvas, los segundos cuando se necesita control total del DOM, rendimiento o integración con librerías JS externas, incluso en apps model-driven.
Un conector personalizado envuelve una API REST (propia o de terceros) en una definición OpenAPI para que Power Apps y Power Automate puedan consumirla como cualquier conector nativo. Diseñarlo implica decidir autenticación, operaciones expuestas y cómo se agrupan para no chocar con políticas DLP.
Las funciones de Power Fx en Dataverse permiten extender columnas calculadas con lógica reutilizable; los plug-ins ejecutan código C# síncrono ante eventos de la plataforma; las custom APIs definen operaciones a medida invocables como mensajes de la Web API, con contrato de entrada/salida propio.
Diseñar un flujo en lugar de codificarlo tiene sentido cuando la lógica es principalmente orquestación entre sistemas (esperar, aprobar, notificar) más que cómputo intensivo. El diseño debe considerar manejo de errores, concurrencia y qué parte de la lógica conviene delegar a un plug-in o Azure Function en vez de al propio flujo.
Las integraciones salientes (outbound) suelen usar Service Endpoints/Webhooks o Azure Service Bus para notificar a sistemas externos cuando cambia un registro; las entrantes (inbound) usan la Web API, custom APIs o conectores para que sistemas externos escriban en Dataverse. La elección depende de si necesitas respuesta síncrona o desacoplamiento.
Las code apps son apps web personalizadas creadas en un IDE code-first (por ejemplo React) que se ejecutan como apps gestionadas de Power Platform: se autentican con Microsoft Entra ID y acceden a Dataverse y a conectores desde el código. Úsalas cuando necesites control total del framework, no cuando baste una canvas o model-driven app. No admiten Power Platform Git integration ni restricción de acceso por IP.
Power Apps Code Apps: Features and Requirements ↗Power Apps Code Apps Architecture for Development and Runtime ↗
El Dataverse MCP server es la pieza clave para agentes que se integran con Power Platform: expone herramientas (consultar, crear, actualizar, describir esquema) a clientes MCP como Copilot Studio, VS Code o Claude, y siempre respeta los roles de seguridad y la seguridad a nivel de fila del usuario. En Copilot Studio, un agente se amplía con tools (conectores, agent flows, MCP), autenticadas con credenciales del usuario final o del creador.
Connect to Dataverse with model context protocol (MCP) ↗Add tools to custom agents - Microsoft Copilot Studio ↗
El área Monitor del Power Platform admin center mide la salud de apps, flujos y agentes con registros diarios agregados, no en tiempo real; requiere análisis de inquilino y un entorno administrado para ver recomendaciones y crear alertas. Application Insights (Azure Monitor) recibe telemetría exportada de Power Platform/Dataverse con esquema estándar, solo para Managed Environments y con roles de administrador de inquilino y de entorno.
Monitor the health of your resources ↗Export data to Application Insights ↗
Implement application lifecycle management (ALM)
Las soluciones de Dataverse registran automáticamente dependencias entre componentes (por ejemplo, un plug-in que referencia una columna concreta). Estas dependencias impiden eliminar o modificar un componente si otro depende de él, y determinan qué se debe incluir al exportar una solución para que funcione en otro entorno.
Las variables de entorno externalizan valores que cambian entre entornos (URLs de API, claves, IDs de conexión) para que el mismo componente funcione en desarrollo, pruebas y producción sin modificar código. Se definen en la solución y se les asigna un valor distinto por entorno, evitando "hardcodear" configuración.
Cuando varias soluciones (no gestionadas y gestionadas, de distintos proveedores) modifican el mismo componente, Dataverse las apila en capas y solo la capa superior activa (top layer) determina el comportamiento visible. Entender el apilado de capas es clave para depurar por qué un cambio "no se ve reflejado" o entra en conflicto con otra solución.
Power Platform Pipelines automatiza el despliegue de soluciones entre entornos (dev → test → prod) directamente desde la interfaz de Power Platform, sin configurar Azure DevOps manualmente. Se pueden extender con etapas o comprobaciones personalizadas cuando el flujo de despliegue estándar no cubre necesidades específicas del proyecto.
Power Platform Build Tools son tareas para Azure DevOps (y equivalentes en GitHub Actions) que exportan, empaquetan, versionan e importan soluciones automáticamente como parte de un pipeline de CI/CD, permitiendo aplicar controles de calidad (checker de soluciones, pruebas automatizadas) antes de llegar a producción.
Practica por dominio oficial y revisa la explicación de cada respuesta.
Empezar a practicar