SC-100 Practice Question: Design security solutions for applications and data

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Admin consent for all scopes

  Why it's wrong here

  Admin consent for all scopes is not a actual permission or scope; it is an administrative action that pre-approves every permission the app requests, including many that are irrelevant to reading a single user's profile. Granting this would authorize broad, potentially sensitive Graph scopes (e.g., mail, files, directory) without any user-specific restriction, effectively bypassing the principle of least privilege. Even if the app only needs User.Read, this action does not selectively grant that scope—it blankets all requested permissions, creating an unnecessary security risk and confusing the permission model.

• ✗

  Application permissions for Microsoft Graph

  Why it's wrong here

  Application permissions for Microsoft Graph use the client credentials OAuth 2.0 flow, which authenticates the app itself with no signed-in user context. This design is for background services or daemons that operate tenant-wide, so it cannot meaningfully read 'the signed-in user's profile' because there is no user to represent. Such app-only access also typically requires tenant-wide admin consent and grants broad data access across all users, directly violating least-privilege principles for a user-scoped Teams app.

• ✓

  Delegated permissions with User.Read

  Why this is correct

  Delegated permissions with User.Read are the correct choice because the app calls Microsoft Graph with a token that includes the signed-in user's identity and consent scope. This scope is the minimal privilege needed to read the current user's profile—name, email, photo, and other basic attributes—while preventing access to other users' data. The user or an administrator can consent to this scope during app usage, and it aligns with the Teams app's requirement to access only the caller's own profile.

• ✗

  Delegated permissions with User.Read.All

  Why it's wrong here

  Delegated permissions with User.Read.All allow the signed-in user's token to read the profiles of all users in the tenant, not just their own. Although this still uses a delegated identity, it is vastly over-privileged for an app that only needs the current user's own profile, expanding the potential data exposure to the entire directory. This scope also typically requires a higher level of consent (sometimes tenant admin consent), which is unnecessary overhead and contradicts least-privilege security practices for a focused user-profile scenario.

Go deeper

Related to this question