SC-300 - Plan and Implement Workload Identities (25% of the exam) - 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.

Exam traps in Plan and Implement Workload Identities

Answers that look right on this material and are not. Each one is a distractor from a different question in the SC-300 bank for this domain.

Define security groups named Approver and Viewer, add the groups as members of the enterprise application, and have the app read group membership claims to decide permissions.
Why it is wrong: Groups can be emitted as claims, but groups are general directory objects added to apps as assignments rather than as app-specific authorisation values, and large group claims can be omitted, making them a weaker fit than purpose-built roles.
Microsoft Entra directory roles such as User Administrator, assigned to the relevant users so their tenant role membership is reflected in the application's token.
Why it is wrong: Directory roles govern administrative permissions over the tenant and are not emitted as application authorisation claims, so they cannot drive approver-only screens in a custom app.
Add the scopes under API permissions on the API's app registration so clients can select them
Why it is wrong: API permissions is where a client app requests access to other APIs, which is the consuming side, not where the API itself publishes the scopes it offers, so this is the wrong blade.

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