LowCodeStacksâ„¢
Sign in

Power Platform admin interview questions (2026) with answers

Power Platform admin interview questions with clear answers and likely follow-ups. Covers environments, data policies, security, capacity, ALM and agent governance.

Governance & adminQuick reference48 min read

Checked against Microsoft Learn · 63 sourcesPosted by the Maker DeskHow we write guides

An interview for a Power Platform admin role tests different things from a maker interview. Nobody asks you to write a formula. They ask what you'd do when the default environment fills up with apps nobody owns, when one data policy change suspends flows across the business, or when Dataverse storage runs out the week before a release.

This page answers 26 of those questions. They're grouped the way admin work is: environments, data policies, security, Managed Environments, visibility, capacity and licensing, ALM, and agents, followed by scenarios and the 2026 changes. Each answer has:

  • Short answer: what to say first, before any detail.
  • In more detail: the reasons and edge cases that make an answer stand out.
  • An example where one helps: a setting path, a PowerShell command from Microsoft's documentation, or a short scenario.
  • Follow-up they may ask: where the interviewer is likely to push next, and how to reply.

We wrote every question here; none comes from a real employer's interview. The answers follow Microsoft Learn as it stood on 20 October 2026. The PowerShell commands follow Microsoft's documented syntax and weren't run for this page. If the role also involves building, our Power Apps interview questions and Power Automate interview questions cover the maker side.

Environments and environment strategy

1. What environment types are there, and what is each one for?

Short answer: Production is for work the business relies on. Sandbox is for development and testing, and can be copied and reset. Trial is short-lived. Developer is a personal space for one maker. Every tenant also has one default environment that everyone shares. Two older options are on their way out: Dataverse for Teams environments and unmanaged developer environments are both deprecated.

In more detail:

  • An environment belongs to one Microsoft Entra tenant and one geography, and has at most one Dataverse database. An app can only use the connections, gateways, flows and database in its own environment.
  • Creating a production environment needs 1 GB of free database capacity in the tenant.
  • Trial environments expire after 30 days, and each user can have one.
  • You can stop non-admins creating production or trial environments, but Learn notes that turning a production environment into a sandbox can't be blocked.
  • A developer environment is for its owner only, so you can't attach a security group to it.
  • Some regions offer early release environments that get updates before the rest, which is a safe place to check a change before it reaches production.

Follow-up they may ask: "When does an app outgrow the default environment?" Microsoft's guidance on managing the default environment weighs four things: how many people use it, how sensitive the data is, whether a failure would cost money or reputation, and whether it needs ALM. Its table puts 1 to 10 users in the default environment, 7 to 30 in a shared one and more than 30 in a dedicated one, and highly confidential data in a dedicated one.

2. What makes the default environment different, and how do you keep it in order?

Short answer: There's exactly one per tenant, and it can't be deleted. Everyone who signs up for Power Apps becomes a maker there automatically, and nobody becomes its admin automatically. It's meant for personal productivity, not production, so we govern it as a shared space rather than a place to build business systems.

In more detail:

  • Its name is the tenant name followed by "(default)". Microsoft suggests renaming it to something like "Personal Productivity Environment" so its purpose is obvious. It stays easy to find, because it's the only environment whose type is Default.
  • You can't assign a security group to it, and you can't take a manual backup. System backups run continuously.
  • It can hold up to 1 TB, and comes with its own 3 GB of database, 3 GB of file and 1 GB of log capacity.
  • Admin roles no longer bring the Dataverse System Administrator role with them there. To avoid being locked out, Learn recommends giving that role to a few trusted users who don't hold the Power Platform administrator role.
  • Customising a SharePoint list form creates a canvas app in the default environment, unless an admin points those forms at another environment. Existing forms don't move, and flows created from SharePoint still land in the default environment.

The cmdlet that points new SharePoint custom forms at another environment:

powershell
Set-AdminPowerAppSharepointFormEnvironment -EnvironmentName '<EnvironmentName>'

Follow-up they may ask: "Would you make the default environment a managed environment?" Microsoft's guidance recommends it, for sharing limits, usage insights, the IP firewall and the Actions page. Name the cost too: in a managed environment, all active use needs a qualifying standalone licence, and from February 2027 people without one can't open apps there. In the default environment, that's potentially everyone.

3. What are environment routing and environment groups, and how do they work together?

Short answer: Environment routing sends makers to their own developer environment, instead of the default one, when they open Power Apps, Power Automate or Copilot Studio. An environment group is a folder of managed environments: rules published on the group lock those settings in every environment inside it. Point routing at a group, and every new personal environment starts life with your rules applied.

In more detail:

  • Routing is off by default, and only a Power Platform administrator can turn it on, under Manage > Tenant settings > Environment routing. Rules apply to everyone or to chosen security groups. They're checked in order, the first match wins, and if nothing matches the maker goes to the default environment.
  • Routed environments are managed developer environments, and each maker gets the admin role in their own. Building there doesn't need a premium licence, but running apps or flows there does.
  • Each one starts with sharing limited to five individuals and no security groups, solution checker set to Warn, and usage insights on. No extra data policy is added; tenant-level policies apply.
  • Routed developer environments don't use tenant Dataverse capacity. If creating one fails, the maker lands in the default environment.
  • A group can only contain managed environments. Each environment can be in one group at most, and groups can't be nested.
  • Once a rule is published, the matching setting becomes read-only in every member environment, and there are no per-environment exceptions. An environment removed from a group keeps its last settings, but they're unlocked again.
  • Watch one known limitation: when you add an environment to a group, published rules for sharing limits, welcome content, solution checker, usage insights, backup retention and generative AI settings overwrite what was set locally.
Where a routed maker lands
  1. A maker opens Power Apps
  2. The first matching routing rule applies
  3. A maker without a developer environment of their own gets a new managed one
  4. It joins that rule's environment group
  5. The group's published rules lock its settings

Follow-up they may ask: "Does the default environment have to be managed before you turn routing on?" No. Learn says routing works without it.

Data policies (DLP)

4. How does a data policy decide what a maker can connect?

Short answer: Each connector goes into one of three groups: Business, Non-Business or Blocked. Connectors from the same group can be used together, an app, flow or agent can't mix Business with Non-Business, and Blocked connectors can't be used at all. A policy is scoped to environments, and a background process enforces each change, usually within an hour.

In more detail:

  • A new policy starts with every connector in Non-Business. You then move connectors into Business or Blocked.
  • Some connectors can't be blocked in a classic policy, only grouped. They include core platform connectors such as Dataverse, Approvals and Notifications, and Microsoft 365 standard connectors such as SharePoint, Microsoft 365 Outlook and Microsoft Teams.
  • Connectors that Microsoft adds later go into the policy's default group. Learn's connector classification page says to keep that as Non-Business. Its guidance for securing the default environment recommends Blocked as the default group for a policy on that environment, so new connectors stay unusable until someone reviews them. Knowing both shows you've read beyond the basics.
  • When a change takes effect, apps, flows and agents that break the policy are suspended or quarantined. Connections to a fully blocked connector are disabled, and anything still running that uses them fails. Learn says most changes apply within an hour, and the worst cases take up to 24 hours.
  • Environment admins can create policies for their own environments, not only tenant admins.
  • The policies live in the Power Platform admin center under Security > Data and privacy > Data policy.

Follow-up they may ask: "When a maker hits a policy error, how do they know who to ask?" Use the New-PowerAppDlpErrorSettings cmdlet to add an admin email address and a "Learn more" link to data policy error messages, and Set-PowerAppDlpErrorSettings to change them later. The settings apply to every app in the tenant.

Read more: Data policy (DLP) checklist: design, roll out and support Power Platform data policies

5. A tenant policy and an environment policy both apply. Which one wins?

Short answer: Neither wins outright. Every policy that applies to the environment is evaluated together. If any one of them blocks a connector, it's blocked. Where policies group connectors differently, the strictest combination applies, which can split your connectors into many small groups that can't be mixed.

In more detail:

  • Blocked always wins. It doesn't matter if another policy puts the same connector in Business.
  • Learn's worked example uses three policies, each with two groups. Together they can split ten connectors into as many as eight combined groups, and several of those end up empty. Two connectors work together only if every policy puts them on the same side.
  • So adding an environment policy can only add restrictions: it can't unblock a connector that a tenant policy blocks, or let two connectors work together when a tenant policy separates them.
  • That's why Microsoft recommends keeping the number of policies on any one environment as small as possible.

Don't

Stack several overlapping data policies on one environment. Each extra policy with a different grouping splits connectors into more groups that can't be mixed, so makers find fewer combinations that work.

Follow-up they may ask: "Can a policy target a person instead of an environment?" Not directly. The scope options are all environments, chosen environments, or all except chosen ones. To limit people, use environment security groups, roles and routing.

6. How do you govern custom connectors, HTTP calls and specific endpoints?

Short answer: Custom connectors are listed and grouped like any other connector in environment-level policies, and classified by URL pattern in tenant-level policies. HTTP connectors can be grouped or blocked like other connectors. For finer control, connector endpoint filtering, which is in preview, allows or denies particular URLs, servers or sites for a short list of connectors.

In more detail:

  • In a tenant-level policy, you list Allow and Deny URL patterns in order. The last rule, *, is set to Ignore by default, which leaves custom connectors free to mix with both groups unless another policy classifies them.
  • In an environment-level policy, the environment's custom connectors appear alongside the others. Any you don't classify go into the default group.
  • Child flows depend on the HTTP connector behind the scenes, so where you put HTTP can affect whether child flows run. If you'd rather not put HTTP in Business in a shared environment such as the default, Microsoft suggests Non-Business or Blocked there, plus a dedicated environment for makers who need child flows.
  • Endpoint filtering covers HTTP, HTTP with Microsoft Entra ID, HTTP Webhook, SQL Server, Azure Blob Storage, SMTP, Browser Automation and UI Automation. It checks only fixed endpoints, not values from environment variables, custom inputs or addresses built at run time.
  • In Copilot Studio, endpoint filtering also covers HTTP requests and SharePoint and public website knowledge sources.

Follow-up they may ask: "What are advanced connector policies?" An allowlist model: everything is blocked unless you allow it, and new connectors start blocked. You can allow or block individual actions, and block an MCP server outright. On managed environments, they can block connectors that classic policies can't. They run alongside classic policies, where the strictest setting wins, or on their own in ACP-only mode. They cover certified connectors only, so custom and HTTP connectors still need classic policies.

Security and access

7. Which admin roles do you use, and what changed about System Administrator access?

Short answer: The service admin roles are Power Platform administrator and Dynamics 365 administrator; a Global Administrator can manage Power Platform too. None of these roles brings the Dataverse System Administrator role with it any more. An admin who needs access to data in an environment elevates themselves there, and each elevation is logged in Microsoft Purview.

In more detail:

  • Both service roles can manage environments, capacity, data policies and support requests. Neither can create users, assign licences or change Exchange or SharePoint settings.
  • One difference: a Power Platform administrator can manage an environment whether or not they're in its security group. A Dynamics 365 administrator has to be a member.
  • Assign these roles directly to people. Learn says assigning them through groups isn't supported.
  • Without elevating, an admin can still change tenant settings and view analytics and capacity. Anything that needs Dataverse access, such as changing a user's security role or installing an app, needs elevation first.
  • With Privileged Identity Management, the System Administrator role is removed again when the time-limited admin role expires.
  • Microsoft's guidance for securing the default environment: keep the Power Platform administrator role to a few people, and use just-in-time access instead of standing access.

To elevate in the admin center: Manage > Environments, select the environment, then Membership > Add me.

Follow-up they may ask: "Is there anything finer-grained than tenant-wide admin?" Inside an environment, the Environment Admin role, or System Administrator once there's a database. Power Platform role-based access control is in preview. For now it's aimed mainly at service principals working through the Power Platform API, with four built-in roles.

Read more: Dataverse access cheat sheet: privileges, access levels and 'missing privilege' errors

8. How do you control who can use an environment?

Short answer: Associate a Microsoft Entra security group with the environment. Only licensed members of the group become users there, removing someone from the group disables them, and attaching a group to an existing environment disables everyone who isn't a member. Membership only gets people in the door: they still need a security role to see any data.

In more detail:

  • You can't attach a security group to the default environment or to a developer environment.
  • Security groups and Microsoft 365 groups both work. On-premises Active Directory groups don't.
  • Members of a group nested inside the environment's group aren't added in advance. Either create a Dataverse group team for the nested group, or accept that they're added on first visit and then need a role.
  • Application users can run in an environment secured by a group without being members.
  • A canvas app can still be shared with someone outside the group, but they can't run it: they get an error saying they aren't a member of the environment's security group.
  • The least-privileged roles for each part of the job differ: Groups Administrator for membership, Power Platform or Dynamics 365 administrator to attach the group, and System Administrator in the environment to assign security roles.

Do

Give each important environment its own security group, and grant data access through Dataverse group teams linked to Entra groups, so access follows group membership.

Follow-up they may ask: "A Dynamics 365 administrator can't manage one environment. Why?" The environment has a security group and they aren't in it. Power Platform administrators and Global Administrators aren't affected by environment security groups; Dynamics 365 administrators are.

9. How would you design Dataverse access for three departments using business units, roles and teams?

Short answer: Business units set the data boundaries, security roles set what people can do, and Entra group teams hand out those roles at scale. Record sharing is for exceptions only. Plan for the fact that privileges accumulate across a user's roles and teams: you can grant extra access, but no role can subtract it.

In more detail:

  • Every Dataverse database has one root business unit, and you add child units under it. They don't have to mirror the org chart.
  • With Record ownership across business units turned on, a user can hold roles from several business units and own records in any of them. Learn calls this the matrix structure. It's under Settings > Product > Features for the environment. Learn's pages disagree about using it in production. That settings page says "Not recommended for production environments" and links to it as a preview. The ownership-based security page explains it, and how to turn it on, without that warning, and gives steps for production environments where it was turned on "during the preview period". We follow the settings page, because it's the more cautious: check the feature's status on Learn before you turn it on in production, and mention the warning if you recommend it in an interview.
  • A group team is tied to an Entra security group or Microsoft 365 group. Members are matched when they sign in, and the team's security role applies to them. The role's Member's privilege inheritance setting decides whether members get user-level access as if the role were theirs, or only team privileges.
  • Entra membership changes reach the group team at the user's next sign-in, or when the cached membership refreshes after 8 hours of continuous sign-in.
  • Owner teams can own records. Access teams can't own records or hold roles; they get access only when a record is shared with them.
  • Column-level security only works on records the user can already open.
  • Security roles and column security profiles travel in solutions. Business units and teams don't, so you create them in each environment.

Example: for Sales, Service and Finance, create three child business units and an Entra group for each. In each environment, create a group team for each group and give it that unit's role. Dataverse creates users in the root business unit when they first sign in. With Record ownership across business units turned on, they can stay there, because the team roles give them access in the right unit. If you leave it off because of the warning above, use Learn's hierarchical structure instead: move each user into their department's business unit, and give them roles from that unit.

Follow-up they may ask: "Why use group teams instead of giving each user a role?" You don't wait for each user to be synced into the environment before assigning a role. A licensed user added to the Entra group gets access straight away, and someone removed from it loses access the next time they sign in.

Read more: Security roles, business units and teams without the tangle

Managed Environments

10. What do Managed Environments add, and what do they cost?

Short answer: They're a set of premium governance features you turn on per environment. Among them are sharing limits, weekly usage insights, solution checker enforcement, the IP firewall, customer-managed keys, Lockbox, extended backup, export to Application Insights and environment groups. The cost is licensing: once an environment is managed, every active user needs a qualifying standalone licence or pay-as-you-go meter, even to run standard apps.

In more detail:

  • Learn's list also includes maker welcome content, pipelines, the catalog, virtual network support, data policies for desktop flows, masking rules and conditional access on individual apps.
  • Qualifying licences include Power Apps Premium, Power Automate Premium, Copilot Studio, Power Pages and several Dynamics 365 licences. The Power Apps per app, Power Pages and Copilot Studio pay-as-you-go meters also qualify.
  • Someone who both runs apps and runs flows in a managed environment needs only one of Power Apps Premium or Power Automate Premium, not both.
  • The Power Apps Developer Plan doesn't include Managed Environments rights for running apps and flows.
  • Microsoft is now notifying people who lack a licence: admin notices began in March 2026 and in-app notices in June 2026. From February 2027, people without a qualifying licence can't open apps in a managed environment.
  • To see who's affected, open Licensing > Power Apps in the admin center, select Download report, and pick Users requiring licenses in Managed Environments.

Follow-up they may ask: "Would you make every environment managed?" In our view, not by default. Make it the rule for environments that hold business solutions, where people already need premium licences. The licence impact is biggest in an environment full of standard apps used by people with only Microsoft 365, which usually means the default environment.

Read more: Power Apps licensing explained: Premium, per app, pay-as-you-go and the Microsoft 365 trap

11. How do sharing limits and solution checker enforcement work?

Short answer: Sharing limits cap how widely makers can share canvas apps, solution-aware cloud flows and agents in a managed environment. Solution checker enforcement scans every custom solution as it's imported, and in Block mode it stops an import that has critical issues before anything changes.

In more detail:

  • Canvas apps: no limit, or no sharing with security groups or Everyone. With that second option on, you can also cap the number of individuals.
  • Solution-aware cloud flows and agent flows: either makers can share them or they can't share them with anyone.
  • Agents: separate switches for sharing as Editor and as Viewer, an individuals-only option, and a cap on viewers.
  • Limits apply when someone tries to share. Existing access stays, but a resource that's over the limit can only be unshared until it complies. A new limit can take up to an hour to apply.
  • Solution checker has three settings. None turns it off. Warn imports the solution and reports the issues. Block cancels the import before any change is made. Only critical-severity rules block, and you can exclude individual rules.
  • Checker emails go to Power Platform and Dynamics 365 administrators and to anyone on the weekly digest list. Enforcement doesn't run while an environment is in administration mode.
  • Both live under Edit Managed Environments on the environment's command bar.

Follow-up they may ask: "Is Share with Everyone on by default?" No, it's off. While it's off, only Dynamics 365, Power Platform and Global Administrators can share an app with everyone. Microsoft recommends leaving it off, partly because the Everyone group includes guests who've ever signed in.

Visibility, monitoring and the CoE Starter Kit

12. How do you get a full picture of what's built in the tenant? Is the CoE Starter Kit still the answer?

Short answer: We'd start in the Power Platform admin center. Inventory lists every app, flow and agent with its environment and owner. Usage, Monitor and Actions cover adoption, health and recommendations. Learn now says the CoE Starter Kit is no longer actively maintained: you can still install and run it, but it gets no new features and reported issues aren't reviewed.

In more detail:

  • Inventory is under Manage > Inventory. It covers agents from Copilot Studio and Agent Builder, canvas, model-driven, code and vibe apps, cloud and agent flows, environments and environment groups. Connector usage is in preview.
  • Changes show up within 15 minutes. You can filter on any column, download everything to a CSV file, and delete a resource or block a published agent or canvas app. Blocking can be undone.
  • Know the caveats. For flows, the Owner column shows the creator and doesn't change when ownership does. Model-driven apps have no owner at all.
  • Global, Power Platform and Dynamics 365 administrators and Global Readers see everything. AI administrators and AI readers see only AI resources such as agents and agent flows.
  • To automate it, use the Power Platform for Admins V2 connector's Query Power Platform resources action, the inventory API or Azure Resource Graph. The query action needs a signed-in user: service principals get a 403 error.
  • The Actions page recommends what to look at, such as apps without a valid owner, apps unused for 60 days, and high-value apps sitting in the default environment.

Follow-up they may ask: "We already run the CoE Starter Kit. Should we remove it?" Not in a hurry; Learn says it remains available. But plan to move each scenario to Inventory, Usage, Monitor and Actions, because the kit won't get new capabilities. Learn asks for any security issue in it to go to the Microsoft Security Response Center.

13. How do you monitor health and audit what makers and admins do?

Short answer: Monitor in the admin center shows the operational health of apps, flows and agents. Microsoft Purview holds the activity and admin audit logs. Application Insights is for run-level detail, retention you choose and alerts you design.

In more detail:

  • Monitor needs tenant-level analytics turned on. Recommendations appear only for managed environments, and you need System Administrator in an environment to see its resource names.
  • Metrics are worked out daily, not in real time. Logs are kept for 7 days and metrics for 28, and resources nobody uses don't appear.
  • Canvas apps, model-driven apps, cloud flows and desktop flows are generally available in Monitor. Copilot Studio agents are in preview.
  • In Purview, collection of Power Platform admin activity is on by default in every tenant. Power Automate's audit records cover creating, editing and deleting flows and permission changes, not individual runs.
  • Application Insights holds more event data, lets you set retention, and can join events across resources. It doesn't produce Monitor's recommendations.

Follow-up they may ask: "The security team wants every flow failure in their SIEM. What do you offer?" Not Purview, because its Power Automate logs don't include runs. Export cloud flow runs to Application Insights and build the alert there, or query the run records Dataverse keeps for solution-aware flows.

Read more: Alerts for failed Power Automate flows in Application Insights

Capacity and licensing

14. Explain Dataverse database, file and log capacity. What happens when you run out?

Short answer: The tenant has one pool each of database, file and log capacity, built from its licences and add-ons, shared by every environment. Files, such as attachments and file or image columns, go to file storage. Audit and plug-in trace logs go to log storage. Almost everything else is database storage. Once the tenant is over, you can't create, copy, restore or recover environments, and Learn describes stricter stages for sandboxes in an upcoming storage validation.

In more detail:

  • Learn's capacity FAQ says environments consume 1 GB whether or not they have a database, but the capacity report doesn't count trial, developer, Microsoft Teams, preview or support environments. Routed environments are developer environments, so they don't count either.
  • Unused capacity can cover a shortage in what Learn calls a lower-value type: database can cover log or file, and log can cover file. Nothing can cover a database shortage.
  • The tenant counts as over only after that borrowing. Admins are notified when less than 15% or less than 5% is left, and when it's over.
  • Environment operations check the specific storage type, with no borrowing, and need at least 1 GB free. So a new sandbox can be refused while the tenant total looks fine.
  • Learn added guidance in September 2026 for an upcoming storage validation, with rollout details in the Message center. It applies to tenants that use Dataverse but not finance and operations apps. After 30 days over, affected sandboxes allow only admins in. After 90 days, nobody can sign in to them, though their data is kept. Production environments and sandboxes on pay-as-you-go billing don't go through those stages.

Follow-up they may ask: "Does moving capacity between environments fix a tenant overage?" No. Allocating capacity to an environment only moves what the tenant already has.

Read more: Dataverse storage capacity full? Find the culprit and free real space

15. How do Power Platform request limits look from the admin side?

Short answer: Each licensed user has a daily allowance of Power Platform requests. Identities without a user licence, such as application users, non-interactive users and the system user, share one tenant pool. If a single flow needs more, the answer is a Process licence on that flow, not a requests add-on. Microsoft says it won't enforce the official limits until at least six months after Power Automate usage reporting becomes generally available.

In more detail:

  • The shared pool starts at 25,000 requests per 24 hours for Power Apps and the same for Power Automate, with nothing added per licence. Dynamics 365 Enterprise and Professional tenants start at 500,000 and add 5,000 per user licence, up to 10 million. A tenant with several kinds of subscription gets the largest pool.
  • A flow owned by a service principal draws on that pool unless it has a Process or per-flow licence, belongs to a flow group with a Process licence, or has a designated licensed user.
  • Each requests add-on adds 50,000 requests per 24 hours, but Learn says add-ons can't currently be assigned to users or flows.
  • With Copilot Studio packs in the tenant, cloud flows that agents start can use up to 250,000 requests per 24 hours across the whole tenant, however many packs you buy. Agent flows use Copilot Credits instead.
  • Desktop flow runs don't use Power Platform requests.
  • Buying more request capacity doesn't lift connector limits or Dataverse service protection limits; those apply separately.
  • To see who's over, use Licensing > Power Automate > Usage in the admin center, which has replaced the downloadable request reports.

Follow-up they may ask: "Would moving a big data sync to a third-party integration tool avoid the limits?" No. Learn says those tools are subject to the same limits as flows.

Read more: Power Automate licensing explained: Premium, Process, and what Microsoft 365 includes

16. Which users need which licence? Keep it short.

Short answer: Microsoft 365 licences let people run apps and flows that use standard connectors. Premium connectors, custom connectors, on-premises gateways and Dataverse need premium rights: Power Apps Premium or a per app plan for apps, Power Automate Premium or a Process licence for flows. Model-driven apps are premium by default, and in a managed environment all active use needs a qualifying licence.

In more detail:

  • An app's licence designation, Standard or Premium, is shown on its details page in Power Apps.
  • Building a canvas app needs no licence. Building a model-driven app does.
  • From February 2027, Microsoft tightens checks in areas that include apps in managed environments, model-driven apps, and custom apps used outside a Dynamics 365 context. People without a suitable licence won't be able to open those apps.
  • Copilot licensing is separate again. We cover it in its own guide.

Follow-up they may ask: "What does allocating per app capacity to an environment do?" Everyone who opens the environment counts as licensed to access it. Each per app plan still covers one person using one app or one portal in that environment.

Read more: Power Apps licensing explained, Power Automate licensing explained and Microsoft Copilot licensing explained

ALM governance

17. What's your rule on managed and unmanaged solutions, and how do you enforce it?

Short answer: Unmanaged in development, managed everywhere else. You can't edit a managed solution's components directly, but unmanaged changes can still be layered on top of them in that environment. To stop that, turn on Block unmanaged customizations in production, which refuses unmanaged imports and direct edits there.

In more detail:

  • Deleting an unmanaged solution only removes the container; its components stay. Deleting a managed solution uninstalls its components, and the data in its custom tables and custom columns is lost with them.
  • You can't import a managed solution into the environment that holds its unmanaged source, so testing it always needs a second environment.
  • Block unmanaged customizations is off by default, under Settings > Product > Features for the environment. With it on, unmanaged solution imports, new components and unmanaged edits to managed components are refused. Learn's pages disagree on whether it's a preview. That settings page links to it as "Block unmanaged customizations (preview)". The feature's own page carries no preview label, and says it "is helpful in reducing unmanaged customizations in production environments". We follow the feature's own page, because it's more specific.
  • Some things still work with it on: setting environment variable values, turning flows on and off, removing unmanaged layers, exporting, and reading run history.
  • Learn lists features that clash with it. Publishing a Copilot Studio agent is one, so check the list before switching it on in an environment with agents.

Follow-up they may ask: "How can makers support their flows in production if they can't edit there?" Make them co-owners of the managed flow. With unmanaged changes blocked, a co-owner can read run history and turn the flow on or off, but can't change it. Fixes go through development and back out in a new release.

Read more: Move a cloud flow into a solution, and fix 'missing dependencies' on import

18. Who can deploy to production, and how do you control it?

Short answer: With pipelines in Power Platform, admins decide which pipelines makers can run. For production we use delegated deployment: each request waits for approval, then runs as a service principal or the stage owner instead of the maker. Each deployment request exports the solution once, and that one export moves through the stages in order, so no stage can be skipped.

In more detail:

  • With a custom pipelines host, makers need the Deployment Pipeline User role in the host, the pipeline shared with them, and rights to export from development and import into the targets. Deployment Pipeline Administrator gives full control of every pipeline in the host.
  • For a service principal stage, the service principal needs Deployment Pipeline Administrator in the host and System Administrator in each target. In Learn's setup, approval is a cloud flow that starts from the OnApprovalStarted trigger and calls the UpdateApprovalStatus action. Until then, the request waits.
  • Deployed objects belong to the identity that deployed them, so with delegated deployment that's the service principal or stage owner.
  • If a service principal stage allows sharing requests, the requester can name security groups to get access to the deployed apps, flows and roles. This only works the first time an object is deployed.
  • Pipelines need managed environments everywhere except the host and developer environments. Since October 2026, an unmanaged target has a deadline: once the admin deployment page flags it, an admin has 30 days to make it managed, plus one 30-day extension per environment, before new deployments to it are blocked. Deployments already made keep working. A host can also be set to convert its targets automatically.
  • Tenant-wide, you can make a custom host the default, which stops makers creating personal pipelines. An environment group rule can attach a default pipeline to every developer and sandbox environment in the group.
A governed release to production
  1. Maker selects Deploy
  2. The pipeline exports the solution once
  3. An approver accepts or rejects the request
  4. A service principal imports the managed solution
  5. The deployed objects belong to the service principal

Follow-up they may ask: "When would you use Azure DevOps or GitHub instead?" When you need what pipelines can't do, such as deploying to a different tenant, which Learn says pipelines don't support. The two can also work together, because pipelines can be extended.

Read more: Deploy Power Platform solutions with Azure DevOps or GitHub

Copilot and agent governance

19. What can a Power Platform admin control about Copilot Studio agents?

Short answer: Four things. Who can build agents, through licences, environment roles and routing. What agents can connect to and where they can be published, through data policies enforced in real time. How widely agents can be shared, through sharing limits in managed environments. And whether agents that use generative AI can be published at all, through a tenant setting.

In more detail:

  • Blocking Chat without Microsoft Entra ID authentication in Copilot Studio forces agents to require sign-in.
  • There are separate connectors to block knowledge sources (uploaded documents, SharePoint and OneDrive, public websites), HTTP requests, Azure Bot Service skills and individual channels such as Teams and Microsoft 365, Direct Line, SharePoint and WhatsApp. Blocking Microsoft Copilot Studio stops event triggers.
  • Learn says data policy enforcement has applied to agents in every tenant since early 2025, and exemptions are no longer supported.
  • Copilot Studio connectors introduced after 2019 are likely to be in Non-Business, the usual default group. Learn notes that many organisations block Non-Business connectors, so when publishing fails, check which group the Copilot Studio connector is in.
  • To build agents in an environment, a maker needs a security role there, such as Environment Maker.
  • Admins can also stop data moving across geographies for generative AI features, and set caps on pay-as-you-go Copilot Credit spending.
  • Inventory lists agents, and blocking a published agent stops it working in every channel. Makers can still test it in Copilot Studio.

Follow-up they may ask: "We put a security group on the Copilot Studio authors setting, but other people can still get in. Why?" Learn explains that the setting grants access to group members under pay-as-you-go; it doesn't take access from anyone else. To keep someone out, they must be outside the group and have no Copilot Studio user or trial licence and no Microsoft Copilot (formerly Microsoft 365 Copilot) licence.

Read more: Copilot Studio licensing and Copilot Credits: who needs a licence, and what uses credits

20. Where does Microsoft Agent 365 fit next to the Power Platform admin center?

Short answer: Agent 365 is Microsoft's control plane for agents across the organisation, Microsoft and non-Microsoft alike. Its registry lives in the Microsoft 365 admin center. The Power Platform admin center still governs the environments, data policies and settings that Copilot Studio agents run under. Agent 365 adds one registry for every agent, lifecycle actions and, with the right licence, policy and security controls.

In more detail:

  • Viewing the full agent inventory needs only a role, such as AI Reader. No licence is needed.
  • Microsoft 365 Enterprise, Business, Education and Frontline plans include the registry, basic actions such as publish, block, delete, approve and reassign owner, and rules that automate lifecycle actions.
  • Policy templates, activity monitoring and tenant-wide control over which tools and MCP servers agents can use need Microsoft 365 E7 or G7, or Agent 365.
  • In a tenant that onboards Agent 365, Copilot Studio agents can be represented as identities in Microsoft Entra and governed with controls such as Conditional Access. Applying those controls needs Microsoft Entra Agent ID licensing.
  • Approving agent requests and assigning owners is limited to AI Administrators and Global Administrators.

Follow-up they may ask: "Does Agent 365 replace data policies?" No. Learn presents it as adding to the Power Platform and Microsoft 365 governance you already have.

Read more: What is Microsoft Agent 365? The control plane for your organisation's AI agents

Scenario questions

Scenario questions test the order you work in. Say what you'd check first, what you'd change, and how you'd stop it happening again.

21. A maker who owns business-critical flows and apps leaves on Friday. What do you do?

Short answer: Start while their account still works: find everything they own, give each item a new owner, replace the connections that sign in as them, and check the new owners' licences. Then fix the pattern: critical automation belongs in solutions, owned by a service principal or a properly licensed service account.

Work through it:

  1. Find what they own. Filter Inventory by owner. For flows, remember the Owner column shows who created the flow, so check each flow's actual owners.
  2. Flows in solutions. Change the primary owner in place. An admin can do this, not only an owner or co-owner.
  3. Flows outside solutions. The owner can't be changed in place. Add a co-owner from the environment's Resources > Flows list in the admin center, or with PowerShell. Then move the flow into a solution if the environment has Dataverse.
  4. Canvas apps. Set-AdminPowerAppOwner makes someone else the owner and leaves the original owner with Can View.
  5. Connections. Actions that use the leaver's connections can fail once their account is gone. Switch each of those actions to a connection the new owner signs in to.
  6. Agents. The Microsoft 365 admin center lists agents without owners, and an AI Administrator or Global Administrator can assign one.
  7. Prevent a repeat. A service principal application user can own a flow and isn't tied to anyone who might leave. It has no user licence, so premium flows it owns need a Process licence, a flow group or a designated licensed user.

To list the flows someone created in an environment, then add a co-owner to one of them:

powershell
Get-AdminFlow -EnvironmentName <env name> -CreatedBy <user-object-id>
Set-AdminFlowOwnerRole -EnvironmentName <env name> -FlowName <flow name> -PrincipalType User -RoleName CanEdit -PrincipalObjectId <new owner object id>

Follow-up they may ask: "What if their account was deleted before anyone noticed?" Their flows show no owner in the admin center's flow list, and an admin can still add a co-owner there or with PowerShell. Learn also gives a script that loops through an environment's flows and lists those whose owners no longer exist in Entra.

Read more: Change a Power Automate flow's owner when someone leaves and Restore a deleted flow in Power Automate

22. The default environment is full of unowned apps, widely shared flows and experiments. Where do you start?

Short answer: Stop the inflow first, then sort out what's there. Turn on environment routing so new makers build elsewhere, make the environment's purpose clear, and put a strict data policy on it. Then use Inventory and the Actions page to find orphaned, unused and important resources. Move the important ones out through solutions, and clean up the rest with their owners.

Work through it:

  1. Stop the inflow. Turn on environment routing, and point SharePoint custom forms at another environment.
  2. Say what it's for. Rename it, for example to Personal Productivity, and set maker welcome content that explains what belongs there.
  3. Tighten it. Scope a data policy to the default environment, make Blocked its default group for new connectors, and block custom connector URL patterns you haven't approved. Keep Share with Everyone off, and set up tenant isolation.
  4. Triage. Filter Inventory to environment type Default. Check the Actions page for apps without valid owners, apps unused for 60 days, and high-value apps.
  5. Move what matters. Put each important app and its flows and tables in a solution, import it into a managed environment, give users roles through a security group, move the data, test, tell users, remove access in the default environment, and delete the old copy later.
  6. Contain what's risky. Quarantine a canvas app while you decide. Users can't open a quarantined app, makers can still edit it, and only admins can lift the quarantine.

To quarantine a canvas app with PowerShell:

powershell
Set-AppAsQuarantined -EnvironmentName <EnvironmentName> -AppName <AppName>

Follow-up they may ask: "Office 365 Outlook can't be blocked. How do you stop flows in the default environment emailing people outside the company?" With Exchange mail flow rules. Mail sent through the connector carries headers such as x-ms-mail-application, which name Power Automate or Power Apps, so an Exchange admin can block external delivery from them and exempt approved mailboxes or environments.

Read more: Data policy (DLP) checklist

23. Dataverse storage is over capacity, and a release needs a new sandbox next week. What do you do?

Short answer: Find which storage type is short and why, free space in that type, and buy time if you need to. Remember that creating, copying or restoring an environment needs free space in the specific storage type, so the new sandbox can be refused even when the tenant total looks healthy.

Work through it:

  1. Read the capacity report. Compare entitled and used capacity for database, file and log, and see which environments use the most.
  2. Find the cause in that type. Log storage holds audit logs, plug-in trace logs and elastic tables. File storage holds attachments, notes and file or image columns, among other tables. Everything else is database.
  3. Free real space. Delete data that has no business, legal or recovery value. Move inactive data you must keep into Dataverse long-term retention. Delete production or sandbox environments nobody needs, because Learn says each environment consumes 1 GB even without a database.
  4. Buy time if needed. Buy a capacity add-on, link an environment to pay-as-you-go billing, or request a temporary capacity extension. A sandbox linked to pay-as-you-go is exempt from the overage restrictions.
  5. Prevent a repeat. Set an environment alert anywhere between 50% and 100% of its allocation, and limit who can create environments.

Follow-up they may ask: "Will going over capacity stop production apps?" Not directly. Learn limits the administration-mode and disabled stages of the coming storage validation to affected sandboxes. But a job that needs a blocked operation, such as a restore, still has to wait.

Read more: Dataverse storage capacity full? Find the culprit and free real space and Power Platform pay-as-you-go on Azure

24. A department asks for its own production environment. What do you check before saying yes?

Short answer: First, whether it needs one, using the same tests Microsoft's guidance applies: users, data sensitivity, business impact and ALM. If it does, check capacity and licences, then create it in the right environment group with a security group, a data policy and a named owner, and add it to your pipeline.

Work through it:

  1. Fit. Does the solution need a dedicated environment, or would a shared one do?
  2. Capacity. A production environment needs 1 GB of free database capacity.
  3. Licences. An environment group only takes managed environments, and in a managed environment every active user needs a qualifying licence. Make sure the department has budgeted for that.
  4. Create it centrally. Set Production environment assignments to Only specific admins in tenant settings, so requests come to you. Then create the environment from Manage > Environments > New and choose its group, so the group's rules apply from the start.
  5. Secure it. Attach a security group, assign roles through group teams, and check which data policies apply.
  6. Set up ALM. Add development and test environments, a pipeline with delegated deployment, and Block unmanaged customizations in production.

Learn also documents a PowerShell setting that limits creating environments to admins:

powershell
$settings = @{ DisableEnvironmentCreationByNonAdminUsers = $true }
Set-TenantSettings $settings

Follow-up they may ask: "Could they later turn it into a sandbox without you?" Learn says converting a production environment to a sandbox can't be blocked, even when sandbox creation is restricted. So in our view, keep admin rights in that environment to a few named people.

25. A maker's flow copies customer records from Dataverse to a personal cloud storage account. How do you stop it, and stop it happening again?

Short answer: Contain it, then close the gap. Put the personal storage connector in a different group from Dataverse, or block it, in the policy for that environment: once the change applies, the flow breaks the policy and is suspended. Then check what other apps, flows and agents use that connector, and talk to the maker and their manager about what left.

Work through it:

  1. Contain. Move the connector to the other side from Dataverse, or block it. Dataverse can't be blocked, but it can be put in Business. Expect enforcement within the hour in most cases.
  2. Check every policy that applies. Policies combine, so make sure no other policy puts both connectors in the same group.
  3. Find the rest. Use Inventory's connector usage, in preview, to list everything that uses the same connector.
  4. Look at the history. Purview's Power Automate audit records show when the flow was created and edited, and when its permissions changed.
  5. Close the cross-tenant route too. Tenant isolation blocks connections to and from other Microsoft Entra tenants unless you allow them, for canvas apps and flows.

Follow-up they may ask: "Would tenant isolation alone have stopped this?" Only if the storage signed in with Microsoft Entra ID in another tenant that your isolation rules don't allow. Learn says tenant isolation applies only to connectors that use Microsoft Entra ID authentication, so a storage service that signs in another way is a job for the data policy.

What changed in 2026

26. What changed for Power Platform admins in 2026, and what's on your calendar?

Short answer: Two environment types are being retired: unmanaged developer environments, suspended from 15 December 2026, and Dataverse for Teams, suspended on 15 September 2027 and decommissioned on 30 October 2027. Licence checks in managed environments become strict in February 2027. Pipelines are being pushed onto managed targets, and the CoE Starter Kit is no longer actively maintained.

In more detail: changes during 2026

  • April 2026: workflows made with Microsoft Copilot's Workflows agent started living in a hidden environment the platform manages, one per tenant, so Inventory shows them without an environment.
  • May 2026: the date Microsoft gave for Dataverse to stop including before-and-after field values in the audit events it sends to Microsoft Purview. Read those values from Dataverse auditing instead.
  • September 2026: Learn published guidance for the coming Dataverse storage validation, covered in question 14.
  • October 2026: the admin deployment page flags pipelines that deploy to unmanaged environments, with 30 days to convert them. The release plan pages we checked also say they were archived as of October 2026, and point to Microsoft's roadmap instead.
  • No date given: Learn now says the CoE Starter Kit is no longer actively maintained.

The deadlines ahead

  • 15 November 2026: nobody can create a new unmanaged developer environment, and signing up for the Developer Plan no longer creates one. From then on, each user can create only one managed developer environment. No new Dataverse for Teams environments can be created either.
  • 15 December 2026: unmanaged developer environments start being suspended, and deletion starts on 15 January 2027. Converting one to a managed environment, or exporting its solutions, keeps the work.
  • February 2027: people without a qualifying licence can't open apps in managed environments, model-driven apps or custom apps used outside a Dynamics 365 context.
  • 15 September and 30 October 2027: Dataverse for Teams environments that haven't been upgraded are suspended, then decommissioned. Upgrading needs free tenant capacity and, afterwards, Power Platform licences for users.

Follow-up they may ask: "A department still runs important apps in a Dataverse for Teams environment. What's your plan?" Find it in the environment list: filter where Type is Microsoft Teams, and use the Last activity column. Check capacity and licences, then upgrade it or move its solutions into an existing environment. After an upgrade, team owners become System Administrators and the environment no longer depends on the team. Environments nobody needs can be left to be decommissioned.

Read more: The Power Apps Developer Plan deadline and Dataverse for Teams is retiring

Before the interview

  1. In a trial tenant, create an environment group, add a managed environment, publish a sharing limit rule, and see the setting lock.
  2. Create a data policy that separates two connectors a test flow uses, and watch the flow get suspended.
  3. Elevate yourself to System Administrator through Membership and find the event in Purview.
  4. Open Inventory, filter by owner and environment type, and download the CSV.
  5. Read your capacity report and say which storage type is growing fastest, and why.
  6. Set up a pipeline with one delegated deployment stage and an approval flow.
  7. Check Microsoft's deprecations page again before the interview, because dates move.
  8. Prepare your own questions: how many environments they run and who can create them, how many are managed, whether the CoE Starter Kit is still in use, and how ready their licences are for February 2027.

The answers reflect Microsoft Learn as of 20 October 2026. The PowerShell commands follow Microsoft's documented syntax and weren't run for this page.

Sources

Was this helpful?

Comments

No comments yet. Share what worked for you.

Sign in to comment. Comments show under a display name you choose, never your email.