All practice questions

972 questions

Question 341Question

You are developing a secure daemon service that runs on an on-premises Linux server. The service must authenticate with Microsoft Entra ID to retrieve secrets from an Azure Key Vault. Security policies prohibit the use of client secrets (passwords) for daemon services, requiring certificate-based authentication instead. You generate a self-signed certificate on the Linux server and register the application in Microsoft Entra ID under the name OnPremDaemon. Which configuration step must you perform in Microsoft Entra ID to enable the service to authenticate using this certificate?

Show answer & explanation

Answer: Upload the public key (.cer or .pem) of the certificate to the Certificates & secrets section of the OnPremDaemon app registration, which populates the keyCredentials property in the application object.

Answer

Upload the public key (.cer or .pem) of the certificate to the Certificates & secrets section of the OnPremDaemon app registration, which populates the keyCredentials property in the application object.
To configure certificate-based authentication, the public key (.cer or .pem) of the certificate must be uploaded to the app registration. This action populates the keyCredentials array in the application object. When the daemon application authenticates, it signs a client assertion (JWT) using its private key and sends it to the token endpoint. Microsoft Entra ID uses the registered public key to verify the signature of the assertion.

Step-by-Step Solution

1
Extract the public key from the generated certificate on the Linux server.
A public key file in .cer or .pem format is obtained.
Only the public key is needed by Microsoft Entra ID to verify signatures, while the private key remains secure on the host.
2
Navigate to the Microsoft Entra ID portal, open the App registrations blade, and select the OnPremDaemon application.
The application registration details page is displayed.
Credentials must be configured on the application registration representing the daemon service.
3
Go to the Certificates & secrets section, click on Upload certificate, and select the public key file.
The certificate is successfully uploaded and its thumbprint, start date, and expiration date are visible.
This action registers the certificate under the keyCredentials array of the application object, enabling Microsoft Entra ID to validate token requests signed with the corresponding private key.

Key Concept

App Registrations and Service Principals credentials configuration using certificates
Question 342Question

You need to copy several files from a source blob container in one Azure Storage account to a destination blob container in a different Azure Storage account using the AzCopy command-line tool. Which two of the following security and access configuration steps are required to perform this copy operation? (Select two.)

Select all that apply

Show answer & explanation

Answer: A Shared Access Signature (SAS) token for the source container that includes Read and List permissions.; A Shared Access Signature (SAS) token for the destination container that includes Write and Add permissions.

Answer

To perform the copy operation, you need a SAS token for the source container with Read and List permissions, and a SAS token for the destination container with Write and Add permissions.
For the copy operation to succeed, the source SAS token must provide Read and List permissions so the tool can identify and download the files, and the destination SAS token must provide Write and Add permissions to allow the creation and population of new blobs in the destination container.

Step-by-Step Solution

1
Configure permissions for the source storage resource.
Generate a SAS token for the source container with Read and List permissions.
AzCopy must be able to read the blob data and list the container contents to locate the files to transfer.
2
Configure permissions for the destination storage resource.
Generate a SAS token for the destination container with Write and Add permissions.
AzCopy must have permissions to write new blobs and append data to the destination container.

Key Concept

Authorizing data movement between Azure Storage containers using Shared Access Signatures (SAS).
Question 343Question

You are developing a .NET application using the Azure.Storage.Blobs SDK to update the custom metadata of an existing block blob. To prevent concurrent writes and ensure that no existing metadata is lost, you must acquire an exclusive-write lease, retrieve the current metadata, append a new key-value pair, save the changes, and release the lease. Which sequence of steps should you perform to complete this process securely and without data loss?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first acquire the lease using the lease client, then retrieve the properties using the blob client, modify the metadata dictionary, upload the updated metadata by passing the lease ID in the request conditions, and finally release the lease.
The correct sequence ensures that the blob is locked before any reads or writes occur, preventing dirty reads or lost updates. By acquiring the lease first, we guarantee that the metadata we retrieve is current and cannot be modified by any other client. Modifying the dictionary in memory preserves the existing keys because SetMetadataAsync replaces the entire metadata collection. Finally, passing the lease ID during the set operation is mandatory for leased blobs, and releasing the lease makes the blob available to others.

Step-by-Step Solution

1
Acquire the lease.
The blob is locked for exclusive-write access by this client.
Acquiring the lease first prevents race conditions by locking the resource before any read or write operation is initiated.
2
Retrieve current metadata.
The current metadata dictionary is read from the leased blob.
Reading the metadata while the lease is active guarantees that the metadata retrieved is the latest and cannot be changed by other processes before we write our updates.
3
Modify the metadata dictionary.
The local metadata dictionary is updated with the new key-value pair.
Since SetMetadataAsync overwrites all existing metadata on the blob, the modification must be done locally on the retrieved dictionary to preserve existing entries.
4
Write the updated metadata back to the blob.
The metadata on Azure Blob Storage is updated.
The write operation must include the lease ID in BlobRequestConditions to authorize the modification on the locked blob.
5
Release the lease.
The blob is unlocked.
The lease must be explicitly released so that other clients and processes can perform modifications on the blob.

Key Concept

To safely modify a leased blob's metadata without data loss or race conditions, you must acquire the lease, retrieve properties, modify the dictionary, write the metadata back using the lease ID, and then release the lease.
Question 344Question

You are deploying a web application to Azure App Service using an Azure Resource Manager (ARM) template. The application must retrieve database connection strings from Azure Key Vault. Security requirements specify that the managed identity used by the application must be decoupled from the App Service's lifecycle so it can be shared with an Azure Function in the future, and it must not be deleted if the App Service is removed. Which two of the following configuration steps must you perform to implement this security architecture? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Set the identity property type to UserAssigned in the App Service ARM template, and define the identity under the userAssignedIdentities dictionary.; Run the az role assignment create Azure CLI command to assign the 'Key Vault Secrets User' role to the principal ID of the user-assigned identity at the Key Vault scope.

Answer

To implement this architecture, you must set the identity type to UserAssigned in the App Service resource definition and use Azure CLI to assign the Key Vault Secrets User role to the identity's principal ID.
Configuring a user-assigned managed identity allows the security context to exist independently of the App Service resource, which is required for sharing with the Azure Function and surviving deletion of the App Service. Assigning the Key Vault Secrets User role to the identity's principal ID grants the required permissions without managing secrets.

Step-by-Step Solution

1
Define the managed identity type in the ARM template.
Set the type property to UserAssigned and configure the identity under the userAssignedIdentities dictionary.
This decouples the identity's lifecycle from the App Service, ensuring it is not deleted when the App Service is removed and allowing it to be shared with other resources.
2
Assign RBAC permissions to the identity.
Execute az role assignment create to grant the 'Key Vault Secrets User' role to the identity's principal ID at the Key Vault scope.
This authorizes the identity to retrieve secrets from the Key Vault, fulfilling the application's requirement to access database connection strings.

Key Concept

Selecting and configuring the correct type of managed identity based on resource sharing and lifecycle requirements.
Estimated Time:1m 30s
Question 345Question

You are troubleshooting a high-volume Azure web application that sends telemetry to Application Insights. You need to write a Kusto Query Language (KQL) query to retrieve all failed requests that occurred during the last 24 hours.

Which of the following queries is the most efficient and syntactically correct way to retrieve this data?

Show answer & explanation

Answer: requests
| where timestamp > ago(24h)
| where success == false

Answer

The query that filters by timestamp first and then by success using double equals is the correct and most efficient choice.
The correct query applies the timestamp filter immediately after referencing the requests table, ensuring that only records from the last 24 hours are scanned. It then correctly uses the double equals operator to check for failed requests.

Step-by-Step Solution

1
Identify the table to query.
The 'requests' table contains request telemetry.
We need to find failed web requests.
2
Apply a time-range filter as the first operation.
Adding '| where timestamp > ago(24h)' restricts the query to the last 24 hours.
Applying the time filter first ensures the query engine only scans the relevant data partition, optimizing performance.
3
Filter for failed requests.
Adding '| where success == false' filters for failures.
The 'success' column is a boolean indicating request status, and comparison requires double equals (==).

Key Concept

Applying time-range filters early in KQL queries to optimize database scanning performance.
Question 346Question

You are developing a local console application that runs on an on-premises developer workstation. The application must periodically upload application diagnostic logs to a specific container in an Azure Storage account. You plan to configure the application to authenticate using a Microsoft Entra ID service principal with a client secret, adhering to the principle of least privilege.

Which sequence of steps should you perform to configure the identity, permissions, and application code?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First register the application in Microsoft Entra ID, then generate a new client secret under Certificates & secrets, next assign the Storage Blob Data Contributor role to the service principal at the scope of the storage container, and finally configure the application code to use the ClientSecretCredential.
The correct sequence begins with registering the application in Microsoft Entra ID to create the security principal. Next, a client secret is generated to authenticate this registration. Then, the service principal is granted the Storage Blob Data Contributor role at the container scope to ensure proper authorization. Finally, the developer instantiates a ClientSecretCredential in code to perform authentication.

Step-by-Step Solution

1
Register the application in Microsoft Entra ID.
Creates the application object and its corresponding service principal in the tenant.
You must establish the identity in the directory before you can add credentials or grant permissions to it.
2
Generate a client secret in the Microsoft Entra portal.
Creates a secure secret key associated with the application registration.
The secret key is required for the application to authenticate itself as the service principal.
3
Assign the Storage Blob Data Contributor role to the service principal at the container scope.
Grants the application permission to write blobs in the specific container.
Roles must be assigned to the service principal (not the application object) at the narrowest possible scope to respect the principle of least privilege.
4
Instantiate ClientSecretCredential in code.
Requests an access token from Microsoft Entra ID to authenticate requests to the storage container.
The application code needs the application ID, tenant ID, and client secret to perform token acquisition and execute authorized operations.

Key Concept

App Registrations, Service Principals, and Client Secrets configuration flow
Estimated Time:1m 30s
Question 347Question

A company uses a Standard General Purpose v2 (GPv2) storage account to store temporary media processing files in a container named incoming-transcodes. You configure a lifecycle management policy to delete all blobs in this container 7 days after they are created. Some of these blobs are actively leased by processing worker roles, while others are accessed by external clients using Shared Access Signatures (SAS). Which of the following describes the execution behavior of the lifecycle management policy when it runs?

Show answer & explanation

Answer: The lifecycle management policy executes and deletes the blobs regardless of active leases or the permissions of SAS tokens used to access the blobs.

Answer

The lifecycle management policy executes and deletes the blobs regardless of active leases or the permissions of SAS tokens used to access the blobs.
The correct answer states that the lifecycle management policy executes and deletes the blobs regardless of active leases or SAS permissions. Azure Blob Storage lifecycle management runs as a platform-level background process. While client applications must honor blob leases and SAS token permissions when performing operations on blobs, the lifecycle management service executes with administrative privileges and is not blocked by active leases or client-level access restrictions.

Step-by-Step Solution

1
Analyze the execution environment of Azure Blob Storage lifecycle management.
Identify that lifecycle management policies are service-level control plane operations defined directly on the storage account.
This establishes that the policy runs with native system privileges rather than under a specific user context or client session.
2
Evaluate the impact of active blob leases on lifecycle management execution.
Recall that active leases on blobs block client-side modifications/deletions but do not block service-level lifecycle management policies.
This determines that the leased blobs will still be successfully deleted when the rule runs.
3
Evaluate the impact of SAS tokens on lifecycle policy execution.
Recognize that lifecycle policies do not require client SAS permissions to execute.
Since the policy is defined at the account level and executes internally, SAS token permissions are irrelevant to the deletion process.

Key Concept

Azure Blob Storage Lifecycle Management Execution Mechanics
Estimated Time:1m 30s
Question 348Question

A developer is configuring a Microsoft Entra ID app registration for a web application named SalesReporter. The web application allows users to sign in and needs to access Microsoft Graph to read the signed-in user's profile and send emails on their behalf. Which two Microsoft Graph delegated permissions must be configured? Select two options.

Select all that apply

Show answer & explanation

Answer: User.Read; Mail.Send

Answer

The application requires User.Read and Mail.Send delegated permissions.
The correct options are User.Read and Mail.Send delegated permissions because the web application acts on behalf of the signed-in user (requiring delegated permissions) to read their profile and send emails.

Step-by-Step Solution

1
Identify that the application acts on behalf of a signed-in user, which requires Delegated permissions rather than Application permissions or Shared Access Signatures.
Confirm that Delegated permissions must be selected.
Delegated permissions allow the application to act on behalf of the signed-in user.
2
Determine that to read the user's basic profile, the User.Read delegated permission is required.
Select User.Read delegated permission.
This permission allows basic profile reading upon login.
3
Determine that to send emails as the signed-in user, the Mail.Send delegated permission is required.
Select Mail.Send delegated permission.
This permission allows sending email on behalf of the signed-in user.

Key Concept

Microsoft Entra ID delegated permissions allow an application to access APIs on behalf of a signed-in user.
Question 349Question

An enterprise data ingestion workflow in C# uses the Azure.Storage.Blobs SDK (v12) to process telemetry payloads. To prevent concurrent write conflicts on a shared blob named `active_logs.json`, the workflow must acquire an exclusive 30-second write lock (lease), perform the upload, and subsequently update the blob's metadata. Consider the following code skeleton:

csharp
using Azure.Storage.Blobs;
using Azure.Storage.Blobs.Models;
using Azure.Storage.Blobs.Specialized;
using System;
using System.IO;
using System.Collections.Generic;
using System.Threading.Tasks;

public class LogProcessor
{ public static async Task UploadLogWithLeaseAsync(BlobClient blobClient, Stream logStream)
{
BlobLeaseClient leaseClient = blobClient.GetBlobLeaseClient();
BlobLease lease = await leaseClient.AcquireAsync(TimeSpan.FromSeconds(30));

// Configure upload options
BlobUploadOptions uploadOptions = new BlobUploadOptions();

// Execute upload
await blobClient.UploadAsync(logStream, uploadOptions);

// Update metadata
var metadata = new Dictionary<string, string>
{ { "Status", "Processed" }
};

await blobClient.SetMetadataAsync(metadata);
}
}

If you execute this code, the write operations will fail because the active lease ID is not supplied to the operations. Which of the following changes must you implement to ensure both the upload and metadata update operations succeed under the active lease? (Select TWO options.)

Select all that apply

Show answer & explanation

Answer: Assign a new `BlobRequestConditions` object to `uploadOptions.Conditions` with its `LeaseId` property set to `lease.LeaseId`.; Pass a new `BlobRequestConditions` object with its `LeaseId` property set to `lease.LeaseId` as the second parameter (`conditions`) in the `SetMetadataAsync` call.

Answer

Configure both write operations using `BlobRequestConditions` with the `LeaseId` property set to the active lease ID. For the upload, assign this to `uploadOptions.Conditions`. For the metadata update, pass it as the second argument to `SetMetadataAsync`.
The correct configurations require passing the acquired lease ID inside a `BlobRequestConditions` object. For the blob upload operation, this object must be assigned to the `Conditions` property of `BlobUploadOptions`. For the metadata update operation, the request conditions must be passed as the second parameter to `SetMetadataAsync`. This ensures that both write actions are authenticated against the active lease.

Step-by-Step Solution

1
Identify the SDK class used to enforce access conditions such as leases.
The `BlobRequestConditions` class is identified as the mechanism for passing lease IDs in the Azure.Storage.Blobs SDK (v12).
Azure Storage requires lease validation via request headers which are configured using request condition parameters in the SDK.
2
Configure the upload options with the lease details.
The `Conditions` property of `BlobUploadOptions` is assigned a `BlobRequestConditions` instance containing the active lease ID.
This prevents write conflicts by ensuring the upload only succeeds if the lease is valid.
3
Configure the metadata update call with the lease details.
The `SetMetadataAsync` method is called with a `BlobRequestConditions` parameter containing the active lease ID.
Like write operations, metadata modifications on a leased blob require the lease ID to be supplied in the request conditions.

Key Concept

Configuring lease conditions for blob upload and metadata operations using the Azure.Storage.Blobs SDK
Question 350Question

An organization is deploying a C# .NET 8 application to an Azure App Service. The application must perform the following tasks:

1. Retrieve configuration secrets from an Azure Key Vault. The Key Vault is shared across several independent applications, and the credentials used to access it must persist even if this App Service instance is deleted.
2. Read messages from an Azure Service Bus queue. The credentials used for the queue must be exclusively tied to this App Service instance's lifecycle and automatically cleaned up if the App Service is deleted.

The application uses the `Azure.Identity` library and `DefaultAzureCredential` to connect to Azure resources.

Which two actions should you perform to implement this configuration?

Select all that apply

Show answer & explanation

Answer: Enable a system-assigned managed identity on the App Service, assign it the Azure Service Bus Data Receiver role on the Service Bus queue, and instantiate the Service Bus client using a default DefaultAzureCredential instance.; Create a user-assigned managed identity, assign it the Key Vault Secrets User role on the Key Vault, associate it with the App Service, and instantiate the Key Vault client using a DefaultAzureCredential instance initialized with DefaultAzureCredentialOptions containing the identity's client ID.

Answer

To implement this configuration, you should enable a system-assigned managed identity on the App Service for the Service Bus queue, assigning it the Azure Service Bus Data Receiver role and instantiating the Service Bus client using a default DefaultAzureCredential instance. Additionally, you should create a user-assigned managed identity for the Key Vault, assigning it the Key Vault Secrets User role, associating it with the App Service, and instantiating the Key Vault client by passing DefaultAzureCredentialOptions containing the identity's client ID to DefaultAzureCredential.
The correct solution uses a system-assigned managed identity for the Service Bus queue because the identity's lifecycle must be linked to the App Service's lifecycle. It uses a user-assigned managed identity for the Key Vault because the credentials must persist independently of the App Service. When both managed identities are enabled on the App Service, DefaultAzureCredential will default to the system-assigned identity unless explicitly configured. Thus, the Service Bus client can use the default credential parameterless constructor, while the Key Vault client must specify the user-assigned identity's client ID via DefaultAzureCredentialOptions.

Step-by-Step Solution

1
Analyze the identity lifecycle requirements for the shared Key Vault and the exclusive Service Bus queue.
Determine that the Key Vault requires a user-assigned managed identity because the credentials must persist independently of the App Service. Determine that the Service Bus queue requires a system-assigned managed identity because the credentials must be tied to the App Service's lifecycle.
System-assigned identities are tied to the host resource's lifecycle, whereas user-assigned identities exist as independent Azure resources.
2
Determine the appropriate RBAC roles for each resource.
Grant the Key Vault Secrets User role to the user-assigned managed identity on the Key Vault. Grant the Azure Service Bus Data Receiver role to the system-assigned managed identity on the Service Bus queue.
This grants the minimum required permissions to perform the operations securely.
3
Configure the Azure.Identity SDK in code to support both identities.
Instantiate the Service Bus client with a parameterless DefaultAzureCredential. Instantiate the Key Vault client with a DefaultAzureCredential configured with DefaultAzureCredentialOptions containing the user-assigned identity's client ID.
When both system-assigned and user-assigned identities are present, DefaultAzureCredential defaults to using the system-assigned identity. To use the user-assigned identity, its client ID must be explicitly provided in the options.

Key Concept

Selecting and configuring system-assigned and user-assigned managed identities based on resource lifecycle, sharing requirements, and multi-identity SDK configuration.
Question 351Question

You are configuring a deployment to Azure Container Instances (ACI). The container must pull its image from a private Azure Container Registry (ACR) and retrieve its database connection strings from Azure Key Vault during startup. You need to configure the authentication and access policies to ensure secure and successful deployment. Which two configurations are required to meet these requirements? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Configure a user-assigned managed identity for the container group and grant it the AcrPull role on the private Azure Container Registry.; Grant the container group's managed identity GET permission on Key Vault Secrets in the Key Vault access policies.

Answer

Configure a user-assigned managed identity for the container group with the AcrPull role on the Azure Container Registry, and grant the container group's managed identity GET permission on Secrets in the Key Vault access policies.
To deploy an ACI container group that pulls from a private ACR and retrieves secrets from Key Vault, a user-assigned managed identity is required for the ACR pull since the identity must exist before container group creation. Additionally, that same managed identity must be granted GET permission in Key Vault access policies to allow the application code to retrieve database connection strings at startup.

Step-by-Step Solution

1
Select the correct identity type for registry authentication.
A user-assigned managed identity is chosen and assigned to the ACI container group, and then granted the AcrPull role on the ACR.
Azure Container Instances (ACI) requires a user-assigned managed identity to authenticate and pull images from a private Azure Container Registry during the container group creation phase. A system-assigned managed identity cannot be used because it is only created after the container group is deployed.
2
Configure Key Vault access for the application.
The managed identity of the container group is granted GET permission for secrets in the Key Vault access policy.
To retrieve secrets at startup, the ACI container group's identity must have explicit read access (GET permission) to Key Vault Secrets.

Key Concept

Configuring private registry access and Key Vault integration for Azure Container Instances using managed identities.
Question 352Question

An organization is developing a secure reporting system consisting of three components:

1. WebPortal: An Angular Single Page Application (SPA) that allows employees to view their personalized dashboard.
2. ReportAPI: A secured ASP.NET Core Web API (https://api.contoso.com) that retrieves data from a backend database.
3. DataSync: A background daemon service that runs on an on-premises server to upload bulk logs to ReportAPI nightly.

You have the following requirements:
- WebPortal must acquire an access token to call ReportAPI. When a user logs in, ReportAPI must read the user's manager's details from Microsoft Graph on behalf of the signed-in user using the on-behalf-of (OBO) flow.
- DataSync must authenticate using client credentials (client secrets) to POST logs directly to ReportAPI.
- The configuration must follow the principle of least privilege.
- Standard user logins must not be blocked by consent prompts during authentication.

Which configuration correctly implements the permissions, scopes, and token acquisition requests to meet these requirements?

Show answer & explanation

Answer: Register ReportAPI, WebPortal, and DataSync in Microsoft Entra ID. In ReportAPI, expose the delegated scope Reports.Read and define an application role (application permission) named Logs.Write. Grant ReportAPI the Microsoft Graph delegated permission User.Read.All and perform tenant-wide admin consent. Configure WebPortal to request the scope api://<ReportAPI_Client_ID>/Reports.Read, and configure DataSync to request a token using the client credentials flow with the scope set to api://<ReportAPI_Client_ID>/.default.

Answer

The correct configuration is to expose Reports.Read as a delegated scope and define Logs.Write as an application role in the ReportAPI registration. WebPortal requests the specific scope api://<ReportAPI_Client_ID>/Reports.Read for user-interactive sessions, while DataSync requests api://<ReportAPI_Client_ID>/.default in a client credentials flow to get its pre-consented application role. Tenant-wide admin consent must be granted to the ReportAPI for the Microsoft Graph User.Read.All delegated permission to enable OBO flows without standard user interruption.
The correct configuration uses a delegated scope (Reports.Read) for the user-interactive Single Page Application (SPA) and defines an application role/permission (Logs.Write) for the background daemon (DataSync) which runs without user interaction. The background daemon authenticates using the client credentials flow, which requires setting the scope parameter to the API's Application ID URI followed by '/.default' rather than requesting individual scopes. Additionally, because the Web API uses the on-behalf-of (OBO) flow to call Microsoft Graph for 'User.Read.All' (which requires admin consent), performing tenant-wide admin consent prevents standard users from being blocked during login.

Step-by-Step Solution

1
Differentiate between delegated and application permissions based on the client application context.
WebPortal (SPA) requires delegated permissions (user context), while DataSync (daemon service) requires application permissions (app roles/service context).
Delegated permissions are used when an app acts on behalf of a signed-in user, whereas application permissions are used when an app runs in the background without a user.
2
Determine the correct scope syntax and acquisition flow for both clients.
WebPortal requests api://<ReportAPI_ClientID>/Reports.Read using authorization code flow. DataSync requests api://<ReportAPI_ClientID>/.default using client credentials flow.
Microsoft Entra ID client credentials flow does not allow requesting individual scopes; it requires the target API's ID URI with the /.default suffix to retrieve all assigned application permissions.
3
Identify the Microsoft Graph consent requirements for the backend on-behalf-of (OBO) call.
Grant ReportAPI the delegated User.Read.All permission and perform tenant-wide admin consent.
Reading a user's manager profile via User.Read.All is a high-privilege Graph permission requiring admin consent. Granting tenant-wide admin consent prevents standard users from encountering consent blocks during login.

Key Concept

Microsoft Entra ID Delegated vs. Application Permissions and Client Credentials Scope Configuration
Question 353Question

You are developing a C# ASP.NET Core web application deployed to Azure App Service. The application is deployed as two regional instances: app-us-east and app-us-west. Both instances must retrieve shared secrets from a central Azure Key Vault named kv-shared. Additionally, app-us-east must write data to a regional Azure Storage account named sa-east-logs, while app-us-west must write data to sa-west-logs. To configure the managed identities, you perform the following steps:

1. Create a single user-assigned managed identity named uami-shared and assign it to both App Services, granting it Get and List secrets permissions on kv-shared.
2. Enable a system-assigned managed identity on both app-us-east and app-us-west, and grant each regional identity Contributor access to its corresponding regional storage account (sa-east-logs or sa-west-logs).

In your C# code, you instantiate the SDK clients as follows:

csharp
// Accessing the shared Key Vault
var kvClient = new SecretClient(
new Uri("https://kv-shared.vault.azure.net/"),
new DefaultAzureCredential()
);

// Accessing the regional storage account
var blobClient = new BlobServiceClient(
new Uri("https://sa-east-logs.blob.core.windows.net/"),
new DefaultAzureCredential()
);

What is the authentication outcome when the app-us-east instance attempts to run this code and connect to both services?

Show answer & explanation

Answer: The application successfully connects to the regional storage account, but fails to authenticate to the shared Key Vault because DefaultAzureCredential defaults to the system-assigned managed identity when both identity types are enabled, causing token requests without a specified client ID to use the system-assigned identity.

Answer

The application successfully connects to the regional storage account, but fails to authenticate to the shared Key Vault because DefaultAzureCredential defaults to the system-assigned managed identity when both identity types are enabled, causing token requests without a specified client ID to use the system-assigned identity.
The correct option is correct because when an Azure App Service has both a system-assigned managed identity and a user-assigned managed identity, the metadata service defaults to issuing tokens for the system-assigned managed identity. Because DefaultAzureCredential is initialized without parameters, it requests a default token, which will represent the system-assigned identity. Consequently, the call to the regional storage account succeeds (authorized for the system-assigned identity), while the call to the shared Key Vault fails (authorized only for the user-assigned identity). To fix this, DefaultAzureCredential must be configured with DefaultAzureCredentialOptions specifying the ManagedIdentityClientId for the user-assigned identity.

Step-by-Step Solution

1
Determine the identities assigned to the App Service host.
The host app-us-east has both a system-assigned managed identity (with permissions to sa-east-logs) and a user-assigned managed identity (uami-shared with permissions to kv-shared).
This establishes the authorization scope for each identity type on the resource.
2
Analyze how DefaultAzureCredential resolves tokens when multiple managed identities are present.
Without specifying a client ID, DefaultAzureCredential calls the IMDS token endpoint without parameters, which causes Azure to default to using the system-assigned managed identity.
This identifies which security principal's token is returned during execution.
3
Evaluate the authentication outcome for each service request.
The token for the system-assigned identity successfully accesses sa-east-logs (due to Contributor RBAC) but fails to access kv-shared (as only uami-shared has permissions there).
This determines the final success/failure behavior of the C# code.

Key Concept

Understanding the default resolution behavior of DefaultAzureCredential and the Azure Instance Metadata Service (IMDS) when both system-assigned and user-assigned managed identities are assigned to a single resource.
Question 354Question

An organization is developing a stateless API service and a separate background processing worker, both interacting with an Azure Cosmos DB API for NoSQL account. The Cosmos DB account is configured with the default Session consistency and is replicated across East US (write region) and West US (read replica). The API service in East US updates a customer's order status document and receives a write confirmation. Immediately after, the background worker in West US needs to read the updated order document to process a notification. Which action must you perform to guarantee that the background worker reads the updated order status?

Show answer & explanation

Answer: Retrieve the session token from the API service's write response and pass it to the background worker's read request.

Answer

Retrieve the session token from the API service's write response and pass it to the background worker's read request.
The correct answer is to retrieve the session token from the API service's write response and pass it to the background worker's read request. Session consistency provides consistency guarantees for a single client session. Because the API service and the background worker are distinct client applications, the session token must be explicitly passed from the writer to the reader to guarantee that the reader sees the latest update.

Step-by-Step Solution

1
Analyze the consistency requirements and deployment topography.
The application runs across two regions (East US and West US) with Session consistency and requires a read-your-writes guarantee across two separate client instances (the API service and the background worker).
Understanding the limits of Session consistency is required, as it is only guaranteed out-of-the-box within a single client session.
2
Determine the mechanism to share session state between different clients.
Passing the session token from the write operation response to the read operation request allows the reader to catch up to the writer's state.
Cosmos DB allows passing session tokens explicitly to extend the Session consistency guarantee to external clients.

Key Concept

Session consistency scope and session token passing in Azure Cosmos DB
Question 355Question

You are analyzing application performance issues in Azure Application Insights. You need to write a Kusto Query Language (KQL) query to retrieve the timestamp, name, and duration for all requests that took longer than 2 seconds (2000 milliseconds). How should you complete the KQL query?

Fill in the blanks below

requests
|
duration > 2000
|
timestamp, name, duration
Show answer & explanation

Answer

The query is completed by using the 'where' operator to filter records by duration, and the 'project' operator to select the specific columns for the output.
The correct operators are 'where' for filtering the records and 'project' for selecting the specific columns to output in the result.

Step-by-Step Solution

1
Identify the filtering operator to restrict records based on the duration value.
The 'where' operator is chosen to filter records where duration > 2000.
In KQL, 'where' is the correct operator for filtering rows based on a boolean condition.
2
Identify the projection operator to select the columns to return.
The 'project' operator is chosen to output 'timestamp', 'name', and 'duration'.
In KQL, 'project' is used to specify which columns should be included in the final result set.

Key Concept

Basic KQL querying structure using where and project operators for filtering and selecting data.
Question 356Question

You are developing a web application hosted on an Azure App Service. The application must retrieve database connection strings securely from an Azure Key Vault using a system-assigned managed identity.

Which three actions should you perform in sequence to configure this security access? To answer, drag 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 the system-assigned managed identity on the Azure App Service instance. Next, assign the Key Vault Secrets User role to the App Service's managed identity at the Key Vault scope. Finally, configure the web application code to authenticate using the DefaultAzureCredential class and retrieve the secret.
To grant an App Service access to Key Vault via managed identity: 1) Enable the system-assigned identity on the App Service, creating the principal. 2) Grant that principal permissions via Key Vault Secrets User role assignment. 3) Configure application code using DefaultAzureCredential to automatically pick up the identity environment and authorize calls.

Step-by-Step Solution

1
Enable the system-assigned managed identity on the Azure App Service.
Azure creates a service principal in Microsoft Entra ID linked directly to the lifecycle of the App Service.
Before permissions can be granted or authentication can happen, the managed identity must be enabled to generate its identity principal.
2
Assign the Key Vault Secrets User role to the managed identity.
The identity is authorized to read secrets from the Key Vault.
Having an identity is not enough; the resource owner must grant it the necessary Role-Based Access Control (RBAC) permissions to access the secrets.
3
Update application code to use DefaultAzureCredential.
The application successfully retrieves secrets at runtime without hardcoded credentials.
DefaultAzureCredential automatically detects the system-assigned managed identity in the App Service environment and uses it to request tokens.

Key Concept

Configuring a system-assigned managed identity to access Azure Key Vault securely.
Question 357Question

You are developing a Single Page Application (SPA) using React that allows employees to view their own profile information from Microsoft Graph after signing in. Which permission type must you configure in the Microsoft Entra ID application registration to ensure that the application accesses the API on behalf of the signed-in user?

Show answer & explanation

Answer: Delegated permissions

Answer

Delegated permissions
Delegated permissions allow the application to act on behalf of the signed-in user. The application can only access resources that the user itself has access to, which is appropriate for a React SPA where users log in to see their own profile information.

Step-by-Step Solution

1
Identify the client application type and runtime context.
The application is a React Single Page Application (SPA) where users sign in directly.
Understanding whether a user is present during execution is critical for choosing the right permission model.
2
Determine the required access scope for the Microsoft Graph API request.
The application needs to access the signed-in user's own profile information (on-behalf-of access).
Accessing resources on behalf of the active user requires user consent and delegation.
3
Select the correct Entra ID permission category based on the user context.
Delegated permissions are selected because they allow the application to run in the context of the signed-in user.
Application permissions are reserved for background services without user interaction, while SAS and Key Vault policies do not apply to Microsoft Graph permissions.

Key Concept

Delegated permissions allow applications to act on behalf of a signed-in user, whereas application permissions allow apps to run independently as background services.
Question 358Question

You are developing a .NET application using the Azure.Storage.Blobs SDK. You need to copy a blob from a source URI to a destination container using the following code:

csharp
// destinationClient is a BlobClient pointing to the target blob path
// sourceUri is the Uri of the source blob
await destinationClient._______(sourceUri);

Which method should you use to fill the blank to initiate the copy operation asynchronously?

Show answer & explanation

Answer: StartCopyFromUriAsync

Answer

StartCopyFromUriAsync is the correct method to asynchronously copy a blob from a source URI.
The method StartCopyFromUriAsync is correct because it is the standard method in the Azure.Storage.Blobs SDK (BlobClient class) designed to start copy operations from a source URI asynchronously.

Step-by-Step Solution

1
Identify the requirement to copy an existing blob to a target destination using a URI in the .NET SDK.
The target object is a destination BlobClient.
The destination BlobClient is responsible for initiating the copy operation from the source URI.
2
Select the appropriate method from BlobClient that initiates a copy from a source URI.
The correct method is StartCopyFromUriAsync.
This method tells the Azure Storage service to start copying the blob data from the source URI asynchronously.

Key Concept

Asynchronous blob copying using the Azure.Storage.Blobs .NET SDK
Estimated Time:45s
Question 359Question

You are developing a multi-tenant daemon application that will run on-premises and read calendar data from multiple customer organizations using Microsoft Graph. The application does not have a user interface and must run without user interaction.

You need to register the application, establish consent in a customer's tenant, and acquire an access token to access their data.

In which order should you perform the steps? To answer, move all 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, register the multi-tenant application and configure its application permissions and client secret in the home tenant. Second, construct the administrator consent URL using the application's client ID. Third, have the customer's administrator access the URL to grant consent. Fourth, verify the service principal is created in the customer's tenant. Lastly, request an access token from the customer's token endpoint using the client credentials.
The correct order proceeds from registering the application in the provider's home tenant to generate the client ID, constructing the admin consent URL, obtaining tenant-wide consent from the customer's administrator, verifying the local service principal's creation, and finally requesting the access token from the customer's specific endpoint.

Step-by-Step Solution

1
Register the application in the home tenant and configure its metadata, supported account types (multi-tenant), and credentials.
The application registration is created, yielding a client ID and a client secret.
You must establish the identity definition and authentication credentials before any tenant-level operations or token requests can occur.
2
Construct the admin consent request URL targeting the Microsoft Entra ID endpoint, appending the client ID and redirect URI.
A valid consent URL is prepared for the customer's tenant administrator.
Since daemon apps use client credentials flow (Application permissions), there is no interactive sign-in flow to trigger dynamic consent; therefore, the administrator consent endpoint must be explicitly called.
3
Have the customer's Global Administrator navigate to the consent URL and sign in to approve the permissions.
Consent is granted to the application for the customer's tenant.
Only a tenant administrator can grant consent for Application-level permissions (such as reading calendar data across all mailboxes).
4
Confirm the instantiation of the service principal in the customer's tenant.
A service principal (Enterprise Application object) is created in the customer's tenant.
The service principal acts as the local identity representation of the application in the target tenant and holds the delegated or consented permissions.
5
Perform a client credentials token request using the client secret to the customer's specific token endpoint.
An OAuth 2.0 access token is returned by Microsoft Entra ID for the target customer tenant.
With consent established and the service principal present, the daemon can securely request a token specifically scoped to the customer's resources.

Key Concept

Multi-tenant application registration, administrative consent flow, and service principal instantiation for daemon applications using Microsoft Entra ID.
Estimated Time:2m 30s
Question 360Question

You are developing a background daemon application that runs on an on-premises Windows server. The application must run unattended to process files and upload them to an Azure Blob Storage container. You need to configure authentication and authorization for the application, ensuring that it uses Microsoft Entra ID and adheres to the principle of least privilege.

Which of the following authentication and authorization configurations should you implement?

Show answer & explanation

Answer: Register the application in Microsoft Entra ID to create an application object and a corresponding service principal, configure a certificate credential for authentication, and assign the Storage Blob Data Contributor role to the service principal.

Answer

Register the application in Microsoft Entra ID to create an application object and a corresponding service principal, configure a certificate credential for authentication, and assign the Storage Blob Data Contributor role to the service principal.
Registering the application in Microsoft Entra ID creates both an application object (defining the app globally) and a service principal (the local representation used for authentication and authorization in the tenant). Because the daemon application runs on-premises, it cannot natively use a managed identity. Authenticating using a certificate credential (rather than a client secret) provides a more secure approach for unattended daemon services. Granting the Storage Blob Data Contributor role to the service principal via Azure Role-Based Access Control (RBAC) ensures the application has only the permissions required to upload files to Blob Storage.

Step-by-Step Solution

1
Register the application in the Microsoft Entra ID tenant.
Creates an application object (representing the app registration) and an associated service principal in the home tenant.
On-premises daemon applications must be registered in Microsoft Entra ID to obtain identity credentials.
2
Upload a public certificate to the app registration to configure a certificate credential.
Establishes a highly secure credential type for the application.
Daemon applications run unattended and require non-interactive credentials. Certificate credentials are preferred over client secrets for production environments.
3
Assign the Storage Blob Data Contributor role to the service principal at the scope of the storage account or container.
Grants the service principal the necessary write permissions to upload files.
Azure Role-Based Access Control (RBAC) maps the required permissions to the service principal identity to authorize storage operations.

Key Concept

App Registrations and Service Principals for On-Premises Daemon Applications
PreviousPage 18 / 49Next