Examkin

Implement Azure Security

203 questions

All types203Multiple choice102Multiple select71Ordering30
Question 21Question →

An on-premises daemon application needs to access a secure Web API protected by Microsoft Entra ID. The application is registered in Microsoft Entra ID and has a client secret configured. Arrange the steps in the correct chronological order to authenticate the application and access the Web API using the client credentials flow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, the daemon application requests an access token by sending its client credentials to the token endpoint. Next, Microsoft Entra ID validates the credentials and returns the token. The daemon application then includes this token in the Authorization header of its request to the Web API. Finally, the Web API validates the token and returns the requested data.
In the client credentials flow, the application must first request an access token from Microsoft Entra ID by presenting its own credentials (client ID and client secret). Once Microsoft Entra ID validates these credentials, it issues an access token. The application then uses this token in the Authorization header of its request to the Web API, and finally, the Web API validates the token to authorize the access.

Step-by-Step Solution

1
Submit client credentials to the Entra ID token endpoint.
The authentication request is initiated using client_credentials grant type.
Daemon applications run without user interaction and must authenticate using their own identity (the service principal) via client ID and client secret.
2
Receive the token from Microsoft Entra ID.
An access token is obtained by the client application.
Microsoft Entra ID acts as the identity provider, verifying the credentials and generating the access token containing the authorized roles.
3
Present the token to the Web API.
The HTTP request is sent with the Authorization header set to 'Bearer <token>'.
The Web API requires a valid bearer token to authenticate and authorize the incoming request.
4
Process the request at the Web API level.
The token is validated and the resource is returned.
The Web API must verify that the token was signed by Microsoft Entra ID and contains the necessary permissions before granting access to the resource.

Key Concept

The client credentials flow enables a daemon application (represented by an application registration and service principal) to acquire an access token to call a Web API without user interaction.
Estimated Time:1m 0s
Question 22Question →

A developer needs to configure passwordless authentication for a GitHub Actions workflow to deploy resources to an Azure subscription using Microsoft Entra Workload Identity. In which order should the developer perform the steps to establish trust and grant the necessary permissions? To answer, arrange the steps in the correct sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, register the application. Second, create the service principal. Third, configure the federated identity credential on the application registration. Fourth, grant the service principal permissions on the target subscription. Finally, update the GitHub Actions workflow YAML file.
Establishing Workload Identity federation requires a sequential chain of trust. First, the application object is registered globally. Second, a local service principal is created to represent it in the home tenant. Third, a federated identity credential is added to the application registration to trust GitHub's OIDC issuer. Fourth, the service principal is assigned an RBAC role to grant resource management permissions. Finally, the GitHub Actions workflow YAML is configured with the target client and tenant IDs, and the required `id-token: write` permission to exchange its GitHub OIDC token for an Entra access token.

Step-by-Step Solution

1
Register the application in Microsoft Entra ID.
An application object is created, generating a unique Application (Client) ID.
This establishes the identity template that defines the application.
2
Create the service principal.
A service principal object is created in the local tenant.
This represents the application instance in the tenant and is required to assign roles and permissions.
3
Create a federated identity credential.
Trust is established between Entra ID and the external OIDC token issuer (GitHub).
This allows Entra ID to trust security tokens issued by GitHub Actions for this specific repository and branch.
4
Assign the RBAC role.
The service principal is authorized to manage resources.
Roles must be assigned to the service principal in the tenant so that the authenticated session has the necessary execution permissions.
5
Configure the GitHub Actions workflow YAML.
The workflow can successfully obtain an Entra ID access token and login.
The workflow must request the OIDC token (`id-token: write`) and present the client and tenant IDs during authentication.

Key Concept

Microsoft Entra Workload Identity federation utilizes an application registration, its corresponding service principal, and federated identity credentials to allow external workloads (like GitHub Actions) to authenticate securely without maintaining client secrets or certificates.
Question 23Question →

You need to configure an Azure App Service web app to retrieve secrets from an Azure Key Vault by using a user-assigned managed identity. Which sequence of steps should you perform? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: first, create the user-assigned managed identity; second, associate the user-assigned managed identity with the Azure App Service web app; third, assign the role or access policy to the identity on the Key Vault; and fourth, configure the application code to authenticate using the client ID of the user-assigned managed identity.
To successfully authenticate an App Service using a user-assigned managed identity, you must first provision the identity resource. Once created, it must be linked to the web app so the runtime environment can access its credentials. You then grant the identity permissions on the target Key Vault via role-based access control or access policies. Finally, since multiple user-assigned identities can exist on a resource, you must explicitly supply the client ID in your code configuration (e.g., using DefaultAzureCredentialOptions) to specify which identity to use.

Step-by-Step Solution

1
Create the user-assigned managed identity.
A standalone Azure identity resource is provisioned with its own client ID.
Since user-assigned identities exist independently of resources, they must be created before they can be configured or assigned.
2
Associate the identity with the App Service web app.
The App Service web app is configured to use the user-assigned identity.
This allows the host environment of the App Service to present the identity's credentials when requesting tokens.
3
Configure permissions on the Key Vault for the identity.
The identity is authorized to access Key Vault secrets.
By default, identities have no access to Azure resources; authorization must be explicitly granted.
4
Update the web app application code.
The code successfully authenticates and retrieves secrets.
Because multiple user-assigned identities can be associated with a single resource, the code must specify which user-assigned identity to use by providing its client ID to the credential class.

Key Concept

Provisioning, assigning, and authorizing a user-assigned managed identity to access Azure resources.
Estimated Time:1m 0s
Question 24Question →

A developer registers a multitenant web application in their organization's Microsoft Entra ID tenant. When a user from a different organization consents to use the application, which object is automatically created in that user's tenant to represent the application instance and manage its local permissions?

Show answer & explanation

Answer: A service principal

Answer

A service principal
The correct answer is the option stating a service principal. When an application is registered in Microsoft Entra ID, an application object is created in the home tenant. However, to allow the application to execute and access resources in other tenants (such as when an external user consents), Microsoft Entra ID creates a service principal in the user's tenant. This service principal represents the local instance of the application and is used to assign permissions and roles locally.

Step-by-Step Solution

1
Analyze the scenario of registering a multitenant application and consenting users from other tenants.
Identify that the application registration acts as the global definition, but each tenant needs a local representation to manage access.
Microsoft Entra ID separates the application's global configuration from its local instance details.
2
Determine the object type that represents this local instance.
A service principal object is created in the consenting tenant to act as the identity for the application instance.
The service principal governs the actual security token issuance and resource access permissions within that specific tenant.

Key Concept

Difference between App Registrations and Service Principals in multitenant environments
Question 25Question →

You are developing a Single Page Application (SPA) in React. The application runs in the user's web browser, authenticates users via Microsoft Entra ID, and reads their calendar events from Microsoft Graph on their behalf. You are creating the app registration in Microsoft Entra ID. Which two configurations should you implement to support this scenario?

Select all that apply

Show answer & explanation

Answer: Configure the Redirect URI with the platform type set to Single-page application (SPA).; Add the delegated Calendars.Read permission for Microsoft Graph to the application registration.

Answer

Configure the Redirect URI with the platform type set to Single-page application (SPA) and add the delegated Calendars.Read permission for Microsoft Graph to the application registration.
To configure authentication and authorization for a Single Page Application (SPA) accessing Microsoft Graph on behalf of a user, the application registration must use the 'Single-page application (SPA)' platform type for the Redirect URI. This platform type enables the Authorization Code Flow with PKCE, which is the secure authentication flow recommended for browser-based clients. Additionally, because the application needs to access the user's calendar data on their behalf, the 'Calendars.Read' delegated permission must be added to the application registration so that the user (or administrator) can consent to the access.

Step-by-Step Solution

1
Determine the application type and authentication flow.
The application is a browser-based Single Page Application (SPA). Secure authentication requires using the Authorization Code Flow with PKCE rather than the implicit flow or client credentials flow.
Choosing the correct flow prevents token exposure and ensures compatibility with modern security standards.
2
Configure the Redirect URI platform type in the Entra ID application registration.
Setting the platform type specifically to 'Single-page application (SPA)' triggers the Authorization Code Flow with PKCE.
This is required to allow the client library (MSAL.js) to securely trade authorization codes for tokens without a client secret.
3
Identify and assign the correct API permission type.
Because the application accesses the resource (calendar events) on behalf of a signed-in user, the delegated permission 'Calendars.Read' must be added.
Application permissions are meant for service-to-service communication without user presence, whereas delegated permissions are correct for user-interactive sessions.

Key Concept

Configuring App Registrations in Microsoft Entra ID for Single-Page Applications (SPAs) accessing protected APIs.
Question 26Question →

A software-as-a-service (SaaS) provider registers a multi-tenant web application in their home Microsoft Entra ID tenant (Tenant A). An enterprise customer (Tenant B) successfully consents to the application, allowing their users to log in. The SaaS provider now needs to grant this application read access to an Azure SQL Database located in Tenant B. Which identity object in Tenant B must be assigned the database permissions?

Show answer & explanation

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

Answer

The service principal object created in Tenant B that references the application object in Tenant A
The correct answer is the service principal object created in Tenant B. In Microsoft Entra ID, the application object is the global definition of the application, which is created only in the home tenant (Tenant A). When a user or administrator in Tenant B consents to the application, a service principal (also called an enterprise application) is created in Tenant B. To grant the application access to resources in Tenant B, you must assign permissions to this local service principal.

Step-by-Step Solution

1
Distinguish between the application object and the service principal in a multi-tenant scenario.
The application object is the global template residing in Tenant A, whereas the service principal is the local instance in Tenant B.
Understanding the relationship between these two objects is required to determine which one receives resource permissions.
2
Evaluate the lifecycle of the identity objects during the consent process.
Consenting to the multi-tenant application in Tenant B automatically provisions a service principal object in Tenant B.
This establishes a security principal in the target tenant that can be authenticated and authorized.
3
Assign the database permission to the appropriate identity principal.
Grant the database permissions directly to the newly created service principal in Tenant B.
Resource authorization in Azure SQL Database requires referencing a security principal local to the tenant hosting the resource.

Key Concept

Multi-tenant application architecture requires a local service principal in the consumer tenant to assign permissions to resources in that tenant.
Question 27Question →

You are developing a web application that will be hosted on Azure App Service. The application must retrieve secrets from an Azure Key Vault. You decide to use a user-assigned managed identity for authentication. The application code uses the DefaultAzureCredential class from the Azure.Identity library.

You need to configure the Azure resources and the web application to enable secure access.

Which four actions should you perform in sequence? To answer, move 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

Create a user-assigned managed identity, assign the user-assigned managed identity to the App Service web app, assign the Key Vault Secrets User role to the user-assigned managed identity's service principal, and add the AZURE_CLIENT_ID application setting containing the Client ID of the user-assigned managed identity to the App Service.
To use a user-assigned managed identity with Azure App Service and access Azure Key Vault via the Azure SDK's DefaultAzureCredential, you must first create the identity as an independent Azure resource. Then, you associate the identity with the App Service web app so the hosting environment is aware of it. Next, you assign the necessary RBAC role (Key Vault Secrets User) to the identity's principal ID on the Key Vault. Finally, you set the AZURE_CLIENT_ID application setting on the web app to specify the Client ID of the user-assigned managed identity, which ensures that DefaultAzureCredential selects the correct user-assigned identity for token requests.

Step-by-Step Solution

1
Create a user-assigned managed identity.
A standalone identity resource is provisioned in Azure with its own Client ID and Principal ID.
The identity must exist in Azure before it can be assigned to the web app or granted permissions.
2
Assign the user-assigned managed identity to the App Service web app.
The App Service web app is associated with the user-assigned managed identity.
This configuration allows the App Service infrastructure to obtain tokens on behalf of the identity.
3
Assign the Key Vault Secrets User role to the user-assigned managed identity's service principal.
The identity's service principal is authorized to retrieve secrets from the Key Vault.
The identity must have appropriate RBAC permissions to access the target resource.
4
Add the AZURE_CLIENT_ID application setting containing the Client ID of the user-assigned managed identity to the App Service.
The environment variable AZURE_CLIENT_ID is set in the App Service execution context.
DefaultAzureCredential uses this environment variable to resolve which user-assigned identity to use when multiple identities or a system identity could be present.

Key Concept

Provisioning and configuring a user-assigned managed identity for Azure App Service and Key Vault
Question 28Question →

An enterprise ASP.NET Core application is hosted on an Azure Virtual Machine. The virtual machine has been assigned two user-assigned managed identities: IdentityA (authorized to read secrets from Azure Key Vault) and IdentityB (authorized to write to Azure Storage). To retrieve secrets, the application uses the following C# code:

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

When execution occurs on the virtual machine, authentication fails with a CredentialUnavailableException.

Which action must you perform to resolve the authentication failure?

Show answer & explanation

Answer: Configure the DefaultAzureCredential to target IdentityA by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of IdentityA.

Answer

Configure the DefaultAzureCredential to target IdentityA by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of IdentityA.
The correct action is to configure the DefaultAzureCredential to target IdentityA by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of IdentityA. When multiple user-assigned managed identities are assigned to a single Azure resource, the IMDS endpoint requires the client ID to resolve the ambiguity and issue the correct token.

Step-by-Step Solution

1
Analyze the exception context and resource configuration.
The virtual machine is configured with multiple user-assigned managed identities (IdentityA and IdentityB) but the application uses DefaultAzureCredential with default options.
When multiple user-assigned managed identities are assigned to a single resource, the Instance Metadata Service (IMDS) endpoint cannot automatically determine which identity to use.
2
Determine the required client-side configuration for the Azure.Identity SDK.
Identify that ManagedIdentityClientId must be set in DefaultAzureCredentialOptions to specify the target user-assigned identity.
Specifying the client ID tells DefaultAzureCredential to pass the client ID parameter to the IMDS token request, resolving the identity ambiguity.
3
Update the client initialization code.
Initialize SecretClient using the configured DefaultAzureCredential.
This allows the application to successfully authenticate and retrieve secrets from the Key Vault using the permissions of IdentityA.

Key Concept

Handling multiple user-assigned managed identities with DefaultAzureCredential in the Azure SDK
Question 29Question →

Your company has developed a multi-tenant software-as-a-service (SaaS) application registered in Microsoft Entra Tenant A. Several client organizations, including Tenant B, have consented to the application, which created a service principal for the application in each customer tenant. The application runs as a background daemon service and uses the client credentials flow with a client secret to access APIs in each customer's tenant. You need to rotate the client secret without causing service interruption or requiring the customers' administrators to perform any actions. Which of the following is the correct way to rotate the secret?

Show answer & explanation

Answer: Configure the new client secret on the application registration in Tenant A, update the daemon service to use the new secret, and then delete the expired secret from the application registration in Tenant A.

Answer

Configure the new client secret on the application registration in Tenant A, update the daemon service to use the new secret, and then delete the expired secret from the application registration in Tenant A.
In a multi-tenant Microsoft Entra ID scenario, the global Application object (managed via the App Registration in the home tenant) holds the authentication credentials (secrets/certificates). The local Service Principals created in consumer tenants reference the global application object for authentication checks. To rotate credentials without downtime, you add a new secret to the App Registration in the home tenant, update your service to use it, and delete the old secret. No updates or admin intervention are required in the customer tenants.

Step-by-Step Solution

1
Locate the application registration in the home tenant (Tenant A) where the multi-tenant app is registered.
Access to the global Application object configuration is obtained.
Credentials for multi-tenant applications are managed globally on the Application object, not on individual local service principals.
2
Generate a new client secret under the Certificates & secrets section of the application registration.
A new client secret value is created and becomes active immediately.
Adding a second secret allows the application to authenticate using either the old or new secret, preventing downtime during transition.
3
Update the daemon service configuration to use the new client secret value when requesting tokens.
The daemon service successfully acquires tokens for Tenant B and other customer tenants using the new secret.
Microsoft Entra ID resolves token requests by validating the provided secret against the application object in Tenant A, even when requesting tokens for Tenant B.
4
Remove the old client secret from the application registration in Tenant A.
The old client secret is revoked and can no longer be used for authentication.
Deleting the old secret ensures proper security hygiene and completes the rotation process.

Key Concept

Multi-tenant application credentials management and the relationship between Application objects (App Registrations) and Service Principals.

Alternative Method

Instead of using client secrets, you can upload a client certificate to the application registration in Tenant A. For production environments, authenticating via a certificate stored securely in Azure Key Vault is the recommended practice for rotation and security compliance.
Estimated Time:3m 0s
Question 30Question →

You are developing a background daemon service that will run on an on-premises server. The service must periodically scan all user mailboxes in your organization's Microsoft Entra ID tenant and archive email attachments to Azure Blob Storage. The service will run in the background without any user interaction or sign-in.

You register the application in Microsoft Entra ID. You need to configure the API permissions and authentication requirements.

Which two actions should you perform to configure the application registration and permissions? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the application registration with the Mail.Read Application permission for the Microsoft Graph API.; Grant tenant-wide admin consent for the configured Microsoft Graph API permission.

Answer

The correct actions are to configure the application registration with the Mail.Read Application permission for the Microsoft Graph API and to grant tenant-wide admin consent for the configured Microsoft Graph API permission.
A background daemon service runs without a user context. Therefore, it requires Application permissions instead of Delegated permissions to access resources like mailboxes. Furthermore, since Application permissions allow broad access to all resources of that type in the tenant, they must be approved by a directory administrator via tenant-wide admin consent.

Step-by-Step Solution

1
Determine the application type and user context.
The application is identified as a daemon service that runs in the background without user interaction.
This establishes that application permissions must be used instead of delegated permissions, since no user will be logging in.
2
Select the appropriate permission type in the application registration.
The application is configured with the Mail.Read Application permission.
Application permissions are intended for applications that run without a signed-in user.
3
Grant tenant consent for the configured application permission.
A tenant administrator grants tenant-wide admin consent for the permission in the Azure Portal or using CLI.
Application permissions grant broad access to resources (e.g. all mailboxes) and therefore cannot be consented to by regular users.

Key Concept

App Registrations, Service Principals, and Application vs Delegated Permissions
Estimated Time:2m 0s
Question 31Question →

You are developing an ASP.NET Core web application hosted on Azure App Service that retrieves database connection strings from Azure Key Vault. The application uses the DefaultAzureCredential class from the Azure.Identity library to authenticate. To meet security requirements, the managed identity must be exclusive to this App Service instance, and its lifecycle must be bound directly to the App Service. You run the command 'az webapp identity assign --name MyWebApp --resource-group MyResourceGroup' to configure the App Service. However, when the web application starts up and attempts to retrieve a secret, a credential retrieval error occurs. Which of the following actions should you perform to resolve this issue?

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.

Answer

Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.
The correct action is to assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope. Running the Azure CLI command enables the system-assigned managed identity on the App Service. However, to access the Key Vault secrets, the identity must be explicitly authorized. The Key Vault Secrets User role provides the necessary data-plane permissions for reading secrets. Using a system-assigned identity satisfies the requirement that the identity's lifecycle is bound directly to the resource.

Step-by-Step Solution

1
Analyze the identity requirements
The requirement states that the identity must be exclusive and its lifecycle bound directly to the App Service, which specifies a system-assigned managed identity.
This helps identify if the command run ('az webapp identity assign') correctly enabled the system-assigned managed identity, which it did.
2
Diagnose the error cause
The identity exists on the App Service but cannot read secrets from the Key Vault, indicating a missing data-plane permission (RBAC role or Key Vault access policy).
Enabling the identity on the host resource only registers it in Microsoft Entra ID; it does not grant permissions to other Azure resources automatically.
3
Determine the correct authorization level
Assign the Key Vault Secrets User role (or equivalent access policy) to the system-assigned managed identity at the Key Vault scope.
This grants the application permission to read secrets (data-plane access) while keeping the lifecycle bound to the App Service.

Key Concept

Authorizing a system-assigned managed identity to access Azure Key Vault secrets using Role-Based Access Control (RBAC).
Question 32Question →

You are configuring security for an Azure Function App that needs to read files from an Azure Storage account. You want to use a managed identity to authenticate. You must determine the characteristics of system-assigned and user-assigned managed identities to choose the best option.

Which of the following statements about these managed identity types are correct? (Select TWO)

Select all that apply

Show answer & explanation

Answer: A system-assigned managed identity is automatically deleted when the associated Azure resource is deleted.; A user-assigned managed identity is created as a standalone Azure resource and its lifecycle is independent of the resources it is assigned to.

Answer

A system-assigned managed identity is automatically deleted when the associated Azure resource is deleted, and a user-assigned managed identity is created as a standalone Azure resource whose lifecycle is independent of the resources it is assigned to.
The correct statements correctly describe the lifecycle boundaries. A system-assigned managed identity is enabled directly on a resource, and deleting that resource automatically deletes the identity. Conversely, a user-assigned managed identity is created as an independent resource in Azure, meaning its lifecycle is separate and it remains in existence even if all resources utilizing it are deleted.

Step-by-Step Solution

1
Analyze the lifecycle characteristics of a system-assigned managed identity.
Confirm that system-assigned identities are tied to the resource lifecycle and deleted when the resource is deleted.
This is a fundamental property of system-assigned managed identities.
2
Analyze the lifecycle and sharing characteristics of a user-assigned managed identity.
Confirm that user-assigned identities are standalone resources, have independent lifecycles, and can be assigned to multiple resources.
This distinguishes user-assigned identities from system-assigned ones.
3
Identify the two correct statements that match these verified characteristics.
The statement about automatic deletion of system-assigned identities and the statement about user-assigned identities being standalone resources with independent lifecycles are selected.
These statements correctly state the properties of managed identities without introducing misconceptions.

Key Concept

Understanding the differences in lifecycle, resource sharing, and configuration properties between system-assigned and user-assigned managed identities in Azure.
Question 33Question →

You are deploying a single Azure App Service web app that needs to retrieve database credentials securely. You want to enable a managed identity for the web app to access Azure Key Vault. The identity must share the lifecycle of the App Service resource, meaning that if the App Service is deleted, the identity is automatically cleaned up. Which identity type or configuration should you implement for the App Service?

Show answer & explanation

Answer: A system-assigned managed identity

Answer

A system-assigned managed identity
A system-assigned managed identity is enabled directly on an Azure resource (such as an App Service). Its lifecycle is bound directly to that resource; when the host resource is deleted, Azure automatically deletes the identity in Microsoft Entra ID. This avoids leaving orphaned identity resources behind and simplifies lifecycle management.

Step-by-Step Solution

1
Analyze the requirements for the identity lifecycle.
The identity must be tied directly to the lifecycle of the App Service and deleted automatically if the App Service is deleted.
This requirement determines whether a system-assigned or user-assigned identity is appropriate.
2
Compare system-assigned and user-assigned managed identity lifecycles.
System-assigned identities are tied to the host resource's lifecycle, while user-assigned identities are standalone resources with independent lifecycles.
System-assigned identities satisfy the requirement of automatic cleanup upon resource deletion.
3
Select the correct configuration option.
Enable a system-assigned managed identity on the App Service.
This aligns exactly with the design goal of automatic lifecycle cleanup.

Key Concept

Managed Identity Lifecycle Management
Question 34Question →

You are designing the security architecture for a C# web application deployed to two distinct Azure App Service instances in different regions (East US and West US) to support active-active high availability. Both App Service instances must retrieve database connection strings from a shared Azure Key Vault and connect to a shared Azure SQL Database without storing credentials in code or configuration files.

The design must satisfy the following security and operational constraints:
- Minimize administrative overhead by avoiding the creation of separate database users and Key Vault access policies/RBAC roles for each regional App Service instance.
- Ensure that if one of the App Service instances is deleted, the identity used to authenticate to the Key Vault and Azure SQL Database remains intact and functional for the remaining instance.
- The application code must use the C# Azure.Identity SDK and instantiate DefaultAzureCredential to authenticate to both services.

Which configuration and code setup should you implement to meet these requirements?

Show answer & explanation

Answer: Create one user-assigned managed identity. In the App Service ARM templates, set the identity.type property to UserAssigned and configure the identity's resource ID in the userAssignedIdentities property. Configure the AZURE_CLIENT_ID application setting on both App Services with the client ID of the user-assigned managed identity, and instantiate DefaultAzureCredential in C# code.

Answer

Create one user-assigned managed identity, configure the App Service ARM templates to use the UserAssigned identity type mapping the resource ID, set the AZURE_CLIENT_ID environment variable on the App Services, and instantiate DefaultAzureCredential in C# code.
The correct option configures a user-assigned managed identity, which operates independently of individual App Service lifecycles and can be shared across regions to minimize permissions management overhead. It correctly sets the identity type to UserAssigned in ARM and configures the AZURE_CLIENT_ID environment variable, which enables DefaultAzureCredential to resolve the identity successfully at runtime.

Step-by-Step Solution

1
Analyze the identity lifecycle and sharing requirements.
A user-assigned managed identity (UAMI) is chosen because it exists as an independent Azure resource and can be assigned to multiple App Service instances, avoiding duplicated database users and policies.
System-assigned identities are tied to a single resource's lifecycle and cannot be shared across multiple resources.
2
Determine the correct ARM template configuration.
Set the identity.type property to UserAssigned and reference the identity's resource ID within the userAssignedIdentities property block.
Setting the type to SystemAssigned or using the principal ID in the configuration block is invalid configuration syntax for user-assigned identities.
3
Configure the App Service environment and C# code.
Add the AZURE_CLIENT_ID application setting containing the client ID of the user-assigned identity to both App Services, and initialize DefaultAzureCredential in C#.
Without the client ID specified via the AZURE_CLIENT_ID environment variable, DefaultAzureCredential will not be able to identify which user-assigned identity to use when requesting tokens.

Key Concept

Selecting and configuring user-assigned managed identities for multi-resource sharing, independent lifecycles, and resolution with DefaultAzureCredential.
Question 35Question →

An administrator is configuring a Microsoft Entra ID app registration for a background daemon service that runs nightly without any user interaction. The daemon service must read all user profiles in the tenant using the Microsoft Graph API.

Which of the following configuration steps are required to implement this? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure the Application permission type for Microsoft Graph's User.Read.All.; Grant tenant-wide admin consent for the configured User.Read.All permission.

Answer

Configure the Application permission type for Microsoft Graph's User.Read.All, and grant tenant-wide admin consent for the permission.
For background services or daemons running without user interaction, Application permissions must be used because there is no signed-in user. Because the User.Read.All permission allows access to all user profiles in the tenant, Microsoft Entra ID requires tenant-wide admin consent to be granted before the token can be issued.

Step-by-Step Solution

1
Identify the application interaction model.
Since the background daemon service runs nightly without any user interaction, it cannot run in the context of a signed-in user.
This establishes that Application permissions are required instead of Delegated permissions.
2
Determine the necessary permission scope and administrative requirements.
Microsoft Graph requires the User.Read.All application permission for reading all user profiles, which requires tenant-wide admin consent.
An administrator must grant consent before the daemon service can acquire a token to access tenant-wide profile data.

Key Concept

Differentiating between Delegated and Application permissions and understanding administrative consent requirements for Microsoft Entra ID app registrations.
Question 36Question →

An organization requires a web application running on Azure App Service to query an Azure SQL Database. The security policy mandates the use of a user-assigned managed identity to eliminate hardcoded credentials. You must perform the configuration steps using the Azure CLI and SQL commands, and configure the .NET application code to connect securely. Which sequence of steps must you perform to provision, configure, and authenticate the application using the user-assigned managed identity?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the user-assigned managed identity using the CLI. Next, assign this identity to the Azure App Service web app. After that, create a contained user for the identity within the Azure SQL Database and grant the database reader role. Then, configure the App Service app settings by adding the client ID of the user-assigned identity to the client ID environment variable. Finally, write application code using the default Azure credential to connect to the database.
The correct sequence flows logically from infrastructure provisioning to application deployment. The identity must be created first before it can be assigned to the web app or authorized in the SQL Database. The app settings must be updated to reference the client ID before the application code is executed, allowing the default Azure credential to correctly resolve the user-assigned identity at runtime.

Step-by-Step Solution

1
Run `az identity create` to provision the user-assigned managed identity.
A user-assigned managed identity is created in Microsoft Entra ID.
You cannot associate an identity or authorize it in other services until it exists.
2
Run `az webapp identity assign` to link the identity to the App Service web app.
The App Service is configured to use the user-assigned managed identity.
This allows the App Service infrastructure to acquire tokens on behalf of the user-assigned identity.
3
Run SQL DDL commands to create a contained user from the external provider.
The identity is authorized inside the target SQL database.
Managed identities authenticate against Microsoft Entra ID, and SQL Database must map this identity to a contained user to authorize access.
4
Set the `AZURE_CLIENT_ID` application setting on the App Service.
The application runtime environment exposes the client ID to the credential libraries.
Unlike system-assigned identities, user-assigned identities require specifying the client ID. The default Azure credential checks this environment variable to know which user-assigned identity to select.
5
Initialize `DefaultAzureCredential` and establish the database connection.
The application successfully connects to the SQL database using passwordless authentication.
The credential library automatically picks up the client ID environment variable and requests a token for Azure SQL Database from the local endpoint.

Key Concept

Configuring a user-assigned managed identity for App Service to access Azure SQL Database requires identity creation, resource association, target system authorization, runtime client ID configuration, and default SDK credential usage.
Question 37Question →

An enterprise architecture requires implementing two new applications integrated with Microsoft Entra ID:

1. SyncDaemon: A background service that runs without user interaction to synchronize user profile information across all users in the tenant.
2. UserPortal: A single-page application (SPA) using the OAuth 2.0 authorization code flow with PKCE, allowing signed-in users to view their own profile and access a custom secure web API.

You need to configure the permissions, scopes, and consent for both applications following the principle of least privilege.

Which two configurations should you implement?

Select all that apply

Show answer & explanation

Answer: Configure SyncDaemon with the Microsoft Graph Application permission User.Read.All and have a tenant administrator grant tenant-wide consent.; Configure UserPortal with the Microsoft Graph Delegated permission User.Read and define a custom scope in the format api://<API_ClientId>/Access on the custom web API registration.

Answer

Configure SyncDaemon with the Microsoft Graph Application permission User.Read.All with tenant admin consent, and configure UserPortal with the Microsoft Graph Delegated permission User.Read and a custom scope on the custom web API registration.
The background service SyncDaemon has no signed-in user context and therefore requires Application permissions (User.Read.All) which always require tenant admin consent. The Single Page Application UserPortal operates in a user context, requiring Delegated permissions (User.Read), and accesses the custom web API using a custom scope registered on the target API's registration in Microsoft Entra ID.

Step-by-Step Solution

1
Determine the application type and user context for SyncDaemon.
SyncDaemon is identified as a daemon application running without user interaction.
This establishes that Application permissions (rather than Delegated permissions) must be used, which consequently requires tenant admin consent.
2
Determine the application type and user context for UserPortal.
UserPortal is identified as a Single Page Application (SPA) where users sign in.
This establishes that Delegated permissions must be used because operations are performed on behalf of the signed-in user.
3
Select the correct permission scopes and authentication mechanism for accessing the custom web API.
A custom scope exposed on the API application registration is defined using the App ID URI prefix.
This allows the SPA to request a token specifically scoped for the custom web API using Entra ID, rather than relying on storage-specific mechanisms like Shared Access Signatures.

Key Concept

Microsoft Entra ID Application vs. Delegated Permissions and API Scopes
Question 38Question →

A company is deploying a background synchronization service on an external cloud provider's virtual machine. The service requires access to Azure resources. You register the service as an application in Microsoft Entra ID. To comply with corporate security policies, the service must authenticate using a certificate instead of a client secret. Which configuration step must you perform in Microsoft Entra ID to enable this authentication?

Show answer & explanation

Answer: Upload the public key of the certificate to the application registration's certificates and secrets settings.

Answer

Upload the public key of the certificate to the application registration's certificates and secrets settings.
To authenticate an application registration with a certificate, the public key of the certificate must be uploaded to the app registration's Certificates & secrets settings. The client application then uses its private key to sign a client assertion when requesting a token from Microsoft Entra ID, which Entra ID verifies using the uploaded public key.

Step-by-Step Solution

1
Generate a self-signed or CA-signed certificate and extract its public key (e.g., in .cer format).
You obtain a public key file and a private key file.
The public key will be uploaded to Microsoft Entra ID, while the private key remains secure on the client machine.
2
Navigate to the application registration in Microsoft Entra ID and upload the public key under the Certificates & secrets section.
Microsoft Entra ID registers the certificate and associates it with the application object.
Entra ID needs the public key to verify client assertions signed by the client application using the matching private key.
3
Configure the client application to sign a client assertion JWT using the private key and send it to the Entra ID token endpoint to request an access token.
Microsoft Entra ID validates the signature with the uploaded public key and returns an access token.
This completes the OAuth 2.0 client credentials flow using a certificate instead of a client secret.

Key Concept

Certificate-based authentication for App Registrations and Service Principals in Microsoft Entra ID.
Question 39Question →

You are developing a web application where users must log in using their corporate accounts. After logging in, the application needs to read the profile details of the currently signed-in user from Microsoft Graph. Which type of permission should you configure for the Microsoft Graph API in the Microsoft Entra ID application registration?

Show answer & explanation

Answer: Delegated permissions

Answer

Delegated permissions
The correct answer is delegated permissions because they are specifically designed for scenarios where an application runs with an active, signed-in user and acts on their behalf. This ensures that the application cannot access any resource that the signed-in user themselves does not have permission to access.

Step-by-Step Solution

1
Analyze the application requirements.
The application requires a user to sign in and needs to access Microsoft Graph API resources on behalf of that signed-in user.
Identifying if a user context exists helps determine the correct permission model.
2
Select the appropriate Microsoft Entra ID permission type.
Delegated permissions are selected because they operate in the context of a signed-in user, enforcing the permissions of both the user and the application.
Delegated permissions allow the application to act on behalf of the signed-in user, whereas application permissions are for daemon services running without user context.

Key Concept

Delegated versus Application permissions in Microsoft Entra ID
Question 40Question →

An administrator deletes an Azure App Service instance that was configured to access an Azure Key Vault. The App Service used a system-assigned managed identity for authentication. What happens to the associated managed identity in Microsoft Entra ID after the App Service is deleted?

Show answer & explanation

Answer: The managed identity is automatically deleted from Microsoft Entra ID.

Answer

The managed identity is automatically deleted from Microsoft Entra ID.
A system-assigned managed identity is enabled directly on an Azure resource instance. Its lifecycle is tied to that resource. Therefore, when the App Service instance is deleted, the identity is automatically cleaned up and deleted from Microsoft Entra ID.

Step-by-Step Solution

1
Identify the type of managed identity configuration being used in the scenario.
The App Service is configured with a system-assigned managed identity.
Managed identity lifecycle characteristics depend on whether the identity is system-assigned or user-assigned.
2
Determine the lifecycle behavior of a system-assigned managed identity upon host resource deletion.
A system-assigned managed identity is tied directly to the lifespan of the Azure resource that hosts it.
Unlike user-assigned identities, system-assigned identities cannot exist independently of their parent resource.
3
Conclude the status of the identity in Microsoft Entra ID.
The identity is automatically deleted from Microsoft Entra ID when the host App Service is deleted.
This cleanup occurs automatically to prevent orphaned identities.

Key Concept

The lifecycle of a system-assigned managed identity is strictly tied to the Azure resource on which it is enabled, meaning it is deleted automatically when the resource is deleted.
Estimated Time:45s
PreviousPage 2 / 11Next
Implement Azure Security Practice Questions — Microsoft Azure Developer (AZ-204) — Page 2 | Examkin