All practice questions

972 questions

Question 481Question

You are developing a secure C# application using the `Azure.Storage.Blobs` SDK. The application must generate a Shared Access Signature (SAS) token that allows external clients to upload a single PDF file named `confidential.pdf` to a container named `secure-docs` in an Azure Storage account named `corpdata`.

Your application must comply with the following security and operational constraints:
- Authentication: Storage account access keys must not be used, stored, or referenced by the application. You must authenticate using the application's system-assigned managed identity.
- Permissions: The token must grant only write permissions to the specific blob. No read, delete, or list permissions should be granted.
- Protocol: Connections must be restricted to HTTPS only.
- Network Constraints: The token must only be usable from the client's public IP address `198.51.100.72198.51.100.72`.
- Validity: The token must be valid for exactly `3030` minutes from generation.
- Reliability: The token must be usable immediately upon receipt by the client, without failing due to potential clock synchronization differences (clock skew) between servers.

Which of the following C# code segments should you use to generate the SAS token?

Show answer & explanation

Answer: var credential = new DefaultAzureCredential();
var blobServiceClient = new BlobServiceClient(
new Uri("https://corpdata.blob.core.windows.net"), credential);

UserDelegationKey delegationKey = await blobServiceClient.GetUserDelegationKeyAsync(
startsOn: DateTimeOffset.UtcNow.AddMinutes(-15),
expiresOn: DateTimeOffset.UtcNow.AddMinutes(45)
);

var sasBuilder = new BlobSasBuilder()
{
BlobContainerName = "secure-docs",
BlobName = "confidential.pdf",
Resource = "b",
StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15),
ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(30),
Protocol = SasProtocol.Https,
IPRange = SasIPRange.Parse("198.51.100.72")
};
sasBuilder.SetPermissions(BlobSasPermissions.Write);

string sasToken = sasBuilder.ToSasQueryParameters(delegationKey, "corpdata").ToString();

Answer

The code segment that uses DefaultAzureCredential to retrieve a UserDelegationKey, sets the start time in the past to allow for clock skew, restricts the protocol to HTTPS, limits the scope to the specific blob resource, and signs the token with the delegation key.
The correct code segment uses DefaultAzureCredential to obtain a UserDelegationKey from Azure Active Directory, complying with the requirement to avoid account keys. It sets the scope specifically to the blob resource by assigning Resource to 'b' and specifying the BlobName. It handles clock skew by setting the start time to 15 minutes in the past, ensures HTTPS-only connections, and limits access to the specified client IP range.

Step-by-Step Solution

1
Identify the authentication requirement.
Managed Identity authentication must be used.
Storage account access keys are forbidden by the security policy.
2
Select the correct SAS type.
User Delegation SAS.
A User Delegation SAS is secured using Azure Active Directory credentials rather than storage account keys.
3
Configure the resource scope.
Set BlobName to 'confidential.pdf' and Resource to 'b'.
Least-privilege requires limiting access to the specific blob, not the entire container.
4
Configure protocol, network, and clock skew properties.
Set Protocol to Https, IPRange to the client's IP, and StartsOn with a negative offset.
Connections must be HTTPS-only, restricted to the client's IP, and a negative offset on StartsOn allows for clock skew so the token is usable immediately.
5
Sign and generate the SAS token.
Call ToSasQueryParameters passing the UserDelegationKey.
The token must be signed using the obtained delegation key to be authorized.

Key Concept

Shared Access Signatures (SAS) allow for secure, delegated access to Azure Storage resources. A User Delegation SAS is secured using Azure AD credentials. For security and reliability, SAS tokens must implement least-privilege, enforce HTTPS, restrict IP ranges, and subtract a brief duration from the start time to mitigate clock skew issues.
Question 482Question

A developer is implementing a partner integration service that authenticates users across several external enterprise clients using Microsoft Entra ID. The configuration must allow sign-ins from any corporate directory but must explicitly block users signing in with personal Microsoft accounts.

Which combination of the `signInAudience` value in the application manifest and the OAuth 2.0 authorization endpoint must be configured?

Show answer & explanation

Answer: Set `signInAudience` to `AzureADMultipleOrgs` and use the `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize` endpoint.

Answer

Set `signInAudience` to `AzureADMultipleOrgs` and use the `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize` endpoint.
The correct configuration is to set `signInAudience` to `AzureADMultipleOrgs` and use the `/organizations` endpoint. The `AzureADMultipleOrgs` value limits the sign-in audience to work or school accounts from any Microsoft Entra ID tenant, excluding personal accounts. Using the `/organizations` endpoint ensures that the authentication flow restricts user discovery and entry to organizational directories only.

Step-by-Step Solution

1
Determine the required user audience restriction
Identify that only organizational (work or school) accounts are allowed, and personal Microsoft accounts must be blocked.
This requirement dictates the choice of the `signInAudience` value in the application registration.
2
Select the correct `signInAudience` parameter
Configure `signInAudience` to `AzureADMultipleOrgs`.
This setting allows users from any organizational Microsoft Entra ID tenant while excluding personal Microsoft accounts.
3
Select the corresponding authority endpoint for authentication
Use the `/organizations` endpoint: `https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize`.
The `/organizations` endpoint restricts sign-in attempts to organizational tenants only. The `/common` endpoint would allow personal accounts to attempt to sign in, which does not satisfy the requirement to block them at the endpoint level.

Key Concept

Configuring multi-tenant Microsoft Entra ID application registration properties and authority endpoints to control user sign-in audience.
Question 483Question

A developer needs to host a backend service named `payment-worker` on Azure Container Apps. The container image is stored in a private Azure Container Registry (ACR) named `payreg.azurecr.io`. To secure the deployment, the developer wants to avoid hardcoding registry credentials and instead use a managed identity to authenticate the image pull. The solution must support the initial deployment creation of the Container App. Which identity type must be configured for the container app to authenticate the registry pull, and what is the minimum required Azure role-based access control (RBAC) role that must be assigned to the identity on the ACR?

Show answer & explanation

Answer: A user-assigned managed identity, with the AcrPull role assigned to the identity on the Azure Container Registry.

Answer

A user-assigned managed identity, with the AcrPull role assigned to the identity on the Azure Container Registry.
For the initial creation and deployment of an Azure Container App that pulls an image from a private Azure Container Registry (ACR), a user-assigned managed identity must be used. Since a system-assigned managed identity is only created after the container app resource itself has been provisioned, it is not available to authenticate the initial image pull. Furthermore, the identity requires the AcrPull role on the ACR to read and download the container image.

Step-by-Step Solution

1
Determine the availability of managed identities during the container app resource lifecycle.
A system-assigned managed identity is only created after the container app resource has been successfully provisioned. A user-assigned managed identity is created beforehand and can be referenced during the initial creation.
Since the container app must pull the container image from the private registry during its initial creation, the system-assigned identity does not yet exist to authenticate the pull. Therefore, a user-assigned managed identity must be used.
2
Identify the minimum required RBAC role on the Azure Container Registry (ACR) for pulling images.
The AcrPull role provides read access to the container registry data plane, allowing container images to be pulled.
The Reader role only grants metadata access (control plane) and does not permit pulling image data. The AcrPush role allows writing data, which violates the principle of least privilege.

Key Concept

Configuring private registry authentication for Azure Container Apps using managed identities
Question 484Question

You are configuring diagnostic logging for a .NET web application hosted on a Windows-based Azure App Service. You need to capture application trace messages directly to the local filesystem of the App Service for immediate, short-term troubleshooting without utilizing external Azure storage resources or external SDK dependencies. Which of the following describes the behavior of enabling Application Logging (Filesystem) in this scenario?

Show answer & explanation

Answer: The filesystem application logging setting is automatically disabled by Azure 12 hours after it is enabled.

Answer

The filesystem application logging setting is automatically disabled by Azure 12 hours after it is enabled.
The correct answer is correct because Azure automatically disables filesystem application logging for Windows-based App Services 12 hours after enabling it. This behavior prevents the App Service instance's local storage from filling up with log files over time.

Step-by-Step Solution

1
Understand the requirements of the scenario, which specifies capturing trace messages directly to the local filesystem of a Windows-based App Service without external storage or SDK configurations.
Identify that the built-in Application Logging (Filesystem) feature fits these criteria.
This feature writes standard trace output directly to the local virtual file system of the App Service instance.
2
Recall the key behaviors of App Service diagnostic logging.
Understand that filesystem-based application logging on Windows App Services is intended purely for temporary troubleshooting and has an automatic cleanup mechanism.
Azure enforces this to prevent diagnostic logs from exhausting the available local disk space on the App Service VMs.
3
Select the correct option that reflects this built-in constraint.
Determine that the setting is automatically turned off by Azure after 12 hours.
This matches standard Azure App Service behavior for Windows-based instances.

Key Concept

App Service Filesystem Application Logging Behavior and Limits
Estimated Time:1m 30s
Question 485Question

You are configuring an ASP.NET Core web application hosted on an Azure App Service to retrieve data from an Azure SQL Database. The application must authenticate using a user-assigned managed identity. You need to configure the required identity and database access. Which five actions should you perform in sequence? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure a user-assigned managed identity for an Azure App Service to access Azure SQL Database, the correct sequence of actions is: 1. Create a user-assigned managed identity in Microsoft Entra ID. 2. Associate the user-assigned managed identity with the Azure App Service web app. 3. Connect to the Azure SQL Database by using a Microsoft Entra ID administrator account. 4. Run the SQL command to create a database user mapped to the user-assigned managed identity. 5. Run the SQL command to add the database user to the db_datareader role.
The correct sequence starts with creating the user-assigned managed identity and associating it with the App Service web app. Next, you must connect to the Azure SQL Database using a Microsoft Entra ID administrator account to have the necessary privileges to provision external users. Inside the SQL Database, you run a SQL query to create a user mapped to the managed identity, and finally run another query to add that user to the db_datareader role to grant the application access.

Step-by-Step Solution

1
Create the user-assigned managed identity
The identity exists in Microsoft Entra ID and has a unique client ID and principal ID.
An identity must exist before it can be assigned to resources or referenced in permissions.
2
Associate the user-assigned managed identity with the App Service
The App Service is configured to use the identity for outbound authentications.
This allows the application hosted on the App Service to request access tokens for this identity.
3
Connect to Azure SQL Database using a Microsoft Entra ID administrator
Established database connection with administrative privileges capable of creating Entra-based users.
Standard SQL logins do not have permissions to query Microsoft Entra ID to validate and create database users from external providers.
4
Create a SQL database user mapped to the managed identity
A database user represents the managed identity within the database context.
A database user is required to grant database-level permissions to the identity.
5
Grant the database user the db_datareader role
The database user is added to the role, giving it read access.
This authorizes the identity to read data from the database.

Key Concept

Provisioning, assigning, and authorizing a user-assigned managed identity to access Azure SQL Database
Question 486Question

An organization needs to allow a partner application to read data from a specific Azure Blob Storage container named `reports`. You must configure a Shared Access Signature (SAS) token that meets the following security requirements:

- Allows read-only (least-privilege) access to the `reports` container only.
- Restricts access to a specific external IP address range: 198.51.100.0/24198.51.100.0/24.
- Restricts communication to the HTTPS protocol only.
- Begins validity immediately and expires in exactly 22 hours.
- Uses Microsoft Entra ID credentials to secure and sign the token, avoiding the use of the storage account key.

Which type of Shared Access Signature (SAS) must you generate?

Show answer & explanation

Answer: User Delegation SAS

Answer

User Delegation SAS
The correct answer is the User Delegation SAS. A User Delegation SAS is signed with Microsoft Entra ID credentials rather than the storage account key. It utilizes a user delegation key obtained from the Microsoft Entra ID token to sign the SAS, providing enhanced security and auditing capability while satisfying the constraint to restrict access to a single container with specific IP ranges, protocols, and lifetime bounds.

Step-by-Step Solution

1
Identify the signing credential constraint from the requirements.
The SAS token must be secured and signed using Microsoft Entra ID credentials instead of the storage account access key.
This is a key security differentiator among Azure Storage SAS types.
2
Evaluate the signing mechanism for each SAS type.
Service SAS and Account SAS are signed using storage account access keys. User Delegation SAS is signed using a user delegation key acquired via Microsoft Entra ID.
To determine which token type matches the signing constraint.
3
Select the token type that matches all requirements, including container-level scope.
A User Delegation SAS supports container-level scope, HTTPS restriction, IP filters, and is signed using Microsoft Entra ID credentials.
It fulfills all the specified security and protocol requirements.

Key Concept

Selecting the correct type of Shared Access Signature based on credentials and scope requirements
Question 487Question

You are setting up monitoring for a .NET web application hosted on Azure App Service. You want to implement Application Insights to proactively alert you to potential performance anomalies using Smart Detection, identify execution hot paths using Profiler, and collect debug state for unhandled exceptions using Snapshot Debugger. However, you notice that the Application Insights dashboard is not receiving any telemetry data from the web application. Which configuration requirement must you complete to enable the application to send telemetry to Application Insights?

Show answer & explanation

Answer: Add the APPLICATIONINSIGHTS_CONNECTION_STRING setting to the App Service application settings.

Answer

Add the APPLICATIONINSIGHTS_CONNECTION_STRING setting to the App Service application settings.
To send telemetry to Application Insights, the application must be configured with a valid connection string (specifically via the APPLICATIONINSIGHTS_CONNECTION_STRING application setting in Azure App Service). This provides the SDK with the target endpoint and authentication details needed to upload logs, traces, and metrics.

Step-by-Step Solution

1
Identify that the application cannot send telemetry because it lacks the endpoint information required by the SDK.
Determine that a connection configuration setting must be established.
The Application Insights SDK requires a valid connection string to locate, route, and authenticate telemetry data to the target Azure resource.
2
Add the APPLICATIONINSIGHTS_CONNECTION_STRING app setting within the Azure App Service configuration.
The application runtime detects the environment variable and establishes a connection to the telemetry ingestion endpoint.
App Service settings are exposed as environment variables, which the Application Insights SDK automatically reads at startup.

Key Concept

Application Insights SDK Connection Configuration
Question 488Question

You are developing a C# console application that uses the Azure.Storage.Blobs SDK (v12). The application retrieves properties for a blob container that has a custom metadata key named `Owner` set to `DevOps`.

You execute the following code to retrieve the container properties:
csharp
var containerClient = new BlobContainerClient(connectionString, "production-logs");
var properties = await containerClient.GetPropertiesAsync();

You need to extract the value of the `Owner` metadata field both directly from the SDK properties dictionary and from the raw HTTP headers.

Which two code segments should you use?

Select all that apply

Show answer & explanation

Answer: properties.Value.Metadata["Owner"]; properties.GetRawResponse().Headers.TryGetValue("x-ms-meta-owner", out string value)

Answer

To retrieve the metadata value using the properties dictionary, access the key directly without the prefix, such as properties.Value.Metadata["Owner"]. To retrieve the metadata from the raw HTTP response headers, search using the full prefix, such as properties.GetRawResponse().Headers.TryGetValue("x-ms-meta-owner", out string value).
When retrieving custom metadata via the C# SDK, the Azure.Storage.Blobs SDK maps HTTP headers starting with x-ms-meta- into the Metadata dictionary and removes the prefix. Therefore, properties.Value.Metadata["Owner"] correctly retrieves the metadata. Conversely, when inspecting raw HTTP response headers directly via the Response object, you bypass this parsing step and must query the exact HTTP header name, which is x-ms-meta-owner.

Step-by-Step Solution

1
Retrieve the container properties asynchronously from the Azure Blob Storage service.
You obtain a Response<BlobContainerProperties> object containing the properties and the raw HTTP response headers.
Before inspecting metadata, you must execute a call to the storage service to get the latest metadata attributes.
2
Query the custom metadata via the SDK dictionary.
The SDK strips the x-ms-meta- prefix from the HTTP headers, mapping the keys directly. You retrieve the value using the key "Owner".
The SDK provides a parsed, user-friendly Metadata dictionary where the HTTP header prefix is omitted.
3
Query the custom metadata via the raw HTTP response headers.
The raw headers contain the key prefixed as x-ms-meta-owner. You lookup this header using TryGetValue.
Accessing raw headers bypasses SDK stripping, requiring the full HTTP header representation as returned by the REST API.

Key Concept

Understanding how the Azure Blob Storage SDK exposes custom metadata keys vs. how they are represented in raw HTTP response headers.
Question 489Question

An organization hosting a containerized API on Azure App Service (webapp-prod) needs to access database connection strings stored in Azure Key Vault (kv-prod). The Key Vault uses the Azure Role-Based Access Control (Azure RBAC) permission model. To comply with security policies, the API must authenticate using a user-assigned managed identity named id-prod instead of a system-assigned identity. Which three actions should you perform to configure the application and Key Vault to retrieve the secrets using the user-assigned managed identity? (Select three.)

Select all that apply

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the id-prod managed identity at the key vault scope.; Associate the id-prod managed identity with webapp-prod by adding it to the App Service's identity configuration.; Set the keyVaultReferenceIdentity property of webapp-prod to the Resource ID of id-prod.

Answer

To configure Key Vault secret retrieval using a user-assigned identity, you must assign the Key Vault Secrets User role to the identity, associate the identity with the App Service, and set the keyVaultReferenceIdentity property of the App Service to the identity's Resource ID.
To retrieve secrets from a Key Vault configured with Azure RBAC using a user-assigned managed identity, you must first assign the Key Vault Secrets User role to the identity to grant data plane read access. Second, you must associate the user-assigned identity with the App Service so that the host environment can access the identity. Finally, you must configure the App Service to use this specific identity for resolving Key Vault references by setting the keyVaultReferenceIdentity property to the Azure Resource Manager (ARM) Resource ID of the identity.

Step-by-Step Solution

1
Assign the appropriate Azure RBAC role to the managed identity.
The user-assigned identity id-prod is granted the Key Vault Secrets User role.
Key Vault RBAC separates management plane roles from data plane roles. The identity needs data plane permissions to retrieve secret values.
2
Associate the user-assigned identity with the App Service web app.
The App Service is configured to load and present the id-prod identity during credential requests.
An App Service cannot use a user-assigned managed identity until the identity is explicitly added to the app's resource configuration.
3
Configure Key Vault references to use the user-assigned identity.
The keyVaultReferenceIdentity App Service property is set to the Resource ID of id-prod.
By default, App Service Key Vault references use the system-assigned managed identity. To use a user-assigned identity, the app must be instructed which identity to use via its Resource ID.

Key Concept

Azure Key Vault Secret Management with Azure RBAC and User-Assigned Managed Identity
Question 490Question

A Python-based background worker runs in an Azure Function App named func-worker-prod. The Function App needs to retrieve a database password from an Azure Key Vault named kv-secrets-prod.

You configure a user-assigned managed identity named id-worker-prod for the Function App and grant it the Key Vault Secrets User role on kv-secrets-prod. The DbPassword application setting in the Function App is currently configured as follows:

@KeyVault(SecretUri=https://kv-secrets-prod.vault.azure.net/secrets/db-password)

At runtime, the Python worker reads the DbPassword environment variable as the plain text reference string rather than the actual secret value. Which two configuration updates must you perform to ensure the Key Vault reference resolves correctly?

Select all that apply

Show answer & explanation

Answer: Create a new application setting named keyVaultReferenceIdentity and set its value to the resource ID of the user-assigned managed identity.; Update the value of the DbPassword application setting to @Microsoft.KeyVault(SecretUri=https://kv-secrets-prod.vault.azure.net/secrets/db-password/).

Answer

Create a new application setting named keyVaultReferenceIdentity set to the identity's resource ID, and update the DbPassword setting to use the correct @Microsoft.KeyVault syntax with a trailing slash.
To successfully resolve a Key Vault reference using a user-assigned managed identity in Azure Functions, you must update the reference to use the correct syntax and point the App Service runtime to the correct identity. The correct syntax must begin with @Microsoft.KeyVault and include a trailing slash at the end of the URL if no secret version is specified. Additionally, you must add the keyVaultReferenceIdentity application setting and set it to the resource ID of the user-assigned managed identity.

Step-by-Step Solution

1
Correct the Key Vault reference syntax.
Changing the prefix from @KeyVault to @Microsoft.KeyVault and adding a trailing slash since no version is specified.
The App Service runtime requires the full @Microsoft.KeyVault prefix and a trailing slash for versionless secret URIs to correctly parse and resolve the reference.
2
Configure the keyVaultReferenceIdentity setting.
Adding the keyVaultReferenceIdentity setting with the user-assigned identity's resource ID.
If an app has only a user-assigned managed identity, the App Service platform needs the resource ID of that identity specified in the keyVaultReferenceIdentity setting to fetch the secret from Key Vault.

Key Concept

Key Vault references in App Service and Azure Functions require correct syntax (including trailing slash for versionless URIs) and explicit configuration of the keyVaultReferenceIdentity setting when using user-assigned managed identities.
Question 491Question

You are deploying a backend microservice named `inventory-service` to an Azure Container Apps environment. The microservice runs inside a container that listens on port 3000 and needs to integrate with Dapr to enable state management and service-to-service invocation using the application ID `inventory-processor`. You are authoring a Bicep template to deploy the container app. Which two settings must you configure within the `dapr` block under `properties.configuration` to successfully enable Dapr integration and register the microservice?

Select all that apply

Show answer & explanation

Answer: enabled: true; appId: 'inventory-processor'

Answer

The settings enabled set to true and appId set to 'inventory-processor' are required inside the dapr block.
To successfully enable and configure Dapr for an Azure Container App in a Bicep template, the dapr object under properties.configuration must have enabled set to true to trigger sidecar injection, and appId set to the required string value ('inventory-processor') to define the application's service identification.

Step-by-Step Solution

1
Enable the Dapr sidecar injection by configuring the enabled boolean property.
enabled is set to true within the dapr block.
This instructs the Container Apps runtime to inject the Dapr sidecar container alongside the application container.
2
Assign the unique identifier for service discovery and state retrieval.
appId is set to 'inventory-processor'.
This specifies the application ID that other services in the environment will use to invoke methods on this microservice.

Key Concept

Dapr integration configuration in Azure Container Apps Bicep templates
Question 492Question

You are developing an ASP.NET Core Web API that runs in an autoscaling Azure App Service plan. The Web API authenticates users using the Microsoft Identity Platform. It must make downstream calls to Microsoft Graph on behalf of the signed-in user by using the OAuth 2.0 On-Behalf-Of (OBO) flow.

During load testing, you observe that downstream calls experience intermittent latency and fail with HTTP 429 (Too Many Requests) errors from Microsoft Entra ID. You determine that because the App Service scales out to multiple instances, each instance maintains a separate in-memory token cache, resulting in frequent, redundant token exchange requests to Microsoft Entra ID.

You need to resolve the performance issue and prevent rate-limiting while maintaining the signed-in user's context for Microsoft Graph calls.

Which of the following configuration changes should you implement?

Show answer & explanation

Answer: Configure a distributed cache (such as Azure Cache for Redis) and register it in the application startup using the AddDistributedTokenCaches method.

Answer

Configure a distributed cache (such as Azure Cache for Redis) and register it in the application startup using the AddDistributedTokenCaches method.
Configuring a distributed cache (such as Azure Cache for Redis) and registering it using the `AddDistributedTokenCaches` method is correct because it shares the token cache across all instances of the scaled-out App Service. When one instance exchanges the user's incoming assertion for a downstream token using the On-Behalf-Of flow, the acquired token is stored in the shared distributed cache. Subsequent requests from the same user handled by other instances will read the token directly from the distributed cache, preventing redundant token exchange calls to Microsoft Entra ID and avoiding HTTP 429 throttling.

Step-by-Step Solution

1
Analyze the token caching behavior in a multi-instance Web API environment.
Realized that default in-memory token caching is limited to individual hosts, leading to cold caches on new scale-out instances and resulting in redundant OAuth 2.0 OBO requests to Microsoft Entra ID.
To identify why rate-limiting and performance degradation are occurring under load.
2
Select a shared token cache strategy that spans across all application instances.
Chose distributed token caching utilizing an external store such as Azure Cache for Redis or SQL Server.
A shared cache ensures that once an access token is acquired for a user, any scaled-out instance can access and reuse it, avoiding redundant OBO token exchanges.
3
Register the distributed token cache in the dependency injection container of the ASP.NET Core API.
Added `AddDistributedTokenCaches` to the authentication builder chain in the application's startup file.
This configures the Microsoft.Identity.Web library to write and read tokens from the registered `IDistributedCache` provider instead of the default in-memory cache.

Key Concept

Distributed Token Cache Serialization in MSAL / Microsoft.Identity.Web
Estimated Time:2m 30s
Question 493Question

You are developing a solution that uses Azure Event Grid to handle custom application events. You need to create a new custom topic, configure a subscription to route events to an Azure Function, and then publish a test event to verify the endpoint routing using an API client.

Which five actions should you perform in sequence? To answer, arrange the actions in the correct order.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Create the custom Event Grid topic, retrieve the endpoint URL and access key, create the event subscription, construct the JSON array with the event object, and send the HTTP POST request to the custom topic endpoint with the access key in the headers.
To configure and verify Event Grid routing, you must follow a logical sequence: first, create the target resource (the custom topic). Once created, retrieve the endpoint URI and SAS key for authorization. Then, create the event subscription so that when you publish the test event, it will actually be routed to the Azure Function rather than being dropped. Next, format the event payload as a JSON array to comply with the Event Grid schema. Finally, send an HTTP POST request to the endpoint, specifying the SAS key in the headers and the JSON array in the request body.

Step-by-Step Solution

1
Create the custom Event Grid topic resource in Azure.
The topic resource is created and allocated a unique endpoint.
You cannot obtain connection credentials or bind subscriptions without first creating the topic.
2
Retrieve the access key and the endpoint URI from the created topic.
The topic endpoint URL and primary access key are obtained.
These values are required to authenticate and direct the HTTP request when publishing events.
3
Create an event subscription on the custom topic targeting the Azure Function endpoint.
The handler endpoint is registered to listen to events from the custom topic.
If events are published before a subscription exists, the custom topic will discard them immediately.
4
Prepare the message payload as a JSON array containing a schema-compliant Event Grid event.
A valid Event Grid JSON payload is created.
Event Grid endpoints reject payloads that do not match the required JSON array structure and schema properties (e.g., id, subject, eventType, eventTime, data).
5
Send an HTTP POST request to the endpoint with the JSON payload and the access key in the aeg-sas-key header.
The event is successfully published and routed to the Azure Function.
This initiates the delivery pipeline, transmitting the test event to the registered handler.

Key Concept

Publishing events to a custom Event Grid topic
Question 494Question

You are writing a C# helper method using the `Azure.Storage.Blobs` SDK (v12) to generate a temporary Shared Access Signature (SAS) URL for a specific blob. The SAS URL must meet the following security and technical requirements:
- The SAS token must be signed using Microsoft Entra ID credentials (not storage account access keys).
- The SAS token must remain valid for exactly 2 hours.
- Access to the blob must be restricted to HTTPS only.
- The client must have read-only access (least privilege).
- The code must execute successfully without throwing runtime exceptions from the Azure Storage service.

You write the following C# method:

csharp
public static async Task<Uri> GenerateSecureBlobSasUriAsync(
BlobClient blobClient,
BlobServiceClient blobServiceClient,
string ipAddressRange)
{
// Step 1: Request User Delegation Key
DateTimeOffset keyStart = DateTimeOffset.UtcNow.AddMinutes(-15);
DateTimeOffset keyEnd = DateTimeOffset.UtcNow.AddDays(10);

UserDelegationKey delegationKey = await blobServiceClient.GetUserDelegationKeyAsync(keyStart, keyEnd);

// Step 2: Configure SAS Builder
BlobSasBuilder sasBuilder = new BlobSasBuilder
{
BlobContainerName = blobClient.BlobContainerName,
BlobName = blobClient.Name,
Resource = "b",
StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15),
ExpiresOn = DateTimeOffset.UtcNow.AddHours(2),
Protocol = SasProtocol.HttpsAndHttp
};

sasBuilder.SetPermissions(BlobSasPermissions.Read | BlobSasPermissions.Write);
sasBuilder.IPRange = SasIPRange.Parse(ipAddressRange);

// Step 3: Generate and append SAS token
BlobSasQueryParameters sasParams = sasBuilder.ToSasQueryParameters(delegationKey, blobServiceClient.AccountName);

UriBuilder uriBuilder = new UriBuilder(blobClient.Uri)
{
Query = sasParams.ToString()
};

return uriBuilder.Uri;
}

Which three modifications must you make to the code to ensure it executes successfully and complies with all requirements?

Select all that apply

Show answer & explanation

Answer: Change the keyEnd variable in Step 1 to a duration of 7 days or less from keyStart to prevent a runtime exception.; Change the Protocol property of the BlobSasBuilder in Step 2 to SasProtocol.Https to restrict access to HTTPS only.; Modify the SetPermissions method call in Step 2 to pass BlobSasPermissions.Read only, removing the Write permission.

Answer

To ensure successful execution and security compliance, you must: 1. Reduce the User Delegation Key lifetime to 7 days or less by modifying keyEnd. 2. Limit the allowed protocol to HTTPS only by setting the SasBuilder Protocol to SasProtocol.Https. 3. Adhere to least privilege by setting permissions to BlobSasPermissions.Read only.
To ensure the code runs without throwing a runtime error and meets the security requirements, three modifications are necessary: first, the User Delegation Key lifetime must be capped at 7 days; second, the SAS builder must restrict protocols to HTTPS only; third, the SAS permissions must be restricted to Read only.

Step-by-Step Solution

1
Analyze the User Delegation Key lifetime limits.
The current code requests a key valid for 10 days. The maximum lifetime for a User Delegation Key is 7 days, so keyEnd must be adjusted to a maximum of 7 days after keyStart to prevent a runtime RequestFailedException.
Azure Storage enforces a strict 7-day limit on the validity period of the signing key used for user delegation.
2
Evaluate the protocol security requirement.
The current configuration uses SasProtocol.HttpsAndHttp, which allows unencrypted HTTP access. The Protocol property must be updated to SasProtocol.Https to meet the HTTPS-only security mandate.
Restricting the protocol at the SAS level ensures the storage service rejects any non-HTTPS traffic using this token.
3
Apply the principle of least privilege to SAS permissions.
The current code grants Read and Write permissions. Since the requirement is read-only (download) access, the BlobSasPermissions.Write flag must be removed, leaving only BlobSasPermissions.Read.
Least privilege security practices dictate that users should only receive the minimum permissions necessary to complete their task.

Key Concept

User Delegation SAS configuration, lifetime limits, and least privilege in Azure Storage.
Question 495Question

You are configuring permissions in Microsoft Entra ID for a Single Page Application (SPA) named TimeTrackerSPA. The application runs in the user's browser and must perform the following actions:

1. Retrieve the signed-in user's profile details from Microsoft Graph.
2. Read and write time entries using a custom backend Web API named TimeSheetAPI on behalf of the signed-in user.

The TimeSheetAPI application registration exposes a delegated scope named TimeSheet.Write.

Which permissions should you configure for the TimeTrackerSPA application registration?

Show answer & explanation

Answer: Microsoft Graph: Delegated permission User.Read; TimeSheetAPI: Delegated permission TimeSheet.Write

Answer

The correct permission configuration is Delegated permission: User.Read (from Microsoft Graph) and Delegated permission: TimeSheet.Write (from TimeSheetAPI).
The application is a Single Page Application (SPA) that runs in the browser under the context of the signed-in user. Therefore, it must use Delegated permissions to access resources on behalf of the user. To read the signed-in user's profile, the delegated permission 'User.Read' is sufficient and does not require administrator consent, fulfilling the principle of least privilege. To call the backend Web API on behalf of the user, the application must use the delegated scope 'TimeSheet.Write' exposed by the API.

Step-by-Step Solution

1
Identify the application type and its execution context.
The application is a Single Page Application (SPA) running in a web browser.
Determines whether to use Delegated permissions (user context) or Application permissions (daemon/background service context).
2
Determine the permission type based on the application context.
Since the SPA operates on behalf of a signed-in user and cannot securely store client secrets, Delegated permissions must be used for both Microsoft Graph and TimeSheetAPI.
Ensures secure token acquisition and proper user-context propagation.
3
Select the least-privileged scopes that satisfy the functional requirements.
Microsoft Graph 'User.Read' is selected instead of 'Directory.Read.All' because reading the signed-in user's own profile does not require administrative consent or directory-wide access. The custom API scope 'TimeSheet.Write' is added as a delegated permission.
Applies security best practices by minimizing access and avoiding unnecessary admin consent requirements.

Key Concept

Configuring Delegated permissions versus Application permissions and applying the principle of least privilege for Microsoft Entra ID app registrations.
Question 496Question

You are developing a C# application that needs to publish telemetry events to an Azure Event Grid custom topic. You plan to use the Azure SDK for .NET (specifically the Azure.Messaging.EventGrid NuGet package). Which sequence of steps must you perform in your code to publish the events?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps to publish events is to first retrieve the custom topic endpoint and key, then instantiate the EventGridPublisherClient, next construct the collection of EventGridEvent objects, and finally invoke SendEventsAsync to transmit the events.
To publish events, you must first fetch the configuration settings (endpoint and key), configure the client with those credentials, prepare the list of events to send, and finally call the send method on the client.

Step-by-Step Solution

1
Retrieve custom topic credentials
Endpoint URI and access key are available in memory.
These credentials are required to authorize the client when communicating with the Azure Event Grid custom topic.
2
Instantiate EventGridPublisherClient
An active client instance is ready for sending events.
The client handles connections and serialization, requiring the endpoint URI and an AzureKeyCredential initialized with the access key.
3
Construct EventGridEvent objects
A list or collection of event models ready to be transmitted.
You must define the metadata (subject, eventType, dataVersion) and the payload data for the events before publishing.
4
Invoke SendEventsAsync
Events are transmitted and published to the Event Grid topic.
The SendEventsAsync method sends the prepared batch of events to the target endpoint asynchronously.

Key Concept

Publishing events to an Azure Event Grid custom topic using the Azure Messaging EventGrid client library for .NET.
Question 497Question

You are configuring Application Insights instrumentation for an ASP.NET Core web application that will be hosted on Azure App Service. You want to ensure telemetry data is collected and sent to Azure Monitor. Which two of the following configuration actions are required to achieve this?

Select all that apply

Show answer & explanation

Answer: Register the telemetry services by calling builder.Services.AddApplicationInsightsTelemetry(builder.Configuration) in Program.cs.; Set the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable in your App Service configuration.

Answer

To configure Application Insights instrumentation, you must register the telemetry services in your application's startup file and specify the Application Insights connection string in the configuration settings.
Registering the services in Program.cs ensures the SDK captures built-in telemetry, and setting the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable instructs the SDK where to send the telemetry.

Step-by-Step Solution

1
Register telemetry services in the Program.cs file.
The application runtime registers dependency injection services required for telemetry auto-collection and custom logging.
Registering the SDK in the startup services enables automatic dependency, request, and exception tracking.
2
Set the APPLICATIONINSIGHTS_CONNECTION_STRING in the environment variables or configuration.
The SDK retrieves the connection string to determine the ingestion endpoint and routing details.
Providing the connection string is mandatory for routing telemetry data to the correct Application Insights resource.

Key Concept

Successful Application Insights SDK setup requires registering the telemetry services in code and providing a connection string for routing.
Question 498Question

An organization deploys a Node.js REST API inside Azure Container Apps (ACA). The container app uses a user-assigned managed identity named `id-api-prod` to authenticate.

The API loads its configuration from an Azure App Configuration instance named `config-payment-prod`. The App Configuration store contains a key named `PaymentGateway:ApiKey` which is configured as a Key Vault reference pointing to a secret named `gateway-api-key` in a Key Vault named `kv-payment-prod`.

The managed identity `id-api-prod` is assigned the App Configuration Data Reader role on the App Configuration store. However, at runtime, the API fails to start because it cannot retrieve the resolved value of the `PaymentGateway:ApiKey` setting, instead receiving an access denied authorization error.

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

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the user-assigned managed identity `id-api-prod` on the Key Vault `kv-payment-prod`.

Answer

Assign the Key Vault Secrets User role to the user-assigned managed identity `id-api-prod` on the Key Vault `kv-payment-prod`.
The correct answer is to assign the Key Vault Secrets User role to the user-assigned managed identity `id-api-prod` on the Key Vault `kv-payment-prod`. This is because Key Vault references stored in Azure App Configuration are resolved at runtime by the client SDK running within the application. The application uses its own credentials (in this case, the user-assigned managed identity) to connect directly to the Key Vault and retrieve the secret values. Therefore, the application's identity must have authorization (such as the Key Vault Secrets User role) to read secrets from the Key Vault.

Step-by-Step Solution

1
Analyze how Azure App Configuration Key Vault references are resolved.
Identify that the client application (Node.js API inside Azure Container Apps) is responsible for fetching the secret from Azure Key Vault using its own credential at runtime.
Azure App Configuration does not fetch the secret value itself; it only returns a JSON metadata reference that tells the client SDK where the secret is stored.
2
Identify the authentication credential used by the client application.
The application uses the user-assigned managed identity `id-api-prod` for authentication.
This identity is configured on the Container App and holds the necessary roles to read configuration.
3
Determine the minimum required permission on the Key Vault to resolve the reference.
The identity `id-api-prod` needs read access to Key Vault secrets. This is granted by assigning the Key Vault Secrets User role on the Key Vault.
Granting Key Vault Secrets User role on the Key Vault allows the application to call the GET secret API, resolving the access denied error.

Key Concept

Key Vault references in Azure App Configuration are resolved at runtime by the client application using its own identity and credentials, requiring the client identity to have read permissions (like Key Vault Secrets User) on the Key Vault.
Question 499Question

You are developing an Azure Durable Function in C# (.NET Isolated) to process user registration requests. The orchestrator function must generate a unique correlation ID for tracking and retrieve the current timestamp to record when the process started.

You need to ensure that the orchestrator code remains deterministic and adheres to Durable Functions execution constraints.

Which code segment should you use inside the orchestrator function?

Show answer & explanation

Answer: Guid correlationId = context.CreateGuid(); DateTime startTimestamp = context.CurrentUtcDateTime;

Answer

Use context.CreateGuid() to generate the correlation ID and context.CurrentUtcDateTime to retrieve the timestamp.
The option utilizing context.CreateGuid() and context.CurrentUtcDateTime is correct because it adheres to the determinism constraints of Durable Functions. In Azure Durable Functions, orchestrator functions are replayed to rebuild their state. Therefore, code inside an orchestrator must be deterministic. Standard APIs like Guid.NewGuid() and DateTime.UtcNow return different values on every execution, causing the orchestration to fail with a non-deterministic workflow error. The TaskOrchestrationContext provides deterministic alternatives: CreateGuid() generates a GUID that is saved and replayed consistently, and CurrentUtcDateTime returns the timestamp of when the orchestrator was scheduled, which is also replayed consistently.

Step-by-Step Solution

1
Analyze the determinism constraints of Azure Durable Functions orchestrator functions.
Identify that APIs returning different values on execution replay (such as generating GUIDs or retrieving system time) cannot be used directly inside the orchestrator.
Orchestrators must run deterministically to rebuild state via execution replay.
2
Identify the deterministic equivalents provided by the TaskOrchestrationContext object in C# (.NET Isolated).
Determine that context.CreateGuid() replaces Guid.NewGuid(), and context.CurrentUtcDateTime replaces DateTime.UtcNow.
These context APIs record their values in the orchestration history during the first execution and return the identical recorded values during subsequent replays.

Key Concept

Orchestrator code determinism and using context-specific APIs for GUIDs and timestamps.
Question 500Question

You are developing a serverless order processing workflow using Azure Durable Functions. The workflow is initiated via an HTTP request, performs a payment processing activity, and then runs a receipt generation activity.

Arrange the execution and execution replay events of the Durable Functions runtime in the correct sequential order from the arrival of the initial client request to the execution of the second activity.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with the client function initiating the orchestrator and returning a response, followed by the orchestrator starting and scheduling the first activity. The orchestrator then yields execution while the activity runs. After the activity completes and logs its output to history, the orchestrator wakes up, replays from the beginning, retrieves the activity output from history, and schedules the second activity.
The correct sequence mirrors the fundamental event-sourcing and execution replay design of Durable Functions. The workflow is started by a client function returning status endpoints. Then, the orchestrator begins, schedules the first activity, and yields. When the activity finishes, its outcome is recorded in Azure Storage, triggering the orchestrator to wake up, replay from the beginning using history, and proceed to the next activity.

Step-by-Step Solution

1
Trigger the orchestration client.
The client function starts the orchestration instance and returns an HTTP 202 response.
Durable workflows are kicked off by a starter client function which generates the management endpoints.
2
Begin orchestrator execution and schedule the first activity.
The orchestrator runs and calls the payment activity using an await expression.
The orchestrator must schedule the first task in the sequence.
3
Yield orchestrator execution.
The orchestrator goes to sleep, saving execution state.
Yielding execution ensures that compute resources are not wasted while waiting for long-running activities.
4
Log activity completion.
The completed activity's return value is saved to the history table in storage.
The runtime relies on persistent storage history to reconstruct the workflow state.
5
Replay the orchestrator and schedule the next activity.
The orchestrator executes again, reads the payment result from history, and schedules the receipt activity.
To maintain state safely, the orchestrator replays its code, bypassing completed tasks recorded in the history table.

Key Concept

Replay mechanism and event sourcing in Azure Durable Functions
PreviousPage 25 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin