Task 3.3: Plan and implement app registrations

• AAccounts in this organizational directory only

  Incorrect

  Single tenant would block the partners' work accounts.

• BAccounts in any organizational directory

  Correct

  Multitenant accepts work and school accounts from any Microsoft Entra tenant, without personal accounts.

• CAccounts in any organizational directory and personal Microsoft accounts

  Incorrect

  This also lets personal Microsoft accounts sign in.

• DPersonal Microsoft accounts only

  Incorrect

  Work accounts couldn't sign in at all.

The supported account types (signInAudience) are single tenant, multitenant (any organizational directory), multitenant plus personal Microsoft accounts, and personal accounts only. Work accounts from Contoso and its partners without personal accounts means AzureADMultipleOrgs.

• AAdd a groups optional claim that lists the object IDs of every security group the user is in

  Incorrect

  Group claims carry group object IDs the app would have to map, and large memberships hit the overage limit.

• BExpose Approver and Requester as delegated scopes under Expose an API

  Incorrect

  Scopes are permissions an app requests; they don't say which business role a user holds.

• CDefine Approver and Requester app roles in the app registration

  Correct

  App roles defined on the registration are emitted in the roles claim once they're assigned.

• DAssign each security group to its app role on the enterprise application

  Correct

  Group assignment lets business owners control the roles through group membership.

• ECreate two custom Microsoft Entra roles and assign one to each group

  Incorrect

  Microsoft Entra roles grant directory administration, not roles inside your app.

App roles are defined on the app registration and assigned to users or groups (group assignment needs Microsoft Entra ID P1) on the enterprise application. Assigned roles are emitted in the roles claim, so the app reads Approver or Requester directly instead of resolving group IDs.

• AThe delegated permission User.Read.All, consented by each user

  Incorrect

  Delegated permissions act on behalf of a signed-in user, and this service has none.

• BThe delegated permission User.Read, with admin consent granted for the tenant

  Incorrect

  User.Read reads the signed-in user's own profile, and still needs a user.

• CAn app role called User.Read.All defined in the app's own manifest

  Incorrect

  Defining a role on your own app doesn't grant access to Microsoft Graph.

• DThe application permission User.Read.All, with admin consent granted for the tenant

  Correct

  App-only access through the client credentials flow uses application permissions, which need admin consent.

Apps that run without a signed-in user use the OAuth 2.0 client credentials flow and application permissions. Application permissions are always consented by an administrator for the whole tenant; delegated permissions need a signed-in user.

• AAn application management policy that blocks new verification and signing credentials

  Incorrect

  Application management policies apply within the tenant that sets them, not to service principals in customers' tenants.

• BPublisher verification for the app registration

  Incorrect

  Verification shows customers who published the app; it doesn't lock service principal properties.

• CAssignment required on the app's enterprise application in Contoso's tenant

  Incorrect

  Assignment controls who can sign in; it doesn't protect the service principals in other tenants.

• DThe app instance property lock for verification and signing credentials

  Correct

  The lock prevents those sensitive properties of the app's service principals from being changed.

App instance property lock lets the app owner lock sensitive service principal properties, such as credentials used for verification or for signing tokens and the token encryption key ID, in every tenant where the app is instantiated. Since June 2026 it's enabled by default for new applications.

• AOne application object and one service principal, both kept in Contoso's tenant only

  Incorrect

  Each tenant that uses the app gets its own service principal.

• BOne application object in Contoso, and a service principal in each tenant using it

  Correct

  The application object is the global definition; service principals are local instances.

• CAn application object in each of the three tenants

  Incorrect

  There's a single application object, in the home tenant.

• DService principals only, with no application object

  Incorrect

  The registration creates an application object in the home tenant.

Registering an app creates a globally unique application object in its home tenant. A service principal, the local instance that defines what the app can do and who can use it there, is created in each tenant where the app is used.

• A6 months

  Incorrect

  Longer lifetimes are allowed, up to a limit.

• B24 months

  Correct

  Client secret lifetime is limited to two years or less.

• C12 months

  Incorrect

  Twelve months is the recommended ceiling, not the maximum.

• DNever expires

  Incorrect

  Secrets can't be set to never expire.

Client secret lifetime is limited to 24 months, and Microsoft recommends setting an expiration of less than 12 months. Certificates or federated credentials are preferred over secrets.

• Ahttps://<tenant>.onmicrosoft.com

  Incorrect

  The default is based on the app's client ID, not the tenant name.

• Burn:microsoft:<object-id>

  Incorrect

  The default doesn't use the object ID.

• CThe app's redirect URI

  Incorrect

  Redirect URIs and the App ID URI are different settings.

• Dapi://<application-client-id>

  Correct

  The App ID URI defaults to api:// followed by the app's client ID.

When you expose an API, the Application ID URI defaults to api://<application-client-id>. It must be globally unique and becomes the prefix of the API's scopes, such as api://<id>/Employees.Read.All.

• AApplication Developer

  Correct

  This role restores the ability to create app registrations for specific people.

• BCloud Application Administrator

  Incorrect

  It can, but it also manages every app; it's more than needed.

• CGlobal Reader

  Incorrect

  Readers can't create app registrations.

• DOwnership of an existing app registration

  Incorrect

  Owning one app doesn't allow creating new registrations.

Setting Users can register applications to No stops members from creating app registrations. You can grant the ability back to specific individuals by adding them to the Application Developer role.