All practice questions

972 questions

Question 941Question

An organization hosts a web application named `FleetTelemetryAPI` on an App Service plan that is currently configured for the Basic (B1B1) pricing tier. During peak operation hours, the application experiences CPU usage spikes that degrade performance. The administrator wants to configure autoscale rules to automatically scale out the application when CPU utilization is high, and scale it back in when demand decreases, ensuring that the configuration prevents flapping.

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

Select all that apply

Show answer & explanation

Answer: Scale up the App Service plan to the Standard (S1S1) tier or higher.; Configure a scale-out rule to increase the instance count when CPU usage exceeds 80%80\%, and a scale-in rule to decrease the instance count when CPU usage drops below 60%60\%.

Answer

Scale up the App Service plan to the Standard (S1S1) tier or higher, and configure a scale-out rule to increase the instance count when CPU usage exceeds 80%80\%, and a scale-in rule to decrease the instance count when CPU usage drops below 60%60\%.
Scaling out (horizontal scaling) and autoscale features require at least the Standard (S1S1) tier of Azure App Service, as the Basic (B1B1) tier only supports manual scale-up/down. Additionally, to prevent autoscale flapping, the scale-in metric threshold must be sufficiently lower than the scale-out threshold so that scaling in does not immediately trigger another scale-out event.

Step-by-Step Solution

1
Evaluate the current App Service pricing tier.
The current plan is Basic (B1B1), which does not support autoscale or horizontal scaling (scale-out).
Autoscale features require a Standard (S1S1) tier or higher.
2
Determine the scaling rule thresholds to prevent flapping.
The scale-out rule triggers when CPU usage is high (80%80\%) and the scale-in rule triggers when CPU usage is low (60%60\%) with a significant buffer in between.
If the scale-in threshold is too close to or higher than the scale-out threshold, the reduction in per-instance load after scaling out will immediately trigger a scale-in, creating a flapping loop.

Key Concept

Azure App Service Scaling Tiers and Autoscale Flapping Prevention
Question 942Question

You are configuring a custom Webhook endpoint to subscribe to events from an Azure Event Grid custom topic. To begin receiving events, your Webhook endpoint must successfully complete the synchronous validation handshake. What must your Webhook endpoint do when it receives the synchronous validation request from Azure Event Grid?

Show answer & explanation

Answer: Extract the validation code from the request body and return it in the validationResponse property of the JSON response.

Answer

Extract the validation code from the request body and return it in the validationResponse property of the JSON response.
When Azure Event Grid sends a subscription validation request to a Webhook endpoint, it includes a validationCode in the request body under the data object. To validate the endpoint synchronously, the subscriber must return this validation code in a JSON response using the validationResponse key.

Step-by-Step Solution

1
Receive the HTTP POST validation request containing the validation code from Azure Event Grid.
The endpoint receives a request containing a SubscriptionValidationEvent in the body, which holds a validationCode.
Azure Event Grid automatically triggers this request to confirm that the endpoint is owned and controlled by the subscription creator.
2
Extract the validationCode from the data object of the received JSON payload.
The string value of the validationCode is retrieved.
This code must be returned to Event Grid to successfully complete the handshake.
3
Respond to the HTTP POST request with an HTTP 200 OK status code and a JSON response body containing the validationResponse property set to the validationCode.
The validation response is sent back, and Event Grid registers the subscription as active.
Event Grid matches the returned validationResponse to the validationCode it generated to confirm ownership.

Key Concept

Azure Event Grid synchronous Webhook endpoint validation requires the subscriber to echo back the received validationCode in a JSON response containing the validationResponse property.
Estimated Time:1m 0s
Question 943Question

You are developing a nightly backup verification workflow using Azure Durable Functions in Python. The orchestrator function must periodically call an activity function to check the status of a database backup job. If the backup is not yet complete, the orchestrator must wait for 15 minutes before checking the status again.

You write the following orchestrator function:

python
import azure.durable_functions as df
import time

def orchestrator_function(context: df.DurableOrchestrationContext):
backup_id = context.get_input()
max_attempts = 5

for attempt in range(max_attempts):
status = yield context.call_activity("CheckBackupStatus", backup_id)
if status == "Completed":
return "Success"

# Wait 15 minutes before the next check
time.sleep(900)

return "Failed"

During testing, the function fails because of thread blocking and invalid replay behavior.

Which modification should you make to ensure the orchestrator function runs correctly without blocking execution threads?

Show answer & explanation

Answer: Replace the time.sleep(900) call with yield context.create_timer(context.current_utc_datetime + datetime.timedelta(minutes=15)) after importing datetime.

Answer

Use context.create_timer with context.current_utc_datetime and datetime.timedelta to schedule a durable timer, allowing the orchestrator to yield and suspend execution safely.
The correct answer is to use a durable timer scheduled via the orchestrator context. Durable orchestrators must be deterministic and cannot execute blocking calls like sleep. Using context.create_timer allows the runtime to suspend the orchestrator, save its current state, and wake it up at the specified datetime without consuming resources or blocking worker threads.

Step-by-Step Solution

1
Analyze the orchestrator code for blocking or non-deterministic operations.
Identify that time.sleep(900) is a blocking call that keeps the thread active and violates the determinism constraint of Durable orchestrators.
Orchestrator functions must yield control back to the runtime to allow state checkpointing and replay without executing blocking side effects.
2
Identify the appropriate Azure Durable Functions API for implementing delays.
Select context.create_timer which schedules a message in the control queue to resume execution at a future timestamp.
Durable timers ensure the orchestrator is unloaded from memory while waiting, avoiding thread blocking and extra billing costs.
3
Calculate the expiration timestamp deterministically using orchestrator context.
Use context.current_utc_datetime instead of datetime.datetime.utcnow() combined with datetime.timedelta(minutes=15) to set the expiration.
Using context.current_utc_datetime guarantees that during replay, the time remains consistent, preserving orchestrator determinism.

Key Concept

Durable Functions Orchestrator Determinism and Timers
Question 944Question

You are configuring a Standard availability test in Azure Application Insights to monitor a secure API endpoint that requires client certificate authentication (mutual TLS). The API is hosted on an external system that does not support Microsoft Entra ID authentication.

You need to ensure that the availability test can authenticate with the API and successfully monitor its availability.

Which configuration should you perform in the Application Insights availability test settings?

Show answer & explanation

Answer: Enable SSL client certificates, and upload the client certificate as a password-protected PFX file.

Answer

Enable SSL client certificates, and upload the client certificate as a password-protected PFX file.
To monitor an endpoint requiring client certificate authentication using an Application Insights Standard availability test, you must enable the SSL client certificates option and upload the client certificate in PFX format along with its password. This allows the Application Insights service to authenticate with the target API during the availability checks.

Step-by-Step Solution

1
Select the Standard test type under Application Insights Availability test creation.
Access to advanced properties such as custom HTTP verbs, headers, and SSL options is enabled.
Standard tests allow advanced monitoring features compared to classic URL ping tests.
2
Locate the SSL client certificates section, check 'Enable SSL client certificates', and upload the PFX certificate file.
The certificate and its corresponding password are encrypted and stored in the test configuration.
This allows the test runner to load the client certificate and perform a mutual TLS handshake when calling the target API endpoint.

Key Concept

Configuring client certificate authentication for Application Insights Standard availability tests
Question 945Question

You are developing a C# service that manages utility smart-meter configurations using the Azure Cosmos DB .NET SDK v3. The target container is configured with a partition key path of `/gridId`.

You need to update the configuration of a specific smart meter. Your task is to write a method that retrieves the existing configuration document, changes the `ReportingIntervalMinutes` property to `15` in memory, and then saves the updated configuration back to the container.

Arrange the steps in the correct order to complete the operation.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order of operations starts with instantiating the CosmosClient, followed by retrieving references to the Database and Container. Next, the existing item is read using ReadItemAsync with its ID and PartitionKey. The retrieved configuration's properties are then modified in memory. Finally, the updated configuration is saved back to the container using ReplaceItemAsync, passing the modified document, its ID, and its PartitionKey.
The correct order follows the logical hierarchy of the Azure Cosmos DB .NET SDK v3. A CosmosClient must be created first to manage connections. The client is used to reference the Database, which is then used to reference the Container. Before modifying and replacing the item, the current state of the item must be read using ReadItemAsync (providing the ID and partition key). The retrieved object's properties are updated in memory next. Finally, the replacement is committed using ReplaceItemAsync with the updated object, its ID, and the partition key.

Step-by-Step Solution

1
Initialize the SDK client.
A CosmosClient instance is created.
The client manages connections and configuration for the Azure Cosmos DB account.
2
Retrieve the database object.
A Database reference is obtained.
You must navigate the SDK hierarchy from client to database.
3
Retrieve the container object.
A Container reference is obtained.
All item operations are executed against a specific Container instance.
4
Perform a point read.
An ItemResponse containing the MeterConfig object is returned.
To modify an existing item, you must read the current state of the document using both ID and the partition key.
5
Update the object in memory.
The local object's property is changed.
Modifications must be made to the local object representation before sending it back.
6
Replace the item in Cosmos DB.
The item is updated in the container.
The ReplaceItemAsync method updates the database representation using the updated local object, the ID, and the partition key.

Key Concept

Azure Cosmos DB .NET SDK v3 item update workflow using point read and replace
Question 946Question

An Azure App Service web app logs database connection exceptions to an Application Insights instance. You need to configure an Azure Monitor Log Search alert rule that triggers when database connection exceptions occur more than 10 times within a 5-minute window. When triggered, the alert must run an Azure Function that retrieves a database credential from Azure Key Vault and restarts the connection pool. Which of the following actions should you perform? (Select two)

Select all that apply

Show answer & explanation

Answer: Create a Log Search alert rule with a KQL query that filters for database connection exceptions, and configure the alert condition's Aggregation Granularity (Period) to 5 minutes.; Create an Azure Monitor Action Group with an Azure Function action type that targets the remediation function, and configure the Function App with a managed identity that has a Key Vault access policy granting GET secrets permission.

Answer

To implement this solution, you must create a Log Search alert rule with a KQL query filtering for database connection exceptions, configure the alert condition's Aggregation Granularity (Period) to 5 minutes, create an Azure Monitor Action Group with an Azure Function action targeting the remediation function, and configure the Function App's managed identity with a Key Vault access policy granting GET secrets permission.
The correct actions involve configuring a Log Search alert rule with the KQL query and the appropriate 5-minute period window, and setting up an Action Group that uses the Azure Function action type while ensuring the function itself has its own managed identity authorized to fetch secrets from the Key Vault.

Step-by-Step Solution

1
Configure the KQL query in the Log Search alert rule to filter database connection exceptions and set the Aggregation Granularity (Period) to 5 minutes.
The alert rule correctly evaluates telemetry data over the specified 5-minute window.
Defining the filter and setting the period ensures the rule triggers precisely when the target conditions are met.
2
Create an Action Group and configure it with an Azure Function action that points to the remediation function.
The alert rule triggers the Azure Function when the threshold is exceeded.
Action Groups map alert triggers to downstream automation resources such as Azure Functions.
3
Configure a system-assigned or user-assigned managed identity on the Function App and grant it a Key Vault access policy with GET permissions.
The Azure Function is authorized to retrieve the database credential from Key Vault.
The Azure Function runs under its own identity context, which must be explicitly authorized to access Key Vault secrets.

Key Concept

Integrating Azure Monitor Alert Rules with Action Groups and securing downstream resource access.
Question 947Question

You are developing a Python backend application that uses the azure-storage-blob SDK (v12). The application needs to overwrite the content of a blob named config.json that has an active lease. The lease ID is 5b8f673d-8d2a-4f5a-9b4e-8c6e2b1a3c5d.

Which of the following code snippets should you use to successfully perform this operation?

Show answer & explanation

Answer: blob_client.upload_blob(data, overwrite=True, lease="5b8f673d-8d2a-4f5a-9b4e-8c6e2b1a3c5d")

Answer

blob_client.upload_blob(data, overwrite=True, lease="5b8f673d-8d2a-4f5a-9b4e-8c6e2b1a3c5d")
The correct option correctly uses the 'lease' keyword argument of the 'upload_blob' method, passing the active lease ID. This enables the Azure Storage SDK to include the necessary lease validation headers, allowing the write operation to succeed on the leased blob.

Step-by-Step Solution

1
Identify the destination BlobClient and the lease ID associated with the active lease.
Destination blob_client is targeted at config.json, and the lease ID string is identified.
An active lease blocks any modifications to the blob unless the correct lease ID is supplied to authorize the operation.
2
Construct the upload_blob method call on BlobClient, passing the lease ID via the lease parameter.
The SDK serializes this parameter to the x-ms-lease-id HTTP request header.
The Azure Storage REST API matches this header against the active lease lock on the blob.
3
Execute the upload_blob call with overwrite=True.
The blob content is overwritten successfully.
Since the correct lease condition is validated, the service accepts the write action.

Key Concept

To perform modifications on an actively leased blob using the Azure Storage SDK for Python, the lease ID must be passed directly to the upload_blob method using the lease keyword argument.
Question 948Question

You are developing an ASP.NET Core Web API that will serve as a webhook subscriber for an Azure Event Grid custom topic. To start receiving events, you must implement the synchronous validation handshake. You have created the following controller action method to handle incoming POST requests:

csharp
[HttpPost]
public async Task<IActionResult> HandleEvent()
{
using var reader = new StreamReader(Request.Body);
string requestBody = await reader.ReadToEndAsync();

EventGridEvent[] events = EventGridEvent.ParseMany(BinaryData.FromString(requestBody));

foreach (EventGridEvent ev in events)
{
if (ev.EventType == "Microsoft.EventGrid.SubscriptionValidationEvent")
{
var data = ev.Data.ToObjectFromJson<SubscriptionValidationEventData>();

// [MISSING CODE]
}
}
return new OkResult();
}

Which of the following code segments should you use to replace `// [MISSING CODE]` to successfully complete the synchronous subscription validation handshake?

Show answer & explanation

Answer: var responseData = new { validationResponse = data.ValidationCode };
return new OkObjectResult(responseData);

Answer

The code segment that returns an anonymous object with the validationResponse property set to the validation code from the request.
To complete the synchronous validation handshake, the endpoint must return an HTTP 200 OK response containing a JSON payload with a single property named 'validationResponse'. The value of this property must match the 'validationCode' sent in the request data. Constructing an anonymous object in ASP.NET Core with the property name 'validationResponse' and passing it to OkObjectResult satisfies this requirement.

Step-by-Step Solution

1
Detect the validation event type in the incoming request payload.
Confirm the request represents a SubscriptionValidationEvent.
Event Grid sends a validation event to verify that the endpoint is owned by the developer and is ready to accept events.
2
Extract the ValidationCode from the SubscriptionValidationEventData object.
Access the system-generated code sent by Event Grid.
The validation response must echo back this specific code to complete the verification.
3
Format the response JSON object with the property name 'validationResponse' and return it with an HTTP 200 status code.
Complete the validation handshake synchronously.
Event Grid expects the validation code to be returned in the response body inside a JSON object with the exact property key 'validationResponse'.

Key Concept

Azure Event Grid Webhook Endpoint Validation Handshake
Question 949Question

A developer is configuring a .NET Core Web API to use Azure Application Insights. In the Program.cs file, they add the call builder.Services.AddApplicationInsightsTelemetry(). However, they do not configure the Application Insights connection string in the appsettings.json file or in the App Service environment variables. What is the behavior of the application at runtime?

Show answer & explanation

Answer: The application starts and runs normally, but no telemetry is sent to Azure Monitor.

Answer

The application starts and runs normally, but no telemetry is sent to Azure Monitor.
The correct answer states that the application starts and runs normally, but no telemetry is sent to Azure Monitor. When the Application Insights SDK is registered in code but the connection string is missing or empty, the SDK initializes successfully but does not transmit any telemetry. It does not throw a startup exception, ensuring application availability is not compromised by a telemetry configuration omission.

Step-by-Step Solution

1
Determine the behavior of the Application Insights SDK when initialized without a connection string configuration.
The SDK initializes without throwing a runtime exception but remains in a dormant state.
This behavior prevents telemetry configuration omissions from causing application downtime in production environments.
2
Evaluate the distractors against Azure hosting and security behaviors.
Autoscale policies and Key Vault access issues do not block local SDK initialization directly.
This isolates the issue as a silent telemetry collection failure rather than a startup crash.

Key Concept

Application Insights SDK Initialization Behavior with Missing Configuration
Question 950Question

An administrator integrates a web application with Application Insights to capture execution profiles using the Profiler tool. However, after the application starts, no telemetry data or traces are visible in the Azure portal.

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

Show answer & explanation

Answer: The Application Insights SDK is initialized in the application code, but the connection string has not been configured in the environment settings.

Answer

The Application Insights SDK is initialized in the application code, but the connection string has not been configured in the environment settings.
For Application Insights to collect and display telemetry data, the SDK must be provided with a valid connection string. If the connection string is missing or not configured in the application environment settings, the SDK cannot send any telemetry data (including Profiler traces) to the Azure portal.

Step-by-Step Solution

1
Verify if the Application Insights SDK is correctly initialized and configured with a valid destination.
The SDK requires either the ApplicationInsights_ConnectionString or APPINSIGHTS_INSTRUMENTATIONKEY environment variable to know where to send telemetry.
Without a valid connection string, the SDK runs in a disconnected state and does not transmit any traces or logs.
2
Check application settings or environment variables in the hosting environment.
Confirm that the connection string value matches the one provided in the Application Insights overview page in the Azure portal.
Ensuring the configuration is present and correct establishes the communication path between the application runtime and the Azure Monitor service.

Key Concept

Application Insights SDK Initialization and Connection String Configuration
Estimated Time:45s
Question 951Question

You are developing a background worker service in C# that runs as a containerized application within Azure Container Apps. The service must run on a schedule without user interaction and authenticate to the Microsoft Identity Platform to read files from Microsoft Graph.

To comply with security policies, you must use Azure Managed Identities for authentication. The credentials must persist independently of the containerized app's lifecycle, allowing the container instances to be deleted, recreated, or scaled across different resource groups without requiring permissions to be reconfigured in Microsoft Entra ID.

Which approach should you use to implement this authentication?

Show answer & explanation

Answer: Create a user-assigned managed identity as a standalone Azure resource. Grant this identity the required Microsoft Graph application permissions, associate it with the Azure Container App, and initialize DefaultAzureCredential by passing the client ID of the user-assigned managed identity.

Answer

Create a user-assigned managed identity as a standalone Azure resource. Grant this identity the required Microsoft Graph application permissions, associate it with the Azure Container App, and initialize DefaultAzureCredential by passing the client ID of the user-assigned managed identity.
The correct approach is to create a user-assigned managed identity. A user-assigned managed identity is created as a standalone Azure resource and has its own lifecycle independent of the Azure Container App. If the container app is deleted or recreated, the user-assigned identity and its assigned Microsoft Graph permissions persist. When initializing DefaultAzureCredential in code, the client ID of the user-assigned managed identity must be specified to ensure the SDK authenticates with the correct identity.

Step-by-Step Solution

1
Create a user-assigned managed identity in Azure.
A standalone identity resource is generated with its own Client ID and Object ID, separate from the container app.
To ensure that the identity credentials persist even if the hosting container app is deleted or redeployed.
2
Grant the user-assigned managed identity the required Microsoft Graph application permissions.
The identity is authorized to access Microsoft Graph APIs directly without user intervention.
Because the background worker service runs automatically on a schedule and cannot perform interactive user login.
3
Associate the user-assigned managed identity with the Azure Container App and configure the C# application to use it.
The Container App gets access to the identity, and DefaultAzureCredential is initialized using the client ID of the user-assigned managed identity.
To ensure the Azure SDK/MSAL resolves to the correct user-assigned identity instead of attempting to fall back to other credentials.

Key Concept

Managed Identities (system-assigned vs. user-assigned) and their lifecycle differences when authenticating to the Microsoft Identity Platform.
Question 952Question

You are managing a web application that distributes documents through an Azure CDN endpoint. You need to configure a custom caching rule in the Azure portal that overrides the default caching behavior specifically for files in the `/pdf/` directory.

In which order should you perform the steps in the Azure portal to configure and apply this custom caching rule?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure a custom caching rule in the Azure portal, you must first navigate to the CDN endpoint, select the Caching rules settings, configure the path match and override behavior in the Custom caching rules section, and then save the changes.
The correct order begins with locating the target CDN endpoint in the portal. Next, navigation to the caching rules settings is required. Once inside, you define the custom rule settings (using the path match condition and override behavior) to target the `/pdf/` directory. Finally, saving the settings deploys the rule to the CDN POPs.

Step-by-Step Solution

1
Navigate to the CDN endpoint
The endpoint blade is displayed, exposing the management settings.
You must target the specific endpoint before you can modify its caching configurations.
2
Open Caching rules
The caching rules workspace opens, showing query string, global caching, and custom caching options.
All caching-related settings are consolidated in the Caching rules menu under Settings.
3
Configure the Custom caching rule
A new custom rule is defined targeting the `/pdf/*` path with an Override behavior.
Defining the rule specifies which requests (by path) will have their cache headers overridden and how the CDN should handle them.
4
Save the changes
The configuration is saved and propagation to the CDN edge servers begins.
Changes to caching rules do not take effect until they are saved and deployed.

Key Concept

Custom caching rules allow overriding or bypassing default caching behaviors based on specific match conditions like path or file extension.
Question 953Question

You are designing a serverless workflow using Azure Durable Functions in C# (.NET Isolated) to manage a vehicle fleet maintenance process. The orchestrator function must query an external vehicle diagnostics REST API to retrieve real-time fault codes before deciding which maintenance tasks to execute.

Which of the following is the correct way to implement this external API call while complying with the determinism requirements of Durable Functions?

Show answer & explanation

Answer: Delegate the REST API call to an Activity function called by the orchestrator, or use the orchestration context's built-in HTTP APIs.

Answer

Delegate the REST API call to an Activity function called by the orchestrator, or use the orchestration context's built-in HTTP APIs.
The correct answer is to delegate the REST API call to an Activity function or use the orchestration context's built-in HTTP APIs. Since orchestrator functions in Durable Functions must be completely deterministic, performing direct I/O (such as invoking external APIs via HttpClient) is not allowed. Activity functions do not have this restriction and are only executed once, with their results recorded in the execution history. Alternatively, the built-in CallHttpAsync method on the orchestration context can be used as it is designed to run deterministically during replays.

Step-by-Step Solution

1
Identify the constraints of the Durable Functions orchestrator code.
Orchestrator code must be deterministic, meaning it cannot execute side effects or I/O operations directly.
During execution, the orchestrator is replayed multiple times from the history log. Any direct network calls would be re-executed, causing performance issues and non-deterministic behavior.
2
Determine the correct mechanism for calling external HTTP services.
External calls must either be placed inside an Activity function (which does not have determinism constraints) or executed using the built-in HTTP action APIs provided by the orchestration context (e.g., CallHttpAsync in .NET Isolated).
Activity functions execute once and record their output in the orchestration history, preventing re-execution during replays. The built-in CallHttpAsync API also registers its results in the orchestration history.

Key Concept

Orchestrator determinism and out-of-process communication using Activity functions or built-in HTTP APIs
Question 954Question

You are designing a serverless document approval workflow using Azure Durable Functions in C# (.NET Isolated). The orchestrator must pause and wait for an external manager approval event named 'ApprovalReceived' for up to 72 hours. If the event is received, the workflow proceeds; if 72 hours elapse without the event, the workflow runs an escalation activity function.

Which two of the following code steps or architectural decisions must you implement to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Use context.CreateTimer to define the timeout and context.WaitForExternalEvent<bool>("ApprovalReceived") for the approval, then await them using Task.WhenAny.; Determine the expiration timestamp by adding the timeout duration to context.CurrentUtcDateTime rather than using DateTime.UtcNow.

Answer

To implement the human interaction pattern with a timeout, you must use context.CreateTimer alongside context.WaitForExternalEvent and await them via Task.WhenAny. Additionally, to maintain determinism within the orchestrator, you must use context.CurrentUtcDateTime instead of DateTime.UtcNow for date-time calculations.
The correct actions are using context.CreateTimer and context.WaitForExternalEvent with Task.WhenAny to wait for whichever happens first, and using context.CurrentUtcDateTime to ensure deterministic execution. Combining the two tasks allows the orchestrator to resume when either the manager approves or the 72-hour limit is reached. Using the orchestrator's built-in date-time property ensures the replay engine gets the same timestamp on every execution.

Step-by-Step Solution

1
Combine timer and event tasks.
A single task that resolves when the first of the two completes.
Enables pausing the orchestrator until either the approval occurs or the timeout is reached.
2
Use context.CurrentUtcDateTime.
Stable timestamps across replays.
Standard DateTime.UtcNow is non-deterministic and violates orchestrator constraints.

Key Concept

Durable Functions Orchestration Constraints and Human Interaction Pattern
Question 955Question

A telemetry ingestion system requires a .NET service to consume stream records from Azure Event Hubs. You plan to implement event processing using the Azure.Messaging.EventHubs.Processor namespace, using Azure Blob Storage for partition checkpoints. What is the correct sequence of API operations to manage the lifecycle of the client?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first initialize the BlobContainerClient and EventProcessorClient, then register callback methods for both ProcessEventAsync and ProcessErrorAsync, followed by calling StartProcessingAsync to start processing, and finally calling StopProcessingAsync to cleanly terminate consumption.
To consume events using the modern Azure.Messaging.EventHubs SDK, the developer must first initialize the required clients (BlobContainerClient and EventProcessorClient). Before processing can begin, the client requires that handler methods for both events and errors be registered. Once registered, StartProcessingAsync is called to begin operations. To shut down cleanly and release partition leases, StopProcessingAsync must be called.

Step-by-Step Solution

1
Instantiate BlobContainerClient and EventProcessorClient.
Clients are constructed and ready for setup.
The processor requires references to the checkpoint storage container and target event hub configurations during creation.
2
Assign event handlers to ProcessEventAsync and ProcessErrorAsync.
Callback methods are registered to process incoming events and errors.
EventProcessorClient mandates both event and error handler registrations before processing can start.
3
Invoke StartProcessingAsync.
The processor starts load balancing and consuming partitions.
Starting the client initiates background tasks to pull events and update checkpoints.
4
Invoke StopProcessingAsync.
Event consumption stops and partition leases are released.
Stopping the client ensures a graceful shutdown, preventing other instances from waiting for lease expiration.

Key Concept

Managing the lifecycle of EventProcessorClient in Azure Event Hubs .NET SDK
Question 956Question

You are designing a monitoring solution for an Azure-hosted web application. You configure an Azure Monitor Action Group to respond to alerts. You need to select the action types that you can add directly to the Action Group to execute notifications or trigger remediation processes. Which two action types should you select?

Select all that apply

Show answer & explanation

Answer: Email Azure Resource Manager Role; Azure Function

Answer

The supported action types that can be directly added to the Action Group are Email Azure Resource Manager Role and Azure Function.
Azure Monitor Action Groups support direct actions for both notifications and automation. 'Email Azure Resource Manager Role' is a supported notification action that sends emails to members of selected subscription roles. 'Azure Function' is a supported automation action that allows you to run serverless code in response to an alert.

Step-by-Step Solution

1
Review the direct notification action types supported by Azure Monitor Action Groups.
Identify that Email Azure Resource Manager Role is a native notification option.
Action Groups allow notifying subscription-level roles such as Owner, Contributor, or Reader.
2
Review the direct automation action types supported by Azure Monitor Action Groups.
Identify that Azure Function is a native automation option.
Azure Functions allow executing custom serverless code directly when the alert is triggered.

Key Concept

Supported action types and receivers in Azure Monitor Action Groups
Question 957Question

You are developing an ASP.NET Core Web API hosted on Azure App Service. You must implement a custom telemetry processor named DependencyFilterProcessor to filter out successful SQL dependency telemetry before it is sent to Application Insights. You also need to register this telemetry processor in the dependency injection container.

How should you complete the code segments for the processor implementation and service registration?

Fill in the blanks below

csharp
// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddApplicationInsightsTelemetry(builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"]);

// Register the custom telemetry processor
builder.Services.
<DependencyFilterProcessor>();

// DependencyFilterProcessor.cs
using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.Extensibility;

public class DependencyFilterProcessor :

{
private readonly
_next;

public DependencyFilterProcessor(
next)
{
_next = next;
}

public void Process(ITelemetry item)
{
// Filtering logic goes here
_next.Process(item);
}
}
Show answer & explanation

Answer

To configure a custom telemetry processor, register it in the dependency injection container using the `AddApplicationInsightsTelemetryProcessor<DependencyFilterProcessor>()` extension method. The processor class and its constructor argument must implement the `ITelemetryProcessor` interface.
The correct implementation utilizes `AddApplicationInsightsTelemetryProcessor` to register the processor, which implements `ITelemetryProcessor` and receives the next `ITelemetryProcessor` in its constructor to continue the pipeline execution.

Step-by-Step Solution

1
Identify the dependency injection extension method for custom telemetry processors in ASP.NET Core.
The correct method is `AddApplicationInsightsTelemetryProcessor`.
This method registers the processor and ensures that the SDK properly chains it with other processors and supplies the next processor via constructor injection.
2
Determine the interface required for implementing a custom telemetry processor.
The interface is `ITelemetryProcessor`.
Custom telemetry processors must implement the `ITelemetryProcessor` interface and define the `Process` method.
3
Determine the parameter type needed in the processor's constructor to chain telemetry processors.
The type is `ITelemetryProcessor`.
The constructor of a custom telemetry processor must accept the next `ITelemetryProcessor` in the execution chain to pass telemetry along.

Key Concept

Custom Telemetry Processors in Application Insights
Question 958Question

You are deploying a containerized microservice named inventory-service to Azure Container Apps. The service needs to communicate with other services in the same Container App Environment using HTTP/2, but it must not be accessible from the public internet.

Which two configuration settings must you apply to the Container App configuration to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the external property within the ingress configuration block to false.; Set the transport property within the ingress configuration block to http2.

Answer

To configure an internal Container App that communicates via HTTP/2, you must set the ingress external property to false and the transport property to http2 within the application's configuration definition.
To restrict access to the Container App Environment and prevent public internet access, the external property within the ingress block must be set to false. Additionally, the transport property within the ingress block must be set to http2 to support HTTP/2 communication. Both properties are standard ingress settings configured at the Container App level.

Step-by-Step Solution

1
Set the ingress scope to internal by configuring the external property.
Setting external to false restricts incoming traffic to only originate from within the Container App Environment, preventing public internet access.
This secures the service by isolation.
2
Set the transport protocol to HTTP/2.
Setting transport to http2 configures the proxy to accept HTTP/2 requests.
This aligns the container app with the required communication protocol for the microservice.

Key Concept

Configuring ingress parameters for Azure Container Apps to restrict accessibility to the internal environment and define specific network transport protocols.
Question 959Question

You are deploying a custom Webhook endpoint to receive events from an Azure Event Grid system topic. The Webhook endpoint is hosted on an internal system that is unable to return a synchronous validation response when the subscription is created. You need to manually validate the subscription.

Which two actions should you perform? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Extract the value of the validationUrl property from the validation request payload.; Send an HTTP GET request to the extracted validation URL.

Answer

Extract the value of the validationUrl property from the validation request payload, and send an HTTP GET request to the extracted validation URL.
To manually validate an Event Grid subscription for a Webhook endpoint, you must capture the validation request sent by Event Grid. From this payload, you extract the validationUrl. Performing an HTTP GET request to this URL completes the validation handshake. This is typical for scenarios where the endpoint is behind a firewall, on a private network, or hosted by a third-party service that cannot respond dynamically.

Step-by-Step Solution

1
Retrieve the event payload sent to the Webhook endpoint when the subscription is created.
The JSON payload containing the subscription validation event is captured.
The event contains the validation URL needed for manual validation.
2
Locate and extract the validationUrl field from the data object of the captured event.
The validation URL (which is valid for 5 minutes) is obtained.
This URL is pre-signed by Event Grid to perform manual validation.
3
Send an HTTP GET request to the extracted validation URL.
Event Grid receives the GET request and successfully transitions the subscription status to active.
The handshake is completed by sending a GET request to the validation URL.

Key Concept

Azure Event Grid subscription endpoint manual validation
Estimated Time:1m 30s
Question 960Question

You are developing a media processing application in C# using the Azure.Storage.Blobs SDK (version 12). The application needs to manage the custom metadata of uploaded video blobs and transition them to the Archive access tier to reduce storage costs. Which two of the following statements are correct regarding how the SDK handles metadata, access tiers, and leases?

Select all that apply

Show answer & explanation

Answer: To change the access tier of a blob to Archive, you call the SetAccessTierAsync method on the BlobClient, and you can read the blob's metadata without needing to rehydrate the blob first.; Azure Blob Storage converts all metadata keys to lowercase. When retrieving metadata via the .NET SDK's Metadata dictionary, you must access the keys using lowercase strings (e.g., 'resolution'), even if they were written with uppercase letters.

Answer

Setting the access tier using SetAccessTierAsync allows reading metadata without rehydration, and retrieving blob metadata requires using lowercase keys since Azure Storage converts all metadata keys to lowercase.
The correct answer statements correctly describe that: 1. You can transition a blob to the Archive tier using the SetAccessTierAsync method and still read its metadata without rehydration. 2. Metadata keys are stored in lowercase by Azure Blob Storage, meaning you must access them with lowercase keys in the SDK.

Step-by-Step Solution

1
Analyze access tier transition and metadata accessibility.
The SetAccessTierAsync method transitions the blob to the Archive tier. Metadata and properties remain accessible for reading and writing directly without rehydration.
Only the blob's actual payload/content is offline in the Archive tier; the system metadata and user-defined metadata remain online.
2
Analyze metadata naming casing rules.
Metadata keys are transmitted via HTTP headers and stored in lowercase. Accessing keys via the .NET SDK requires using lowercase strings.
Azure Blob Storage does not preserve the original casing of custom metadata keys; all metadata keys are stored and returned in lowercase.
3
Evaluate write operations on leased blobs.
Modifying metadata on a leased blob requires passing the lease ID in the request conditions.
An active write lease prevents any write operations, including metadata updates, unless the specific lease ID is provided.

Key Concept

Blob Metadata Case Sensitivity, Access Tier Management, and Lease Requirements
PreviousPage 48 / 49Next