A developer needs to configure a Copilot Studio agent deployed in Microsoft Teams so that it accesses the user's own Microsoft 365 calendar data. Each user should see only their own calendar events, not a shared service account's calendar. The connection must use the user's identity at runtime without requiring them to re-enter credentials each session. Which authentication configuration achieves this requirement?

Microsoft identity platform OAuth 2.0 supports two types of permissions: delegated permissions and application permissions. Understanding which to use is fundamental to agent authentication design.

The configuration that uses Azure Active Directory with OAuth 2.0, sets the scope to Calendars.Read, and enables 'Require users to sign in' is correct because it makes the agent request a token on behalf of the signed-in user. The user's own identity is used to authorize the calendar read, so they see only their own calendar data. The 'Require users to sign in' setting in Copilot Studio triggers the OAuth authorization code flow at the start of the conversation, obtaining a user-delegated access token. When deployed in Teams, Teams Single Sign-On can be leveraged to automatically pass the user's Teams identity to the agent, eliminating the need for repeated credential entry across sessions.

The approach that registers an app in Azure Active Directory with application permissions for Calendars.Read.All, stores the client secret in environment variables, and uses a service principal to read calendars based on the signed-in user's UPN is incorrect because application permissions allow the app to read any user's calendar without a signed-in user context. This is a service-to-service permission that uses a client secret or certificate for authentication; it does not scope the data to the conversation user's identity. The developer would need to explicitly filter calendar reads by UPN, and this approach violates the principle of least privilege by granting access to all calendars.

The approach that configures the agent's connection to Microsoft 365 using the connector's default authentication, selects the shared mailbox option, and maps calendar data to the conversation user's email address using a Power Fx lookup is incorrect because the shared mailbox option in a connector is designed for accessing a mailbox that multiple users share, not for accessing each user's personal calendar. Mapping calendar data via a Power Fx lookup on the user's email does not override the shared mailbox authentication context; the connector still authenticates as the shared mailbox account, not as the individual user.

The approach that creates a Power Automate flow accepting the user's email as an input, authenticating to the Graph API using a service account stored in key vault, reading the user's calendar, and returning events to the agent as JSON output is incorrect because using a service account in a Power Automate flow to read user calendar data is equivalent to application-level access. The service account acts as a privileged identity reading on behalf of users. This approach breaks the user-delegated access requirement and introduces security risks by centralizing a privileged service account credential. It also adds unnecessary flow overhead for a scenario that should be handled natively by the agent's authentication layer.

Exam tip: The key distinction is delegated vs. application permissions. Delegated means the user's identity, limited to their own data, and requires sign-in. Application means a service identity, can access any data, and requires admin consent. Scope names matter: Calendars.Read is delegated, while Calendars.Read.All is application. If the requirement says each user sees only their own data, the answer is delegated OAuth with user sign-in.