All practice questions

972 questions

Question 221Question

You are developing a .NET application for a fleet management system that logs vehicle telemetry. You need to write C# code using the Azure Cosmos DB .NET SDK v3 to insert a new status record into a container. Arrange the steps in the correct order to initialize the required SDK components and execute the item creation operation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To insert an item using the Azure Cosmos DB .NET SDK v3, you must first instantiate a CosmosClient with the connection string. Using that client, call GetDatabase to get a Database reference, and then call GetContainer on the database to get a Container reference. Finally, invoke CreateItemAsync on the container reference while providing both the item object and its PartitionKey.
The Azure Cosmos DB .NET SDK v3 structures its objects in a strict hierarchy mapping directly to Azure Cosmos DB resources. You start by instantiating the CosmosClient (1), which represents the connection. From the client, you acquire a reference to the Database (2). From the database reference, you acquire a reference to the Container (3). With the Container reference, you can execute operations like CreateItemAsync (4).

Step-by-Step Solution

1
Instantiate the client object
A CosmosClient instance is configured and active.
The client holds configuration settings and handles connections to the Azure Cosmos DB service.
2
Access the database reference
A Database proxy object is returned.
The SDK requires traversing the logical hierarchy: Client -> Database -> Container.
3
Access the container reference
A Container proxy object is returned.
All item-level operations such as creates, reads, and deletes are executed directly against a Container reference.
4
Execute the item creation
The telemetry item is persisted in the database.
Calling CreateItemAsync with the payload and PartitionKey sends the insert request to the correct physical partition.

Key Concept

Traversing the Azure Cosmos DB .NET SDK v3 resource hierarchy (CosmosClient to Database to Container) to perform item operations.
Question 222Question

An organization uses a Standard General Purpose v2 (GPv2) storage account to store telemetry data. You need to configure an Azure Blob Storage lifecycle management policy. The policy must move all block blobs in the `telemetry` container to the Archive tier if they have not been modified for more than 9090 days. Additionally, the policy must only apply to blobs that have a blob index tag named `Project` with a value of `Alpha`.

Which JSON policy definition should you use?

Show answer & explanation

Answer: {
"rules": [
{
"enabled": true,
"name": "ArchiveTelemetry",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 90
}
}
},
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "telemetry/" ],
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Alpha"
}
]
}
}
}
]
}

Answer

The correct policy definition contains the action tierToArchive with daysAfterModificationGreaterThan set to 90, matches block blobs within the telemetry container, and configures the case-sensitive blobIndexMatch filter matching Project with Alpha.
The correct JSON policy uses the proper actions and filters block layout. It maps the daysAfterModificationGreaterThan parameter to 90 days, targets the block blobs in the telemetry container, and strictly adheres to the case-sensitive blob index tag filter parameters.

Step-by-Step Solution

1
Identify the target action and condition.
The action is to archive blobs (tierToArchive) and the condition is modification time older than 90 days (daysAfterModificationGreaterThan set to 90).
This matches the storage tiering requirements for GPv2 storage accounts.
2
Establish the filters for target container and blob index tags.
The prefix filter points to telemetry/ and the blobIndexMatch filter specifies name as Project and value as Alpha.
Blob index tags are case-sensitive, so the exact casing specified in the scenario must be preserved in the policy JSON.
3
Ensure the JSON schema conforms to Azure Storage requirements.
The policy should only contain valid properties defined in the Azure Lifecycle Management schema, excluding any credentials or unsupported lease parameters.
Adding unauthorized blocks or unknown keys like ignoreActiveLease causes schema validation errors.

Key Concept

Azure Blob Storage Lifecycle Management policy definition with blob index tag filtering.
Question 223Question

You are designing an Azure Cosmos DB Core (SQL) API container for a health technology platform that tracks daily patient health metrics during clinical trials.

Each document in the container contains the following fields:
- `tenantId`: A unique identifier for the pharmaceutical sponsor
- `trialId`: A unique identifier for the clinical trial
- `patientId`: A unique identifier for the patient
- `recordDate`: The date of the measurement in `YYYY-MM-DD` format
- `heartRate`: The patient's heart rate value

The database solution must meet the following requirements:
- Write Ingestion: High-frequency writes from thousands of patient devices uploading metrics concurrently. Write operations for a single patient's daily metrics must be executed as a transactional batch to ensure atomicity.
- Read Queries: Clinical researchers frequently query all metrics for a specific clinical trial (`trialId`) within a date range of 33 to 77 days.
- Scalability: Individual logical partitions must not exceed the 20 GB20\text{ GB} storage limit, and write throughput (RUs) must be distributed evenly to avoid rate-limiting.

Which partition key strategy should you implement?

Show answer & explanation

Answer: Create a synthetic partition key by concatenating the `trialId` and `recordDate` fields.

Answer

Create a synthetic partition key by concatenating the trialId and recordDate fields.
Creating a synthetic partition key by combining the trial identifier and the record date restricts the size of each logical partition to a single day's worth of data for a specific trial. This ensures the 20 GB20\text{ GB} logical partition limit is not exceeded, even for large trials. Since a patient's daily metrics share the same trial identifier and date, they will also share the same partition key value, enabling transactional batch operations. Furthermore, queries from researchers looking for a trial's data over a 33 to 77 day period will target only a small, specific set of logical partitions (one for each day), preventing expensive container-wide fan-out queries.

Step-by-Step Solution

1
Analyze the transactional batch boundary requirement.
Cosmos DB transactional batches require all operations in the batch to share the same partition key. Since the requirement is to commit a single patient's daily metrics atomically, the partition key must remain constant for a given patient on a specific day.
Transactional batches cannot span multiple logical partitions.
2
Evaluate the scalability and storage constraints.
Partitioning by tenantId or trialId would aggregate too much data into single logical partitions, quickly exceeding the 20 GB20\text{ GB} logical partition limit and creating hot partitions. Partitioning by patientId or a synthetic key like trialId_recordDate avoids this by limiting the size of each logical partition.
Logical partitions in Azure Cosmos DB have a hard limit of 20 GB20\text{ GB} and a maximum throughput capacity.
3
Analyze the query pattern trade-offs.
Partitioning by patientId forces trial-wide queries to perform a costly container-wide fan-out. A synthetic key combining trialId and recordDate (trialId_recordDate) allows trial queries for a date range of 33 to 77 days to target only 33 to 77 specific logical partitions, optimizing read operations while maintaining write distribution.
Restricting query scope to a known subset of partition keys minimizes Request Unit (RU) consumption.

Key Concept

Selecting a partition key or designing a synthetic partition key to meet transactional, scalability, and query performance requirements in Azure Cosmos DB.
Question 224Question

An organization is deploying an inventory tracking application using an Azure Cosmos DB SQL API account. The account is configured with a single write region in East US and a read replica in West US. To group inventory by availability, the container is partitioned using the /availabilityStatus property, which has only three possible values: 'InStock', 'LowStock', and 'OutOfStock'. The application must meet the following requirements:
- Users must always read their own updates immediately, regardless of which regional application instance they connect to.
- The solution must support stateless web client instances without requiring the application layer to manage or pass session tokens between requests.

During load testing, the application encounters frequent request rate limiting (HTTP status code 429) on write operations.

Which default consistency level must you configure for the Cosmos DB account to meet the consistency and session requirements?

Show answer & explanation

Answer: Strong

Answer

Strong
Strong consistency is the correct choice because it guarantees that reads always see the most recent write. This satisfies the requirement of immediate read-your-own-writes for stateless web client instances without needing to manage and pass session tokens. Since the Cosmos DB account has a single write region, Strong consistency is fully supported.

Step-by-Step Solution

1
Analyze the requirements for read-your-own-writes guarantees across multiple stateless client connections without session token propagation.
Identify that any consistency level weaker than Strong requires the use and propagation of session tokens to guarantee that a client reads its own writes across different sessions.
Since the application instances are stateless and cannot pass session tokens, Session consistency cannot guarantee read-your-own-writes.
2
Evaluate the remaining consistency options for global read-your-own-writes guarantees.
Strong consistency is the only level that guarantees reads will always return the absolute latest version of the data across all replicas, satisfying the requirement without token sharing.
Bounded Staleness and Eventual consistency allow reads to lag behind writes, meaning clients may see stale data.
3
Address the HTTP 429 write rate-limiting issue.
Recognize that the HTTP 429 error is caused by a hot partition due to the poor choice of the partition key (/availabilityStatus has only three values), which cannot be solved by changing the consistency level.
A high-cardinality partition key is required to distribute the write load evenly across physical partitions.

Key Concept

Azure Cosmos DB Consistency Levels and Session Token Scope
Estimated Time:2m 0s
Question 225Question

You are implementing a data retention solution for a high-throughput microservices logging platform that writes log blobs to an Azure Storage account named telemetrydata. The account is provisioned as a Premium Block Blobs storage account. You need to configure a lifecycle management policy to automate the following requirements:
- Automatically delete block blobs 14 days after modification if they have a blob index tag named Environment set to Staging.
- Automatically transition block blobs to the Cool tier 30 days after modification if they have a blob index tag named Environment set to Production, and delete them after 90 days.

Which of the following actions should you take to achieve these requirements?

Show answer & explanation

Answer: Change the storage account type to Standard General Purpose v2 (GPv2), and then deploy a lifecycle policy that filters blobs using blobIndexMatch for the Environment tag, applying delete to the staging blobs and both tierToCool and delete to the production blobs.

Answer

Change the storage account type to Standard General Purpose v2 (GPv2), and then deploy a lifecycle policy that filters blobs using blobIndexMatch for the Environment tag, applying delete to the staging blobs and both tierToCool and delete to the production blobs.
To support the tiering action (moving production blobs to the Cool tier), the storage account must be of a type that supports access tiers, such as Standard General Purpose v2 (GPv2). Premium Block Blobs storage accounts only support the delete action in lifecycle policies. Furthermore, blob index tags are filtered using the blobIndexMatch property in the policy rule filters.

Step-by-Step Solution

1
Evaluate the storage account type capabilities.
Premium Block Blobs storage accounts do not support tiering to Cool or Archive; they only support the delete action in lifecycle management.
Since the production logs must transition to the Cool tier, the account type must be converted or upgraded to Standard General Purpose v2 (GPv2).
2
Select the correct JSON policy filter for blob tags.
Use blobIndexMatch in the filters block to match the key-value tag Environment with values Staging and Production.
Lifecycle management policies do not support standard metadata headers (like x-ms-meta-) for filtering, but do support blob index tags.
3
Formulate the lifecycle rule actions.
Create a rule applying delete with daysAfterModificationGreaterThan set to 14 for staging logs, and another rule applying both tierToCool (30 days) and delete (90 days) for production logs.
Standard GPv2 supports multiple rules containing different combinations of tierToCool, tierToArchive, and delete actions.
4
Verify execution and authorization requirements.
Deploy the policy natively on the storage account without including custom SAS tokens or lease-handling properties.
Lifecycle management runs natively as a platform service and automatically retries on leased blobs, requiring no extra credential configuration.

Key Concept

Azure Blob Storage Lifecycle Management policy execution, account type support, and tag-based filtering.
Question 226Question

A retail company is deploying a Python-based processing service to a V4 Azure Function App. The function is configured with a Service Bus queue trigger, where the trigger's Connection property is set to QueueConnection. Company security guidelines mandate that credentials must not be stored in configuration files or key vaults, and the connection must utilize the function's system-assigned managed identity. Which application setting must be added to the Function App to establish a successful connection?

Show answer & explanation

Answer: QueueConnection__fullyQualifiedNamespace set to the fully qualified domain name of the Service Bus namespace.

Answer

The correct approach is to set QueueConnection__fullyQualifiedNamespace to the fully qualified domain name of the Service Bus namespace in the Function App's application settings. This allows the V4 runtime to connect using the system-assigned managed identity.
Configuring QueueConnection__fullyQualifiedNamespace with the Service Bus namespace name allows the Azure Functions V4 runtime to connect to the Service Bus using the system-assigned managed identity. This complies with the security requirement to avoid using secrets or connection strings in settings.

Step-by-Step Solution

1
Identify the requirement to connect to Azure Service Bus using managed identity rather than storing credentials.
Confirm that an identity-based connection is required.
The scenario prohibits storing credentials or connection strings in configuration settings or Key Vault.
2
Determine the application setting suffix used by the V4 runtime for Service Bus identity-based connections.
Identify the '__fullyQualifiedNamespace' suffix.
Azure Functions uses specific setting suffixes to configure connection metadata, and Service Bus trigger connections require the fully qualified namespace.
3
Configure the application setting combining the connection name and the suffix.
Add 'QueueConnection__fullyQualifiedNamespace' to the application settings.
This tells the runtime to connect to the specified namespace using the app's managed identity.

Key Concept

Configuring identity-based connections for Azure Function triggers
Estimated Time:1m 30s
Question 227Question

An administrator is configuring a Web App named `inventory-api` on Azure App Service. The application must satisfy the following requirements:

1. Retrieve database credentials from Azure Key Vault without storing them in the application code.
2. Authenticate to the Key Vault using a managed identity that is tied to the lifecycle of the Web App.
3. Automatically increase the instance count when CPU usage exceeds 80%, and decrease the instance count when CPU usage drops below 70% without causing flapping.

Which two of the following configuration actions must you perform? Select two.

Select all that apply

Show answer & explanation

Answer: Assign a system-assigned managed identity to the Web App and grant it GET access to the Key Vault secrets.; Create an application setting for the database credential that uses the value `@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-password)`.

Answer

Assign a system-assigned managed identity to the Web App and grant it GET access to the Key Vault secrets, and create an application setting for the database credential that uses the value `@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-password)`.
Assigning a system-assigned managed identity fulfills the lifecycle requirement since system-assigned identities are deleted automatically when the associated Web App is deleted. Granting GET access allows the App Service to fetch the secret values. The App Service Key Vault reference syntax `@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-password)` allows the app setting to fetch the value securely from Key Vault.

Step-by-Step Solution

1
Select the correct managed identity type based on the lifecycle requirement.
Identify that a system-assigned managed identity is required because it is tied directly to the lifecycle of the Web App, whereas a user-assigned managed identity is a standalone resource.
Managed identity lifecycle requirements dictate whether to use system-assigned (tied to resource lifecycle) or user-assigned (independent).
2
Identify the correct syntax for referencing Key Vault secrets in App Service application settings.
Determine that `@Microsoft.KeyVault(VaultName=kv-prod;SecretName=db-password)` is the correct format.
App Service native Key Vault references must use the @Microsoft.KeyVault prefix and specify either SecretUri or VaultName/SecretName.
3
Evaluate the autoscale thresholds to prevent flapping.
Avoid configuring a scale-in threshold that is higher than or equal to the scale-out threshold, as this results in flapping.
Proper autoscale configuration requires the scale-out threshold to be higher than the scale-in threshold.

Key Concept

Configuring App Service App Settings, Managed Identities, Key Vault references, and autoscale rules.
Question 228Question

You are deploying a new Azure Container App named order-api to an Azure Container Apps environment. The container image is hosted in a private Azure Container Registry (ACR) named contosoacr.azurecr.io.

You are writing a Bicep template to perform the initial deployment of the container app. You must configure the container app to pull the image from the registry securely using a managed identity. The deployment must succeed on the first run without requiring any post-deployment manual configuration or secondary deployments.

Which configuration strategy and Bicep resource definition snippet should you use?

Show answer & explanation

Answer: Use a user-assigned managed identity. Grant the identity the AcrPull role on the registry, assign it to the container app, and configure it under the registries list in the Bicep template:

identity: {
type: 'UserAssigned'
userAssignedIdentities: {
'${userAssignedIdentity.id}': {}
}
}
properties: {
configuration: {
registries: [
{
server: 'contosoacr.azurecr.io'
identity: userAssignedIdentity.id
}
]
}
}

Answer

Use a user-assigned managed identity with the AcrPull role pre-assigned, and reference its resource ID in both the identity and registries configurations of the Bicep template.
For the initial deployment of an Azure Container App to succeed when pulling from a private Azure Container Registry using a managed identity, you must use a user-assigned managed identity. This is because the role assignment (AcrPull) must exist on the identity before the container app is created. A system-assigned managed identity is only created after the container app resource starts provisioning, making it impossible to assign the required role beforehand. In Bicep, a user-assigned identity is declared in the identity block and then referenced in the registries configuration using its resource ID.

Step-by-Step Solution

1
Create a user-assigned managed identity prior to the container app deployment.
A managed identity resource with a stable resource ID is available.
This avoids the chicken-and-egg problem of authorizing an identity that doesn't yet exist.
2
Assign the AcrPull role to the user-assigned identity at the scope of the Azure Container Registry.
The identity has the necessary permission to pull images from the registry.
The container app environment needs this permission to authenticate with the registry during container provisioning.
3
Reference the user-assigned identity in the Bicep template's identity and configuration.registries blocks.
The container app is successfully created and retrieves the container image during initial deployment.
This establishes the identity configuration on the resource and configures the environment to use that identity for the registry credentials.

Key Concept

To pull images from a private Azure Container Registry during the initial provisioning of an Azure Container App, a pre-created and authorized user-assigned managed identity must be used. System-assigned identities cannot be pre-authorized since they are created alongside the app.
Estimated Time:2m 0s
Question 229Question

You are developing a C# application using the Azure Cosmos DB .NET SDK v3 to manage configuration settings for a multi-tenant SaaS application. The target container uses '/tenantId' as its partition key path. You need to retrieve a single configuration item with an id of 'config-100' for a tenant whose tenantId is 'tenant-99' using the most efficient operation (lowest latency and RU cost). Which code segment should you use?

Show answer & explanation

Answer: ItemResponse<TenantConfig> response = await container.ReadItemAsync<TenantConfig>("config-100", new PartitionKey("tenant-99"));

Answer

ItemResponse<TenantConfig> response = await container.ReadItemAsync<TenantConfig>("config-100", new PartitionKey("tenant-99"));
The correct option uses the ReadItemAsync method, passing the item ID ('config-100') and the partition key ('tenant-99') as arguments. This constitutes a point read, which is the most efficient operation in Cosmos DB, providing the lowest latency and costing only 1 Request Unit (RU) for items under 1 KB.

Step-by-Step Solution

1
Determine the most efficient SDK operation for single-item retrieval.
A point read (ReadItemAsync) is selected over a query (GetItemQueryIterator) because it bypasses the query engine and executes in under 1 RU for items up to 1 KB.
Point reads are the fastest and most cost-effective way to read a single item in Azure Cosmos DB.
2
Supply the mandatory parameters to the ReadItemAsync method.
Pass the item ID ('config-100') as the first parameter, and the PartitionKey object instantiated with the logical partition key value ('tenant-99') as the second parameter.
The .NET SDK v3 requires both the item ID and the logical partition key value to perform a point read.

Key Concept

Performing point reads using the Azure Cosmos DB .NET SDK v3.
Estimated Time:45s
Question 230Question

You are developing a Python application that uses the azure-storage-blob SDK to retrieve properties for an Azure Storage blob. The blob has custom metadata configured with a key of Department and a value of Sales. You retrieve the blob's properties using properties = blob_client.get_blob_properties(). Which of the following code segments should you use to retrieve the metadata value?

Show answer & explanation

Answer: department = properties.metadata.get('Department')

Answer

The correct line of code is department = properties.metadata.get('Department') because metadata keys are case-sensitive and do not include the x-ms-meta- prefix in the SDK dictionary.
The correct code segment accesses the metadata dictionary using the exact key name without the x-ms-meta- prefix. Since the key was uploaded as 'Department', calling .get('Department') correctly retrieves 'Sales'.

Step-by-Step Solution

1
Retrieve blob properties from Azure Storage.
A BlobProperties object is returned containing a metadata dictionary.
To inspect user-defined custom metadata, the application must first call get_blob_properties() to load the metadata into memory.
2
Access the metadata dictionary using the exact case-sensitive key.
The metadata value is extracted using the key 'Department'.
The azure-storage-blob SDK strips the x-ms-meta- HTTP header prefix when exposing metadata in the Python dictionary, but preserves the casing configured during upload.

Key Concept

Accessing blob metadata keys in the Azure SDK requires using the exact casing without the x-ms-meta- prefix.
Question 231Question

You are developing a C# application that uses the Azure.Storage.Blobs SDK (v12) to manage files in Azure Blob Storage. You need to delete a blob that currently has an active, exclusive-write lease. Which two actions can you perform to successfully delete the blob? (Select two.)

Select all that apply

Show answer & explanation

Answer: Call the DeleteAsync method on the BlobClient and pass the active lease ID in a BlobRequestConditions object.; Instantiate a BlobLeaseClient for the blob, call BreakAsync to release the lease lock, and then call DeleteAsync on the BlobClient.

Answer

To delete a leased blob, you must either provide the active lease ID using a BlobRequestConditions object when calling DeleteAsync, or break the active lease using a BlobLeaseClient before calling DeleteAsync.
To delete a blob that has an active lease, you can either provide the lease ID in the request conditions using a BlobRequestConditions object, or release/break the lease lock on the blob using a BlobLeaseClient prior to deletion. Both methods satisfy the requirements for modifying or deleting a leased resource in Azure Storage.

Step-by-Step Solution

1
Determine if the lease needs to be kept active during the operation or if it can be terminated.
If the lease can be terminated, it can be broken. If it must remain active, the delete request must include the lease ID.
This determines which API call sequence to use.
2
Implement the deletion using request conditions with the lease ID, or break the lease first.
Passing the lease ID in BlobRequestConditions allows the delete to proceed, while breaking the lease removes the lock so that a standard delete call works.
Both methods are valid ways to bypass the write/delete lock imposed by the lease.

Key Concept

Handling write/delete operations on leased blobs using the Azure.Storage.Blobs SDK.
Question 232Question

A team is troubleshooting an Azure App Service web application named myApp. They want to configure the application to write diagnostic trace messages to the local filesystem and view the incoming log messages live in their terminal.

Which two Azure CLI commands should they run?

Select all that apply

Show answer & explanation

Answer: az webapp log config --name myApp --resource-group myRG --application-logging true; az webapp log tail --name myApp --resource-group myRG

Answer

The commands to enable application logging to the filesystem and start streaming the logs are: `az webapp log config --name myApp --resource-group myRG --application-logging true` and `az webapp log tail --name myApp --resource-group myRG`.
To view live diagnostic trace messages on the local filesystem of an App Service, you must first enable filesystem-based application logging using the config command, and then initiate the log stream using the tail command.

Step-by-Step Solution

1
Enable application logging to the filesystem for the App Service web application.
FileSystem application logging is activated, allowing runtime trace messages to be captured.
By default, application logging to the filesystem is disabled. It must be turned on using the `az webapp log config` command with the `--application-logging true` parameter.
2
Initiate the live log stream in the terminal.
The terminal starts displaying live trace messages from the application.
Using the `az webapp log tail` command connects to the App Service log streaming service to show output in real time.

Key Concept

Built-in diagnostic logging and log streaming in Azure App Service via Azure CLI
Estimated Time:1m 0s
Question 233Question

An organization hosts a report generation web application named contoso-reports on an Azure App Service Web App. The web application currently runs on an App Service plan named asp-free using the Free (F1) pricing tier.

During scheduled weekly report generation, the web application experiences severe CPU spikes that cause performance degradation. You need to implement an autoscale strategy using the Azure CLI that meets the following requirements:
- The hosting plan must be changed to the lowest cost tier that supports autoscale rules.
- The instance count must scale out by 1 instance when average CPU utilization is greater than 85% for 10 minutes.
- The instance count must scale in by 1 instance when average CPU utilization drops below 40% for 10 minutes.
- The configuration must prevent autoscale flapping.

Which four Azure CLI commands should you execute in sequence? To answer, move the appropriate commands from the list of commands to the answer area and arrange them in the correct order. (Note: Configure the scale-out rule before the scale-in rule.)

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure autoscale for the web app, you must first update the App Service plan SKU to S1 to support autoscale. Next, create the autoscale setting on the plan. Finally, configure the scale-out rule followed by the scale-in rule.
The correct order begins with scaling up the App Service plan from Free (F1) to Standard (S1) using 'az appservice plan update' because autoscaling is not supported on the Free tier. Next, you must create the autoscale setting container using 'az monitor autoscale create' before you can add rules to it. After creating the setting container, you add the scale-out rule to handle CPU spikes, and finally, you add the scale-in rule with a 40% threshold to prevent autoscale flapping when the load drops.

Step-by-Step Solution

1
Scale up the App Service plan to the Standard (S1) tier.
The plan is updated to a SKU that supports custom autoscale rules.
The Free (F1) tier does not support autoscale features; Standard (S1) is the lowest pricing tier that supports custom autoscale.
2
Create the autoscale setting container.
An autoscale setting named autoscale-reports is created and linked to the App Service plan.
You cannot add rules without first creating an autoscale setting that defines the base instance limits.
3
Create the scale-out rule.
A scale-out rule is added to autoscale-reports to increase instances by 1 when average CPU exceeds 85% for 10 minutes.
This rule allows the web app to scale out during CPU spikes to maintain performance.
4
Create the scale-in rule.
A scale-in rule is added to autoscale-reports to decrease instances by 1 when average CPU is below 40% for 10 minutes.
This rule reduces costs when the CPU spikes subside, and the 40% threshold prevents flapping.

Key Concept

Scaling Azure App Service plans using the Azure CLI
Question 234Question

You have an Azure subscription that contains a General Purpose v1 (GPv1) storage account named storage1 in a resource group named group1. You need to implement an Azure Blob Storage lifecycle management policy to automatically move inactive blobs to the Cool and Archive tiers. You plan to define the policy rules in a local file named policy.json and apply the policy using the Azure CLI. Which four actions should you perform in sequence? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To implement the lifecycle management policy, you must first upgrade the storage account from GPv1 to GPv2 because GPv1 does not support lifecycle policies. Next, you create the local policy.json file containing the policy rules. Then, you apply the policy to the storage account by running the az storage account management-policy create command. Finally, you verify that the policy is active by running the az storage account management-policy show command.
Upgrading the storage account from GPv1 to GPv2 is required first because lifecycle management policies are not supported on GPv1 accounts. Once upgraded, the rules must be defined in a JSON file. This file is then passed to the create command to apply the policy, and finally, the show command is run to verify the policy is active.

Step-by-Step Solution

1
Upgrade the storage account from General Purpose v1 (GPv1) to General Purpose v2 (GPv2).
The storage account is upgraded to GPv2, enabling support for lifecycle management policies.
Lifecycle management policies are only supported on General Purpose v2 (GPv2), Premium Block Blobs, and Blob Storage accounts.
2
Create the local policy.json file with the lifecycle rules.
The policy rules are defined in JSON format on the local machine.
The Azure CLI command to apply the policy requires a local path to a JSON file containing the policy rules.
3
Run the az storage account management-policy create command.
The lifecycle management policy is created and associated with the storage account.
This command applies the rules from the JSON file to the target storage account.
4
Run the az storage account management-policy show command.
The applied policy details are retrieved and displayed.
This confirms that the policy has been successfully configured and is active on the storage account.

Key Concept

Azure Blob Storage Lifecycle Management requires a GPv2 (or compatible) storage account and can be applied via the Azure CLI using a JSON policy file.
Question 235Question

You are developing a .NET microservice that processes user orders in a multi-tenant SaaS application. Each tenant has their own partition in an Azure Cosmos DB SQL API container, and all operations within a single order lifecycle must be executed within a single transaction. You need to write C# code using the Azure Cosmos DB .NET SDK v3 to configure the client, access the container, and run a transactional batch of operations. In which sequence should you perform the steps to configure the client and execute the transactional batch?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To perform a transactional batch operation in Azure Cosmos DB using the .NET SDK v3, you must first initialize a singleton CosmosClient with the required options. Next, obtain the Database and Container references. Since transactional batches operate on a single logical partition, you must define the PartitionKey. Then, initialize the TransactionalBatch using CreateTransactionalBatch on the container with the partition key. Finally, chain the operations onto the batch and call ExecuteAsync.
The correct sequence starts with client initialization (CosmosClient), followed by drilling down to the specific database and container references. Because transactional batching in Azure Cosmos DB requires operations to share the same partition key, the PartitionKey instance must be defined prior to calling CreateTransactionalBatch on the container. Finally, individual operations are chained to the batch, and ExecuteAsync is called to execute the entire transaction.

Step-by-Step Solution

1
Initialize CosmosClient
An active connection client to the Azure Cosmos DB account.
CosmosClient is the top-level SDK client needed for all subsequent operations.
2
Obtain Container Reference
A Container object representing the target collection.
Container operations and transaction builders are scoped to the container level.
3
Define PartitionKey
A PartitionKey structure representing the tenant ID.
Azure Cosmos DB requires the logical partition key value to scope a transactional batch.
4
Build TransactionalBatch
A TransactionalBatch object initialized for the target partition key.
The CreateTransactionalBatch factory method on the container initiates the transactional workflow.
5
Chain Operations and Execute
A TransactionalBatchResponse containing the status and results of each chained operation.
Chained operations are added to the batch, and ExecuteAsync transmits them as a single atomic transaction.

Key Concept

Initiating CosmosClient, obtaining Container references, constructing a PartitionKey, and executing a TransactionalBatch with .NET SDK v3.
Question 236Question

You are deploying a latency-sensitive Azure Function App (V4 runtime) that processes messages from an Azure Service Bus queue. The application must meet the following requirements:
- Avoid cold start latency for all invocations.
- Scale dynamically and automatically based on the volume of incoming queue messages.
- Keep a minimum of two instances pre-warmed and ready to handle requests at all times.

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

Select all that apply

Show answer & explanation

Answer: Create the Function App under an Azure Functions Premium hosting plan.; Configure the minimum number of pre-warmed instances to 2 in the hosting plan settings.

Answer

Create the Function App under an Azure Functions Premium hosting plan and configure the minimum number of pre-warmed instances to 2 in the hosting plan settings.
Creating the Function App under the Azure Functions Premium hosting plan satisfies both the dynamic scaling and cold start avoidance requirements. Configuring the minimum number of pre-warmed instances to 2 ensures that two instances are continuously running and ready to handle requests, eliminating cold start delays for those resources.

Step-by-Step Solution

1
Evaluate the hosting plan requirements.
Identify that the Premium plan is necessary because it supports both dynamic event-driven scaling (unlike Dedicated plans) and pre-warmed instances to eliminate cold start latency (unlike Consumption plans).
Choosing the correct hosting plan is the foundation for scaling and performance requirements.
2
Configure instance settings to meet the concurrency requirement.
Set the minimum pre-warmed instance count to 2.
This guarantees that two instances are active and ready to handle incoming queue messages immediately, avoiding cold starts.

Key Concept

Azure Functions Premium plan features and scale configuration
Estimated Time:1m 30s
Question 237Question

An organization has a workflow that polls the status of a long-running data export job. The workflow is implemented using Python Azure Durable Functions.

The orchestrator function is defined as follows:

python
import azure.functions as func
import azure.durable_functions as df
import datetime
import time

my_app = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@my_app.orchestration_trigger(context_name="context")
def export_monitor_orchestrator(context: df.DurableOrchestrationContext):
job_id = context.get_input()
expiry_time = datetime.datetime.utcnow() + datetime.timedelta(hours=2)

while datetime.datetime.utcnow() < expiry_time:
status = yield context.call_activity("CheckJobStatus", job_id)
if status == "Completed":
yield context.call_activity("SendSuccessAlert", job_id)
return "Finished"

time.sleep(300)

yield context.call_activity("SendTimeoutAlert", job_id)
return "Timeout"

The function app is hosted on an Azure Functions Consumption plan. During testing, the orchestration fails to complete successfully and frequently times out.

Which two modifications should you make to resolve the issues and ensure the orchestrator runs reliably? (Select two.)

Select all that apply

Show answer & explanation

Answer: Replace the datetime.datetime.utcnow() calls with context.current_utc_datetime.; Replace time.sleep(300) with a durable timer using yield context.create_timer().

Answer

Replace the datetime.datetime.utcnow() calls with context.current_utc_datetime and replace time.sleep(300) with a durable timer using yield context.create_timer().
To resolve the issues, the orchestrator must adhere to the determinism and non-blocking constraints of Azure Durable Functions. First, replacing the system clock calls with the context's current UTC datetime property ensures that the time remains consistent when the orchestrator replays. Second, replacing the thread-blocking sleep call with a durable timer yields control back to the functions host, allowing the orchestrator to shut down and wake up only when the timer expires. This avoids resource waste and runtime timeouts on the Consumption plan.

Step-by-Step Solution

1
Identify the determinism violation in the orchestrator code.
The code calls datetime.datetime.utcnow() multiple times, which returns the current wall-clock time and changes value during orchestrator replays.
Orchestrator functions must be deterministic; using standard system clock methods causes a runtime discrepancy on replay, throwing a NonDeterministicOrchestrationException.
2
Identify the thread-blocking call in the orchestrator code.
The code uses time.sleep(300) to delay the execution loop.
Blocking the execution thread stops the orchestrator from yielding control back to the host, resulting in execution timeouts on the Consumption plan and unnecessary resource usage.
3
Refactor the non-deterministic time checks.
Replace datetime.datetime.utcnow() with context.current_utc_datetime.
The context property guarantees consistent datetime values across orchestrator replays.
4
Refactor the thread-blocking sleep call.
Replace time.sleep(300) with yield context.create_timer(context.current_utc_datetime + datetime.timedelta(seconds=300)).
This creates a durable, non-blocking timer that schedules a wake-up event in the task hub and safely stops the function instance, releasing CPU and memory resources.

Key Concept

Orchestrator function determinism and non-blocking execution constraints in Azure Durable Functions.
Question 238Question

A logistics company is designing an Azure Cosmos DB for NoSQL database to track inventory movements across 15 high-volume regional warehouses. The system has the following requirements:

* Each warehouse processes up to 100,000 inventory transaction logs per day.
* To maintain inventory accuracy, the system must use the Azure Cosmos DB SDK's TransactionalBatch to perform atomic, multi-document updates (such as deducting stock from one bin and adding it to another) within a warehouse context.
* While the write throughput is extremely high and distributed across the warehouses, business analysts run daily reporting queries to analyze the complete historical data of a single warehouse, which requires scanning months of logs.
* The design must prevent logical partitions from exceeding the 20 GB storage limit while maintaining transactional integrity.

Which two of the following strategies should you implement to satisfy these requirements?

Select all that apply

Show answer & explanation

Answer: Create a synthetic partition key by concatenating the warehouse identifier and the current date (e.g., warehouseId_YYYY-MM-DD).; Execute operations that must succeed or fail atomically using the SDK's TransactionalBatch class, targeting the same synthetic partition key value.

Answer

Create a synthetic partition key by concatenating the warehouse identifier and the current date (e.g., warehouseId_YYYY-MM-DD), and execute operations that must succeed or fail atomically using the SDK's TransactionalBatch class targeting the same synthetic partition key value.
The correct strategy combines a synthetic partition key (the warehouse identifier and the current date) with TransactionalBatch. This ensures that atomic transactions (like transferring stock between bins) can be executed using TransactionalBatch because the items share the same logical partition. Furthermore, partitioning by date prevents any single warehouse's logical partition from growing indefinitely beyond the 20 GB limit.

Step-by-Step Solution

1
Analyze partition size constraints and transaction boundaries.
Identify that using a simple warehouse identifier partition key will cause the 20 GB logical partition limit to be exceeded over time, while a random suffix will break the transactional boundary needed for TransactionalBatch.
Azure Cosmos DB has a strict limit of 20 GB per logical partition, and TransactionalBatch operations are limited to a single logical partition.
2
Select a partition key strategy that balances write distribution and transactional scoping.
Choose a synthetic key that combines the warehouse identifier and a time window (e.g., warehouseId_YYYY-MM-DD).
This groups related daily operations within the same logical partition for transactions while preventing individual partitions from growing indefinitely.
3
Design SDK operations using the transaction scope.
Use TransactionalBatch for atomic writes, ensuring all operations in the batch point to the same synthetic partition key.
This guarantees transactional execution across the items sharing that synthetic key.

Key Concept

Azure Cosmos DB logical partition limits and transactional scopes
Question 239Question

You are developing a daemon application that runs on an on-premises physical server. The application must authenticate programmatically to Azure Key Vault to retrieve secrets. You need to configure the identity for this application. Which identity configuration should you use?

Show answer & explanation

Answer: Register an application in Microsoft Entra ID to create a service principal, and authenticate using a certificate or client secret.

Answer

Register an application in Microsoft Entra ID to create a service principal, and authenticate using a certificate or client secret.
For workloads hosted on-premises, a standard application registration must be created in Microsoft Entra ID. This registration creates an application object and a service principal. The application can then authenticate programmatically using a client secret or certificate credentials to obtain Entra ID tokens and access Azure resources like Key Vault.

Step-by-Step Solution

1
Identify the hosting environment of the daemon application.
The application runs on an on-premises physical server, which is outside the Azure boundary.
Managed identities are designed for applications running within Azure on supported resources. On-premises workloads require a standard registration.
2
Select the appropriate Microsoft Entra ID identity type.
An application registration is created, which generates a corresponding service principal in the tenant.
The service principal acts as the security principal representing the application identity in Microsoft Entra ID.
3
Configure credentials for the service principal.
Generate a client secret or upload a certificate associated with the application registration.
The daemon application on-premises will use these credentials to acquire tokens from Microsoft Entra ID to access Azure Key Vault.

Key Concept

App Registrations and Service Principals vs Managed Identities
Question 240Question

You are preparing to deploy a containerized application to Azure Container Instances (ACI). The container image is stored in a private Azure Container Registry (ACR). You need to configure the container group to pull the image from the registry using a managed identity to avoid using container registry credentials.

Which managed identity configuration must you use to allow the container group to pull the image?

Show answer & explanation

Answer: A user-assigned managed identity, because the identity must exist and have the appropriate permissions before Azure Container Instances initiates the image pull.

Answer

A user-assigned managed identity must be used because the identity must exist and have the appropriate permissions before Azure Container Instances initiates the image pull.
The correct answer is the option stating that a user-assigned managed identity must be used because the identity must exist and have the appropriate permissions before Azure Container Instances initiates the image pull. Because ACI needs to authenticate with ACR to retrieve the container image before the container group resource is fully provisioned, a system-assigned identity (which is only generated after the container group exists) cannot be used.

Step-by-Step Solution

1
Analyze the lifecycle of managed identities in Azure Container Instances (ACI).
System-assigned managed identities are created only when the container group resource is created, whereas user-assigned managed identities exist independently prior to container group deployment.
Understanding when each identity type is available is crucial for determining which one can be used for the initial image pull.
2
Determine the sequence of events during ACI deployment.
To spin up the container group, Azure must first pull the container image from the registry. Thus, the identity used for authentication must be fully active and authorized prior to the start of the container group creation.
This sequence explains why a system-assigned identity cannot be used, as it does not yet exist when the pull is initiated.
3
Select the correct identity type and configuration.
Use a user-assigned managed identity, assign it the AcrPull role on the registry, and configure the container group to use this identity for the image pull.
This ensures secure authentication without credentials and aligns with ACI's architectural constraints.

Key Concept

Managed Identity Authentication for Container Image Pulls in Azure Container Instances
PreviousPage 12 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin