Examkin

Implement Azure Security

203 questions

All types203Multiple choice102Multiple select71Ordering30
Question 41Question →

You are deploying a C# ASP.NET Core web application to an Azure App Service. The application must retrieve secrets from two distinct Azure Key Vaults:

1. `kv-finance`: Contains highly sensitive financial credentials and must only be accessible by this specific App Service instance. Access must be automatically revoked if the App Service is deleted.
2. `kv-shared`: Contains shared configuration data and is accessed by multiple App Service instances across the resource group.

You have created a user-assigned managed identity named `id-shared` for shared resource access. You need to configure the identities and implement the authentication code using the `Azure.Identity` SDK and `DefaultAzureCredential` class.

Which two configuration steps should you implement to satisfy the requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the identity property of the App Service in your ARM template with a type of SystemAssigned, UserAssigned and list the resource ID of id-shared under userAssignedIdentities.; For accessing kv-shared, instantiate the SecretClient using: new SecretClient(new Uri("https://kv-shared.vault.azure.net/"), new DefaultAzureCredential(new DefaultAzureCredentialOptions { ManagedIdentityClientId = "<user-assigned-client-id>" }));

Answer

Configure the App Service identity property in the ARM template using the type 'SystemAssigned, UserAssigned' while listing the resource ID of the user-assigned identity, and instantiate the client for the shared Key Vault by passing DefaultAzureCredentialOptions with the user-assigned identity's client ID.
To satisfy the requirements, the App Service needs to be provisioned with both system-assigned and user-assigned managed identities, which requires setting the ARM identity type to 'SystemAssigned, UserAssigned' and linking the user-assigned identity. In the application code, the default behavior of DefaultAzureCredential is to attempt authentication via the system-assigned managed identity first. To target the user-assigned identity for the shared Key Vault, the client ID of the user-assigned identity must be explicitly configured using DefaultAzureCredentialOptions.

Step-by-Step Solution

1
Determine the lifecycle requirements for both Key Vaults.
The finance Key Vault requires a system-assigned managed identity since its access must be revoked automatically upon resource deletion. The shared Key Vault requires a user-assigned managed identity to facilitate shared access across multiple instances.
This aligns identity selection with resource lifecycle boundaries.
2
Define the identity configuration in the ARM template.
Configure the App Service resource with identity type 'SystemAssigned, UserAssigned' and reference the user-assigned identity's resource ID in the userAssignedIdentities block.
This enables both system-assigned and user-assigned managed identities on the App Service instance.
3
Configure the .NET code for the database-specific Key Vault (kv-finance).
Instantiate the client using 'new DefaultAzureCredential()'.
By default, when no client ID is explicitly provided, DefaultAzureCredential attempts to use the system-assigned managed identity.
4
Configure the .NET code for the shared Key Vault (kv-shared).
Instantiate the client using 'new DefaultAzureCredential(new DefaultAzureCredentialOptions { ManagedIdentityClientId = "<client-id>" })'.
Specifying the client ID targets the user-assigned managed identity, ensuring it does not default to the system-assigned managed identity.

Key Concept

Configuring co-existing system-assigned and user-assigned managed identities and resolving client identities programmatically using DefaultAzureCredential.
Question 42Question →

You are developing an ASP.NET Core web application that will be hosted on two Azure App Service instances: web-app-primary and web-app-secondary. Both web apps must retrieve database connection strings from a shared Azure Key Vault named kv-shared. You decide to use a user-assigned managed identity named id-app-reader to access the Key Vault, ensuring that the identity's lifecycle is independent of the App Service instances. The application code uses the following C# code to authenticate:

csharp
var client = new SecretClient(new Uri("https://kv-shared.vault.azure.net/"), new DefaultAzureCredential());

To implement this security architecture, you assign id-app-reader to both App Service instances and configure the Key Vault access policy. Which of the following configuration steps must you also perform on each App Service instance to ensure that the application successfully authenticates?

Show answer & explanation

Answer: Add an Application Setting named AZURE_CLIENT_ID and set its value to the Client ID of the id-app-reader identity.

Answer

Add an Application Setting named AZURE_CLIENT_ID and set its value to the Client ID of the id-app-reader identity.
The correct action is to add an Application Setting named AZURE_CLIENT_ID and set its value to the Client ID of the id-app-reader identity. When an application uses DefaultAzureCredential and needs to authenticate with a user-assigned managed identity, it reads the AZURE_CLIENT_ID environment variable (which is populated via Application Settings in Azure App Service) to determine which identity to use. The Azure.Identity library expects the Client ID (App ID) of the identity.

Step-by-Step Solution

1
Assign the user-assigned managed identity to both Azure App Service instances.
The identity is linked to the App Service host environment, making it available for token requests.
This establishes the identity configuration at the Azure resource level.
2
Configure the Azure Key Vault access policies or Azure RBAC role assignments for the user-assigned managed identity.
The identity has the necessary permissions (e.g., Get/List Secrets) on the Key Vault.
This authorizes the identity to perform actions on the target resource.
3
Define the AZURE_CLIENT_ID Application Setting on each App Service instance pointing to the Client ID of the user-assigned managed identity.
DefaultAzureCredential reads this setting and uses it to specify the correct client ID during token acquisition.
When multiple identities are present or a user-assigned identity is used, DefaultAzureCredential requires the Client ID to differentiate and request tokens for the target identity.

Key Concept

Configuring DefaultAzureCredential for User-Assigned Managed Identities in Azure App Service
Question 43Question →

You are deploying a set of Azure Virtual Machines (VMs) that need to read configuration files from a shared Azure Storage account. To simplify access control, you want to create a managed identity as a standalone Azure resource that is shared across all the VMs and persists even if all the VMs are deleted. Which value should you specify for the type property in the identity section of the VM's Azure Resource Manager (ARM) template?

Show answer & explanation

Answer: UserAssigned

Answer

The correct property value is UserAssigned.
Setting the identity type to UserAssigned is correct because a user-assigned managed identity is created as a standalone Azure resource. This design allows it to be shared across multiple virtual machines in a scale set and ensures that the identity persists even if individual virtual machines are deleted or scaled down.

Step-by-Step Solution

1
Analyze the requirements to identify if the managed identity needs to be shared across multiple resources and if its lifecycle should be independent of them.
The identity must be shared across multiple virtual machines and persist independently of their lifecycle, indicating that a user-assigned managed identity is required.
System-assigned identities are tied to a single resource's lifecycle and cannot be shared.
2
Identify the corresponding identity type value used in the Azure Resource Manager (ARM) template.
The type value for a user-assigned managed identity is UserAssigned.
This property configures the virtual machine resource to use the specified user-assigned identity resource.

Key Concept

Choosing between system-assigned and user-assigned managed identities based on lifecycle and sharing requirements.
Question 44Question →

You are developing a secure daemon service that runs on an on-premises Linux server. The service must authenticate with Microsoft Entra ID to retrieve secrets from an Azure Key Vault. Security policies prohibit the use of client secrets (passwords) for daemon services, requiring certificate-based authentication instead. You generate a self-signed certificate on the Linux server and register the application in Microsoft Entra ID under the name OnPremDaemon. Which configuration step must you perform in Microsoft Entra ID to enable the service to authenticate using this certificate?

Show answer & explanation

Answer: Upload the public key (.cer or .pem) of the certificate to the Certificates & secrets section of the OnPremDaemon app registration, which populates the keyCredentials property in the application object.

Answer

Upload the public key (.cer or .pem) of the certificate to the Certificates & secrets section of the OnPremDaemon app registration, which populates the keyCredentials property in the application object.
To configure certificate-based authentication, the public key (.cer or .pem) of the certificate must be uploaded to the app registration. This action populates the keyCredentials array in the application object. When the daemon application authenticates, it signs a client assertion (JWT) using its private key and sends it to the token endpoint. Microsoft Entra ID uses the registered public key to verify the signature of the assertion.

Step-by-Step Solution

1
Extract the public key from the generated certificate on the Linux server.
A public key file in .cer or .pem format is obtained.
Only the public key is needed by Microsoft Entra ID to verify signatures, while the private key remains secure on the host.
2
Navigate to the Microsoft Entra ID portal, open the App registrations blade, and select the OnPremDaemon application.
The application registration details page is displayed.
Credentials must be configured on the application registration representing the daemon service.
3
Go to the Certificates & secrets section, click on Upload certificate, and select the public key file.
The certificate is successfully uploaded and its thumbprint, start date, and expiration date are visible.
This action registers the certificate under the keyCredentials array of the application object, enabling Microsoft Entra ID to validate token requests signed with the corresponding private key.

Key Concept

App Registrations and Service Principals credentials configuration using certificates
Question 45Question →

You are deploying a web application to Azure App Service using an Azure Resource Manager (ARM) template. The application must retrieve database connection strings from Azure Key Vault. Security requirements specify that the managed identity used by the application must be decoupled from the App Service's lifecycle so it can be shared with an Azure Function in the future, and it must not be deleted if the App Service is removed. Which two of the following configuration steps must you perform to implement this security architecture? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Set the identity property type to UserAssigned in the App Service ARM template, and define the identity under the userAssignedIdentities dictionary.; Run the az role assignment create Azure CLI command to assign the 'Key Vault Secrets User' role to the principal ID of the user-assigned identity at the Key Vault scope.

Answer

To implement this architecture, you must set the identity type to UserAssigned in the App Service resource definition and use Azure CLI to assign the Key Vault Secrets User role to the identity's principal ID.
Configuring a user-assigned managed identity allows the security context to exist independently of the App Service resource, which is required for sharing with the Azure Function and surviving deletion of the App Service. Assigning the Key Vault Secrets User role to the identity's principal ID grants the required permissions without managing secrets.

Step-by-Step Solution

1
Define the managed identity type in the ARM template.
Set the type property to UserAssigned and configure the identity under the userAssignedIdentities dictionary.
This decouples the identity's lifecycle from the App Service, ensuring it is not deleted when the App Service is removed and allowing it to be shared with other resources.
2
Assign RBAC permissions to the identity.
Execute az role assignment create to grant the 'Key Vault Secrets User' role to the identity's principal ID at the Key Vault scope.
This authorizes the identity to retrieve secrets from the Key Vault, fulfilling the application's requirement to access database connection strings.

Key Concept

Selecting and configuring the correct type of managed identity based on resource sharing and lifecycle requirements.
Estimated Time:1m 30s
Question 46Question →

You are developing a local console application that runs on an on-premises developer workstation. The application must periodically upload application diagnostic logs to a specific container in an Azure Storage account. You plan to configure the application to authenticate using a Microsoft Entra ID service principal with a client secret, adhering to the principle of least privilege.

Which sequence of steps should you perform to configure the identity, permissions, and application code?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First register the application in Microsoft Entra ID, then generate a new client secret under Certificates & secrets, next assign the Storage Blob Data Contributor role to the service principal at the scope of the storage container, and finally configure the application code to use the ClientSecretCredential.
The correct sequence begins with registering the application in Microsoft Entra ID to create the security principal. Next, a client secret is generated to authenticate this registration. Then, the service principal is granted the Storage Blob Data Contributor role at the container scope to ensure proper authorization. Finally, the developer instantiates a ClientSecretCredential in code to perform authentication.

Step-by-Step Solution

1
Register the application in Microsoft Entra ID.
Creates the application object and its corresponding service principal in the tenant.
You must establish the identity in the directory before you can add credentials or grant permissions to it.
2
Generate a client secret in the Microsoft Entra portal.
Creates a secure secret key associated with the application registration.
The secret key is required for the application to authenticate itself as the service principal.
3
Assign the Storage Blob Data Contributor role to the service principal at the container scope.
Grants the application permission to write blobs in the specific container.
Roles must be assigned to the service principal (not the application object) at the narrowest possible scope to respect the principle of least privilege.
4
Instantiate ClientSecretCredential in code.
Requests an access token from Microsoft Entra ID to authenticate requests to the storage container.
The application code needs the application ID, tenant ID, and client secret to perform token acquisition and execute authorized operations.

Key Concept

App Registrations, Service Principals, and Client Secrets configuration flow
Estimated Time:1m 30s
Question 47Question →

A developer is configuring a Microsoft Entra ID app registration for a web application named SalesReporter. The web application allows users to sign in and needs to access Microsoft Graph to read the signed-in user's profile and send emails on their behalf. Which two Microsoft Graph delegated permissions must be configured? Select two options.

Select all that apply

Show answer & explanation

Answer: User.Read; Mail.Send

Answer

The application requires User.Read and Mail.Send delegated permissions.
The correct options are User.Read and Mail.Send delegated permissions because the web application acts on behalf of the signed-in user (requiring delegated permissions) to read their profile and send emails.

Step-by-Step Solution

1
Identify that the application acts on behalf of a signed-in user, which requires Delegated permissions rather than Application permissions or Shared Access Signatures.
Confirm that Delegated permissions must be selected.
Delegated permissions allow the application to act on behalf of the signed-in user.
2
Determine that to read the user's basic profile, the User.Read delegated permission is required.
Select User.Read delegated permission.
This permission allows basic profile reading upon login.
3
Determine that to send emails as the signed-in user, the Mail.Send delegated permission is required.
Select Mail.Send delegated permission.
This permission allows sending email on behalf of the signed-in user.

Key Concept

Microsoft Entra ID delegated permissions allow an application to access APIs on behalf of a signed-in user.
Question 48Question →

An organization is deploying a C# .NET 8 application to an Azure App Service. The application must perform the following tasks:

1. Retrieve configuration secrets from an Azure Key Vault. The Key Vault is shared across several independent applications, and the credentials used to access it must persist even if this App Service instance is deleted.
2. Read messages from an Azure Service Bus queue. The credentials used for the queue must be exclusively tied to this App Service instance's lifecycle and automatically cleaned up if the App Service is deleted.

The application uses the `Azure.Identity` library and `DefaultAzureCredential` to connect to Azure resources.

Which two actions should you perform to implement this configuration?

Select all that apply

Show answer & explanation

Answer: Enable a system-assigned managed identity on the App Service, assign it the Azure Service Bus Data Receiver role on the Service Bus queue, and instantiate the Service Bus client using a default DefaultAzureCredential instance.; Create a user-assigned managed identity, assign it the Key Vault Secrets User role on the Key Vault, associate it with the App Service, and instantiate the Key Vault client using a DefaultAzureCredential instance initialized with DefaultAzureCredentialOptions containing the identity's client ID.

Answer

To implement this configuration, you should enable a system-assigned managed identity on the App Service for the Service Bus queue, assigning it the Azure Service Bus Data Receiver role and instantiating the Service Bus client using a default DefaultAzureCredential instance. Additionally, you should create a user-assigned managed identity for the Key Vault, assigning it the Key Vault Secrets User role, associating it with the App Service, and instantiating the Key Vault client by passing DefaultAzureCredentialOptions containing the identity's client ID to DefaultAzureCredential.
The correct solution uses a system-assigned managed identity for the Service Bus queue because the identity's lifecycle must be linked to the App Service's lifecycle. It uses a user-assigned managed identity for the Key Vault because the credentials must persist independently of the App Service. When both managed identities are enabled on the App Service, DefaultAzureCredential will default to the system-assigned identity unless explicitly configured. Thus, the Service Bus client can use the default credential parameterless constructor, while the Key Vault client must specify the user-assigned identity's client ID via DefaultAzureCredentialOptions.

Step-by-Step Solution

1
Analyze the identity lifecycle requirements for the shared Key Vault and the exclusive Service Bus queue.
Determine that the Key Vault requires a user-assigned managed identity because the credentials must persist independently of the App Service. Determine that the Service Bus queue requires a system-assigned managed identity because the credentials must be tied to the App Service's lifecycle.
System-assigned identities are tied to the host resource's lifecycle, whereas user-assigned identities exist as independent Azure resources.
2
Determine the appropriate RBAC roles for each resource.
Grant the Key Vault Secrets User role to the user-assigned managed identity on the Key Vault. Grant the Azure Service Bus Data Receiver role to the system-assigned managed identity on the Service Bus queue.
This grants the minimum required permissions to perform the operations securely.
3
Configure the Azure.Identity SDK in code to support both identities.
Instantiate the Service Bus client with a parameterless DefaultAzureCredential. Instantiate the Key Vault client with a DefaultAzureCredential configured with DefaultAzureCredentialOptions containing the user-assigned identity's client ID.
When both system-assigned and user-assigned identities are present, DefaultAzureCredential defaults to using the system-assigned identity. To use the user-assigned identity, its client ID must be explicitly provided in the options.

Key Concept

Selecting and configuring system-assigned and user-assigned managed identities based on resource lifecycle, sharing requirements, and multi-identity SDK configuration.
Question 49Question →

An organization is developing a secure reporting system consisting of three components:

1. WebPortal: An Angular Single Page Application (SPA) that allows employees to view their personalized dashboard.
2. ReportAPI: A secured ASP.NET Core Web API (https://api.contoso.com) that retrieves data from a backend database.
3. DataSync: A background daemon service that runs on an on-premises server to upload bulk logs to ReportAPI nightly.

You have the following requirements:
- WebPortal must acquire an access token to call ReportAPI. When a user logs in, ReportAPI must read the user's manager's details from Microsoft Graph on behalf of the signed-in user using the on-behalf-of (OBO) flow.
- DataSync must authenticate using client credentials (client secrets) to POST logs directly to ReportAPI.
- The configuration must follow the principle of least privilege.
- Standard user logins must not be blocked by consent prompts during authentication.

Which configuration correctly implements the permissions, scopes, and token acquisition requests to meet these requirements?

Show answer & explanation

Answer: Register ReportAPI, WebPortal, and DataSync in Microsoft Entra ID. In ReportAPI, expose the delegated scope Reports.Read and define an application role (application permission) named Logs.Write. Grant ReportAPI the Microsoft Graph delegated permission User.Read.All and perform tenant-wide admin consent. Configure WebPortal to request the scope api://<ReportAPI_Client_ID>/Reports.Read, and configure DataSync to request a token using the client credentials flow with the scope set to api://<ReportAPI_Client_ID>/.default.

Answer

The correct configuration is to expose Reports.Read as a delegated scope and define Logs.Write as an application role in the ReportAPI registration. WebPortal requests the specific scope api://<ReportAPI_Client_ID>/Reports.Read for user-interactive sessions, while DataSync requests api://<ReportAPI_Client_ID>/.default in a client credentials flow to get its pre-consented application role. Tenant-wide admin consent must be granted to the ReportAPI for the Microsoft Graph User.Read.All delegated permission to enable OBO flows without standard user interruption.
The correct configuration uses a delegated scope (Reports.Read) for the user-interactive Single Page Application (SPA) and defines an application role/permission (Logs.Write) for the background daemon (DataSync) which runs without user interaction. The background daemon authenticates using the client credentials flow, which requires setting the scope parameter to the API's Application ID URI followed by '/.default' rather than requesting individual scopes. Additionally, because the Web API uses the on-behalf-of (OBO) flow to call Microsoft Graph for 'User.Read.All' (which requires admin consent), performing tenant-wide admin consent prevents standard users from being blocked during login.

Step-by-Step Solution

1
Differentiate between delegated and application permissions based on the client application context.
WebPortal (SPA) requires delegated permissions (user context), while DataSync (daemon service) requires application permissions (app roles/service context).
Delegated permissions are used when an app acts on behalf of a signed-in user, whereas application permissions are used when an app runs in the background without a user.
2
Determine the correct scope syntax and acquisition flow for both clients.
WebPortal requests api://<ReportAPI_ClientID>/Reports.Read using authorization code flow. DataSync requests api://<ReportAPI_ClientID>/.default using client credentials flow.
Microsoft Entra ID client credentials flow does not allow requesting individual scopes; it requires the target API's ID URI with the /.default suffix to retrieve all assigned application permissions.
3
Identify the Microsoft Graph consent requirements for the backend on-behalf-of (OBO) call.
Grant ReportAPI the delegated User.Read.All permission and perform tenant-wide admin consent.
Reading a user's manager profile via User.Read.All is a high-privilege Graph permission requiring admin consent. Granting tenant-wide admin consent prevents standard users from encountering consent blocks during login.

Key Concept

Microsoft Entra ID Delegated vs. Application Permissions and Client Credentials Scope Configuration
Question 50Question →

You are developing a C# ASP.NET Core web application deployed to Azure App Service. The application is deployed as two regional instances: app-us-east and app-us-west. Both instances must retrieve shared secrets from a central Azure Key Vault named kv-shared. Additionally, app-us-east must write data to a regional Azure Storage account named sa-east-logs, while app-us-west must write data to sa-west-logs. To configure the managed identities, you perform the following steps:

1. Create a single user-assigned managed identity named uami-shared and assign it to both App Services, granting it Get and List secrets permissions on kv-shared.
2. Enable a system-assigned managed identity on both app-us-east and app-us-west, and grant each regional identity Contributor access to its corresponding regional storage account (sa-east-logs or sa-west-logs).

In your C# code, you instantiate the SDK clients as follows:

csharp
// Accessing the shared Key Vault
var kvClient = new SecretClient(
new Uri("https://kv-shared.vault.azure.net/"),
new DefaultAzureCredential()
);

// Accessing the regional storage account
var blobClient = new BlobServiceClient(
new Uri("https://sa-east-logs.blob.core.windows.net/"),
new DefaultAzureCredential()
);

What is the authentication outcome when the app-us-east instance attempts to run this code and connect to both services?

Show answer & explanation

Answer: The application successfully connects to the regional storage account, but fails to authenticate to the shared Key Vault because DefaultAzureCredential defaults to the system-assigned managed identity when both identity types are enabled, causing token requests without a specified client ID to use the system-assigned identity.

Answer

The application successfully connects to the regional storage account, but fails to authenticate to the shared Key Vault because DefaultAzureCredential defaults to the system-assigned managed identity when both identity types are enabled, causing token requests without a specified client ID to use the system-assigned identity.
The correct option is correct because when an Azure App Service has both a system-assigned managed identity and a user-assigned managed identity, the metadata service defaults to issuing tokens for the system-assigned managed identity. Because DefaultAzureCredential is initialized without parameters, it requests a default token, which will represent the system-assigned identity. Consequently, the call to the regional storage account succeeds (authorized for the system-assigned identity), while the call to the shared Key Vault fails (authorized only for the user-assigned identity). To fix this, DefaultAzureCredential must be configured with DefaultAzureCredentialOptions specifying the ManagedIdentityClientId for the user-assigned identity.

Step-by-Step Solution

1
Determine the identities assigned to the App Service host.
The host app-us-east has both a system-assigned managed identity (with permissions to sa-east-logs) and a user-assigned managed identity (uami-shared with permissions to kv-shared).
This establishes the authorization scope for each identity type on the resource.
2
Analyze how DefaultAzureCredential resolves tokens when multiple managed identities are present.
Without specifying a client ID, DefaultAzureCredential calls the IMDS token endpoint without parameters, which causes Azure to default to using the system-assigned managed identity.
This identifies which security principal's token is returned during execution.
3
Evaluate the authentication outcome for each service request.
The token for the system-assigned identity successfully accesses sa-east-logs (due to Contributor RBAC) but fails to access kv-shared (as only uami-shared has permissions there).
This determines the final success/failure behavior of the C# code.

Key Concept

Understanding the default resolution behavior of DefaultAzureCredential and the Azure Instance Metadata Service (IMDS) when both system-assigned and user-assigned managed identities are assigned to a single resource.
Question 51Question →

You are developing a web application hosted on an Azure App Service. The application must retrieve database connection strings securely from an Azure Key Vault using a system-assigned managed identity.

Which three actions should you perform in sequence to configure this security access? To answer, drag the appropriate 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

First, enable the system-assigned managed identity on the Azure App Service instance. Next, assign the Key Vault Secrets User role to the App Service's managed identity at the Key Vault scope. Finally, configure the web application code to authenticate using the DefaultAzureCredential class and retrieve the secret.
To grant an App Service access to Key Vault via managed identity: 1) Enable the system-assigned identity on the App Service, creating the principal. 2) Grant that principal permissions via Key Vault Secrets User role assignment. 3) Configure application code using DefaultAzureCredential to automatically pick up the identity environment and authorize calls.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the Azure App Service.
Azure creates a service principal in Microsoft Entra ID linked directly to the lifecycle of the App Service.
Before permissions can be granted or authentication can happen, the managed identity must be enabled to generate its identity principal.
2
Assign the Key Vault Secrets User role to the managed identity.
The identity is authorized to read secrets from the Key Vault.
Having an identity is not enough; the resource owner must grant it the necessary Role-Based Access Control (RBAC) permissions to access the secrets.
3
Update application code to use DefaultAzureCredential.
The application successfully retrieves secrets at runtime without hardcoded credentials.
DefaultAzureCredential automatically detects the system-assigned managed identity in the App Service environment and uses it to request tokens.

Key Concept

Configuring a system-assigned managed identity to access Azure Key Vault securely.
Question 52Question →

You are developing a Single Page Application (SPA) using React that allows employees to view their own profile information from Microsoft Graph after signing in. Which permission type must you configure in the Microsoft Entra ID application registration to ensure that the application accesses the API on behalf of the signed-in user?

Show answer & explanation

Answer: Delegated permissions

Answer

Delegated permissions
Delegated permissions allow the application to act on behalf of the signed-in user. The application can only access resources that the user itself has access to, which is appropriate for a React SPA where users log in to see their own profile information.

Step-by-Step Solution

1
Identify the client application type and runtime context.
The application is a React Single Page Application (SPA) where users sign in directly.
Understanding whether a user is present during execution is critical for choosing the right permission model.
2
Determine the required access scope for the Microsoft Graph API request.
The application needs to access the signed-in user's own profile information (on-behalf-of access).
Accessing resources on behalf of the active user requires user consent and delegation.
3
Select the correct Entra ID permission category based on the user context.
Delegated permissions are selected because they allow the application to run in the context of the signed-in user.
Application permissions are reserved for background services without user interaction, while SAS and Key Vault policies do not apply to Microsoft Graph permissions.

Key Concept

Delegated permissions allow applications to act on behalf of a signed-in user, whereas application permissions allow apps to run independently as background services.
Question 53Question →

You are developing a multi-tenant daemon application that will run on-premises and read calendar data from multiple customer organizations using Microsoft Graph. The application does not have a user interface and must run without user interaction.

You need to register the application, establish consent in a customer's tenant, and acquire an access token to access their data.

In which order should you perform the steps? To answer, move all 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

First, register the multi-tenant application and configure its application permissions and client secret in the home tenant. Second, construct the administrator consent URL using the application's client ID. Third, have the customer's administrator access the URL to grant consent. Fourth, verify the service principal is created in the customer's tenant. Lastly, request an access token from the customer's token endpoint using the client credentials.
The correct order proceeds from registering the application in the provider's home tenant to generate the client ID, constructing the admin consent URL, obtaining tenant-wide consent from the customer's administrator, verifying the local service principal's creation, and finally requesting the access token from the customer's specific endpoint.

Step-by-Step Solution

1
Register the application in the home tenant and configure its metadata, supported account types (multi-tenant), and credentials.
The application registration is created, yielding a client ID and a client secret.
You must establish the identity definition and authentication credentials before any tenant-level operations or token requests can occur.
2
Construct the admin consent request URL targeting the Microsoft Entra ID endpoint, appending the client ID and redirect URI.
A valid consent URL is prepared for the customer's tenant administrator.
Since daemon apps use client credentials flow (Application permissions), there is no interactive sign-in flow to trigger dynamic consent; therefore, the administrator consent endpoint must be explicitly called.
3
Have the customer's Global Administrator navigate to the consent URL and sign in to approve the permissions.
Consent is granted to the application for the customer's tenant.
Only a tenant administrator can grant consent for Application-level permissions (such as reading calendar data across all mailboxes).
4
Confirm the instantiation of the service principal in the customer's tenant.
A service principal (Enterprise Application object) is created in the customer's tenant.
The service principal acts as the local identity representation of the application in the target tenant and holds the delegated or consented permissions.
5
Perform a client credentials token request using the client secret to the customer's specific token endpoint.
An OAuth 2.0 access token is returned by Microsoft Entra ID for the target customer tenant.
With consent established and the service principal present, the daemon can securely request a token specifically scoped to the customer's resources.

Key Concept

Multi-tenant application registration, administrative consent flow, and service principal instantiation for daemon applications using Microsoft Entra ID.
Estimated Time:2m 30s
Question 54Question →

You are developing a background daemon application that runs on an on-premises Windows server. The application must run unattended to process files and upload them to an Azure Blob Storage container. You need to configure authentication and authorization for the application, ensuring that it uses Microsoft Entra ID and adheres to the principle of least privilege.

Which of the following authentication and authorization configurations should you implement?

Show answer & explanation

Answer: Register the application in Microsoft Entra ID to create an application object and a corresponding service principal, configure a certificate credential for authentication, and assign the Storage Blob Data Contributor role to the service principal.

Answer

Register the application in Microsoft Entra ID to create an application object and a corresponding service principal, configure a certificate credential for authentication, and assign the Storage Blob Data Contributor role to the service principal.
Registering the application in Microsoft Entra ID creates both an application object (defining the app globally) and a service principal (the local representation used for authentication and authorization in the tenant). Because the daemon application runs on-premises, it cannot natively use a managed identity. Authenticating using a certificate credential (rather than a client secret) provides a more secure approach for unattended daemon services. Granting the Storage Blob Data Contributor role to the service principal via Azure Role-Based Access Control (RBAC) ensures the application has only the permissions required to upload files to Blob Storage.

Step-by-Step Solution

1
Register the application in the Microsoft Entra ID tenant.
Creates an application object (representing the app registration) and an associated service principal in the home tenant.
On-premises daemon applications must be registered in Microsoft Entra ID to obtain identity credentials.
2
Upload a public certificate to the app registration to configure a certificate credential.
Establishes a highly secure credential type for the application.
Daemon applications run unattended and require non-interactive credentials. Certificate credentials are preferred over client secrets for production environments.
3
Assign the Storage Blob Data Contributor role to the service principal at the scope of the storage account or container.
Grants the service principal the necessary write permissions to upload files.
Azure Role-Based Access Control (RBAC) maps the required permissions to the service principal identity to authorize storage operations.

Key Concept

App Registrations and Service Principals for On-Premises Daemon Applications
Question 55Question →

You are developing a multi-tenant SaaS application that will be distributed to various corporate clients. The application requires access to the Microsoft Graph API.

You have the following requirements:
1. Users from any Microsoft Entra ID tenant must be able to sign in to the application.
2. Personal Microsoft accounts (such as Skype, Outlook.com, or Xbox Live) must be prevented from signing in.
3. A tenant administrator must be able to grant consent to the application's required permissions for all users in their tenant.

You need to configure the application registration and endpoints.

Which two actions should you perform? (Each correct answer presents part of the solution.)

Select all that apply

Show answer & explanation

Answer: In the application manifest, set the `signInAudience` property to `AzureADMultipleOrgs`.; Configure the application's user sign-in endpoint to target `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize`.

Answer

To configure the multi-tenant application to allow only organizational directories and block personal accounts, set the `signInAudience` property to `AzureADMultipleOrgs` in the application manifest and configure the user sign-in endpoint to target the `/organizations` authorize endpoint.
Configuring the application manifest with a `signInAudience` of `AzureADMultipleOrgs` specifies that the app supports accounts in any organizational directory. Pairing this with the `/organizations` authorize endpoint ensures that only work or school accounts are accepted during authentication, effectively blocking personal Microsoft accounts. Together, these steps satisfy the multi-tenant requirements while enforcing the exclusion of personal accounts.

Step-by-Step Solution

1
Select the correct `signInAudience` in the application manifest.
Setting `signInAudience` to `AzureADMultipleOrgs` enables multi-tenant support for organizational directories only.
This excludes personal Microsoft accounts at the application registration level.
2
Determine the appropriate sign-in endpoint for user authentication.
Using `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize` restricts incoming authentication requests to organizational tenants.
The `/common` endpoint would allow personal Microsoft accounts to authenticate, violating the requirement to exclude them.
3
Understand the requirements of the admin consent endpoint.
Constructing the admin consent URL requires a specific tenant ID or domain name instead of a generic placeholder like `/organizations`.
Microsoft Entra ID requires an explicit target directory to record the tenant-wide admin consent.

Key Concept

Microsoft Entra ID multi-tenant application endpoint configuration and manifest properties
Question 56Question →

You are configuring a multi-tenant web application in Microsoft Entra ID. The application must allow users with work or school accounts from any organization's tenant to log in, but must exclude personal Microsoft accounts. Which two configurations are required 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 to use the /organizations endpoint

Answer

Set the signInAudience property in the application manifest to AzureADMultipleOrgs and configure the authority URI to use the /organizations endpoint.
To configure a multi-tenant application that supports work and school accounts from any organization but excludes personal accounts, you must set the signInAudience to AzureADMultipleOrgs and use the /organizations endpoint. The /organizations endpoint is specifically designed for work or school accounts from any Microsoft Entra ID tenant, whereas the /common endpoint would also include personal Microsoft accounts.

Step-by-Step Solution

1
Configure the application manifest to allow multi-tenant access.
The signInAudience property is set to AzureADMultipleOrgs.
This allows accounts in any organizational directory to sign in to the application.
2
Configure the authority endpoint URI in the application's authentication configuration.
The authority URI uses the /organizations endpoint.
This filters the sign-ins to only organizational accounts and excludes personal Microsoft accounts.

Key Concept

Configuring multi-tenant Microsoft Entra ID applications requires setting the appropriate signInAudience parameter in the application manifest and using the correct authority endpoint to filter user accounts.
Question 57Question →

A company is developing a C# daemon application that runs on an on-premises server. The application must connect to Microsoft Graph to read directory data without any user intervention.

Which two configuration steps must you perform to enable authentication for this daemon application? Select two.

Select all that apply

Show answer & explanation

Answer: Register the application as a confidential client in Microsoft Entra ID and configure a client secret or certificate.; Initialize the application using the ConfidentialClientApplicationBuilder class in the Microsoft Authentication Library (MSAL.NET).

Answer

To enable authentication for the daemon application, you must register the application as a confidential client in Microsoft Entra ID and configure a client secret or certificate, and initialize the application using the ConfidentialClientApplicationBuilder class in MSAL.NET.
The application runs unattended as a daemon service. In Microsoft Entra ID, this requires a confidential client registration with a client secret or certificate. In MSAL.NET, the developer must use the ConfidentialClientApplicationBuilder class to initialize the client and acquire tokens using the client credentials flow.

Step-by-Step Solution

1
Determine the application type based on user interaction requirements.
The application runs on a server without user intervention, meaning it must be treated as a daemon service (confidential client).
Daemon applications require application-level permissions and use confidential client flows because they can securely keep a client credential.
2
Configure the registration in Microsoft Entra ID.
Register the application and generate a client secret or upload a certificate under Certificates & secrets.
Confidential client flows require a secret or certificate credential to verify the application's identity.
3
Select the correct builder in MSAL.NET.
Use ConfidentialClientApplicationBuilder.Create(clientId) to build the client instance.
The ConfidentialClientApplicationBuilder class is specifically designed to support confidential client flows such as Client Credentials.

Key Concept

Daemon applications run without user interaction and must be configured as confidential clients using MSAL.NET ConfidentialClientApplicationBuilder and registered in Microsoft Entra ID with appropriate credentials (client secrets or certificates).
Question 58Question →

You are developing an ASP.NET Core web application that will be hosted on an Azure App Service. The application must securely read blobs from an Azure Storage container. You decide to use a user-assigned managed identity to handle authentication.

Which sequence of steps should you perform to provision, configure, and utilize the user-assigned managed identity to access the storage container?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first create the user-assigned managed identity, then associate it with the Azure App Service instance, then assign the Storage Blob Data Reader RBAC role to the identity at the storage container scope, and finally instantiate the DefaultAzureCredential class in the application code by passing the Client ID of the identity to the constructor options.
The correct sequence begins with provisioning the user-assigned managed identity. Once created, the identity is linked to the App Service hosting environment. Next, the identity is granted the Storage Blob Data Reader role to authorize access. Finally, the application code initiates authentication using DefaultAzureCredential configured with the identity's Client ID.

Step-by-Step Solution

1
Create the user-assigned managed identity resource.
A standalone user-assigned managed identity resource is created with its own Client ID and Principal ID.
The identity must exist in Microsoft Entra ID before it can be associated with hosts or granted access permissions.
2
Associate the user-assigned managed identity with the App Service.
The identity is linked to the App Service host instance, permitting it to request tokens for this identity.
The hosting platform must be aware of the identity to expose its credentials through the local metadata endpoint.
3
Create an RBAC role assignment for the identity on the Storage account.
The identity is granted the Storage Blob Data Reader role at the container or storage account scope.
The identity needs explicit authorization to perform data plane operations on the Azure Storage resource.
4
Configure the application code to use the identity client ID.
The application code uses DefaultAzureCredential with the specific Client ID to request a token and read blobs.
Without the client ID, DefaultAzureCredential will default to a system-assigned managed identity and fail since only a user-assigned identity is associated.

Key Concept

Provisioning and configuring a user-assigned managed identity for Azure App Service authorization
Question 59Question →

You are developing a secure Web API named InventoryAPI and registering it in Microsoft Entra ID. You need to expose two distinct permission sets for client applications that will consume this API:

1. A permission set for automated backend daemon services that run without user interaction.
2. A permission set for user-facing client applications where permissions are delegated on behalf of the signed-in user.

You need to configure the application registration manifest for InventoryAPI to support these requirements.

Which configuration should you implement in the manifest?

Show answer & explanation

Answer: Define app roles in the appRoles array with allowedMemberTypes set to ["Application"] for the daemon services, and define delegated scopes in the oauth2PermissionScopes array for the user-interactive applications.

Answer

Define app roles in the appRoles array with allowedMemberTypes set to ["Application"] for the daemon services, and define delegated scopes in the oauth2PermissionScopes array for the user-interactive applications.
The correct option correctly states that application permissions (which daemon applications require because they authenticate as their own identity) must be defined as app roles within the appRoles array with the allowedMemberTypes property containing "Application". Meanwhile, delegated permissions (which user-facing client applications require to act on behalf of a signed-in user) must be defined as scopes within the oauth2PermissionScopes array.

Step-by-Step Solution

1
Analyze client type requirements for the API.
Backend daemon applications require Application permissions (as they run without a signed-in user). User-facing applications require Delegated permissions (scopes) since they act on behalf of a signed-in user.
This establishes the appropriate Entra ID authorization model needed for each consumer type.
2
Map the permission types to their respective Microsoft Entra ID manifest elements.
Application permissions are represented by appRoles where allowedMemberTypes includes "Application". Delegated permissions are represented by OAuth 2.0 permission scopes defined in the oauth2PermissionScopes array.
This determines the syntax and structure needed in the InventoryAPI registration manifest.
3
Validate the valid values for manifest properties.
allowedMemberTypes only accepts "User", "Application", or both. oauth2PermissionScopes defines scopes for delegated user access.
This ensures the manifest configuration is syntactically valid and aligns with Microsoft Entra ID schema constraints.

Key Concept

Exposing delegated permissions (scopes) vs application permissions (app roles) in a Microsoft Entra ID App Registration manifest
Question 60Question →

You are developing a C# .NET 8 application hosted on an Azure App Service. The application must access both an Azure Key Vault and an Azure SQL Database.

You have the following security and lifecycle requirements:
- The credentials used to access the Key Vault must be unique to the App Service instance and must be automatically deleted if the App Service is deleted.
- The credentials used to access the SQL Database must be shared with another App Service instance in a different region and must persist even if the primary App Service is deleted.

To meet these requirements, you enable a system-assigned managed identity on the App Service and grant it access to the Key Vault. You also create a user-assigned managed identity, assign it to the App Service, and grant it access to the SQL Database.

In your application code, you instantiate the clients using the parameterless DefaultAzureCredential constructor from the Azure.Identity library. During testing, the application successfully retrieves secrets from the Key Vault, but attempts to connect to the SQL Database fail with an access denied error.

Which modification must you make to resolve the SQL Database connection failure?

Show answer & explanation

Answer: Instantiate the credential for the SQL Database client by passing a DefaultAzureCredentialOptions object with its ManagedIdentityClientId property set to the client ID of the user-assigned managed identity.

Answer

Instantiate the credential for the SQL Database client by passing a DefaultAzureCredentialOptions object with its ManagedIdentityClientId property set to the client ID of the user-assigned managed identity.
When both system-assigned and user-assigned managed identities are enabled on a resource, DefaultAzureCredential defaults to using the system-assigned identity. To use the user-assigned identity for the SQL Database connection, you must explicitly specify its client ID using the ManagedIdentityClientId property of DefaultAzureCredentialOptions.

Step-by-Step Solution

1
Identify the default behavior of DefaultAzureCredential when both identity types are enabled.
DefaultAzureCredential defaults to using the system-assigned managed identity.
Azure token endpoints resolve requests without a client ID to the system-assigned managed identity by default.
2
Analyze why Key Vault succeeds and SQL Database fails.
Key Vault client succeeds because it uses the default system-assigned identity which has access, while SQL Database fails because the system-assigned identity does not have SQL access.
Only the user-assigned managed identity has been granted permissions to the SQL Database.
3
Configure the credential for the user-assigned managed identity.
Provide the user-assigned managed identity client ID in the DefaultAzureCredentialOptions.
Specifying the ManagedIdentityClientId overrides the default behavior and forces the credential to authenticate using the user-assigned managed identity.

Key Concept

Configuring DefaultAzureCredential when using both system-assigned and user-assigned managed identities on a single Azure resource.
PreviousPage 3 / 11Next
Implement Azure Security Practice Questions — Microsoft Azure Developer (AZ-204) — Page 3 | Examkin