All practice questions

972 questions

Question 581Question

You are developing a logistics monitoring solution in C# that tracks cargo container shipments. The container data is stored in Azure Cosmos DB. You need to write a method using the Azure Cosmos DB .NET SDK v3 that configures the connection, accesses the database and container, and performs a point read of a shipment item. In which order should you execute the steps to initialize the client and perform the point read?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To perform a point read using the Azure Cosmos DB .NET SDK v3, you must first create and configure the CosmosClientOptions, instantiate the CosmosClient with those options, obtain a Database reference, obtain a Container reference, and finally call ReadItemAsync on the container specifying the item ID and its partition key.
The correct sequence begins with configuring CosmosClientOptions. Next, you instantiate the CosmosClient passing these options. Once the client is active, you navigate down the resource hierarchy by first retrieving the Database object via GetDatabase and then the Container object via GetContainer. Finally, you execute the point read on the Container object using ReadItemAsync with the item ID and partition key.

Step-by-Step Solution

1
Configure client options.
A CosmosClientOptions object is initialized with configurations like preferred regions.
This object is required during the client initialization step if custom settings are needed.
2
Instantiate the CosmosClient.
A thread-safe CosmosClient instance is created to manage connection pooling.
The client is the root object used to interact with the Azure Cosmos DB service.
3
Obtain Database reference.
A Database object is returned.
You must reference the database containing the target container.
4
Obtain Container reference.
A Container object is returned.
Item operations are executed against a specific container, so a container reference is necessary.
5
Perform the point read.
An ItemResponse is returned containing the deserialized shipment item.
ReadItemAsync executes the point read, which requires the item ID and the partition key.

Key Concept

Initializing the Cosmos DB SDK v3 client hierarchy and executing point reads with the Container class.
Question 582Question

You are developing an ASP.NET Core web application hosted on an Azure App Service. The application must retrieve database connection strings from an Azure Key Vault. The security architecture requires that:

1. The application must authenticate to Azure Key Vault without storing any credentials or secrets in code or configuration files.
2. The identity used for authentication must be shared across multiple web applications in the same environment to simplify access control management.

Which configuration should you implement to meet these requirements?

Show answer & explanation

Answer: Create a user-assigned managed identity, assign it the Key Vault Secrets User role on the Key Vault, associate the identity with the App Service, and configure the client ID in the application settings.

Answer

Create a user-assigned managed identity, assign it the Key Vault Secrets User role on the Key Vault, associate the identity with the App Service, and configure the client ID in the application settings.
The correct option is to create a user-assigned managed identity, assign it the Key Vault Secrets User role, associate it with the App Service, and configure the client ID in the settings. This ensures the identity is shared across resources without storing secrets and allows DefaultAzureCredential to resolve the specified identity.

Step-by-Step Solution

1
Determine the type of managed identity that supports sharing across multiple Azure resources.
Identify that user-assigned managed identities are standalone Azure resources that can be shared across multiple App Services, unlike system-assigned managed identities which are tied 1:1 to a single resource.
This satisfies the requirement to share the identity and simplify access control management.
2
Select the correct permission assignment method to allow the identity to read secrets from Key Vault.
Assign the Key Vault Secrets User role to the user-assigned managed identity.
This grants the identity the minimum required permission to retrieve secret values without requiring administrative access.
3
Associate the identity with the App Service and configure the application to target it.
Add the user-assigned identity to the App Service, and set the client ID in the application settings so that DefaultAzureCredential in the code knows which identity to use.
This completes the binding and allows the SDK to resolve the correct token.

Key Concept

User-assigned managed identities allow for shared access across multiple Azure resources with an independent lifecycle from the resource, whereas system-assigned managed identities are restricted to a single resource.
Question 583Question

A development team implements Application Insights monitoring for a .NET 8.0 web API hosted on an Azure App Service using a Premium v3 plan. During testing, the team confirms that the Snapshot Debugger is enabled in the application configuration. However, when developers attempt to open a debug snapshot from an unhandled exception in the Azure portal, they are blocked by an access denied message. The developers already hold the Contributor role at the subscription level. Which of the following actions must be taken to allow the developers to view the debug snapshots?

Show answer & explanation

Answer: Assign the Application Insights Snapshot Debugger Access role to the developers' Microsoft Entra accounts.

Answer

Assign the Application Insights Snapshot Debugger Access role to the developers' Microsoft Entra accounts.
The correct action is to assign the Application Insights Snapshot Debugger Access role to the developers' Microsoft Entra accounts. Azure restricts snapshot visibility because snapshots can capture sensitive personal or proprietary data in local variables during an exception. Even Subscription Owners and Contributors cannot view snapshots by default. They must be explicitly granted the Application Insights Snapshot Debugger Access role.

Step-by-Step Solution

1
Analyze the access requirement for Application Insights Snapshot Debugger snapshots.
Identify that debug snapshots contain sensitive application state, local variables, and memory dumps, requiring specialized access control beyond standard Contributor/Owner roles.
By design, Azure restricts access to snapshot data to protect potentially sensitive information stored in variables at the time of the exception.
2
Identify the specific RBAC role required to view the debug snapshots.
The correct role is the Application Insights Snapshot Debugger Access role.
This built-in role provides the necessary read permissions for Snapshot Debugger telemetry data.
3
Assign the role to the developers' accounts.
Assign the role at either the Subscription, Resource Group, or individual Application Insights resource level.
Role assignments propagate down to the Application Insights instance, granting portal access to the developers.

Key Concept

Snapshot Debugger RBAC Permissions
Question 584Question

An enterprise web application is hosted on a Linux-based Azure App Service. A developer needs to configure built-in application logging to capture standard output (stdout) and standard error (stderr) streams to the local filesystem for temporary debugging, and also stream these logs to an Azure Storage account for long-term retention.

Which of the following configurations must the developer perform? (Select two.)

Select all that apply

Show answer & explanation

Answer: Run the Azure CLI command: az webapp log config --name myApp --resource-group myRG --docker-container-logging filesystem; Configure a Diagnostic Setting on the App Service to send the AppServiceConsoleLogs category to the Azure Storage account.

Answer

The developer must run the Azure CLI command to configure docker container logging to the filesystem and configure a Diagnostic Setting on the App Service to send the AppServiceConsoleLogs category to the Azure Storage account.
For Linux-based Azure App Services, application logs correspond to stdout and stderr streams. These are enabled on the local filesystem using the docker-container-logging filesystem parameter in the Azure CLI. To archive these logs to a storage account, a Diagnostic Setting must be configured to forward the AppServiceConsoleLogs category.

Step-by-Step Solution

1
Enable container-level diagnostic logging on the Linux-based App Service.
Execute the command 'az webapp log config --name myApp --resource-group myRG --docker-container-logging filesystem'.
Linux App Services run applications inside containers where stdout and stderr represent application logs. These are configured using the docker-container-logging parameter.
2
Determine the diagnostic log category for container logs.
Identify 'AppServiceConsoleLogs' as the designated category.
On Linux, console logs are collected under the AppServiceConsoleLogs category, distinct from the Windows-specific AppServiceAppLogs category.
3
Configure the streaming endpoint for long-term retention.
Create a Diagnostic Setting sending 'AppServiceConsoleLogs' to the target Storage account.
Diagnostic settings route the selected log streams to Azure Storage, Event Hubs, or Log Analytics.

Key Concept

Configuring container console logging and diagnostic settings on Linux-based Azure App Service
Question 585Question

You are deploying a custom Webhook endpoint to receive events from an Azure Event Grid custom topic. The solution must use the default Event Grid event schema. To complete the subscription setup, the endpoint must successfully process the automatic, synchronous validation handshake. Which two of the following configuration or code implementation steps must the Webhook endpoint execute to satisfy the Event Grid validation requirements? (Each correct answer presents a part of the solution. Choose two.)

Select all that apply

Show answer & explanation

Answer: Extract the validationCode value from the data payload of the incoming HTTP POST request.; Return an HTTP 200 OK response with a JSON payload containing the validationResponse set to the extracted validation code.

Answer

To complete the Event Grid subscription validation handshake, the Webhook endpoint must extract the validationCode from the incoming event data payload and return it in the JSON response body under the validationResponse property along with an HTTP 200 OK status.
The correct actions require the endpoint to process the incoming HTTP POST request, parse the JSON payload to extract the validationCode, and then reply synchronously with a 200 OK status containing the validationResponse field populated with that code.

Step-by-Step Solution

1
Analyze the incoming request payload to locate the verification request.
Identify that the event contains an eventType value of Microsoft.EventGrid.SubscriptionValidationEvent.
Event Grid identifies validation requests using this specific event type.
2
Parse the payload to retrieve the unique verification token.
Extract the validationCode property from the data object of the event.
This code is dynamically generated by Event Grid and must be returned to verify ownership of the endpoint.
3
Formulate and transmit the synchronous HTTP response.
Return HTTP status code 200 OK with a JSON body mapping validationResponse to the extracted validationCode.
Providing the matching validation code in the response payload completes the handshake.

Key Concept

Event Grid Webhook subscription validation handshake
Question 586Question

An organization is migrating an ASP.NET Core web application to Azure App Service. The application must retrieve a database connection string from Azure Key Vault `kv-prod` using Azure App Configuration. The web application is configured to use a user-assigned managed identity named `id-app-prod`. The Azure Key Vault uses Azure role-based access control (Azure RBAC) for authorization. You need to configure the App Configuration key-vault reference and ensure the App Service web application can retrieve the database connection string. Which two configuration steps must you perform? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure a key-value pair in Azure App Configuration with a value of `@Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn-string)`; Assign the 'Key Vault Secrets User' Azure RBAC role to the user-assigned managed identity `id-app-prod` for the Key Vault `kv-prod`

Answer

Configure a key-value pair in Azure App Configuration with a value using the `@Microsoft.KeyVault(SecretUri=...)` syntax, and assign the 'Key Vault Secrets User' Azure RBAC role to the user-assigned managed identity `id-app-prod` on the Key Vault.
The correct configuration requires using the exact `@Microsoft.KeyVault(SecretUri=...)` syntax in Azure App Configuration so the client provider knows to retrieve the secret value from Azure Key Vault. In addition, because the Key Vault uses Azure RBAC for authorization, the application's user-assigned managed identity must be granted the 'Key Vault Secrets User' role. The client application resolves these references at runtime using its own credentials, not the App Configuration service principal.

Step-by-Step Solution

1
Configure the key-value pair in Azure App Configuration.
The reference uses the prefix `@Microsoft.KeyVault(SecretUri=...)` pointing to the Key Vault secret URI.
This instructs the App Configuration client library to resolve the secret directly from Azure Key Vault.
2
Configure authorization on the Azure Key Vault.
The user-assigned managed identity `id-app-prod` is granted the 'Key Vault Secrets User' role on the vault.
Because the Key Vault uses Azure RBAC, the web app's identity must have read access to the secrets.

Key Concept

Azure App Configuration Key Vault References and Azure RBAC Authorization
Question 587Question

You are developing a daemon application named 'BillingJob' that runs nightly as a background service on an Azure Virtual Machine. The application must query Microsoft Graph to retrieve the profile details of all users in the Microsoft Entra ID tenant to generate monthly billing reports. No user is signed in when the application runs.

You need to configure the permissions for the application registration in Microsoft Entra ID while adhering to the principle of least privilege.

Which configuration should you implement?

Show answer & explanation

Answer: Add the Microsoft Graph User.Read.All Application permission to the application registration, and grant admin consent for the tenant.

Answer

Add the Microsoft Graph User.Read.All Application permission to the application registration, and grant admin consent for the tenant.
Because the application runs as a background daemon service without user interaction, it cannot acquire a user context and must use Application permissions. The User.Read.All permission allows reading full user profiles for all accounts, and because it is an Application permission, it requires tenant administrator consent. This satisfies the requirement using the principle of least privilege.

Step-by-Step Solution

1
Determine the application type and interaction context.
The application runs as a background service (daemon) without any signed-in user.
This establishes that Delegated permissions cannot be used, and Application permissions (app roles) are required.
2
Identify the required data and the corresponding Microsoft Graph permission.
The application needs to read user profile details for all users in the tenant, which maps to the User.Read.All permission.
Using User.Read.All is the most restrictive permission that satisfies the requirement, aligning with the principle of least privilege.
3
Determine the consent requirement for the selected permission.
Application permissions for User.Read.All require administrator consent.
Microsoft Entra ID requires tenant administrator approval for application permissions that access organization-wide directory data.

Key Concept

Daemon applications running without user context must use Application permissions and require admin consent for directory-wide scopes.
Question 588Question

You need to import an Azure Function App as a new API in an existing Azure API Management (APIM) instance using the Azure portal. In which order should you perform the configuration steps?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, navigate to the API Management instance in the Azure portal and open the APIs section. Second, click Add API and choose Function App. Third, browse and select the Function App along with the specific functions. Fourth, configure the API URL suffix and click Create.
The correct sequence begins by navigating to the API Management service in the portal and opening the APIs blade. You then select Add API and choose Function App to configure the integration. Next, you browse and select the specific Function App and its functions. Finally, you set the URL suffix and display name, and click Create to complete the import.

Step-by-Step Solution

1
Open the API Management instance in the Azure portal and click APIs.
Displays the API management workspace.
Before configuring or importing an API, you must navigate to the specific API Management service instance where the API will reside.
2
Select Add API and click Function App.
Initiates the import workflow specifically for Azure Functions.
Choosing the correct resource type tells APIM to read from Azure Function App configurations.
3
Browse for the target Function App and select its functions.
Selects the source functions to be exposed as API operations.
You must map specific backend function endpoints to API operations in APIM.
4
Set the URL suffix and click Create.
Completes the import and publishes the API.
Configuring the URL suffix ensures unique routing for the API within the APIM gateway before creation.

Key Concept

Importing and configuring Azure Functions as APIs in Azure API Management
Question 589Question

You are developing an Azure Durable Functions application in C# using the .NET Isolated worker model. You write the following orchestrator function to manage an order processing workflow:

csharp
[Function("ProcessOrderOrchestrator")]
public static async Task RunOrchestrator(
[OrchestrationTrigger] TaskOrchestrationContext context)
{
var orderId = context.GetInput<string>();

var status = await context.CallActivityAsync<string>("CheckStatus", orderId);

var trackingId = Guid.NewGuid().ToString();

await context.CallActivityAsync("ProcessPayment", new { OrderId = orderId, TrackingId = trackingId });
}

Which line of code in this orchestrator function violates the determinism constraints of Durable Functions?

Show answer & explanation

Answer: var trackingId = Guid.NewGuid().ToString();

Answer

The statement generating the tracking ID using Guid.NewGuid()
The statement `var trackingId = Guid.NewGuid().ToString();` violates the determinism constraints of Durable Functions orchestrator functions. Orchestrator functions must be deterministic because they are replayed from the beginning of the execution history to rebuild the state of the orchestration. Generating a new GUID via `Guid.NewGuid()` produces a different value on every replay, leading to non-deterministic execution paths and runtime errors. Instead, the orchestrator should use `context.NewGuid()` to safely generate a random identifier that yields the same value during replays.

Step-by-Step Solution

1
Analyze the orchestrator function for non-deterministic APIs or operations.
Identify that Guid.NewGuid() is invoked directly in the orchestrator.
Orchestrator functions must be deterministic because their execution is replayed to rebuild state.
2
Identify replay-safe alternatives for generating identifiers in Durable Functions.
The TaskOrchestrationContext provides the NewGuid() API to safely generate GUIDs deterministically during replays.
Using context.NewGuid() allows the framework to return the same GUID during replay, preserving determinism.

Key Concept

Durable Functions Orchestrator Code Constraints and Determinism
Question 590Question

You are configuring an Azure Monitor Action Group to route alert notifications to a secured custom webhook endpoint. The webhook endpoint is secured using Microsoft Entra ID. You need to ensure that the Action Group can successfully authenticate and send alerts to the webhook. Which configuration should you use for the Webhook receiver in the Action Group?

Show answer & explanation

Answer: Enable Microsoft Entra ID authentication in the Webhook receiver settings, and provide the Tenant ID and client Application ID (Object ID) of the target application.

Answer

Enable Microsoft Entra ID authentication in the Webhook receiver settings, and provide the Tenant ID and client Application ID (Object ID) of the target application.
To secure an Action Group Webhook receiver using Microsoft Entra ID, you must enable the Active Directory authorization option and provide the Tenant ID and target Object ID. When the alert fires, Azure Monitor retrieves an Entra ID token and includes it in the Authorization header of the webhook request.

Step-by-Step Solution

1
Open the Action Group configuration in Azure Monitor and add a new action with the action type set to Webhook.
The Webhook receiver configuration pane opens, prompting for a URI and other authorization details.
This initiates the configuration of the webhook target.
2
Enable the 'Use Azure Active Directory auth' (Microsoft Entra ID) option in the configuration.
Input fields for Tenant ID and Application/Object ID become active.
This instructs Azure Monitor to acquire an Entra ID token before sending requests to the webhook.
3
Provide the Tenant ID and client Application ID (Object ID) of the target Entra ID application registration.
The Webhook action is successfully configured with token-based authentication.
These details are required so Azure Monitor can identify the target resource and fetch the correct authentication token.

Key Concept

Action Group Webhook authentication using Microsoft Entra ID
Question 591Question

You are configuring a monitoring solution for an Azure Cosmos DB API for NoSQL account. You need to configure an Azure Monitor alert rule that triggers when client applications receive HTTP status code 429 (Request Rate Too Large) responses. When triggered, the alert must email the operations team and execute an Azure Automation runbook. Which of the following configurations should you implement?

Show answer & explanation

Answer: Create a metric alert rule for the Cosmos DB resource targeting the 'Total Requests' metric, add a dimension filter where 'StatusCode' equals '429', and associate the rule with an action group containing Email and Automation Runbook actions.

Answer

Create a metric alert rule for the Cosmos DB resource targeting the 'Total Requests' metric, add a dimension filter where 'StatusCode' equals '429', and associate the rule with an action group containing Email and Automation Runbook actions.
The correct configuration is to create a metric alert rule targeting the 'Total Requests' metric on the Azure Cosmos DB resource, filter it using the 'StatusCode' dimension set to '429', and trigger an action group containing both Email and Automation Runbook actions. This utilizes native Azure Monitor capabilities to detect rate limiting and execute both notification and remediation steps efficiently.

Step-by-Step Solution

1
Identify the signal type and resource metric to monitor.
Select the 'Total Requests' metric for the Azure Cosmos DB resource.
This metric provides real-time transaction telemetry including response status codes.
2
Configure the alert logic using dimensions.
Add a dimension filter for 'StatusCode' with the value '429'.
This isolates rate-limiting events (Request Rate Too Large) from successful or other error requests.
3
Create and associate an Action Group.
Define an Action Group with an Email receiver for the operations team and an Automation Runbook receiver to scale the throughput.
Action groups allow multi-receiver routing to perform notifications and automated remediation simultaneously.

Key Concept

Azure Monitor Metric Alerts with dimension filters and Action Groups with multiple receivers
Question 592Question

You are developing a secure .NET web application using the `Azure.Storage.Blobs` SDK (v12). The application must generate a Shared Access Signature (SAS) token for an Azure Blob Storage container named `invoices`.

The security requirements are as follows:
- The token must be signed using Microsoft Entra ID credentials (a User Delegation SAS) instead of the storage account key.
- The client must only be allowed to read and list the contents of the container.
- The SAS must restrict access to requests originating from the client IP address range `198.51.100.0/24`.
- The token must enforce the use of HTTPS only.
- The token must account for potential clock skew by setting the start time to 15 minutes before the current time.

You write the following method to generate the SAS token:

csharp
public async Task<string> GenerateContainerSasUriAsync(BlobServiceClient client, string containerName, string accountName)
{
UserDelegationKey delegationKey = await client.GetUserDelegationKeyAsync(
DateTimeOffset.UtcNow.AddMinutes(-15),
DateTimeOffset.UtcNow.AddHours(2)
);

BlobSasBuilder builder = new BlobSasBuilder()
{
BlobContainerName = containerName,
Resource = "c",
StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15),
ExpiresOn = DateTimeOffset.UtcNow.AddHours(2)
};

// INSERT CODE HERE

BlobSasQueryParameters sasParams = builder.ToSasQueryParameters(delegationKey, accountName);
return $"{client.Uri}{containerName}?{sasParams}";
}

Which code segment should you insert to complete the method and meet the requirements?

Show answer & explanation

Answer: builder.SetPermissions(BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List);
builder.Protocol = SasProtocol.Https;
builder.IPRange = IPAddressRange.Parse("198.51.100.0/24");

Answer

The code segment that calls builder.SetPermissions with BlobContainerSasPermissions.Read and BlobContainerSasPermissions.List, configures builder.Protocol to SasProtocol.Https, and parses the correct IP range.
The correct option properly uses BlobContainerSasPermissions.Read | BlobContainerSasPermissions.List to grant both read and list permissions at the container level. It also restricts the communication to HTTPS-only using SasProtocol.Https and parses the IP range correctly using IPAddressRange.Parse.

Step-by-Step Solution

1
Select the correct permission enum class for the target resource level.
BlobContainerSasPermissions must be used because the SAS applies to a container (Resource = "c") and requires the List permission, which is not available in the blob-specific BlobSasPermissions class.
Ensures compilation succeeds and scope constraints match the container level.
2
Enforce the security protocol configuration.
builder.Protocol must be explicitly set to SasProtocol.Https.
By default, a SAS might allow both HTTP and HTTPS (HttpsAndHttp). Enforcing HTTPS-only mitigates data transit intercept risks.
3
Restrict request origins using IP filtering.
Assign IPAddressRange.Parse("198.51.100.0/24") to builder.IPRange.
This limits token usage strictly to the defined client subnet.

Key Concept

Configuring Container-scoped User Delegation Shared Access Signatures using Azure.Storage.Blobs SDK
Estimated Time:2m 30s
Question 593Question

A library book reservation system uses an Azure Service Bus queue to manage user reservation requests. The reservation system must process each request reliably. If a worker instance fails or restarts while processing a request, the request message must not be lost and must become available again in the queue so that another worker can pick it up.

Which option or method should you configure for the Service Bus receiver to satisfy this requirement?

Show answer & explanation

Answer: ServiceBusReceiveMode.PeekLock

Answer

ServiceBusReceiveMode.PeekLock
The correct option is ServiceBusReceiveMode.PeekLock because it locks the message when retrieved, allowing the receiver to complete the processing. If the processing fails or the client crashes, the lock expires and the message is returned to the queue, ensuring no messages are lost.

Step-by-Step Solution

1
Analyze the requirements for message processing reliability.
The application requires that a message must not be lost if a processing worker fails or restarts.
This tells us that a mechanism is needed to keep the message locked or in the queue until processing is explicitly confirmed as successful.
2
Evaluate the available receive modes and methods in Azure Service Bus.
ServiceBusReceiveMode.PeekLock locks the message on receipt without deleting it. ServiceBusReceiveMode.ReceiveAndDelete deletes the message immediately.
We must choose a mode that keeps the message in the queue during processing.
3
Select the correct mode based on the analysis.
ServiceBusReceiveMode.PeekLock is the correct mode because it prevents message loss by holding the message in a locked state until completed.
If the worker crashes, the lock will time out and the message will automatically become available for other workers again.

Key Concept

Azure Service Bus Receive Modes
Question 594Question

You are designing a security architecture for three Azure Function apps that must retrieve database connection secrets from a single Azure Key Vault. The solution must use managed identities, minimize administrative overhead, and grant only the minimum permissions required to read the secrets.

Which two configuration steps should you perform?

Select all that apply

Show answer & explanation

Answer: Create a single user-assigned managed identity and associate its resource ID with all three Function apps using the userAssignedIdentities configuration property.; Assign the Key Vault Secrets User role to the user-assigned managed identity at the Key Vault scope.

Answer

To implement the solution, you should create a single user-assigned managed identity, associate its resource ID with all three Function apps, and assign the Key Vault Secrets User role to this identity at the Key Vault scope.
A user-assigned managed identity is a standalone Azure resource with its own lifecycle. Because it is independent, it can be shared across multiple resources like the three Function apps. This reduces overhead since we only need to manage a single identity and configure permissions once on the Key Vault. The Key Vault Secrets User role is the minimum role required to retrieve the secret values.

Step-by-Step Solution

1
Determine the identity type that minimizes overhead for sharing access.
Select a user-assigned managed identity since it can be shared among multiple Function apps, requiring only one RBAC role assignment instead of three.
System-assigned identities cannot be shared across resources, which would lead to duplicate role assignments and increased management overhead.
2
Identify the minimum required RBAC role for reading secrets.
Select the Key Vault Secrets User role.
This role allows the identity to read secret values without granting permissions to manage the Key Vault itself.
3
Assign the selected role to the identity.
The user-assigned managed identity is granted Key Vault Secrets User access at the scope of the Key Vault.
This establishes authorization for the shared identity to pull database secrets securely.

Key Concept

User-Assigned Managed Identities and Least-Privilege RBAC Roles
Question 595Question

You are implementing an Azure Durable Functions workflow in C# to handle a human approval process with a 2424-hour escalation timeout. Order the steps in the sequence they occur during a successful execution where a manager approves the request within the 2424-hour window.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of events is: the orchestrator sets up the timer and event listener tasks, yields execution using Task.WhenAny to persist state, receives the external event raised by the client function, wakes up to replay history and cancel the timer, and finally executes the activity to process the decision.
The correct sequence begins with the orchestrator defining the approval notification and wait tasks. Next, it yields control by awaiting Task.WhenAny, which saves state. A client function then raises the event using the orchestration client. The orchestrator wakes up, replays state to recognize the event completion, cancels the timer, and finally executes the final approval activity.

Step-by-Step Solution

1
Identify the initialization step of the Human Interaction pattern in the orchestrator.
The orchestrator initiates tasks for both the event listener (WaitForExternalEvent) and the escalation timer (CreateTimer).
Both tasks must be defined before the orchestrator can wait on them.
2
Identify how the orchestrator pauses execution while waiting for either event to complete.
The orchestrator awaits Task.WhenAny on the timer and event tasks, yielding control and saving state.
Awaiting Task.WhenAny prevents active blocking and ensures the current state is saved to storage.
3
Determine the mechanism by which the orchestrator is notified of user approval.
An external client function calls RaiseEventAsync with the decision.
Since the orchestrator is asleep, an external process must push the event to resume execution.
4
Analyze the behavior of the orchestrator upon receiving the event.
The orchestrator wakes up, replays its history to restore state, evaluates the completed event, and cancels the timer.
Replaying history ensures the orchestrator rebuilds state deterministically, and canceling the timer avoids unnecessary escalation.
5
Determine the final step in the workflow.
The orchestrator executes the activity to process the decision and completes.
The workflow logic is finished once the final processing activity completes.

Key Concept

Orchestrating human interaction patterns and managing state lifecycle in Azure Durable Functions
Estimated Time:1m 30s
Question 596Question

You are developing a C# daemon application that runs on an Azure Virtual Machine. The application must automate the renewal of an Azure Key Vault certificate named 'ssl-cert' which is issued by a non-integrated internal Certificate Authority (CA).

The application must run under a user-assigned managed identity named 'app-identity'. The renewal workflow requires:
1. Retrieving the pending Certificate Signing Request (CSR) generated by Key Vault.
2. Submitting the CSR to the CA and receiving the signed certificate.
3. Merging the signed certificate back into Key Vault to complete the process.

You need to configure the required permissions and implement the code using the Azure.Security.KeyVault.Certificates library.

Which of the following configurations and code segments should you implement?

Show answer & explanation

Answer: Assign the 'app-identity' to the Virtual Machine and grant it the Key Vault Certificates Officer Azure RBAC role. Use the following C# code:

var client = new CertificateClient(new Uri("https://vault.vault.azure.net/"), new DefaultAzureCredential());
CertificateOperation operation = await client.GetCertificateOperationAsync("ssl-cert");
byte[] csr = operation.Csr;
// Submit to CA and receive signedCertBytes
await client.MergeCertificateAsync(new MergeCertificateOptions("ssl-cert", new[] { signedCertBytes }));

Answer

To perform certificate operations such as retrieving pending operations and merging certificates in Azure Key Vault, the application identity must possess certificate permissions (like the Key Vault Certificates Officer Azure RBAC role) rather than secret permissions. Furthermore, the user-assigned managed identity must be associated with the virtual machine hosting the application. The Azure.Security.KeyVault.Certificates SDK requires using GetCertificateOperationAsync to access the pending CSR and MergeCertificateAsync to upload the signed public certificate.
To complete the renewal of a certificate from a non-integrated CA, the application must fetch the pending CSR using GetCertificateOperationAsync, sign it at the CA, and then call MergeCertificateAsync to combine the signed certificate with the private key stored in Key Vault. Additionally, the user-assigned managed identity must be associated with the VM and granted the Key Vault Certificates Officer role to authorize the action.

Step-by-Step Solution

1
Ensure the user-assigned managed identity is attached to the Virtual Machine hosting the application.
The Virtual Machine environment can retrieve Azure AD tokens on behalf of the user-assigned managed identity.
DefaultAzureCredential attempts to acquire a token using the associated identities on the hosting environment.
2
Grant the user-assigned managed identity the 'Key Vault Certificates Officer' role (or appropriate certificate-level Access Policy permissions).
The identity is authorized to get certificate operations and merge certificates.
Secrets permissions do not authorize certificate lifecycle management actions.
3
Use GetCertificateOperationAsync to retrieve the pending CSR.
A CertificateOperation object containing the DER-encoded CSR is retrieved.
Key Vault generates the CSR and retains the private key during the initial certificate creation stage.
4
Use MergeCertificateAsync to upload the signed certificate from the CA.
The signed public key is combined with the private key stored inside Key Vault, completing the certificate.
For non-integrated CAs, merging completes the pending renewal process.

Key Concept

Azure Key Vault Certificate Lifecycle and Renewal for Non-Integrated CAs
Question 597Question

You are developing a C# application using the Azure.Storage.Blobs SDK (version 12) to update the metadata and change the access tier of an existing block blob. The blob is currently leased under the lease ID 5e2b834b-74d1-4e0d-b8d2-5a210d7a04bc. You must set a custom metadata tag Project to Delta and change the blob's access tier to Cool. Which C# code snippet should you use to successfully perform these operations?

Show answer & explanation

Answer: var metadata = new Dictionary<string, string> { { "Project", "Delta" } };
var conditions = new BlobRequestConditions { LeaseId = "5e2b834b-74d1-4e0d-b8d2-5a210d7a04bc" };

await blobClient.SetMetadataAsync(metadata, conditions);
await blobClient.SetAccessTierAsync(AccessTier.Cool, conditions: conditions);

Answer

The correct option sets the custom metadata key without the standard prefix, instantiates the request conditions with the active lease ID, and passes those conditions to both SetMetadataAsync and SetAccessTierAsync.
The correct snippet successfully updates the metadata and changes the access tier because it passes the active lease ID inside the BlobRequestConditions to both asynchronous write calls. It also defines the custom metadata key without the x-ms-meta- prefix, allowing the SDK to handle the header prefixing automatically.

Step-by-Step Solution

1
Define the metadata dictionary containing the target key-value pairs without manual prefixes.
A dictionary is created containing the key 'Project' with the value 'Delta'.
The Azure Storage SDK handles HTTP header prefixing (x-ms-meta-) automatically, so manual prefixes must be omitted.
2
Instantiate BlobRequestConditions containing the active lease ID.
A request conditions instance is initialized with the LeaseId property set to '5e2b834b-74d1-4e0d-b8d2-5a210d7a04bc'.
Since the blob has an active lease, all write operations require the lease ID to verify write authorization.
3
Invoke SetMetadataAsync and SetAccessTierAsync sequentially, passing the request conditions containing the lease ID to both methods.
The metadata is successfully updated and the access tier is changed on the leased blob without raising concurrency exceptions.
Both methods represent write operations on the blob resource and will fail with a 412 (Precondition Failed) status code if the lease conditions are omitted.

Key Concept

To modify the metadata or change the access tier of a leased blob, write operations must include the active lease ID via BlobRequestConditions. Custom metadata keys must be defined without the 'x-ms-meta-' header prefix as the SDK applies it automatically.
Question 598Question

An organization is implementing a client-side Single Page Application (SPA) named ClientConnect. The application must authenticate users using Microsoft Entra ID and access a secure downstream web API named DataAPI on behalf of the signed-in user. The DataAPI exposes a custom scope named Data.Write.

You register both ClientConnect and DataAPI in Microsoft Entra ID.

Which two configuration steps should you perform in Microsoft Entra ID to implement the required permissions and consent? Select two.

Select all that apply

Show answer & explanation

Answer: In the App Registration for ClientConnect, add the custom scope Data.Write from DataAPI as a Delegated permission.; In the App Registration for DataAPI, define the custom scope Data.Write under the Expose an API section.

Answer

In the App Registration for ClientConnect, add the custom scope Data.Write from DataAPI as a Delegated permission; and in the App Registration for DataAPI, define the custom scope Data.Write under the Expose an API section.
To access the custom downstream web API on behalf of a signed-in user, two configurations must be met: First, the target web API (DataAPI) must expose the scope by defining it in the Expose an API section. Second, the client application (ClientConnect) must request access by adding that scope as a Delegated permission. This maintains the user context flow.

Step-by-Step Solution

1
Expose the custom scope in the downstream API registration.
The Data.Write scope is defined in the registration of DataAPI, allowing other applications to request it.
Before a client can request permissions for a custom API, the API must explicitly declare the scopes it supports.
2
Add the exposed scope as a Delegated permission to the client application registration.
ClientConnect is configured with a delegated permission to request Data.Write on behalf of the signed-in user.
Since ClientConnect is a Single Page Application running in the context of the user, it requires delegated permissions to act on the user's behalf.

Key Concept

Delegated permissions and custom API scopes in Microsoft Entra ID
Question 599Question

You are deploying an Azure Container App named `payment-processor` that needs to securely access a database connection string stored in an Azure Key Vault named `kv-vault`.

You want the Container App to authenticate to the Key Vault using a system-assigned managed identity and expose the secret to the application container as an environment variable named `DB_CONNECTION`.

Which four actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, enable a system-assigned managed identity on the `payment-processor` Container App. Second, in the Azure Key Vault `kv-vault`, assign the Key Vault Secrets User role to the Container App's managed identity principal. Third, add a secret named `db-secret` to the Container App that references the Azure Key Vault secret URI. Fourth, update the container configuration of the Container App to map the environment variable `DB_CONNECTION` to the `db-secret` secret.
To secure secrets in an Azure Container App using Key Vault, the application must first have an identity. Enabling the system-assigned managed identity creates a principal in Microsoft Entra ID. Next, this identity must be granted the Key Vault Secrets User role so that the Container App is authorized to read the secret. Once authorized, the secret is mapped at the Container App resource level using the Key Vault secret URI. Finally, the container template within the Container App references this App-level secret to expose it as an environment variable to the application code.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the Container App.
A service principal representing the Container App is created in Microsoft Entra ID.
An identity must exist before you can assign roles or permissions to it.
2
Assign the Key Vault Secrets User role to the system-assigned managed identity on the Key Vault.
The identity principal is granted permission to read secret values.
The Container App environment must be authorized to pull secret values from Key Vault at runtime.
3
Create a secret at the Container App level that references the Key Vault secret URI.
A secret reference is registered in the Container App environment.
Container Apps act as the secure store that bridges the Key Vault secret and the application container.
4
Map the Container App secret to the container's environment variable.
The container configuration is updated with the environment variable definition.
This injects the decrypted secret value into the container's environment space.

Key Concept

Configuring Key Vault Secret References in Azure Container Apps using Managed Identities

Alternative Method

You can also perform this configuration using a Bicep template by defining the identity block, setting up the Microsoft.Authorization/roleAssignments resource, defining the secrets array in the container app resource, and referencing the secret in the env block of the container definition.
Estimated Time:2m 0s
Question 600Question

You need to secure static content delivered via an Azure CDN endpoint by configuring a custom domain named `media.contoso.com` with HTTPS. You want to use a free certificate managed by Azure CDN. Which sequence of actions must you perform to configure the custom domain and enable HTTPS? Arrange the steps in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure and secure a custom domain with an Azure CDN-managed certificate, you must first create a DNS CNAME record mapping the custom domain to your CDN endpoint hostname. Then, add the custom domain to the CDN endpoint in the Azure portal. Next, enable HTTPS on the custom domain, select CDN-managed certificate type, and save the settings. Finally, wait for the domain validation, certificate provisioning, and global propagation steps to complete.
The correct sequence begins with establishing the DNS CNAME record so that Azure CDN's domain ownership validation succeeds when adding the custom domain. After adding the domain, HTTPS can be enabled. Setting the certificate management type to CDN-managed allows Azure to handle the certificate lifecycle. The final phase involves waiting for the automated validation, certificate issuance, and edge replication to complete.

Step-by-Step Solution

1
Create a DNS CNAME record.
The custom domain points to the CDN endpoint hostname.
Azure CDN requires the CNAME record to exist to validate domain ownership when adding the custom domain, preventing unauthorized domain associations.
2
Add the custom domain to the CDN endpoint in the Azure Portal.
The custom domain is registered with the CDN endpoint.
Enabling HTTPS requires the custom domain to be linked to the endpoint first.
3
Enable the HTTPS feature on the custom domain.
The HTTPS configuration panel is opened.
This begins the security provisioning process for the domain.
4
Select the CDN-managed certificate management type.
Azure CDN is authorized to request and manage the SSL certificate.
Allows Azure CDN to handle the certificate lifecycle without user intervention.
5
Wait for validation, provisioning, and propagation.
The HTTPS status transitions to Enabled and traffic is secured.
DNS propagation and certificate deployment across edge POPs takes time to complete.

Key Concept

Configuring custom domains and enabling CDN-managed HTTPS on Azure CDN endpoints.
Estimated Time:2m 0s
PreviousPage 30 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin