Examkin

All practice questions

171 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 61Question →

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

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

Configuring certificate-based client credentials flow using Microsoft Entra ID application registrations, local service principals, and role assignments.
Estimated Time:3m 0s
Question 62Question →

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 63Question →

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 64Question →

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 65Question →

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 66Question →

You need to deploy a containerized API gateway to Azure Container Instances (ACI). The container must be integrated into a new subnet within an existing virtual network to access private back-end services. In which order should you perform the steps to configure and deploy the container group?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: Create a new subnet in the existing virtual network, delegate the subnet to the Microsoft.ContainerInstance/containerGroups service, retrieve the resource ID of the delegated subnet, and run the az container create command specifying the subnet resource ID.
To integrate an Azure Container Instances container group with a virtual network, you must first create a subnet, delegate that subnet to the Microsoft.ContainerInstance/containerGroups provider, retrieve the subnet's resource ID, and then issue the deployment command with the subnet ID referenced.

Step-by-Step Solution

1
Create a new subnet in the existing virtual network.
A subnet is successfully provisioned within the virtual network.
The network path must exist before any service-specific delegation or resource deployment can occur.
2
Delegate the subnet to the Microsoft.ContainerInstance/containerGroups service.
The subnet is delegated to the container instances service.
Subnet delegation permits Azure Container Instances to create the network profiles required to run inside the virtual network.
3
Retrieve the resource ID of the delegated subnet.
The resource ID of the subnet is obtained (e.g., via az network vnet subnet show).
The deployment command needs the precise resource identifier of the delegated subnet to position the container group correctly.
4
Run the az container create command specifying the subnet resource ID.
The ACI container group is created and integrated into the virtual network.
This initiates the container group deployment inside the configured subnet.

Key Concept

Integrating Azure Container Instances (ACI) into a virtual network via subnet delegation
Question 67Question →

You are developing a backend synchronization service in C# using the Azure.Storage.Blobs SDK (v12). The service needs to update the metadata of a critical blob. However, another worker instance crashed while holding an active lease on the blob, blocking updates. To recover, your service must immediately break the existing lease, secure a new lease to prevent other instances from writing, update the blob's metadata, and clean up. Arrange the steps in the correct order to perform this workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, instantiate a BlobClient, then instantiate a BlobLeaseClient. Next, break the existing lease, acquire a new lease, set the metadata using the new lease ID in the request conditions, and finally release the lease.
The correct sequence starts by obtaining a BlobClient, which is used to construct a BlobLeaseClient. Since the blob is currently locked by a crashed worker's lease, the lease must first be broken using BreakAsync. After the lease is broken, the current process must call AcquireAsync to get a new lease for itself. The metadata is then updated using SetMetadataAsync, passing the new lease ID in the request conditions to authorize the write operation on the locked blob. Finally, ReleaseAsync is called to free the lock.

Step-by-Step Solution

1
Instantiate BlobClient.
An instance of BlobClient pointing to the target blob is created.
A blob client is required to reference the target storage resource.
2
Instantiate BlobLeaseClient.
A lease client associated with the blob client is created.
The lease client is used to perform lease actions like breaking, acquiring, and releasing.
3
Call BreakAsync on the lease client.
The crashed worker's lease is broken.
A lease must be broken before another client can acquire a lease on the same blob immediately.
4
Call AcquireAsync on the lease client.
A new lease is acquired and a lease ID is generated.
Acquiring a new lease secures exclusive access for the current thread of execution.
5
Call SetMetadataAsync on the blob client.
The blob's metadata is updated.
The metadata must be written along with the lease ID inside BlobRequestConditions to satisfy the lease requirement.
6
Call ReleaseAsync on the lease client.
The lease is released.
Releasing the lease cleans up the lock and allows other workers to acquire it.

Key Concept

Managing blob leases and performing write operations under an active lease using the Azure.Storage.Blobs SDK.
Question 68Question →

A backend service is being updated to coordinate access to a shared log file stored in Azure Blob Storage. To ensure thread safety when modifying metadata, the service must obtain a write lease, perform the metadata update, and clean up the lease. What is the correct sequence of operations to complete this task using the Azure.Storage.Blobs namespace?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: Instantiate a BlobClient representing the target log blob, initialize a BlobLeaseClient using the BlobClient and call AcquireAsync to obtain a lease ID, call SetMetadataAsync on the BlobClient passing a BlobRequestConditions object initialized with the lease ID, and then invoke ReleaseAsync on the BlobLeaseClient to unlock the blob.
To update a leased blob, a client must first establish a BlobClient, use it to initialize a BlobLeaseClient, acquire the lease, apply the metadata update by passing the lease ID in the request conditions, and finally release the lease to unlock the resource.

Step-by-Step Solution

1
Obtain a BlobClient reference.
An active client reference to the target blob is established.
Both the lease client initialization and the metadata update require the underlying BlobClient.
2
Create a BlobLeaseClient and call AcquireAsync.
A lease lock is successfully acquired on the blob, generating a lease ID.
The blob must be locked prior to any modification to prevent concurrent writes from other instances.
3
Invoke SetMetadataAsync with BlobRequestConditions containing the lease ID.
The metadata on the leased blob is updated.
Since the blob has an active lease, all write operations must explicitly include the lease ID to prove ownership of the lock.
4
Call ReleaseAsync on the BlobLeaseClient.
The lease is released, clearing the write lock.
Releasing the lease unlocks the blob, enabling other operations and clients to modify it.

Key Concept

Acquiring, using, and releasing exclusive-write leases during metadata updates using the Azure Storage SDK for .NET.
Question 69Question →

You are configuring a custom domain `www.contoso.com` for an Azure App Service web app named `app-prod-west`. You must secure the custom domain by using a free App Service Managed Certificate. Which sequence of steps should you perform to complete the configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, create a CNAME record mapping the domain to the app's default host name. Second, add the custom domain to the App Service web app. Third, create a free App Service Managed Certificate. Finally, create a TLS/SSL binding associating the domain with the certificate.
To secure a custom domain using an App Service Managed Certificate, the domain must first be pointed to the web app's default URL via DNS. Once the DNS propagates, you register the custom domain in the App Service. After registration, Azure can issue the managed certificate for that validated domain. Finally, you bind the domain to the certificate to enable HTTPS traffic.

Step-by-Step Solution

1
Configure DNS mapping
The DNS registrar has a CNAME record mapping `www.contoso.com` to `app-prod-west.azurewebsites.net`.
Azure App Service must verify domain ownership via external DNS queries before allowing registration.
2
Register the domain on Azure
The domain is successfully validated and added to the Custom Domains blade of the web app.
The web app must be configured to accept and route requests coming from the custom host name.
3
Generate the managed certificate
Azure generates and renews a free App Service Managed Certificate for the domain.
The certificate can only be issued once Azure can verify that the custom domain resolves to the App Service web app.
4
Apply TLS/SSL binding
The custom domain is configured with SNI SSL using the managed certificate, securing HTTPS traffic.
Applying the binding completes the setup and secures incoming traffic on port 443.

Key Concept

Configuring custom domains and securing them with App Service Managed Certificates in Azure App Service.
Question 70Question →

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 71Question →

You have an existing Azure Function App (V4 runtime) that uses a standard connection string for the host storage account configuration (AzureWebJobsStorage). To comply with security policies, you must migrate the Function App to use an identity-based connection instead of connection secrets.

Which sequence of steps should you perform to configure the Function App to use a system-assigned managed identity for its host storage?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the Function App to use a system-assigned managed identity for host storage, first enable the system-assigned managed identity on the Function App. Next, assign the Storage Blob Data Owner, Storage Queue Data Contributor, and Storage Table Data Contributor roles to the managed identity. Then, add the AzureWebJobsStorage__accountName application setting to the Function App configuration. Finally, delete the connection string value named AzureWebJobsStorage from the Function App application settings.
The correct sequence begins with enabling the system-assigned managed identity to generate the service principal ID. Once the principal is created, the required Azure RBAC roles must be assigned to grant the identity access to the storage account. The configuration settings must then be updated by adding the AzureWebJobsStorage__accountName setting to specify the target storage account name. Finally, the legacy AzureWebJobsStorage connection string setting must be deleted, as connection string settings take precedence over identity-based configurations.

Step-by-Step Solution

1
Enable a system-assigned managed identity on the Function App.
A system-assigned managed identity principal is created in Microsoft Entra ID for the Function App.
An identity principal must exist in Microsoft Entra ID before it can be assigned Azure role-based access control (RBAC) roles.
2
Assign Storage Blob Data Owner, Storage Queue Data Contributor, and Storage Table Data Contributor roles to the managed identity.
The identity principal is granted permission to read, write, and manage blobs, queues, and tables within the storage account.
The Azure Functions host runtime requires specific permissions to coordinate executions, manage leases, and log data. These roles must be assigned before removing connection secrets to prevent runtime initialization failures.
3
Add the application setting AzureWebJobsStorage__accountName to the Function App.
The setting instructs the Functions runtime to connect to the specified storage account using the identity.
Specifying the accountName tells the host to locate the target storage account and use the default credential flow (system-assigned managed identity) to establish the connection.
4
Delete the AzureWebJobsStorage connection string setting.
The legacy connection string containing secrets is removed from the Function App.
If the legacy AzureWebJobsStorage setting is left in place, it takes precedence over the identity-based configuration, and the app will continue to use the connection string secret.

Key Concept

Configuring Azure Functions host storage with identity-based connections using system-assigned managed identity.
Estimated Time:2m 0s
Question 72Question →

You are developing a .NET application using the Azure.Storage.Blobs SDK to update the custom metadata of an existing block blob. To prevent concurrent writes and ensure that no existing metadata is lost, you must acquire an exclusive-write lease, retrieve the current metadata, append a new key-value pair, save the changes, and release the lease. Which sequence of steps should you perform to complete this process securely and without data loss?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first acquire the lease using the lease client, then retrieve the properties using the blob client, modify the metadata dictionary, upload the updated metadata by passing the lease ID in the request conditions, and finally release the lease.
The correct sequence ensures that the blob is locked before any reads or writes occur, preventing dirty reads or lost updates. By acquiring the lease first, we guarantee that the metadata we retrieve is current and cannot be modified by any other client. Modifying the dictionary in memory preserves the existing keys because SetMetadataAsync replaces the entire metadata collection. Finally, passing the lease ID during the set operation is mandatory for leased blobs, and releasing the lease makes the blob available to others.

Step-by-Step Solution

1
Acquire the lease.
The blob is locked for exclusive-write access by this client.
Acquiring the lease first prevents race conditions by locking the resource before any read or write operation is initiated.
2
Retrieve current metadata.
The current metadata dictionary is read from the leased blob.
Reading the metadata while the lease is active guarantees that the metadata retrieved is the latest and cannot be changed by other processes before we write our updates.
3
Modify the metadata dictionary.
The local metadata dictionary is updated with the new key-value pair.
Since SetMetadataAsync overwrites all existing metadata on the blob, the modification must be done locally on the retrieved dictionary to preserve existing entries.
4
Write the updated metadata back to the blob.
The metadata on Azure Blob Storage is updated.
The write operation must include the lease ID in BlobRequestConditions to authorize the modification on the locked blob.
5
Release the lease.
The blob is unlocked.
The lease must be explicitly released so that other clients and processes can perform modifications on the blob.

Key Concept

To safely modify a leased blob's metadata without data loss or race conditions, you must acquire the lease, retrieve properties, modify the dictionary, write the metadata back using the lease ID, and then release the lease.
Question 73Question →

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 74Question →

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 75Question →

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 76Question →

A developer is configuring a data retention policy for a Standard General Purpose v2 (GPv2) storage account. The goal is to automatically transition specific blobs to the Archive tier when they are no longer actively needed. The developer plans to identify target blobs using the index tag `ArchiveStatus = 'Pending'`. Which sequence of steps must the developer perform to configure, apply, and verify this lifecycle management policy?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure and verify the lifecycle management policy, you must first apply the case-sensitive blob index tag to the target blobs. Next, create a local JSON policy file defining a rule with a matching tag filter and a transition action. Then, run the CLI command to apply this policy. Allow up to 2424 hours for the platform's daily run to execute. Finally, query the properties of the blobs to confirm the access tier has transitioned to Archive.
The correct sequence begins with preparing the blobs by tagging them, as they must exist with index tags before evaluation. Then, the JSON policy document must be authored with a `blobIndexMatch` rule. The policy is applied to the Standard GPv2 storage account using `az storage account management-policy create`. Since execution occurs on a daily schedule, the developer must wait up to 2424 hours for the run to complete. Finally, the developer queries the blobs to verify the transition to the Archive tier.

Step-by-Step Solution

1
Tag the target blobs with the index tag `ArchiveStatus` set to `Pending`.
The blobs are indexed and searchable by the lifecycle management service.
The lifecycle service relies on these index tags to match the blob selection criteria during the policy run.
2
Create a JSON policy file defining the rules, filters, and actions.
A valid configuration document that includes the `blobIndexMatch` filter and the `tierToArchive` action.
The policy engine requires a JSON structure matching the Azure Storage lifecycle schema.
3
Apply the policy to the storage account using the Azure CLI command `az storage account management-policy create`.
The lifecycle policy is successfully bound to the Standard GPv2 storage account.
The configuration must be uploaded to the Azure Resource Manager to take effect.
4
Wait for the platform's scheduled execution run.
The platform processes the applied policy on all matching blobs in the storage account.
Lifecycle management policies are executed once every 2424 hours by the Azure platform.
5
Query the access tier of the blobs.
The metadata returns the access tier as Archive.
Confirming the metadata state change verifies that the policy was successfully executed.

Key Concept

Azure Blob Storage Lifecycle Management policy configuration, application, and scheduled execution cycles using index tag filters and Azure CLI.
Question 77Question →

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 78Question →

You are developing a C# console application that processes IoT telemetry using the Azure Cosmos DB .NET SDK v3.

The application must connect to a database named `TelemetryDb` and a container named `DeviceData`. The container's partition key path is set to `/deviceId`.

You need to write code to retrieve a single telemetry reading document with an ID of `device-reading-101` and a partition key value of `device-id-55`.

Arrange the following steps in the correct order to configure the SDK, execute the point read operation, and retrieve the deserialized telemetry data.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To retrieve the telemetry data, you must first initialize a CosmosClient. Then, call GetDatabase to get a Database reference, and call GetContainer on that database to get a Container reference. Execute the point read by calling ReadItemAsync on the container with the item ID and the PartitionKey. Finally, retrieve the deserialized object by accessing the Resource property of the response.
The correct order follows the logical hierarchy of the Azure Cosmos DB SDK v3: first, a CosmosClient is initialized to manage connections; then, a Database reference is retrieved; next, a Container reference is obtained; after that, ReadItemAsync is called on the container using the document's ID and its partition key; finally, the Resource property of the response is accessed to get the deserialized entity.

Step-by-Step Solution

1
Initialize CosmosClient
A thread-safe, singleton client instance connected to Azure Cosmos DB
The CosmosClient acts as the entry point to the Azure Cosmos DB service and maintains connection pools.
2
Obtain Database reference
A Database object representing TelemetryDb
You must navigate the hierarchy from client to database before referencing a container.
3
Obtain Container reference
A Container object representing DeviceData
Item operations are executed against a specific Container object, which is a child of the database.
4
Call ReadItemAsync
An ItemResponse containing the status and payload of the read
The point read must be executed by passing both the item ID and the partition key value as a PartitionKey object.
5
Access Resource property
The deserialized DeviceReading object
The ItemResponse contains metadata and headers; the actual document payload is accessed via the Resource property.

Key Concept

Point read operations using the Azure Cosmos DB .NET SDK v3 hierarchy
Estimated Time:2m 0s
Question 79Question →

You are designing a secure, event-driven solution in Azure. You have an Event Grid custom topic and a Webhook endpoint. You must route events from the custom topic to the Webhook endpoint.

To ensure reliability and security, you must meet the following requirements:
- If event delivery to the Webhook fails, events must be dead-lettered to an Azure Storage blob container.
- Event Grid must write the dead-letter events to the container using a system-assigned managed identity.
- The subscription must be successfully validated.

Which four actions should you perform in sequence to configure the solution? 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

First, enable a system-assigned managed identity on the Event Grid custom topic. Second, assign the Storage Blob Data Contributor role to the custom topic's managed identity on the destination storage account. Third, configure the Webhook endpoint to parse the incoming JSON array and return the validationCode from the subscription validation request. Finally, create the Event Grid subscription, specifying the Webhook endpoint, the storage container for dead-lettering, and configuring the subscription to use the custom topic's identity for dead-letter delivery.
To set up the scenario securely and reliably, you must follow a dependency chain. First, you enable a system-assigned managed identity on the Event Grid custom topic so that the security principal exists in Microsoft Entra. Second, you assign the Storage Blob Data Contributor role to that newly created identity on the storage account, ensuring the permission is active. Third, you configure the Webhook endpoint application to handle the subscription validation handshake. Finally, you create the Event Grid subscription, which triggers both the synchronous Webhook handshake and the dead-letter write validation using the configured managed identity.

Step-by-Step Solution

1
Enable a system-assigned managed identity on the Event Grid custom topic.
A Microsoft Entra security principal is generated for the custom topic resource.
You must establish the identity principal before you can assign RBAC permissions to it.
2
Assign the Storage Blob Data Contributor role to the custom topic's managed identity on the storage account.
The identity principal is granted write permissions on the storage account blob service.
During the creation of the event subscription, Azure Event Grid performs a write validation check against the dead-letter destination. If the role is not already assigned, subscription creation will fail.
3
Configure the Webhook endpoint to parse the incoming JSON array and return the validationCode from the subscription validation request.
The Webhook application is ready to respond to Event Grid's validation handshake.
When the event subscription is created, Event Grid sends a synchronous HTTP POST validation request. If the endpoint does not return the code, the subscription fails to create.
4
Create the Event Grid subscription, specifying the Webhook endpoint, the storage container for dead-lettering, and configuring the subscription to use the custom topic's identity for dead-letter delivery.
The event subscription is created, the validation handshake completes successfully, and dead-lettering is secured.
This registers the subscription in Azure and initiates the synchronous validation and dead-letter permissions validation checks.

Key Concept

Azure Event Grid custom topic subscription lifecycle, including managed identities for dead-lettering and endpoint validation handshakes.
Estimated Time:3m 0s
Question 80Question →

An organization requires developer portal authentication for an Azure API Management (APIM) instance using Microsoft Entra ID. To implement this, you must configure the trust relationship between Microsoft Entra ID and the APIM developer portal. What is the correct sequence of steps to configure this identity provider and make it available to portal users?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with registering the app in Microsoft Entra ID, adding the provider to API Management, retrieving the redirect URL, configuring the redirect URL in Microsoft Entra ID, and finally publishing the developer portal.
The correct sequence follows the logical dependency flow: first, create the identity credentials by registering the application in Microsoft Entra ID. Second, input these credentials into the API Management identity provider configuration, which generates the instance-specific redirect URL. Third, retrieve this redirect URL from API Management. Fourth, configure the application registration in Microsoft Entra ID with the retrieved redirect URL to authorize authentication responses. Lastly, publish the developer portal so that the changes are compiled and the login option becomes active for users.

Step-by-Step Solution

1
Register the application in Microsoft Entra ID.
The Application ID and a client secret are generated.
Establishing the app registration creates the security principal and credentials that APIM will use to authenticate with Entra ID.
2
Add the Microsoft Entra ID identity provider in APIM.
The identity provider is configured, and a redirect URL is generated in the APIM portal.
This links the APIM developer portal to the Entra ID tenant using the credentials registered in the first step.
3
Retrieve the generated redirect URL from the APIM portal.
The redirect URL is copied to the clipboard.
The redirect URL is dynamic and instance-specific, meaning it must be captured from APIM to register it with Entra ID.
4
Add the redirect URL to the Entra ID app registration.
The app registration is updated to allow redirects to the APIM developer portal sign-in endpoint.
For security reasons, Entra ID will only send authentication tokens to pre-authorized redirect URIs.
5
Publish the APIM developer portal.
The portal is compiled and refreshed for visitors.
Any changes to identity providers, designs, or APIs are not visible to users in the developer portal until the portal is explicitly published.

Key Concept

Configuring Microsoft Entra ID authentication for the Azure API Management Developer Portal
PreviousPage 4 / 9Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin