All practice questions

972 questions

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

You are developing a C# administrative utility to reset the checkpoint state for an active Azure Event Hub consumer group. The consumer application uses the EventProcessorClient and stores checkpoints as blobs in Azure Blob Storage.

When the utility attempts to delete a checkpoint blob using BlobClient.DeleteAsync(), the operation fails with an HTTP status code 412 (Precondition Failed).

What is the cause of this error, and how should it be resolved?

The checkpoint blob has an active lease held by a running EventProcessorClient instance to coordinate partition ownership. You must stop the event processor instances to release the lease, or specify the active lease ID in the delete request.

The utility is authenticated using a system-assigned managed identity, which cannot modify or release leases owned by user-assigned managed identities. You must migrate the service principal to a user-assigned managed identity.

The delete request failed because the utility attempted to perform the operation using ReceiveAndDelete mode, which is incompatible with leased blobs. You must modify the storage client configuration to use PeekLock mode.

The checkpoint blob contains metadata that exceeds the maximum payload limit of 64 KB allowed for single-transaction deletions. You must first clear the blob's metadata before deleting it.

Show answer & explanation

Answer: The checkpoint blob has an active lease held by a running EventProcessorClient instance to coordinate partition ownership. You must stop the event processor instances to release the lease, or specify the active lease ID in the delete request.

Answer

The correct answer is that the checkpoint blob is actively leased by the EventProcessorClient to manage partition ownership. To resolve the issue, you must stop the event processors to release the lease, or supply the lease ID when calling the delete API.

Step-by-Step Solution

Identify the cause of the HTTP 412 (Precondition Failed) error during the blob deletion attempt.

The error occurs because the target blob has an active lease associated with it, which is being held by the EventProcessorClient to coordinate partition ownership.

Azure Blob Storage returns HTTP 412 when a write or delete operation is attempted on a leased blob without providing the lease ID.

Determine the correct mitigation strategy to safely release or bypass the lease restriction.

The running EventProcessorClient instances must be stopped to release their partition leases, or the active lease ID must be acquired and supplied in the request options.

Stopping the processor releases all active partition ownership leases, allowing administrative cleanup tools to safely delete or modify checkpoint metadata.

Key Concept

Partition lease coordination and checkpoint management using EventProcessorClient and Azure Blob Storage.

Question 682Question →

A developer is designing an integration solution that buffers messages using Azure Queue Storage. The developer expects some message payloads to occasionally exceed the standard size limit of a single queue message.

What is the maximum message size supported for a single message in Azure Queue Storage, and how should payloads exceeding this limit be handled?

64\text{ KB}

; store the payload in Azure Blob Storage and place the blob reference URI in the queue message.

256\text{ KB}

; store the payload in Azure Service Bus and place the Service Bus message ID in the queue message.

1\text{ MB}

; split the payload across multiple queue messages and use a correlation ID to reassemble them.

64\text{ KB}

; generate a Shared Access Signature (SAS) token with write permissions to temporarily bypass the limit.

Show answer & explanation

Answer: $64\text{ KB}$ ; store the payload in Azure Blob Storage and place the blob reference URI in the queue message.

Answer

The maximum message size limit for Azure Queue Storage is

64\text{ KB}

. Payloads exceeding this limit should be stored in Azure Blob Storage, and the reference URI to the blob should be placed in the queue message.

The correct answer specifies that the maximum message size limit for Azure Queue Storage is

64\text{ KB}

. To handle payloads exceeding this limit, the developer should implement the claim-check pattern. This involves uploading the large payload to Azure Blob Storage and storing only the resulting blob URI in the queue message. The consumer can then read the URI from the queue and download the payload directly from Blob Storage.

Step-by-Step Solution

Determine the maximum size limit for Azure Queue Storage messages.

The limit is identified as

64\text{ KB}

Azure Queue Storage restricts individual message payloads to a maximum of

64\text{ KB}

Select the appropriate storage service for large payloads.

Azure Blob Storage is selected to store the large message payload.

Blob Storage is optimized for unstructured data and large files, making it the ideal store for payloads that exceed the queue limit.

Link the queue message to the stored payload.

The queue message is written to contain only the URI pointing to the blob containing the actual payload.

This implements the claim-check pattern, ensuring the queue message remains small and lightweight while still providing access to the full payload.

Key Concept

Azure Queue Storage message size limit and the claim-check pattern using Azure Blob Storage.

Question 683Question →

A developer is deploying a Go-based web application to Azure App Service. The application must retrieve a database connection string stored in an Azure Key Vault named `kv-prod-westus`. A system-assigned managed identity is enabled for the App Service.

You configure an application setting in the App Service with the key `DbConnectionString` and the value `@Microsoft.KeyVault(VaultName=kv-prod-westus;SecretName=DbConnectionString)`.

During testing, the application fails to retrieve the secret value and instead reads the raw reference string.

Which of the following is the most likely cause of this issue?

The App Service application setting key must match the secret name in the Key Vault exactly for the reference to resolve.

The system-assigned managed identity of the App Service has not been granted the 'Get' secret permission in the Key Vault access policies or Azure RBAC roles.

The Key Vault reference must be configured using a user-assigned managed identity, as system-assigned managed identities are not supported for Key Vault references.

The Key Vault reference value is using incorrect syntax because the secret version parameter is required when referencing secrets by name.

Show answer & explanation

Answer: The system-assigned managed identity of the App Service has not been granted the 'Get' secret permission in the Key Vault access policies or Azure RBAC roles.

Answer

The system-assigned managed identity of the App Service has not been granted the 'Get' secret permission in the Key Vault access policies or Azure RBAC roles.

The correct answer is that the system-assigned managed identity lacks the necessary 'Get' secret permission. When Azure App Service is unable to resolve a Key Vault reference—due to missing permissions, network restrictions, or deletion of the resource—it will populate the environment variable with the raw reference string instead of failing the deployment or throwing an exception.

Step-by-Step Solution

Analyze the configuration and the observed behavior where the application receives the raw `@Microsoft.KeyVault(...)` reference string instead of the secret value.

Confirm that the syntax of the reference is correct and that the App Service is failing to resolve the reference at runtime.

When a Key Vault reference cannot be resolved due to configuration or access issues, App Service defaults to passing the raw reference string to the application code.

Verify the syntax of the Key Vault reference: `@Microsoft.KeyVault(VaultName=kv-prod-westus;SecretName=DbConnectionString)`.

The syntax is valid because it specifies both the correct vault name and secret name, and the secret version is optional.

This rules out syntax errors as the cause of the failure.

Check the authentication and authorization configuration between the App Service and the Key Vault.

The App Service has a system-assigned managed identity enabled, but it needs explicit authorization to read secrets.

For the App Service to retrieve the secret, its managed identity must be granted the 'Get' secret permission via Key Vault access policies or Azure RBAC (Key Vault Secrets User role).

Key Concept

Key Vault references in Azure App Service require correct syntax and appropriate read permissions ('Get' secret permission) granted to the app's managed identity in the Key Vault.

Question 684Question →

A microservice API gateway runs on an Azure App Service plan (Premium V3 tier) that is currently scaled to $4$ instances. You configure an autoscale setting with the following scale-out rule:
- Metric: CPU Percentage
- Time grain (aggregation): Average
- Operator: Greater than
- Threshold: $75\%$
- Action: Increase count by $2$

To ensure that the application scales in when load decreases but does not experience scale flapping, you need to configure the scale-in rule. Which of the following scale-in configurations should you use?

Metric: CPU Percentage; Time grain: Average; Operator: Less than; Threshold:

45\%

; Action: Decrease count by

2

Metric: CPU Percentage; Time grain: Average; Operator: Less than; Threshold:

55\%

; Action: Decrease count by

2

Metric: CPU Percentage; Time grain: Average; Operator: Less than; Threshold:

40\%

; Action: Decrease count by

3

Migrate the App Service plan to the Shared tier to automatically enable the built-in dynamic scaling feature.

Show answer & explanation

Answer: Metric: CPU Percentage; Time grain: Average; Operator: Less than; Threshold: $45\%$ ; Action: Decrease count by $2$

Answer

Configure the scale-in rule with CPU Percentage, Average time grain, Operator less than, Threshold of

45\%

, and Action to decrease the count by

2

The correct scale-in configuration uses a threshold of

45\%

and decreases the instance count by

2

. At the scale-out threshold of

75\%

CPU on

4

instances, the total workload load is

300\%

. After scaling out by

2

instances (total of

6

), the average CPU load becomes

300\% / 6 = 50\%

. Because the scale-in threshold is set to

45\%

, the rule will not trigger immediately. If the workload drops enough to trigger the scale-in rule (below

45\%

, which is less than

270\%

total workload), scaling in by

2

instances reduces the capacity back to

4

instances. The new average CPU load will be less than

270\% / 4 = 67.5\%

, which is safely below the

75\%

scale-out threshold, preventing flapping.

Step-by-Step Solution

Calculate the total workload capacity at the scale-out trigger point.

Total workload is

4 \text{ instances} \times 75\% = 300\% \text{ CPU capacity}

We must determine the total CPU resource load consumed just before scaling out.

Calculate the average CPU load per instance immediately after scaling out.

New average CPU is

300\% / (4 + 2) \text{ instances} = 50\%

This represents the target CPU load under the same workload. The scale-in threshold must be strictly below this value to prevent immediate scale-in.

Calculate the maximum safe CPU load when scaling back in from

6

4

instances.

The post-scale-in CPU must be less than the scale-out threshold (

75\%

). For

4

instances, total workload must be less than

4 \times 75\% = 300\%

. Across

6

instances, this corresponds to an average CPU of less than

300\% / 6 = 50\%

. A scale-in threshold of

45\%

(with a decrease of

2

) satisfies this condition.

We must verify that scaling back in does not instantly push the average CPU load back above the scale-out threshold, avoiding an infinite loop.

Key Concept

Configuring Azure Monitor autoscale rules to avoid flapping by aligning the scale-out and scale-in thresholds and step sizes.

Question 685Question →

You need to enable Microsoft Entra ID (formerly Azure Active Directory) authentication for the developer portal of an existing Azure API Management (APIM) instance. Which sequence of actions should you perform to complete the configuration? To answer, drag all actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Register the application in Microsoft Entra ID with the redirect URI, generate a client secret, navigate to the Identities blade in the API Management resource, add Microsoft Entra ID as an identity provider with the application details, and publish the Developer Portal.

To enable Microsoft Entra ID authentication for the developer portal, you must first register an application in Microsoft Entra ID to obtain the Client ID and set up a client secret. This allows secure integration between API Management and Entra ID. Next, you navigate to the Identities blade under the Developer portal section of the API Management instance in the Azure portal and configure the Microsoft Entra ID identity provider using the registered credentials. Finally, the developer portal must be published for the sign-in option to become active and visible to users.

Step-by-Step Solution

An application registration is created with a Redirect URI matching the developer portal's callback endpoint.

Microsoft Entra ID needs to know about the developer portal app to authenticate users and redirect them back securely.

Generate a client secret

A client secret value is generated for the registered application.

API Management requires a credential (client secret) to securely establish a trust relationship and communicate with Microsoft Entra ID.

Navigate to Identities in API Management

The Identities configuration panel for the developer portal is opened in the Azure portal.

This is the location where identity providers for the developer portal are managed.

Add and configure Microsoft Entra ID provider

The identity provider configuration is saved with the Client ID, Tenant ID, and Client Secret.

This registers Microsoft Entra ID as an active authentication option for developer portal users.

Publish the Developer Portal

The developer portal is rebuilt and redeployed to its hosting endpoint.

Developer portal customizations, including changes to identity providers, do not take effect for users until the portal is published.

Key Concept

Configuring identity providers and authentication for the Azure API Management developer portal.

Question 686Question →

You are developing a C# background service to process telemetry data from an Azure Event Hub. The service must use the EventProcessorClient to consume events, manage partition ownership, and store checkpoints in Azure Blob Storage.

What is the correct sequence of steps to initialize, run, and terminate the EventProcessorClient lifecycle?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: 1) Instantiate a BlobContainerClient pointing to the Azure Storage account container designated for checkpointing. 2) Instantiate the EventProcessorClient using the BlobContainerClient, consumer group, namespace connection string, and Event Hub name. 3) Register callback methods for the ProcessEventAsync and ProcessErrorAsync event handlers on the processor client. 4) Invoke the StartProcessingAsync method on the EventProcessorClient. 5) Invoke the StopProcessingAsync method on the EventProcessorClient when the application shuts down.

The lifecycle of the EventProcessorClient requires a storage container to coordinate work across multiple processor instances. Therefore, the BlobContainerClient must be instantiated first, followed by the EventProcessorClient itself. Before starting the processor client, you must register handlers for event and error processing. Once registered, StartProcessingAsync starts the ingestion and processing loop, and StopProcessingAsync stops it gracefully during application shutdown.

Step-by-Step Solution

Instantiate the BlobContainerClient.

A BlobContainerClient instance is ready, pointing to the designated checkpoint container.

The EventProcessorClient requires an active BlobContainerClient during its instantiation to coordinate partition ownership and checkpoints.

Instantiate the EventProcessorClient.

An EventProcessorClient instance is created with the necessary Storage and Event Hub configuration.

The client must be instantiated with credentials, consumer group name, and the BlobContainerClient before registration of handlers.

Event and error processing logic is linked to the client's event handlers.

The .NET SDK requires event and error handlers to be explicitly registered before processing starts to prevent runtime exceptions.

Invoke StartProcessingAsync.

The background thread begins execution, partition leases are acquired, and events start flowing.

This starts the consuming loop asynchronously in the background.

Invoke StopProcessingAsync.

The processor stops reading events and cleanly releases its storage lease blobs.

Gracefully stopping the client allows other processing instances to immediately assume ownership of the partitions without waiting for lease expirations.

Key Concept

EventProcessorClient Lifecycle and Azure Blob Storage Checkpointing in .NET SDK

Question 687Question →

A developer is configuring a multi-tenant web application named AppRegister in Microsoft Entra ID. The application must allow users from any organizational tenant to authenticate. However, the application must prevent users with personal Microsoft accounts (MSA) from signing in. Which two configurations should the developer implement to meet these requirements?

Select all that apply

Set the signInAudience parameter in the application manifest to AzureADMultipleOrgs.

Set the signInAudience parameter in the application manifest to AzureADandPersonalMicrosoftAccount.

Configure the application to direct authentication requests to the /organizations endpoint.

Configure the application to direct authentication requests to the /common endpoint.

Show answer & explanation

Answer: Set the signInAudience parameter in the application manifest to AzureADMultipleOrgs.; Configure the application to direct authentication requests to the /organizations endpoint.

Answer

Setting the signInAudience parameter in the application manifest to AzureADMultipleOrgs and directing authentication requests to the /organizations endpoint.

To configure a multi-tenant application that supports only work or school accounts from any organization and excludes personal Microsoft accounts, the signInAudience parameter in the application manifest must be set to AzureADMultipleOrgs. Additionally, the application must send authorization requests to the /organizations endpoint. The /common endpoint and the AzureADandPersonalMicrosoftAccount audience value would allow personal Microsoft accounts to authenticate, which violates the requirement.

Step-by-Step Solution

Identify the audience requirement for the application registration.

The application must allow any organization's tenant but exclude personal Microsoft accounts.

This filters out single-tenant settings and configurations that permit personal accounts.

Select the correct signInAudience value in the manifest.

AzureADMultipleOrgs must be selected.

AzureADMultipleOrgs supports multiple organizational tenants and explicitly excludes personal accounts, unlike AzureADandPersonalMicrosoftAccount.

Select the correct Microsoft Entra ID authorization endpoint.

The /organizations endpoint must be chosen.

The /organizations endpoint restricts login to work or school accounts, whereas the /common endpoint permits personal accounts.

Key Concept

Multi-tenant Applications Configuration

Question 688Question →

You are configuring an Azure API Management (APIM) instance to route traffic to a backend service that requires mutual TLS (mTLS) authentication. You upload the client certificate to the APIM instance. You need to ensure that APIM presents this client certificate when sending requests to the backend service. Which configuration should you apply to meet this requirement?

Add the authentication-certificate policy with the certificate thumbprint or ID to the inbound section of the API policy.

Add the authentication-certificate policy with the certificate thumbprint or ID to the outbound section of the API policy.

Add the authentication-certificate policy with the certificate thumbprint or ID to the on-error section of the API policy.

Grant the APIM system-assigned managed identity GET permissions in the Azure Key Vault access policy for secrets and certificates, and rely on default credential forwarding.

Show answer & explanation

Answer: Add the authentication-certificate policy with the certificate thumbprint or ID to the inbound section of the API policy.

Answer

Add the authentication-certificate policy with the certificate thumbprint or ID to the inbound section of the API policy.

The correct option is to apply the authentication-certificate policy in the inbound section. This instructs the gateway to use the specified client certificate when executing the outbound request to the backend service. Because the backend connection is initiated during or immediately after the inbound processing phase, policies affecting authentication to the backend must be declared in the inbound block.

Step-by-Step Solution

Upload the client certificate to the Certificates store of the Azure API Management instance.

The certificate is registered with APIM and assigned an identifier or thumbprint.

APIM must have the certificate in its store to present it during the TLS handshake.

Determine the correct policy to attach the client certificate to outbound backend calls.

The authentication-certificate policy is identified as the correct tool.

This policy explicitly configures client certificate credentials for backend authentication.

Insert the authentication-certificate policy into the inbound section of the policy XML configuration.

The certificate is attached to the request before it is sent to the backend.

Inbound policies run before the request is sent to the backend, enabling the gateway to establish the mTLS connection.

Key Concept

Configuring client certificate authentication for backends in Azure API Management

Estimated Time:1m 30s

Question 689Question →

You are configuring Azure API Management (APIM) to authenticate to a secure backend API using a user-assigned managed identity. You have already created the identity and associated it with the APIM instance. You add the authentication-managed-identity policy to the inbound processing section of the API. Which attribute must you include in the policy to identify the user-assigned managed identity?

resource

secret-identifier

client-id (or identity-id)

tenant-id

Show answer & explanation

Answer: client-id (or identity-id)

Answer

The correct attribute is client-id (or identity-id).

To authenticate to a backend API using a user-assigned managed identity, the authentication-managed-identity policy must include either the client-id or identity-id attribute. If these attributes are omitted, Azure API Management defaults to using the system-assigned managed identity.

Step-by-Step Solution

Analyze the authentication requirement.

A user-assigned managed identity must be used instead of the default system-assigned identity.

This is necessary when sharing a single identity across multiple resources or managing its lifecycle independently.

Examine the policy attributes for authentication-managed-identity.

The authentication-managed-identity policy has attributes like resource, client-id, and identity-id.

By default, omitting the client-id or identity-id will cause APIM to attempt to use the system-assigned managed identity.

Select the correct attribute to specify the user-assigned managed identity.

Adding the client-id (or identity-id) attribute resolves to the correct user-assigned identity.

This tells the APIM gateway which specific user-assigned identity's token to acquire.

Key Concept

Configuring user-assigned managed identity authentication in Azure API Management policies

Estimated Time:1m 0s

Question 690Question →

A developer is writing a service in C# that moves large backup files from a public container to a secure archival container in a different Azure Storage account using the Azure.Storage.Blobs SDK (version 12.x). The operation must execute asynchronously and log a message once the file transfer completes successfully. Place the steps in the correct order to programmatically copy the blob and monitor the progress of the copy operation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To perform an asynchronous copy operation and monitor it using the Azure.Storage.Blobs SDK, first instantiate the BlobContainerClient for the destination container. Second, retrieve the target BlobClient from that container. Third, call StartCopyFromUriAsync on the destination client with the source SAS URI. Fourth, call GetPropertiesAsync to fetch the current state. Finally, poll the CopyStatus in a loop until it is no longer Pending.

The correct sequence begins with initializing the container client, followed by getting the specific blob client. Next, the copy is triggered from the destination blob client pointing to the source URI. Finally, the status is monitored by fetching the destination blob properties and polling until the copy status leaves the pending state.

Step-by-Step Solution

Instantiate the BlobContainerClient.

Establishes connection capabilities to the target container.

You must have a container client reference to acquire a reference to a specific blob in that container.

Retrieve the destination BlobClient.

Provides a client reference for the specific blob to be created or overwritten by the copy operation.

Copy operations are initiated on the destination blob client directly.

Call StartCopyFromUriAsync using the source URI.

Triggers the asynchronous copy operation on the Azure side, returning a copy ID.

The destination blob must pull the data from the source URI using the Storage service copy engine.

Call GetPropertiesAsync on the destination client.

Populates the BlobProperties object containing the CopyStatus.

You need to retrieve the latest state from Azure to check if the operation has already completed or is still running.

Check the CopyStatus value and poll in a loop.

Ensures the application waits for the operation to resolve to Success, Failed, or Aborted.

Because copying is asynchronous, the copy status must be checked iteratively until it is no longer pending.

Key Concept

Using Azure.Storage.Blobs SDK to copy blobs asynchronously from a source URI and monitor the copy status.

Question 691Question →

You are configuring Azure Monitor autoscale rules for several Azure resources. Match each workload scaling requirement on the left to the most appropriate Azure Monitor autoscale metric and time aggregation configuration on the right.

Click a left item, then click its matching right item

Show answer & explanation

Answer

Match the queue-processing application with ActiveMessageCount (Maximum); match the memory-intensive microservice with MemoryPercentage (Average); match the web API thread exhaustion with HttpQueueLength (Average); and match the data-streaming service with Network Out (Total).

The correct pairings align each resource requirement with its target resource metric and the mathematically appropriate time aggregation. ActiveMessageCount (Maximum) reacts immediately to queue spikes; MemoryPercentage (Average) tracks memory usage stably; HttpQueueLength (Average) detects IIS/App Service request queuing; and Network Out (Total) measures the total volume of data transmitted over the monitoring window.

Step-by-Step Solution

Analyze the queue-processing requirement.

Since it processes messages from a queue and needs to scale out based on peak volume spikes, ActiveMessageCount with a Time Aggregation of Maximum is the correct configuration.

Maximum aggregation captures the peak value within the evaluation interval, ensuring the scale-out action is triggered immediately during a burst.

Analyze the memory-intensive microservice requirement.

For memory usage on App Service, the MemoryPercentage metric with an Average time aggregation is appropriate.

Average resource aggregation provides a stable indicator of overall memory consumption, avoiding premature scaling based on brief spikes.

Analyze the web API thread exhaustion scenario.

Thread pool exhaustion in an App Service results in requests waiting in the queue. The HttpQueueLength metric aggregated as Average is the correct match.

HttpQueueLength measures the queue of requests waiting to be handled, indicating that the existing instances cannot handle the concurrency load.

Analyze the data-streaming service requirement.

Data-streaming outbound volume is monitored using the Network Out metric with a Total time aggregation.

Total time aggregation measures the cumulative bytes sent over the time grain, which represents the total volume of network traffic.

Key Concept

Selecting correct metrics and time aggregation types for Azure Monitor autoscale rules.

Question 692Question →

A health monitoring system uses Azure Event Hubs to collect real-time patient telemetry. You are configuring a .NET host application to consume these events using the EventProcessorClient class. You create an Azure Blob Storage container to serve as the checkpoint store. The application is configured to authenticate using a system-assigned managed identity that has been granted the Storage Blob Data Reader role on the storage container. When the application starts, it throws an exception during initialization because it cannot acquire partition leases. You need to ensure the application can successfully coordinate partition ownership and write checkpoints. Which action should you perform?

Configure the application to use an Azure Queue Storage queue as the checkpoint store and grant the identity the Storage Queue Data Contributor role.

Grant the system-assigned managed identity the Storage Blob Data Contributor role on the storage container.

Reconfigure the application to use a user-assigned managed identity, as system-assigned managed identities cannot be authorized for lease operations.

Initialize a BlobLeaseClient in the application startup code to manually release any active partition leases before starting the event processor.

Show answer & explanation

Answer: Grant the system-assigned managed identity the Storage Blob Data Contributor role on the storage container.

Answer

Grant the system-assigned managed identity the Storage Blob Data Contributor role on the storage container.

The correct answer provides the necessary permissions for the EventProcessorClient to interact with the checkpoint store. Because the processor needs to create checkpoints and acquire/renew leases on partition ownership blobs, it requires read, write, and delete permissions on the container's blobs. The Storage Blob Data Contributor role grants these data plane permissions, resolving the authorization error.

Step-by-Step Solution

Identify the cause of the lease acquisition failure.

The EventProcessorClient relies on Azure Blob Storage to coordinate partition ownership (via blob leases) and track progress (via checkpoint blobs).

This establishes that the application must perform write, update, and delete actions on blobs in the storage container.

Evaluate the current Azure RBAC role assignments.

The system-assigned managed identity only has the Storage Blob Data Reader role, which permits reading but denies write and delete operations.

This explains why the client application throws an authorization exception when attempting to acquire or update partition ownership leases.

Determine the minimum required role that permits lease management.

The Storage Blob Data Contributor role provides full data-plane access to read, write, and delete blobs, fulfilling the minimum requirements of the EventProcessorClient.

Applying this role to the managed identity resolves the initialization exception while maintaining the principle of least privilege.

Key Concept

Azure Event Hubs EventProcessorClient storage requirements and Azure RBAC role configurations

Question 693Question →

You are securing an API hosted in Azure API Management (APIM). The API must validate a JSON Web Token (JWT) sent by clients in the Authorization header. Additionally, APIM must use its own system-assigned managed identity to authenticate against the secure backend service. You need to configure the APIM policy definition.

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

Select all that apply

Add the `validate-jwt` policy to the `<inbound>` section of the policy definition.

Add the `authentication-managed-identity` policy to the `<inbound>` section of the policy definition.

Add the `validate-jwt` policy to the `<outbound>` section of the policy definition.

Add the `authentication-managed-identity` policy to the `<outbound>` section of the policy definition.

Add the `authentication-managed-identity` policy to the `<inbound>` section and specify a user-assigned client ID.

Show answer & explanation

Answer: Add the `validate-jwt` policy to the `<inbound>` section of the policy definition.; Add the `authentication-managed-identity` policy to the `<inbound>` section of the policy definition.

Answer

Add the `validate-jwt` policy to the `<inbound>` section of the policy definition, and add the `authentication-managed-identity` policy to the `<inbound>` section of the policy definition.

To secure the API endpoints, the incoming token must be validated, and credentials for the backend must be attached before forwarding the request. The `validate-jwt` policy and the `authentication-managed-identity` policy must both be defined in the `<inbound>` section of the APIM policy. The system-assigned identity is used directly without specifying any client ID parameters.

Step-by-Step Solution

Determine where client request token validation should take place.

The token must be validated before forwarding the request to the backend. This requires the `validate-jwt` policy in the `<inbound>` section.

Inbound policies process the incoming client request before it is sent to the backend.

Determine how to configure backend authentication.

APIM must authenticate to the backend using its system-assigned managed identity, which is done using the `authentication-managed-identity` policy in the `<inbound>` section.

The backend authentication policy modifies the outbound request headers/context before it leaves the APIM gateway for the backend, which must be configured within the `<inbound>` section.

Key Concept

Azure API Management inbound policies for JWT validation and backend authentication using managed identities

Estimated Time:1m 0s

Question 694Question →

You are developing a background service in C# that uses the .NET Azure.Storage.Blobs SDK to migrate public assets to a secure container. You need to copy a blob named video.mp4 from a public source container to a destination container in your storage account. The copy operation must run asynchronously, and the service must monitor the progress until it is fully completed.

Arrange the steps in the correct order to perform the copy and monitor its status.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, instantiate the BlobServiceClient. Next, retrieve the destination BlobContainerClient and get a reference to the destination BlobClient. Then, call StartCopyFromUriAsync on the destination BlobClient using the source URI. Afterward, call GetPropertiesAsync to retrieve the initial status. Finally, poll the CopyStatus property in a loop until it is no longer pending.

The correct sequence begins with creating the client connection, accessing the destination container and blob references, initiating the copy from the source URI, and then polling the status properties until the operation is no longer pending.

Step-by-Step Solution

Instantiate the BlobServiceClient.

A service client is created to communicate with the target Azure Storage Account.

Establishing a service client is the prerequisite step for obtaining container and blob client references.

Retrieve references to the destination BlobContainerClient and BlobClient.

Client objects representing the destination container and the target blob are initialized.

You must obtain a reference to the specific target blob client to execute the copy method on it.

Call StartCopyFromUriAsync on the target BlobClient.

The asynchronous copy operation is initiated on the Azure Storage side.

This triggers the destination storage service to start copying data from the specified source URI.

Call GetPropertiesAsync on the target BlobClient.

The current metadata and state of the target blob are fetched.

The copy operation runs asynchronously on the server, so you must query the blob properties to find the status of the copy.

Poll the CopyStatus property in a loop.

The loop terminates once the copy status transitions to Succeeded, Failed, or Aborted.

This ensures the application waits until the background copy is fully resolved before performing subsequent logic.

Key Concept

Asynchronous blob copying and status monitoring using the .NET Azure.Storage.Blobs SDK

Question 695Question →

You are developing a C# utility to copy a blob named db-backup.bak from a source container to a destination container in a different Azure Storage account using the Azure.Storage.Blobs SDK. The source blob is private. The destination container already contains a blob named db-backup.bak that has an active lease. You need to initiate the copy asynchronously from the destination client and ensure the operation succeeds. Which configuration must you use for the copy operation?

Provide a source SAS token with Read (r) permission in the source URI, and specify the active lease ID in the DestinationConditions property of BlobCopyFromUriOptions.

Provide a source SAS token with Read (r) and Write (w) permissions in the source URI, and specify the active lease ID in the SourceConditions property of BlobCopyFromUriOptions.

Provide a source SAS token with Read (r) permission in the source URI, and include user-defined metadata in the copy options using headers that omit the x-ms-meta- prefix.

Provide a source SAS token with Write (w) permission in the source URI, and initiate the copy from the source BlobClient without supplying any destination conditions.

Show answer & explanation

Answer: Provide a source SAS token with Read (r) permission in the source URI, and specify the active lease ID in the DestinationConditions property of BlobCopyFromUriOptions.

Answer

Provide a source SAS token with Read (r) permission in the source URI, and specify the active lease ID in the DestinationConditions property of BlobCopyFromUriOptions.

The correct option correctly identifies that the source SAS token needs Read (r) permission because the copy engine must read the source blob. It also properly configures DestinationConditions with the active lease ID to allow overwriting the leased destination blob.

Step-by-Step Solution

Determine the source SAS token permissions.

The source blob is private and must be read by the destination service. Therefore, the source SAS token must contain at least Read (r) permission.

The copy process reads from the source URI, so read access is necessary and sufficient.

Address the active lease on the destination blob.

Since the destination blob is leased, writing to it requires passing the lease ID via the DestinationConditions property of BlobCopyFromUriOptions.

Setting the lease ID in the destination conditions authorizes the write operation on the leased blob.

Select the option that combines both configurations.

The option specifying Read permission for the source SAS and DestinationConditions for the destination lease ID is correct.

This configuration satisfies both authorization and lease requirements.

Key Concept

Asynchronous blob copying using Azure.Storage.Blobs SDK requires proper source SAS read permissions and destination lease conditions if the target blob is leased.

Question 696Question →

An organization is deploying an ASP.NET Core web application to an Azure App Service. The application must retrieve a database password from an Azure Key Vault named `kv-finance-prod`. The Key Vault's permission model is configured to use Azure role-based access control (Azure RBAC). The App Service has a system-assigned managed identity enabled.

During testing, the application's C# code throws a `RequestFailedException` with an HTTP `403 Forbidden` error when calling `SecretClient.GetSecretAsync`.

You need to resolve this authorization issue using the principle of least privilege.

Which of the following actions should you perform?

Create an access policy in `kv-finance-prod` that grants the Get secret permission to the App Service's system-assigned managed identity.

Assign the Key Vault Reader role to the App Service's system-assigned managed identity at the Key Vault scope.

Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.

Create a user-assigned managed identity, assign it the Key Vault Secrets User role at the Key Vault scope, and configure the App Service to use the system-assigned managed identity.

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.

Answer

Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.

Assigning the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope is the correct solution because it grants the identity the necessary data-plane permissions to read secret values, and it adheres to the principle of least privilege. Because the Key Vault is configured with the Azure RBAC permission model, Azure RBAC roles must be used instead of classic access policies.

Step-by-Step Solution

Identify the Key Vault permission model.

The Key Vault uses the Azure RBAC model, meaning vault access policies cannot be used to grant data-plane access.

Determines the correct authorization mechanism to configure.

Determine the required permission level.

The application needs to read secret values using `SecretClient.GetSecretAsync`.

Allows selecting a role that matches the required data action.

Select the least-privilege role and target identity.

Select the Key Vault Secrets User role and assign it to the App Service's system-assigned managed identity at the Key Vault scope.

Ensures the application has read-only access to secrets without administrative or metadata-only access.

Key Concept

Assigning appropriate Azure RBAC roles to managed identities for Key Vault secrets retrieval

Estimated Time:1m 30s

Question 697Question →

You are deploying a Java Spring Boot application to an Azure App Service (Linux). The application loads its configuration settings from an Azure App Configuration store using the Spring Cloud Azure App Configuration library. The App Configuration store contains a key named `/application/payment-gateway-key` configured as a Key Vault reference that points to a secret in an Azure Key Vault named `kv-payment-prod`. A system-assigned managed identity is enabled on the App Service. When the application starts, it throws an authorization exception while trying to resolve the Key Vault reference.

Which of the following configurations is required to successfully resolve the secret value at runtime?

Update the /application/payment-gateway-key key in the Azure App Configuration store to use the value @Microsoft.KeyVault(SecretUri=https://kv-payment-prod.vault.azure.net/secrets/GatewayKey) and set the content type to application/json.

Grant the App Service's system-assigned managed identity the App Configuration Data Reader role on the Azure App Configuration store, and grant the Azure App Configuration instance the Key Vault Secrets User role on the Azure Key Vault.

Grant the App Service's system-assigned managed identity the App Configuration Data Reader role on the Azure App Configuration store, and grant the same identity the Key Vault Secrets User role on the Azure Key Vault.

Enable a user-assigned managed identity on the Azure App Configuration store, grant it the Key Vault Administrator role, and associate that user-assigned identity with the App Service.

Show answer & explanation

Answer: Grant the App Service's system-assigned managed identity the App Configuration Data Reader role on the Azure App Configuration store, and grant the same identity the Key Vault Secrets User role on the Azure Key Vault.

Answer

The correct configuration requires granting the App Service's system-assigned managed identity the App Configuration Data Reader role on the App Configuration store and the Key Vault Secrets User role on the Key Vault.

The correct answer is the configuration where the App Service's system-assigned managed identity is granted App Configuration Data Reader on the App Configuration store and Key Vault Secrets User on the Key Vault. The client application provider library loads the Key Vault reference metadata (specifically the URI) from the App Configuration store and then connects directly to the Key Vault to resolve the secret value using its own managed identity. Thus, the App Service identity needs read access to both resources.

Step-by-Step Solution

Enable a system-assigned managed identity on the Azure App Service host.

An identity is created in Microsoft Entra ID representing the App Service instance.

This identity will be used to authenticate requests to both Azure App Configuration and Azure Key Vault.

Grant the App Service's managed identity the App Configuration Data Reader role on the App Configuration store.

The application can authenticate and retrieve configuration key-values, including the Key Vault reference metadata.

The application needs access to read configuration keys before it can resolve references.

Grant the App Service's managed identity the Key Vault Secrets User role on the Azure Key Vault.

The application can retrieve the secret payload directly from the Key Vault.

Key Vault references are resolved on the client side; the application identity, not the App Configuration store, must have permission to access the secret.

Key Concept

Azure App Configuration Key Vault Reference Resolution Process

Question 698Question →

An organization runs a web application on an Azure App Service plan that currently has a capacity of $2$ instances. You need to configure autoscale rules with a minimum of $2$ instances and a maximum of $10$ instances. You configure a scale-out rule to increase the instance count by $1$ when the Average CPU percentage is greater than $75\%$ . You want to configure a scale-in rule that decreases the instance count by $1$ when the CPU percentage is lower than a specific threshold. Which configuration should you use to prevent flapping when scaling out from $2$ to $3$ instances?

Set the scale-in threshold to CPU percentage less than

45\%

using the Average metric aggregation

Set the scale-in threshold to CPU percentage less than

55\%

using the Average metric aggregation

Set the scale-in threshold to CPU percentage less than

70\%

using the Maximum metric aggregation

Set the scale-in threshold to CPU percentage less than

45\%

and downgrade the App Service plan to the Basic tier

Show answer & explanation

Answer: Set the scale-in threshold to CPU percentage less than $45\%$ using the Average metric aggregation

Answer

Set the scale-in threshold to CPU percentage less than

45\%

using the Average metric aggregation.

The correct option sets the scale-in threshold to

45\%

with the Average aggregation. At the point of scaling out from

2

3

instances, the average CPU percentage is just above

75\%

, representing a total load of

150\%

. Upon adding a third instance, the average CPU per instance drops to

50\%

(

150\% / 3

). Setting the scale-in threshold below

50\%

(such as

45\%

) ensures the scale-in rule is not immediately triggered, thereby preventing flapping.

Step-by-Step Solution

Calculate the total CPU percentage load at the scale-out threshold.

Total CPU workload is

150\%

To determine the aggregate workload required to trigger the scale-out rule.

Calculate the post-scale-out average CPU percentage per instance.

New average CPU percentage per instance is

50\%

To find the target CPU utilization immediately after the scale-out action completes.

Determine the maximum scale-in threshold to avoid flapping.

The threshold must be less than

50\%

, so

45\%

with Average metric aggregation is the correct configuration.

If the scale-in threshold were

50\%

or higher, the newly scaled scale set would immediately trigger a scale-in rule, causing a flapping loop.

Key Concept

Prevention of flapping in autoscale rules by ensuring the scale-in threshold is set sufficiently lower than the post-scaling-out average metric utilization.

Question 699Question →

An organization is configuring a custom domain for a web application. You need to create an SSL/TLS certificate in Azure Key Vault by using a non-integrated Certificate Authority (CA). Which sequence of steps should you perform to complete this process? To answer, drag the appropriate actions from the list of actions to the answer area and arrange them in the correct sequence.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: First, create a certificate in Azure Key Vault with the policy set to use a non-integrated CA (Issuer Name set to Unknown). Second, download the Certificate Signing Request (CSR) file from the pending certificate. Third, submit the CSR to your external Certificate Authority (CA) and download the signed certificate. Finally, merge the signed certificate into the pending certificate request in Azure Key Vault.

To create a certificate in Azure Key Vault using a non-integrated CA, you must first initiate the request in Key Vault by setting the issuer to Unknown. This generates a private key and a CSR within Key Vault. Next, you download the CSR to submit it to the external CA. Once the CA issues the signed certificate, you merge it back into the pending request to pair it with the private key.

Step-by-Step Solution

Create the certificate with the issuer set to Unknown.

Azure Key Vault generates a key pair and a CSR, and sets the certificate status to pending.

This is the initial step required to generate the CSR within Key Vault's secure boundary.

Retrieve the CSR from the pending certificate.

The CSR file (.csr or PEM format) is downloaded.

The CSR contains the public key and identity information that must be signed by the external CA.

Submit the CSR to the CA and retrieve the signed certificate.

A signed public certificate (.cer or .crt file) is obtained from the CA.

The external CA validates ownership and issues the signed certificate.

Merge the signed certificate in Azure Key Vault.

The pending certificate status changes to active, associating the private key with the signed certificate.

This finalizes the certificate creation process inside the Key Vault.

Key Concept

Azure Key Vault Certificate Lifecycle Management with Non-Integrated CA

Question 700Question →

You are designing a secure backend service that provides external audit applications with temporary access to read audit logs stored in a specific Azure Blob Storage container. You decide to generate a Shared Access Signature (SAS) token.

The solution must meet the following security requirements:
- Minimize the risk of compromising the storage account's root access keys.
- Prevent the external application from listing other blobs or deleting logs.
- Enforce secure transmission protocols.
- Restrict access to a specific external IP range: 198.51.100.0/24.

Which two of the following configuration options should you implement to meet the requirements?

Select all that apply

Generate a User Delegation SAS using a Microsoft Entra ID user principal or managed identity that has the Storage Blob Data Reader role on the container.

Set the SAS protocol constraint to HTTPS only and restrict the allowed IP range to 198.51.100.0/24.

Generate an Account SAS signed with the primary storage account key, granting Read, Write, and List permissions.

Generate a Service SAS and retrieve the storage account access key from Azure Key Vault using a managed identity without configuring Key Vault access policies.

Show answer & explanation

Answer: Generate a User Delegation SAS using a Microsoft Entra ID user principal or managed identity that has the Storage Blob Data Reader role on the container.; Set the SAS protocol constraint to HTTPS only and restrict the allowed IP range to 198.51.100.0/24.

Answer

The correct options are generating a User Delegation SAS using a Microsoft Entra ID principal with the Storage Blob Data Reader role, and setting the protocol to HTTPS only with the specified IP range restriction.

Generating a User Delegation SAS secured by Microsoft Entra ID prevents exposure of the storage account key. Restricting the SAS to HTTPS only and scoping the IP address range ensures encrypted data transmission and boundaries to the client's network.

Step-by-Step Solution

Determine the authentication mechanism that avoids exposing primary or secondary storage account keys.

Identify that User Delegation SAS, which is secured by Microsoft Entra ID credentials, meets the key protection requirement.

Using Account or Service SAS relies on access keys, which introduces security risks if exposed.

Select the appropriate RBAC role and scope for the identity generating the User Delegation SAS.

Assign Storage Blob Data Reader to the generating identity at the container level.

This restricts the generated SAS token to read-only permissions on a specific container, following the least privilege principle.

Configure the network and transport constraints on the SAS token builder.

Enforce HTTPS protocol and restrict the allowed IP range to the auditor's IP block (198.51.100.0/24).

Enforcing HTTPS secures the channel, and IP restriction limits access origin, reinforcing the perimeter defense.

Key Concept

Shared Access Signatures and Token-based Storage Security

PreviousPage 35 / 49Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept