Examkin

All practice questions

972 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 821Question →

You are configuring an Azure App Service web app named app-orders-prod that must retrieve a database connection string from an Azure Key Vault named kv-orders-prod. The web app is configured with multiple user-assigned managed identities. One of these identities, named id-orders-kv-reader, has the resource ID /subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/rg-prod/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-orders-kv-reader and has been granted the Key Vault Secrets User role. You need to configure the connection string as an application setting using a Key Vault reference that specifies the correct managed identity. Which of the following app setting values should you use?

Show answer & explanation

Answer: @Microsoft.KeyVault(SecretUri=https://kv-orders-prod.vault.azure.net/secrets/DbConnectionString/;UserAssignedIdentity=/subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/rg-prod/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-orders-kv-reader)

Answer

The setting value starting with @Microsoft.KeyVault and containing the UserAssignedIdentity parameter with the full resource ID of the managed identity.
The correct app setting value uses the '@Microsoft.KeyVault' prefix, references the secret using its URI ('SecretUri'), and explicitly specifies the resource ID of the user-assigned managed identity via the 'UserAssignedIdentity' parameter. This parameter is required when an App Service has multiple user-assigned managed identities configured, so the App Service knows which identity to use to authenticate against the Key Vault.

Step-by-Step Solution

1
Identify the correct namespace prefix for Key Vault references in App Service.
The reference must begin with '@Microsoft.KeyVault' to be parsed by the App Service token parser.
Prefixes like '@Azure.KeyVault' are syntactically invalid and will be treated as raw strings rather than dynamic references.
2
Determine the identity property name and value format needed for multiple user-assigned identities.
The property name must be 'UserAssignedIdentity', and the value must be the full Azure Resource Manager ID of the identity.
Short names or invalid parameter names like 'Identity' fail syntax validation, and omitting the identity leads to reference resolution errors when multiple user-assigned identities exist.
3
Combine the secret URI and identity details to construct the final reference string.
A semicolon-separated string containing 'SecretUri' and 'UserAssignedIdentity' is created.
This matches the official syntax requirements for user-assigned managed identities accessing Key Vault secrets via App Service configuration.

Key Concept

Azure App Service Key Vault References with User-Assigned Managed Identities
Question 822Question →

An organization has a data-processing pipeline that runs on a V4 Azure Function App using the Consumption hosting plan. A specific HTTP-triggered function in the app usually processes webhooks in under 2 minutes. However, during periodic bulk uploads, the execution time for some requests increases to approximately 8 minutes, causing the executions to time out and fail. You need to adjust the function app configuration to allow a maximum execution duration of 8 minutes for these long-running requests without migrating to a different hosting plan. How should you configure the function app?

Show answer & explanation

Answer: Modify the host.json configuration file at the root of the function app to include the functionTimeout property set to '00:08:00'.

Answer

Modify the host.json configuration file at the root of the function app to include the functionTimeout property set to '00:08:00'.
The correct action is to modify the host.json configuration file at the root of the function app by setting the 'functionTimeout' property to '00:08:00'. In Azure Functions V4, the Consumption plan has a default timeout of 5 minutes, but it can be configured up to a maximum of 10 minutes. Because 8 minutes is within the maximum limit, migrating to another hosting plan is not required.

Step-by-Step Solution

1
Determine the current hosting plan and its execution duration limits.
The function app is on the Consumption plan, which has a default timeout of 5 minutes and a maximum timeout of 10 minutes.
Since 8 minutes is under the 10-minute maximum limit, the requirement can be met on the Consumption plan without migrating the hosting plan.
2
Identify the configuration file and setting used to manage execution timeout in Azure Functions V4.
The 'functionTimeout' setting in the host.json file at the root of the function app configures the execution timeout.
Application settings (like local.settings.json or custom app settings) or autoscale rules are not used to configure the function execution duration timeout.
3
Apply the correct time format to the functionTimeout property.
Set 'functionTimeout' to '00:08:00' in the host.json file.
The value must be formatted as a timespan (hh:mm:ss).

Key Concept

Configuring execution timeout in host.json for Azure Functions V4
Estimated Time:1m 30s
Question 823Question →

You manage an Azure App Service web app named `app-catalog` that contains a production slot and a deployment slot named `staging`. The application uses an application setting named `DatabaseConnectionString` to connect to a database.

You must configure the web app to meet the following requirements:
- The staging slot must always connect to the staging database, and the production slot must always connect to the production database, even after a swap operation.
- The web app must perform a custom warm-up request to the path `/api/warmup` before the slot swap completes.

Which two configuration steps should you perform? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure DatabaseConnectionString as a deployment slot setting.; Add an application setting named WEBSITE_SWAP_WARMUP_PING_PATH and set its value to /api/warmup.

Answer

To configure the database connection strings to remain slot-specific and to specify a custom warm-up path, you must configure the DatabaseConnectionString setting as a deployment slot setting and add an application setting named WEBSITE_SWAP_WARMUP_PING_PATH with the value /api/warmup.
Marking the connection string as a deployment slot setting ensures it stays with the respective slot (staging connects to staging DB, production connects to production DB) after a swap. Setting the WEBSITE_SWAP_WARMUP_PING_PATH environment variable ensures that App Service performs the warm-up request to the custom path before routing production traffic to the new instance.

Step-by-Step Solution

1
Identify the mechanism to prevent app settings from swapping.
Determine that marking DatabaseConnectionString as a deployment slot setting (sticky setting) keeps the connection string bound to the slot during swaps.
By default, App Service swaps all non-sticky app settings between the staging and production slots. Marking it as a deployment slot setting prevents this.
2
Identify the setting for configuring a custom warmup path.
Determine that the WEBSITE_SWAP_WARMUP_PING_PATH app setting allows you to specify a custom endpoint for warm-up pings.
By default, App Service pings the root path (/). Specifying a path in WEBSITE_SWAP_WARMUP_PING_PATH allows a targeted warm-up of specific endpoints.

Key Concept

Configuring deployment slots and slot swap behaviors in Azure App Service.
Question 824Question →

You are developing an Azure CDN solution to distribute localized product description pages for an e-commerce website. The application uses a query string parameter to retrieve the localized content (for example, `https://cdn.contoso.com/products/info?lang=en` and `https://cdn.contoso.com/products/info?lang=fr`). You discover that French-speaking users are frequently served cached English pages. You must resolve this issue by ensuring that the CDN caches and serves the correct language variant for each request while still utilizing caching to improve response times. Which query string caching behavior should you configure on the CDN endpoint?

Show answer & explanation

Answer: Cache every unique URL

Answer

Cache every unique URL
The correct answer is to configure the 'Cache every unique URL' behavior. When this setting is enabled, each request with a unique URL, including the query string parameters, is treated as a separate asset with its own cache. This ensures that a request for the English page is cached and served separately from a request for the French page, while still taking advantage of CDN caching to optimize response times.

Step-by-Step Solution

1
Analyze the requirement to cache distinct page versions based on localized query string values (lang=en and lang=fr) while keeping caching enabled.
Identify that the CDN needs to treat query strings as part of the cache key rather than ignoring them or bypassing caching entirely.
Choosing the correct query string behavior is necessary to prevent users from receiving mismatched language content.
2
Evaluate the query string caching options available in Azure CDN.
Determine that 'Ignore query strings' serves the same cached version to everyone, and 'Bypass caching' turns off caching for these pages. Only 'Cache every unique URL' caches each variant separately.
This matches the criteria of serving the correct language while maintaining CDN caching benefits.

Key Concept

Azure CDN Query String Caching Behavior determines how requests with query parameters are cached on edge nodes.
Question 825Question →

You need to upload a locally built container image to a private Azure Container Registry (ACR) named contosoacr. Arrange the following commands in the correct sequence to authenticate your session and push the image to the registry.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of commands is to first run `az login` to authenticate with Azure, then run `az acr login --name contosoacr` to authenticate with the specific registry, and finally run `docker push contosoacr.azurecr.io/myimage:v1` to upload the image.
The correct order requires first authenticating with Azure via `az login` to set up the CLI credentials context. Next, `az acr login --name contosoacr` uses that context to log the Docker daemon into the target registry. Finally, `docker push contosoacr.azurecr.io/myimage:v1` uploads the image now that authentication is successful.

Step-by-Step Solution

1
Run `az login`.
Establishes an active Azure session in the Azure CLI.
This is required so subsequent Azure CLI commands can access subscription details and credentials.
2
Run `az acr login --name contosoacr`.
Authenticates the local Docker client daemon with the `contosoacr` registry.
This command retrieves registry credentials using the active Azure CLI session to allow Docker operations.
3
Run `docker push contosoacr.azurecr.io/myimage:v1`.
Transfers the container image to the Azure Container Registry.
Since the local Docker CLI is authenticated, the push command can upload the image to the login server without authorization errors.

Key Concept

To push local container images to a private Azure Container Registry (ACR), you must first authenticate with Azure using `az login`, authenticate the local Docker client to the registry using `az acr login`, and then execute `docker push` with the registry's login server path.
Question 826Question →

You are configuring an Azure App Service web app named webapp-prod that runs on a Linux App Service Plan. The web app must retrieve a database connection string from an Azure Key Vault named vault-prod.

To adhere to security best practices, you create a User-Assigned Managed Identity named identity-prod, grant it Secret Get permissions on vault-prod, and assign identity-prod to webapp-prod. You decide not to enable the System-Assigned Managed Identity.

You need to configure the web app's settings so that it can resolve the connection string from the latest version of the secret named db-conn in vault-prod.

Which of the following configurations must you apply?

Show answer & explanation

Answer: Set the web app's keyVaultReferenceIdentity site configuration property to the resource ID of identity-prod, and configure an application setting named DbConnectionString with the value @Microsoft.KeyVault(VaultName=vault-prod;SecretName=db-conn).

Answer

Set the web app's keyVaultReferenceIdentity site configuration property to the resource ID of identity-prod, and configure an application setting named DbConnectionString with the value @Microsoft.KeyVault(VaultName=vault-prod;SecretName=db-conn).
The correct configuration is to set the web app's keyVaultReferenceIdentity site configuration property to the resource ID of the user-assigned identity, and use the @Microsoft.KeyVault(VaultName=vault-prod;SecretName=db-conn) syntax for the application setting. This ensures App Service is explicitly told which user-assigned identity to use for token acquisition and provides the proper syntax for resolving the latest secret version.

Step-by-Step Solution

1
Assign the user-assigned identity to the web app.
The identity-prod identity is associated with webapp-prod, but App Service does not yet know which identity to use for Key Vault references.
By default, App Service attempts to use the system-assigned identity to fetch Key Vault references unless a specific user-assigned identity is defined.
2
Configure the keyVaultReferenceIdentity site configuration property.
The keyVaultReferenceIdentity property is set to the Azure Resource Manager (ARM) resource ID of identity-prod.
This configuration informs App Service which user-assigned identity should be used to authenticate against the Key Vault when resolving app setting references.
3
Set the application setting using the correct reference syntax.
An application setting named DbConnectionString is created with the value @Microsoft.KeyVault(VaultName=vault-prod;SecretName=db-conn).
This syntax references the key vault by name and specifies the secret. Omitting the version parameter ensures that App Service always retrieves the latest version of the secret.

Key Concept

Key Vault references in Azure App Service with User-Assigned Managed Identities require specifying the keyVaultReferenceIdentity site configuration property using the identity's resource ID, along with the proper @Microsoft.KeyVault reference syntax.
Question 827Question →

You are designing an Azure Cosmos DB container to store reservation records for a hotel management system. Each reservation includes the fields `hotelId`, `guestId`, `reservationDate`, and `status`. You need to configure the container to support multi-document transactional batches for reservations at the same hotel, while avoiding hot partitions.

Which two configuration choices should you make? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the partition key of the container to `/hotelId`; Ensure that all operations within a single transactional batch specify the same `/hotelId` value

Answer

Configure the container with `/hotelId` as the partition key and ensure all operations in a transactional batch target the same `/hotelId` value.
To support transactional batches for reservations at the same hotel, the container must be partitioned by `/hotelId` so that all reservations for a given hotel reside in the same logical partition. Furthermore, all operations within a transactional batch must target this same partition key value, as transactional batches cannot span multiple logical partitions.

Step-by-Step Solution

1
Analyze the transactional requirement
Multi-document transactions in Azure Cosmos DB (using transactional batches) require all involved documents to share the same partition key value (i.e., reside in the same logical partition).
Since the transactions must be executed for reservations at the same hotel, the partition key must group reservations by hotel, pointing to `/hotelId`.
2
Verify partitioning rules for transactional batches
All operations in a transactional batch must target the same partition key value. Therefore, you must ensure all operations in the batch use the same `/hotelId`.
Cross-partition transactional batches are not supported in Azure Cosmos DB.
3
Evaluate distractors for partition key suitability
Partitioning by `/status` is rejected due to low cardinality (leading to hot partitions), and cross-partition transactions are structurally impossible.
Ensures the system remains scalable and performs within transactional boundary constraints.

Key Concept

Azure Cosmos DB partition keys must be chosen to align with transactional boundaries (which are limited to a single logical partition) while avoiding hot partitions by ensuring sufficient cardinality.
Estimated Time:1m 0s
Question 828Question →

An organization is deploying an Azure Function App (V4 runtime) that requires access to a database password. To secure the credential, the password is stored in an Azure Key Vault. A developer configures an App Setting in the Function App named DatabaseConnectionString with the value @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/dbpassword/). When the function executes, it is unable to connect to the database because the environment variable retrieves the raw @Microsoft.KeyVault(...) reference string instead of the resolved secret value. Which of the following is the most likely cause of this behavior?

Show answer & explanation

Answer: The system-assigned managed identity of the Function App has not been granted GET permissions on secrets in the Key Vault access policies or Azure role-based access control.

Answer

The system-assigned managed identity of the Function App has not been granted GET permissions on secrets in the Key Vault access policies or Azure role-based access control.
The App Service and Azure Functions runtime resolves Key Vault references at startup or configuration reload using the app's managed identity. If the system-assigned managed identity of the Function App does not have GET permission on secrets in the Key Vault, the platform fails to retrieve the secret and defaults to exposing the raw configuration string to the application code.

Step-by-Step Solution

1
Identify the mechanism used by the Azure Functions host to resolve Key Vault references.
The Azure Functions platform uses the app's configured managed identity to authenticate and retrieve the secrets from Key Vault.
To troubleshoot the failure of resolving Key Vault references, we must check the authentication and authorization flow between the Function App and the Key Vault.
2
Verify the access control settings on the Key Vault.
The managed identity must be granted GET permission for secrets in either the Key Vault Access Policies or through Azure RBAC (using Key Vault Secrets User role).
Without explicit GET permission, the platform's requests to retrieve the secrets will be denied, causing the runtime to fall back to the raw reference string.
3
Evaluate and eliminate incorrect configuration and hosting constraints.
Omit version constraints are allowed (automatically resolves to latest), both system-assigned and user-assigned identities are supported, and all hosting plans support Key Vault references.
This confirms that the absence of permissions is the only plausible issue causing the raw string to be returned.

Key Concept

Key Vault references in Azure Functions allow app settings to securely reference secrets stored in Key Vault, requiring appropriate managed identity configurations and access policies.
Estimated Time:1m 30s
Question 829Question →

You need to create a new Azure Function App on an Elastic Premium plan using the Azure CLI. Which sequence of commands should you execute? To answer, arrange the steps in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of commands is to first create the resource group, then create the storage account, followed by creating the Elastic Premium App Service plan, and finally creating the Function App.
The resource group must exist first. Then, the storage account and the App Service plan are created as they have no mutual dependencies but both require the resource group. Finally, the function app is created because it depends on the resource group, the storage account, and the App Service plan.

Step-by-Step Solution

1
Create the Resource Group
az group create --name myResourceGroup --location eastus
All other resources require a resource group to be defined first.
2
Create the Storage Account
az storage account create --name mystorageaccount --location eastus --resource-group myResourceGroup --sku Standard_LRS
The function app relies on standard storage for state and key management.
3
Create the App Service Plan
az appservice plan create --name myPremiumPlan --resource-group myResourceGroup --sku EP1 --is-linux
An Elastic Premium plan (EP1 SKU) is required before assigning the function app to it.
4
Create the Function App
az functionapp create --name myFunctionApp --resource-group myResourceGroup --storage-account mystorageaccount --plan myPremiumPlan --runtime dotnet-isolated --functions-version 4
The function app links the previously created storage account and hosting plan.

Key Concept

Azure Functions resources have creation dependencies: a resource group must exist first, followed by storage and hosting plan resources, before the function app itself can be initialized.
Question 830Question →

You are designing an Azure Cosmos DB container to store chat messages for a multi-tenant enterprise collaboration application. The application supports thousands of corporate tenants, each containing numerous distinct chat channels.

The workload has the following characteristics:
- Writes are heavy and occur continuously across all active channels.
- The most frequent query retrieves the history of a specific chat channel, sorted by timestamp.
- The application uses transactional batch operations to insert, update, or delete multiple messages within a single channel as an atomic unit.
- A single tenant's data can exceed 20 GB20\text{ GB} over time, whereas any individual channel's data is guaranteed to remain under 2 GB2\text{ GB}.

You need to select a partition key that ensures scalability, avoids hot partitions, and supports the transactional requirements.

Which partition key strategy should you implement?

Show answer & explanation

Answer: Create a synthetic partition key by combining the tenant ID and the channel ID.

Answer

Create a synthetic partition key by combining the tenant ID and the channel ID.
The correct strategy is to create a synthetic partition key by combining the tenant ID and the channel ID. In Azure Cosmos DB, transactional batches are constrained to a single logical partition, meaning all items in the transaction must share the same partition key value. Combining tenant ID and channel ID ensures that all messages in a specific channel are stored in the same partition, enabling atomic batch operations and efficient single-partition reads for channel history. Additionally, because any single channel's data is guaranteed to be under 2 GB2\text{ GB} (well below the 20 GB20\text{ GB} logical partition limit), this strategy avoids partition size issues and distributes the active write workload across many distinct partitions, preventing hot partitions.

Step-by-Step Solution

1
Analyze the transactional boundary requirements of the application.
Cosmos DB transactions (like transactional batches or stored procedures) must occur within a single logical partition (items must share the same partition key value).
Since the application needs to run transactional batch operations on messages within a single channel, the partition key must encompass the channel identifier.
2
Analyze the partition size and cardinality constraints.
A single tenant's data can exceed the 20 GB20\text{ GB} logical partition limit, while channel data is guaranteed to remain under 2 GB2\text{ GB}. Using the tenant ID alone is invalid because it violates the partition size limit. Using a unique message ID or sender ID prevents transactional batches on channels.
We must choose a key that keeps a single channel's data in one partition while remaining under 20 GB20\text{ GB} and avoiding hot partitions.
3
Synthesize a partition key to meet both criteria.
Combining the tenant ID and the channel ID (e.g., 'tenant123_channel456') satisfies all requirements.
This synthetic key groups channel messages into a single partition for transactions and efficient reads, keeps partitions below the 20 GB20\text{ GB} limit, and distributes the workload across many partitions to prevent hot partitions.

Key Concept

Synthetic partition keys and transaction boundaries in Azure Cosmos DB
Question 831Question →

You are deploying an Azure Container App named shipping-service that pulls its container image from a private Azure Container Registry (ACR). You enable a system-assigned managed identity on the Container App, but the deployment fails with an error indicating that the image cannot be pulled. Which action should you perform to resolve this deployment failure?

Show answer & explanation

Answer: Assign the AcrPull role to the Container App's system-assigned managed identity at the scope of the Azure Container Registry.

Answer

Assign the AcrPull role to the Container App's system-assigned managed identity at the scope of the Azure Container Registry.
To allow an Azure Container App to securely pull images from a private Azure Container Registry, the Container App's managed identity must be granted the AcrPull role at the registry's scope. This allows the host environment to retrieve the image using Azure AD authentication.

Step-by-Step Solution

1
Determine the identity type configured on the Container App.
The Container App uses a system-assigned managed identity.
This identifies the security principal that needs permissions to pull images.
2
Grant the required permissions on the target Azure Container Registry.
The system-assigned managed identity is granted the AcrPull role.
This allows the Container App runtime to authenticate against the private ACR.

Key Concept

Configuring secure private registry access using managed identities in Azure Container Apps
Question 832Question →

You are developing an order processing workflow using Azure Durable Functions in C# (.NET Isolated). You need to write an HTTP-triggered function that acts as the entry point to start the orchestration workflow. Which parameter binding attribute must you use to obtain a client instance for starting the orchestrator?

Show answer & explanation

Answer: [DurableClient]

Answer

The [DurableClient] attribute must be used to bind the client parameter that starts the orchestration.
The [DurableClient] attribute binds the client parameter (such as DurableTaskClient in .NET Isolated) to the function, enabling it to start new orchestration instances.

Step-by-Step Solution

1
Identify the role of the entry-point function.
The entry-point function (such as an HTTP-triggered function) needs to start the orchestrator using a client object.
Durable Functions use client bindings to interact with orchestrations from non-durable functions.
2
Select the correct binding for the client in .NET Isolated.
Use the [DurableClient] attribute on a DurableTaskClient parameter.
This binding instantiates the client-side wrapper allowing developers to invoke StartNewAsync or other management methods.

Key Concept

Durable Functions Client Binding
Estimated Time:45s
Question 833Question →

You are configuring a lifecycle management policy for a Standard General Purpose v2 (GPv2) storage account to minimize costs for log blobs. The policy will transition blobs through various access tiers and eventually delete them.

Arrange the following lifecycle policy events in the correct chronological order of execution for a newly created blob, starting from the earliest event to the latest.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological order starts with uploading the blob to the Hot tier, followed by transitioning it to the Cool tier (`tierToCool`), then transitioning it to the Archive tier (`tierToArchive`), and finally permanently deleting the blob (`delete`).
The correct chronological sequence for optimizing costs moves the blob from the Hot tier (initial upload) to the Cool tier (`tierToCool`), then to the Archive tier (`tierToArchive`), and lastly to the deleted state (`delete`). This aligns with the progressive decline in storage tier costs and access frequencies.

Step-by-Step Solution

1
Identify the initial state of the blob.
The blob starts in the Hot tier upon upload.
Standard GPv2 accounts default to the Hot tier for new blob writes unless specified otherwise.
2
Determine the first cost-tier transition.
Transition to the Cool tier (`tierToCool`).
Cool tier is the next progressive tier offering lower storage costs than Hot but higher than Archive.
3
Determine the second cost-tier transition.
Transition to the Archive tier (`tierToArchive`).
Archive tier offers the lowest storage costs but has high retrieval latency and cost, suitable for historical data before deletion.
4
Identify the final lifecycle action.
Permanent deletion (`delete`).
Deleting the blob removes it permanently to prevent any further storage charges.

Key Concept

Azure Storage Lifecycle Management allows automatic transitioning of blobs to cooler storage tiers (Hot to Cool, Cool to Archive) and deletion based on age rules.
Question 834Question →

When implementing authentication and authorization in Microsoft Entra ID, developers must understand the relationships between different identity objects. Which two of the following statements correctly describe the characteristics or roles of application objects and service principals?

Select all that apply

Show answer & explanation

Answer: The application object serves as the global definition of the application and remains in the tenant where the application was registered.; A service principal is the local representation of the application object in a specific tenant and is used to define access policies and permissions.

Answer

The correct statements are that the application object serves as the global definition of the application and remains in the tenant where the application was registered, and a service principal is the local representation of the application object in a specific tenant used to define access policies and permissions.
The statement about the application object serving as the global definition in the home tenant is correct because the application object defines the application's configuration globally. The statement about the service principal being the local instance is correct because the service principal acts as the security identity (instance) in each tenant to enforce access policies.

Step-by-Step Solution

1
Analyze the relationship between application objects and service principals.
Identify that the application object is the global definition of the app, while the service principal is the concrete local instance (identity) created in a tenant to manage access.
This establishes the fundamental distinction between application objects and service principals in Microsoft Entra ID.
2
Evaluate the statements regarding managed identities.
Determine that managed identities (system-assigned or user-assigned) are restricted to Azure resources and cannot be assigned to on-premises applications, nor are they automatically created during standard application registration.
This rules out incorrect options that confuse service principals with managed identities.

Key Concept

The relationship and differences between application objects, service principals, and managed identities in Microsoft Entra ID.
Question 835Question →

You are writing a .NET application to update the custom metadata of an Azure Blob Storage blob. The blob currently has an active exclusive-write lease.

Which of the following is required to successfully update the blob's metadata?

Show answer & explanation

Answer: Provide the active lease ID in the request conditions.

Answer

Providing the active lease ID in the request conditions is required to update the metadata of a leased blob.
Updating metadata is a write operation. When a blob is leased, any write operation must include the active lease ID. Passing this ID in the request conditions allows the storage service to verify ownership of the lock and permit the metadata change.

Step-by-Step Solution

1
Identify that updating metadata is a write operation on the blob.
Recognize that metadata operations are subject to the same concurrency controls as content updates.
This establishes that any active locks on the blob will affect the metadata update request.
2
Check the lease status of the blob.
Identify that the blob has an active exclusive-write lease.
An active lease prevents any modifications unless the correct lease ID is supplied.
3
Include the active lease ID in the request parameters when calling the update method.
The SDK attaches the lease ID to the request headers, allowing the update to proceed.
This satisfies the lease precondition and prevents a Precondition Failed (HTTP 412) error.

Key Concept

Writing or modifying a leased blob's properties or metadata requires specifying the active lease ID in the request.
Question 836Question →

An order processing system uses a C# background worker running the Azure.Storage.Blobs SDK to inspect inbound XML invoices. An external partner uploads these invoices and programmatically sets a custom metadata field with the key `ApprovalStatus` and value `Pending` to flag items for review.

The background worker retrieves the blob details using the following code segment:

csharp
BlobClient client = containerClient.GetBlobClient("invoice_992.xml");
BlobProperties properties = await client.GetPropertiesAsync();

The application must check if the `ApprovalStatus` metadata key is present. However, the evaluation logic consistently fails to detect the metadata key when querying `properties.Metadata`.

Which of the following describes the correct way to check for the presence of this metadata key in the dictionary?

Show answer & explanation

Answer: Query the properties.Metadata dictionary using the lowercase string "approvalstatus" as the key.

Answer

Query the properties.Metadata dictionary using the lowercase string "approvalstatus" as the key.
Querying the properties.Metadata dictionary using the lowercase string "approvalstatus" is correct because the Azure Storage REST API returns custom metadata keys as lowercase HTTP headers. When the SDK processes these headers, it removes the prefix and creates a standard C# dictionary with the lowercase keys. Since standard C# dictionaries are case-sensitive, only the lowercase key will successfully match.

Step-by-Step Solution

1
Analyze how Azure Storage stores and transmits metadata.
Metadata is stored as name-value pairs and sent over HTTP using the x-ms-meta-name prefix. The storage service processes metadata keys in a case-insensitive manner.
This explains why the casing is modified during HTTP transmission.
2
Determine the output format of the metadata headers.
The Azure Storage REST API returns all metadata headers in lowercase (e.g., x-ms-meta-approvalstatus: Pending).
This establishes that the incoming payload headers are fully lowercased.
3
Inspect how the Azure SDK for .NET populates the Metadata property.
The SDK strips the 'x-ms-meta-' prefix and puts the key-value pair into a standard case-sensitive C# Dictionary<string, string> using the lowercase key name 'approvalstatus'.
Understanding the C# Dictionary behavior highlights why the mixed-case lookup fails.
4
Identify the correct lookup key.
The lookup must use the exact lowercase string 'approvalstatus' to match the key in the case-sensitive dictionary.
This resolves the key mismatch and ensures the condition evaluates correctly.

Key Concept

Azure Blob Storage custom metadata keys are returned as lowercase HTTP headers and are parsed by the SDK into a case-sensitive dictionary using only their lowercase names.
Estimated Time:2m 0s
Question 837Question →

You are designing a globally distributed application that utilizes Azure Cosmos DB. You need to select the most appropriate consistency level for three different application scenarios to meet their architectural requirements while optimizing for request units (RUs) and performance. Match each application scenario to its optimal Azure Cosmos DB consistency level.

Click a left item, then click its matching right item

Items

A retail checkout application uses a globally distributed Azure Cosmos DB account configured with a single-write region and multiple read regions. To prevent stock discrepancies, client applications must be guaranteed to read the most recent, fully committed write from any region, regardless of latency overhead.
An e-commerce user profile application runs on a globally distributed Azure Cosmos DB account with multiple read regions. A web application must guarantee that a user who edits their shipping address will always see the updated address on subsequent page loads within their browser session. Other users do not need to see the update immediately.
A global package tracking application uses an Azure Cosmos DB account with multiple write regions. The tracking system logs package scan events sequentially (e.g., 'Departed facility' must never be visible before 'Arrived at facility'). The application must guarantee that reads see updates in their exact write order, while keeping Request Unit (RU) costs lower than Bounded Staleness.

Matches

Show answer & explanation

Answer

The retail checkout application scenario matches Strong consistency, the e-commerce user profile application matches Session consistency, and the global package tracking application matches Consistent Prefix consistency.
The correct pairings align each scenario with the lowest-overhead consistency level that satisfies its core requirements. The checkout system requires Strong consistency to prevent stock discrepancies. The user profile updates are scoped to a browser session, making Session consistency the ideal choice for read-your-own-writes. The tracking system requires ordered updates without real-time consistency, which is satisfied by Consistent Prefix at a lower cost than Bounded Staleness.

Step-by-Step Solution

1
Analyze the requirements for the retail checkout application.
The application requires absolute global consistency to prevent stock discrepancies, meaning reads must always return the most recent write. This requires Strong consistency.
Strong consistency is the only level that guarantees reads always return the latest committed write globally.
2
Analyze the requirements for the user profile application.
The user must immediately see their own shipping address updates on subsequent page loads, which is a classic read-your-own-writes requirement scoped to a browser session. This matches Session consistency.
Session consistency is scoped to the client session and guarantees read-your-own-writes, monotonic reads, and monotonic writes.
3
Analyze the requirements for the package tracking application.
The package tracking events must be read in the exact order they were written to avoid logical inconsistencies (e.g., departed before arrived), but real-time global synchronization is not needed. The cost must be lower than Bounded Staleness, which points to Consistent Prefix.
Consistent Prefix guarantees that reads see updates as a prefix of all writes in order, with lower resource overhead than Bounded Staleness.

Key Concept

Understanding and selecting Azure Cosmos DB consistency levels based on application requirements, latency, ordering guarantees, and resource cost.
Question 838Question →

You are developing a custom script that runs on an on-premises server to automate resource provisioning in Azure. The script must authenticate programmatically with Microsoft Entra ID using a dedicated service principal associated with an application registration. Which of the following credential types can be configured directly on the application registration to enable this authentication? (Select TWO)

Select all that apply

Show answer & explanation

Answer: A client secret (symmetric key) created under the Certificates & secrets settings; An uploaded public certificate (asymmetric key) under the Certificates & secrets settings

Answer

A client secret (symmetric key) created under the Certificates & secrets settings and an uploaded public certificate (asymmetric key) under the Certificates & secrets settings.
Microsoft Entra ID application registrations support two credential types for authenticating a service principal: client secrets (symmetric keys) and certificates (asymmetric keys). Client secrets act as passwords, while certificates allow using cryptography by uploading a public key (.cer, .pem, etc.), which is more secure for production daemon applications or scripts.

Step-by-Step Solution

1
Identify the authentication requirements for the on-premises automation script using a Microsoft Entra ID application registration.
The script requires credentials to authenticate as a service principal.
On-premises resources cannot use Azure-managed identities directly and must use standard credentials associated with the app registration.
2
Evaluate the valid credential options available under the application registration settings in Microsoft Entra ID.
Microsoft Entra ID allows configuring either client secrets (symmetric keys) or uploading public certificates (asymmetric keys).
These are the two primary mechanisms to authenticate an application registration's service principal.
3
Select the correct options based on the evaluation.
Client secrets and public certificates are the correct choices.
Managed identities and Shared Access Signatures are distinct Azure features that do not serve as direct credentials on an application registration.

Key Concept

Microsoft Entra application registrations support two primary types of credentials for service principal authentication: client secrets and certificates.
Question 839Question →

You are developing a custom ASP.NET Core Web API that will consume events from an Azure Event Grid system topic. When you attempt to create the Event Grid subscription with the Web API endpoint as the Webhook destination, the subscription creation fails. You determine that the Web API endpoint is not correctly responding to the subscription validation request sent by Event Grid.

Which response must the Web API endpoint return to Event Grid to successfully complete the synchronous subscription validation handshake?

Show answer & explanation

Answer: An HTTP 200 OK response containing a JSON object in the body with a property named validationResponse set to the value of validationCode found in the request event data.

Answer

An HTTP 200 OK response containing a JSON object in the body with a property named validationResponse set to the value of validationCode found in the request event data.
For synchronous endpoint validation, Azure Event Grid sends a subscription validation event to the configured Webhook endpoint. The endpoint must respond with an HTTP status code 200 OK and a JSON body containing a property named validationResponse set to the value of validationCode that was sent in the request payload.

Step-by-Step Solution

1
Extract the request body JSON payload sent by Azure Event Grid during subscription creation.
You obtain an array containing a validation event of type Microsoft.EventGrid.SubscriptionValidationEvent.
Event Grid sends a validation event containing a validationCode in the data object to verify the endpoint ownership.
2
Parse the validationCode from the event data object.
You retrieve the unique validation code string sent by Event Grid.
This code must be returned back to Event Grid to prove control of the webhook endpoint.
3
Construct a JSON response with a single property named validationResponse, assigning it the extracted validationCode value, and return it with a 200 OK HTTP status.
The validation process succeeds, and the Event Grid subscription is successfully created.
Event Grid expects this specific JSON structure and HTTP status code to verify the handshake synchronously.

Key Concept

Azure Event Grid Webhook endpoint validation handshake requires echoing the validationCode using the validationResponse key in an HTTP 200 OK response.
Estimated Time:1m 30s
Question 840Question →

An enterprise is deploying a web application behind an Azure CDN Standard from Microsoft endpoint. The application has three categories of assets with distinct caching requirements:

* `/reports/*`: Serves sensitive, user-specific PDF reports generated on-demand with query parameters (e.g., `/reports/download?user=123&token=abc`). These must never be cached on the CDN edge servers.
* `/images/*`: Contains product photos that are updated using a version query parameter (e.g., `/images/keyboard.jpg?ver=2.4`). To ensure immediate updates, the CDN must cache these based on the `ver` parameter only, while ignoring all tracking parameters (e.g., `utm_source`) to prevent cache pollution.
* `/styles/*`: Contains static CSS files where the origin server does not set any `Cache-Control` headers. These files must be cached for exactly 14 days, regardless of any future caching headers added to the origin server.

The endpoint's global Query String Caching behavior is set to 'Ignore query strings'.

Which configuration of caching rules and rules engine rules should you implement to meet these requirements?

Show answer & explanation

Answer: Create a Rules Engine rule matching `/reports/*` with the Cache expiration action set to Bypass cache. Create a Rules Engine rule matching `/images/*` with the Cache-key query string action set to Include with the parameter value `ver`. Create a Rules Engine rule matching `/styles/*` with the Cache expiration action set to Override with a duration of 14 days.

Answer

The correct configuration is to create three Rules Engine rules: one bypassing the cache for `/reports/*`, one using the Cache-key query string action with the Include behavior for parameter `ver` on `/images/*`, and one setting Cache expiration to Override with a duration of 14 days on `/styles/*`.
The correct configuration utilizes the Azure CDN Standard Rules Engine to target specific paths and apply fine-grained caching rules. For the sensitive reports, bypassing the cache entirely ensures security. For the versioned images, using the Cache-key query string action with the Include behavior and specifying the 'ver' parameter ensures that only changes to the version number result in a new cache entry, while other parameters (like tracking codes) are ignored to prevent cache pollution. For the stylesheets, setting Cache expiration to Override guarantees that the CDN caches the assets for 14 days, ignoring any future Cache-Control headers returned by the origin server.

Step-by-Step Solution

1
Analyze the caching requirement for the `/reports/*` path, which contains sensitive user-specific data.
Determine that caching must be bypassed entirely. This requires configuring a match rule for the path `/reports/*` and setting the Cache expiration action to 'Bypass cache'.
Bypassing the cache ensures that sensitive user-specific reports are never stored on CDN edge servers, preventing data leakage.
2
Analyze the caching and query string requirement for the `/images/*` path.
Determine that version query strings (`ver`) must trigger cache updates, but other query strings (like tracking parameters) must be ignored. This requires the 'Cache-key query string' action set to 'Include' with the parameter name 'ver'.
Including only the 'ver' parameter in the cache key ensures version updates are immediately reflected, while ignoring tracking parameters prevents cache pollution and low cache hit ratios.
3
Analyze the caching requirement for the `/styles/*` path.
Determine that stylesheets must be cached for exactly 14 days regardless of future origin headers. This requires configuring a match rule for `/styles/*` and setting the Cache expiration action to 'Override' with a duration of 14 days.
Using 'Override' ensures that the CDN-specified TTL is enforced even if the origin server starts sending Cache-Control headers, whereas 'Set if missing' would honor the origin's headers.

Key Concept

Fine-grained caching control using the Azure CDN Standard Rules Engine and Cache-key query string configurations.
Estimated Time:3m 0s
PreviousPage 42 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin