Examkin

All practice questions

972 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 81Question →

An organization plans to migrate a public-facing website to an Azure App Service web app named `prod-web`. The website is currently hosted on-premises and is accessed via the custom subdomain `sales.contoso.com`.

The migration must meet the following requirements:
- The website must experience zero downtime during the DNS transition.
- The custom domain `sales.contoso.com` must be secured with an SSL/TLS certificate.
- The domain binding and SSL configuration must be fully prepared in the Azure Web App before the live DNS traffic is rerouted.
- The web app's Custom Domain Verification ID is `A1B2C3D4E5F6G7H8`.

Which three actions should you perform to prepare the web app for the transition? (Select three.)

Select all that apply

Show answer & explanation

Answer: Create a DNS TXT record named asuid.sales with the value A1B2C3D4E5F6G7H8.; Add the custom hostname sales.contoso.com to the prod-web web app.; Upload and bind a custom SSL/TLS private certificate to sales.contoso.com.

Answer

Create a DNS TXT record named asuid.sales with the value of the Custom Domain Verification ID, add the custom domain sales.contoso.com to the web app, and upload and bind a custom TLS/SSL private certificate.
To prepare a web app for migration with zero downtime, you must map the custom domain and configure its SSL binding before updating the routing CNAME record. Creating a TXT record named `asuid.sales` with the Custom Domain Verification ID verifies ownership. After verification, the hostname `sales.contoso.com` can be added. Finally, a custom private TLS/SSL certificate must be uploaded and bound; a managed certificate cannot be generated because it requires the DNS routing to already point to Azure, which is not possible during the pre-verification stage.

Step-by-Step Solution

1
Create a DNS TXT record named asuid.sales containing the Custom Domain Verification ID.
The verification record is registered in the public DNS namespace.
Allows Azure App Service to verify domain ownership without rerouting live website traffic.
2
Add the custom hostname sales.contoso.com to the web app.
Azure resolves the TXT record, completes verification, and links the hostname to the web app.
Registers the custom host header on the Web App so it is ready to receive requests.
3
Upload and bind a custom private SSL/TLS certificate (.pfx) to sales.contoso.com.
The SSL binding is configured on the Web App.
Secures the domain using SSL/TLS before traffic is redirected, avoiding downtime.

Key Concept

Zero-Downtime Custom Domain Mapping and Pre-binding TLS/SSL Certificates
Estimated Time:3m 0s
Question 82Question →

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

Azure App Service Easy Auth configuration
Question 83Question →

You are designing an Azure Function App that must process files uploaded to an Azure Blob Storage container. The requirements are as follows:
- The processing of each file can take up to 20 minutes to complete.
- The storage account is secured behind an Azure Virtual Network (VNet) and does not allow public internet access.
- The Function App must authenticate to the storage account using a user-assigned managed identity named `fn-storage-identity`.
- The solution must scale dynamically based on the volume of incoming uploads.

Which combination of hosting plan and connection settings should you configure?

Show answer & explanation

Answer: Deploy the Function App on a Premium plan. Set the application settings StorageConnection__blobServiceUri to the storage account blob endpoint, StorageConnection__credential to managedidentity, and StorageConnection__clientId to the client ID of fn-storage-identity.

Answer

Deploy the Function App on a Premium plan, and configure the connection settings using the blob service URI, the managedidentity credential, and the client ID of the user-assigned managed identity.
The correct configuration uses the Premium plan, which supports both virtual network integration (required to access the VNet-secured storage account) and execution durations longer than 10 minutes (the default is 30 minutes, and can be configured as unbounded). Additionally, for a user-assigned managed identity, configuring the Client ID parameter is mandatory to distinguish it from a system-assigned managed identity.

Step-by-Step Solution

1
Analyze hosting plan requirements based on execution duration and networking constraints.
The Consumption plan is eliminated due to its 10-minute maximum timeout and lack of VNet integration support. The Premium plan is selected because it supports both VNet integration and longer/unbounded execution times.
Azure Functions must run on a plan that supports VNet access to reach the secured storage account, and support a 20-minute execution duration.
2
Determine the required identity-based connection configuration for the user-assigned managed identity.
To use a user-assigned identity for the storage connection, you must set the endpoint URI, specify the credential type as managedidentity, and provide the client ID of the identity.
The client ID is necessary for the runtime to locate the correct user-assigned identity associated with the Function App; otherwise, it will default to a system-assigned identity.
3
Evaluate Key Vault permission requirements for key vault references.
Confirm that any Key Vault secret references require the Function App's identity to have access policies or Azure RBAC permissions to read the secrets.
Merely pointing to a Key Vault secret URI in app settings is insufficient; access must be explicitly authorized.

Key Concept

Azure Functions hosting plans and identity-based connection configuration for user-assigned managed identities.
Question 84Question →

A company is developing a centralized logging service that stores application log messages in Azure Cosmos DB.

The workload has the following characteristics:
- Throughput Profile: High-volume write ingestion of up to 20,00020,000 writes per second, with occasional read queries by administrators.
- Transactional Boundaries: There are no transactional requirements across different log entries; each log document is written independently.
- Read/Write Trade-off: The partitioning strategy must be optimized to maximize write throughput and avoid bottlenecks, even if it requires read queries for a specific day to span multiple partitions.

The log documents contain a `logDate` property (formatted as `YYYY-MM-DD`) and a `serviceName` property. Using `logDate` directly as the partition key would direct all writes for the current day to a single partition, causing a hot partition.

You need to select a partitioning strategy that distributes the write throughput evenly.

Which strategy should you use?

Show answer & explanation

Answer: Create a synthetic partition key by appending a random integer suffix to the `logDate` value.

Answer

Create a synthetic partition key by appending a random integer suffix to the `logDate` value.
Appending a random integer suffix to the `logDate` creates a synthetic partition key with higher cardinality. This distributes the write operations of a single day across multiple logical partitions (e.g., from suffix 11 to 1010), preventing any single partition from being overwhelmed by the high write rate of 20,00020,000 operations per second.

Step-by-Step Solution

1
Analyze the workload characteristics and requirements.
High-volume write throughput (20,00020,000 writes/sec) with no transactional boundaries between separate logs.
Understanding boundaries and throughput patterns guides partition key selection.
2
Identify potential hot partitions.
Using `logDate` causes a hot partition because all logs on a given day target the same key. Using `serviceName` creates a hot partition if a few services dominate logs.
A partition key must distribute write traffic evenly across logical partitions.
3
Determine the optimal partitioning strategy.
Append a random suffix to the `logDate` to create a synthetic key, distributing write traffic across multiple logical partitions.
A synthetic partition key with random suffixes distributes high write traffic evenly, satisfying the write-optimized requirement.

Key Concept

Avoiding hot partitions in high-write Azure Cosmos DB containers using synthetic partition keys.

Alternative Method

Instead of appending a random suffix, a pre-calculated hash of another property (like a transaction ID) could be appended to the date to create a deterministic synthetic partition key, which helps when reading specific records if the suffix can be calculated.
Estimated Time:1m 30s
Question 85Question →

An organization deploys a web application to an Azure App Service web app. You configure the following autoscale rules for the App Service plan:

* Scale-out rule: Increase the instance count by 2 when the average CPU percentage is greater than 70% over a 10-minute duration.
* Scale-in rule: Decrease the instance count by 1 when the average CPU percentage is less than 75% over a 10-minute duration.

During periods of moderate, stable load, the application experiences flapping, where instances are repeatedly added and removed.

You need to resolve the flapping behavior and ensure stable scaling of the web application.

Which of the following modifications should you make?

Show answer & explanation

Answer: Change the scale-in threshold to trigger when the average CPU percentage is less than 40%.

Answer

Change the scale-in threshold to trigger when the average CPU percentage is less than 40%.
Changing the scale-in threshold to less than 40% CPU usage resolves the flapping behavior. When the web app scales out by 2 instances, the average CPU percentage drops. By setting the scale-in threshold to a significantly lower value (40%), you prevent the system from immediately triggering a scale-in action when the CPU usage drops after scaling out. This creates a stable scaling profile.

Step-by-Step Solution

1
Identify the cause of flapping in the autoscale settings.
The current scale-in threshold of 75% is higher than the scale-out threshold of 70%, meaning there is a logical overlap where both conditions can be met, leading to constant scaling.
Understanding the logic error in the autoscale rules is necessary to find the right resolution.
2
Determine how instance capacity changes affect CPU metrics.
When the scale-out rule adds 2 instances, the overall CPU usage per instance drops. The scale-in threshold must be low enough to not immediately trigger a scale-in command when this drop occurs.
Autoscale thresholds must account for the change in metric values that occurs as a direct result of scaling actions.
3
Select a scale-in threshold that provides a safe margin.
Changing the scale-in threshold to 40% CPU usage creates a safe margin below 70%, preventing flapping and ensuring stable operation.
This configuration ensures that scaling in only happens when the workload has genuinely decreased.

Key Concept

Autoscale rules must have a sufficient safety margin (cool-down gap) between scale-out and scale-in thresholds to prevent flapping.
Question 86Question →

An operations team is configuring autoscale rules for an Azure App Service Plan hosting a web application. They define the following rules:

* Scale-out Rule 1: Increase the instance count by 1 if the average CPU Percentage is greater than 80%.
* Scale-out Rule 2: Increase the instance count by 1 if the average Memory Percentage is greater than 85%.
* Scale-in Rule 1: Decrease the instance count by 1 if the average CPU Percentage is less than 40%.
* Scale-in Rule 2: Decrease the instance count by 1 if the average Memory Percentage is less than 50%.

Under which condition will the App Service Plan scale in?

Show answer & explanation

Answer: Only when the CPU Percentage is less than 40% and the Memory Percentage is less than 50%

Answer

Only when the CPU Percentage is less than 40% and the Memory Percentage is less than 50%
In Azure Monitor autoscale engine, when multiple scale-in rules are defined, they are evaluated using a logical AND operation. This means the autoscale engine will only decrease the instance count if all scale-in conditions are met. In this scenario, both the CPU Percentage must be below 40% and the Memory Percentage must be below 50% for scale-in to occur.

Step-by-Step Solution

1
Identify the scale-out evaluation logic in Azure Autoscale.
Multiple scale-out rules are combined using a logical OR operator (scaling out if any rule is met).
This is the default engine behavior designed to prioritize application performance under load.
2
Identify the scale-in evaluation logic in Azure Autoscale.
Multiple scale-in rules are combined using a logical AND operator (scaling in only if all rules are met).
This prevents premature scale-in events that could degrade performance if one metric is still high.
3
Apply the scale-in logic to the configured rules.
Scale-in will trigger only when both CPU Percentage is less than 40% AND Memory Percentage is less than 50%.
Both conditions must evaluate to true simultaneously to satisfy the logical AND requirement.

Key Concept

Azure App Service Autoscale Rule Evaluation Logic
Question 87Question →

You configure an application setting in an Azure Function App to reference a database connection string stored in Azure Key Vault using the syntax: `@Microsoft.KeyVault(VaultName=kv-prod;SecretName=conn-string)`. During testing, the function fails to connect to the database. You inspect the function logs and discover that the environment variable for the connection string contains the literal string `@Microsoft.KeyVault(VaultName=kv-prod;SecretName=conn-string)` instead of the resolved secret value. What is the most likely cause of this issue?

Show answer & explanation

Answer: The Function App's managed identity has not been granted permissions to read secrets from the Key Vault.

Answer

The Function App's managed identity has not been granted permissions to read secrets from the Key Vault.
The correct answer is correct because when a Key Vault reference cannot be resolved by the runtime, it returns the raw reference string instead of the secret. The most common cause for this is that the Azure Function App's managed identity has not been granted the 'Get' secret permission in the Key Vault access policies or the 'Key Vault Secrets User' role in Azure role-based access control (RBAC).

Step-by-Step Solution

1
Analyze the behavior of unresolved Key Vault references in Azure Functions.
When a Key Vault reference cannot be resolved by the runtime, the application setting returns the raw reference string (e.g., starting with `@Microsoft.KeyVault`) rather than throwing a runtime exception.
This behavior helps developers detect configuration issues, such as missing permissions or incorrect URIs, by examining the returned value.
2
Verify key requirements for resolving Key Vault references.
The reference requires a configured managed identity (system-assigned or user-assigned) and appropriate access permissions (such as Key Vault Secrets User or a custom policy with Get secrets permissions). The secret version is optional, and the feature is supported across all hosting plans.
Eliminating options related to versioning, hosting plan restrictions, and identity type constraints isolates the authorization policy as the missing link.
3
Select the option that matches the authorization failure.
The option indicating that the managed identity lacks permissions to read secrets from the Key Vault is the correct answer.
Without the correct permissions, the Function App cannot fetch the secret value, resulting in the literal reference string being exposed at runtime.

Key Concept

Azure Functions Security Configuration and Key Vault References
Question 88Question →

You are designing an Azure Cosmos DB container to store customer order records for an online retail application. Each order document contains `OrderId`, `CustomerId`, `OrderDate`, and `ShippingStatus`. The application frequently queries orders for a given customer and requires transactional updates when modifying multiple orders for the same customer.

Which two requirements are satisfied by selecting `CustomerId` as the partition key for this container?

Select all that apply

Show answer & explanation

Answer: It enables multi-document transactions using transactional batches or stored procedures for orders belonging to the same customer.; It ensures that queries filtering by the customer identifier to retrieve order history are served as single-partition queries.

Answer

Selecting the customer identifier as the partition key satisfies the requirements by enabling multi-document transactions for orders within the same customer scope and ensuring that customer history queries are single-partition queries.
Selecting the customer identifier as the partition key ensures all orders for a single customer reside in the same logical partition. This enables transaction execution (stored procedures, transactional batch) across those documents and allows the database to route customer-specific queries to a single partition, minimizing Request Unit (RU) consumption.

Step-by-Step Solution

1
Analyze transactional requirements.
Since transactions in Azure Cosmos DB are scoped to a single logical partition, partitioning by customer identifier puts all of a customer's orders in the same logical partition, allowing transaction execution.
Azure Cosmos DB requires all items participating in a transaction to share the same partition key value.
2
Analyze query patterns.
Queries filtering by customer identifier will target a single logical partition.
Providing the partition key in the query filter allows the Azure Cosmos DB SDK to route the query directly to the correct partition, optimizing Request Unit consumption.
3
Evaluate limits and consistency constraints.
Identify that partitioning does not prevent a logical partition from growing beyond 20 GB if a single partition key value accumulates too much data, and does not configure session consistency.
Logical partitions are limited to 20 GB, and session consistency requires session token management.

Key Concept

Selecting an appropriate partition key in Azure Cosmos DB is essential for maintaining transactional boundaries and optimizing query performance.
Estimated Time:1m 0s
Question 89Question →

You configure a user-assigned managed identity for an Azure App Service web app. You want the web app to retrieve a database password from Azure Key Vault by using a Key Vault reference in the App Settings. The web app has the system-assigned managed identity disabled. The Key Vault reference is configured as DatabasePassword = @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/db-password/). The web app fails to retrieve the secret because it attempts to use a system-assigned identity. Which action should you perform to resolve this issue and allow the web app to retrieve the password?

Show answer & explanation

Answer: Configure the web app's keyVaultReferenceIdentity setting to the Resource Manager resource ID of the user-assigned managed identity.

Answer

Configure the web app's keyVaultReferenceIdentity setting to the Resource Manager resource ID of the user-assigned managed identity.
To resolve Key Vault references using a user-assigned managed identity, the App Service web app must have its keyVaultReferenceIdentity setting configured with the full Resource Manager resource ID of that user-assigned identity. This is because App Service defaults to using the system-assigned identity for reference resolution, and when it is disabled, the resolution fails unless the specific user-assigned identity is explicitly configured at the App Service level.

Step-by-Step Solution

1
Determine that when system-assigned managed identity is disabled, the App Service does not automatically resolve Key Vault references using user-assigned identities.
Identify that the resolving identity must be explicitly configured on the web app.
By default, App Service attempts to use the system-assigned identity for reference resolution.
2
Select the correct configuration setting and identifier type required by Azure App Service.
Identify that the keyVaultReferenceIdentity property must be set to the Resource Manager resource ID of the user-assigned managed identity.
The keyVaultReferenceIdentity setting expects the full resource ID path rather than the client ID or principal ID.
3
Update the site configuration parameters of the App Service web app.
Set keyVaultReferenceIdentity to the user-assigned identity resource ID, allowing reference resolution to succeed.
This updates the App Service control plane to use the specified user-assigned identity when performing Secret Get operations.

Key Concept

User-assigned managed identity configuration for App Service Key Vault references
Question 90Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

You are configuring a multi-container group in Azure Container Instances (ACI) using an Azure Resource Manager (ARM) template. An application container within the group must retrieve database credentials from Azure Key Vault at runtime. You configure the container group with a system-assigned managed identity. The deployment completes successfully, but the application container fails to start. Reviewing the container logs reveals an HTTP 403 (Forbidden) error when the application attempts to fetch the credentials from the Key Vault. Which action should you take to resolve this error?

Show answer & explanation

Answer: Grant the system-assigned managed identity's principal ID the GET permission on secrets using a Key Vault access policy or Azure RBAC role assignment.

Answer

Grant the system-assigned managed identity's principal ID the GET permission on secrets using a Key Vault access policy or Azure RBAC role assignment.
The correct action is to grant the system-assigned managed identity's principal ID the GET permission on secrets in the Key Vault. A system-assigned managed identity is automatically created for the container group when deployed, but it requires explicit permissions (such as a Key Vault access policy or an Azure RBAC role like Key Vault Secrets User) to access resources like secrets.

Step-by-Step Solution

1
Verify the managed identity configuration on the container group.
The container group has a system-assigned managed identity enabled, which generates an identity principal in Microsoft Entra ID after provisioning.
To ensure the container group can authenticate to Azure services using its own identity.
2
Identify why the Key Vault request returned an HTTP 403 Forbidden status.
The request failed authorization because the newly created identity principal does not have permission to read secrets from the Key Vault.
A managed identity has zero access permissions by default; permissions must be explicitly assigned.
3
Configure permissions on the Key Vault.
Add an access policy granting GET permission on secrets to the container group's system-assigned managed identity principal ID (or assign the Key Vault Secrets User RBAC role).
To authorize the identity to retrieve the secret values at runtime.

Key Concept

Configuring runtime authorization for ACI container groups using system-assigned managed identities and Key Vault access policies.
Question 92Question →

An enterprise architecture requires that an Azure Function App (V4 runtime, .NET 8 isolated worker model) connects to an Azure Event Hubs namespace named 'fin-data-eh' without using any secrets or connection strings. The Function App uses a user-assigned managed identity to access the Event Hubs namespace, and the identity has been granted the Azure Event Hubs Data Receiver role. In the function code, the trigger attribute uses a connection property named `EventHubConnection`. Which configuration settings must be added to the application settings of the Function App to authenticate the trigger using the user-assigned managed identity?

Show answer & explanation

Answer: Configure `EventHubConnection__fullyQualifiedNamespace` with the value `fin-data-eh.servicebus.windows.net`, `EventHubConnection__credential` with the value `managedidentity`, and `EventHubConnection__clientId` with the Client ID of the user-assigned managed identity.

Answer

Configure EventHubConnection__fullyQualifiedNamespace with the value fin-data-eh.servicebus.windows.net, EventHubConnection__credential with the value managedidentity, and EventHubConnection__clientId with the Client ID of the user-assigned managed identity.
To configure a user-assigned managed identity for an identity-based connection in Azure Functions V4, you must specify the fully qualified namespace of the target service, set the credential type to 'managedidentity', and specify the Client ID of the user-assigned identity using the designated double-underscore environment variable syntax.

Step-by-Step Solution

1
Identify the required endpoint setting for identity-based connections in Azure Functions V4.
The setting EventHubConnection__fullyQualifiedNamespace must be defined with the service namespace URL.
Identity-based connections require the fully qualified domain address of the target service rather than a full connection string.
2
Determine how to target a user-assigned managed identity instead of the system-assigned default.
The setting EventHubConnection__credential must be set to 'managedidentity', and EventHubConnection__clientId must be set to the specific Client ID.
By default, the runtime attempts to use the system-assigned managed identity. To override this, the credential type and user-assigned client ID must be explicitly configured.
3
Evaluate the hosting plan capabilities and trigger connection settings structure.
Confirm that the Consumption and Premium hosting plans natively support identity-based connections without changing the plan.
Hosting plan migration is not required as identity-based connections are supported across serverless plans.

Key Concept

Azure Functions identity-based connections and user-assigned managed identity configuration
Question 93Question →

You are developing a lightweight Azure Function that runs once per day to prune expired user sessions from a database. The function takes approximately 30 seconds to run. You must minimize costs by only paying for the exact compute resource time that the function consumes. Which hosting plan should you select for the function app?

Show answer & explanation

Answer: Consumption plan

Answer

The Consumption plan is the correct choice because it scales automatically and only charges for the time that the function executes, making it ideal for a lightweight daily task.
The Consumption plan is designed for serverless workloads where billing is based on resource consumption and execution count. For a function that runs only once per day for 30 seconds, this model ensures you only pay for those 30 seconds of compute time, minimizing total expenses.

Step-by-Step Solution

1
Analyze the workload requirements
The function runs sporadically (once per day) and has a short execution duration (30 seconds).
Understanding the workload pattern determines the most cost-efficient hosting model.
2
Compare hosting plan billing models
The Consumption plan charges only for execution time. The Premium and Dedicated plans charge continuously for allocated compute instances.
To satisfy the requirement to minimize costs and only pay when the function is running, a serverless billing model is required.
3
Select the correct hosting plan
Select the Consumption plan to achieve the lowest cost for this execution profile.
The Consumption plan aligns with the requirement of paying only for active compute time.

Key Concept

Azure Functions hosting plans and their billing models
Estimated Time:45s
Question 94Question →

You are configuring an Azure App Service web app named `app-finance` to retrieve database credentials from an Azure Key Vault named `kv-finance`. You want to use a user-assigned managed identity named `id-finance` to authenticate and resolve the Key Vault references in your application settings. You have already associated the user-assigned managed identity with the web app and granted it the `Key Vault Secrets User` role on `kv-finance`. However, when the application runs, the Key Vault references in the application settings fail to resolve, and the web app attempts to use a non-existent system-assigned identity instead of the user-assigned identity. What configuration step must you perform next to ensure the web app uses the user-assigned managed identity to resolve the Key Vault references?

Show answer & explanation

Answer: Set the site configuration property `keyVaultReferenceIdentity` of the web app to the resource ID of the user-assigned managed identity.

Answer

Set the site configuration property `keyVaultReferenceIdentity` of the web app to the resource ID of the user-assigned managed identity.
The correct answer is to configure the `keyVaultReferenceIdentity` site property with the resource ID of the user-assigned managed identity. Since an App Service web app can have multiple user-assigned managed identities, the platform cannot determine which one to use for resolving Key Vault references unless it is explicitly specified. Without this configuration, the platform defaults to using the system-assigned managed identity.

Step-by-Step Solution

1
Ensure the user-assigned managed identity is associated with the Azure App Service web app and has the necessary permissions (e.g., Key Vault Secrets User role) to read secrets from the Key Vault.
The identity is linked and authorized, but the app cannot yet use it for references automatically.
Before the app can fetch secrets, the chosen identity must have read permissions in the Key Vault.
2
Configure the site configuration property `keyVaultReferenceIdentity` to point to the resource ID of the user-assigned managed identity.
The App Service is configured to use the specified user-assigned identity to authenticate to Key Vault for reference resolution.
Since a web app can have multiple user-assigned identities associated with it, App Service requires you to explicitly designate which identity to use for resolving Key Vault references.
3
Restart the App Service web app or trigger a configuration update to apply the changes.
The environment variables are updated and the Key Vault references successfully resolve to the secret values.
App Service resolves Key Vault references at startup or when configuration changes are applied.

Key Concept

Azure App Service Key Vault reference identity configuration
Question 95Question →

You are deploying a containerized application to Azure Container Instances (ACI). The application container needs to pull its image from a private Azure Container Registry (ACR) and retrieve a database connection string secret from an Azure Key Vault. Which two configurations are required to ensure the container can authenticate to the registry and access the secret? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the container group with registry credentials (server, username, and password) or enable a managed identity with permissions to pull from the registry.; Assign a managed identity to the container group and grant it permissions to get secrets in the Azure Key Vault access policies.

Answer

Configure the container group with registry credentials or a managed identity with pull permissions, and assign a managed identity to the container group with Key Vault secret access permissions.
To pull from a private registry, ACI must be provided with registry server credentials or a managed identity assigned the AcrPull role. To access Key Vault secrets, the container group must have a managed identity that is granted GET secrets permission in Key Vault. These settings satisfy both secure pull and runtime secret access requirements.

Step-by-Step Solution

1
Configure Azure Container Registry authentication.
The ACI deployment is configured with ACR credentials or a managed identity with AcrPull role.
Allows ACI to authenticate and pull the container image from the private registry.
2
Enable a managed identity on the container group.
The ACI container group has a system-assigned or user-assigned identity.
Provides a secure identity wrapper that can be authorized in Azure services like Key Vault.
3
Configure Key Vault access policies.
The managed identity is granted GET permissions on secrets in Key Vault.
Allows the container to retrieve the database connection string at runtime.

Key Concept

Azure Container Instances authentication to ACR and Azure Key Vault
Question 96Question →

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

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

You are deploying a web application to an Azure App Service web app that has a production slot and a staging deployment slot. The application requires a database connection string defined in its application settings. You must ensure that the staging slot always connects to the staging database and the production slot always connects to the production database, even after you perform a slot swap. Which configuration should you apply to the connection string setting?

Show answer & explanation

Answer: Mark the setting as a deployment slot setting.

Answer

Mark the setting as a deployment slot setting.
Marking the configuration as a deployment slot setting ensures that the database connection string is sticky to the slot. When you perform a slot swap, Azure swaps all settings that are not marked as deployment slot settings, but leaves slot-specific settings untouched, keeping the staging slot connected to the staging database and the production slot connected to the production database.

Step-by-Step Solution

1
Identify the configuration settings that must remain specific to each environment (the staging database vs the production database).
The database connection string is identified as the environment-specific configuration.
This determines which configurations need to be prevented from swapping.
2
Navigate to the configuration section of the Azure App Service Web App in the Azure Portal or use the Azure CLI.
Access is gained to the application settings key-value pairs.
You must edit the settings definition to apply the slot-specific constraint.
3
Edit the connection string setting and select the checkbox for 'Deployment slot setting' (or use the '--slot-settings' parameter in the Azure CLI).
The setting is marked as sticky to the slot.
This ensures that when a swap occurs, the value of the setting stays with the slot and does not move to the other slot.

Key Concept

Deployment Slot Settings (Sticky Settings)
Question 98Question →

An organization is developing a delivery driver tracking system that stores location logs in an Azure Cosmos DB container. The system processes thousands of status updates per minute from active drivers. Write operations are distributed evenly across all drivers, and the most common queries retrieve location history for a specific driver. The container must distribute storage and Request Units (RUs) uniformly without causing hot partitions. Which property should be configured as the partition key?

Show answer & explanation

Answer: driverId

Answer

driverId
Selecting driverId is correct because it has high cardinality and matches the query filter. This ensures that driver-specific queries are routed directly to a single partition (single-partition queries) while writes are evenly distributed across all active drivers.

Step-by-Step Solution

1
Analyze the query and write patterns for the Cosmos DB workload.
Writes are distributed across drivers, and read queries frequently search by a specific driver.
Choosing a key that aligns with search filters minimizes cross-partition queries.
2
Evaluate candidate properties for partition key cardinality.
driverId and logId have high cardinality, whereas city and status have lower cardinality.
High cardinality is necessary to prevent hot partitions by distributing data across many physical partitions.
3
Select the key that satisfies both cardinality and query routing.
driverId is the optimal choice because it is highly unique and matches the filter for the primary query pattern.
This avoids cross-partition queries while maintaining uniform resource distribution.

Key Concept

Selecting a partition key that matches query filters and has high cardinality to distribute throughput and storage.
Question 99Question →

Your company uses an Azure Container Registry (ACR) named prodacr. You have created an ACR Task named build-app in prodacr that is configured to build an application image whenever the base image, which resides in a separate private ACR named sharedacr, is updated. You create a user-assigned managed identity named task-identity, assign it to the build-app task, and grant it the AcrPull role on sharedacr. Which command must you run to configure the task to use the user-assigned managed identity when pulling the base image from sharedacr?

Show answer & explanation

Answer: az acr task credential add --name build-app --registry prodacr --login-server sharedacr.azurecr.io --use-identity <client-id>

Answer

Execute the 'az acr task credential add' command, specifying the task name, target registry, login server of the source registry, and the '--use-identity' parameter with the client ID of the user-assigned managed identity.
To authenticate an Azure Container Registry (ACR) Task to another private registry using a user-assigned managed identity, you must run the 'az acr task credential add' command. This command configures the specific login server credentials for the task. The '--use-identity' parameter must be set to the client ID of the user-assigned managed identity to ensure that the task uses the identity that has the AcrPull permission on the source registry.

Step-by-Step Solution

1
Identify the authentication requirements for the cross-registry pull within the ACR Task.
The task needs to authenticate to 'sharedacr.azurecr.io' using the user-assigned managed identity 'task-identity' which has been granted 'AcrPull' permissions.
Cross-registry pulls by ACR Tasks require explicit credential registration.
2
Select the correct command for adding credentials to an ACR Task.
The 'az acr task credential add' command is the standard CLI command to associate registry credentials with a specific task.
This command stores registry-specific credentials within the task metadata.
3
Configure the command parameters to use the user-assigned managed identity.
Specify the '--use-identity' parameter followed by the Client ID of the identity, and set the '--login-server' to 'sharedacr.azurecr.io'.
Passing the Client ID tells Azure Container Registry to use that specific user-assigned identity, whereas '[system]' would erroneously trigger system-assigned identity lookup.

Key Concept

Configuring credentials and managed identities for Azure Container Registry Tasks to perform cross-registry image pulls.
Estimated Time:2m 0s
Question 100Question →

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

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

Step-by-Step Solution

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

Key Concept

Deploying containerized Azure Functions using managed identity for Azure Container Registry authentication
PreviousPage 5 / 49Next