How Do You Lock a Power Pages Chatbot to Entra ID Users?
A company deploys a chatbot that is embedded in a Power Pages website. The company has the following requirements for the chatbot: • Microsoft Entra ID users only must be able to use the chatbot when accessing sensitive data. • The chatbot must be accessible only from the Power Pages website. You need to recommend a solution that meets the requirements. Which two options should you recommend? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.
Community Votes
57% of anonymous learners picked answer CE. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests the split between Copilot Studio authentication settings (who may chat) and channel security settings (where the bot can be embedded) — the common trap is treating "set up a new channel" as the way to pin the bot to Power Pages.
A Power Pages-embedded chatbot must be limited to Microsoft Entra ID sign-in and reachable only from the company website, so the correct recommendation pairs manual authentication with web channel security. This page explains why D and E satisfy both PL-200 requirements while a new channel does not.
Many learners choose C ("Set up a new channel") for the website restriction, but adding a channel only creates another endpoint; web channel security is what limits the bot to the Power Pages domain.
Community Discussion (7 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The first requirement is about identity: only Microsoft Entra ID users may use the chatbot when sensitive data is involved, and that is an authentication decision. Manual authentication in Copilot Studio lets you configure the OAuth connection to Microsoft Entra ID, so visitors to the site sign in and the bot receives the user's token. The second requirement is about reachability: the bot must be usable only from the company's Power Pages website, which is exactly what web channel security does — once enabled with the Power Pages domain listed, anyone who copies the bot ID cannot chat from another site. Option A cannot cover this because "Only for Teams" authentication is bound to Teams sign-in, and this bot is exposed on the web, not in Teams. D and E is therefore the only pairing where each option maps one-to-one to a stated requirement.Why the Other Options Are Wrong
A is wrong: enabling Only for Teams authentication restricts usage to Teams users, which contradicts both the website embedding and the "Entra ID users" (not "Teams users") requirement. B is wrong: a data loss prevention policy is a data-governance control over connectors and content, not a sign-in or channel-restriction control, so it never limits who chats or where the bot is hosted. C is wrong: setting up a new channel simply creates another way into the bot; it does not require Entra ID sign-in and does not lock the bot to the Power Pages domain, which is the job of web channel security. That leaves D and E, which together close both gaps in the scenario.Community Comment Notes
The source key and a slim majority (57 votes for CE against 43 for DE) favour C and E, with DaanEp arguing that "A, B, and D do not directly address the specified requirements." That argument only holds if a new channel somehow delivers Entra ID-only access, and it does not; Hamed64 pointed out that manual authentication "allows you to configure the chatbot to authenticate users with Microsoft Entra ID," which is precisely requirement one. MrEz added a useful nuance on the web channel, noting that because the bot ID can be shared, "With Direct Line-based security, you can enable access only to locations that you control" — the exact control web channel security exercises. The tight DE/CE split shows how easily an authentication setting is mistaken for a channel setting on this objective.Official Reference
Exam Strategy
Reduce the scenario to two verbs: "who may sign in" and "where it can be used." The first verb always points to an authentication option (manual authentication for Entra ID on the web channel), and the second always points to a channel-security option (web channel security with the Power Pages domain). Any answer that names a new channel instead of one of those two controls is only creating another entry point, not enforcing a requirement.
Frequently Asked Questions
Why is "set up a new channel" not enough to keep the chatbot on Power Pages?
Adding a channel only creates another entry point, and anyone who obtains the bot ID could still use it. Web channel security is the setting that limits the bot to your Power Pages domain.
Why does manual authentication fit the Entra ID requirement for a Power Pages bot?
Manual authentication lets you configure the OAuth connection to Microsoft Entra ID, so only signed-in Entra ID users can chat when sensitive data is involved.