SC-300 - Plan and Implement Workload Identities - Section 3.4

Plan and implement app registrations, app authentication, API permissions, and app roles.

Create and configure app registrations including app authentication credentials, redirect URIs, and app roles in Microsoft Entra ID. Distinguish delegated permissions - which act on behalf of a signed-in user - from application permissions, and apply the principle of least privilege when requesting API permissions.

app registrationsapp authentication and redirect URIsAPI permissionsdelegated versus application permissionsapp roles

Practice question for this objective

Free samplePlan and Implement Workload Identitiesmedium

A background daemon service has no signed-in user and must read all users' profiles from Microsoft Graph on a recurring schedule. The identity team registers the application and must decide which kind of Microsoft Graph permission to configure and how access is authorised. What is the correct approach?

  • AConfigure application User.Read.All permission and grant tenant-wide admin consent for the registered application. Correct
  • BConfigure delegated User.Read.All permission and have the daemon prompt each user to consent the first time their profile is read.
  • CConfigure delegated User.Read.All permission and enable the admin consent workflow so an administrator approves the request to run the daemon.
  • DConfigure application User.Read.All permission and let each user grant user consent the first time the daemon reads their data.
Unattended daemon apps use application permissions, which act without a signed-in user and require tenant-wide admin consent rather than delegated permissions or user consent. Microsoft Graph distinguishes delegated permissions, which combine the app's and a signed-in user's privileges, from application permissions, which let the app act as itself with no user present. A background daemon has no interactive user, so it must use application permissions, and those can only be authorised by an administrator granting tenant-wide admin consent. Delegated permissions and user consent both depend on a signed-in user, so they cannot serve an unattended workload.

Why A is correct: Application permissions let the app act as itself without a user, and admin consent authorises that permission across the tenant, which is exactly how an unattended daemon reads all profiles from Microsoft Graph.

Why B is wrong: Delegated permissions act on behalf of a signed-in user and require an interactive sign-in, which a background daemon with no user cannot provide, so this approach cannot run unattended.

Why C is wrong: The admin consent workflow routes a user's request for delegated access to an approver, but delegated access still needs a signed-in user, so the daemon cannot operate without an interactive session.

Why D is wrong: Application permissions can never be authorised by user consent; they require admin consent, so relying on per-user consent leaves the daemon unauthorised for its app-only calls.

See more SC-300 practice questions, answers explained.

More in this domain

Back to all Plan and Implement Workload Identities objectives, or the SC-300 cert hub.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.