Examkin

All practice questions

972 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 541Question →

You need to update a specific metadata tag on an existing Azure Blob Storage blob using the Azure.Storage.Blobs SDK (v12) for C# while ensuring that all other existing metadata key-value pairs on the blob are preserved. Which sequence of steps should you perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To update a specific metadata key on a blob while preserving existing metadata using the Azure.Storage.Blobs SDK (v12) for C#, you must first instantiate a BlobClient, call GetPropertiesAsync() to retrieve the current Metadata dictionary, modify or add the key-value pairs in memory, and then call SetMetadataAsync() with the updated dictionary.
The correct order requires first initializing the BlobClient to communicate with the service, then calling GetPropertiesAsync() to fetch the existing metadata so it is not lost. Next, the metadata dictionary is modified in memory, and finally, SetMetadataAsync() is called to upload the entire updated dictionary.

Step-by-Step Solution

1
Instantiate BlobClient
A client object targeting the specific blob is created.
All SDK operations on the blob require a configured client instance.
2
Call GetPropertiesAsync()
The current blob properties, including the existing metadata dictionary, are retrieved.
Since the SDK's metadata update operation is a full overwrite, you must retrieve existing values first to avoid losing them.
3
Modify the metadata dictionary
The target key-value pairs are added or updated in the dictionary in memory.
Modifying the dictionary in memory prepares the complete payload for the update. Keys do not need the HTTP prefix.
4
Call SetMetadataAsync()
The updated metadata dictionary is sent to Azure Storage and applied to the blob.
This persists the updated collection of metadata on the blob.

Key Concept

Preserving metadata during updates with Azure.Storage.Blobs SDK
Question 542Question →

You are configuring a Standard availability test in Azure Application Insights to monitor a public web application. You need to ensure the test fails if the page load takes longer than a specified duration or if the home page does not contain the word "Welcome".

Which two settings under the Success criteria section of the availability test configuration should you configure? (Select two.)

Select all that apply

Show answer & explanation

Answer: Content match; Test timeout

Answer

The correct options are Content match and Test timeout.
Content match allows verifying that specific text (such as 'Welcome') is present in the response body, and Test timeout defines the threshold for response delay before a failure is recorded. Both are located in the Success criteria section.

Step-by-Step Solution

1
Identify the success requirements from the scenario.
The test needs to fail on response delay (timeout) and missing response content (contains 'Welcome').
This determines which test settings are relevant to verify availability.
2
Locate the corresponding settings under the Success criteria section of the Standard test configuration.
Content match enables response body string validation, and Test timeout defines the maximum response delay.
These success parameters directly govern the pass/fail result based on timing and response content.

Key Concept

Configuring success criteria parameters such as timeout and content matching in Application Insights Standard web tests.
Question 543Question →

You have a private Azure Blob Storage account named `storeorigin` containing static web assets in a container named `images`. You deploy an Azure CDN Standard from Microsoft endpoint to deliver these assets. You must configure the solution so that the CDN endpoint can retrieve the assets using a Shared Access Signature (SAS) token, while ensuring clients can access the assets using clean URLs that do not expose the SAS token. Which sequence of actions should you perform?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure Azure CDN with a private Blob Storage origin, you must first generate a SAS token for the storage container. Next, modify the CDN endpoint's Origin path to append the container name and the SAS token. Follow this by setting the query string caching behavior to ignore query strings, which allows clients to bypass sending the token. Finally, purge the CDN endpoint to apply the changes.
The correct sequence begins with securing origin access by generating a SAS token for the private container. This token must then be configured on the CDN side via the Origin path so that the CDN can authenticate requests to the backend. To hide the SAS token from the end users, the query string caching policy is set to ignore query strings, ensuring that clean client URLs are cached and mapped to the backend requests that include the Origin path token. A cache purge is the final step to make the configuration immediately effective.

Step-by-Step Solution

1
Generate a SAS token for the container.
A SAS token is created that authorizes read access to the private blob assets.
The CDN needs authentication to access private blob storage.
2
Configure the CDN endpoint Origin path.
The Origin path is configured as '/{container_name}?{sas_token}'.
This automatically appends the SAS credentials to all origin requests initiated by the CDN.
3
Configure query string caching to 'Ignore query strings'.
The CDN caches files based on the file path alone and does not pass client query strings to the origin.
This allows clients to request files using clean URLs without containing the SAS token.
4
Purge the CDN cache.
The cached content is invalidated on all edge nodes.
Ensures that old, unauthenticated request errors or outdated cache results are removed.

Key Concept

Integrating Azure CDN with private storage origins using Shared Access Signature (SAS) tokens and query string caching behavior configurations.
Question 544Question →

An enterprise order processing application sends custom metric telemetry to Azure Application Insights to monitor message queue sizes. A custom metric named 'QueueBacklog' is recorded, and the specific queue's identifier is stored inside a custom dimension named 'QueueName'.

You need to write a Kusto Query Language (KQL) query to find the maximum backlog value for each queue over the last 36 hours. To ensure optimal query performance, you must filter by time range before performing any other operations.

How should you complete the KQL query?

Fill in the blanks below

kusto

| where timestamp > ago(36h) and name == "QueueBacklog"
| extend QueueName = (customDimensions.QueueName)
| summarize MaxBacklog = (value) by QueueName
Show answer & explanation

Answer

To complete the query, query the 'customMetrics' table first to load custom metric telemetry, then use the 'tostring' function to cast the dynamic custom dimension property to a string, and finally use the 'max' aggregation function to find the maximum backlog value.
The query starts by targeting the 'customMetrics' telemetry table. To ensure optimization, the time-range filter is applied immediately using the 'where' clause, which restricts processing to the last 36 hours. The dynamic property 'customDimensions.QueueName' is cast to a string type using the 'tostring' function. Finally, the 'max' aggregation function calculates the highest backlog value recorded in the 'value' column, grouping the results by the queue name.

Step-by-Step Solution

1
Select the correct table for custom metrics telemetry.
The query starts with the 'customMetrics' table name.
Application Insights stores custom metrics recorded via the TrackMetric API inside the 'customMetrics' table.
2
Cast the custom dimension to a string format.
Apply the 'tostring' function to 'customDimensions.QueueName'.
Properties in the 'customDimensions' property bag are dynamic objects. To group by them in KQL summarization, they must be cast to string types using 'tostring()'.
3
Aggregate the maximum metric value.
Use the 'max' aggregation function on the 'value' column.
The 'max' function calculates the highest value recorded for the 'value' field in the 'customMetrics' table across the specified time frame.

Key Concept

Querying custom metrics and dimensions in Application Insights using optimized KQL filters and aggregations.
Estimated Time:2m 0s
Question 545Question →

You are developing a backend service in C# using MSAL.NET that runs on an Azure App Service. The App Service has a user-assigned managed identity configured with the Client ID `d29d3368-8f83-4a25-97a1-872f23cf9e3c`. The service must securely access an Azure Key Vault without storing any secrets or certificates in the application configuration. Which two configuration steps should you implement in the C# code? (Select two.)

Select all that apply

Show answer & explanation

Answer: Initialize the managed identity application by calling `ManagedIdentityApplicationBuilder.Create(ManagedIdentityId.WithUserAssignedClientId("d29d3368-8f83-4a25-97a1-872f23cf9e3c")).Build()`; Acquire the token by calling `app.AcquireTokenForManagedIdentity("https://vault.azure.net/.default").ExecuteAsync()` on the initialized application instance

Answer

Initialize the managed identity application by calling ManagedIdentityApplicationBuilder.Create(ManagedIdentityId.WithUserAssignedClientId("d29d3368-8f83-4a25-97a1-872f23cf9e3c")).Build(), and acquire the token by calling app.AcquireTokenForManagedIdentity("https://vault.azure.net/.default").ExecuteAsync() on the initialized application instance.
To authenticate using a user-assigned managed identity via MSAL.NET, you must initialize the application using ManagedIdentityApplicationBuilder with ManagedIdentityId.WithUserAssignedClientId to specify the client ID. Once configured, you must call AcquireTokenForManagedIdentity on the application instance to acquire a token for the Azure Key Vault resource scope.

Step-by-Step Solution

1
Determine the identity type and configure the application builder
Identify that the application uses a user-assigned managed identity requiring its Client ID. Initialize the application using ManagedIdentityApplicationBuilder.Create(ManagedIdentityId.WithUserAssignedClientId(...)).Build().
ManagedIdentityApplicationBuilder is the specific class in MSAL.NET designed to acquire tokens for managed identities without client secrets or certificates.
2
Request the access token for the target Azure service
Call the AcquireTokenForManagedIdentity method on the initialized application instance, passing the default scope for Azure Key Vault (https://vault.azure.net/.default), and execute it asynchronously.
AcquireTokenForManagedIdentity is the correct MSAL.NET method for retrieving tokens from the local managed identity endpoint for a given resource.

Key Concept

Configuring MSAL.NET to acquire tokens using a user-assigned managed identity with its Client ID.
Question 546Question →

An organization has a web application that provides temporary write access to an Azure Blob Storage container named `uploads` for external clients. You must meet the following requirements:
- Enable the security team to revoke access tokens immediately without impacting other clients or rotating the storage account keys.
- Limit the lifetime of individual client tokens to a maximum of 30 minutes.
- Enforce the use of secure connections only.

Which two actions should you perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Create a stored access policy on the container and specify the policy identifier when generating a service-level SAS token.; Set the allowed protocols on the stored access policy or the generated SAS token to HTTPS only.

Answer

Create a stored access policy on the container and specify the policy identifier when generating a service-level SAS token, and set the allowed protocols on the stored access policy or the generated SAS token to HTTPS only.
The correct actions are to create a stored access policy on the container and reference it when generating a service-level SAS, and to enforce HTTPS only on the policy or token. A stored access policy allows for immediate revocation of the associated SAS tokens by modifying or deleting the policy. Restricting the protocol to HTTPS ensures all transit is encrypted.

Step-by-Step Solution

1
Analyze the requirement for immediate token revocation without rotating the storage account keys.
Identify that a stored access policy on the container is required because deleting or modifying the policy immediately revokes any associated service-level SAS tokens.
This satisfies the revocation requirement without impacting other clients or requiring a key rotation.
2
Analyze the requirement for secure connections.
Configure the SAS token or stored access policy to enforce HTTPS only.
This blocks any unencrypted HTTP requests from clients.
3
Evaluate the options against account-level and user-delegated SAS tokens.
Recognize that account-level SAS tokens and SAS tokens signed with Microsoft Entra ID (user delegation) do not support stored access policies.
This rules out the incorrect configurations.

Key Concept

Implementing container-level stored access policies to manage and revoke Service Shared Access Signatures (SAS) with protocol constraints.
Question 547Question →

You are configuring an Azure CDN endpoint to serve static images for an online catalog. The images are updated infrequently, but users append query parameters such as version numbers (e.g., image.png?v=1.2) to the URLs. You want to ensure that the CDN serves the cached image regardless of any query strings provided in the request to maximize the cache hit ratio and reduce traffic to the origin.

Which query string caching behavior should you configure for the CDN endpoint?

Show answer & explanation

Answer: Ignore query strings

Answer

Ignore query strings
The setting that ignores query strings is correct. Under this behavior, the first request is cached, and all subsequent requests with different query strings (such as version numbers) are served from the cache, maximizing the cache hit ratio and minimizing origin requests.

Step-by-Step Solution

1
Analyze the business requirement.
The goal is to serve cached images from the CDN regardless of any query parameters appended to the URL (such as version numbers) in order to optimize the cache hit ratio.
Since the static images are the same regardless of query parameters, we want the CDN to treat all variations of the URL as the same cached asset.
2
Evaluate Azure CDN query string caching settings.
The three caching settings are: 'Ignore query strings' (caches the first request and ignores subsequent query parameters), 'Bypass caching' (sends all query-string requests to the origin without caching), and 'Cache every unique URL' (caches each query string variation separately).
We must match the target behavior to one of the supported caching configurations.
3
Select the behavior that ignores query string changes.
The 'Ignore query strings' behavior is selected because it serves the same cached asset for any query string parameters, fulfilling the requirement.
This configuration directly aligns with the goal of serving the cached asset ignoring parameters.

Key Concept

Azure CDN Query String Caching Behavior
Estimated Time:45s
Question 548Question →

You are configuring telemetry for a C# application using the Application Insights SDK. You instantiate and initialize the telemetry client, but notice that no telemetry data is transmitted to Azure Monitor. You confirm that there are no runtime exceptions, compile errors, or network blockages.

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

Show answer & explanation

Answer: The connection string was not configured on the telemetry configuration object.

Answer

The connection string was not configured on the telemetry configuration object.
The correct option is correct because the Application Insights SDK requires a valid connection string to locate the ingestion endpoint and authenticate the payload. When the connection string is missing or empty, the SDK does not throw exceptions but silently fails to send any telemetry data.

Step-by-Step Solution

1
Inspect the application code or configuration files to locate the Application Insights SDK initialization logic.
Identify how the telemetry configuration is being created or loaded.
This confirms whether a connection string is actively being passed to the SDK.
2
Verify if the ApplicationInsights:ConnectionString setting is present in appsettings.json or if the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable is populated.
Confirm that the value is missing, empty, or not being bound correctly to the configuration object.
Application Insights requires the connection string to determine the ingestion endpoint and authentication parameters.
3
Set the connection string in the configuration or pass it directly to the configuration initialization method.
The SDK successfully connects to the ingestion service and telemetry starts appearing in the Azure portal.
Providing a valid connection string resolves the configuration gap and enables telemetry transmission.

Key Concept

Configuring Application Insights connection string to enable telemetry ingestion
Question 549Question →

You are building a C# application to process events from an Azure Event Hub. The application needs to dynamically distribute partitions among multiple running instances of the consumer and checkpoint progress using Azure Blob Storage. Which class from the Azure.Messaging.EventHubs.Processor SDK library should you use as the main client to implement this consumer?

Show answer & explanation

Answer: EventProcessorClient

Answer

Use the EventProcessorClient class from the Azure.Messaging.EventHubs.Processor library.
The EventProcessorClient class is the standard class in the Azure.Messaging.EventHubs.Processor library. It connects to an Event Hub, reads events, balances partitions dynamically among other active consumer instances, and checkpoints read positions using an Azure Blob Storage container.

Step-by-Step Solution

1
Analyze the consumer requirements.
The application requires automatic partition load balancing across multiple instances and checkpoint storage.
This is a typical scalable consumer pattern for Azure Event Hubs.
2
Identify the standard SDK library class for this scenario.
The EventProcessorClient class is designed specifically to read events, manage partition ownership via blob leases, and write checkpoints.
It acts as the primary orchestrator for distributed partition consumption.

Key Concept

Azure Event Hubs consumer implementation with EventProcessorClient
Question 550Question →

You are developing an integration solution that uses Azure Event Grid to route custom events to a Webhook endpoint. To secure the webhook, you must implement Microsoft Entra ID authentication so that the Webhook only accepts authorized requests from Event Grid. You need to configure the authentication and the subscription.

Which sequence of steps should you perform to complete the configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps is: Register a new application in Microsoft Entra ID to represent the webhook endpoint, define an application role within the registered webhook application, grant the Azure Event Grid Service Principal the defined application role on the webhook application, and finally create the Event Grid subscription, specifying the webhook endpoint and configuring the Microsoft Entra ID authentication details.
To secure an Event Grid Webhook using Microsoft Entra ID, you must register the Webhook application first to establish its identity. Next, you define an application role inside the registration. You then grant the Azure Event Grid Service Principal this role. Finally, you create the subscription using the Webhook's Entra ID application details. This order ensures that the validation handshake succeeds because Event Grid is already authorized to call the endpoint.

Step-by-Step Solution

1
Register the webhook application in Microsoft Entra ID.
An application registration is created with a unique Application (Client) ID.
This establishes the identity of the webhook endpoint in the Microsoft Entra ID tenant.
2
Expose an application role in the webhook application registration.
An authorized role (e.g., AzureEventGridSecureWebhookSubscriber) is defined.
The role must exist before it can be assigned to the caller service principal.
3
Assign the defined application role to the Azure Event Grid Service Principal.
Event Grid is granted permission to call the secure webhook endpoint.
The service must have permission to call the endpoint to complete the upcoming validation handshake.
4
Create the Event Grid subscription with Entra ID endpoint authentication properties.
The event subscription is created, and the validation handshake completes successfully.
This is the final step where Event Grid validates the webhook endpoint using the authorized identity context.

Key Concept

Microsoft Entra ID secured webhook endpoints in Azure Event Grid
Question 551Question →

You are developing a C# service that processes real-time bids for an online auction platform using the Azure Cosmos DB .NET SDK v3. The target container uses `/auctionId` as the partition key. To ensure data consistency, when a new bid is placed, you must atomically create a new bid item of type `Bid` and replace the existing auction summary item of type `AuctionSummary` within the same partition.

Which two of the following code segments must you use to successfully initialize and execute the transactional batch?

Select all that apply

Show answer & explanation

Answer: TransactionalBatch batch = container.CreateTransactionalBatch(new PartitionKey(auctionId));; using TransactionalBatchResponse response = await batch.ExecuteAsync();

Answer

Initialize the transactional batch using the container instance and the specific partition key, then execute the batch asynchronously using the ExecuteAsync method on the batch object.
To create and run a transaction using the Cosmos DB .NET SDK v3, you must first call CreateTransactionalBatch on the Container instance, passing the logical partition key (PartitionKey). Then, after adding the operations (such as CreateItem and ReplaceItem) to the batch, you execute the batch by calling the ExecuteAsync method directly on the TransactionalBatch object.

Step-by-Step Solution

1
Obtain a reference to the container and call CreateTransactionalBatch.
Create a TransactionalBatch object scoped to the target partition key.
Azure Cosmos DB transactional batches require all operations to reside in the same logical partition, so the partition key must be specified during batch initialization.
2
Add operations to the batch using methods like CreateItem and ReplaceItem.
Queue the operations to be executed atomically.
Operations are chained or added to the batch object prior to execution.
3
Execute the batch by calling ExecuteAsync on the TransactionalBatch instance.
Commit the transaction and receive a TransactionalBatchResponse.
The transaction is executed atomically in a single request to the Cosmos DB service.

Key Concept

Executing atomic transactions within a single logical partition in Azure Cosmos DB using the .NET SDK v3 TransactionalBatch.
Question 552Question →

You are developing a C# web application that runs on an Azure App Service. The application must retrieve database connection secrets from an Azure Key Vault. You have already enabled a system-assigned managed identity for the App Service.

You write the following code to access the Key Vault:

csharp
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;

// ...
var client = new SecretClient(new Uri("https://myvault.vault.azure.net/"), new DefaultAzureCredential());
var secret = await client.GetSecretAsync("DbConnectionString");

When you deploy and run the application in Azure, it fails to retrieve the secret and throws an exception indicating that access is forbidden.

Which of the following actions should you perform to resolve this error?

Show answer & explanation

Answer: Create an access policy in Azure Key Vault that grants the Get secret permission to the system-assigned managed identity of the App Service.

Answer

Create an access policy in Azure Key Vault that grants the Get secret permission to the system-assigned managed identity of the App Service.
The correct answer is to create an access policy in Azure Key Vault that grants the Get secret permission to the system-assigned managed identity of the App Service. When the system-assigned managed identity is enabled, Azure automatically creates an enterprise application principal representing the App Service instance. DefaultAzureCredential automatically detects this identity when deployed to Azure and uses it to acquire tokens. However, the identity must be authorized to perform data plane operations on the Key Vault by defining an access policy or an RBAC role assignment.

Step-by-Step Solution

1
Analyze the error context
The application successfully attempts to authenticate using the system-assigned managed identity, but receives a forbidden response.
This indicates that authentication succeeded, but authorization to access the Key Vault secrets is missing.
2
Configure the Key Vault access policy
Create a new Key Vault access policy matching the system-assigned managed identity's object principal ID, assigning the 'Get' permission under Secret Permissions.
The system-assigned managed identity is a service principal in Microsoft Entra ID and must be granted explicit permissions on the Key Vault data plane.
3
Verify DefaultAzureCredential behavior
No code changes are required because DefaultAzureCredential automatically searches for and utilizes the system-assigned managed identity in the App Service environment.
Ensuring code changes are minimized simplifies deployment and maintenance.

Key Concept

Azure Managed Identities and Azure Key Vault Authorization
Estimated Time:1m 30s
Question 553Question →

You are configuring an Azure CDN endpoint to distribute responses from a weather forecast API. The API serves localized forecast data based on geographic coordinates passed as query string parameters, such as `/forecast?lat=40.7128&lon=-74.0060`. You need to ensure that the CDN endpoint caches unique forecast data for each distinct coordinate combination while maximizing cache efficiency for the rest of the application. Which query string caching behavior should you select?

Show answer & explanation

Answer: Cache every unique URL

Answer

Cache every unique URL
Selecting the caching behavior that treats each unique URL as a separate asset ensures that coordinate-specific forecasts are correctly cached and served. This maintains caching benefits while preserving the localized functionality of the weather API.

Step-by-Step Solution

1
Analyze the application requirements.
The application relies on query string parameters (`lat` and `lon`) to serve localized data, meaning each unique coordinate set must yield a separate cached response.
To determine how the CDN should process requests with query parameters without serving incorrect or stale data.
2
Evaluate the caching options available in Azure CDN for query strings.
The main options are: Bypass caching (does not cache requests with query strings), Ignore query strings (caches the first request and serves it to all subsequent query string variants), and Cache every unique URL (caches each query string combination separately).
To align the candidate options with the standard configuration settings of Azure CDN.
3
Select the behavior that caches coordinates separately.
'Cache every unique URL' matches the requirement because it creates a unique cache entry for each query string combination.
This configuration satisfies the need to cache localized forecast data for each coordinate combination while still leveraging the CDN cache.

Key Concept

Azure CDN Query String Caching Behaviors
Question 554Question →

You are setting up monitoring for an Azure App Service web app. You create an Azure Monitor metric alert rule to detect when the HTTP Server Errors count exceeds a specified threshold. You need to ensure that an email notification is automatically sent to the operations team when the alert fires. Which Azure Monitor component must you configure to define the email notification recipient and delivery channel?

Show answer & explanation

Answer: An Action Group

Answer

An Action Group
The correct option is the Action Group. In Azure Monitor, alert rules are separated from the actions they trigger. Alert rules specify the conditions (like a metric exceeding a threshold), while Action Groups define the receiver list (such as email addresses, SMS, or webhooks) and actions to execute when the alert state changes.

Step-by-Step Solution

1
Identify the requirement to send a notification when an alert fires.
Recognize that alert rules only detect conditions, but do not natively contain recipient lists or notification logic.
Alert logic is decoupled from alert action delivery in Azure Monitor.
2
Select the component responsible for orchestration of alert actions.
Identify that Azure Monitor Action Groups are the resource type designed to hold lists of actions and notification channels.
Action Groups allow you to reuse notification setups (like emailing a specific team) across multiple alerts.

Key Concept

Azure Monitor Action Groups define the notification preferences and action channels (such as Email, SMS, Push, Voice, Webhooks, or Automation Runbooks) associated with an alert rule.
Estimated Time:45s
Question 555Question →

You are developing a Single Page Application (SPA) named SalesPortal and a backend Web API named SalesAPI. You register both applications in Microsoft Entra ID. SalesPortal runs in the user's web browser and must call SalesAPI to retrieve the signed-in user's sales data. You need to configure the applications to ensure SalesPortal can access SalesAPI on behalf of the signed-in user while adhering to the principle of least privilege. Which action should you perform to configure the required permissions?

Show answer & explanation

Answer: In the SalesAPI registration, expose an API scope named Sales.Read. In the SalesPortal registration, request a Delegated permission for the SalesAPI Sales.Read scope.

Answer

In the SalesAPI registration, expose an API scope named Sales.Read. In the SalesPortal registration, request a Delegated permission for the SalesAPI Sales.Read scope.
To allow a Single Page Application (SPA) to access a custom Web API on behalf of a signed-in user, you must expose an API scope on the API's app registration (such as Sales.Read) and request it as a delegated permission on the client application registration. This ensures the app operates under the user's security context and permissions.

Step-by-Step Solution

1
Identify the application architecture and authentication flow requirements.
The application is a browser-based SPA calling a backend API, which requires the OAuth 2.0 authorization code flow with PKCE and delegated permissions (acting on behalf of the user).
Understanding the flow dictates that delegated permissions rather than application permissions or managed identities are required.
2
Expose a custom scope on the API application registration.
The SalesAPI registration exposes a scope such as Sales.Read, defining what permissions the client application can request.
Before a client application can request a delegated permission, the API must declare the available scopes in Entra ID.
3
Request the exposed scope as a delegated permission on the client application registration.
The SalesPortal registration requests the SalesAPI's Sales.Read delegated scope, allowing users to consent to this permission.
This links the client's request to the API's exposed capability, fulfilling the security configuration.

Key Concept

Delegated permissions and scopes in Microsoft Entra ID are used when an application needs to access resources on behalf of a signed-in user.
Question 556Question →

You need to download the diagnostic log files from a Windows-based Azure App Service named `contoso-web` by using the Kudu REST API. You want to retrieve all log files compiled into a single compressed ZIP file.

Arrange the actions in the correct order to configure the request, authenticate, and download the logs.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Retrieve the deployment credentials, construct the SCM endpoint URL targeting the zip API, execute the authenticated HTTP GET request, and extract the downloaded ZIP file.
To download logs using the Kudu API, you must first obtain valid publishing credentials to satisfy authentication requirements. Then, you construct the endpoint URL using the app's SCM site name and the `/api/zip/LogFiles/` directory path. Next, you send the authenticated GET request to receive the compressed log archive. Finally, you extract the ZIP locally to view the logs.

Step-by-Step Solution

1
Obtain the deployment credentials from the Azure portal or CLI.
You have the publishing username and password required for Kudu authentication.
The Kudu REST API endpoint is secured and requires authentication.
2
Formulate the URL using the format: `https://contoso-web.scm.azurewebsites.net/api/zip/LogFiles/`.
You have the target URL pointing to the LogFiles zip API.
The SCM endpoint is separate from the production site and hosts the Kudu service tools.
3
Make an HTTP GET request to the URL using the publishing credentials in the Authorization header.
The server returns a binary stream representing the zipped LogFiles directory.
This initiates the download process from the Azure server.
4
Save the binary stream to a local file and extract its contents.
You have access to files like web server logs, application logs, and detailed errors locally.
Extracting the ZIP is required to read the text-based log files directly.

Key Concept

Accessing App Service diagnostic logs via the Kudu (SCM) REST API zip endpoint.
Question 557Question →

You are developing a C# application using the .NET SDK Azure.Messaging.EventHubs to send telemetry data to an Azure Event Hub. You need to write the code to send a batch of events efficiently and reliably. Which two actions must you perform to create and publish the event batch using the SDK? (Select TWO).

Select all that apply

Show answer & explanation

Answer: Create an EventDataBatch object by calling CreateBatchAsync on the EventHubProducerClient instance.; Add events to the batch using the TryAdd method, and then transmit the batch by calling SendAsync.

Answer

To publish a batch of events to an Azure Event Hub using the modern .NET SDK, you must create an EventDataBatch instance by calling CreateBatchAsync on the EventHubProducerClient, append events to it using the TryAdd method to ensure they do not exceed size constraints, and then send the completed batch using SendAsync.
Publishing events in batches using the .NET SDK requires calling CreateBatchAsync on an EventHubProducerClient to manage the size constraints. Individual events are added via TryAdd, and the completed batch is sent to the Event Hub using SendAsync.

Step-by-Step Solution

1
Instantiate an EventHubProducerClient and call CreateBatchAsync.
An EventDataBatch object is created, which is pre-configured with the maximum size allowed for a single transmission based on the Event Hub service limits.
This guarantees that the payload being assembled will not exceed the maximum allowed message size.
2
Call TryAdd on the EventDataBatch object for each EventData payload to be sent.
Events are successfully added to the batch if they fit within the size limit. The method returns false if the event is too large to fit in the current batch.
This provides client-side validation of message size limits, preventing runtime failures during transmission.
3
Pass the EventDataBatch to the SendAsync method of the EventHubProducerClient.
The batch of events is sent to the Azure Event Hub over the wire.
This sends all buffered events in a single network transaction, maximizing performance and efficiency.

Key Concept

Batch publishing pattern with EventHubProducerClient in the Azure.Messaging.EventHubs SDK
Question 558Question →

You are developing a Python application that uses the `azure-storage-blob` SDK (v12). You write the following code to upload a blob and assign custom metadata:

python
from azure.storage.blob import BlobServiceClient

service_client = BlobServiceClient.from_connection_string(connection_string)
blob_client = service_client.get_blob_client(container="reports", blob="annual_report.pdf")

blob_client.upload_blob(data=pdf_data, metadata={"ProjectName": "Delta"}, overwrite=True)

Later, you need to read this metadata value from the blob. Which code segment should you use to retrieve the value of the `ProjectName` metadata?

Show answer & explanation

Answer: python
properties = blob_client.get_blob_properties()
project_name = properties.metadata.get("projectname")

Answer

Retrieve the blob properties and access the metadata dictionary using the lowercase key 'projectname' without any 'x-ms-meta-' prefix.
The correct option retrieves the metadata using the key in lowercase ('projectname'). This is because the Azure Storage SDK for Python normalizes all metadata keys to lowercase and strips the 'x-ms-meta-' prefix.

Step-by-Step Solution

1
Call `blob_client.get_blob_properties()`.
A `BlobProperties` object is returned containing the blob metadata, properties, and system-defined attributes.
This SDK call is required to pull the latest properties and metadata of the blob from the Azure Storage service.
2
Access the `metadata` dictionary on the returned properties object.
A Python dictionary containing the parsed user-defined metadata.
User-defined metadata is stored in the `metadata` property of the `BlobProperties` instance.
3
Use the lowercase key `'projectname'` to look up the value.
The metadata value `'Delta'` is successfully returned.
The Azure Storage SDK for Python strips the HTTP prefix `'x-ms-meta-'` and normalizes all dictionary keys to lowercase.

Key Concept

Azure Blob metadata keys are case-insensitive HTTP headers under the hood; the Python SDK handles this by stripping the 'x-ms-meta-' prefix and exposing all keys in lowercase.
Question 559Question →

A university course enrollment system uses an Azure Service Bus queue to process student registration requests. You are developing a C# console application that retrieves these requests. The application must guarantee that if the console application crashes during processing, the registration request is not lost and remains on the queue to be reprocessed by another instance. Which approach should you implement?

Show answer & explanation

Answer: Create a ServiceBusReceiver using ServiceBusReceiveMode.PeekLock and call CompleteMessageAsync after successfully processing the registration.

Answer

Create a ServiceBusReceiver using ServiceBusReceiveMode.PeekLock and call CompleteMessageAsync after successfully processing the registration.
Using the PeekLock receive mode ensures that the message is locked on the server side during processing but remains on the queue. If the application finishes processing successfully, it calls CompleteMessageAsync to delete the message. If the application crashes, the lock will expire, making the message available for other instances to process.

Step-by-Step Solution

1
Select the correct Service Bus receive mode that preserves the message in case of worker failure.
Using ServiceBusReceiveMode.PeekLock preserves the message on the server and locks it, preventing other workers from receiving it temporarily.
PeekLock ensures the message is not lost if the processing node fails.
2
Ensure the application explicitly signals completion of the message.
Invoke CompleteMessageAsync after processing is complete.
This removes the message from the queue after successful processing, ensuring it is not processed again.

Key Concept

Azure Service Bus receive modes (PeekLock vs ReceiveAndDelete)
Question 560Question →

You are configuring inbound request processing rules for an API in Azure API Management (APIM). You need to allow cross-origin resource sharing (CORS) and limit the rate of incoming calls based on the client IP address.

Which two of the following configurations must you perform to implement these policies? (Select two.)

Select all that apply

Show answer & explanation

Answer: Place the cors policy within the inbound section of the policy document.; Place the rate-limit-by-key policy within the inbound section of the policy document.

Answer

Configure both the cors policy and the rate-limit-by-key policy within the inbound section of the policy document.
Both cross-origin resource sharing (CORS) rules and client-side rate limiting are request-filtering and protection mechanisms. To be effective and functional, they must be processed on incoming requests before the API Management gateway contacts the backend service. Therefore, both policies must be placed in the inbound section of the policy document.

Step-by-Step Solution

1
Identify the phase of execution for CORS validation.
CORS validation must occur when a request arrives, before forwarding it to the backend.
This determines that the cors policy belongs in the inbound section.
2
Identify the phase of execution for rate limiting.
Rate limiting protects the backend by throttling incoming requests before they are sent to the backend.
This determines that the rate-limit-by-key policy belongs in the inbound section.

Key Concept

API Management policies are structured into sections (inbound, backend, outbound, on-error) based on when the policy should execute. Pre-processing policies like CORS and rate limiting must be placed in the inbound section.
PreviousPage 28 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin