Implement Azure Security

203 questions

Question 61Question

A developer is configuring security for an Azure App Service instance. They need to understand how managed identities behave when the App Service is deleted or updated. Which of the following statements correctly describe the characteristics of a system-assigned managed identity? (Select TWO).

Select all that apply

Show answer & explanation

Answer: The identity is tied directly to the lifecycle of the Azure App Service instance.; The identity is automatically deleted when the associated Azure App Service instance is deleted.

Answer

The correct statements are that the system-assigned managed identity is tied directly to the lifecycle of the Azure App Service instance, and it is automatically deleted when the associated App Service instance is deleted.
A system-assigned managed identity is created directly on an Azure resource instance (such as an App Service). As a result, its lifecycle is directly tied to that resource: it is automatically deleted when the resource is deleted, and it cannot be shared with or assigned to any other resources.

Step-by-Step Solution

1
Analyze the lifecycle characteristics of system-assigned managed identities.
System-assigned managed identities are enabled directly on a resource, and their identity in Microsoft Entra ID is tied directly to that resource.
This establishes that the identity's existence depends entirely on the resource's existence.
2
Determine the behavior of the identity when the hosting resource is deleted.
Deleting the Azure App Service instance automatically triggers the cleanup and deletion of the associated system-assigned identity in Microsoft Entra ID.
This ensures that no orphaned identities remain when resources are decommissioned.
3
Contrast with user-assigned managed identities to eliminate incorrect options.
User-assigned managed identities are created as independent Azure resources and can be shared across multiple Azure resources, whereas system-assigned identities are exclusive and have a dependent lifecycle.
This distinguishes system-assigned identities from user-assigned identities.

Key Concept

Managed Identity Lifecycle and Resource Binding
Question 62Question

You are developing a C# desktop application that needs to authenticate users against Microsoft Entra ID using the Microsoft Identity Platform.

Which two components from the Microsoft.Identity.Client namespace must you use to configure and represent the client application?

Select two.

Select all that apply

Show answer & explanation

Answer: PublicClientApplicationBuilder; IPublicClientApplication

Answer

The application must use PublicClientApplicationBuilder to configure the application and IPublicClientApplication to represent the instantiated client application.
For a desktop application, which cannot securely store client secrets, you must use a public client flow. In MSAL.NET, public client applications are configured using the PublicClientApplicationBuilder and represented by the IPublicClientApplication interface.

Step-by-Step Solution

1
Determine the application type based on the deployment scenario.
Since a desktop application runs on a user's device and cannot keep client secrets secure, it is classified as a public client application.
Microsoft Identity Platform distinguishes between public clients (desktop/mobile) and confidential clients (web apps/daemons).
2
Select the correct builder class to instantiate the application.
Use the PublicClientApplicationBuilder class from the Microsoft.Identity.Client namespace to build the application configuration.
The builder pattern is used in MSAL.NET to construct the client application instance with required settings like Client ID and Tenant ID.
3
Identify the correct interface type representing the instantiated client.
The builder's Build() method returns an object implementing the IPublicClientApplication interface.
IPublicClientApplication provides the methods needed to acquire tokens for public clients, such as AcquireTokenInteractive.

Key Concept

Identifying MSAL client types and initializing MSAL.NET public client applications.
Question 63Question

You are developing a command-line interface (CLI) application that will run on Linux servers without a graphical user interface or local web browser. The application must authenticate individual users against Microsoft Entra ID before executing commands. Which MSAL.NET method should you use to perform the authentication?

Show answer & explanation

Answer: AcquireTokenWithDeviceCode

Answer

The correct option is AcquireTokenWithDeviceCode, which initiates the Device Code Flow for environments without a local web browser.
The method AcquireTokenWithDeviceCode executes the OAuth 2.0 Device Authorization Grant. This flow provides the user with an verification URL and a code to perform authentication on a separate, browser-equipped device, making it ideal for headless command-line interfaces.

Step-by-Step Solution

1
Analyze the execution environment constraints.
The CLI application runs on a headless Linux server with no GUI or local web browser.
This rules out standard interactive flows that rely on launching a local system browser.
2
Identify the authentication subject.
The application must authenticate individual users (delegated permissions), not the application itself.
This rules out client credential flows meant for daemon/service identity.
3
Select the appropriate OAuth 2.0 flow for headless user authentication.
The Device Code Flow is designed for this scenario, allowing the user to sign in on a separate device using a code and a browser.
The MSAL.NET library implements this flow using the AcquireTokenWithDeviceCode method.

Key Concept

Microsoft Identity Platform Device Code Flow
Question 64Question

You are developing a secure background daemon application in C# that runs as an on-premises scheduled task. The application must periodically retrieve records from a secured downstream Azure Web API. The organization's security policy strictly prohibits the use of client secrets (passwords) for authentication. Instead, you must authenticate using a client certificate. You have already registered the daemon application in Microsoft Entra ID.

Which two of the following actions must you perform to configure the application registration and implement the authentication flow using MSAL.NET? (Select two.)

Select all that apply

Show answer & explanation

Answer: In the C# application code, retrieve the certificate and instantiate the client using ConfidentialClientApplicationBuilder.Create(clientId).WithCertificate(certificate).WithAuthority(AzureCloudInstance.AzurePublic, tenantId).Build().; In the Microsoft Entra admin center, select the registered application, navigate to Certificates & secrets, select the Certificates tab, upload the public key file (.cer) of the certificate, and save.

Answer

The application must be configured in Microsoft Entra ID by uploading the public key (.cer) to the Certificates tab of the Certificates & secrets page, and implemented in C# by instantiating the client using ConfidentialClientApplicationBuilder.Create(clientId).WithCertificate(certificate).WithAuthority(AzureCloudInstance.AzurePublic, tenantId).Build().
For a daemon application to authenticate securely using a certificate, it must register the public key in Microsoft Entra ID under the application's Certificates & secrets section, and the application code must use the ConfidentialClientApplicationBuilder class with the WithCertificate method to sign the client assertion and acquire tokens.

Step-by-Step Solution

1
Upload the public key file (.cer) of the certificate to the daemon application registration in Microsoft Entra ID.
Microsoft Entra ID has the public key needed to verify assertions signed by the application.
This establishes trust between Microsoft Entra ID and the daemon application without relying on a password-like client secret.
2
Use ConfidentialClientApplicationBuilder in the C# code, passing the private key certificate using the WithCertificate method.
The application is configured as a confidential client and is ready to generate signed client assertions for authentication.
Daemon applications run in secure server environments and are capable of maintaining credentials, which requires the confidential client application model rather than the public client application model.

Key Concept

Daemon applications using MSAL.NET and Microsoft Identity Platform must act as confidential client applications and authenticate using client credentials (either client secrets or client certificates). In Entra ID, the public key of the certificate is registered, while the private key is used in C# code with the ConfidentialClientApplicationBuilder to acquire a token.
Question 65Question

An organization is implementing a multi-tier solution where a mobile client calls a secure Web API. The Web API must call Microsoft Graph to access the user's files. The security policy dictates that the Web API must execute this request using the identity of the signed-in user, rather than using the API's own application identity. The Web API must authenticate to Microsoft Entra ID using a client certificate. You are writing the MSAL.NET code within the Web API to acquire the required token.

Which two code actions must you perform to implement this authentication flow? (Select two.)

Select all that apply

Show answer & explanation

Answer: Construct the application client using ConfidentialClientApplicationBuilder.Create(clientId).WithClientCertificate(certificate).Build(); Call the AcquireTokenOnBehalfOf(scopes, userAssertion) method on the application client, passing a UserAssertion object created from the incoming user token, and execute it.

Answer

Construct the application client using ConfidentialClientApplicationBuilder configured with the certificate, and then call AcquireTokenOnBehalfOf passing a UserAssertion object built from the incoming token.
The On-Behalf-Of (OBO) flow is designed for a Web API that needs to propagate the user's identity and permissions to a downstream API. To implement this using MSAL.NET, the Web API must act as a confidential client (configured via ConfidentialClientApplicationBuilder with its own certificate or secret) and request a token using AcquireTokenOnBehalfOf by supplying a UserAssertion derived from the incoming client JWT token.

Step-by-Step Solution

1
Determine the type of client application required.
The application must be configured as a confidential client since it runs on a secure Web API backend and must store a client certificate.
Web APIs are secure backends and must authenticate themselves to the Identity provider as confidential clients.
2
Initialize the confidential client application instance.
Use ConfidentialClientApplicationBuilder with the Client ID and the client certificate.
This establishes the client's identity for the subsequent token exchange process.
3
Extract the incoming JWT token from the client's request headers.
Construct a UserAssertion object using the raw JWT token.
The user assertion is needed to prove the identity of the signed-in user to Microsoft Entra ID.
4
Initiate the token acquisition flow for the downstream resource.
Call AcquireTokenOnBehalfOf(scopes, userAssertion) and execute the request.
This requests a new access token for the downstream API (Microsoft Graph) carrying the user's delegated permissions.

Key Concept

Microsoft Identity Platform On-Behalf-Of (OBO) authentication flow using MSAL.NET.
Estimated Time:3m 0s
Question 66Question

An organization registry application built in Microsoft Entra ID needs to support authentication for business users from external directories. The registration must allow log-in capabilities exclusively for corporate credentials across any Microsoft Entra ID tenant, preventing personal email accounts (such as Hotmail or Outlook.com) from authenticating. To implement this restriction, which setting should be selected for the application registration's sign-in audience in the manifest?

Show answer & explanation

Answer: AzureADMultipleOrgs

Answer

AzureADMultipleOrgs
The value AzureADMultipleOrgs is used in the Microsoft Entra ID application manifest to allow sign-ins from any organizational directory (work or school accounts) while preventing users with personal Microsoft accounts from signing in.

Step-by-Step Solution

1
Analyze the identity requirements for the registry application.
The application must support multi-tenant work/school accounts but exclude personal Microsoft accounts.
This determines the scope of the target identity providers.
2
Identify the corresponding Microsoft Entra ID application manifest property for audience configuration.
The target property is signInAudience.
This property controls which accounts are allowed to sign in to the application.
3
Select the correct value for the property.
AzureADMultipleOrgs is the value that enables multi-tenant work or school accounts while excluding personal accounts.
Choosing this specific value ensures compliance with the target security boundary.

Key Concept

Multi-tenant Applications Configuration
Question 67Question

You are developing a web application that retrieves reports from Azure Blob Storage. You need to generate a Service Shared Access Signature (SAS) token to allow an external partner to download a specific report file. To meet security guidelines, you must restrict access to a specific client IP address and enforce the use of HTTPS. Which two configurations must you define in the SAS token to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: An IP address filter restricting access to the partner's public IP address; An HTTPS-only protocol restriction

Answer

The correct options are the IP address filter restricting access to the partner's public IP address, and the HTTPS-only protocol restriction.
The correct configurations are the IP address filter and the HTTPS-only protocol restriction. An IP address filter limits the client source IP, and the protocol parameter ensures secure transit over HTTPS.

Step-by-Step Solution

1
Analyze the security requirements specified in the scenario.
The requirements are: download a specific report file (Read access), restrict access to a specific client IP address, and enforce HTTPS.
This establishes the constraints needed to select the correct configurations.
2
Determine the SAS configurations that implement IP filtering and protocol enforcement.
Defining the allowed IP address or range limits source access, and setting the protocol parameter to HTTPS only secures transit.
These parameters directly correspond to standard Azure Storage SAS token properties.
3
Evaluate the incorrect options against security best practices.
Granting full container-level write/delete permissions violates least-privilege, and embedding root credentials compromises account security.
This rules out the distractors.

Key Concept

Configuring security constraints on Azure Storage Shared Access Signatures (SAS) to enforce least privilege, specific IP access, and secure protocols.
Question 68Question

You are developing a multi-tenant web application that must allow users from any Microsoft Entra ID tenant to sign in using their work or school accounts. Personal Microsoft accounts (such as outlook.com or xbox.com) must be prevented from signing in. Which two configurations must you implement to meet these requirements? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Set the signInAudience property in the application manifest to AzureADMultipleOrgs.; Configure the authority URI in the application code to use the organizations endpoint.

Answer

Set the signInAudience property in the application manifest to AzureADMultipleOrgs, and configure the authority URI in the application code to use the organizations endpoint.
To support multi-tenant login restricted to work or school accounts, the application's registration manifest must have the signInAudience set to AzureADMultipleOrgs. In the application code, the authentication flow must target the organizations endpoint, which ensures that personal accounts are blocked during the authentication process.

Step-by-Step Solution

1
Configure the application registration audience constraint in Entra ID.
Setting the signInAudience property to AzureADMultipleOrgs allows any organization tenant to sign in, but excludes personal accounts.
The AzureADMultipleOrgs setting is explicitly designed for multi-tenant applications that restrict access to work or school accounts.
2
Update the authentication authority endpoint in the application code.
Setting the endpoint path to organizations redirects authenticating users to the organization-specific login flow.
The organizations endpoint filters out personal accounts, whereas the common endpoint allows both organizational and personal accounts to sign in.

Key Concept

Multi-tenant Applications Configuration in Microsoft Entra ID
Estimated Time:1m 0s
Question 69Question

You are developing an Azure App Service web app that needs to retrieve a database connection string stored as a secret in Azure Key Vault. You want to authenticate the web app using a system-assigned managed identity.

Which two actions should you perform to configure the required access? (Select two.)

Select all that apply

Show answer & explanation

Answer: Enable a system-assigned managed identity on the App Service web app.; Create an access policy in Azure Key Vault that grants the Get permission for secrets to the web app's managed identity.

Answer

Enable a system-assigned managed identity on the App Service web app, and create an access policy in Azure Key Vault that grants the Get permission for secrets to the web app's managed identity.
To retrieve a secret using a system-assigned managed identity, you must first enable the identity on the App Service web app to register it with Microsoft Entra ID. Then, you must configure authorization on the Azure Key Vault (such as an access policy) to grant the web app's identity the Get permission for secrets.

Step-by-Step Solution

1
Enable the identity on the web app.
The web app gets registered in Microsoft Entra ID with a system-assigned managed identity.
This establishes a security principal for the web app without needing credentials.
2
Configure Azure Key Vault access.
An access policy or Azure RBAC role assignment is created on the Key Vault.
This authorizes the web app's managed identity to perform the Get operation on secrets.

Key Concept

Configuring secure access to Key Vault secrets using managed identities
Question 70Question

You are developing a multi-tenant web application named App1 that will be registered in Microsoft Entra ID under Tenant A. Users from other Microsoft Entra ID tenants, such as Tenant B, must be able to sign in to App1 and grant the application permissions to read their profile data.

You need to understand how the identity objects are represented in the directory structure when a user from Tenant B consents to App1.

Which of the following describes the resource creation behavior in Tenant B?

Show answer & explanation

Answer: A service principal is created in Tenant B that references the application object in Tenant A.

Answer

A service principal is created in Tenant B that references the application object in Tenant A.
The correct answer is correct because in Microsoft Entra ID, the application registration generates a global application object in the home tenant. When the application is made multi-tenant and consented to by a user in another tenant, a local service principal (enterprise application) is created in that target tenant to represent the application and hold its local permissions.

Step-by-Step Solution

1
Understand the difference between application objects and service principals in Microsoft Entra ID.
The application object is the global definition of the application, while the service principal is the local instance or representation of that application within a specific tenant.
This conceptual distinction is fundamental to understanding how multi-tenant applications operate and are authorized across tenant boundaries.
2
Analyze the lifecycle of a multi-tenant application consent flow.
When a user in Tenant B consents to the application registered in Tenant A, Microsoft Entra ID creates a service principal in Tenant B pointing back to the application object in Tenant A.
This establishes the security principal in Tenant B to which permissions and roles can be assigned locally.

Key Concept

The relationship between application objects (global definition) and service principals (local instance) in multi-tenant environments.
Question 71Question

An engineer is designing a background daemon service that synchronizes directory metadata across several external corporate Microsoft Entra ID tenants using the Microsoft Graph API. The service must operate with application-only permissions (`User.Read.All`), prevent consumer accounts (such as Outlook.com) from registering, and allow external tenant administrators to grant consent and run the sync process without user interaction.

Which configuration combination must be used to meet these requirements?

Show answer & explanation

Answer: Manifest signInAudience: AzureADMultipleOrgs; Admin consent endpoint: https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent; Token acquisition endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token

Answer

The configuration using 'AzureADMultipleOrgs' for signInAudience, combined with the tenant-specific endpoints for admin consent (https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent) and token acquisition (https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token).
Configuring the application with 'AzureADMultipleOrgs' ensures that only work or school accounts from Microsoft Entra ID can access the application, satisfying the requirement to prevent personal Microsoft accounts. For daemon applications that run in the background using application-only permissions (such as the client credentials flow), token acquisition requires a tenant-specific endpoint (containing the client's tenant ID or verified domain) because the identity provider cannot resolve the tenant context without an active user session. Similarly, administrative consent must be granted within a specific tenant context, requiring a tenant-specific admin consent endpoint.

Step-by-Step Solution

1
Determine the required client directory audience.
The application must support multi-tenant organizations but exclude personal Microsoft accounts, pointing to the 'AzureADMultipleOrgs' audience configuration.
The 'AzureADMultipleOrgs' signInAudience targets corporate directories while preventing consumer Microsoft accounts from authenticating.
2
Identify the endpoint required for tenant-wide administrative consent.
The consent URL must be directed to a tenant-specific endpoint: https://login.microsoftonline.com/{tenant-id}/v2.0/adminconsent.
Administrative consent for application permissions requires a specific target tenant ID or domain context to apply the permissions to that directory.
3
Select the appropriate token endpoint for the background synchronization service.
The background service must request tokens using the client credentials grant flow directed to the tenant-specific endpoint: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token.
The client credentials flow is a non-interactive flow that lacks a user context, meaning the generic /common or /organizations endpoints cannot resolve the target directory and will fail.

Key Concept

Multi-tenant daemon application configuration and endpoint routing in Microsoft Entra ID.
Question 72Question

You are developing a secure Web App named InventoryManager that runs on Azure App Service. The application must perform two main tasks:
1. Allow signed-in users to view their own profile details and manage their calendar events in Microsoft 365.
2. Run a scheduled background job every night to retrieve a list of all office groups in the tenant to update local access lists. This background job runs without a signed-in user.

You need to configure the app registration in Microsoft Entra ID.

Which of the following configurations must you apply to meet these requirements while adhering to the principle of least privilege? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure the Microsoft Graph delegated permissions User.Read and Calendars.ReadWrite, and allow signed-in users to consent to these permissions.; Configure the Microsoft Graph application permission Group.Read.All, and have a tenant administrator grant tenant-wide consent.

Answer

Configure the Microsoft Graph delegated permissions User.Read and Calendars.ReadWrite for user-interactive operations, and configure the application permission Group.Read.All with tenant-wide administrator consent for the background daemon job.
For the user-centric features, the application runs on behalf of the signed-in user. This necessitates delegated permissions (User.Read and Calendars.ReadWrite) which are eligible for user consent. In contrast, the nightly background task operates independently of any user context, which requires a daemon flow (client credentials flow) and application-level permissions. Specifically, Group.Read.All is the correct application permission to read tenant groups, and because it is an application-level permission, it requires tenant-wide administrator consent.

Step-by-Step Solution

1
Analyze the client contexts for the two tasks.
Task 1 involves a signed-in user (delegated context), whereas Task 2 is a background daemon running without a user (application context).
This determines whether delegated or application permissions are required for each task.
2
Select the appropriate permissions under the principle of least privilege.
For the user context, delegated permissions User.Read and Calendates.ReadWrite are needed. For the background context, application permission Group.Read.All is needed.
Least privilege mandates using specific, narrow scopes rather than broad directory-wide administrative scopes like Directory.Read.All.
3
Determine the consent requirements for the selected permissions.
Delegated permissions can be consented to by individual users. Application permissions always require administrator consent.
Application permissions bypass user consent checks and expose tenant-wide data, requiring a tenant administrator to explicitly authorize them.
4
Determine the token request structure for the daemon service.
The client credentials flow must request the scope ending in /.default.
Unlike delegated flows that can request specific scopes dynamically, daemon flows require static permission registration and the use of the default scope suffix.

Key Concept

Differentiating delegated permissions and user consent from application permissions and admin consent in Microsoft Entra ID app registrations.
Question 73Question

You are deploying a web application to Azure App Service. The application must retrieve a database connection string stored in Azure Key Vault named keyvault1. You need to configure an application setting named ConnectionString using a Key Vault reference that points to a secret named dbsecret. Which of the following represents the correct format to use as the value of the application setting?

Show answer & explanation

Answer: @Microsoft.KeyVault(SecretUri=https://keyvault1.vault.azure.net/secrets/dbsecret/)

Answer

The correct format is '@Microsoft.KeyVault(SecretUri=https://keyvault1.vault.azure.net/secrets/dbsecret/)'
The correct syntax uses the prefix '@Microsoft.KeyVault' and the parameter 'SecretUri' to specify the full URI of the secret in Azure Key Vault.

Step-by-Step Solution

1
Identify the required prefix for Key Vault references in Azure App Service settings.
The prefix must be '@Microsoft.KeyVault'.
Azure App Service requires this specific prefix to detect and parse the value as a Key Vault reference.
2
Determine the correct parameter name when reference is defined by a secret URI.
The parameter name is 'SecretUri'.
The parser expects 'SecretUri' followed by the URL of the Key Vault secret.
3
Combine the prefix and parameter into the final reference string.
'@Microsoft.KeyVault(SecretUri=https://keyvault1.vault.azure.net/secrets/dbsecret/)'
This matches the official syntax format for referencing a secret by URI.

Key Concept

Key Vault Reference Syntax in Azure App Service
Estimated Time:45s
Question 74Question

You are developing a C# ASP.NET Core web application that will be hosted on an Azure App Service. The application must securely query data from an Azure SQL Database. You decide to use a user-assigned managed identity to authenticate the App Service to the database to ensure that database credentials are not hardcoded. Which sequence of steps should you perform to provision the identity, associate it with the App Service, and configure the database access permissions?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations is to first create the user-assigned managed identity, then associate it with the App Service, establish an administrative connection to the SQL Database, create a database user mapped to the external provider identity, and lastly assign the database user to the db_datareader role.
The correct sequence begins with provisioning the user-assigned managed identity so it exists in Microsoft Entra ID. Next, this identity is associated with the App Service resource. To configure permissions, an administrator must log into the target database, create a containment user representing the identity, and finally add that user to the db_datareader role.

Step-by-Step Solution

1
Create the user-assigned managed identity.
A managed identity is registered as a standalone resource in Microsoft Entra ID.
This establishes a security principal that can be associated with resources and granted permissions.
2
Associate the user-assigned managed identity with the App Service.
The App Service is configured to run under the context of the user-assigned managed identity.
The hosting environment requires the identity association to make the identity's credentials available to the application's runtime.
3
Connect to the database using a Microsoft Entra ID admin account.
An administrative database session is initialized.
Creating external database users requires administrator-level access to the database.
4
Run the CREATE USER statement with the EXTERNAL PROVIDER clause.
A containment database user is created inside the SQL database.
This maps the database security principal to the external Microsoft Entra ID identity resource.
5
Add the containment user to the db_datareader database role.
The mapped database user receives read access to the database.
Role membership establishes the actual permissions needed by the application.

Key Concept

Configuring user-assigned managed identities involves registering the identity in the directory, associating it with the computing host, and mapping it to a database principal prior to assigning permissions.
Question 75Question

You are developing a background utility service that runs on an on-premises Windows server. The service must periodically retrieve diagnostic data from a secure custom web API protected by Microsoft Entra ID. You register the utility as an application in your Microsoft Entra ID tenant. The service must authenticate programmatically without user interaction using a certificate. Which two configuration steps should you perform? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Upload the public key portion of the certificate to the application registration in Microsoft Entra ID.; Configure the application to request an access token using the OAuth 2.0 client credentials grant flow.

Answer

Upload the public key portion of the certificate to the application registration in Microsoft Entra ID, and configure the application to request an access token using the OAuth 2.0 client credentials grant flow.
For background services running on-premises, authentication is performed via the OAuth 2.0 client credentials flow. Since a certificate is required for authentication, the public key (.cer) must be uploaded to the Microsoft Entra ID application registration. The client service then signs its client assertion locally using the corresponding private key to request an access token.

Step-by-Step Solution

1
Determine the application type and authentication flow.
Since the service runs on-premises as a background process without user interaction, it cannot use managed identity or delegated permissions. It must authenticate using the client credentials flow with a certificate.
Managed identities require Azure hosting, and user-interactive flows are not suitable for background automation.
2
Configure the credentials on the Microsoft Entra ID application registration.
Upload the public key (.cer) of the certificate to the registered application.
Microsoft Entra ID needs the public key to verify the signature of the token request signed by the client's private key.
3
Implement the token request logic in the client application.
Acquire a token from Microsoft Entra ID using the OAuth 2.0 client credentials flow, passing the client assertion signed with the private key.
This retrieves the access token needed to authenticate calls to the custom web API.

Key Concept

Application registration authentication using certificates and client credentials flow
Question 76Question

You need to use the Azure CLI to create a new Azure Key Vault, store a database connection string as a secret, and then retrieve that secret. What is the correct sequence of Azure CLI commands to achieve this?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first create the resource group with `az group create`, then create the Key Vault with `az keyvault create`, next store the secret with `az keyvault secret set`, and finally retrieve the secret with `az keyvault secret show`.
To store and retrieve a secret using the Azure CLI, you must progress from global resource containers to the specific secret value. First, the resource group is created. Next, the Key Vault is provisioned within that resource group. Once the vault exists, the secret is written using the set command, and finally, the secret is retrieved using the show command.

Step-by-Step Solution

1
Create the resource group.
A resource group is provisioned in Azure.
Azure Key Vault requires a resource group to hold the resource.
2
Create the Key Vault.
The Key Vault instance is created inside the resource group.
Secrets must be stored within a specific Key Vault instance.
3
Set the secret.
The secret is successfully written to the Key Vault.
The connection string must be written to Key Vault storage before it can be referenced or read.
4
Show the secret.
The secret's value and metadata are returned.
Retrieving the secret requires querying the specific secret name inside the vault.

Key Concept

Azure Key Vault CLI Secret Management Lifecycle
Question 77Question

You are configuring permissions and consent in Microsoft Entra ID for an enterprise scheduling solution consisting of two applications:

1. SyncDaemon: A background service (daemon) that runs continuously without user interaction to synchronize user profile information from Microsoft Graph.
2. PlannerSPA: A client-side Single Page Application (SPA) that allows authenticated users to access a custom backend Web API named `TaskAPI` to manage their tasks. The backend API is registered with the App ID URI `api://taskapi.contoso.com`.

Which two of the following configuration actions must you perform to implement the correct permissions and consent flows? (Select two.)

Select all that apply

Show answer & explanation

Answer: For SyncDaemon, assign the Microsoft Graph Application permission User.Read.All and perform an admin consent flow.; For PlannerSPA, configure the application to request the scope api://taskapi.contoso.com/Tasks.Manage to obtain an access token for the backend API.

Answer

To configure the solution correctly, assign the Microsoft Graph Application permission User.Read.All with admin consent for SyncDaemon, and configure PlannerSPA to request the fully qualified scope api://taskapi.contoso.com/Tasks.Manage.
The correct actions are assigning the Application permission User.Read.All with admin consent for the background SyncDaemon service, and requesting the fully qualified custom scope api://taskapi.contoso.com/Tasks.Manage for the PlannerSPA. Background daemons run without user interaction and require Application permissions with tenant admin consent. Single-page applications calling a custom API require delegated access using the fully qualified App ID URI scope format.

Step-by-Step Solution

1
Determine the identity flow and permission type for SyncDaemon.
Since SyncDaemon is a background service running without user interaction, it must use the client credentials flow, which requires Application permissions (User.Read.All) rather than Delegated permissions.
Delegated permissions require an active user session, whereas Application permissions represent the application's identity.
2
Determine the consent requirement for SyncDaemon's permissions.
Microsoft Graph Application permissions require tenant-wide admin consent.
Admin consent prevents non-admin users from granting permissions that could access directory-wide data.
3
Determine the correct scope syntax for PlannerSPA calling TaskAPI.
The scope must be fully qualified as api://taskapi.contoso.com/Tasks.Manage.
Microsoft Entra ID requires custom API scopes to be requested using their full URI prefix so it can resolve the target resource registration.

Key Concept

Distinction between Delegated and Application permissions, and proper custom API scope syntax in Microsoft Entra ID.
Question 78Question

You are deploying an Azure App Service web app that must retrieve a database connection string from an Azure Key Vault using a user-assigned managed identity for compliance reasons. The Key Vault uses Azure Role-Based Access Control (RBAC) for authorization.

The user-assigned managed identity has been assigned the 'Key Vault Secrets User' role on the Key Vault. You use the following Bicep template snippet to deploy the web app:

bicep
resource webApp 'Microsoft.Web/sites@2022-03-01' = {
name: webAppName
location: location
identity: {
type: 'UserAssigned'
userAssignedIdentities: {
'${userAssignedIdentityId}': {}
}
}
properties: {
siteConfig: {
appSettings: [
{
name: 'ConnectionStrings__Default'
value: '@Microsoft.KeyVault(SecretUri=https://kv-prod-01.vault.azure.net/secrets/DbConn)'
}
]
}
}
}

During deployment validation, the application fails to start, and the logs indicate that the application setting `ConnectionStrings__Default` cannot resolve the Key Vault reference.

Which configuration change must you apply to the Bicep template to ensure the web app can resolve the connection string?

Show answer & explanation

Answer: Set the keyVaultReferenceIdentity property under properties to the value of userAssignedIdentityId.

Answer

Set the keyVaultReferenceIdentity property under properties to the value of userAssignedIdentityId.
The correct solution is to set the keyVaultReferenceIdentity property under properties to the value of the user-assigned managed identity's resource ID. By default, Azure App Service attempts to resolve Key Vault configuration references using the system-assigned managed identity. When using a user-assigned identity instead, the App Service must be explicitly told which identity to use by configuring the keyVaultReferenceIdentity property.

Step-by-Step Solution

1
Analyze the Bicep template configuration
Identify that the Web App is configured with a user-assigned managed identity, but lacks configuration pointing the Key Vault resolution mechanism to this identity.
When a Key Vault reference is evaluated at runtime, the App Service host must authenticate against the Key Vault. By default, it attempts to use a system-assigned identity.
2
Determine the default identity resolution behavior
Realize that without a system-assigned identity enabled or explicit configuration, the App Service cannot authenticate to resolve `@Microsoft.KeyVault(...)` syntax.
The template uses a user-assigned managed identity instead of a system-assigned identity, so the host needs explicit guidance on which identity context to execute under.
3
Identify the required Bicep property for identity selection
Locate the keyVaultReferenceIdentity property under the properties block of Microsoft.Web/sites.
This property configures the specific user-assigned identity resource ID that the App Service host should use to authenticate against the Key Vault for App Setting reference resolution.
4
Validate the Key Vault reference syntax and RBAC configuration
Ensure the @Microsoft.KeyVault(SecretUri=...) syntax is correct and Key Vault Secrets User role is active on the user-assigned identity.
The role and syntax are already correct in the initial template, confirming that the missing keyVaultReferenceIdentity property is the sole blocker.

Key Concept

App Service Key Vault References with User-Assigned Managed Identity

Alternative Method

Alternatively, you could switch to using a system-assigned managed identity, which automatically configures the App Service to use that identity for Key Vault references without needing the keyVaultReferenceIdentity property. However, this may conflict with organizations requiring user-assigned identities for strict lifecycle management.
Estimated Time:3m 0s
Question 79Question

You are authoring a Bicep template to deploy an Azure App Service web app that requires access to a shared Azure Key Vault. The web app must use a user-assigned managed identity named `app-identity` that is defined in the same template.

You declare the user-assigned managed identity resource as follows:

bicep
resource appIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
name: 'app-identity'
location: location
}

You need to define the `identity` property of the App Service web app resource to assign this managed identity.

Which Bicep block should you include in the App Service resource definition?

Show answer & explanation

Answer: identity: {
type: 'UserAssigned'
userAssignedIdentities: {
'${appIdentity.id}': {}
}
}

Answer

The correct Bicep block must set the identity type to 'UserAssigned' and define the userAssignedIdentities property as a dictionary with the managed identity's resource ID as the key and an empty object as the value.
The correct Bicep block sets the type to 'UserAssigned' and maps the resource ID of the identity as a key in the userAssignedIdentities object with an empty object value. In ARM/Bicep, the user-assigned identities are represented as a dictionary/object to allow assigning multiple identities, where each key is the unique resource ID of an identity.

Step-by-Step Solution

1
Analyze the resource definition requirements for assigning a user-assigned managed identity in Bicep/ARM.
The identity property requires setting the type property and specifying the identity resource(s).
This establishes the identity configuration schema used by the Azure Resource Manager.
2
Determine the correct value for the type property.
The type property must be set to 'UserAssigned'.
This tells Azure to associate one or more user-assigned managed identities rather than a system-assigned identity.
3
Specify the user-assigned identity using its resource ID.
Use the userAssignedIdentities property, structured as a dictionary (object) where the keys are the resource IDs (e.g., appIdentity.id) and the values are empty objects.
The ARM API expects a JSON object map to support multiple user-assigned identities, rather than a string array or a single property name.

Key Concept

Configuring user-assigned managed identities in Bicep/ARM templates
Estimated Time:1m 30s
Question 80Question

An Azure App Service web app uses a system-assigned managed identity to load configuration from an Azure App Configuration store. The App Configuration store contains a Key Vault reference that points to a secret stored in Azure Key Vault. While the web app successfully retrieves standard key-value settings, it fails to resolve the Key Vault reference at runtime. Which configuration change is required to allow the web app to resolve the Key Vault reference?

Show answer & explanation

Answer: Grant the system-assigned managed identity of the web app the Secret Get permission on the Key Vault.

Answer

Grant the system-assigned managed identity of the web app the Secret Get permission on the Key Vault.
The correct approach is to grant the system-assigned managed identity of the web app the Secret Get permission on the Key Vault. Key Vault references stored in Azure App Configuration are not resolved by the App Configuration service itself. Instead, the application's configuration provider fetches the reference metadata (the secret URI) from the App Configuration store, and then the application uses its own credentials to fetch the actual secret value directly from the Key Vault. Therefore, the web app's identity must have read access to the Key Vault.

Step-by-Step Solution

1
Identify how Key Vault references in Azure App Configuration are resolved.
References are resolved at runtime by the application client library, not by the Azure App Configuration service.
This determines which service identity requires access to the Key Vault.
2
Determine the identity used by the application to access Azure resources.
The application uses its own system-assigned managed identity.
This is the security principal that must be authorized on the Key Vault.
3
Configure the access control policy on the target Key Vault.
Grant the web app's system-assigned managed identity the 'Secret Get' permission (or the 'Key Vault Secrets User' role).
This enables the web app to directly retrieve the secret payload from the vault when resolving the reference.

Key Concept

Key Vault references in Azure App Configuration are resolved by the client application at runtime, requiring the application's identity to have access permissions on the target Key Vault.
PreviousPage 4 / 11Next
Implement Azure Security Practice Questions — Microsoft Azure Developer (AZ-204) — Page 4 | Examkin