Examkin

Implement Azure Security

203 questions

All types203Multiple choice102Multiple select71Ordering30
Question 1Question →

An organization is developing an ASP.NET Core Web App named ExpenseTracker. The application allows signed-in employees to submit business expenses. To support this, ExpenseTracker must perform the following actions:
1. Retrieve the profile details of the signed-in user from Microsoft Graph.
2. Retrieve a list of departments from a custom protected Web API named DepartmentService (App ID URI: api://departmentservice) on behalf of the signed-in user.

You need to configure the permissions in Microsoft Entra ID for the ExpenseTracker application registration while adhering to the principle of least privilege. Which of the following configuration steps should you perform? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Add the User.Read delegated permission for the Microsoft Graph API.; Add the api://departmentservice/Departments.Read delegated permission for the DepartmentService API.

Answer

Add the User.Read delegated permission for the Microsoft Graph API, and add the api://departmentservice/Departments.Read delegated permission for the DepartmentService API.
To access Microsoft Entra ID protected resources on behalf of a signed-in user, client applications must be configured with Delegated permissions. The User.Read delegated permission for Microsoft Graph is the least-privileged permission required to read the signed-in user's profile. For custom APIs, scopes must be defined in the target API's registration (e.g., api://departmentservice) and then consented to by the client app using the fully qualified scope syntax: api://departmentservice/Departments.Read.

Step-by-Step Solution

1
Analyze the client application type and runtime context.
The client application is an ASP.NET Core Web App where users sign in, and API calls must be made on behalf of the signed-in user. This dictates the use of delegated permissions rather than application permissions.
Delegated permissions allow the application to act on behalf of the signed-in user, enforcing the user's specific access boundaries.
2
Identify the least-privileged Microsoft Graph permission needed to retrieve the user's profile.
The User.Read delegated permission is selected.
User.Read allows the application to read the profile of the signed-in user, which satisfies the first requirement under the principle of least privilege without exposing other users' profiles.
3
Determine the correct custom API scope and format for calling the DepartmentService API.
The api://departmentservice/Departments.Read delegated scope is selected.
Custom API scopes requested by external clients must use the fully qualified URI format (prefixed by the resource's App ID URI) to successfully resolve the resource during token acquisition.

Key Concept

Microsoft Entra ID Delegated Permissions and Scope Configuration
Question 2Question →

You are developing a C# daemon application that runs as a background service on an on-premises Windows server. The application must connect to Azure Blob Storage to process files and authenticate to the Microsoft Identity Platform to obtain access tokens. The solution must meet the following security requirements:
- The application must authenticate without user interaction.
- Credentials must not be stored in cleartext in the application files.
- The authentication mechanism must follow the principle of least privilege.

You need to configure the authentication for the application using MSAL.NET. Which two actions should you perform?

Select all that apply

Show answer & explanation

Answer: Initialize the application using ConfidentialClientApplicationBuilder.Create(clientId).WithCertificate(certificate).Build() pointing to a locally installed certificate.; Request the access token by calling AcquireTokenForClient with the scope parameter set to https://storage.azure.com/.default.

Answer

To securely configure MSAL.NET for the on-premises daemon application, you must use a certificate with ConfidentialClientApplicationBuilder and request the token via AcquireTokenForClient specifying the /.default scope.
A background daemon application running on-premises must authenticate without user interaction as a confidential client. Using a client certificate allows the application to authenticate securely to Microsoft Entra ID without exposing cleartext credentials in local configuration files. Furthermore, because daemon applications do not act on behalf of a user, they must request application-only permissions using the client credentials flow, which requires the scope to be configured with the default resource suffix (e.g., https://storage.azure.com/.default).

Step-by-Step Solution

1
Determine the application type in MSAL.NET
Confidential Client Application
Since the application runs as a background service without user interaction, it is classified as a confidential client rather than a public client.
2
Select the secure credential mechanism
Client certificate configuration via WithCertificate
To satisfy the requirement of not storing credentials in cleartext (which rules out client secrets) and given the on-premises hosting context, a locally installed certificate must be used.
3
Determine the correct authentication flow and scope format
AcquireTokenForClient with the default resource scope
Daemon applications use the Client Credentials flow. This flow requires requesting the default scope of the resource (/.default) because there is no user context to delegate specific scopes.

Key Concept

Daemon applications using MSAL.NET must build confidential client instances using certificates for secure on-premises deployments and request tokens using the /.default scope.
Question 3Question →

You are developing a C# ASP.NET Core web application hosted on an Azure App Service. The App Service is already configured with a system-assigned managed identity to access an Azure SQL Database. You need to configure the App Service to access secrets in an Azure Key Vault. The Key Vault uses Azure Role-Based Access Control (Azure RBAC) for its data plane authorization. To minimize the security blast radius, you must use a user-assigned managed identity for Key Vault access. You must implement the solution using the Azure.Identity SDK and the DefaultAzureCredential class without modifying the initialization parameters of DefaultAzureCredential in your application code. Which sequence of steps should you perform to successfully retrieve the secrets?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps starts with creating the user-assigned managed identity, followed by assigning the Key Vault Secrets User RBAC role to the identity, associating the identity with the App Service, configuring the AZURE_CLIENT_ID app setting with the identity's client ID, and finally deploying the application code that instantiates the SecretClient using DefaultAzureCredential.
The correct sequence ensures that the user-assigned managed identity is first created to obtain its Client ID and Principal ID. Then, the identity is granted the Key Vault Secrets User role on the Key Vault. Next, the identity is linked to the App Service. After linking, the AZURE_CLIENT_ID app setting must be configured on the App Service to ensure that DefaultAzureCredential selects the user-assigned identity instead of the system-assigned identity. Finally, the application code is deployed, using DefaultAzureCredential to retrieve the secrets.

Step-by-Step Solution

1
Provision the user-assigned managed identity.
A Microsoft Entra ID security principal is created, returning a unique Client ID and Principal ID.
The identity must exist before any configuration or permission assignment can refer to it.
2
Assign the Key Vault Secrets User RBAC role to the identity.
The identity is authorized to read secrets from the Key Vault.
Since the Key Vault uses Azure RBAC, the identity requires data plane permissions before code execution.
3
Associate the identity with the App Service.
The App Service is configured to host the user-assigned managed identity.
This allows the App Service's identity endpoint to authenticate requests on behalf of this identity.
4
Configure the AZURE_CLIENT_ID app setting.
The AZURE_CLIENT_ID environment variable is populated on the host container.
Since the App Service has both system-assigned and user-assigned identities, DefaultAzureCredential requires the AZURE_CLIENT_ID environment variable to select the correct user-assigned identity.
5
Instantiate SecretClient with DefaultAzureCredential and deploy the code.
The application successfully authenticates and retrieves the secrets.
The code relies on all previous configuration steps to successfully acquire a token and query the Key Vault.

Key Concept

Configuring user-assigned managed identities alongside system-assigned managed identities using DefaultAzureCredential and Azure RBAC in Azure App Service.
Estimated Time:3m 0s
Question 4Question →

You are developing a background daemon service named DataArchiver that runs on a schedule to back up documents from all user OneDrive libraries to an Azure Blob Storage container. The service must authenticate silently without any user interaction.

You register DataArchiver in Microsoft Entra ID. You need to configure the permissions for Microsoft Graph to allow the service to read the files.

Which configuration should you apply to the application registration to meet the requirements while adhering to the principle of least privilege?

Show answer & explanation

Answer: Configure Microsoft Graph Application permissions for Files.Read.All, and obtain tenant-wide admin consent.

Answer

Configure Microsoft Graph Application permissions for Files.Read.All, and obtain tenant-wide admin consent.
The correct configuration is to use Microsoft Graph Application permissions for Files.Read.All and obtain tenant-wide admin consent. Because the daemon runs as a background service without a signed-in user, it must authenticate as its own identity using Application permissions rather than Delegated permissions. Additionally, reading data across all users' OneDrive libraries is a high-privilege operation that requires tenant-wide admin consent.

Step-by-Step Solution

1
Determine the authentication context and identity flow.
Since the service runs silently on a schedule with no user interaction, it must use the client credentials flow with Application permissions instead of Delegated permissions.
Delegated permissions require an active user session, whereas Application permissions allow a daemon or service to run autonomously.
2
Identify the Microsoft Graph permission required to read all users' OneDrive files.
The minimum permission needed to read files across all user libraries is Files.Read.All.
Following the principle of least privilege, Files.Read.All provides read access to all files, which is sufficient for backup purposes without granting write or delete privileges.
3
Determine the consent requirement.
Obtain tenant-wide admin consent for the Files.Read.All Application permission.
Application permissions that access organization-wide data (like Files.Read.All) cannot be consented to by regular users and require an administrator to grant consent tenant-wide.

Key Concept

Configuring Application Permissions and Consent for Daemon Apps
Estimated Time:1m 30s
Question 5Question →

You are developing a web application named DocPortal. The application must perform the following security actions:
1. Allow users to sign in and view files stored in their personal OneDrive folders.
2. Allow a scheduled background service within the application to read group memberships across the tenant without a signed-in user.

You need to configure the Microsoft Graph permissions for the application registration. The solution must adhere to the principle of least privilege.

Which two permissions should you configure? (Select two.)

Select all that apply

Show answer & explanation

Answer: Files.Read configured as a Delegated permission.; GroupMember.Read.All configured as an Application permission.

Answer

Configure Files.Read as a Delegated permission and GroupMember.Read.All as an Application permission.
Delegated permissions are required when the application needs to act on behalf of a signed-in user (such as reading the user's personal OneDrive files via Files.Read). Application permissions are required when the application runs as a background service without a user present (such as a scheduled job reading group memberships via GroupMember.Read.All). This configuration ensures proper identity context separation and complies with the principle of least privilege.

Step-by-Step Solution

1
Determine the identity context for the first requirement.
The requirement calls for a signed-in user to access their own files, which requires a Delegated permission.
Delegated permissions run in the context of the signed-in user.
2
Identify the minimum required delegated scope for the first requirement.
The scope is Files.Read.
Files.Read provides read access to the signed-in user's files, fulfilling the least privilege concept.
3
Determine the identity context for the second requirement.
The requirement calls for a scheduled background service to read group memberships without a signed-in user, which requires an Application permission.
Application permissions run in the context of the application service principal rather than a user.
4
Identify the minimum required application scope for the second requirement.
The scope is GroupMember.Read.All.
GroupMember.Read.All is the least privileged application permission that allows reading group memberships.

Key Concept

Selecting and configuring the correct permission type (Delegated vs. Application) and scope for Microsoft Graph API integrations.
Question 6Question →

You are developing a web application named ComplianceHub and a backend Web API named AuditAPI. Both applications are registered in Microsoft Entra ID. The applications must meet the following security requirements:

1. ComplianceHub must allow signed-in users to read their own audit reports from AuditAPI.
2. A background archiving service must run nightly to read all audit logs from AuditAPI without user interaction.

You need to configure the permissions and scopes for the application registrations. Which two configurations should you perform? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure AuditAPI to expose a delegated scope named Audits.Read, and grant the ComplianceHub app registration the delegated permission for api://<AuditAPI_App_ID>/Audits.Read.; Configure AuditAPI to expose an application permission (App Role) named Audits.Archive with the allowed member type set to Applications, grant ComplianceHub this permission, and obtain administrator consent.

Answer

Configure the backend API to expose a delegated scope and grant the client application the delegated permission (api://<AuditAPI_App_ID>/Audits.Read) for user-interactive operations, and configure the backend API to expose an application permission (App Role) and obtain administrator consent for background operations.
The correct configurations involve defining a delegated scope on the API and granting it to the client for user-centric access, and defining an application permission (App Role) with admin consent for the service-to-service background access. For user-interactive access, the API exposes a scope (Audits.Read) and the client requests delegated access using the App ID URI prefix. For background access, the API exposes an App Role, which is assigned to the client application and requires admin consent.

Step-by-Step Solution

1
Analyze the user-interactive requirement.
The client application must act on behalf of the signed-in user to access the API. This requires a delegated permission (scope) such as api://<AuditAPI_App_ID>/Audits.Read.
Delegated permissions allow applications to run in the context of a signed-in user, honoring their permissions and identity.
2
Analyze the background service requirement.
The service runs automatically without user interaction. This requires application permissions (App Roles) instead of delegated scopes.
Application permissions are used by daemon services or background tasks that run without a signed-in user.
3
Determine consent requirements.
Application permissions always require administrator consent, whereas delegated permissions for custom APIs may be consented to by users or administrators depending on the organization's policies.
Since application permissions grant access to data across the directory or service without user intervention, they carry higher risk and require admin approval.

Key Concept

Microsoft Entra ID delegated permissions (scopes) vs. application permissions (App Roles) and consent requirements.
Question 7Question →

You are developing a Single Page Application (SPA) using React and MSAL.js to authenticate users and obtain tokens for a downstream Web API. During the application registration in Microsoft Entra ID, you configured the redirect URI as http://localhost:3000/callback. When testing the authentication flow, the user can successfully sign in and the application receives an authorization code. However, when MSAL.js attempts to exchange the authorization code for an access token by sending a POST request to the token endpoint, the browser blocks the request with a Cross-Origin Resource Sharing (CORS) error. Which of the following describes the cause of this issue and the correct action to resolve it?

Show answer & explanation

Answer: The redirect URI was registered under the Web platform in the App Registration. You must change the platform type of the redirect URI to Single-page application (SPA).

Answer

The redirect URI must be registered under the Single-page application (SPA) platform in the App Registration to enable CORS support on the token endpoint.
The platform type of the redirect URI dictates how the Microsoft Identity Platform handles token requests. For SPAs, registering the redirect URI under the 'Single-page application' platform enables Cross-Origin Resource Sharing (CORS) on the token endpoint. Without this, the token endpoint does not send the required CORS headers, leading to browser-side errors during the authorization code exchange.

Step-by-Step Solution

1
Analyze the CORS error generated when MSAL.js calls the token endpoint.
The token endpoint is blocking the request from the browser because it did not return the required Access-Control-Allow-Origin headers.
The browser blocks cross-origin requests unless the target resource explicitly allows the origin through CORS headers.
2
Inspect the application registration settings in Microsoft Entra ID.
Identify that the redirect URI is configured under the 'Web' platform type instead of the 'Single-page application' platform type.
The 'Web' platform type is designed for confidential clients (web servers) and does not support browser-based CORS operations at the token endpoint.
3
Change the platform type of the redirect URI in the App Registration.
Migrating the redirect URI to the 'Single-page application' platform enables CORS on the token endpoint for the registered origin and configures Authorization Code Flow with PKCE.
This updates the Entra ID security configuration to allow public browser clients to securely acquire tokens directly.

Key Concept

Entra ID App Registration Platform Types and CORS
Estimated Time:1m 30s
Question 8Question →

You are developing a secure C# web application that runs on-premises. The application must sign in users and then call a downstream Web API on their behalf using the Microsoft Identity Platform.

The application is configured as a confidential client. You have already obtained the authorization code from the initial user login redirect.

You write the following code to initialize the application:

csharp
IConfidentialClientApplication app = ConfidentialClientApplicationBuilder.Create(clientId)
.WithClientSecret(clientSecret)
.WithRedirectUri(redirectUri)
.Build();

You need to complete the code to exchange the authorization code for an access token. Which code segment should you use?

Show answer & explanation

Answer: AuthenticationResult result = await app.AcquireTokenByAuthorizationCode(scopes, authorizationCode).ExecuteAsync();

Answer

AuthenticationResult result = await app.AcquireTokenByAuthorizationCode(scopes, authorizationCode).ExecuteAsync();
The application needs to exchange an authorization code for an access token to call a downstream API on behalf of a user. The app is a confidential client initialized as an IConfidentialClientApplication. The correct method to exchange the authorization code is AcquireTokenByAuthorizationCode, followed by ExecuteAsync to run the request.

Step-by-Step Solution

1
Identify the client type and the authentication flow needed.
The web application is a confidential client, and it must exchange an authorization code for a delegated user access token.
The scenario specifies a confidential client application that has already received an authorization code from a user login redirect.
2
Match the required flow to the correct MSAL.NET method.
Use the AcquireTokenByAuthorizationCode method of IConfidentialClientApplication.
This method is specifically designed to exchange the authorization code for access and refresh tokens.
3
Chain the MSAL builder execution method.
Append .ExecuteAsync() to the builder.
MSAL.NET uses a builder pattern, and .ExecuteAsync() must be called to send the asynchronous HTTP request to Microsoft Identity Platform.

Key Concept

Exchanging an authorization code for an access token using MSAL.NET ConfidentialClientApplication.
Question 9Question →

You are developing a daemon application that runs on an on-premises physical server. The application must authenticate programmatically to Azure Key Vault to retrieve secrets. You need to configure the identity for this application. Which identity configuration should you use?

Show answer & explanation

Answer: Register an application in Microsoft Entra ID to create a service principal, and authenticate using a certificate or client secret.

Answer

Register an application in Microsoft Entra ID to create a service principal, and authenticate using a certificate or client secret.
For workloads hosted on-premises, a standard application registration must be created in Microsoft Entra ID. This registration creates an application object and a service principal. The application can then authenticate programmatically using a client secret or certificate credentials to obtain Entra ID tokens and access Azure resources like Key Vault.

Step-by-Step Solution

1
Identify the hosting environment of the daemon application.
The application runs on an on-premises physical server, which is outside the Azure boundary.
Managed identities are designed for applications running within Azure on supported resources. On-premises workloads require a standard registration.
2
Select the appropriate Microsoft Entra ID identity type.
An application registration is created, which generates a corresponding service principal in the tenant.
The service principal acts as the security principal representing the application identity in Microsoft Entra ID.
3
Configure credentials for the service principal.
Generate a client secret or upload a certificate associated with the application registration.
The daemon application on-premises will use these credentials to acquire tokens from Microsoft Entra ID to access Azure Key Vault.

Key Concept

App Registrations and Service Principals vs Managed Identities
Question 10Question →

You need to use the Azure CLI to create a new application registration in Microsoft Entra ID, instantiate its service principal, and grant the service principal Contributor access to a resource group.

Which sequence of commands should you perform? To answer, move all the actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of actions is: First, run `az login` to authenticate. Second, run `az ad app create` to register the application. Third, run `az ad sp create` to create a service principal for the registered application. Fourth, run `az role assignment create` to assign the Contributor role to the service principal.
The correct sequence begins with authenticating via `az login`. Next, the application registration must be created using `az ad app create` to obtain the Application ID. Then, a service principal must be instantiated in the tenant via `az ad sp create` using that Application ID. Finally, role-based access control (RBAC) is configured by running `az role assignment create` to grant the service principal the Contributor role.

Step-by-Step Solution

1
Run `az login` to authenticate the session.
The CLI session is authenticated with Azure.
Authentication is a prerequisite for executing any commands that interact with Azure resources or Microsoft Entra ID.
2
Run `az ad app create` to register the application.
The application object is created in Microsoft Entra ID, generating an Application (client) ID.
An application object must exist in the directory before a service principal can be created for it.
3
Run `az ad sp create` to create the service principal.
A service principal object is created in the tenant, linked to the application registration.
The service principal acts as the security identity (credential holder) that can be assigned roles in Azure.
4
Run `az role assignment create` to grant access.
The service principal is assigned the Contributor role on the resource group.
Azure RBAC roles can only be assigned to existing security principals, such as the newly created service principal.

Key Concept

An Application Registration creates the global definition of the application, while a Service Principal is the local representation (security principal) in a specific tenant that receives role assignments and permissions.
Estimated Time:1m 0s
Question 11Question →

An organization is developing a multi-tenant web application. You register the application in your home Microsoft Entra ID tenant. Which resource is automatically created in a customer's tenant when their administrator consents to allow your application to access their resources?

Show answer & explanation

Answer: A service principal

Answer

A service principal
A service principal is the local representation of the application in a specific Microsoft Entra ID tenant. When an administrator consents to a multi-tenant application, a service principal is created in that tenant to hold the permissions and access configuration.

Step-by-Step Solution

1
Differentiate between the global application object and local tenant identities.
The application registration acts as the global template created in the home tenant, while the service principal acts as the local instance.
Understanding this distinction helps clarify which object is created in the target tenant to hold the local consent and permissions.
2
Analyze the consent workflow for multi-tenant applications.
When a customer administrator grants consent, Microsoft Entra ID creates a local instance of the application to authorize access to resources within that specific tenant.
This shows how the local representation is instantiated to manage permissions.
3
Select the correct Azure identity resource that represents this local instance.
The local instance created in the customer tenant is a service principal.
Service principals are the security identities used to define access policies and permissions for applications within specific Microsoft Entra ID tenants.

Key Concept

The relationship between Application Registrations and Service Principals in Microsoft Entra ID.
Estimated Time:45s
Question 12Question →

You are developing a multi-tenant web application that will be hosted in Azure. The application must access Microsoft Graph API on behalf of signed-in users from various external Microsoft Entra ID tenants. When a customer's tenant administrator consents to the application, a local representation of your application must be created in their tenant to define permissions and access controls. Which object is created in the customer's tenant to represent this local instance of the application?

Show answer & explanation

Answer: A service principal

Answer

A service principal
A service principal is the local instance of a global application object in a specific Microsoft Entra ID tenant. It is created when consent is granted to the application, serving as the security identity that defines permissions and policies for the app within that tenant.

Step-by-Step Solution

1
Analyze the requirement for multi-tenant applications in Microsoft Entra ID.
The application needs a local representation in each tenant where it is consented to by an administrator.
To govern permissions and security configuration local to that customer's tenant.
2
Differentiate between application registration and service principal.
The application registration is the global template (in the home tenant), whereas the service principal is the local instance representing the application in a target tenant.
This determines which object is actually instantiated in the target customer tenant.
3
Exclude managed identities as options.
Managed identities are designed for Azure resources to authenticate to other Azure services, not for representing multi-tenant external SaaS apps.
Managed identities cannot be shared or instantiated dynamically in customer tenants through user/admin consent flows.

Key Concept

The relationship between Application Registrations (global template) and Service Principals (local tenant-specific instance) in Microsoft Entra ID.
Question 13Question →

You are developing a multi-tenant web application that will be used by other organizations. The application requires delegated access to Microsoft Graph. You need to configure the application registration and ensure that a customer's tenant administrator can consent to the application and assign users to it.

Which sequence of actions should you perform? To answer, move all actions from the list of actions to the active area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to register the application as multi-tenant, configure the delegated API permissions, direct the customer's tenant administrator to grant consent to instantiate the service principal, and finally assign users or groups to the service principal in the customer's tenant.
The correct sequence begins by registering the application as multi-tenant to establish its identity. Next, the developer defines the required delegated API permissions on the application registration. After deployment, the customer's administrator must grant consent, which instantiates the service principal in the customer's tenant. Only after the service principal exists can the customer administrator assign users or groups to it.

Step-by-Step Solution

1
Register the application in the home tenant as multi-tenant.
Creates the application object with a unique Application (client) ID that is accessible by other tenants.
You must establish the identity of the application before you can configure its permissions or seek consent.
2
Configure the required delegated API permissions in the application registration.
Defines the specific access scopes (such as Microsoft Graph) that the application will request.
The permissions must be declared on the application registration so that administrators can consent to them.
3
Direct the customer's tenant administrator to the admin consent endpoint.
The administrator consents, which automatically instantiates a service principal (enterprise application) in the customer's tenant.
A service principal must exist in the customer's tenant to represent the application and hold permissions within that tenant.
4
Assign users or groups to the service principal in the customer's tenant.
Limits or delegates application access to specific users or groups within the customer's organization.
Users cannot be assigned to an application in the customer's tenant until the service principal has been created in that tenant.

Key Concept

Multi-tenant application registration, consent flow, and service principal instantiation
Estimated Time:2m 0s
Question 14Question →

You are designing the security architecture for a suite of internally developed Azure microservices. One of the backend services, OrderProcessor, is registered as a Web API in Microsoft Entra ID. You must enforce a policy where other client microservices (which authenticate daemon-to-daemon using the client credentials flow) cannot acquire an access token for OrderProcessor unless they have been explicitly assigned permission by an administrator. If an unassigned client service attempts to request a token for OrderProcessor, Microsoft Entra ID must deny the token request at the token endpoint. Which configuration step must you perform to enforce this behavior?

Show answer & explanation

Answer: Set the appRoleAssignmentRequired property to true on the OrderProcessor service principal.

Answer

Set the appRoleAssignmentRequired property to true on the OrderProcessor service principal.
The correct action is to set the appRoleAssignmentRequired property to true on the OrderProcessor service principal. In Microsoft Entra ID, the service principal represents the local instance of an application within a tenant. Setting this property to true restricts token issuance for that API/resource to only those users and service principals that have been explicitly assigned to one of the application's defined roles.

Step-by-Step Solution

1
Identify the authentication flow and requirements.
The scenario describes daemon-to-daemon authentication (client credentials flow) without a signed-in user context.
This establishes that the solution requires application permissions and service principal-level access controls rather than user-delegated scopes.
2
Select the correct location for enforcing token block policies.
The policy must be applied to the resource's representation in the tenant (its service principal object).
Microsoft Entra ID evaluates token requests against the target resource's service principal properties in the executing tenant, not the client's application registration.
3
Configure the assignment requirement property.
Set the appRoleAssignmentRequired property (visible as 'Assignment required?' in the Azure Portal) to true on the service principal.
This explicitly instructs Microsoft Entra ID to validate that the requesting service principal has an active app role assignment before issuing an access token.

Key Concept

Enforcing application assignment requirements on service principals for daemon-to-daemon token acquisition.
Question 15Question →

An organization is developing an automated data synchronization tool that runs on an on-premises physical server. The tool must run as a background service without user interaction and read files from an Azure Blob Storage container. You register an application named DataSyncApp in your Microsoft Entra ID tenant. You need to configure the required identity and credentials to allow the synchronization tool to authenticate and access the storage container. What should you do?

Show answer & explanation

Answer: Create a client secret or upload a certificate for the application registration, and assign the Storage Blob Data Reader role to the corresponding service principal.

Answer

Create a client secret or upload a certificate for the application registration, and assign the Storage Blob Data Reader role to the corresponding service principal.
To support unattended authentication for on-premises services, the application registration must be configured with a client secret or certificate credential. Permissions are then granted by assigning the appropriate Azure RBAC role to the service principal that represents the application in the tenant.

Step-by-Step Solution

1
Add a credential (client secret or certificate) to the DataSyncApp application registration in Microsoft Entra ID.
Allows the on-premises background service to authenticate securely with Microsoft Entra ID.
On-premises resources cannot use Azure Managed Identities natively, so they require client credentials to authenticate.
2
Locate the service principal (enterprise application) created automatically in the tenant during registration.
Identifies the local representation of the application registration used for security policy enforcement.
Permissions in Microsoft Entra ID are assigned to the service principal object, not the application object itself.
3
Assign the Storage Blob Data Reader role to the service principal at the scope of the target storage container or storage account.
Grants the tool the necessary read-only permissions on Azure Blob Storage data plane resources.
Azure Role-Based Access Control (RBAC) is the standard method for managing secure access to Azure Storage services.

Key Concept

Configuring non-interactive daemon authentication for on-premises applications using application registration client credentials and service principal role assignments.
Question 16Question →

A developer is configuring a background service running on an on-premises server that must retrieve data from a custom Web API secured by Microsoft Entra ID. The background service runs autonomously without any user interaction and authenticates using its client secret.

The developer manually updates the Microsoft Entra ID application manifest of the background service to request access to the Web API. In the requiredResourceAccess section of the manifest, the developer adds the correct resource app ID and includes the permission ID in the resourceAccess array, setting the type property of the permission to Scope.

After the developer grants administrator consent, the background service successfully obtains an access token using the OAuth 2.0 client credentials grant flow. However, when the service presents the token to the Web API, the API rejects the request with an HTTP 403 Forbidden error.

What is the cause of this authentication issue?

Show answer & explanation

Answer: The permission was configured with a type of Scope instead of Role, which prevents the permission from being included in the token during a client credentials grant flow.

Answer

The permission was configured with a type of Scope instead of Role, which prevents the permission from being included in the token during a client credentials grant flow.
The correct answer is correct because background daemon services do not have a signed-in user and must use application permissions, which are configured as type 'Role' in the application manifest. Setting the type to 'Scope' configures it as a delegated permission. When the client credentials flow is executed, only 'Role' permissions are included in the generated access token. Therefore, the token returned will lack the expected scopes/roles, resulting in an HTTP 403 Forbidden error when calling the API.

Step-by-Step Solution

1
Analyze the application type and the authentication flow used in the scenario.
The application is a background daemon service running autonomously (no user logged in) and uses the OAuth 2.0 client credentials grant flow.
Daemon services rely on application permissions because there is no signed-in user to consent to delegated scopes.
2
Examine the configuration of the application manifest.
The permission in the manifest is configured with the type property set to Scope.
In Microsoft Entra ID, Scope indicates delegated permissions, while Role indicates application permissions.
3
Determine the impact of the manifest configuration on the client credentials flow token request.
Microsoft Entra ID will not include the permission in the access token because the client credentials grant flow only requests and issues application permissions (Roles).
Since the scope permission is not included in the token, the backend API rejects the token with an HTTP 403 Forbidden error.

Key Concept

Application permissions (Roles) vs. Delegated permissions (Scopes) in Microsoft Entra ID app registrations for daemon applications.
Estimated Time:2m 0s
Question 17Question →

You register a new application in Microsoft Entra ID to integrate authentication into a custom web app. Which object is created in your home tenant to serve as the global configuration and blueprint for the application across all tenants?

Show answer & explanation

Answer: Application object

Answer

The application object is the global configuration and template representing the registered application.
The application object represents the global configuration of the registered application and acts as the template from which its local service principal representations are generated.

Step-by-Step Solution

1
Analyze the requirements for the object
The target object must represent the global configuration and act as a template/blueprint for all tenants.
Microsoft Entra ID separates the global definition of an application from its local instantiations.
2
Differentiate between Application Objects and Service Principals
An application registration creates an Application Object (global template) in the home tenant. A Service Principal represents the local instance of that application in a specific tenant.
This differentiation ensures that the application's configuration can exist once globally, while permissions and local settings can be managed per tenant.

Key Concept

Application Object vs. Service Principal
Question 18Question →

You are developing a web application that will be hosted on an Azure App Service. The application must securely retrieve database connection strings from an Azure Key Vault. You decide to use a managed identity to authenticate to the Key Vault. The identity must be dedicated to this specific App Service instance, and its lifecycle must be tied directly to the App Service so that deleting the App Service automatically deletes the identity. Which identity type should you implement?

Show answer & explanation

Answer: A system-assigned managed identity

Answer

A system-assigned managed identity
A system-assigned managed identity is directly associated with a single Azure resource instance. Enabling it creates an identity in Azure Active Directory (Microsoft Entra ID) that is tied to that resource's lifecycle. When the App Service is deleted, the identity is automatically removed by Azure, fulfilling the scenario's lifecycle requirement without manual management.

Step-by-Step Solution

1
Analyze the lifecycle requirement
The identity's lifecycle must match the App Service lifecycle, deleting when the App Service is deleted.
This requirement determines whether a system-assigned or user-assigned identity is appropriate, as system-assigned identities share their lifecycle with the host resource.
2
Evaluate identity characteristics
System-assigned identities are automatically deleted when the parent resource is deleted. User-assigned identities exist as independent Azure resources and must be manually deleted.
Selecting the system-assigned option satisfies the automatic cleanup and exclusive access requirements.

Key Concept

Managed Identity Lifecycle Boundaries
Question 19Question →

You are designing a deployment architecture for a set of five independent Azure App Service web apps. Each web app must access a shared Azure Key Vault to retrieve common application settings. Each web app is managed and scaled independently, and some may be deleted or recreated during routine updates. You need to configure a managed identity solution that minimizes administrative overhead for granting Key Vault permissions and ensures that the identity credentials persist even if individual web apps are deleted.

Which managed identity configuration should you implement to meet these requirements?

Show answer & explanation

Answer: A single user-assigned managed identity assigned to all five App Services, with that identity granted the necessary access permissions on the Key Vault.

Answer

A single user-assigned managed identity assigned to all five App Services, with that identity granted the necessary access permissions on the Key Vault.
Using a single user-assigned managed identity is the optimal choice because it exists as a standalone Azure resource. It can be shared across multiple Azure App Services, allowing you to configure a single access control rule (RBAC role or Key Vault access policy) on the Key Vault. Additionally, its lifecycle is independent of the App Services; deleting or recreating the web apps does not delete the user-assigned identity, avoiding the need to reconfigure Key Vault permissions.

Step-by-Step Solution

1
Analyze resource sharing and lifecycle requirements.
The identity must support sharing across five App Services to minimize administrative overhead and survive the deletion and recreation of the individual App Service instances.
Identifying these parameters determines whether a system-assigned or user-assigned identity is appropriate.
2
Compare managed identity lifecycles and sharing features.
User-assigned managed identities are standalone resources that can be shared, while system-assigned identities are tied 1-to-1 to a single resource instance's lifecycle.
Selecting a user-assigned managed identity satisfies the independent lifecycle and cross-resource sharing requirements.
3
Determine the required access policy configuration.
Grant Key Vault access explicitly to the selected user-assigned managed identity.
Security credentials provided by managed identities do not have access by default, and access must be explicitly granted on the target resource.

Key Concept

Architectural and lifecycle differences between system-assigned and user-assigned managed identities.
Estimated Time:1m 30s
Question 20Question →

An enterprise is migrating a legacy batch processing system to Azure. The system consists of an on-premises scheduler service that must securely upload transaction logs to an Azure Blob Storage container. Corporate security policies strictly prohibit storing passwords, client secrets, or access keys in the service configuration. You must establish authentication using a Microsoft Entra ID service principal configured with a client certificate.

You need to configure the required Microsoft Entra ID and Azure resources to establish this secure communication flow.

Which five actions should you perform in sequence? To answer, arrange the actions from the list of actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Generate a self-signed certificate locally and export the public key -> Create an application registration in Microsoft Entra ID -> Upload the public key certificate to the application registration -> Assign the Storage Blob Data Contributor role to the application's service principal -> Configure the scheduler service to authenticate using the client certificate's private key.
Establishing a secure connection without secrets requires a certificate-based flow. First, the certificate pair must be generated on the client machine to create the public key. Next, the application is registered in Microsoft Entra ID to establish its identity. After registration, the public key is uploaded to Microsoft Entra ID to associate the credential with the registration. Next, the Storage Blob Data Contributor role is assigned to the service principal in the tenant to allow data plane access. Finally, the daemon scheduler is configured with the private key locally to acquire access tokens using the client credentials flow.

Step-by-Step Solution

1
Generate a self-signed certificate locally and export the public key certificate (.cer) file.
A public/private key pair is created, and the public key is saved in a .cer file.
This establishes the cryptographic trust foundation where the private key remains secure on-premises.
2
Create an application registration in Microsoft Entra ID.
An application object is created globally, and a corresponding service principal is generated in the home tenant.
A directory identity must exist before you can assign credentials or configure access permissions.
3
Upload the public key (.cer) file to the Certificates & secrets section of the application registration.
The public key is bound as a credential to the Entra ID application object.
This allows Microsoft Entra ID to validate signed JSON Web Tokens (JWTs) presented as client assertions during authentication.
4
Assign the Storage Blob Data Contributor role to the application's service principal at the storage account scope.
The service principal is granted read/write permissions to the blob storage data plane.
Security permissions are evaluated against the service principal (the local instance of the app in the tenant), not the application object itself.
5
Configure the scheduler service to authenticate using the client certificate's private key to acquire an Entra ID token.
The service requests and receives an access token from the Microsoft Entra ID token endpoint to perform authorized blob operations.
The client application uses the private key to sign a client assertion locally, preventing any secret or key transmission over the network.

Key Concept

Configuring certificate-based client credentials flow using Microsoft Entra ID application registrations, local service principals, and role assignments.
Estimated Time:3m 0s
Page 1 / 11Next