All practice questions

972 questions

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

You are developing a secure C# web application that runs on-premises. The application must sign in users and then call a downstream Web API on their behalf using the Microsoft Identity Platform.

The application is configured as a confidential client. You have already obtained the authorization code from the initial user login redirect.

You write the following code to initialize the application:

csharp
IConfidentialClientApplication app = ConfidentialClientApplicationBuilder.Create(clientId)
.WithClientSecret(clientSecret)
.WithRedirectUri(redirectUri)
.Build();

You need to complete the code to exchange the authorization code for an access token. Which code segment should you use?

AuthenticationResult result = await app.AcquireTokenByAuthorizationCode(scopes, authorizationCode).ExecuteAsync();

AuthenticationResult result = await app.AcquireTokenForClient(scopes).ExecuteAsync();

AuthenticationResult result = await app.AcquireTokenSilent(scopes, accounts.FirstOrDefault()).ExecuteAsync();

var credential = new DefaultAzureCredential(new DefaultAzureCredentialOptions { ManagedIdentityClientId = clientId });
var tokenContext = new TokenRequestContext(scopes.ToArray());
var token = await credential.GetTokenAsync(tokenContext);

Show answer & explanation

Answer: AuthenticationResult result = await app.AcquireTokenByAuthorizationCode(scopes, authorizationCode).ExecuteAsync();

Answer

AuthenticationResult result = await app.AcquireTokenByAuthorizationCode(scopes, authorizationCode).ExecuteAsync();

The application needs to exchange an authorization code for an access token to call a downstream API on behalf of a user. The app is a confidential client initialized as an IConfidentialClientApplication. The correct method to exchange the authorization code is AcquireTokenByAuthorizationCode, followed by ExecuteAsync to run the request.

Step-by-Step Solution

Identify the client type and the authentication flow needed.

The web application is a confidential client, and it must exchange an authorization code for a delegated user access token.

The scenario specifies a confidential client application that has already received an authorization code from a user login redirect.

Match the required flow to the correct MSAL.NET method.

Use the AcquireTokenByAuthorizationCode method of IConfidentialClientApplication.

This method is specifically designed to exchange the authorization code for access and refresh tokens.

Chain the MSAL builder execution method.

Append .ExecuteAsync() to the builder.

MSAL.NET uses a builder pattern, and .ExecuteAsync() must be called to send the asynchronous HTTP request to Microsoft Identity Platform.

Key Concept

Exchanging an authorization code for an access token using MSAL.NET ConfidentialClientApplication.

Question 22Question →

An enterprise application uses Azure API Management (APIM) to route requests to a secure backend microservice. The backend microservice requires a specific API key passed via an HTTP header named X-Backend-Key. To secure the credential, the API key is stored as a secret in Azure Key Vault. You have already created an APIM named value named BackendApiKey that references this secret. APIM must retrieve the secret dynamically from the Key Vault using its system-assigned managed identity. Which configuration and policy placement will successfully inject the API key header into the request sent to the backend?

Place a set-header policy in the outbound section of the policy definition using the {{BackendApiKey}} named value, and ensure the API Management system-assigned managed identity is granted the Key Vault Secrets User role in Azure Key Vault.

Place a set-header policy in the inbound section of the policy definition using the {{BackendApiKey}} named value, and ensure the API Management system-assigned managed identity is granted the Key Vault Secrets User role in Azure Key Vault.

Place a set-header policy in the inbound section of the policy definition using the {{BackendApiKey}} named value, and ensure a user-assigned managed identity is granted the Key Vault Secrets User role in Azure Key Vault while the named value is configured to use the system-assigned managed identity.

Place a set-header policy in the inbound section of the policy definition using the {{BackendApiKey}} named value, without granting any explicit Key Vault permissions to the API Management system-assigned managed identity, as API Management instances possess default read privileges to Key Vault resources within the same Azure subscription.

Show answer & explanation

Answer: Place a set-header policy in the inbound section of the policy definition using the {{BackendApiKey}} named value, and ensure the API Management system-assigned managed identity is granted the Key Vault Secrets User role in Azure Key Vault.

Answer

Placing the set-header policy in the inbound section modifies the request headers before they are forwarded to the backend service. Referencing the named value via the double curly braces syntax retrieves the secret from Azure Key Vault, which succeeds because the system-assigned managed identity is assigned the Key Vault Secrets User role.

Step-by-Step Solution

Determine the correct policy section for modifying requests forwarded to the backend.

The inbound section must be used because it processes the request prior to calling the backend service.

Outbound and other sections run too late or are for different stages of the gateway pipeline.

Identify the correct referencing format for named values in API Management policies.

Use the curly brace notation format, which in this case is {{BackendApiKey}}.

This tells API Management to look up the named value and retrieve its mapped value, which points to the Key Vault secret.

Assign the necessary permissions for Key Vault retrieval via the system-assigned managed identity.

Grant the API Management system-assigned managed identity the Key Vault Secrets User role or Get secret permission in the target Key Vault.

Without explicit permissions, the Key Vault request will be denied, preventing the named value from resolving.

Key Concept

API Management policy configuration for inbound request header injection using Key Vault named values backed by system-assigned managed identities.

Question 23Question →

You are developing a .NET background service using the Azure.Messaging.ServiceBus SDK to process payroll update messages from an Azure Service Bus queue named payroll-queue. The queue has sessions enabled.

The service must meet the following requirements:
- Process messages in the exact order they were sent within each session.
- Ensure that no message is lost if the background service encounters an unhandled exception during processing.
- Follow the principle of least privilege for security and access control.

Which two actions should you perform to implement these requirements? (Select two.)

Select all that apply

Call client.AcceptNextSessionAsync("payroll-queue") to obtain a session receiver.

Call receiver.CompleteMessageAsync(message) after the message is successfully processed.

Configure the receiver to use ServiceBusReceiveMode.ReceiveAndDelete to automatically delete messages upon retrieval.

Authenticate the client using a Shared Access Signature (SAS) token that has the Manage permission on the Service Bus namespace.

Configure the Azure Key Vault access policy to grant the service's identity only the Set permission to retrieve the Service Bus connection string.

Show answer & explanation

Answer: Call client.AcceptNextSessionAsync("payroll-queue") to obtain a session receiver.; Call receiver.CompleteMessageAsync(message) after the message is successfully processed.

Answer

To implement these requirements, you must obtain a session-enabled receiver using the AcceptNextSessionAsync method, and settle each message by calling CompleteMessageAsync after successful processing.

Accepting the next session ensures that messages with the same session ID are processed in sequence by a single receiver instance. Completing the message manually under PeekLock mode guarantees that if an unhandled exception occurs before completion, the lock will release and another instance can retry the message, ensuring zero message loss.

Step-by-Step Solution

Establish session-based message retrieval.

Call AcceptNextSessionAsync on the ServiceBusClient.

Because the queue has sessions enabled, standard receivers cannot read from it. A session receiver locks a specific session and ensures messages within that session are received sequentially.

Settle messages reliably to prevent data loss.

Process the message using the default PeekLock mode, then call CompleteMessageAsync.

PeekLock locks the message temporarily. If the processing fails or an unhandled exception occurs, the lock expires and the message is returned to the queue. Explicitly completing it deletes it only after successful execution.

Apply least privilege authentication.

Ensure the identity or token uses Listen-only permissions, and has Get permission on the Key Vault secrets.

Receiving messages requires only Listen permissions, and reading secrets from Key Vault requires Get permissions, maintaining a secure design.

Key Concept

Azure Service Bus sessions enable FIFO message ordering within a session context, which must be paired with PeekLock receive mode and explicit message settlement to ensure transactional reliability and prevent message loss.

Question 24Question →

You are designing an integration solution that uses Azure Queue Storage to process order messages. The application client must occasionally submit order details that exceed $64\text{ KB}$ up to a maximum of $1\text{ MB}$ . Additionally, the client requires temporary access to add messages to the queue, and this access must expire after $15\text{ minutes}$ .

Which two actions should you perform? (Select TWO.)

Select all that apply

Store payloads that exceed

64\text{ KB}

in Azure Blob Storage, and write the blob reference URL to the queue message.

Generate a service-level Shared Access Signature (SAS) token configured with only the Add permission and an expiration time of

15\text{ minutes}

Configure the queue properties in the Azure portal to allow a maximum message size of

1\text{ MB}

Generate an account-level Shared Access Signature (SAS) token configured with Read, Write, and Delete permissions and no expiration time.

Assign a system-assigned managed identity to the client and grant it the Owner role on the storage account resource.

Show answer & explanation

Answer: Store payloads that exceed $64\text{ KB}$ in Azure Blob Storage, and write the blob reference URL to the queue message.; Generate a service-level Shared Access Signature (SAS) token configured with only the Add permission and an expiration time of $15\text{ minutes}$ .

Answer

Store payloads that exceed

64\text{ KB}

in Azure Blob Storage, writing the blob reference URL to the queue message, and generate a service-level SAS token configured with only the Add permission and an expiration time of

15\text{ minutes}

To handle message sizes larger than

64\text{ KB}

(such as the

1\text{ MB}

payloads), you must use the Claim Check pattern: save the payload to Azure Blob Storage and write the corresponding blob URL to the queue message. To provide the client application with secure, temporary, and limited access to write messages to the queue, you should generate a service-level SAS token configured with the Add permission only, expiring after

15\text{ minutes}

Step-by-Step Solution

Evaluate the message size requirement.

Identify that because some payloads are up to

1\text{ MB}

(which exceeds the Azure Queue Storage limit of

64\text{ KB}

), a workaround is required.

Azure Queue Storage cannot directly store messages larger than

64\text{ KB}

Implement the Claim Check pattern.

Store the larger payload in Azure Blob Storage, and put its reference URL in the queue message.

This allows referencing large datasets while staying within the

64\text{ KB}

queue message size limit.

Determine the authentication mechanism for temporary write-only client access.

Create a service-level SAS token targeting the specific queue with the Add permission and an expiration window of

15\text{ minutes}

This implements the principle of least privilege (only write access to the queue) and enforces the temporal constraint.

Key Concept

Handling large queue messages using the Claim Check pattern and securing queue access using least-privilege SAS tokens.

Question 25Question →

A developer needs to push a locally built container image to an Azure Container Registry (ACR) named contosoacr. The developer has already logged into their Azure account on their workstation using the Azure CLI command az login. However, when they attempt to push the image, they receive an authentication error from the Docker daemon.

Which of the following Azure CLI commands should the developer run to authenticate the local Docker daemon to the registry?

az acr login --name contosoacr

docker login contosoacr.azurecr.io

az login --registry contosoacr

az acr login --name contosoacr --identity

Show answer & explanation

Answer: az acr login --name contosoacr

Answer

Run the command az acr login --name contosoacr to authenticate the local Docker daemon to the registry.

The command az acr login --name contosoacr uses the active Azure CLI session to fetch a token and configure the local Docker daemon. This allows the subsequent docker push command to authenticate successfully against the private container registry.

Step-by-Step Solution

Ensure the developer is signed in to Azure using the Azure CLI command az login.

The Azure CLI has an active authentication session on the workstation.

This provides the credentials necessary to access Azure resources, including the registry.

Run the command az acr login --name contosoacr.

The local Docker configuration is updated with credentials to access the registry.

This helper command bridges Azure CLI authentication with the Docker daemon configuration.

Execute the docker push command.

The container image is successfully pushed to the Azure Container Registry.

The Docker daemon is now authenticated and authorized to perform the push operation.

Key Concept

Authenticating a local developer workstation to Azure Container Registry using the Azure CLI.

Question 26Question →

You are developing a serverless API using Azure Functions. The API must scale automatically to handle traffic spikes, but it requires that instances are pre-warmed to completely avoid cold-start latency. Which hosting plan should you select?

Premium plan

Consumption plan

Shared App Service plan

Basic App Service plan

Show answer & explanation

Answer: Premium plan

Answer

Premium plan

The Premium plan is the correct choice because it offers the same dynamic scaling as the Consumption plan while ensuring that instances are kept pre-warmed to prevent cold starts.

Step-by-Step Solution

Identify the key requirements from the scenario.

The function app needs serverless automatic scaling and pre-warmed instances to eliminate cold start latency.

This determines which hosting plans meet both serverless scaling and zero cold start requirements.

Evaluate the capabilities of the Consumption plan.

The Consumption plan scales automatically but scales down to zero when idle, leading to cold starts on subsequent invocations.

This eliminates the Consumption plan as a valid option.

Evaluate the capabilities of the Premium plan.

The Premium plan scales automatically and maintains pre-warmed worker instances to avoid any cold start latency.

This confirms the Premium plan satisfies all criteria.

Key Concept

Azure Functions hosting plans capabilities and selection

Estimated Time:45s

Question 27Question →

You are deploying an ASP.NET Core web application to an Azure App Service Web App named app-prod-01. The application requires a secret named DbConnectionString stored in an Azure Key Vault named kv-prod-01. The Web App has a system-assigned managed identity that is already configured with a GET access policy on the key vault. You must configure the application settings in the Web App to reference the Key Vault secret without modifying the code. Which configuration format must you use for the value of the DbConnectionString application setting?

@Microsoft.KeyVault(VaultUri=https://kv-prod-01.vault.azure.net/secrets/DbConnectionString)

@Microsoft.KeyVault(VaultName=kv-prod-01;SecretName=DbConnectionString)

@Azure.KeyVault(SecretUri=https://kv-prod-01.vault.azure.net/secrets/DbConnectionString)

@Microsoft.KeyVault(VaultName=kv-prod-01,SecretName=DbConnectionString)

Show answer & explanation

Answer: @Microsoft.KeyVault(VaultName=kv-prod-01;SecretName=DbConnectionString)

Answer

The correct format is to use the key-value pair syntax with the @Microsoft.KeyVault prefix, specifying the VaultName and SecretName parameters separated by a semicolon.

The configuration syntax stating '@Microsoft.KeyVault(VaultName=kv-prod-01;SecretName=DbConnectionString)' is correct. App Service successfully parses this format, identifies the Key Vault resource by name, and fetches the secret using the web app's managed identity.

Step-by-Step Solution

Identify the mandatory prefix for App Service Key Vault references.

The prefix must be @Microsoft.KeyVault.

Azure App Service parses application settings looking for this exact prefix to resolve secrets dynamically.

Select the correct parameters and delimiter for referencing the vault and secret name directly.

Use VaultName and SecretName parameters delimited by a semicolon.

The key-value pair syntax uses semicolons to separate parameters inside the parentheses.

Validate the final format structure.

The final structure is @Microsoft.KeyVault(VaultName=kv-prod-01;SecretName=DbConnectionString).

This matches the official syntax rules for referencing Key Vault secrets within App Service settings without relying on a full URI.

Key Concept

Azure App Service Key Vault references allow applications to securely access secrets from a key vault through environment variables without code modifications.

Estimated Time:1m 30s

Question 28Question →

You are configuring an Azure Function App that runs on a Consumption hosting plan. You need to increase the execution timeout limit for all functions in the app to the maximum allowable duration under this hosting plan.

Which configuration should you apply to the host.json file?

Set the "functionTimeout" property to "00:30:00" in the host.json file.

Set the "functionTimeout" property to "-1" in the host.json file.

Set the "functionTimeout" property to "00:10:00" in the host.json file.

Set the "functionTimeout" property to "00:05:00" in the host.json file.

Show answer & explanation

Answer: Set the "functionTimeout" property to "00:10:00" in the host.json file.

Answer

Set the "functionTimeout" property to "00:10:00" in the host.json file.

The configuration setting the property to 10 minutes ('00:10:00') is correct. Under the Consumption hosting plan, Azure Functions are limited to a maximum execution duration of 10 minutes, up from the default of 5 minutes.

Step-by-Step Solution

Identify the hosting plan constraints.

The function app runs on the Consumption plan, which has a default timeout of 5 minutes and a maximum hard limit of 10 minutes.

Knowing hosting plan limits is necessary to determine the maximum value that can be successfully configured.

Determine the host.json property used for configuring timeouts.

The correct property to configure function timeouts globally is "functionTimeout".

This property controls execution timeout behavior for all functions within the function app.

Format the timeout duration correctly.

The duration must be specified in a timespan format (HH:MM:SS), resulting in "00:10:00".

Azure Functions configuration parser requires timespan formatting for duration properties.

Key Concept

Azure Functions Consumption plan timeout configuration

Question 29Question →

Your company deploys an Azure App Service web app named webapp-prod. The web app must retrieve a database connection string securely from an Azure Key Vault named kv-prod. You configure a user-assigned managed identity named id-webapp for webapp-prod and grant it the Key Vault Secrets User role on kv-prod. You need to configure the App Service application settings so that the web app can retrieve the latest version of the secret named DbConnectionString using the user-assigned identity. Which of the following configurations should you apply to the App Service application settings?

Configure the DbConnectionString setting with the value @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString;Identity=id-webapp).

Configure the DbConnectionString setting with the value @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString) and add an application setting named managedIdentityClientId set to the client ID of the user-assigned managed identity.

Configure the DbConnectionString setting with the value @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString) and add an application setting named keyVaultReferenceIdentity set to the resource ID of the user-assigned managed identity.

Configure the DbConnectionString setting with the value @Microsoft.KeyVault(SecretUrl=https://kv-prod.vault.azure.net/secrets/DbConnectionString) and add an application setting named keyVaultReferenceIdentity set to the resource ID of the user-assigned managed identity.

Show answer & explanation

Answer: Configure the DbConnectionString setting with the value @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString) and add an application setting named keyVaultReferenceIdentity set to the resource ID of the user-assigned managed identity.

Answer

Configure the DbConnectionString setting with the value @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString) and add an application setting named keyVaultReferenceIdentity set to the resource ID of the user-assigned managed identity.

The correct configuration uses the standard `@Microsoft.KeyVault(SecretUri=...)` syntax to point to the secret URI. Additionally, because the application uses a user-assigned managed identity, the `keyVaultReferenceIdentity` application setting must be added, with its value set to the resource ID of that user-assigned managed identity, to let App Service know which identity to use to authenticate to the Key Vault.

Step-by-Step Solution

Define the Key Vault reference in the application setting value.

The application setting is defined as @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbConnectionString).

This uses the correct syntax and standard SecretUri parameter format to tell App Service where to retrieve the secret.

Configure App Service to use the user-assigned managed identity for resolution.

The keyVaultReferenceIdentity application setting is added with the user-assigned managed identity's resource ID as its value.

By default, App Service attempts to use the system-assigned identity. To use a user-assigned identity, you must set the keyVaultReferenceIdentity app setting to point to the resource ID of the user-assigned identity.

Key Concept

Key Vault references in Azure App Service allow applications to securely retrieve secrets without exposing them in configuration. When using user-assigned managed identities, you must configure the keyVaultReferenceIdentity setting alongside the reference.

Estimated Time:2m 0s

Question 30Question →

You are configuring a continuous integration pipeline in GitHub Actions to build and push a container image to an Azure Container Registry (ACR) named contosoacr.azurecr.io. The runner does not have the Azure CLI installed, but has the Docker CLI installed. You have created an Azure Active Directory (Azure AD) service principal with the AcrPush role.

You need to authenticate the Docker CLI on the runner to contosoacr.azurecr.io using the service principal credentials.

Which command should you execute in the pipeline runner?

az acr login --name contosoacr --username <clientId> --password <clientSecret>

echo <clientSecret> | docker login contosoacr --username <clientId> --password-stdin

echo <clientSecret> | docker login contosoacr.azurecr.io --username <clientId> --password-stdin

Configure a system-assigned managed identity for the GitHub-hosted runner, and run az acr login --name contosoacr without credentials.

Show answer & explanation

Answer: echo <clientSecret> | docker login contosoacr.azurecr.io --username <clientId> --password-stdin

Answer

Run the command: echo <clientSecret> | docker login contosoacr.azurecr.io --username <clientId> --password-stdin

To authenticate the Docker CLI with an Azure Container Registry using a service principal when the Azure CLI is unavailable, you must use the standard docker login command. The username must be the service principal's Client ID, the password must be the Client Secret, and the target registry must be specified by its repository login server domain name.

Step-by-Step Solution

Identify the target registry URL and the authentication tools available.

The target registry is contosoacr.azurecr.io, and only the Docker CLI is available on the runner.

The runner does not have Azure CLI installed, meaning az acr commands cannot be executed.

Formulate the Docker login command using the service principal credentials.

Use the client ID as the username and the client secret as the password targeting contosoacr.azurecr.io.

The Docker CLI requires the full login server domain to route the authentication request to Azure Container Registry rather than Docker Hub.

Securely pass the client secret to the Docker login command.

Pipe the client secret into docker login using the --password-stdin flag.

Passing passwords directly via command line arguments is insecure and can expose credentials in build logs.

Key Concept

Authenticating to Azure Container Registry using Docker CLI and service principal credentials.

Question 31Question →

You are a developer managing container images in Azure. You need to copy a container image named application:v1 from a development Azure Container Registry named devreg to a production Azure Container Registry named prodreg. Both registries are in the same Azure subscription. To save network bandwidth and time, you want to perform this copy directly from registry to registry, without downloading the image to your local workspace or requiring a local Docker installation. Which Azure CLI command should you run?

docker pull devreg.azurecr.io/application:v1 followed by tagging and pushing the image to prodreg.azurecr.io

az acr build --registry prodreg --image application:v1 https://devreg.azurecr.io/application:v1

az acr import --name prodreg --source devreg.azurecr.io/application:v1 --image application:v1

Enable a system-assigned managed identity on devreg and grant it push access to prodreg, then run az acr login --name prodreg --identity

Show answer & explanation

Answer: az acr import --name prodreg --source devreg.azurecr.io/application:v1 --image application:v1

Answer

Run the command: az acr import --name prodreg --source devreg.azurecr.io/application:v1 --image application:v1

The correct command is the one starting with 'az acr import', as it enables registry-to-registry import directly in the cloud without downloading the image or requiring a local Docker installation.

Step-by-Step Solution

Identify the target registry name and the fully qualified source image path.

Target registry is 'prodreg', source image path is 'devreg.azurecr.io/application:v1'.

The import command requires the destination registry name and the source image identifier.

Select the correct Azure CLI command for registry-to-registry image copying.

The correct command is 'az acr import'.

This command performs a registry-to-registry import entirely in the cloud without downloading image layers locally.

Construct and execute the command specifying the target registry, source registry/image, and target image name/tag.

The final command is: az acr import --name prodreg --source devreg.azurecr.io/application:v1 --image application:v1

This provides all required parameters to copy the image directly on the Azure backend.

Key Concept

Direct registry-to-registry container image importing in Azure Container Registry

Question 32Question →

You are designing an automated deployment for a batch processing workload using Azure Container Instances (ACI). The workload has the following requirements:

1. It must run two containers: a file downloader (producer) and a data analyzer (consumer).
2. Both containers must share a temporary directory that only needs to persist during the lifecycle of the container group.
3. The container images are hosted in a private Azure Container Registry (ACR).
4. The consumer container must securely retrieve a database connection string from an Azure Key Vault.
5. The container group must be deployed inside a subnet of an existing Azure Virtual Network to connect to a private database.

Which three actions should you perform to meet these requirements?

Select all that apply

Delegate the target subnet within the Azure Virtual Network to the Microsoft.ContainerInstance/containerGroups service before deployment.

Configure a shared volume of type emptyDir in the container group YAML definition and mount it to both the producer and consumer containers.

Create a user-assigned managed identity, grant it the AcrPull role on the Azure Container Registry, and configure the container group to pull images using this identity.

Enable a system-assigned managed identity on the container group and grant it the AcrPull role on the Azure Container Registry to authenticate image pulls.

Run the az acr login command in the local Azure CLI session to automatically authorize the Azure Container Instances service host to pull registry images.

Grant the container group's managed identity the Set and Delete secret permissions in the Azure Key Vault access policies to retrieve the database credentials.

Show answer & explanation

Answer: Delegate the target subnet within the Azure Virtual Network to the Microsoft.ContainerInstance/containerGroups service before deployment.; Configure a shared volume of type emptyDir in the container group YAML definition and mount it to both the producer and consumer containers.; Create a user-assigned managed identity, grant it the AcrPull role on the Azure Container Registry, and configure the container group to pull images using this identity.

Answer

To deploy the solution, you must delegate the virtual network subnet to the container group service, configure an emptyDir volume for ephemeral shared storage, and configure a user-assigned managed identity with the AcrPull role on the private Azure Container Registry to authorize the image pull.

Delegating the subnet to the ACI service is required for VNet integration. Using an emptyDir volume provides shared, ephemeral file storage between containers in the same container group. Using a user-assigned managed identity with the AcrPull role is required because system-assigned identities do not exist in time to authorize the initial image pull during deployment.

Step-by-Step Solution

Configure the virtual network by delegating a subnet to the Microsoft.ContainerInstance/containerGroups service resource type.

The subnet is reserved and configured to host Azure Container Instance container groups.

VNet integration for ACI requires a dedicated subnet that does not host other resource types.

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

The identity has the permission to pull images from the registry.

Since ACI must pull the image before creating the container group, a pre-existing user-assigned identity is required for authentication.

Define the container group in YAML or an ARM template, configuring an emptyDir volume and mounting it to both containers.

The containers share a temporary folder that persists for the lifecycle of the container group.

An emptyDir volume provides a shared, non-persistent directory suitable for temporary multi-container processing workloads.

Key Concept

Azure Container Instances networking, volumes, and private registry authentication

Question 33Question →

Your company is deploying a web application to Azure App Service. The application requires a database connection string that is stored securely as a secret named 'db-conn' in an Azure Key Vault named 'kv-prod'. You need to configure the web app's application settings to reference this Key Vault secret using its name. Which value should you use for the application setting?

@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-conn)

@Microsoft.KeyVault(VaultName=kv-prod,SecretName=db-conn)

https://kv-prod.vault.azure.net/secrets/db-conn

@KeyVault(VaultName=kv-prod;SecretName=db-conn)

Show answer & explanation

Answer: @Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-conn)

Answer

The correct reference format is '@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-conn)' because it uses the correct prefix, encloses the parameters in parentheses, and separates the VaultName and SecretName parameters with a semicolon.

The correct option is the one specifying '@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-conn)'. In Azure App Service, Key Vault references in application settings must start with the '@Microsoft.KeyVault' prefix, enclose the properties in parentheses, and use a semicolon as the delimiter between key-value pairs like VaultName and SecretName.

Step-by-Step Solution

Identify the required prefix for Key Vault references in Azure App Service application settings.

The prefix must be '@Microsoft.KeyVault'.

Azure App Service parses application setting values starting with '@Microsoft.KeyVault' to retrieve secrets at runtime.

Determine the parameter format when referencing a secret by the vault name and secret name.

The syntax requires 'VaultName=vault-name;SecretName=secret-name' inside the parentheses.

Parameters must be specified using key-value pairs separated by a semicolon.

Construct the final reference string with the given vault 'kv-prod' and secret 'db-conn'.

'@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-conn)'

This matches the requirements of prefix, parameter names, semicolon separator, and parentheses wrapping.

Key Concept

Azure Key Vault references in Azure App Service Application Settings

Estimated Time:45s

Question 34Question →

You are configuring a CI/CD pipeline script to push container images to an Azure Container Registry (ACR) named `myregistry`. The script runs in a lightweight container context where only the Docker CLI is available for the build and push steps. To authenticate, you have already retrieved a Microsoft Entra ID access token for the registry using the Azure CLI and stored it in a variable named `$TOKEN`.

You need to run the `docker login` command to authenticate the local Docker daemon to the registry using this token.

Which command should you run?

docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password $TOKEN

docker login myregistry.azurecr.io --username myregistry --password $TOKEN

docker login myregistry.azurecr.io --username <Managed-Identity-Client-ID> --password $TOKEN

az acr login --name myregistry --username 00000000-0000-0000-0000-000000000000 --password $TOKEN

Show answer & explanation

Answer: docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password $TOKEN

Answer

docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password $TOKEN

The correct command uses the docker login utility to target the myregistry.azurecr.io login server. When authenticating with an access token (such as a Microsoft Entra ID token), the registry requires the username parameter to be the specific GUID 00000000-0000-0000-0000-000000000000, and the password parameter to contain the token value.

Step-by-Step Solution

Identify the registry's login server URL.

The login server URL for an ACR named myregistry is myregistry.azurecr.io.

The docker login command requires the full login server URL rather than just the registry name.

Determine the correct username for token-based authentication.

The designated username GUID is 00000000-0000-0000-0000-000000000000.

ACR requires the specific token GUID as the username when authenticating via an access token.

Formulate and run the docker login command.

docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password $TOKEN

This successfully logs the local Docker daemon into the target Azure Container Registry using the retrieved token.

Key Concept

Authenticating with Azure Container Registry using tokens

Question 35Question →

An organization is designing a serverless background processing solution using Azure Functions V4 to process large batches of files uploaded to an Azure Blob Storage container. The solution must satisfy the following constraints:
- Individual file processing operations are CPU-intensive and can take up to 15 minutes to complete.
- The function app must connect securely to an Azure SQL Database that is restricted to a private virtual network.
- The system must dynamically scale out the number of instances to handle sudden, unpredictable spikes in upload volume, and scale back down when idle.
- Cold start latency must be minimized for initial requests after periods of inactivity.

Which hosting plan should the organization choose to deploy the Azure Function app?

Premium plan

Consumption plan

Dedicated (App Service) plan

Consumption plan with Azure App Service Environment (ASE)

Show answer & explanation

Answer: Premium plan

Answer

Premium plan

The Premium plan is the correct choice because it supports outbound virtual network integration, has a default execution timeout of 30 minutes (unbounded maximum), and provides event-based scaling via the Scale Controller to rapidly handle spikes while minimizing cold starts with pre-warmed instances.

Step-by-Step Solution

Evaluate the runtime execution limit requirement.

The Consumption plan has a strict 10-minute maximum execution limit, which rules it out since processing can take up to 15 minutes.

Azure Functions hosting plans have different default and maximum execution timeouts.

Evaluate the network connectivity requirement.

The basic Consumption plan does not support virtual network integration, further ruling it out.

Securing database access behind a private virtual network requires a plan that supports outbound VNet integration.

Compare scaling behaviors of the Premium and Dedicated plans.

The Dedicated plan scales based on standard autoscale rules (e.g., CPU/Memory metrics), whereas the Premium plan scales rapidly based on events (e.g., number of blobs/messages) via the Scale Controller and provides pre-warmed instances to prevent cold starts.

Unpredictable spikes require the event-driven Scale Controller to add instances dynamically and proactively.

Key Concept

Azure Functions hosting plan features and limits, focusing on execution timeouts, network integration, and scaling behaviors.

Question 36Question →

You are configuring an Azure Container Registry (ACR) task named `build-task` in a registry named `myregistry`. The task must build a container image from a remote GitHub repository and push it to `myregistry`. The build process requires pulling a private base image from an external Azure Container Registry named `sharedregistry.azurecr.io`.

You create a user-assigned managed identity named `task-identity` and assign it the `AcrPull` role on `sharedregistry.azurecr.io`.

You associate the identity with the task by running the following command:
azurecli
az acr task create \
--registry myregistry \
--name build-task \
--image myimage:latest \
--context https://github.com/myorg/myrepo.git#main \
--file Dockerfile \
--assign-identity /subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/myrg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/task-identity

When the task executes, the build fails during the base image pull from `sharedregistry.azurecr.io` with an HTTP 401 Unauthorized error.

Which command should you execute to enable the task to authenticate successfully to the external registry?

az acr task credential add --name build-task --registry myregistry --login-server sharedregistry.azurecr.io --user-assigned-identity 11111111-1111-1111-1111-111111111111

Add a RUN az acr login --name sharedregistry.azurecr.io instruction inside the Dockerfile before the FROM instruction

az acr task update --name build-task --registry myregistry --auth-mode ManagedIdentity

az acr task credential add --name build-task --registry myregistry --login-server sharedregistry.azurecr.io --use-system-assigned

Show answer & explanation

Answer: az acr task credential add --name build-task --registry myregistry --login-server sharedregistry.azurecr.io --user-assigned-identity 11111111-1111-1111-1111-111111111111

Answer

Execute the command: az acr task credential add --name build-task --registry myregistry --login-server sharedregistry.azurecr.io --user-assigned-identity 11111111-1111-1111-1111-111111111111

Executing the command that adds the credential with the user-assigned managed identity client ID matches the target login server to the identity. When ACR Tasks initiates the build and pulls the base image from the external login server, it retrieves an OAuth token representing the user-assigned managed identity to authenticate the pull request.

Step-by-Step Solution

Identify the authentication failure source

The task fails when trying to pull the base image from the external registry sharedregistry.azurecr.io because it lacks credentials for it.

By default, the task only has built-in credentials for its home registry, not for external registries.

Determine the authentication mechanism

The task must use the user-assigned managed identity to authenticate to the external registry.

The user-assigned managed identity has already been granted the AcrPull role on the external registry.

Map the identity to the external registry in the task configuration

Execute the az acr task credential add command, specifying the home registry, task name, target login server, and the client ID of the user-assigned managed identity.

This registers the credentials within the ACR Task context so it can automatically inject the managed identity token when communicating with the external registry.

Key Concept

ACR Tasks cross-registry authentication using managed identities

Question 37Question →

You are designing an Azure Function app (Runtime version 4.x) that processes sensitive financial transactions from an Azure Service Bus queue. The function requires outbound connectivity to an Azure SQL Database secured behind a private endpoint in a virtual network (VNet). The transaction processing logic is resource-intensive, requiring up to 25 minutes to complete per batch, and must avoid any cold start latency to meet strict Service Level Agreements (SLAs). Additionally, you must ensure that the function app does not scale beyond 20 concurrent VM instances to prevent connection pool exhaustion on the database. Which hosting plan and scale configuration should you implement to meet these requirements?

Deploy the function app to an Elastic Premium plan. Configure outbound virtual network integration, set the function app timeout (functionTimeout in host.json) to 30 minutes, and set the functionAppScaleLimit property of the function app to 20.

Deploy the function app to a Consumption plan. Configure outbound virtual network integration, set the function app timeout (functionTimeout in host.json) to 30 minutes, and set the WEBSITE_MAX_DYNAMIC_SCALE_OUT application setting to 20.

Deploy the function app to a Dedicated (App Service) plan with Always On enabled. Configure outbound virtual network integration, and configure the maxConcurrentCalls setting to 20 in the host.json configuration file.

Deploy the function app to an Elastic Premium plan. Configure outbound virtual network integration, set the function app timeout (functionTimeout in host.json) to 30 minutes, and set the WEBSITE_MAX_DYNAMIC_SCALE_OUT application setting to 20.

Show answer & explanation

Answer: Deploy the function app to an Elastic Premium plan. Configure outbound virtual network integration, set the function app timeout (functionTimeout in host.json) to 30 minutes, and set the functionAppScaleLimit property of the function app to 20.

Answer

Deploy the function app to an Elastic Premium plan, configure outbound virtual network integration, set the timeout to 30 minutes, and set the functionAppScaleLimit property of the function app resource to 20.

The correct option correctly pairs the Elastic Premium plan—which provides outbound VNet integration, pre-warmed instances to avoid cold starts, and a configurable timeout limit beyond 10 minutes—with the functionAppScaleLimit property, which is the platform-supported way to cap instance scale-out on Premium plans.

Step-by-Step Solution

Evaluate hosting plans based on execution duration.

The Consumption plan has a hard limit of 10 minutes for execution duration, which rules it out since the batch process takes 25 minutes. Both the Elastic Premium plan and Dedicated (App Service) plan support execution limits that can accommodate 25 minutes.

Choosing a plan that supports long-running executions prevents premature function timeouts.

Evaluate hosting plans based on network integration and cold start requirements.

The Elastic Premium plan and Dedicated plan both support regional outbound virtual network integration to reach the secured database. They also both support cold-start mitigation (via pre-warmed instances and Always On respectively), but the Premium plan offers serverless dynamic scaling that scales to zero when idle.

VNet integration is necessary for connecting to private endpoints, and pre-warmed instances ensure the first execution starts immediately.

Determine the correct scaling limit configuration method.

To restrict the number of instances for an Elastic Premium plan, the functionAppScaleLimit property on the function app resource must be set to 20. The WEBSITE_MAX_DYNAMIC_SCALE_OUT app setting only works on the Consumption plan. The maxConcurrentCalls setting in host.json only restricts per-instance concurrency, not VM scaling.

Configuring the correct scale limit property ensures that the function scaling behavior matches the platform configuration guidelines for the selected hosting plan.

Key Concept

Azure Functions hosting plans, execution timeouts, VNet integration, and scale-out configurations.

Question 38Question →

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

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.

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.

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.

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

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

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.

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.

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.

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.

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

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

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.

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.

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.

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.

PreviousPage 2 / 49Next

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