Study guide
2.1 Managing Power Platform Environments for Development
Microsoft Power Platform Developer Associate PL-400
Track your progress as you read
Finished sections get a check mark.
1 Introduction, Exam Overview & Developer Toolchain
0.1 PL-400 Exam Facts 0.2 Audience Profile & Required Developer Skills 0.3 The Power Platform Developer Toolchain 0.4 Extension-Point Map & AI in the Developer Workflow
2 Create a Technical Design
1.1 Analyzing Technical Architecture and Choosing Out-of-the-Box vs. Custom Solutions 1.2 Designing Authentication, Authorization, and Security Architecture 1.3 Deciding Where Business Logic Runs and Choosing the Right Table Type 1.4 Designing Reusable Power Apps Components and Custom Connectors 1.5 Designing Dataverse Code Components, Automations, and Integrations
3 Build Power Platform Solutions
2.1 Managing Power Platform Environments for Development 2.2 Dataverse Security Roles for Code Components, Least Privilege & Troubleshooting Operational Security 2.3 Solutions, Managing Dependencies & Solution Layers 2.4 Environment Variables & Connection References 2.5 Power Platform Pipelines & CI/CD with Power Platform Build Tools
4 Implement Power Apps Improvements
3.1 Complex Power Fx Formulas and Functions 3.2 Building Reusable Canvas Component Libraries 3.3 Invoking Power Automate Cloud Flows from a Canvas App 3.4 Troubleshooting Canvas and Model-Driven Apps with Monitor and Browser Debugging Tools 3.5 Optimizing Canvas and Model-Driven App Performance
5 Extend the User Experience
4.1 The Client API Object Model & JavaScript Form Scripting 4.2 Event Handler Registration & Navigation to Custom Pages via the Client API 4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript 4.4 PCF Fundamentals: The Component Manifest & Lifecycle Events 4.5 Implementing PCF Component Interfaces; Device, Utility & Web API Features 4.6 Packaging, Deploying & Consuming a PCF Component
6 Extend the Platform: Dataverse Plug-ins & Custom APIs
5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages 5.2 Execution Context & Implementing Business Logic in Plug-ins 5.3 Pre/Post Images & Organization Service Operations in Plug-ins 5.4 Registering Plug-ins with the Plug-in Registration Tool & Optimizing Plug-in Performance 5.5 Custom API Messages & Plug-ins That Implement a Custom API 5.6 Configuring Dataverse Business Events
7 Extend the Platform: Custom Connectors
6.1 Open API Definitions: Building and Extending a Custom Connector 6.2 Authentication and Policy Templates for Custom Connectors 6.3 Importing Definitions and Creating Connectors for Azure Services 6.4 Azure Functions in Custom Connectors and Data Transformation
8 Extend the Platform: Platform APIs & Azure Functions
7.1 Dataverse Web API Operations & OAuth Authentication 7.2 Organization Service Operations, Concurrency, Transactions & Bulk Operations 7.3 Service Protection API Limits & Retry Policies 7.4 Azure Functions for Long-Running, Scheduled & Event-Driven Workloads 7.5 Authenticating to Power Platform with Managed Identities
9 Extend the Platform: Power Automate Cloud Flows
8.1 Dataverse connector triggers/actions, trigger filters & retry policies 8.2 Complex expressions & flow control with error handling 8.3 Sensitive input/output parameters & Azure Key Vault 8.4 Reusable child flows & Microsoft Entra ID service principals
10 Develop Integrations
9.1 Publishing Dataverse Events: IServiceEndpointNotificationService & the Plug-in Registration Tool 9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub 9.3 Data Synchronization with Change Tracking & Alternate Keys 9.4 Upsert-Based Synchronization with the UpsertRequest Message
11 Exam Readiness & Practice
10.1 Cross-Domain "Where Do I Implement This?" Decision Framework 10.2 Exam-Day Strategy, PL-400 Item Styles & Study Plan
2.1 Managing Power Platform Environments for Development
Key Takeaways Explain This Topic AI
Production and Sandbox environments always provision a Dataverse database, while Trial environments are time-boxed to 30 days.
Developer environments are provisioned free per individual user and are the recommended home for solo plug-in, PCF, and connector development.
pac auth create and pac auth select manage the CLI's active environment authentication profile for scripted deployments.
Managed solutions belong in Production; unmanaged, in-progress customizations belong in Development and Sandbox environments.
Microsoft Entra security groups can restrict who sees an environment in the maker portal, independent of Dataverse security roles.
Last updated: July 2026
Managing Power Platform Environments for Development
Quick Answer: A Power Platform environment is a container - usually holding one Dataverse database - for apps, flows, connections, and code components. PL-400 developers need to know which environment type to build in (Developer or Sandbox), how to provision and authenticate against environments from the Power Platform CLI, and why Production should only ever receive managed solutions.
For PL-400 candidates, environment strategy is not an admin afterthought. Every plug-in, custom API, PCF component, custom connector, and cloud flow you build is developed, deployed, and tested inside environments, and a poorly planned environment topology breaks ALM before a single line of code ships.
Environment Types
- Environment type Dataverse database Typical use
- Production Always Live, business-critical apps and data; managed solutions only
- Sandbox Always Non-production; safe for testing; can be reset, copied, or promoted to Production
Developer Always (one per user) Free, individual environment tied to one Microsoft Entra ID user; ideal for solo plug-in/PCF development
Trial Optional Time-boxed to 30 days; evaluation only
Default Always Created automatically per tenant; every licensed user is a maker here; not recommended for solution development
A minimum viable ALM topology for a PL-400 developer is at least two environments: a Development sandbox (or Developer environment) where unmanaged customizations are authored, and a Production environment where only managed solutions are imported. Many teams add a Test/UAT sandbox between the two so QA validates a solution package before it reaches production.
Choosing the Right Environment for Development Work
Developer environments are provisioned free per user (through the Power Apps Developer Plan) and are the right home for individual plug-in, PCF, and custom-connector development, because they isolate a single developer's in-progress, unmanaged work from the rest of the team.
Sandbox environments back shared team development, integration testing, and UAT. They can be copied - a full copy or a copy without customer data - from Production to reproduce a realistic dataset for debugging, and they can be reset to start clean.
Production should only ever receive managed solutions through a deployment pipeline - never unmanaged, in-place customization - so environment strategy and solution/ALM strategy (covered later in this chapter) are two sides of the same coin.
Provisioning and Managing Environments
Environments are created and managed from the Power Platform admin center, or programmatically for CI/CD scenarios with the Power Platform CLI:
pac admin create - provisions a new environment (type, region, Dataverse database, currency/language) from the command line, which is useful for scripting throwaway test environments inside a pipeline.
pac auth create --url <environment URL> - creates an authentication profile so subsequent pac commands (solution export/import, PCF push, plug-in deployment) target the right environment; pac auth select switches the active profile when a developer or pipeline works across multiple environments.
pac org who - confirms which environment and user context the CLI is currently authenticated against, which is the first troubleshooting step when a deployment lands in the wrong place.
Security Group Restriction and Environment Access
Admins can restrict who can even see an environment in the maker portal by assigning a Microsoft Entra security group to it. As a developer, this matters because losing access to a dev environment - for example, after a group membership change - is a common "why can't I open my solution" support case. Check environment security-group membership before assuming a Dataverse security-role problem (covered in the next section).
Backup, Restore, and Capacity
Every Dataverse environment consumes tenant-level storage capacity (database, file, and log) and API request entitlements, which admins monitor centrally. Sandbox and Production environments support system-generated and on-demand backups, and a sandbox can be restored to a prior point in time - useful when a bad deployment or bulk data operation needs to be rolled back for investigation. Developer environments are capped and excluded from certain capacity pools, which is exactly why they are safe defaults for experimentation but unsuitable for production workloads.
Exam Angle
PL-400 scenario questions in this area typically describe a symptom - "a developer cannot deploy a plug-in assembly to environment X" or "changes made in a sandbox never appear in production" - and ask you to identify the missing environment-management step: the wrong environment type was provisioned, the CLI auth profile pointed at the wrong environment, or the developer lacked environment-level access. Recognize that environment management is the foundation the rest of this chapter sits on: security roles, solution layers, environment variables, and pipelines all operate within an environment boundary that must be correctly provisioned first.