All practice questions

171 questions

All types972 Multiple choice497 Multiple select269 Matching9 Ordering171 Fill in the blank26

A developer is configuring local Git deployment for an Azure App Service web app named `app-hr-prod`. The developer needs to set up deployment credentials, retrieve the Git clone URL, and push the application code from a local repository to Azure.

Which sequence of steps should the developer perform to complete this configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Configure user-level deployment credentials, enable local Git deployment on the App Service, add the generated Git URL as a remote in your local repository, and push the code.

To configure local Git deployment for an Azure App Service web app, you must first establish the user-level deployment credentials. Next, you enable local Git deployment on the App Service web app to generate the Git repository clone URL. You then register this URL as a remote destination in your local Git repository. Finally, you push the local branch to the Azure remote to build and deploy the web application.

Step-by-Step Solution

Run `az webapp deployment user set` to configure deployment credentials.

User-level deployment credentials are established globally for the Azure subscription.

A deployment user must be configured to authenticate local Git push requests to Azure App Service.

Run `az webapp deployment source config-local-git` for the target web app.

Local Git deployment is enabled on the web app, and the Azure Git repository URL is returned.

This exposes the endpoint needed to associate the local Git repository with the Azure host.

Run `git remote add azure <url>` inside the local repository directory.

The local repository has a new Git remote named 'azure' pointing to the App Service repository.

Git needs the remote URL configured locally before it can transmit code to that endpoint.

Run `git push azure main` to push code to Azure.

The code is uploaded, built, and deployed to the active App Service slot.

Pushing the commits triggers the deployment workflow on Azure App Service.

Key Concept

Local Git deployment configuration for Azure App Service

Question 22Question →

You plan to map a custom domain to an Azure App Service web app and secure it using a free App Service Managed Certificate. You need to configure this using the Azure CLI.

Which sequence of steps should you perform to map the domain and configure the certificate? Arrange the steps in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first, retrieve the web app's custom domain verification ID; second, create the TXT and CNAME records at your DNS registrar; third, add the custom domain hostname to the web app; fourth, generate the App Service Managed Certificate; and fifth, bind the certificate to the custom domain using SNI.

To successfully configure a custom domain with an App Service Managed Certificate, you must perform the steps in a strict logical order. First, get the verification ID using `az webapp show`. Second, configure the TXT and CNAME records at your DNS registrar. Third, map the hostname using `az webapp config hostname add`. Fourth, generate the certificate using `az webapp config ssl create`. Finally, bind the certificate to the domain using `az webapp config ssl bind`.

Step-by-Step Solution

Retrieve the custom domain verification ID using `az webapp show`.

The `customDomainVerificationId` property is retrieved.

This ID is required to create the TXT validation record at the DNS provider.

Create a TXT record (prefixed with `asuid.`) containing the verification ID, and a CNAME record pointing to the default app URL at the DNS registrar.

The DNS records are created and propagate.

Azure queries these records to verify ownership before allowing the custom hostname to be mapped.

Add the custom hostname to the web app using `az webapp config hostname add`.

The custom domain mapping is successfully added to the App Service.

You cannot issue an App Service Managed Certificate for a domain that is not mapped to the web app.

Generate the managed certificate using `az webapp config ssl create`.

An App Service Managed Certificate is created, and its thumbprint is returned.

The certificate must exist in the App Service environment before it can be bound.

Configure the TLS/SSL binding using `az webapp config ssl bind` with the certificate thumbprint.

The custom domain is secured with HTTPS.

This binds the certificate to the custom hostname using SNI SSL.

Key Concept

Azure App Service custom domain and SSL binding configuration requires verifying ownership via DNS records before adding hostnames, and binding the hostname before generating or assigning an App Service Managed Certificate.

Question 23Question →

You need to deploy a containerized application to Azure Container Instances (ACI). The container image is stored in a private Azure Container Registry (ACR) named `contosoacr`. You must use a user-assigned managed identity named `contoso-aci-identity` to authenticate the container group to pull the image from `contosoacr`. The solution must follow the principle of least privilege. Which sequence of Azure CLI commands should you perform to deploy the container instance?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To deploy a container in ACI that pulls an image from a private ACR using a user-assigned managed identity, you must first create the identity, retrieve its principal ID and the ACR resource ID, assign the AcrPull role to the identity at the ACR scope, and finally run the container creation command referencing the identity.

The correct order follows the logical dependency chain of Azure resources. The user-assigned managed identity must first exist. Once it exists, its principal ID and the target ACR resource ID are retrieved to configure the role assignment. The role assignment granting 'AcrPull' must be active before deployment is initiated. Finally, the container group is deployed using the container creation CLI command, which references the identity to pull the image.

Step-by-Step Solution

Create the user-assigned managed identity

The identity resource is provisioned in Azure.

You must establish the identity's resource lifecycle before configuring permissions or assigning it.

Retrieve required security identifier (Principal ID) and resource identifier (ACR Resource ID)

The necessary resource IDs are retrieved for role mapping.

Role assignments require target identity and target resource scopes defined by Azure Resource Manager IDs.

Assign the AcrPull role to the identity

The identity has authorization to pull images from the registry.

This permission must be in place before the container is deployed, as ACI will pull the image during provisioning.

Deploy the ACI container group referencing the identity

The container group is deployed, using the identity to successfully pull the image from ACR.

Using both parameters ensures the identity is bound to the container group and utilized specifically for registry authentication.

Key Concept

Deploying container groups to ACI with secure registry authentication using user-assigned managed identities.

Question 24Question →

You are configuring an existing Azure Container App named `my-app` to pull container images from a private Azure Container Registry (ACR) named `myregistry.azurecr.io`. You want to use a User-Assigned Managed Identity for authentication to adhere to the principle of least privilege. What is the correct sequence of steps to configure the container app to use the managed identity and deploy the image?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Create the User-Assigned Managed Identity, assign the AcrPull role to it over the registry scope, associate the identity with the Container App, configure the Container App registry credential helper, and then update the Container App image.

The correct order resolves dependencies strictly. The User-Assigned Managed Identity must be created first to obtain its configuration details. Then, permissions must be granted to the identity to authenticate with the container registry. Next, the identity must be bound to the Container App before configuring the app's registry settings to use it. Finally, the container image can be updated, allowing the app to authenticate, pull the image, and spin up a new revision.

Step-by-Step Solution

Provision the User-Assigned Managed Identity using the Azure CLI.

The identity resource is generated with a unique principal ID and resource ID.

You must establish the identity principal first to retrieve its properties for downstream role assignments and associations.

Grant the AcrPull role to the identity over the Azure Container Registry.

The managed identity is authorized to pull images from the ACR.

Authentication relies on role-based access control (RBAC). Without this permission, the Container App will fail to pull the image even if the identity is correctly assigned.

Assign the User-Assigned Managed Identity to the Container App resource.

The container app is associated with the identity's resource ID in its identity block.

Azure Resource Manager validates that the identity is associated with the Container App before letting you configure it for container registry authentication.

Establish the registry configuration on the Container App.

The Container App registry block is updated to specify the target ACR server and user-assigned identity.

This links the ACR server path to the identity credentials so the platform knows how to authenticate for subsequent pull requests.

Update the image on the Container App.

A new revision is created and the private image is pulled successfully.

Since the registry mappings, identity association, and RBAC permissions are configured, the platform resolves the registry reference and pulls the private image with zero authentication failures.

Key Concept

Deploying Azure Container Apps with private registry pull using User-Assigned Managed Identity

Question 25Question →

A company hosts a critical Web API on an Azure App Service Web App that currently runs on the Shared (D1) pricing tier. The API experiences sudden CPU spikes during nightly batch processing jobs, leading to performance degradation. You must implement an automated scaling strategy that meets the following requirements:
- Automatically scales out up to 10 instances during high CPU load.
- Scales in to minimize costs when the load subsides.
- Prevents autoscale flapping.
- Minimizes administrative overhead by using the Azure CLI.

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

The correct sequence of actions is: First, scale the App Service Plan to the S1 tier; second, initialize the autoscale setting targeting the plan; third, add the scale-out rule for CPU usage above 80%; and fourth, add the scale-in rule with a 30% CPU threshold to prevent flapping.

The correct sequence begins by scaling the App Service Plan to the Standard (S1) tier, as the Basic and Shared tiers do not support custom autoscale features. Next, the autoscale setting must be created for the App Service Plan before rules can be assigned. The scale-out rule is then added to monitor for CPU spikes. Finally, a scale-in rule is configured with a threshold of 30% CPU utilization, which prevents flapping because it is sufficiently low compared to the scale-out threshold.

Step-by-Step Solution

Scale the App Service Plan to the Standard (S1) tier.

The App Service Plan is updated to the Standard tier, which unlocks autoscale capabilities and supports scaling up to 10 instances.

The existing Shared (D1) tier and the Basic (B1) tier do not support automated scale-out features.

Create the autoscale setting targeting the App Service Plan resource.

An autoscale setting profile is created with defined limits (minimum of 1, maximum of 10, default of 1).

An autoscale configuration must be initialized before individual scaling rules can be registered under it.

Add the scale-out rule targeting the autoscale setting.

A rule is added to scale out the instances by 1 when the average CPU percentage exceeds 80% for 10 minutes.

This fulfills the requirement of scaling out the App Service instances during high CPU utilization.

Add the scale-in rule with a safe CPU threshold.

A rule is added to scale in the instances by 1 when the average CPU percentage drops below 30% for 10 minutes.

A 30% CPU threshold prevents flapping. If the scale-in threshold were too high (like 75%), scaling out from 1 to 2 instances would immediately drop the average CPU utilization per instance and trigger an immediate scale-in, causing an infinite loop of scaling up and down.

Key Concept

Configuring Azure App Service plan autoscaling rules via CLI, ensuring the correct pricing tier is selected, and configuring appropriate scale-in thresholds to avoid autoscale flapping.

Question 26Question →

You need to deploy a container to Azure Container Instances (ACI). The container must mount a persistent volume to store application logs. You decide to use an Azure Files share for the volume. Which three actions should you perform in sequence to deploy the container? 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 an Azure Storage account and file share, retrieve the storage account access key, and then run the az container create command specifying the volume parameters.

To mount an Azure Files share to a container in Azure Container Instances, you must first create the storage account and the file share. Next, you retrieve the storage account key, which is required by ACI for authentication. Finally, you execute the deployment using the az container create command, passing the file share name, storage account name, storage account key, and the mount path.

Step-by-Step Solution

Create storage resources

An Azure Storage account and a file share are created.

Before mounting an Azure Files share in ACI, the storage account and file share must exist.

Retrieve access key

The storage account access key is retrieved.

ACI requires the storage account access key to authenticate and mount the file share.

Deploy the container group

The container group is deployed with the file share mounted.

Running the az container create command with the appropriate volume parameters mounts the file share to the container.

Key Concept

Mounting persistent storage to Azure Container Instances using Azure Files

Question 27Question →

You are configuring a custom domain for an Azure App Service web app. You have purchased an SSL/TLS certificate from a third-party certificate authority. You need to configure the web app to use the custom domain secured with this certificate. Which sequence of steps should you perform? Move all actions to the active list and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Create the CNAME record at your registrar, add the custom domain to the web app, upload the private certificate, and then create the TLS/SSL binding.

The correct order requires first creating the DNS record (CNAME) so Azure can verify ownership when mapping the domain. After mapping the domain, you upload the private certificate so it is available in the App Service environment. Finally, you bind the certificate to the domain to secure the connection.

Step-by-Step Solution

Create a CNAME record pointing to the default hostname.

The DNS record is resolvable.

Allows Azure to verify ownership of the domain.

Add the custom domain in the Azure portal or CLI.

The domain is successfully mapped.

The domain must exist in the web app configuration before binding.

Upload the private .pfx certificate.

The certificate is stored in Azure App Service.

Prepares the certificate for use in the binding step.

Create the TLS/SSL binding.

HTTPS is enabled on the custom domain.

Secures the custom domain traffic.

Key Concept

Configuring custom domains and TLS/SSL certificate bindings in Azure App Service

Estimated Time:1m 30s

Question 28Question →

A developer needs to configure an Azure Container Registry (ACR) named `registry204` to notify an external service via a webhook whenever a new container image tag is pushed. The developer must also verify that the webhook is successfully triggered by a push event. Which sequence of steps should the developer perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, verify that the Azure Container Registry is using either the Standard or Premium service tier and obtain the target webhook URL. Next, create the webhook with the `az acr webhook create` command, configuring it to trigger on the `push` action. Then, perform a `docker push` to upload a container image to the registry, triggering the webhook. Finally, run the `az acr webhook list-events` command to verify successful delivery of the webhook notification.

The correct order begins with verifying that the registry is Standard or Premium tier (as Basic does not support webhooks) and obtaining the target URL. Next, the webhook must be created using the `az acr webhook create` command. After the webhook is created, a container image is pushed to trigger the webhook. Finally, the event delivery is verified by running the `az acr webhook list-events` command.

Step-by-Step Solution

Verify the ACR service tier and obtain the webhook destination URL.

The registry is verified to be on a supported tier (Standard or Premium) and the target URL is ready.

ACR webhooks are only available in the Standard and Premium service tiers; they are not supported in the Basic tier.

A webhook is created in the registry configured to trigger on the `push` action.

The webhook must exist in the registry prior to the push event to capture and forward the trigger.

Push a container image to the registry.

The container image is uploaded, triggering the webhook.

Uploading the image triggers the webhook since it was configured to monitor the `push` action.

Verify webhook delivery using the CLI.

Webhook invocation logs and status codes are displayed.

The `az acr webhook list-events` command provides the delivery history and response codes from the target API.

Key Concept

Configuring and verifying webhooks in Azure Container Registry (ACR) to respond to image push events.

Question 29Question →

An organization is deploying a critical microservice to run on Azure Container Instances (ACI). The microservice container image is hosted in a private Azure Container Registry (ACR) named contosoregistry. Security policies dictate that you must avoid using ACR admin credentials or storing secrets in the deployment configuration, and instead use a user-assigned managed identity to authenticate and pull the image. You need to configure the environment and deploy the container group.

In which sequential order should you perform the steps to accomplish this goal?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To deploy an ACI container group pulling from a private ACR using a user-assigned identity, you must first create the user-assigned managed identity, assign the AcrPull role to it at the ACR scope, retrieve its resource ID, configure the YAML file with the identity block and imageRegistryCredentials referencing the resource ID, and finally run the az container create command referencing the YAML file.

The correct order requires creating the user-assigned identity first, granting it permission on the registry, retrieving its resource ID, incorporating it into the YAML deployment manifest, and then running the deployment command. This sequence ensures that all security and configuration dependencies are met before deployment is initiated.

Step-by-Step Solution

Create the user-assigned managed identity.

A new managed identity resource is created in Microsoft Entra ID and Azure.

You cannot assign roles or reference the identity until the resource is created.

Assign the AcrPull role to the identity scoped to the ACR.

The identity is authorized to pull container images from the private registry.

This permission must be in place before ACI attempts to pull the image using this identity.

Retrieve the resource ID of the identity.

The resource ID string is obtained.

The YAML deployment file requires the fully qualified resource ID of the identity in both the identity definition and the registry credentials section.

Write the YAML manifest containing both the identity reference and the imageRegistryCredentials block.

A deployment YAML file is created.

The manifest must specify how ACI will authenticate (using the user-assigned identity) to the registry.

Execute the az container create command with the --file argument.

The container group is deployed to ACI.

This starts the creation process in Azure using the defined configuration.

Key Concept

Deploying Azure Container Instances using user-assigned managed identities to pull images from a private Azure Container Registry.

Estimated Time:3m 0s

Question 30Question →

You are a developer managing an Azure App Service web app named app-prod-westus. The web app currently has a deployment slot named staging that contains a pre-production release. You need to perform a deployment slot swap with preview from staging to the production slot to verify that the staging application works correctly with production configurations before the swap completes. Which sequence of actions should you perform to execute and complete the swap with preview?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To perform a swap with preview, first run the swap command with the preview action to apply target configuration settings to the source slot. Next, verify the app's behavior at the staging slot's endpoint. Finally, complete the swap using the swap action.

The correct sequence ensures that the swap is first initialized in preview mode, which applies target configurations to the source slot. Once configurations are verified at the staging endpoint, the swap is completed by running the command with the swap action.

Step-by-Step Solution

Initiate the preview swap using the Azure CLI.

The configuration settings of the production slot are applied to the staging slot, and the swap process pauses.

This allows the staging slot to run the new code with production settings without routing live production traffic to it yet.

Test the staging application at its URL.

Confirm that the application behaves correctly with the production database connection strings and configuration settings.

This ensures that configuration mismatches or application startup issues are identified before traffic is redirected.

Complete the slot swap using the Azure CLI.

The staging slot code is moved to the production slot, and client traffic is directed to the new version.

This finalizes the deployment process after validation is successful.

Key Concept

Deployment slot swap with preview

Question 31Question →

An enterprise application requires an Azure Function App to retrieve its database connection strings securely from Azure Key Vault without storing credentials in the application configuration. According to your organization's security policy, you must use a user-assigned managed identity instead of a system-assigned managed identity to access the key vault.

Which four 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 first create the identity and assign it to the Function App. Next, grant the identity Secret Get permission on the Key Vault. Then, set the keyVaultReferenceIdentity app setting to the resource ID of the identity. Finally, add the application setting referencing the secret.

The correct sequence ensures that the user-assigned managed identity is established first, granted permissions to the Key Vault next, mapped as the identity provider for Key Vault references in the application configuration using its full resource ID, and then utilized in the app setting references.

Step-by-Step Solution

Create a user-assigned managed identity and assign it to the Function App.

The Function App is associated with the user-assigned identity.

The identity must exist and be registered with the app resource before it can be referenced in App Service config.

Grant the user-assigned managed identity Secret Get permission on the Azure Key Vault.

The identity is authorized to access secrets in the vault.

Data plane access is required for the identity to read the secrets referenced by the app settings.

Configure the Function App setting keyVaultReferenceIdentity with the resource ID of the user-assigned managed identity.

The Function App runtime is configured to use the specified user-assigned identity for resolving Key Vault references.

The default behavior is to use the system-assigned identity; setting keyVaultReferenceIdentity overrides this and points to the user-assigned identity's Resource ID.

Add a new application setting to the Function App with its value formatted as a Key Vault reference.

The application setting is created and references the vault secret dynamically.

Adding the reference syntax allows the host to fetch the secret at startup and inject it as an environment variable.

Key Concept

Configuring Key Vault references in Azure Functions with user-assigned managed identities.

Question 32Question →

You are migrating an existing Azure Function App (V4 runtime) to use identity-based connections for its internal host storage instead of a connection string. The function app is currently configured with the `AzureWebJobsStorage` application setting. To comply with security guidelines, you must use a system-assigned managed identity to connect to the storage account. Which sequence of actions should you perform to complete this migration while minimizing application downtime and startup errors?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, enable the system-assigned managed identity on the Function App resource. Second, grant the system-assigned managed identity the Storage Blob Data Owner, Storage Queue Data Contributor, and Storage Table Data Contributor roles on the storage account. Third, add the `AzureWebJobsStorage__accountName` setting with the storage account name to the Function App application settings. Fourth, delete the `AzureWebJobsStorage` connection string setting from the Function App application settings.

To migrate the Azure Function App host storage safely, the system-assigned managed identity must first be enabled so that its principal exists. Next, the required Azure RBAC roles must be granted to this identity on the storage account. To prevent startup failures, the new `AzureWebJobsStorage__accountName` setting is added next. Finally, deleting the `AzureWebJobsStorage` connection string setting completes the configuration transition, as the connection string takes precedence when both are present.

Step-by-Step Solution

Enable the system-assigned managed identity on the Function App resource.

The Function App is assigned an identity in Microsoft Entra ID, creating a service principal with a unique principal ID.

The principal ID is required to configure role-based access control (RBAC) in subsequent steps.

Assign the Storage Blob Data Owner, Storage Queue Data Contributor, and Storage Table Data Contributor roles to the system-assigned managed identity on the storage account.

The system-assigned managed identity is granted permission to manage blobs, queues, and tables in the target storage account.

The Azure Functions runtime uses these storage services internally for host coordination and state management, and must be authorized before the configuration switches to identity-based authentication.

Add the `AzureWebJobsStorage__accountName` app setting to the Function App.

The Function App is configured to locate the storage account for host storage using the identity-based connection format.

Adding this setting first ensures that there is a valid configuration target before the connection string is removed, preventing configuration gaps.

Remove the `AzureWebJobsStorage` application setting.

The runtime no longer detects the connection string and immediately switches to the identity-based configuration defined in the account name setting.

The connection string setting has precedence. Removing it is necessary to force the host to use the system-assigned managed identity.

Key Concept

Configuring identity-based connections for the Azure Functions host storage (`AzureWebJobsStorage`).

Question 33Question →

You are troubleshooting a startup failure in an ASP.NET Core web application deployed to a Linux Azure App Service. The application fails to initialize, and you need to capture container startup logs to identify the error. You decide to use the Azure CLI to enable container logging, trigger a container restart to generate fresh telemetry under the new configuration, stream the startup log sequence in real time, and download the log zip archive for offline analysis.

Arrange the steps in the correct order to configure, capture, and retrieve these logs.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To properly diagnose the startup failure, first configure container filesystem logging, restart the application to trigger a fresh initialization attempt, stream the live stdout/stderr streams to observe the failure in real time, and then download the persistent log archive for detailed offline analysis.

The correct order follows a logical pipeline: first, configure the logging infrastructure to persist docker container logs on the file system; second, restart the application to trigger a new container initialization attempt under the active log configuration; third, open a real-time stream to observe stderr/stdout streams during the startup cycle; and fourth, download the full Kudu log archive to get detailed system-level files for offline debugging.

Step-by-Step Solution

Enable container filesystem logging using `az webapp log config` with the `--docker-container-logging filesystem` parameter.

The App Service is configured to write container logs to the local file system.

By default, container stdout and stderr streams are not persisted or streamed for Linux apps unless container logging is explicitly enabled.

Restart the application using `az webapp restart`.

The Docker container hosting the web application is terminated and a new container instance starts up.

Restarting the application generates fresh startup telemetry under the newly enabled container logging configuration.

Start log streaming using `az webapp log tail`.

A live connection is established to the App Service log stream.

Streaming the logs in real time allows you to observe container initialization issues and runtime crashes as they happen.

Download the log archive using `az webapp log download`.

A ZIP archive containing container and system logs is saved locally.

Downloading the complete log package provides Kudu deployment history and host logs that may not be fully visible in the live stream.

Key Concept

Azure App Service container diagnostics, log configuration, real-time log streaming, and download logs via Azure CLI.

Estimated Time:3m 0s

Question 34Question →

A developer needs to deploy a containerized API to Azure Container Apps using the Azure CLI. The container image is stored in a public registry. Which sequence of Azure CLI commands must the developer execute to successfully deploy the application?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The developer must first create an Azure Resource Group, then create a Container Apps environment, and finally deploy the Container App inside the environment.

The correct order follows the logical resource hierarchy in Azure: the resource group acts as the top-level container, the Container Apps environment is provisioned inside it, and the Container App itself is deployed within that environment.

Step-by-Step Solution

Run `az group create` to establish a resource group.

A resource group is provisioned to contain all other services.

All Azure resources must reside in a resource group, which manages their lifecycle and metadata.

Run `az containerapp env create` to provision the environment.

A Container Apps environment is created inside the resource group.

The environment functions as a secure network boundary and configuration holder for one or more Container Apps.

Run `az containerapp create` to deploy the container.

The Container App is running in the environment.

The Container App requires both a resource group and a Container Apps environment parameter to be created successfully.

Key Concept

Deploying Azure Container Apps requires provisioning a Resource Group and a Container Apps Environment before deploying the container app resource itself.

Estimated Time:1m 0s

Question 35Question →

You are developing a data processing solution using Azure Durable Functions. You need to sequence the execution flow of the application during a standard function chaining scenario. Arrange the actions in the correct chronological order from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence is: first, the client function starts the orchestrator instance; second, the orchestrator executes and yields control at the first await statement; third, the activity function runs to completion and saves its result; and finally, the orchestrator wakes up, replays history, and schedules the next activity function.

In Durable Functions, the workflow is initiated by a client function. When the orchestrator executes, it schedules tasks and yields control (goes to sleep) when awaiting asynchronous activities. The activity runs independently and stores its state. Once complete, the orchestrator wakes up and replays the history to reconstruct its state, allowing it to schedule the next step without maintaining an in-memory active state.

Step-by-Step Solution

Trigger the orchestration client.

A new orchestrator instance is created and placed in the queue.

Durable Functions require an orchestrator client to start orchestrations.

Run the orchestrator function until the first await point.

The first activity function is scheduled, and the orchestrator goes to sleep.

Orchestrators are designed to yield control when waiting for asynchronous tasks to save cost and resources.

Run the activity function on a worker.

The activity task completes, and the result is written to Azure Storage.

Activity functions execute the actual processing work and store their state upon completion.

Awaken the orchestrator function.

The orchestrator replays execution history and proceeds to schedule the next step.

Orchestrator functions rebuild state by replaying history when a scheduled task completes.

Key Concept

Azure Durable Functions Execution Lifecycle and Replay Mechanism

Question 36Question →

You are a developer configuring an Azure App Service web app to connect to an on-premises Microsoft SQL Server database on port $1433$ . You must use Azure Hybrid Connections to establish the connection without opening public inbound firewall ports on the local network.

Arrange the steps in the correct order to configure and establish the Hybrid Connection.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To establish the Hybrid Connection, you must first create the connection in the Azure Portal, retrieve the gateway connection string, install the Hybrid Connection Manager (HCM) on-premises, paste the connection string into the HCM, and verify the connection status.

The logical sequence begins with defining the cloud endpoint in the Azure Portal to get the authorization credentials (gateway connection string). Next, the local daemon (HCM) is installed on the on-premises network and configured using that connection string to establish the outbound tunnel. Finally, the setup is validated by verifying the connection status.

Step-by-Step Solution

Create the Hybrid Connection in the Azure Portal's Networking section.

Azure provisions the Hybrid Connection and associated Relay namespace.

This establishes the cloud endpoint for the hybrid connection.

Copy the gateway connection string from the Azure Portal.

You obtain the connection string required for local agent authentication.

The connection string is needed to authorize the on-premises manager to connect to the Azure Relay.

Install the Hybrid Connection Manager (HCM) on the on-premises server.

The HCM software is ready to run locally.

The on-premises agent must be installed on a machine that can reach the local resource.

Configure the HCM with the copied gateway connection string.

The HCM connects to the Azure Relay endpoint.

This establishes the outbound tunnel from the on-premises network to Azure.

Verify that the connection status is Connected in the portal and HCM.

The web app can now route traffic to the database on port

1433

Confirms the tunnel is active and resolving requests.

Key Concept

Configuring Hybrid Connections for Azure App Service Web Apps to access on-premises resources.

Estimated Time:2m 0s

Question 37Question →

You host a web application on an Azure App Service Web App that currently runs on the Free (F1) App Service plan. You need to configure the web app to automatically scale out when the CPU utilization exceeds $80\%$ . In which order should you perform the configuration steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, upgrade the App Service plan to the Standard (S1) pricing tier. Second, enable Custom autoscale in the Scale out settings of the App Service plan. Third, add a scale-out rule that increases the instance count when the CPU percentage exceeds

80\%

The correct order requires upgrading the App Service plan to a tier that supports autoscale (Standard S1) before configuring the settings and adding the CPU-based scaling rule.

Step-by-Step Solution

Upgrade the App Service plan to the Standard (S1) pricing tier.

The plan is moved to a tier that supports custom autoscale rules.

The Free (F1) tier does not support autoscale or manual scale-out; a minimum of Standard (S1) is required for metric-based autoscale.

Enable Custom autoscale in the Scale out (App Service plan) settings.

The custom autoscale policy editor becomes active, allowing rule configuration.

Autoscale must be enabled and set to custom before specific metric-based rules can be added.

Add a scale-out rule with the CPU percentage metric set to trigger an increase in the instance count when it exceeds

80\%

The auto-scaling rule is applied and active.

Once the custom autoscale engine is active, the rule is defined to increase capacity based on the CPU workload.

Key Concept

Scaling Azure App Service Web Apps requires a compatible pricing tier (Standard or higher) to support Custom autoscale rules.

Question 38Question →

You need to deploy a containerized application to Azure Container Instances (ACI). The container image is stored in a private Azure Container Registry (ACR). You plan to use a user-assigned managed identity to authenticate to the ACR during the container group creation. You will perform the deployment using a YAML configuration file and the Azure CLI. Once the deployment is complete, you must verify the container startup logs to ensure the application initialized correctly.

Which sequence of actions should you perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To deploy a container group from a private ACR using a user-assigned managed identity, you must first create the identity and assign it the AcrPull role on the registry. Next, retrieve the resource ID of the managed identity. Use this ID to configure the image registry credentials and identity properties inside the YAML definition file. Then, deploy the container group using the az container create command with the --file parameter. Finally, inspect the startup logs using the az container logs command.

The correct order establishes a logical dependency chain. First, the user-assigned identity must be created and granted the AcrPull role on the ACR to authorize image retrieval. Second, its resource ID must be retrieved so it can be embedded in the deployment manifest. Third, the YAML configuration file must be written to specify the identity and credentials. Fourth, the deployment is executed via the Azure CLI using the --file parameter. Finally, after the containers are running, their logs are inspected to verify initialization.

Step-by-Step Solution

Create a user-assigned managed identity and assign it the AcrPull role on the Azure Container Registry (ACR).

A managed identity is provisioned and authorized to pull container images from the registry.

Azure Container Instances requires permission to pull the image from the private registry. Using a user-assigned managed identity is a secure, credential-free method, but it must be created and authorized beforehand.

Retrieve the resource ID of the user-assigned managed identity.

You obtain the fully qualified Azure Resource Manager (ARM) ID of the managed identity.

The YAML template configuration requires the exact resource ID of the managed identity to reference it under the identity block and image registry credentials.

Author a YAML configuration file that defines the container group, referencing the registry credentials and the managed identity resource ID.

A completed YAML configuration file representing the container group structure and authentication details.

To use a user-assigned managed identity to authenticate to ACR, the relationship must be defined in the YAML file before deployment under the imageRegistryCredentials and identity sections.

Deploy the container group by running the az container create command with the --file parameter pointing to the YAML configuration file.

The ACI container group is created and deployed in Azure.

The az container create command applies the YAML configuration to spin up the container group.

Verify the deployment and inspect the container startup logs by running the az container logs command.

The stdout/stderr streams of the container are displayed.

Checking the container logs is the final step to confirm the application within the container group started successfully.

Key Concept

Deploying container groups using YAML and authenticating to ACR using a user-assigned managed identity.

Question 39Question →

You are implementing a simple Durable Functions chaining workflow in C# to process a customer order. The workflow consists of an HTTP-triggered client function, an orchestrator function, and two activity functions: `ValidateOrder` and `ProcessPayment`.

Arrange the steps in the correct order of execution, starting from when a client submits an order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with the client function receiving the HTTP request and starting the orchestrator. Next, the orchestrator begins execution and calls the ValidateOrder activity. The orchestrator then awaits the activity and goes to sleep while ValidateOrder runs. Finally, the orchestrator wakes up, receives the output, and calls the ProcessPayment activity.

In a Durable Functions workflow, execution begins with the client function starting the orchestrator. The orchestrator runs until it reaches an await statement for an activity, at which point it schedules the activity and goes to sleep. Once the activity completes, the orchestrator is woken up (replayed) to retrieve the result and proceed to the next step in the chain.

Step-by-Step Solution

Trigger the workflow through the client function.

An orchestrator instance is created.

Client functions act as entry points to start orchestrations.

Begin orchestrator execution and invoke the first activity.

The ValidateOrder activity is scheduled.

The orchestrator controls the workflow and schedules activities sequentially.

Await the scheduled activity.

The orchestrator goes to sleep.

Orchestrators are suspended during active tasks to avoid unnecessary resource consumption.

Replay the orchestrator upon activity completion.

The next activity is called.

Azure Durable Functions replay orchestrator functions to resume execution state from history.

Key Concept

Durable Functions Chaining Execution Lifecycle

Question 40Question →

A package delivery dispatch system is implemented using Azure Durable Functions. The workflow assigns a driver, waits up to 30 minutes for the driver to accept the assignment via an external event, and dispatches the delivery if accepted. The driver accepts the assignment 10 minutes after it is assigned.

How does the Durable Task Framework execute and replay the orchestrator function to complete this workflow? Order the execution and replay events chronologically from the initial start of the orchestrator to its completion.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological order of execution and replay events is: first, the orchestrator starts and schedules the AssignDriver activity; second, it restarts, replays, and schedules both the external event and the timer; third, it restarts upon receiving the external event, cancels the timer, and schedules DispatchDelivery; finally, it restarts, replays all events, and completes execution.

The correct sequence mirrors the stateful replay model of Azure Durable Functions. The orchestrator never blocks; instead, it executes sequentially until it encounters an await, at which point it schedules the activity or event, yields, and shuts down. When the scheduled task completes, the orchestrator is awakened, replays the execution history to rebuild the local state, and continues to the next step.

Step-by-Step Solution

Initiate orchestration and schedule the first activity

The AssignDriver activity is queued, and the orchestrator yields control to save resources.

Durable Functions use an asynchronous queue-based model where the orchestrator does not block thread execution while waiting for activities.

Replay the first activity and set up concurrent monitoring

The orchestrator replays, retrieves the AssignDriver result, schedules the DriverResponse event and the timer, and yields control.

To wait for either a timeout or an external event, both tasks must be created and monitored concurrently using Task.WhenAny or equivalent.

Process external event completion, cancel the timer, and trigger the dispatch

The orchestrator restarts, cancels the active timer, queues the DispatchDelivery activity, and yields control.

Since the driver responded within the limit, the timer task must be cancelled to avoid unnecessary execution, and the next step is scheduled.

Replay final steps and close the orchestration

The orchestrator performs a final replay, matches the DispatchDelivery result, and exits successfully.

The orchestrator must run one final time to evaluate the completed DispatchDelivery activity and return the final state.

Key Concept

Durable Functions execution lifecycle, determinism, and event/timer orchestration

PreviousPage 2 / 9Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept