Examkin

All practice questions

171 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 1Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

You are developing a C# background service that consumes events from an Azure Event Hub. The service must use the EventProcessorClient class from the Azure.Messaging.EventHubs.Processor library and utilize Azure Blob Storage for checkpointing and load balancing.

Which sequence of actions must you perform in your C# code to properly configure, run, and cleanly terminate the event processor?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To implement the EventProcessorClient lifecycle, you must first instantiate a BlobContainerClient, then pass it to initialize the EventProcessorClient, next bind delegate handlers to the ProcessEventAsync and ProcessErrorAsync properties, then invoke StartProcessingAsync to start processing, and finally call StopProcessingAsync to gracefully shut down the consumer.
The correct order follows the standard lifecycle of EventProcessorClient initialization and operation. You must first create the storage client since the event processor client depends on it. Once the processor is instantiated, handlers must be registered before the client is started. Finally, the client must be stopped cleanly when shutting down.

Step-by-Step Solution

1
Create the BlobContainerClient instance.
A client reference to the Azure Blob Storage container is established.
The EventProcessorClient constructor requires an object implementing the CheckpointStore pattern, which is fulfilled by BlobContainerClient.
2
Construct the EventProcessorClient.
The EventProcessorClient is initialized with the connection string, hub name, consumer group, and storage client.
This establishes the client with the configuration metadata needed to coordinate with other instances.
3
Assign event and error handlers.
The processor is configured to invoke user code on receiving events or encountering errors.
The processor client will fail to start if the ProcessEventAsync and ProcessErrorAsync handlers are not registered.
4
Invoke StartProcessingAsync.
The background processing threads start, partition ownership is balanced, and event reading commences.
This initiates the active processing lifecycle of the consumer.
5
Invoke StopProcessingAsync.
Events stop being processed, partition ownership is released, and connections are closed.
This ensures a graceful shutdown without leaving stale partition leases in blob storage.

Key Concept

Lifecycle of EventProcessorClient with Blob Storage Checkpointing
Question 3Question →

You are developing a C# application that must send a batch of telemetry messages to an Azure Service Bus topic. You are using the Azure.Messaging.ServiceBus SDK. To ensure efficient network usage, you decide to send the messages in a single batch. Move the steps required to initialize the client, construct the batch, send the messages, and clean up resources into the correct chronological order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first initialize the ServiceBusClient, then create the ServiceBusSender, followed by calling CreateMessageBatchAsync to prepare the batch. Next, add the messages using TryAddMessage, send the batch using SendMessagesAsync, and finally dispose of the sender and client.
The correct workflow requires establishing the client connection first, obtaining a sender, initializing a size-bounded batch, adding messages safely to that batch, calling the asynchronous send method, and then cleaning up the connection resources.

Step-by-Step Solution

1
Instantiate ServiceBusClient
A ServiceBusClient object is initialized.
The client is required to connect to the namespace.
2
Create ServiceBusSender
A ServiceBusSender object is created.
The sender is required to send messages to the topic.
3
Initialize ServiceBusMessageBatch
A ServiceBusMessageBatch object is created.
The batch ensures the overall message sizes do not exceed service limits.
4
Add messages via TryAddMessage
Messages are added to the batch.
This safely checks size limits before sending.
5
Call SendMessagesAsync
The batch is sent.
Transmits the batch of messages in one network operation.
6
Dispose of client and sender
Resources are freed.
Prevents connection leaks and cleans up AMQP channels.

Key Concept

Message batching using the Azure.Messaging.ServiceBus C# SDK
Estimated Time:1m 30s
Question 4Question →

You have an Azure App Service web app named app-contoso that runs in a Standard App Service plan. You need to configure a custom domain www.contoso.com for the web app and secure the domain using a free Azure App Service Managed Certificate.

Which four actions should you perform in sequence? 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 actions is: 1) Create a CNAME record with the DNS provider that maps the custom domain to the default web app domain. 2) Add the custom domain to the App Service web app. 3) Create an App Service Managed Certificate for the custom domain. 4) Add a TLS/SSL binding using the managed certificate and SNI SSL.
The correct sequence respects the dependency chain of Azure App Service domain configuration. First, the DNS record must be mapped to allow verification. Second, the domain is added to the web app using that verification. Third, the managed certificate is generated for the registered domain. Finally, the certificate is bound to the domain to secure the traffic using SNI.

Step-by-Step Solution

1
Configure the DNS CNAME record mapping the subdomain to the web app's default URL.
The domain registrar or DNS server points traffic and validation requests to Azure.
Azure App Service requires verification of domain ownership before allowing a custom domain to be mapped.
2
Add the custom domain to the web app configuration in Azure App Service.
Azure verifies the CNAME record and registers the custom domain under the web app.
You cannot generate certificates or bindings for a custom domain that has not been mapped to the App Service web app.
3
Generate a free App Service Managed Certificate for the verified custom domain.
Azure provisions a free certificate for the custom domain.
The custom domain must already be validated and bound to the web app before Azure can issue a managed certificate for it.
4
Configure a TLS/SSL binding on the custom domain using the managed certificate.
The web app secures HTTPS traffic on the custom domain via SNI SSL.
Creating the certificate does not automatically secure the domain; you must bind the certificate to the domain to complete the setup.

Key Concept

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

You are setting up a secure continuous integration (CI) pipeline to build and publish container images to an Azure Container Registry (ACR) named `acr2026`.

The pipeline must authenticate using an Azure Active Directory service principal named `sp-pipeline`. The service principal has just been created and has no permissions assigned.

You need to configure permissions, authenticate the pipeline runner, build a local image, and upload the image.

In which order should you perform the steps? To answer, arrange the actions in the correct sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps requires you to first assign the AcrPush role to the service principal. Next, log in to the registry using the docker login command with the service principal credentials and the registry's login server name (acr2026.azurecr.io). After authenticating, build the image locally with the docker build command, tag the image with the registry's namespace using the docker tag command, and finally push the tagged image to the registry with the docker push command.
To push an image to Azure Container Registry using a service principal, you must first authorize the principal with the AcrPush role. Next, authenticate Docker using the service principal's application ID and client secret against the registry login server. Then, build the image locally, tag it with the target registry's login server namespace, and finally push it.

Step-by-Step Solution

1
Assign the AcrPush role to the service principal.
The service principal is authorized to push images to the registry.
By default, a new service principal has no access. Pushing images requires the AcrPush role.
2
Run docker login targeting the registry's login server with the service principal credentials.
The Docker client on the runner is authenticated to the registry.
Docker CLI commands like docker push require authentication to the registry's specific login server.
3
Run docker build to build the image locally.
A local container image is created.
The image must exist locally before it can be tagged or pushed.
4
Run docker tag to apply the registry namespace to the image.
The image is tagged with the fully qualified registry login server path.
Docker uses the image tag prefix to determine the target registry domain during a push operation.
5
Run docker push with the fully qualified tag.
The image is uploaded and stored in the Azure Container Registry.
This is the final action that uploads the local image layers to the authenticated registry endpoint.

Key Concept

Building and pushing container images to Azure Container Registry using service principal authentication and Docker CLI.
Question 6Question →

You need to configure local Git deployment for a new Azure App Service web app. Which sequence of steps should you perform? 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, configure subscription-level deployment credentials with `az webapp deployment user set`. Second, enable local Git deployment on the web app using `az webapp deployment source config-local-git` to obtain the clone URL. Third, add the clone URL as a local remote named `azure` using `git remote add`. Finally, deploy the application code by running `git push azure main`.
The correct sequence begins by configuring subscription-level credentials with `az webapp deployment user set`. Once credentials are set, the next step is to enable local Git deployment on the target web app using `az webapp deployment source config-local-git`, which provides the Git repository clone URL. This URL is then added as a remote endpoint to the local Git repository using `git remote add azure`. Finally, the application code is deployed by pushing the local branch to the remote using `git push azure main`.

Step-by-Step Solution

1
Run the command `az webapp deployment user set --user-name <username> --password <password>`.
Subscription-level deployment credentials are created or updated.
Azure App Service local Git deployment requires authentication credentials configured at the subscription level to authenticate the push operation.
2
Run the command `az webapp deployment source config-local-git --name <app-name> --resource-group <group-name>`.
Local Git deployment is enabled for the web app, and the Git repository URL is returned.
This establishes the remote Git endpoint inside Azure App Service for receiving deployments.
3
Run the command `git remote add azure <git-clone-url>` locally.
The local Git repository is configured with a new remote target named `azure`.
This registers the Azure repository endpoint as a remote branch source inside the local Git repository.
4
Run the command `git push azure main` locally.
The code is transferred, built, and deployed to the Azure App Service web app.
Pushing the commits to the `azure` remote triggers the server-side deployment engine (Kudu) to deploy the app.

Key Concept

Configuring local Git deployment for an Azure App Service web app requires setting deployment credentials, enabling the Git repository on the web app, configuring a local git remote pointing to the Azure Git URL, and pushing the code to trigger the build.
Question 7Question →

You are developing a secure serverless solution using Azure Functions V4. You need to configure a Function App to retrieve a database connection string from an Azure Key Vault. The security team requires that you use a user-assigned managed identity rather than a system-assigned managed identity to access the Key Vault secrets.

Which five actions should you perform in sequence to configure the Function App? 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

To configure the Function App to use a user-assigned managed identity for Key Vault references, you must first create a user-assigned managed identity in Microsoft Entra ID. Next, associate the user-assigned managed identity with the Function App. Then, create an access policy or RBAC role assignment in Key Vault granting the identity Secret Get permissions. After that, set the keyVaultReferenceIdentity configuration of the Function App to the resource ID of the user-assigned identity. Finally, create a new application setting in the Function App using the @Microsoft.KeyVault reference syntax.
The correct sequence of steps requires first creating the user-assigned managed identity and associating it with the Function App. Then, the identity must be granted Secret Get permissions in the Key Vault. To ensure that Key Vault references resolve using this user-assigned identity instead of the default system-assigned identity, the Function App's configuration must be updated to specify the user-assigned identity as the key vault reference identity. Finally, the application setting is created using the Key Vault reference syntax, which allows the Function App to load the database connection string securely.

Step-by-Step Solution

1
Create a user-assigned managed identity.
A managed identity resource is created in Microsoft Entra ID with a client ID and principal ID.
The identity is needed as the security principal that will be assigned permissions and associated with the Function App.
2
Associate the identity with the Function App.
The Function App is updated to include the user-assigned managed identity.
This allows the Function App to authenticate using this specific identity.
3
Configure Key Vault access permissions.
An access policy or Azure RBAC role assignment is created in the Key Vault allowing the user-assigned identity's principal to perform Get operations on secrets.
The identity must have permission to read the secret; otherwise, Key Vault reference resolution will fail.
4
Set the Key Vault reference identity for the Function App.
The Function App's configuration is updated with keyVaultReferenceIdentity set to the resource ID of the user-assigned managed identity.
By default, Azure Functions attempts to resolve Key Vault references using the system-assigned identity. To use a user-assigned identity, you must explicitly configure this setting.
5
Create the application setting with Key Vault reference syntax.
The application setting is added to the Function App using the format @Microsoft.KeyVault(SecretUri=...).
This triggers the Azure Functions host to automatically fetch the secret from Key Vault and inject it into the app environment settings.

Key Concept

Configuring Azure Functions to retrieve Key Vault secrets using a User-Assigned Managed Identity
Question 8Question →

You are configuring an Azure Function App (Runtime version 4.x) to securely retrieve database credentials from Azure Key Vault. Security guidelines require the following constraints:
- You must use a user-assigned managed identity.
- You must not enable or use a system-assigned managed identity.
- The Azure Functions hosting platform must natively resolve the secrets without custom code.
- The configuration must follow the principle of least privilege, ensuring no intermediate state exposes unresolved secrets to the application runtime or results in service resolution failures.

In which order should you execute the configuration steps to successfully enable the Function App to resolve the Key Vault secrets?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first create the user-assigned managed identity, associate it with the Function App, grant it the Key Vault Secrets User role on the Key Vault, configure the keyVaultReferenceIdentity property of the Function App to use this identity, and finally add the application setting using the Key Vault reference syntax.
To resolve Key Vault references using a user-assigned managed identity, the identity must first exist. It then must be associated with the Function App. Granting Key Vault Secrets User permissions ensures that the identity can retrieve the secret. The keyVaultReferenceIdentity property must be configured to point to this identity before the application setting is created. If the application setting is added first, the platform will attempt to resolve the reference using either the system-assigned identity (which is disabled) or will fail to resolve because it does not know which user-assigned identity to use.

Step-by-Step Solution

1
Create the user-assigned managed identity.
A new user-assigned managed identity is provisioned in Microsoft Entra ID.
An identity must exist in Microsoft Entra ID before it can be assigned permissions or associated with any Azure resources.
2
Associate the user-assigned managed identity with the Function App.
The Function App's identity block is updated to include the user-assigned managed identity.
The identity must be associated with the Function App resource so that Azure's hosting platform recognizes it as a valid identity for the app.
3
Grant the user-assigned managed identity the 'Key Vault Secrets User' role on the Key Vault.
An RBAC role assignment is created, allowing the identity to read secrets from the Key Vault.
By default, identities have no permissions to access Key Vault secrets. This step ensures the identity has the necessary read access.
4
Set the 'keyVaultReferenceIdentity' property on the Function App to the resource ID of the user-assigned identity.
The Function App site configuration is updated to designate this specific identity for resolving Key Vault references.
By default, Azure Functions attempts to resolve Key Vault references using the system-assigned identity. Since only a user-assigned identity is used here, the platform must be explicitly told which identity to use.
5
Add the application setting using the @Microsoft.KeyVault(SecretUri=...) syntax.
The application setting is added, and the Azure Functions runtime resolves the secret value at startup.
Once all security, identity, and routing configurations are in place, the application setting can be safely added to trigger resolution without errors.

Key Concept

Configuring Azure Functions to retrieve app settings securely using User-Assigned Managed Identity and Key Vault References.
Question 9Question →

You are developing a new HTTP-triggered Azure Function locally using the Azure Functions Core Tools. You need to initialize a local project, create a new function within the project, and then publish it to an existing Function App in Azure. In which sequence should you perform the command-line steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, initialize the project with `func init`. Second, create the function inside the project with `func new`. Third, deploy the project to Azure with `func azure functionapp publish <AppName>`.
The correct sequence begins with initializing the local project workspace, followed by adding a new function from a template, and finally publishing the project files to the Azure Function App service.

Step-by-Step Solution

1
Initialize the local workspace using the Core Tools CLI.
A local project folder containing configuration files like host.json is created.
All Azure Functions must belong to a project container, which manages settings and runtime configuration.
2
Add a function to the initialized project folder.
A template-based function file matching the selected trigger is generated.
You cannot publish an empty project without at least one function defined inside it.
3
Publish the completed local project to Azure.
The local project is zipped and sent to the target Function App resource.
This transfers your locally tested code and configurations into your live Azure subscription.

Key Concept

Developing and deploying Azure Functions locally using Azure Functions Core Tools
Question 10Question →

You need to configure an Azure App Service web app to retrieve application settings securely from an Azure Key Vault secret using a system-assigned managed identity. Which sequence of steps should you perform to complete this configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the retrieval of settings using a system-assigned managed identity, first enable the identity on the App Service web app to register its principal. Next, create a Key Vault access policy or role assignment that grants the identity Secret Get permissions. Finally, configure the web app's application settings using the Key Vault reference syntax.
The system-assigned managed identity must first be created on the App Service web app so its principal ID exists. Then, this principal must be granted Secret Get permissions in Key Vault. Finally, the application setting containing the Key Vault reference syntax is configured to successfully retrieve the secret.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the web app.
The identity principal is created in Microsoft Entra ID.
This identity is required so that you have a security principal to which Key Vault permissions can be assigned.
2
Assign Secret Get permissions to the identity in Key Vault.
The identity is authorized to retrieve the secrets.
Without this authorization, the Key Vault service will reject any access attempts made by the App Service.
3
Add an application setting in the web app referencing the Key Vault secret.
The App Service retrieves the secret and exposes it as an environment variable.
Using the `@Microsoft.KeyVault` syntax in the app settings directs the App Service runtime to fetch the secret securely.

Key Concept

Integrating App Service Web Apps with Azure Key Vault using system-assigned managed identities.
Question 11Question →

You need to configure an automated build and push process for a containerized application using Azure Container Registry (ACR) Tasks. The process must trigger automatically whenever source code in a private GitHub repository is updated. Which sequence of steps should you perform to create and verify the triggered build task?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure and verify the triggered task, first generate a GitHub Personal Access Token (PAT) with repository and hook permissions. Next, create the task using the 'az acr task create' command with the PAT. Then, manually run the task using the 'az acr task run' command to verify the build configuration. Finally, push a commit to the GitHub repository to verify that the automated trigger functions correctly.
The correct order requires generating a GitHub Personal Access Token (PAT) first, since the token must be supplied during task creation to register the webhook. The task must then be created with 'az acr task create'. Testing the build with 'az acr task run' ensures that the build configuration is correct before verifying the automated webhook trigger by pushing a code change.

Step-by-Step Solution

1
Generate a Personal Access Token in GitHub
A token with the 'repo' and 'admin:repo_hook' scopes is generated.
This token allows ACR to read private repository content and configure the automated trigger webhook.
2
Run the 'az acr task create' command
An ACR task is created and a webhook is added to the GitHub repository.
This establishes the build task mapping and sets up the event listener for code changes.
3
Run the 'az acr task run' command
The build task runs manually and builds the container image in ACR.
This isolates and verifies that the Dockerfile and task parameters are fully functional.
4
Commit and push code changes to GitHub
The commit triggers a webhook, which starts an ACR task run automatically.
This tests the end-to-end automation of the trigger.

Key Concept

Automating container image builds with Azure Container Registry Tasks and GitHub commit triggers.
Question 12Question →

You are developing a Go-based web service that needs to be hosted as an Azure Function. You plan to use a custom handler. You need to configure your local project environment for the custom handler before deploying it to Azure. Which four actions should you perform in sequence to set up the project? 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

Initialize the project using `func init --worker-runtime custom`, compile the Go application to an executable binary, configure the `host.json` file with the `customHandler` section pointing to the binary, and create a function folder with a `function.json` file to define triggers and bindings.
To set up an Azure Function custom handler, you first initialize the project environment with a custom worker runtime. Next, you compile your web server application code into an executable binary. You then configure the `host.json` file's `customHandler` section, specifying the path to the executable. Finally, you create a function folder and define the bindings in a `function.json` file.

Step-by-Step Solution

1
Run `func init` with custom runtime.
Creates the base configuration files like `host.json` and `local.settings.json` configured for a custom handler.
This establishes the project framework before adding custom handler code.
2
Compile Go code to an executable binary.
Generates the binary file that the Functions runtime will launch.
Custom handlers require a compiled binary or process to handle requests from the Functions host.
3
Configure the `customHandler` block in `host.json`.
Updates the Functions host configuration so it points to the executable binary.
The Functions host must know the path of the executable via `defaultExecutablePath` to launch it.
4
Create function folder with `function.json`.
Registers the function endpoints and their bindings within the Functions host.
Each endpoint must have its own directory containing a `function.json` metadata file to describe the input triggers and output bindings.

Key Concept

Azure Functions Custom Handlers configures the host to forward events to a lightweight web server executable via the host.json configuration and function.json trigger definitions.
Question 13Question →

You are configuring a multi-registry container build workflow in Azure. You have a main Azure Container Registry (ACR) named `prodacr` where you want to build and store application images, and a secured ACR named `sharedacr` that hosts the base images.

You need to configure an ACR task named `AppBuildTask` in `prodacr` to build an image from a GitHub repository. The build process must pull the base image from `sharedacr` using the task's system-assigned managed identity.

Which sequence of steps should you perform to configure the task?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, create the task with a system-assigned managed identity. Second, retrieve the principal ID of the identity. Third, assign the AcrPull role to the identity at the scope of the base registry. Fourth, add the base registry credentials to the task using the system-assigned identity.
The correct order establishes the identity during task creation, retrieves its principal ID, authorizes it to pull from the base registry, and configures the task credentials to use that identity.

Step-by-Step Solution

1
Run `az acr task create` with the `--assign-identity` parameter.
The task is created and the system-assigned managed identity is provisioned.
System-assigned identities are tied to the resource lifecycle, meaning the task must exist before the identity can be referenced or assigned roles.
2
Run `az acr task show` querying `identity.principalId`.
The security principal ID (object ID) of the managed identity is retrieved.
This ID is necessary to bind Azure RBAC roles to the identity in subsequent steps.
3
Run `az role assignment create` assigning the `AcrPull` role to the principal ID at the scope of `sharedacr`.
The identity is authorized to pull images from the base registry.
ACR Tasks require explicit read access to retrieve base images from registries other than the one hosting the task.
4
Run `az acr task credential add` specifying the base registry login server and using `[system]` for the identity.
The registry credentials configuration is added to the task definition.
This instructs the ACR Task to use the system-assigned identity to authenticate against the specified login server during run execution.

Key Concept

ACR Tasks cross-registry authentication using system-assigned managed identities
Estimated Time:3m 0s
Question 14Question →

You are configuring a custom domain named `www.contoso.com` for an Azure App Service web app named `app-prod-westus`. You need to secure the custom domain using a free App Service Managed Certificate.

Which sequence of actions should you perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, create a DNS CNAME record pointing `www.contoso.com` to the default Azure Web Apps URL. Second, add the custom hostname `www.contoso.com` to the web app. Third, generate the free App Service Managed Certificate for the domain. Finally, bind the generated certificate to the custom hostname using SNI SSL.
To secure an App Service web app with a custom domain using a free App Service Managed Certificate, you must perform these steps in order. First, configure the DNS CNAME record pointing to the app's default hostname to allow ownership verification. Second, register the custom domain on the App Service. Third, request the managed certificate for the custom domain. Finally, bind the issued certificate to the hostname using SNI SSL.

Step-by-Step Solution

1
Create the CNAME record pointing `www.contoso.com` to `app-prod-westus.azurewebsites.net` in your domain registrar's DNS zone.
The DNS record propagates, allowing Azure to resolve and verify the domain name.
Azure App Service requires domain ownership verification before the hostname can be registered in the App Service instance.
2
Run `az webapp config hostname add` to add `www.contoso.com` to the web app.
The custom hostname is registered on the web app.
You must associate the domain with the app first. Free App Service Managed Certificates can only be issued for hostnames that are already bound to the App Service web app.
3
Run `az webapp config ssl create` to generate the free App Service Managed Certificate for `www.contoso.com`.
An App Service Managed Certificate is issued for the domain, and its thumbprint is returned.
The certificate must exist in the App Service environment before it can be bound to the custom domain.
4
Run `az webapp config ssl bind` using the certificate thumbprint, specifying `SNI` as the SSL type.
The SSL binding is configured, securing incoming traffic to `www.contoso.com`.
An SSL binding is required to associate the certificate with the hostname and enable HTTPS.

Key Concept

Azure App Service custom domain verification and free App Service Managed Certificate lifecycle management.
Question 15Question →

An organization is configuring an existing Linux-based Azure Function App named `contosofn` running on an Elastic Premium plan to deploy and pull its custom container image from a private Azure Container Registry (ACR) named `contosoacr`. You have created a user-assigned managed identity named `fn-pull-identity`. You must configure `contosofn` to pull the custom image from `contosoacr` using `fn-pull-identity`. 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

Associate the user-assigned managed identity with the Function App, assign the AcrPull role to the identity at the registry scope, configure the AcrUseManagedIdentityCreds and AcrUserManagedIdentityID app settings, and then update the container image configuration.
To configure a containerized Azure Function to pull from a private ACR using a user-assigned managed identity, you must first register the identity with the resource, authorize the identity at the source registry using the AcrPull role, configure the application settings to use the identity (AcrUseManagedIdentityCreds = true and AcrUserManagedIdentityID = client ID), and finally set the image setting. Setting the image setting triggers the image pull, so the authorization infrastructure must be fully set up beforehand.

Step-by-Step Solution

1
Associate the user-assigned identity with the Function App resource.
The Function App resource is aware of the user-assigned managed identity and can request tokens on its behalf.
Before the identity can be used by the function runtime or reference client IDs in settings, it must be linked to the resource.
2
Assign the AcrPull role to the user-assigned identity at the scope of the container registry.
The identity is authorized to pull container images from the Azure Container Registry.
Access control must be granted before the platform tries to pull the image to avoid authorization errors.
3
Add the AcrUseManagedIdentityCreds and AcrUserManagedIdentityID app settings to the Function App.
The deployment engine is configured to use the managed identity for registry pulls.
Setting AcrUseManagedIdentityCreds to true and specifying the client ID via AcrUserManagedIdentityID directs the App Service platform to request tokens for the target identity.
4
Update the container image settings on the Function App.
The Function App deploys the new container image.
Updating the container image triggers the platform deployment engine to pull the target image. This must occur last so that permissions and settings are already active.

Key Concept

Configuring identity-based container deployment for Azure Functions using user-assigned managed identities.
Question 16Question →

You need to deploy a containerized application to Azure Container Instances (ACI) using the Azure CLI and verify that it has started successfully. Arrange the steps in the correct sequence to achieve this goal.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of steps is to first create the Azure resource group, then deploy the container instance to that resource group, and finally query the properties of the container group to verify its status.
In Azure, resources cannot exist without a parent resource group. Therefore, the resource group must be created first. Once the resource group is active, the container instance can be provisioned. Finally, the container show command is run to inspect the state and ensure it has successfully transitioned to running.

Step-by-Step Solution

1
Execute the command to create an Azure resource group.
A resource group is provisioned in the specified region.
Azure Container Instances require an existing resource group to host the deployment.
2
Execute the command to deploy the container instance.
The ACI resource starts provisioning and pulling the specified container image.
This command creates the container group resource within the resource group prepared in the first step.
3
Execute the command to retrieve the container instance details.
The CLI outputs the JSON configuration containing the current provisioning state and IP address.
This is necessary to verify that the container state is 'Running' and to retrieve connectivity details.

Key Concept

Azure Container Instances deployment workflow via Azure CLI
Question 17Question →

An organization requires authentication for an Azure App Service web app using Microsoft Entra ID. You are tasked with configuring this using the Azure portal.

Which four actions should you perform in sequence to enable Microsoft Entra ID authentication for the web app?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To enable Microsoft Entra ID authentication on an App Service web app using the Azure portal, you must first navigate to the web app's Authentication settings, select 'Add identity provider' and choose Microsoft, configure the app registration details to restrict access to authenticated requests, and finally click Add to apply the configuration.
To enable built-in authentication (Easy Auth) for an Azure App Service web app using Microsoft Entra ID, the standard sequence starts by opening the Authentication blade in the Azure portal under the web app's Settings. You then click 'Add identity provider' and select 'Microsoft'. Next, you configure the details such as creating a new Entra ID app registration and setting the action to take for unauthenticated requests. Finally, you click 'Add' to save and apply the settings.

Step-by-Step Solution

1
Navigate to the Authentication settings of the web app.
The Authentication configuration blade is displayed.
All identity providers must be configured from this central settings page.
2
Add a new identity provider and select Microsoft.
The Microsoft provider configuration page opens.
Microsoft Entra ID is configured as the 'Microsoft' provider in the portal wizard.
3
Define the app registration and access restriction parameters.
The integration between the web app and Entra ID is defined.
This establishes the trust relationship and determines if unauthenticated traffic is blocked.
4
Click the Add button.
The provider is added and the authentication flow is enabled.
Saving the configuration applies the authentication middleware settings to the App Service runtime.

Key Concept

Azure App Service Easy Auth configuration
Question 18Question →

A developer is configuring a continuous integration workflow using Azure Container Registry (ACR). The developer needs to automate container image builds whenever source code changes are pushed to a GitHub repository. The developer plans to create a task in the registry named acrtask204 to build and push the image. Which sequence of steps should the developer perform to configure, execute, and monitor the task?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: first generate a GitHub Personal Access Token (PAT); second, create the task using the `az acr task create` command; third, trigger the task manually using the `az acr task run` command; and finally, view the build logs using the `az acr task logs` command.
The correct sequence starts with generating a GitHub Personal Access Token (PAT) because authentication credentials must exist before creating the task. Next, the task is created using the `az acr task create` command to specify the repository and credentials. Once defined, the task is manually triggered using `az acr task run`. Finally, the progress of the execution is monitored by streaming the build logs using the `az acr task logs` command.

Step-by-Step Solution

1
Generate a GitHub Personal Access Token (PAT)
A token that grants Azure Container Registry access to the GitHub repository.
Azure Container Registry requires authentication credentials to clone the code from the GitHub repository.
2
Create the ACR Task using the Azure CLI
A task resource named `acrtask204` is registered in Azure Container Registry.
The task must be defined in ACR with the repository path, image name, and authentication token before it can be triggered.
3
Trigger the task manually using `az acr task run`
The build task starts executing in ACR.
To test the task configuration and build the image immediately, the task must be manually run.
4
Retrieve and stream the logs using `az acr task logs`
The console displays the build steps, Docker commands, and completion status of the task.
Streaming the logs allows the developer to verify if the container image builds and pushes successfully.

Key Concept

Automating container builds and image management using Azure Container Registry (ACR) Tasks with source code triggers.
Estimated Time:2m 0s
Question 19Question →

You are developing a new event-driven processing application. You need to create a C# Azure Function named ProcessOrder that uses the Azure Functions V4 runtime and the .NET isolated worker model. The function must run locally on your developer workstation and execute whenever a new message is received in an Azure Queue Storage queue.

Which sequence of actions should you perform to initialize, create, and test the function locally? Arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure and run the function locally, you must first install the Azure Functions Core Tools. Next, initialize the local project using the init command with the dotnet-isolated worker runtime. Then, create the new function inside the project directory using the new command with the QueueTrigger template. Finally, start the local runtime host using the start command.
The correct sequence starts with installing the Azure Functions Core Tools, which provides the 'func' CLI. Once installed, a developer must initialize the project structure using 'func init' to create the baseline configuration files. After the project is initialized, the developer can generate the queue-triggered function code using 'func new'. Finally, the developer can start the local development host to run and test the function locally using 'func start'.

Step-by-Step Solution

1
Install the Azure Functions Core Tools on the developer workstation.
The local system has access to the 'func' CLI and the local Functions runtime host.
This is a prerequisite for creating and running Azure Functions locally.
2
Run the command `func init OrderProcessor --worker-runtime dotnet-isolated`.
A new directory named OrderProcessor is created, containing configuration files such as host.json and local.settings.json.
You must establish a project context before creating specific function triggers.
3
Run the command `func new --name ProcessOrder --template "QueueTrigger"` inside the project directory.
A new function named ProcessOrder is generated with the Queue Trigger template and added to the project.
This creates the function-specific code files and configuration bindings.
4
Run the command `func start` inside the project directory.
The local Azure Functions host starts and begins listening for queue events.
This starts the local runtime environment to test and debug the function.

Key Concept

Local development workflow of Azure Functions using the Azure Functions Core Tools CLI
Question 20Question →

You are deploying a containerized Azure Function App using a custom Linux Docker image stored in a private Azure Container Registry (ACR).

You must configure the Function App to pull the container image from the ACR using a system-assigned managed identity instead of admin credentials.

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of actions is: 1) Build and push the container image to the Azure Container Registry; 2) Create the Linux-based Function App in a plan that supports containers; 3) Enable the system-assigned managed identity on the Function App; 4) Assign the AcrPull role to the managed identity at the registry scope; 5) Configure the ACR_USE_MANAGED_IDENTITY_CREDENTIALS application setting to true.
To secure the deployment of a custom container image from a private Azure Container Registry (ACR) to an Azure Function App, you must first build and push the container image to ACR. Next, create the Function App on an Elastic Premium or Dedicated hosting plan, as Consumption plans do not support custom container deployments. Once the app is created, enable the system-assigned managed identity. With the identity active, you can then assign it the 'AcrPull' role at the registry scope. Finally, configure the Function App settings to use the managed identity credentials by setting the ACR_USE_MANAGED_IDENTITY_CREDENTIALS app setting to true.

Step-by-Step Solution

1
Build the Function App container image and push it to the Azure Container Registry (ACR).
The Docker image containing the Azure Function code and runtime dependencies is stored in the private registry.
The image must be present in the registry before it can be referenced during the Function App creation and deployment process.
2
Create a Linux-based Function App in an Elastic Premium plan configured for custom containers.
A Function App hosting resource is provisioned in Azure.
Custom container deployment for Azure Functions requires a Premium or Dedicated App Service plan (Consumption plans do not support custom container deployments).
3
Enable the system-assigned managed identity for the Function App.
A service principal is registered in Microsoft Entra ID representing the Function App.
You must generate the identity first before assigning Azure RBAC roles to it.
4
Assign the AcrPull role to the Function App's system-assigned managed identity at the ACR resource scope.
The Function App's identity is authorized to pull container images from the ACR.
Secure access without storing secrets is achieved by assigning the appropriate Azure RBAC role (AcrPull) to the Function App's identity.
5
Add an application setting named ACR_USE_MANAGED_IDENTITY_CREDENTIALS to the Function App and set its value to true.
The Function App's container runtime is configured to authenticate against the registry using the managed identity.
Setting ACR_USE_MANAGED_IDENTITY_CREDENTIALS to true instructs the platform to bypass admin credentials and pull using the managed identity.

Key Concept

Deploying containerized Azure Functions using managed identity for Azure Container Registry authentication
Page 1 / 9Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin