Examkin

All practice questions

972 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 41Question →

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

Which five actions should you perform in sequence to configure the Function App? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

An Azure App Service plan currently hosts a single instance of a web application. You configure a scale-out rule to add one instance to the plan when the average CPU usage exceeds 80%80\% for 1010 minutes. You need to configure a scale-in rule to remove one instance when the traffic decreases. Assuming the workload is distributed evenly across all instances after scaling out, which of the following is the maximum CPU threshold you should set for the scale-in rule to prevent autoscale flapping?

Show answer & explanation

Answer: 35%35\%

Answer

The maximum CPU threshold for the scale-in rule should be set to 35%35\% to prevent autoscale flapping.
When the web app is running on a single instance and CPU usage hits 80%80\%, the scale-out rule triggers, increasing the instance count to two. Since the workload is distributed evenly, the CPU usage on each of the two instances will drop to approximately half of the total load: 80%÷2=40%80\% \div 2 = 40\%. If the scale-in threshold is set to 40%40\% or higher, the new CPU usage level of 40%40\% will immediately satisfy the scale-in condition. This triggers a scale-in back to one instance, causing the CPU usage to spike back to 80%80\%, triggering another scale-out, and creating an infinite loop (flapping). To prevent this, the scale-in threshold must be set below the expected post-scale-out CPU usage. A threshold of 35%35\% is strictly below 40%40\% and will prevent flapping.

Step-by-Step Solution

1
Calculate the expected CPU usage per instance after a scale-out event.
With one instance scaling out to two instances under an 80%80\% CPU load, the expected CPU per instance is 80%×12=40%80\% \times \frac{1}{2} = 40\%.
This determines the new operating baseline CPU level immediately after the scale-out action occurs.
2
Analyze the flapping condition for scale-in thresholds.
To prevent immediate scale-in, the scale-in threshold must be strictly less than the post-scale-out CPU level of 40%40\%.
If the scale-in threshold is equal to or greater than the post-scale-out CPU usage, the scale-in rule triggers immediately, causing a loop.
3
Identify the correct option that satisfies the condition.
A threshold of 35%35\% is selected since 35%<40%35\% < 40\%, while all other options are greater than or equal to 40%40\%.
This is the only threshold configuration that successfully avoids autoscale flapping.

Key Concept

App Service Autoscale Rule Metric Configuration and Flapping Prevention
Question 44Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

You are developing a Go-based web service that needs to be hosted as an Azure Function. You plan to use a custom handler. You need to configure your local project environment for the custom handler before deploying it to Azure. Which four actions should you perform in sequence to set up the project? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

You are managing container images in an Azure Container Registry (ACR) named `contosoregistry`. You need to configure the registry to meet the following requirements for an image named `payment-service:v2`:

* Prevent the image from being deleted.
* Prevent the image from being overwritten by subsequent build pipelines.
* Allow deployments to continue pulling the image.

Which two Azure CLI commands should you run to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: az acr repository update --name contosoregistry --image payment-service:v2 --delete-enabled false; az acr repository update --name contosoregistry --image payment-service:v2 --write-enabled false

Answer

Run `az acr repository update` with `--delete-enabled false` to prevent deletion and `--write-enabled false` to prevent overwriting, while ensuring read operations are not disabled.
To protect a container image in Azure Container Registry from deletion, you must disable delete operations using the `--delete-enabled false` parameter. To protect it from being overwritten (which is a write operation), you must disable write operations using the `--write-enabled false` parameter. Since pulling requires read access, the `--read-enabled` parameter must not be disabled.

Step-by-Step Solution

1
Disable delete operations on the specific image tag
The command `az acr repository update --name contosoregistry --image payment-service:v2 --delete-enabled false` is executed, preventing the image from being deleted.
This directly fulfills the requirement to prevent accidental deletion.
2
Disable write operations on the specific image tag
The command `az acr repository update --name contosoregistry --image payment-service:v2 --write-enabled false` is executed, preventing the image from being overwritten.
This directly fulfills the requirement to prevent subsequent build pipelines from overwriting the image.
3
Ensure read operations remain enabled
Do not set `--read-enabled false`.
This ensures the image can still be pulled for deployments.

Key Concept

Locking container images in Azure Container Registry (ACR) to enforce immutability and prevent deletion or overwriting.
Estimated Time:2m 0s
Question 49Question →

You are deploying a containerized application to Azure Container Instances (ACI). The container needs to retrieve secrets from an Azure Key Vault at runtime. You have successfully enabled a system-assigned managed identity for the ACI container group. Which of the following actions must you perform to allow the container group to retrieve the secrets from the key vault?

Show answer & explanation

Answer: Grant the system-assigned managed identity GET permission to secrets in the Azure Key Vault access policies or Azure RBAC.

Answer

Grant the system-assigned managed identity GET permission to secrets in the Azure Key Vault access policies or Azure RBAC.
To retrieve secrets from Azure Key Vault, the container's managed identity must be granted the necessary permissions (such as GET/LIST) in the Key Vault access policies or via Azure RBAC. Enabling the identity only registers it with Microsoft Entra ID; it does not grant permissions by default.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the Azure Container Instances (ACI) container group.
The container group receives an identity registered in Microsoft Entra ID.
This establishes a security identity for ACI without needing hardcoded credentials in the deployment configuration.
2
Configure Azure Key Vault access policies or Azure RBAC roles.
The identity is authorized to access secrets.
By default, the managed identity has no permissions, so you must explicitly grant it GET permission to read secrets.
3
Access the Key Vault from the application code within the container.
The application successfully retrieves the secret.
The code uses Azure SDKs (e.g., DefaultAzureCredential) to authenticate using the environment's managed identity and retrieve the secret.

Key Concept

Configuring access policies or RBAC roles to grant an ACI managed identity access to Azure Key Vault secrets.
Estimated Time:1m 0s
Question 50Question →

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

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

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

Which sequence of actions should you perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

A developer deploys a web application to an Azure App Service Web App. The developer configures an application setting named DbPassword to reference a secret in Azure Key Vault. The syntax of the reference is verified as correct. However, at runtime, the application cannot retrieve the password and displays an authorization error. Which of the following is the most likely cause of this error?

Show answer & explanation

Answer: The App Service Web App's managed identity has not been granted Get secret permissions in the Key Vault access policies.

Answer

The App Service Web App's managed identity has not been granted Get secret permissions in the Key Vault access policies.
The correct answer is correct because Azure App Service requires the web app's managed identity (either system-assigned or user-assigned) to have GET secret permissions on the Azure Key Vault access policies to successfully resolve Key Vault references at runtime. Without this permission, the app cannot retrieve the secret value.

Step-by-Step Solution

1
Verify the syntax of the Key Vault reference in the App Service application settings.
The syntax is verified as correct, ruling out syntax errors.
Ensures that the application setting is properly directed to the Key Vault secret.
2
Check the identity configuration of the Web App and the corresponding access policies in the Key Vault.
The identity is enabled but lacks the GET permission in Key Vault.
App Service requires explicit authorization to read Key Vault secrets using its managed identity.
3
Grant the GET permission to the Web App's managed identity in the Key Vault access policies.
The Web App successfully retrieves and resolves the secret value at runtime.
Allows the App Service host to authenticate and retrieve the secret on behalf of the application.

Key Concept

Key Vault references in Azure App Service allow web apps to retrieve secrets using managed identities, which requires proper access policies (GET permissions) on the Key Vault.
Question 53Question →

You have a private Azure Container Registry named registry2026. You need to copy a public container image named redis:alpine from Docker Hub directly into your registry without pulling it to your local development machine first. Which of the following Azure CLI commands should you run?

Show answer & explanation

Answer: az acr import --name registry2026 --source docker.io/library/redis:alpine --image redis:alpine

Answer

Use the az acr import command specifying the registry name, the source image from Docker Hub, and the target image name.
The command starting with 'az acr import' is correct because it uses the Azure Container Registry import capability to copy an image directly from Docker Hub (docker.io) into the specified registry. This bypasses the need to install Docker locally, pull the image, authenticate, tag the image, and push it.

Step-by-Step Solution

1
Identify the target container registry and the source image registry path.
Target registry is registry2026 and source image path is docker.io/library/redis:alpine.
Knowing the correct source and destination identifiers is necessary to construct the command.
2
Select the Azure CLI command designed for direct network-to-network registry image copying.
The az acr import command is identified.
This command avoids pulling the image locally to a developer workstation and then pushing it back up to Azure.
3
Construct and execute the command with the correct parameters.
az acr import --name registry2026 --source docker.io/library/redis:alpine --image redis:alpine is executed.
This copies the image directly within the Azure backbone from Docker Hub to the specified Container Registry.

Key Concept

Directly importing container images from public or external registries into an Azure Container Registry using the Azure CLI.
Question 54Question →

You are configuring a new Azure Function App that must retrieve secrets from Azure Key Vault. According to your organization's security policy, you must ensure that no credentials, tokens, or connection strings are stored directly in the Function App's configuration settings or code. Which Azure feature should you enable for the Function App to authenticate and gain access to the Key Vault?

Show answer & explanation

Answer: A system-assigned managed identity for the Function App

Answer

A system-assigned managed identity for the Function App
Enabling a system-assigned managed identity creates a security principal in Microsoft Entra ID that is uniquely tied to the Azure Function App. The Function App can use this identity to authenticate to Key Vault and other Azure services without needing to store or manage credentials in settings or code.

Step-by-Step Solution

1
Analyze the security constraints.
The Function App must access the Key Vault without storing any credentials or secrets in its configuration settings or source code.
This rules out authentication methods that rely on shared keys, connection strings, or static SAS tokens.
2
Select the correct identity mechanism.
A system-assigned managed identity is enabled directly on the Function App.
This provides the application with an identity in Microsoft Entra ID that is automatically managed and tied to the lifecycle of the Function App resource.
3
Configure permissions on the target resource.
Grant the system-assigned managed identity GET secret permissions on the Key Vault.
This allows the Function App to authenticate securely and authorizes it to read the required secrets.

Key Concept

Configuring managed identities for Azure Functions to secure resource access
Estimated Time:1m 0s
Question 55Question →

You are configuring a deployment pipeline on a non-Azure container runner that needs to push images to an Azure Container Registry (ACR) named registry2026.azurecr.io. The runner does not have the Azure CLI installed. You create a repository-scoped token named pipeline-token that has permissions restricted to the target repository. Which command and credentials should you use to authenticate the container runner with the registry?

Show answer & explanation

Answer: Run `docker login registry2026.azurecr.io` using `pipeline-token` as the username and one of the generated passwords as the password.

Answer

Run `docker login registry2026.azurecr.io` using `pipeline-token` as the username and one of the generated passwords as the password.
The correct answer is to run the standard `docker login` command targeting the fully qualified registry name (`registry2026.azurecr.io`) using the token name (`pipeline-token`) as the username and one of the generated secret passwords as the password. This provides secure, scoped access without needing the Azure CLI or broad admin credentials on a non-Azure runner.

Step-by-Step Solution

1
Identify the authentication requirements of the container runner.
The runner is a non-Azure resource and does not have the Azure CLI installed, meaning standard Azure CLI authentication methods (like `az acr login`) cannot be used.
This establishes that we must use standard Docker CLI commands (`docker login`) with explicit credentials.
2
Determine the proper login server name.
The login server name is `registry2026.azurecr.io`.
Docker CLI commands require the fully qualified registry domain name rather than just the registry name prefix.
3
Apply repository-scoped token authentication rules.
For repository-scoped tokens, the token name (`pipeline-token`) acts as the username, and the generated token password acts as the password.
This complies with the Azure Container Registry token-based authentication specification.

Key Concept

Azure Container Registry repository-scoped token authentication via Docker CLI
Estimated Time:1m 30s
Question 56Question →

You are designing an Azure Function App that will host critical HTTP-triggered APIs. The APIs must securely access an Azure SQL Database that is restricted to a private virtual network. To ensure optimal performance, the Function App must scale out dynamically to handle traffic spikes while avoiding cold-start latency. Which hosting plan should you configure for the Function App?

Show answer & explanation

Answer: Premium plan

Answer

Premium plan
The Premium plan (often called Elastic Premium) supports regional virtual network integration, enabling the Function App to securely connect to private databases. Additionally, it supports pre-warmed instances, which guarantees that new instances are already initialized and ready to process requests, thereby avoiding cold-start latency during scaling.

Step-by-Step Solution

1
Analyze the networking requirement.
Virtual network (VNet) integration is required to access the secure Azure SQL Database.
The Consumption plan does not support VNet integration, which rules it out.
2
Analyze the performance requirement.
Pre-warmed instances are required to eliminate cold-start latency during dynamic scale-out.
The Premium plan maintains pre-warmed instances, whereas the Dedicated plan relies on standard VM scale-out which is slower and does not use the Functions-specific pre-warmed instances.
3
Select the plan that satisfies both networking and scaling requirements.
The Premium plan (Elastic Premium) supports both regional VNet integration and pre-warmed instances.
This is the only serverless hosting plan option that meets all specified requirements.

Key Concept

Azure Functions hosting plan selection based on networking and cold-start requirements
Question 57Question →

You need to build a container image and push it to an Azure Container Registry named `acrdemo` using the Azure CLI. You want to run the build in Azure Container Registry (ACR) without using a local container engine or daemon. The Dockerfile is located in your current local directory. Which two parameters or arguments must you specify in the `az acr build` command?

Select all that apply

Show answer & explanation

Answer: The --registry parameter (or -r) followed by the registry name; The path to the source directory, such as a period (.) to represent the current directory

Answer

To build an image using Azure Container Registry Tasks from a local directory, you must run the 'az acr build' command and specify the registry name (using the --registry parameter) and the path to the source files (such as the current directory '.').
To run the az acr build command, you must specify the destination registry via the --registry parameter and the source directory path (such as the period representing the current directory). The command sends the source context to the registry, builds the image, and pushes it automatically.

Step-by-Step Solution

1
Ensure the Azure CLI is logged in and has access to the target Azure Container Registry.
Your active command-line session is authenticated with Azure.
The build command uses the CLI session's context automatically, eliminating the need for a separate login parameter.
2
Identify the target container registry and the directory containing the Dockerfile.
You have the registry name (acrdemo) and the source directory path (e.g., '.').
These two arguments are mandatory inputs for the az acr build command.
3
Construct and run the command: az acr build --registry acrdemo .
The local source context is packaged, sent to the ACR instance, built according to the Dockerfile, and the resulting image is pushed to the registry.
This executes the remote build without requiring a local Docker container engine.

Key Concept

Azure Container Registry (ACR) Tasks allow developers to offload container image builds to Azure, removing the need for a local Docker installation. The 'az acr build' command requires the target registry name and the source directory context to run.
Question 58Question →

You are developing an Azure App Service web app named webapp-prod that has a deployment slot named staging. The application uses an app setting named DbConnection to store its database connection string. You need to configure the application so that the DbConnection setting remains slot-specific and does not change slots during a swap operation. Which Azure CLI command should you run?

Show answer & explanation

Answer: az webapp config slot-settings set --name webapp-prod --resource-group rg-prod --app-settings DbConnection

Answer

The command 'az webapp config slot-settings set --name webapp-prod --resource-group rg-prod --app-settings DbConnection' is correct.
The correct command uses the 'az webapp config slot-settings set' command with the '--app-settings' parameter to specify that the 'DbConnection' setting should remain sticky to the slot and not be swapped.

Step-by-Step Solution

1
Identify the type of setting to make slot-specific.
The setting is defined as an app setting (DbConnection) rather than a connection string.
This determines whether to use the --app-settings or --connection-strings parameter.
2
Select the correct Azure CLI subgroup for configuring slot-specific (sticky) settings.
The correct subgroup is 'az webapp config slot-settings'.
Standard 'az webapp config appsettings' is for editing app setting values, not for configuring stickiness.
3
Construct and run the CLI command specifying the app settings to keep sticky.
az webapp config slot-settings set --name webapp-prod --resource-group rg-prod --app-settings DbConnection
This registers 'DbConnection' as a slot-specific setting for the webapp-prod app.

Key Concept

Azure App Service deployment slot settings stickiness configuration
Question 59Question →

You are designing a serverless background processing solution using Azure Functions V4. The function app must process large video files uploaded to Azure Blob Storage, where the processing of a single video file can take up to 2525 minutes to complete. The function app must also securely access an Azure SQL Database instance hosted within an Azure Virtual Network without exposing the database to the public internet. You need to select the hosting plan and configuration that satisfies these requirements. Which of the following configurations should you select?

Show answer & explanation

Answer: An Elastic Premium plan with regional virtual network integration, and the host.json functionTimeout property set to 00:30:00.

Answer

An Elastic Premium plan with regional virtual network integration, and the host.json functionTimeout property set to 00:30:00.
The configuration specifying an Elastic Premium plan with regional virtual network integration and a 3030-minute functionTimeout is correct because the Elastic Premium plan supports regional virtual network integration for outbound connectivity to resources within a virtual network. Additionally, the Premium plan allows for execution timeouts beyond 1010 minutes (up to unbounded, with 3030 minutes as the default), which easily accommodates the 2525-minute requirement.

Step-by-Step Solution

1
Analyze execution duration requirements.
The requirement states that execution can take up to 2525 minutes. The Consumption plan has a maximum execution limit of 1010 minutes. Therefore, the Consumption plan is ruled out, and either an Elastic Premium or Dedicated (App Service) plan must be used.
Choosing a hosting plan that supports execution durations longer than 1010 minutes is necessary to prevent function executions from timing out.
2
Analyze networking requirements.
The function app needs outbound connectivity to access an Azure SQL Database within a virtual network. Regional virtual network integration is required for outbound connectivity.
Regional virtual network integration enables the function app to route outbound traffic into the virtual network, while Private Endpoints only control inbound access.
3
Evaluate hosting plan configurations and host.json timeout settings.
An Elastic Premium plan with regional virtual network integration supports both requirements. The default timeout on the Premium plan is 3030 minutes, which can be configured explicitly in host.json using the functionTimeout property (e.g., '00:30:00'). Dedicated plans require Always On to be enabled for background triggers to work properly.
Verifying the correct property and values in host.json ensures the function app scales and executes within the limits of the chosen plan.

Key Concept

Azure Functions hosting plans support different execution limits and networking features. The Elastic Premium plan is required for serverless scaling when regional virtual network integration or executions longer than 1010 minutes are needed.
Estimated Time:2m 0s
Question 60Question →

An organization is configuring an existing Linux-based Azure Function App named `contosofn` running on an Elastic Premium plan to deploy and pull its custom container image from a private Azure Container Registry (ACR) named `contosoacr`. You have created a user-assigned managed identity named `fn-pull-identity`. You must configure `contosofn` to pull the custom image from `contosoacr` using `fn-pull-identity`. Which four actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

Configuring identity-based container deployment for Azure Functions using user-assigned managed identities.
PreviousPage 3 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin