All practice questions

972 questions

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

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

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

Step-by-Step Solution

Create the user-assigned managed identity.

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

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

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

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

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

Retrieve the resource ID of the identity.

The resource ID string is obtained.

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

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

A deployment YAML file is created.

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

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

The container group is deployed to ACI.

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

Key Concept

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

Estimated Time:3m 0s

Question 142Question →

You need to create an Azure Function that runs automatically on a schedule every hour to check for inactive user accounts and update their status in an Azure Cosmos DB database. Which two configurations should you use for this function? (Select two.)

Select all that apply

A Timer trigger to execute the function on the hourly schedule

An Azure Cosmos DB output binding to update the user account documents

An Azure Cosmos DB trigger to run the function when accounts become inactive

An HTTP trigger to initiate the function execution from an external scheduler

Show answer & explanation

Answer: A Timer trigger to execute the function on the hourly schedule; An Azure Cosmos DB output binding to update the user account documents

Answer

A Timer trigger to execute the function on the hourly schedule, and an Azure Cosmos DB output binding to update the user account documents.

To execute the function on an hourly schedule, a Timer trigger is required. To write the status changes back to Azure Cosmos DB, an output binding is the correct configuration as it enables writing data without manually instantiating database client connections.

Step-by-Step Solution

Identify the execution model required for the schedule.

The function must run automatically every hour.

The Timer trigger uses CRON expressions to run functions periodically, making it the correct choice.

Identify the database operation required.

The function must modify or save updated status back to Azure Cosmos DB.

An output binding provides a simple, declarative way to write data from the function to the target database.

Key Concept

Azure Functions use triggers to define how a function is invoked, and bindings to connect to data sources. A Timer trigger executes code on a schedule, while an output binding writes data to a service like Azure Cosmos DB.

Estimated Time:45s

Question 143Question →

A company hosts a web application on an Azure App Service Web App that currently runs on the Shared ( $D1$ ) pricing tier. You are tasked with configuring the web app to automatically scale out (add more instances) when CPU usage exceeds $80\%$ and scale in when CPU usage falls below $30\%$ .

Which two actions should you perform to meet these requirements?

Select all that apply

Scale up the App Service plan to the Standard (

S1

) pricing tier

Configure autoscale rules with scale-out and scale-in conditions based on the CPU Percentage metric

Configure autoscale rules directly on the Shared (

D1

) pricing tier to scale out based on CPU usage

Scale up the App Service plan to the Basic (

B1

) pricing tier and configure the autoscale rules

Show answer & explanation

Answer: Scale up the App Service plan to the Standard ( $S1$ ) pricing tier; Configure autoscale rules with scale-out and scale-in conditions based on the CPU Percentage metric

Answer

To meet the requirements, you must scale up the App Service plan to the Standard (

S1

) pricing tier and configure autoscale rules based on the CPU Percentage metric.

To implement autoscale rules, the App Service plan must be scaled up to at least the Standard (

S1

) tier because the Shared (

D1

) and Basic (

B1

) tiers do not support autoscale. Once on a supported tier, autoscale rules must be configured with both scale-out and scale-in conditions based on the CPU Percentage metric to handle the load characteristics dynamically.

Step-by-Step Solution

Evaluate the current App Service pricing tier for autoscale support.

The Shared (

D1

) pricing tier does not support scaling out. The Basic (

B1

) pricing tier supports manual scale-out but does not support autoscale rules. The Standard (

S1

) pricing tier is the minimum tier that supports autoscale rules.

Choosing the correct pricing tier is required before autoscale rules can be configured.

Configure the autoscale conditions.

Create a scale-out rule for CPU usage above

80\%

and a scale-in rule for CPU usage below

30\%

using the CPU Percentage metric.

This implements the automatic scaling behavior required by the load characteristics.

Key Concept

Pricing tier requirements for Azure App Service autoscale rules

Question 144Question →

You are configuring diagnostic logging for a Node.js web application hosted on an Azure App Service running on a Linux plan. You need to configure a diagnostic setting using the Azure CLI to stream both the application container's standard output/error (stdout/stderr) streams and the web server's HTTP request logs to a Log Analytics workspace. Which JSON array should you pass to the `--logs` parameter of the `az monitor diagnostic-settings create` command to achieve this?

[{"category": "AppServiceConsoleLogs", "enabled": true}, {"category": "AppServiceHTTPLogs", "enabled": true}]

[{"category": "AppServiceAppLogs", "enabled": true}, {"category": "AppServiceHTTPLogs", "enabled": true}]

[{"category": "AppServiceConsoleLogs", "enabled": true}, {"category": "AppServicePlatformLogs", "enabled": true}]

[{"category": "AppServiceConsoleLogs", "enabled": true}, {"category": "AppServiceAuditLogs", "enabled": true}]

Show answer & explanation

Answer: [{"category": "AppServiceConsoleLogs", "enabled": true}, {"category": "AppServiceHTTPLogs", "enabled": true}]

Answer

The configuration that contains both AppServiceConsoleLogs and AppServiceHTTPLogs with enabled set to true.

For Linux-based App Services, application console outputs (stdout/stderr) are collected under the AppServiceConsoleLogs category, and the HTTP request logs are collected under the AppServiceHTTPLogs category. Thus, enabling these two categories routes the desired telemetry to the Log Analytics workspace.

Step-by-Step Solution

Identify the hosting operating system for the App Service.

The web application is hosted on Linux.

Logging behavior in Azure App Service differs significantly between Windows and Linux platforms.

Determine the correct log category for Node.js application stdout/stderr streams on Linux.

The correct category is AppServiceConsoleLogs.

On Linux App Service, standard output and standard error from the application container are captured by App Service as Console logs, whereas Windows App Service uses AppServiceAppLogs.

Determine the correct log category for web server HTTP request logs.

The correct category is AppServiceHTTPLogs.

Both Windows and Linux App Services route web server request logs to the AppServiceHTTPLogs category.

Construct the JSON array configuration for the --logs parameter.

An array containing enabling objects for AppServiceConsoleLogs and AppServiceHTTPLogs.

The CLI command az monitor diagnostic-settings create expects an array of category enablement objects.

Key Concept

Azure Monitor integration requires selecting correct platform-specific diagnostic log categories (AppServiceConsoleLogs vs AppServiceAppLogs) depending on the underlying operating system of the App Service.

Estimated Time:3m 0s

Question 145Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

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

Step-by-Step Solution

Initiate the preview swap using the Azure CLI.

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

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

Test the staging application at its URL.

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

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

Complete the slot swap using the Azure CLI.

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

This finalizes the deployment process after validation is successful.

Key Concept

Deployment slot swap with preview

Question 146Question →

An administrator is deploying an Azure Container App named inventory-service. The application needs to securely retrieve configuration settings from an Azure Key Vault. To minimize management overhead, the administrator requires that the identity used by the application is automatically deleted if the container app itself is deleted. Which identity type should the administrator use, and which Azure CLI command will enable this identity on the container app?

System-assigned managed identity; run: az containerapp identity assign --name inventory-service --resource-group my-rg --system-assigned

User-assigned managed identity; run: az containerapp identity assign --name inventory-service --resource-group my-rg --user-assigned my-identity-resource-id

System-assigned managed identity; run: az containerapp registry set --name inventory-service --resource-group my-rg --server myregistry.azurecr.io --identity system

System-assigned managed identity; run: az containerapp secret set --name inventory-service --resource-group my-rg --secrets KeyVaultAccess=my-vault-url

Show answer & explanation

Answer: System-assigned managed identity; run: az containerapp identity assign --name inventory-service --resource-group my-rg --system-assigned

Answer

System-assigned managed identity; run: az containerapp identity assign --name inventory-service --resource-group my-rg --system-assigned

The correct option correctly identifies that a system-assigned managed identity is lifecycle-bound to the container app and uses the proper 'az containerapp identity assign' command with the '--system-assigned' flag to enable it.

Step-by-Step Solution

Determine the required identity lifecycle behavior.

Since the identity must be automatically deleted when the container app is deleted, a system-assigned managed identity must be used instead of a user-assigned managed identity.

System-assigned managed identities are bound to the lifecycle of the specific Azure resource that created them.

Identify the correct Azure CLI command to enable the system-assigned managed identity.

The correct command is 'az containerapp identity assign --name inventory-service --resource-group my-rg --system-assigned'.

This command enables the system-assigned identity on the target container app, which will generate an identity in Microsoft Entra ID.

Key Concept

Azure Container Apps managed identity configuration and lifecycle management

Question 147Question →

You are building a scheduled batch processing application that runs as an Azure Container Instances (ACI) container group. The container image is hosted in a private Azure Container Registry (ACR). The batch application processes sensitive medical records and must retrieve an encryption key stored in Azure Key Vault at startup. You need to configure the ACI container group so that it can pull the image from the private ACR and authenticate to the Key Vault to retrieve the encryption key using the minimum level of privileges. Which configuration should you implement?

Assign a system-assigned managed identity to the container group, assign the AcrPull role to this identity for the ACR resource, and grant the identity GET permissions in the Key Vault access policies.

Assign a user-assigned managed identity to the container group, assign the AcrPull role to this identity for the ACR resource, and grant the identity GET permissions in the Key Vault access policies.

Assign a user-assigned managed identity to the container group, assign the AcrPull role to this identity for the ACR resource, and enable Key Vault firewall bypass for trusted Microsoft services without defining access policies.

Assign a user-assigned managed identity to the container group, grant the identity GET permissions in the Key Vault access policies, and configure the container startup command to run 'az acr login' to authenticate the registry pull.

Show answer & explanation

Answer: Assign a user-assigned managed identity to the container group, assign the AcrPull role to this identity for the ACR resource, and grant the identity GET permissions in the Key Vault access policies.

Answer

Assign a user-assigned managed identity to the container group, assign the AcrPull role to this identity for the ACR resource, and grant the identity GET permissions in the Key Vault access policies.

The correct configuration uses a user-assigned managed identity. Because ACI needs to pull the container image from a private registry before the container group itself is fully created, a system-assigned identity cannot be used for registry authentication. Assigning the AcrPull role to the user-assigned identity allows ACI to pull the image, and granting GET permissions to the same identity in the Key Vault access policies ensures the application can retrieve secrets at runtime.

Step-by-Step Solution

Identify the authentication needs of the ACI resource at deployment time versus runtime.

The ACI host needs to authenticate to the private registry before the container runs, whereas the application inside the container needs to access Key Vault during runtime.

This determines whether a system-assigned or user-assigned identity is required, as system-assigned identities do not exist until after deployment.

Select the correct identity type and configure registry access.

A user-assigned managed identity is selected and granted the AcrPull role on the Azure Container Registry.

This allows the ACI service host to authenticate using the user-assigned identity to pull the image during deployment.

Configure access to Key Vault.

The same user-assigned managed identity is granted GET permission on the Key Vault secrets.

This permits the application running inside the container to authenticate to the Key Vault and retrieve the required encryption key.

Key Concept

Authentication and authorization configuration for Azure Container Instances pulling from private Azure Container Registry and accessing Azure Key Vault using managed identities.

Question 148Question →

A developer is configuring a web app named prod-orders-app in Azure App Service. The app must retrieve a database password from an Azure Key Vault named orders-vault using a Key Vault reference in the application settings. You have created a user-assigned managed identity named orders-identity and granted it the 'Key Vault Secrets User' role on the Key Vault. You have also associated orders-identity with the web app. Which configuration should you apply to the web app to ensure it successfully retrieves the secret using the user-assigned managed identity?

Set the DatabasePassword app setting to @KeyVault(SecretUri=https://orders-vault.vault.azure.net/secrets/db-password/) and configure the web app's key vault reference identity by running az webapp update --name prod-orders-app --resource-group myRG --keyvault-reference-identity <resource-id-of-orders-identity>.

Set the DatabasePassword app setting to @Microsoft.KeyVault(SecretUri=https://orders-vault.vault.azure.net/secrets/db-password/) and enable the system-assigned managed identity on the web app, leaving the keyvault-reference-identity configuration parameter unset.

Set the DatabasePassword app setting to @Microsoft.KeyVault(SecretUri=https://orders-vault.vault.azure.net/secrets/db-password/) and configure the web app's key vault reference identity by running az webapp update --name prod-orders-app --resource-group myRG --keyvault-reference-identity <resource-id-of-orders-identity>.

Show answer & explanation

Answer: Set the DatabasePassword app setting to @Microsoft.KeyVault(SecretUri=https://orders-vault.vault.azure.net/secrets/db-password/) and configure the web app's key vault reference identity by running az webapp update --name prod-orders-app --resource-group myRG --keyvault-reference-identity <resource-id-of-orders-identity>.

Answer

To successfully resolve a Key Vault reference using a user-assigned managed identity, you must use the correct fully qualified prefix '@Microsoft.KeyVault' and explicitly configure the App Service's 'keyVaultReferenceIdentity' property to the Resource ID of the user-assigned identity. This instructs App Service to use the specific user-assigned identity to perform the runtime call to Key Vault.

Step-by-Step Solution

Formulate the correct Key Vault reference syntax for the application setting.

Use the format @Microsoft.KeyVault(SecretUri=https://orders-vault.vault.azure.net/secrets/db-password/).

App Service requires the fully qualified @Microsoft.KeyVault prefix along with the SecretUri parameter to correctly identify and parse the Key Vault reference.

Configure the web app to use the user-assigned managed identity for resolving Key Vault references.

Run the command: az webapp update --name prod-orders-app --resource-group myRG --keyvault-reference-identity <resource-id-of-orders-identity>.

By default, App Service attempts to resolve Key Vault references using the system-assigned managed identity. To use a user-assigned identity, you must set the keyVaultReferenceIdentity configuration property to the Resource ID of that identity.

Ensure the user-assigned managed identity has access to retrieve secrets from the Key Vault.

Verify that the 'Key Vault Secrets User' role is assigned to the user-assigned managed identity on the Key Vault.

At runtime, App Service uses the configured user-assigned managed identity to authenticate. The identity must have explicit read access to Key Vault secrets.

Key Concept

Key Vault references in App Service can be configured to use a user-assigned managed identity by setting the keyVaultReferenceIdentity configuration property to the Resource ID of the identity and using the correct @Microsoft.KeyVault prefix in the application setting.

Question 149Question →

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the Function App to use a user-assigned managed identity for Key Vault references, you first create the identity and assign it to the Function App. Next, grant the identity Secret Get permission on the Key Vault. Then, set the keyVaultReferenceIdentity app setting to the resource ID of the identity. Finally, add the application setting referencing the secret.

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

Step-by-Step Solution

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

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

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

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

The identity is authorized to access secrets in the vault.

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

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

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

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

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

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

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

Key Concept

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

Question 150Question →

You are developing a user onboarding workflow using Azure Durable Functions. The workflow must execute three tasks in sequence: first, create the user profile in a database; second, generate a welcome PDF document; and third, send a welcome email containing the PDF. The output of each task is required as the input for the subsequent task.

Which Durable Functions pattern should you use to implement this workflow?

Function chaining

Fan-out/fan-in

Async HTTP APIs

Monitor

Show answer & explanation

Answer: Function chaining

Answer

Function chaining

Function chaining is the correct pattern because it represents a workflow where functions are executed sequentially, and the output of one function is directly passed as the input to the next function. This matches the requirements of creating a profile, generating a PDF from the profile details, and then emailing the generated PDF.

Step-by-Step Solution

Analyze the workflow requirements to identify the execution flow and dependencies between tasks.

The workflow requires executing three tasks sequentially where the output of each task is required as the input for the next task.

This establishes a clear sequential dependency chain represented as

F_1 \rightarrow F_2 \rightarrow F_3

Compare the requirements against standard Azure Durable Functions patterns.

Function chaining is designed specifically to execute a sequence of functions in a helper topology where output feeds into input, whereas Fan-out/fan-in handles parallelization and Monitor handles polling.

Choosing the pattern that natively supports sequential data passing reduces complexity and matches architectural best practices.

Key Concept

Durable Functions Patterns - Function Chaining

Estimated Time:45s

Question 151Question →

A logistics company is designing an Azure Cosmos DB container to store delivery tracking records. The system receives a high volume of writes representing tracking status updates. Each tracking record contains a `shipmentId`, a `destinationCountry`, and a `statusDate` (formatted as YYYY-MM-DD). The system must support transactional batch writes (using `TransactionalBatch`) for all status updates of a single shipment on a specific date. The destination country has low cardinality, with 10 countries representing 95% of all shipments. You must prevent hot partitions during peak shipping seasons while satisfying the transactional boundary. Which two actions should you perform to configure the partitioning strategy?

Select all that apply

Create a synthetic partition key by concatenating shipmentId and statusDate in each item.

Set the container's partition key path to the custom synthetic property.

Configure destinationCountry as the partition key to optimize queries that filter by country.

Configure Session consistency to guarantee transactional ACID compliance for batch updates across different shipment partitions.

Show answer & explanation

Answer: Create a synthetic partition key by concatenating shipmentId and statusDate in each item.; Set the container's partition key path to the custom synthetic property.

Answer

Create a synthetic partition key by concatenating shipmentId and statusDate in each item, and configure the container's partition key path to point to the custom synthetic property.

To support transactional batches for updates of a single shipment on a specific date, all involved items must share the same partition key. Concatenating shipmentId and statusDate to create a synthetic partition key satisfies this constraint. Selecting this synthetic property as the container's partition key distributes writes evenly due to its high cardinality, preventing hot partition issues that would arise from using destinationCountry.

Step-by-Step Solution

Analyze partition key requirements for transactional batches.

Identified that TransactionalBatch operations in Azure Cosmos DB require all operations to target the same logical partition key.

Azure Cosmos DB only supports multi-document transactions (TransactionalBatch) within a single logical partition.

Evaluate candidate fields for partition keys based on cardinality and write patterns.

Determined that using destinationCountry results in hot partitions due to low cardinality (10 countries representing 95% of traffic). Determined that a synthetic key combining shipmentId and statusDate provides high cardinality and satisfies the transactional boundary.

High cardinality prevents hot partitions by distributing writes across many logical and physical partitions, while combining shipmentId and statusDate keeps the transactional operations scoped to a single logical partition.

Define the container's partition key configuration.

Concatenate the fields in the item and configure the container's partition key path to point to this new synthetic property.

Azure Cosmos DB does not automatically generate synthetic keys; they must be created in the application code and the partition key path configured on the container to match.

Key Concept

Azure Cosmos DB partitioning strategy, including synthetic partition keys and transactional boundaries.

Estimated Time:2m 0s

Question 152Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

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

Step-by-Step Solution

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

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

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

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

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

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

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

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

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

Remove the `AzureWebJobsStorage` application setting.

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

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

Key Concept

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

Question 153Question →

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

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

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

Step-by-Step Solution

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

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

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

Restart the application using `az webapp restart`.

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

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

Start log streaming using `az webapp log tail`.

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

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

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

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

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

Key Concept

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

Estimated Time:3m 0s

Question 154Question →

A developer hosts a lightweight web API on an Azure App Service web app that currently runs on the Free ( $F1$ ) pricing tier. The API is experiencing minor CPU spikes due to an increase in user requests. The developer wants to configure manual scale-out to run the web app on $2$ instances to distribute the load. Which action should the developer perform first?

Scale up the App Service plan to the Basic (

B1

) pricing tier or higher.

Configure the Instance count setting to

2

in the scale-out settings of the Azure portal while remaining on the Free (

F1

) tier.

Configure an Azure Monitor autoscale rule to increase the instance count to

2

when CPU usage exceeds

70\%

Create a second App Service plan in the same region on the Free (

F1

) tier and bind the web app to both plans.

Show answer & explanation

Answer: Scale up the App Service plan to the Basic ( $B1$ ) pricing tier or higher.

Answer

Scale up the App Service plan to the Basic (

B1

) pricing tier or higher.

Scaling up the App Service plan to the Basic (

B1

) tier or higher is correct because the Free (

F1

) tier only supports a single instance. The Basic (

B1

) tier is the minimum tier that supports manual scale-out (up to

3

instances).

Step-by-Step Solution

Determine the scale-out capabilities of the current Free (

F1

) pricing tier.

The Free (

F1

) tier does not support scaling out and is limited to a single instance.

Understanding the current tier limits is necessary to identify the constraint.

Identify the minimum pricing tier that supports manual scale-out to

2

instances.

The Basic (

B1

) pricing tier is the minimum tier that supports manual scale-out (up to

3

instances).

This determines the target tier required to support the desired instance count.

Change the pricing tier of the App Service plan.

Scale up the App Service plan from Free (

F1

) to Basic (

B1

) or higher.

This unlocks the scale-out settings in Azure App Service.

Key Concept

Azure App Service scaling capabilities are restricted by the pricing tier. The Free (

F1

) and Shared (

D1

) tiers do not support scaling out. Upgrading (scaling up) to the Basic (

B1

) tier is the minimum requirement to enable manual scale-out.

Question 155Question →

A financial reconciliation service logs credit card transactions to an Azure Cosmos DB Core (SQL) API container. Each document contains the following structure:

{
"transactionId": "d7bfa5d3-8b7a-47ef-b4b1-9f9fa82fb5a7",
"merchantId": "8f8c6e3b-5867-4e78-bc41-df0c0cf8ef23",
"transactionDate": "2026-07-16",
"amount": 120.50,
"status": "Pending"
}

The service has the following requirements:
- Ingestion: Handles up to $15,000$ write operations per second during peak hours.
- Transactional Boundary: A daily reconciliation process must use a `TransactionalBatch` to atomically update the status of all transactions for a single merchant on a specific day.
- Reads: Multiple independent reconciliation nodes must read and verify these daily merchant records.

You need to select a partitioning strategy that avoids hot partitions and satisfies the transactional requirements.

Which partitioning strategy should you implement?

Configure transactionId as the partition key.

Configure transactionDate as the partition key.

Configure a synthetic partition key that concatenates the merchantId and transactionDate properties.

Configure merchantId as the partition key and rely on Session consistency to guarantee read-your-writes visibility across all distributed reconciliation nodes.

Show answer & explanation

Answer: Configure a synthetic partition key that concatenates the merchantId and transactionDate properties.

Answer

Configure a synthetic partition key that concatenates the merchantId and transactionDate properties.

The correct answer is to use a synthetic partition key combining the merchant identifier and the transaction date. This ensures that all transactions for a specific merchant on any given day share the same partition key, placing them in the same logical partition. This configuration satisfies the transactional boundary required to execute a TransactionalBatch while distributing the overall write volume across many unique merchant-date combinations, preventing hot partitions.

Step-by-Step Solution

Identify the transactional boundaries.

All updates to transactions for a single merchant on a specific day must be executed within a single TransactionalBatch.

Cosmos DB restricts TransactionalBatch operations to items that share the exact same partition key value.

Evaluate the cardinality and write distribution of candidate partition keys.

Using transactionDate creates a hot partition on the current date, while using transactionId makes transactional batches impossible. Using merchantId alone can lead to unbounded partition growth over time for high-volume merchants.

A partition key must distribute throughput and storage evenly to prevent rate-limiting and exceeding physical partition limits.

Formulate a synthetic partition key solution.

Combining merchantId and transactionDate (e.g., merchantId_transactionDate) creates a key with high cardinality that groups all required documents for a merchant's daily batch into a single logical partition.

Synthetic partition keys allow developers to meet transactional boundaries without sacrificing partition key cardinality or causing hot partitions.

Key Concept

Configuring synthetic partition keys to satisfy transactional boundaries (TransactionalBatch) while preventing hot partitions under high-volume workloads.

Estimated Time:2m 0s

Question 156Question →

You are designing an Azure Cosmos DB container for a global financial clearing platform that processes credit card transactions. The workload has the following characteristics:

* Write Ingestion: The platform continuously ingests transaction records at a rate of $50,000$ transactions per second.
* Transactional Boundary: The platform uses the Azure Cosmos DB .NET SDK to execute `TransactionalBatch` operations. Each batch contains up to $100$ transaction updates for a single merchant account that must succeed or fail atomically.
* Read Query Pattern: Hourly reconciliation jobs query for all transactions executed for a specific merchant during a specific hour (e.g., querying for merchant `M_98765` between $10:00$ and $11:00$ UTC).
* Storage and Throughput Profile: A small number of high-volume merchants (such as global airlines and retail chains) generate over $45\%$ of the total transaction volume, while the remaining volume is distributed across millions of boutique merchants.

You need to select a partitioning strategy that supports the transactional batches, avoids logical partition size limits, and minimizes hot partitions.

Which partition key strategy should you select?

A synthetic partition key created by combining the merchant ID and the transaction hour (e.g., merchantId_yyyy-MM-dd-HH).

A partition key defined as the transaction ID (/transactionId).

A partition key defined as the merchant ID (/merchantId).

A synthetic partition key created by appending a random integer suffix between 1 and 10 to the merchant ID (e.g., merchantId_randomSuffix).

Show answer & explanation

Answer: A synthetic partition key created by combining the merchant ID and the transaction hour (e.g., merchantId_yyyy-MM-dd-HH).

Answer

A synthetic partition key created by combining the merchant ID and the transaction hour (e.g., merchantId_yyyy-MM-dd-HH).

The correct strategy is to use a synthetic partition key that combines the merchant ID and the transaction hour. This satisfies the transactional boundary since all transactions inside a batch belong to the same merchant and occur within the same hour, thus sharing the same partition key value. It also optimizes the hourly reconciliation queries by directing them to a single logical partition. Additionally, distributing a high-volume merchant's transactions across hourly partitions avoids exceeding the

20\text{ GB}

logical partition size limit.

Step-by-Step Solution

Analyze the transactional boundary requirement.

Cosmos DB `TransactionalBatch` operations require all items in the batch to share the exact same partition key value.

This rules out partitioning strategies that separate transactions within the same batch, such as using the transaction ID or random suffixes on the merchant ID.

Evaluate the storage growth limits and hot partition risks.

A single logical partition in Azure Cosmos DB cannot exceed

20\text{ GB}

of storage.

Using the merchant ID alone as the partition key would cause high-volume merchants to exceed the storage limit and cause write rate-limiting due to hot partitions.

Analyze the read query optimization requirement.

Queries filtering by merchant and hour should target a single partition key to avoid cross-partition query overhead.

A synthetic key combining the merchant ID and the transaction hour ensures that all transactions for that hour are co-located in the same logical partition.

Select the partition key that satisfies all criteria.

The synthetic key `merchantId_yyyy-MM-dd-HH` is the optimal choice.

It preserves transactional boundaries for hourly batches, prevents any single partition from growing indefinitely, and optimizes hourly queries to a single logical partition.

Key Concept

Synthetic partition keys and partition boundaries in Azure Cosmos DB.

Question 157Question →

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

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

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

Step-by-Step Solution

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

A resource group is provisioned to contain all other services.

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

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

A Container Apps environment is created inside the resource group.

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

Run `az containerapp create` to deploy the container.

The Container App is running in the environment.

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

Key Concept

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

Estimated Time:1m 0s

Question 158Question →

A web application uses a single-region Azure Cosmos DB account with a single write region. The application requires that a user must always see their own updates immediately within their active browser session. Other users can tolerate a slight propagation delay to see these updates. Which consistency level should you configure to meet these requirements with the lowest latency and resource cost?

Strong

Session

Eventual

Bounded Staleness

Show answer & explanation

Answer: Session

Answer

Session consistency should be selected because it provides read-your-own-writes guarantees within the client session at the lowest cost and latency.

Session consistency provides a read-your-own-writes guarantee scoped to the client session. This satisfies the requirement that a user immediately sees their own updates while allowing other users to tolerate a slight delay, all at a lower latency and cost than Strong or Bounded Staleness.

Step-by-Step Solution

Analyze the requirements for read freshness and consistency scope.

The application requires that users must see their own updates immediately (read-your-own-writes), but other users can tolerate a propagation delay.

This establishes the minimum consistency boundary needed for the user's active session without requiring global strong consistency.

Evaluate the cost and latency characteristics of the available Cosmos DB consistency levels.

Strong and Bounded Staleness provide global consistency guarantees but incur higher costs and latencies. Eventual and Consistent Prefix have low latency and cost but do not guarantee read-your-own-writes.

This helps identify the most cost-effective option that satisfies the requirements.

Select the default consistency level that matches these exact requirements.

Session consistency provides the required session-bound read-your-own-writes guarantee with low latency and standard read/write costs.

Selecting Session consistency achieves the desired balance of session-scoped data freshness, performance, and resource efficiency.

Key Concept

Azure Cosmos DB consistency levels and their performance/cost trade-offs, specifically Session consistency.

Question 159Question →

You are configuring autoscale rules for an Azure App Service plan named AppServicePlan1 that hosts a critical API. The plan currently runs a single instance. You define a scale-out rule that increases the instance count by $1$ when the average CPU utilization exceeds $80\%$ . You need to configure a scale-in rule to decrease the instance count by $1$ when the load decreases. You must ensure that scaling in does not immediately trigger a scale-out event (flapping) when the resource count is reduced from $2$ instances to $1$ instance. Which CPU utilization threshold should you specify for the scale-in rule?

Less than

35\%

Less than

50\%

Less than

65\%

Less than

85\%

Show answer & explanation

Answer: Less than $35\%$

Answer

Less than

35\%

The correct option is the one specifying a threshold of less than

35\%

. When average CPU utilization across

2

instances is below

35\%

, the total combined workload is less than

70\%

. Reducing the instance count to

1

results in a single instance carrying a load of less than

70\%

, which is below the scale-out threshold of

80\%

and prevents immediate re-scaling (flapping).

Step-by-Step Solution

Analyze the scale-out rule configuration and determine the relationship between instance counts and workload distribution.

The scale-out rule is triggered when CPU utilization exceeds

80\%

on a single instance, and scaling out distributes the load across

2

instances.

To understand the resource state before a scale-in event is evaluated.

Calculate the maximum safe CPU utilization on

2

instances before scaling down to

1

instance without exceeding the scale-out threshold.

The maximum safe load on

1

instance is just below the scale-out threshold (

80\%

). On

2

instances, this corresponds to an average CPU utilization of less than

\frac{80\%}{2} = 40\%

To find the threshold where the combined workload of both instances can fit onto a single instance without triggering a scale-out.

Select the option with a threshold value below the calculated maximum safe average CPU utilization of

40\%

The threshold of less than

35\%

is below

40\%

and is the only option that prevents flapping.

To choose the correct rule parameter that ensures stable autoscale operations.

Key Concept

Preventing flapping in App Service autoscale configurations by ensuring the scale-in threshold accounts for load distribution changes when instance count decreases.

Estimated Time:1m 30s

Question 160Question →

You are preparing to deploy a container group to Azure Container Instances (ACI). The container group must connect to an Azure SQL Database that is secured within an Azure Virtual Network (VNet). You need to deploy the container group into the VNet. Which two requirements must be met to deploy the container group into the virtual network? (Choose two.)

Select all that apply

The destination subnet must be delegated to the Microsoft.ContainerInstance/containerGroups service.

The container group must be deployed to the same Azure region as the virtual network.

The container group must be configured with a system-assigned managed identity to bypass subnet delegation.

The container group deployment must authenticate with Azure Container Registry (ACR) using az acr login to validate the subnet configuration.

Show answer & explanation

Answer: The destination subnet must be delegated to the Microsoft.ContainerInstance/containerGroups service.; The container group must be deployed to the same Azure region as the virtual network.

Answer

The correct requirements are that the destination subnet must be delegated to the Microsoft.ContainerInstance/containerGroups service, and the container group must be deployed to the same Azure region as the virtual network.

Deploying a container group into an Azure Virtual Network requires delegating the destination subnet to the Microsoft.ContainerInstance/containerGroups service so that ACI can create network interfaces. Furthermore, the container group must be deployed in the same Azure region as the virtual network.

Step-by-Step Solution

Ensure region matching.

The container group and the target virtual network are in the same Azure region.

ACI VNet integration requires the container group and VNet to share the same region.

Configure subnet delegation.

The subnet is delegated to the Microsoft.ContainerInstance/containerGroups service.

Subnet delegation is mandatory to allow ACI to provision network interfaces in the VNet.

Key Concept

Azure Container Instances virtual network integration requirements

PreviousPage 8 / 49Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept