2.1 Managing Power Platform Environments for Development

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

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.