Examkin

All practice questions

972 questions

All types972Multiple choice497Multiple select269Matching9Ordering171Fill in the blank26
Question 601Question →

You are building a microservices gateway using an Azure API Management (APIM) instance. You need to restrict access to one of the microservices by filtering incoming traffic based on the sender's IP address. In which policy section of the API's policy XML definition must you place the ip-filter policy?

Show answer & explanation

Answer: <inbound>

Answer

The <inbound> policy section
The correct answer is the <inbound> section. In Azure API Management, the policy execution pipeline is divided into four main sections: inbound, backend, outbound, and on-error. The <inbound> section is executed immediately when a request is received from a client, before it is sent to the backend. Since the goal of IP filtering is to prevent unauthorized clients from reaching the backend API, placing the ip-filter policy within the <inbound> block is correct and ensures security at the entry point.

Step-by-Step Solution

1
Analyze the security requirement to filter incoming API traffic based on the client's IP address using the ip-filter policy.
Identify that the security filter must block unauthorized requests before they consume backend resources or hit the backend microservice.
Security boundaries should evaluate and reject traffic at the earliest possible stage in the request lifecycle.
2
Evaluate the execution flow of the Azure API Management policy pipeline (inbound, backend, outbound, on-error).
Determine that the inbound phase is the only phase that runs before forwarding the request to the backend microservice.
Inbound policies process the incoming client request, backend policies control backend routing/forwarding, outbound policies modify the backend response, and on-error policies handle exceptions.
3
Map the inbound phase to the corresponding policy XML element name.
Place the ip-filter policy inside the <inbound> tag of the APIM policy document.
Syntactically and logically, IP filtering belongs inside the <inbound> processing block.

Key Concept

Azure API Management policy execution pipeline structure
Question 602Question →

You are implementing Azure Monitor alerts and notifications for an Azure App Service web application. You need to configure a Log Search alert rule to detect failed dependency calls in Application Insights. When the alert fires, it must execute a custom workflow using an Azure Logic App. Which two configurations should you implement?

Select all that apply

Show answer & explanation

Answer: Configure the alert rule to use an Action Group that includes a Logic App receiver.; Include a time-range filter in the KQL query, such as `where timestamp > ago(5m)`, to scope the Log Search alert rule.

Answer

Configure the alert rule to use an Action Group that includes a Logic App receiver, and include a time-range filter in the KQL query, such as `where timestamp > ago(5m)`, to scope the Log Search alert rule.
To execute a custom workflow using an Azure Logic App when an alert is triggered, you must configure the alert rule with an Action Group that contains a Logic App receiver. Additionally, Log Search alert rules in Azure Monitor require a KQL query that includes a time-range filter (such as `where timestamp > ago(5m)`) to scope the query and prevent scanning the entire history of telemetry data, which ensures optimal performance and prevents execution limits from being exceeded.

Step-by-Step Solution

1
Analyze the requirements for executing a custom workflow in response to Azure Monitor alerts.
Identify that an Azure Monitor Action Group must be configured with a Logic App receiver.
Action Groups support direct integration with Logic Apps to orchestrate custom workflows.
2
Determine how to query Application Insights telemetry for log search alert rules efficiently.
Ensure that the KQL query specifies a time filter (e.g., `where timestamp > ago(5m)`).
Omitting a time filter causes the query to scan the entire log history, leading to performance degradation and query execution limit errors.

Key Concept

Azure Monitor Log Search Alerts and Action Group Receivers
Question 603Question →

You are developing a C# backend service that manages user profiles in a multi-tenant SaaS application. User profile items are stored in an Azure Cosmos DB container with the partition key path `/tenantId`. The Azure Cosmos DB account is configured to use Session consistency.

A user updates their profile through one instance of the service, which returns a session token. A separate service instance must immediately read this updated profile. To guarantee read-your-writes consistency across the separate service instances with the lowest latency and RU cost, you must perform a point read using the Cosmos DB .NET SDK v3.

Which C# code snippet should you use?

Show answer & explanation

Answer: csharp
ItemRequestOptions options = new ItemRequestOptions { SessionToken = sessionToken };
ItemResponse<UserProfile> response = await container.ReadItemAsync<UserProfile>(
id: "user-99",
partitionKey: new PartitionKey("tenant-abc"),
requestOptions: options
);

Answer

The correct code snippet performs a point read using ReadItemAsync, passes the tenant ID as a PartitionKey object, and includes the session token within ItemRequestOptions.
The correct snippet uses ReadItemAsync to perform a point read (the lowest latency and cost operation for single item retrieval). By passing the partition key as new PartitionKey("tenant-abc") and setting the SessionToken property in ItemRequestOptions, it successfully guarantees read-your-writes consistency across separate service instances.

Step-by-Step Solution

1
Select the correct SDK method for a low-cost, low-latency single item retrieval.
ReadItemAsync is selected over GetItemQueryIterator because point reads are faster and cost fewer RUs (1 RU for items <= 1KB).
Point reads are the most efficient read operations in Azure Cosmos DB.
2
Ensure the partition key parameter is supplied correctly using the Cosmos DB .NET SDK v3 types.
Use 'new PartitionKey("tenant-abc")' as the partitionKey parameter.
Item operations in SDK v3 require a PartitionKey struct parameter containing the partition key value of the targeted document.
3
Configure the session token to maintain read-your-writes consistency across different client sessions.
Instantiate ItemRequestOptions, set the SessionToken property, and pass it as the requestOptions parameter.
Session consistency guarantees read-your-writes only within the same client session unless the session token is explicitly shared and passed to separate clients.

Key Concept

Performing point reads with session tokens using the Azure Cosmos DB .NET SDK v3 to guarantee read-your-writes consistency across clients.
Estimated Time:1m 30s
Question 604Question →

You are developing a solution that routes resource group lifecycle events to an Azure Storage Queue. The storage account is secured, and public access is restricted. You need to configure Azure Event Grid to deliver these events securely using a user-assigned managed identity. Which sequence of steps should you perform to complete the configuration? To answer, arrange all actions from the list of actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure secure Event Grid delivery to an Azure Storage Queue using a user-assigned managed identity, you must first create the identity, associate it with the Event Grid system topic, grant it the Storage Queue Data Message Sender role on the queue, and then create the event subscription specifying the queue endpoint and the identity for delivery.
First, the user-assigned managed identity must be created in Microsoft Entra ID. Next, this identity must be associated with the Event Grid system topic so that the topic can leverage it. Then, the identity must be granted the Storage Queue Data Message Sender role at the scope of the target storage queue to allow message writing. Finally, the event subscription can be created, referencing the target queue as the endpoint and using the user-assigned managed identity for delivery.

Step-by-Step Solution

1
Create the user-assigned managed identity
A standalone user-assigned managed identity resource is created in Microsoft Entra ID.
The identity must exist before it can be assigned permissions or associated with other Azure resources.
2
Associate with system topic
The Event Grid system topic is configured with the user-assigned managed identity.
Azure Event Grid requires the identity to be associated with the topic from which the event subscription is created.
3
Assign RBAC role
The identity is granted the Storage Queue Data Message Sender role on the target queue.
Event Grid must have authorization to write to the queue, and the minimum privilege role for this action is Storage Queue Data Message Sender.
4
Create the subscription
The event subscription is created and successfully validated.
During creation, Event Grid validates that the endpoint is reachable and that the configured identity has the necessary permissions to write to it.

Key Concept

Configuring managed identities for Event Grid delivery
Question 605Question →

A developer is troubleshooting an application startup issue on a Linux-based Azure App Service named finance-app in the resource group finance-rg. The container starts but immediately exits. The developer wants to view the startup logs in real-time from the Azure CLI. They execute the command: az webapp log tail --name finance-app --resource-group finance-rg. However, the command output remains empty and does not display any container startup messages. What must the developer do first to resolve this issue and view the startup logs?

Show answer & explanation

Answer: Enable Docker container logging to the filesystem by running the command: az webapp log config --name finance-app --resource-group finance-rg --docker-container-logging filesystem

Answer

Enable Docker container logging to the filesystem by running the command: az webapp log config --name finance-app --resource-group finance-rg --docker-container-logging filesystem
On a Linux-based Azure App Service, application logs (STDOUT/STDERR) are captured via Docker container logging. This is disabled by default. Running 'az webapp log config' with '--docker-container-logging filesystem' enables the collection of these logs to the local filesystem, which allows the 'az webapp log tail' command to successfully stream the log output in real-time.

Step-by-Step Solution

1
Identify why the log tail output is empty on the Linux-based App Service.
By default, Docker container stdout and stderr logging are disabled on Linux-based Azure App Services, which prevents log streaming from displaying any startup output.
Understanding the default logging state of Linux App Services is key to troubleshooting empty log streams.
2
Select the correct Azure CLI command to configure Docker container logging.
The command 'az webapp log config' with the '--docker-container-logging filesystem' parameter must be used.
This parameter configures the App Service host to write container output streams to the filesystem so they can be captured by the streaming engine.
3
Run the log streaming command to capture the active log stream.
Executing 'az webapp log tail' displays the live logs as the container attempts to start.
Once logging is enabled, the tail command can successfully attach to the active log file stream.

Key Concept

Enabling Docker container logging to filesystem for Linux Azure App Services to stream container logs via CLI.
Question 606Question →

A company hosts a web application on an Azure App Service plan that currently runs on 22 instances. You configure an autoscale rule to add 11 instance (scale out) when the average CPU Percentage exceeds 75%75\%. If the CPU load is evenly distributed, the CPU percentage per instance drops to 50%50\% immediately after scaling out to 33 instances. To prevent autoscale flapping, which configuration should you apply for the scale-in rule?

Show answer & explanation

Answer: Set the scale-in threshold to 40%40\% CPU Percentage.

Answer

Set the scale-in threshold to 40%40\% CPU Percentage.
Setting the scale-in threshold to 40%40\% CPU Percentage prevents flapping. Since the CPU percentage drops to 50%50\% immediately after scaling out to 33 instances, the scale-in threshold must be lower than 50%50\% (e.g., 40%40\%) so that the newly added instance is not immediately removed.

Step-by-Step Solution

1
Determine the CPU level immediately after the scale-out event.
The CPU level drops to 50%50\% per instance when a third instance is added.
To analyze when the scale-in rule might trigger relative to the scale-out outcome.
2
Compare the potential scale-in thresholds with the post-scale-out CPU level.
A scale-in threshold of 40%40\% is below 50%50\%, whereas 60%60\% and 80%80\% are above 50%50\%.
If the scale-in threshold is higher than or equal to the post-scale-out level, the system will immediately scale back in.
3
Select the threshold that ensures the system does not immediately trigger scale-in.
The 40%40\% threshold prevents immediate scale-in.
This avoids flapping by ensuring a buffer exists between the post-scale-out state and the scale-in trigger.

Key Concept

Autoscale flapping occurs when a scale action causes the metric to cross the threshold for the opposite scale action, triggering a continuous cycle of scaling up and down.
Question 607Question →

You are deploying a C# Azure Functions application that is integrated with Application Insights. You need to enable both Application Insights Profiler to identify execution hot paths, and Snapshot Debugger to capture debug snapshots when unhandled exceptions occur. Developers must be able to view the performance traces and download the debug snapshots from the Azure portal.

Which of the following actions should you perform? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the Azure Functions application to run on an Elastic Premium plan or a Dedicated App Service plan (Basic or higher).; Assign the Application Insights Snapshot Debugger role to the developers' Microsoft Entra ID accounts.

Answer

To configure Application Insights Profiler and Snapshot Debugger for Azure Functions, you must host the application on an Elastic Premium plan or a Dedicated App Service plan (Basic or higher). Additionally, developers require the Application Insights Snapshot Debugger role to download or view the generated snapshots.
The correct configurations involve running the Azure Functions application on a Premium or Dedicated App Service plan because the Consumption hosting plan does not support Profiler and Snapshot Debugger. Additionally, developers must be assigned the Application Insights Snapshot Debugger role to download and view the debug snapshots.

Step-by-Step Solution

1
Determine hosting plan compatibility for Azure Functions monitoring tools.
Identify that the default Consumption plan does not support either Application Insights Profiler or Snapshot Debugger, requiring a scale-up to Elastic Premium or a Dedicated App Service plan.
Profiler and Snapshot Debugger require dedicated compute resources or premium scaling capabilities to capture memory dumps and execution traces without causing performance issues.
2
Determine the necessary Azure Role-Based Access Control (RBAC) role for accessing snapshot data.
Identify that snapshot data contains sensitive in-memory information, which is protected and requires the specific Application Insights Snapshot Debugger role.
Standard roles like Reader or Monitoring Contributor do not grant the required permissions to decrypt or download snapshot files.

Key Concept

Azure Functions hosting plan requirements for advanced diagnostics and RBAC roles for Snapshot Debugger.
Question 608Question →

You are developing a native mobile application named FleetApp that allows delivery drivers to view their own calendar events from Microsoft Graph and upload telemetry data to a custom backend web API named RouteAPI. You register RouteAPI in Microsoft Entra ID and expose a custom scope named Telemetry.Write.

You register FleetApp in Microsoft Entra ID. The application must perform all actions on behalf of the signed-in driver, allow drivers to consent to permissions themselves, and adhere to the principle of least privilege.

Which permissions should you configure for the FleetApp registration?

Show answer & explanation

Answer: Delegated permission Calendars.Read for Microsoft Graph, and Delegated permission Telemetry.Write for RouteAPI

Answer

Delegated permission Calendars.Read for Microsoft Graph, and Delegated permission Telemetry.Write for RouteAPI
The correct configuration uses Delegated permissions for both APIs because the mobile application acts on behalf of a signed-in user (the driver). By selecting Calendars.Read instead of Calendars.Read.All, the application adheres to the principle of least privilege and allows the drivers to consent to the permissions themselves, as directory-level read permissions are not required.

Step-by-Step Solution

1
Analyze the client application context and user presence requirement.
The application runs on a mobile device and must perform actions using the identity of a signed-in user (the driver) and allow self-consent.
This determines that Delegated permissions (which run in the context of a signed-in user) must be used instead of Application permissions (which run as a daemon or background service without a user).
2
Evaluate the required scope level for Microsoft Graph access under the principle of least privilege.
The driver only needs to view their own calendar events, so the Calendars.Read permission is sufficient.
Using Calendars.Read.All would allow access to all users' calendars, which requires admin consent and violates the principle of least privilege.
3
Select the correct permission type and scope for the custom backend API.
FleetApp needs delegated permission for the custom scope Telemetry.Write exposed by RouteAPI.
Since the write operation is initiated by the signed-in driver, the driver must delegate their authority to the client application using a delegated permission.

Key Concept

Delegated vs. Application permissions and least-privilege scoping in Microsoft Entra ID app registrations.
Estimated Time:1m 30s
Question 609Question →

An Azure integration workflow must modify the metadata of a blob while preventing write conflicts. Using the .NET SDK (`Azure.Storage.Blobs`), write operations to the blob must be temporarily locked.

Order the steps required to programmatically lock the blob, apply the metadata changes, and release the lock.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins by instantiating a lease client using GetBlobLeaseClient, followed by acquiring the lease using AcquireAsync. Next, SetMetadataAsync is invoked on the BlobClient with the acquired lease ID supplied within BlobRequestConditions, and finally, the lease is freed by calling ReleaseAsync on the lease client.
To modify a blob safely under a concurrency lock, a client must first obtain a BlobLeaseClient to coordinate lease actions. Second, the lease must be explicitly acquired to retrieve the lease ID. Third, the metadata update is committed using the lease ID inside BlobRequestConditions. Finally, the lease must be released to clean up the lock and make the blob available to other clients.

Step-by-Step Solution

1
Instantiate the lease client.
A BlobLeaseClient object bound to the target BlobClient is created.
The Azure SDK structures lease operations under a specialized lease client rather than the main blob client.
2
Acquire the lease.
The blob is locked for write operations, and a unique lease ID is returned.
Acquiring the lease establishes the lock and generates the identifier required for subsequent modifications.
3
Apply the metadata with the lease ID.
The metadata is successfully updated on the blob.
Passing the lease ID in BlobRequestConditions ensures the write operation is permitted on the leased blob.
4
Release the lease.
The lease lock is removed, returning the blob to an unlocked state.
Releasing the lease promptly allows other processes to interact with the blob without waiting for the lease duration to expire.

Key Concept

Acquiring, using, and releasing a lease during blob metadata modifications to prevent concurrency issues using the Azure Storage SDK.
Question 610Question →

You are configuring a new Azure Container App named shipping-tracker to host a containerized microservice. The container image is stored in a private Azure Container Registry (ACR) named shippingregistry.azurecr.io. You need to configure the Container App to securely pull the image from the registry without enabling the ACR admin user or using static credentials.

Which configuration should you apply to meet these requirements?

Show answer & explanation

Answer: Assign a user-assigned managed identity to the Container App, grant that identity the AcrPull role on the Azure Container Registry, and configure the Container App's registry settings to reference the user-assigned identity.

Answer

The correct configuration is to assign a user-assigned managed identity to the Container App, grant that identity the AcrPull role on the Azure Container Registry, and configure the Container App's registry settings to reference the user-assigned identity.
To securely pull an image from a private Azure Container Registry without using admin credentials, you must use a user-assigned managed identity. The identity is granted the AcrPull role on the registry, and its resource ID is referenced in the container app's registry configuration. This allows the Container App to authenticate and pull the image during provisioning.

Step-by-Step Solution

1
Create or identify a user-assigned managed identity in Azure.
A user-assigned managed identity resource is created with a unique resource ID.
Azure Container Apps requires a pre-existing user-assigned managed identity to authenticate container pulls from private registries before the Container App is fully deployed.
2
Assign the AcrPull role to the user-assigned managed identity at the Azure Container Registry scope.
The identity is granted read-only permission to pull container images from the registry.
This conforms to the principle of least privilege while providing the necessary permissions to retrieve the container image.
3
Configure the Container App registry settings with the registry server name and the resource ID of the user-assigned managed identity.
The Container App is configured to use the managed identity for authentication when pulling the image.
This establishes the secure link between the Container App and the registry, allowing successful deployment of the container.

Key Concept

Configuring Azure Container App registry authentication using user-assigned managed identities for secure image pulls from a private Azure Container Registry.
Question 611Question →

You are deploying a Node.js microservice to an Azure Kubernetes Service (AKS) cluster. The microservice uses a user-assigned managed identity named `mi-node-app` via workload identity.

The microservice must load configuration settings from an Azure App Configuration store named `appconfig-prod`. The store contains several configurations, including Key Vault references pointing to database credentials in an Azure Key Vault named `kv-prod`.

You need to configure the minimum required role assignments to allow the microservice to successfully fetch all configurations and resolve the Key Vault references.

Which two actions should you perform? Select two.

Select all that apply

Show answer & explanation

Answer: Assign the App Configuration Data Reader role on `appconfig-prod` to the `mi-node-app` user-assigned managed identity.; Assign the Key Vault Secrets User role on `kv-prod` to the `mi-node-app` user-assigned managed identity.

Answer

Assign the App Configuration Data Reader role on `appconfig-prod` to the `mi-node-app` user-assigned managed identity, and assign the Key Vault Secrets User role on `kv-prod` to the `mi-node-app` user-assigned managed identity.
The microservice's user-assigned managed identity (`mi-node-app`) needs direct read access to the App Configuration store to retrieve configuration key-values and Key Vault reference metadata. It also needs direct access to the Key Vault because Key Vault references are resolved on the client side by the application's SDK.

Step-by-Step Solution

1
Identify the identity used by the microservice.
The microservice authenticates using the workload identity associated with the `mi-node-app` user-assigned managed identity.
Permissions must be granted to the specific identity used by the workload running in the AKS cluster.
2
Assign the necessary role to read configuration metadata.
Grant the App Configuration Data Reader role on `appconfig-prod` to `mi-node-app`.
This allows the application SDK to fetch the keys and the Key Vault reference metadata from Azure App Configuration.
3
Assign the necessary role to resolve Key Vault secrets.
Grant the Key Vault Secrets User role on `kv-prod` to `mi-node-app`.
Key Vault references are resolved client-side by the application's client library, requiring direct read access to the secrets in Key Vault.

Key Concept

Key Vault references in Azure App Configuration are resolved client-side by the application, requiring the application's identity to have read permissions on both the App Configuration store and the target Key Vault.
Question 612Question →

An online food delivery application uses Azure Service Bus queues to process customer orders. You are developing a C# application using the Azure.Messaging.ServiceBus SDK to receive and process these order messages. You need to ensure that the messages are processed reliably: they must not be deleted from the queue until processing succeeds, and they must be returned to the queue if the processing application crashes or fails. Which two configurations or actions should you implement to achieve this? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the receive mode to ServiceBusReceiveMode.PeekLock.; Call CompleteMessageAsync on the receiver or processor after the message is successfully processed.

Answer

To ensure reliable processing, configure the receive mode to PeekLock and explicitly call CompleteMessageAsync on the receiver or processor after successful execution.
Reliable processing requires PeekLock mode so that the message is locked during execution. If processing succeeds, the application calls CompleteMessageAsync to finalize the process and delete the message. If the application crashes, the lock expires and the message becomes available again on the queue.

Step-by-Step Solution

1
Set the receive mode configuration.
Using PeekLock mode locks the message for processing without immediately deleting it.
This prevents other clients from receiving the message while processing is in progress, and keeps it safe on the queue.
2
Invoke completion after successful processing.
Calling CompleteMessageAsync deletes the message from the queue.
This signals to the Service Bus that processing completed successfully, allowing the message to be safely removed.

Key Concept

Reliable message receiving modes in Azure Service Bus
Question 613Question →

You are configuring a connection to a custom backend API from an Azure API Management (APIM) instance. The backend API is hosted on-premises and secured using a TLS/SSL certificate signed by a private internal Certificate Authority (CA) that is not publicly trusted. When APIM attempts to forward requests to the backend API, the connection fails with an HTTP 500 error due to a TLS handshake failure. You need to resolve the error and ensure that APIM can establish a secure TLS connection to the backend API while maintaining strict TLS validation. Which of the following actions should you perform?

Show answer & explanation

Answer: Upload the public root CA certificate to the Certificates section of the API Management instance.

Answer

Upload the public root CA certificate to the Certificates section of the API Management instance.
Uploading the public root CA certificate of the private Certificate Authority to the Certificates section of the API Management instance allows the gateway to build the trust chain and validate the backend certificate. This resolves the TLS handshake failure while maintaining strict validation.

Step-by-Step Solution

1
Obtain the public root CA certificate (typically in .cer format) of the private internal Certificate Authority that signed the backend API's TLS certificate.
The public root CA certificate is prepared for import.
API Management needs this certificate to construct and verify the trust chain of the backend server's certificate.
2
In the Azure Portal, navigate to the API Management instance, select Certificates under the Security section, and upload the certificate to the CA certificates tab.
The private CA is added to the trusted store of the API Management instance.
This establishes trust at the API Management infrastructure level, enabling successful TLS handshakes with any backend server whose certificate is signed by this CA.

Key Concept

Configuring trusted CA certificates in Azure API Management to secure backend communication.
Question 614Question →

You are developing a .NET application using the Azure Cosmos DB .NET SDK v3. The application must process changes from a source container using the Change Feed Processor and send real-time notifications. You need to configure and start the Change Feed Processor. How should you sequence the steps to initialize, configure, and start the Change Feed Processor?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To initialize the Change Feed Processor using the .NET SDK v3, you must first define the delegate that will handle the changes, retrieve the Container references for the monitored and lease containers, invoke GetChangeFeedProcessorBuilder on the monitored container, configure the builder with the lease container and instance name, and finally build and start the processor asynchronously.
The correct sequence begins by defining the change processing delegate and acquiring the required Container SDK instances. You then initialize the builder using the source container, configure the leases and host identity using fluent methods on the builder, and complete the process by invoking Build and starting the processor.

Step-by-Step Solution

1
Define the delegate.
The delegate that processes document changes is declared.
The delegate is a required parameter for the builder factory method.
2
Get container references.
Container objects for both source and lease containers are obtained.
The monitored container starts the builder, and the lease container is passed during configuration.
3
Initialize the builder.
A ChangeFeedProcessorBuilder instance is created.
Calling GetChangeFeedProcessorBuilder on the source container begins the builder pattern.
4
Configure parameters.
The builder is configured with lease and instance parameters.
The Change Feed Processor requires a lease container to track state and an instance name to scale out across hosts.
5
Build and start the processor.
The ChangeFeedProcessor is instantiated and starts listening.
Build creates the processor object, and StartAsync begins reading notifications.

Key Concept

The initialization sequence of the Azure Cosmos DB Change Feed Processor requires setting up dependencies (delegate, containers) before configuring the builder and starting the background reader.
Question 615Question →

You are configuring Application Insights telemetry for a C# .NET 8 console application. The application retrieves its configuration from an Azure App Configuration instance, which includes the Application Insights configuration. You write the following code to initialize telemetry:

csharp
var config = TelemetryConfiguration.CreateDefault();
var client = new TelemetryClient(config);
client.TrackTrace("Offline processing started.");

During testing, you verify that no telemetry data is transmitted to the Application Insights resource, and the application runs without throwing any exceptions.

Which of the following is the most likely root cause of the missing telemetry?

Show answer & explanation

Answer: The connection string was not explicitly assigned to the ConnectionString property of the TelemetryConfiguration object, and the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable was not set.

Answer

The connection string was not explicitly assigned to the ConnectionString property of the TelemetryConfiguration object, and the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable was not set.
The correct option is that the connection string was not explicitly assigned to the configuration object and the environment variable was missing. When using the Application Insights SDK programmatically in .NET, TelemetryConfiguration.CreateDefault() searches for the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable. If it is not found and the ConnectionString property is not set in code, the SDK initializes with an empty destination and silently drops all tracked traces, events, and metrics without throwing any runtime exceptions.

Step-by-Step Solution

1
Inspect telemetry configuration initialization code.
Identify that TelemetryConfiguration.CreateDefault() is called without programmatically setting the ConnectionString property.
By default, TelemetryConfiguration.CreateDefault() looks for the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable.
2
Check environment variable configuration.
Determine that the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable is not defined in the host environment.
If neither the environment variable is set nor the property is assigned in code, the SDK is left unconfigured.
3
Analyze SDK telemetry transmission behavior under missing configuration.
Observe that the Application Insights SDK silently drops telemetry calls without throwing configuration exceptions.
The SDK is designed to fail silently to prevent telemetry configuration issues from crashing the primary application logic.

Key Concept

Application Insights SDK programmatic initialization requires a Connection String to be supplied either via TelemetryConfiguration.ConnectionString or the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable.
Estimated Time:2m 0s
Question 616Question →

You are configuring metric-based autoscale rules for an Azure App Service plan that currently runs on 11 instance. To prevent metric flapping when scaling between 11 and 22 instances, you need to set appropriate scale-out and scale-in thresholds. Which two of the following threshold configurations, based on the Average CPU percentage metric, will prevent flapping?

Select all that apply

Show answer & explanation

Answer: Scale-out when CPU percentage is greater than 80%80\%; scale-in when CPU percentage is less than 35%35\%; Scale-out when CPU percentage is greater than 70%70\%; scale-in when CPU percentage is less than 30%30\%

Answer

The correct threshold configurations are a scale-out threshold of 80%80\% with a scale-in threshold of 35%35\%, and a scale-out threshold of 70%70\% with a scale-in threshold of 30%30\%.
The configurations specifying a scale-out threshold of 80%80\% with a scale-in threshold of 35%35\%, and a scale-out threshold of 70%70\% with a scale-in threshold of 30%30\%, prevent flapping. This is because scaling from 11 to 22 instances divides the workload in half. For a scale-out threshold of 80%80\%, the CPU load drops to approximately 40%40\%, which is safely above the scale-in threshold of 35%35\%. For a scale-out threshold of 70%70\%, the CPU load drops to approximately 35%35\%, which is safely above the scale-in threshold of 30%30\%.

Step-by-Step Solution

1
Analyze how the CPU load is distributed when scaling out from 11 to 22 instances.
The average CPU load per instance is halved because the workload is divided equally between 22 instances.
To determine the new CPU level after a scale-out action occurs at or just above the scale-out threshold.
2
Calculate the new CPU level after scaling out for a scale-out threshold of 80%80\% and 70%70\%.
For an 80%80\% threshold, the new CPU is 80%/2=40%80\% / 2 = 40\%. For a 70%70\% threshold, the new CPU is 70%/2=35%70\% / 2 = 35\%.
To identify the minimum post-scale-out CPU percentage that will be observed on the instances.
3
Compare the post-scale-out CPU level to the scale-in threshold for each configuration.
For the configuration with scale-out 80%80\% and scale-in 35%35\%, 40%>35%40\% > 35\% (no flapping). For scale-out 70%70\% and scale-in 30%30\%, 35%>30%35\% > 30\% (no flapping). The other configurations have scale-in thresholds (45%45\% and 60%60\%) higher than the post-scale-out levels, which triggers immediate scale-in (flapping).
To select the configurations where the scale-in threshold is lower than the new CPU load, avoiding immediate scale-in.

Key Concept

Configuring scale-out and scale-in thresholds with a sufficient margin to prevent metric flapping when resource count changes.
Question 617Question →

A secure C# Web API is hosted on an Azure App Service instance that has a system-assigned managed identity enabled. The Web API needs to retrieve a database connection string stored as a secret in an Azure Key Vault named kv-prod. The Key Vault is configured to use the Azure role-based access control (Azure RBAC) permission model. During testing, the Web API receives a 403 Forbidden error when attempting to retrieve the secret. You need to resolve the authorization issue while adhering to the principle of least privilege. What should you do?

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 system-assigned managed identity at the Key Vault scope is the correct solution. Since the Key Vault uses the Azure RBAC permission model, traditional access policies are disabled. The Key Vault Secrets User role provides the minimum permissions necessary to retrieve secret values, satisfying the principle of least privilege.

Step-by-Step Solution

1
Identify the active authorization model for the Key Vault.
The Key Vault is configured to use the Azure RBAC permission model.
This determines whether to use role assignments or access policies.
2
Determine the minimum required permissions to read a secret.
The Key Vault Secrets User role is required to read secret values.
The Key Vault Secrets Officer role grants write/delete permissions and violates the principle of least privilege.
3
Assign the role to the correct identity at the appropriate scope.
Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.
This authorizes the Web API to retrieve the connection string securely and with least privilege.

Key Concept

Azure Key Vault authorization using the Azure RBAC permission model
Question 618Question →

You are developing a C# service that updates the metadata of a blob in Azure Blob Storage using the Azure.Storage.Blobs SDK. The target blob is currently locked with an active lease. You have the lease ID stored in a variable named `activeLeaseId` and the metadata dictionary stored in a variable named `metadata`.

Which of the following code segments should you use to successfully update the blob's metadata?

Show answer & explanation

Answer: await blobClient.SetMetadataAsync(metadata, new BlobRequestConditions { LeaseId = activeLeaseId });

Answer

The correct option is the one that calls the SetMetadataAsync method with a BlobRequestConditions object containing the LeaseId property set to the active lease ID.
The correct code block initializes a BlobRequestConditions object and sets its LeaseId property to the activeLeaseId. This object is then passed as the second argument to SetMetadataAsync, which correctly informs Azure Blob Storage of the authorized lease hold for the write operation.

Step-by-Step Solution

1
Identify the requirement to update a leased blob's metadata.
Any write or update operation on a leased blob requires the active lease ID to be passed as part of the request conditions.
Azure Blob Storage enforces leases to prevent concurrent write conflicts, and requests without the lease ID on a leased resource fail with an HTTP 412 error.
2
Select the correct SDK class for passing request conditions in the Azure.Storage.Blobs SDK.
The BlobRequestConditions class should be instantiated, and its LeaseId property must be set to the active lease ID.
The base RequestConditions class does not expose the LeaseId property, which is specific to blob storage operations.
3
Call the SetMetadataAsync method with the metadata dictionary and the request conditions.
await blobClient.SetMetadataAsync(metadata, new BlobRequestConditions { LeaseId = activeLeaseId });
This matches the signature of the SDK's SetMetadataAsync overload that accepts request conditions.

Key Concept

To modify a leased blob or its metadata, you must provide the active lease ID using the BlobRequestConditions class in the Azure.Storage.Blobs SDK.
Estimated Time:1m 30s
Question 619Question →

You are developing a web API and exposing it through Azure API Management. You must implement a policy that filters incoming requests to ensure they originate only from a specific range of IP addresses. In which section of the API Management policy document should you define the IP filtering policy?

Show answer & explanation

Answer: inbound

Answer

The inbound section is the correct location for the IP filtering policy because it processes requests before they are sent to the backend service.
The inbound section is executed immediately when a request is received by the API Management gateway and before it is forwarded to the backend. Policies designed to inspect, authorize, rate-limit, or filter client requests, such as the ip-filter policy, must be placed within this section.

Step-by-Step Solution

1
Analyze the policy requirement.
The requirement is to filter incoming client requests based on their IP address before they reach the backend service.
This is an inbound security filter that prevents unauthorized traffic from hitting the backend API.
2
Identify the API Management policy execution pipeline stages.
The execution flow in API Management goes: inbound -> backend -> outbound. If an error occurs, it goes to on-error.
Understanding the lifecycle of a request in Azure API Management is key to placing policies in the correct section.
3
Select the appropriate section for request filtering.
The inbound section executes first, making it the only appropriate place to filter client requests based on IP addresses.
Placing the filter here ensures that requests from invalid IP addresses are rejected early, saving backend resources.

Key Concept

Azure API Management policy execution order and section placement
Estimated Time:45s
Question 620Question →

An organization hosts a .NET 8.0 web application on Azure App Service using the Shared (D1) pricing tier. The development team has configured Application Insights but finds that both the Profiler and Snapshot Debugger tools are unavailable. To resolve this, you need to configure the hosting environment to the minimum supported pricing tier that enables these features, and ensure the team can view local variables and call stacks from captured exceptions. Which combination of App Service plan configuration and Azure role assignment must you implement?

Show answer & explanation

Answer: Upgrade the App Service plan to the Basic (B1) tier, and assign the Application Insights Snapshot Debugger role to the developers.

Answer

Upgrade the App Service plan to the Basic (B1) tier, and assign the Application Insights Snapshot Debugger role to the developers.
Upgrading the App Service plan to the Basic (B1) tier is the minimum required to support Profiler and Snapshot Debugger. Access to view the captured exception snapshots in the Azure portal is restricted to users with the Application Insights Snapshot Debugger role due to the potential inclusion of sensitive data in the memory snapshot.

Step-by-Step Solution

1
Determine the minimum App Service plan pricing tier supporting Profiler and Snapshot Debugger.
Basic (B1) pricing tier.
Both Profiler and Snapshot Debugger require a minimum of a Basic, Standard, or Premium App Service plan. Free (F1) and Shared (D1) tiers are not supported.
2
Identify the required Azure RBAC role for developers to view call stacks and local variables in the captured exceptions.
Application Insights Snapshot Debugger role.
Debug snapshots can contain sensitive personal data (PII) from memory. As a result, standard monitoring roles like Reader or Monitoring Contributor do not have permission to view snapshots. The dedicated Application Insights Snapshot Debugger role must be assigned to the users.

Key Concept

Pricing tier requirements and RBAC access permissions for Application Insights Profiler and Snapshot Debugger.
PreviousPage 31 / 49Next