For a policy intended to control user access to Power Platform, I would strongly recommend avoiding selecting every resource with a name containing Power Platform, Power Apps, or Dataverse. Many of those service principals are backend services and adding them unnecessarily can cause unexpected authentication or functionality issues.
A better approach is:
Start with the main user-facing resources you want to protect:
Microsoft Power Apps
Microsoft Power Automate / Microsoft Flow
Dataverse
Power Apps and Power Automate
Power Virtual Agents / Copilot Studio, if applicable
Test the policy in Report-only mode first.
Use the Microsoft Entra sign-in logs to identify which applications/resources are actually being accessed and which Conditional Access policy would affect them.
Add additional Target Resources only when testing or sign-in logs demonstrate that they are required for your particular Power Platform scenario.
Resources such as Power Platform Global Discovery Service, Environment Discovery Service, Dataverse Resource Provider, Power Platform API, PowerApps-Advisor, and various backend/data-plane services should generally not be added simply because they appear related to Power Platform. Some are service/backend components rather than the primary interactive applications you are trying to govern.
Also, if your objective is "block Power Platform access except for members of an exemption group," make sure the policy design is tested carefully across:
Power Apps portal
Power Automate portal
Dataverse-backed apps
Model-driven apps
Canvas apps
Power Platform admin functionality
API/integration scenarios
The most practical way to determine the true minimum in your tenant is therefore Report-only mode + Entra sign-in logs, rather than relying on a static list, because Microsoft's underlying service/application architecture can change and different Power Platform workloads authenticate against different resources.
In short: start with the primary user-facing Power Platform resources, don't automatically include every backend service principal, and use sign-in logs to identify anything additional that is genuinely required.
