All practice questions

972 questions

Question 301Question

A developer registers a multitenant web application in their organization's Microsoft Entra ID tenant. When a user from a different organization consents to use the application, which object is automatically created in that user's tenant to represent the application instance and manage its local permissions?

Show answer & explanation

Answer: A service principal

Answer

A service principal
The correct answer is the option stating a service principal. When an application is registered in Microsoft Entra ID, an application object is created in the home tenant. However, to allow the application to execute and access resources in other tenants (such as when an external user consents), Microsoft Entra ID creates a service principal in the user's tenant. This service principal represents the local instance of the application and is used to assign permissions and roles locally.

Step-by-Step Solution

1
Analyze the scenario of registering a multitenant application and consenting users from other tenants.
Identify that the application registration acts as the global definition, but each tenant needs a local representation to manage access.
Microsoft Entra ID separates the application's global configuration from its local instance details.
2
Determine the object type that represents this local instance.
A service principal object is created in the consenting tenant to act as the identity for the application instance.
The service principal governs the actual security token issuance and resource access permissions within that specific tenant.

Key Concept

Difference between App Registrations and Service Principals in multitenant environments
Question 302Question

You deploy a Java application to a Linux-based Azure App Service. You must configure a diagnostic logging solution that meets the following requirements:
- Capture the stdout and stderr streams of the container and save them to an Azure Storage account for long-term archiving.
- View the logs in real-time from your local terminal during troubleshooting sessions.

Which two actions should you perform? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Create a diagnostic setting for the App Service that routes AppServiceConsoleLogs to the storage account.; Run the Azure CLI command az webapp log tail --name <app-name> --resource-group <group-name>.

Answer

Create a diagnostic setting for the App Service that routes AppServiceConsoleLogs to the storage account, and run the Azure CLI command az webapp log tail --name <app-name> --resource-group <group-name>.
To archive stdout/stderr on Linux App Services, you must route AppServiceConsoleLogs to your target destination using Diagnostic Settings. To view live logs directly from the terminal, the CLI tail utility must be invoked.

Step-by-Step Solution

1
Determine the correct log category for stdout and stderr on a Linux App Service.
stdout and stderr streams from a Linux container in Azure App Service are classified under AppServiceConsoleLogs.
This is different from Windows App Services, which write application trace calls to AppServiceAppLogs.
2
Select the appropriate mechanism to archive logs to a storage account.
Create an Azure Monitor Diagnostic Setting to stream AppServiceConsoleLogs to the storage account.
Linux App Services do not support direct configuration of Application Logging to Blob Storage from the built-in portal settings.
3
Select the tool for real-time log streaming from a local CLI.
The CLI command 'az webapp log tail' connects to the streaming log endpoint.
This outputs log streams continuously to the console as they occur.

Key Concept

Configuring diagnostic settings for Linux container logging and streaming container logs via CLI.
Question 303Question

You are developing a Single Page Application (SPA) in React. The application runs in the user's web browser, authenticates users via Microsoft Entra ID, and reads their calendar events from Microsoft Graph on their behalf. You are creating the app registration in Microsoft Entra ID. Which two configurations should you implement to support this scenario?

Select all that apply

Show answer & explanation

Answer: Configure the Redirect URI with the platform type set to Single-page application (SPA).; Add the delegated Calendars.Read permission for Microsoft Graph to the application registration.

Answer

Configure the Redirect URI with the platform type set to Single-page application (SPA) and add the delegated Calendars.Read permission for Microsoft Graph to the application registration.
To configure authentication and authorization for a Single Page Application (SPA) accessing Microsoft Graph on behalf of a user, the application registration must use the 'Single-page application (SPA)' platform type for the Redirect URI. This platform type enables the Authorization Code Flow with PKCE, which is the secure authentication flow recommended for browser-based clients. Additionally, because the application needs to access the user's calendar data on their behalf, the 'Calendars.Read' delegated permission must be added to the application registration so that the user (or administrator) can consent to the access.

Step-by-Step Solution

1
Determine the application type and authentication flow.
The application is a browser-based Single Page Application (SPA). Secure authentication requires using the Authorization Code Flow with PKCE rather than the implicit flow or client credentials flow.
Choosing the correct flow prevents token exposure and ensures compatibility with modern security standards.
2
Configure the Redirect URI platform type in the Entra ID application registration.
Setting the platform type specifically to 'Single-page application (SPA)' triggers the Authorization Code Flow with PKCE.
This is required to allow the client library (MSAL.js) to securely trade authorization codes for tokens without a client secret.
3
Identify and assign the correct API permission type.
Because the application accesses the resource (calendar events) on behalf of a signed-in user, the delegated permission 'Calendars.Read' must be added.
Application permissions are meant for service-to-service communication without user presence, whereas delegated permissions are correct for user-interactive sessions.

Key Concept

Configuring App Registrations in Microsoft Entra ID for Single-Page Applications (SPAs) accessing protected APIs.
Question 304Question

You host a containerized ASP.NET Core web application on a Linux-based Azure App Service. You must implement a diagnostic logging solution that routes all runtime standard output (stdout) and standard error (stderr) logs to an Azure Storage account. The logs must be retained permanently for compliance auditing, and the logging mechanism must not automatically deactivate over time. Which configuration should you implement?

Show answer & explanation

Answer: Create a diagnostic setting for the App Service, select the AppServiceConsoleLogs log category, and configure the destination to archive to your Azure Storage account.

Answer

Create a diagnostic setting for the App Service, select the AppServiceConsoleLogs log category, and configure the destination to archive to your Azure Storage account.
For Linux-based App Services, the container's standard output (stdout) and standard error (stderr) streams are the primary source of application logs. These streams are captured by the AppServiceConsoleLogs category in Azure Monitor diagnostic settings. To ensure persistent, long-term retention that doesn't expire, you must configure a diagnostic setting to forward these logs to a storage account. This bypasses the 12-hour limit associated with filesystem logging.

Step-by-Step Solution

1
Identify the platform hosting the App Service.
The application runs on a Linux-based App Service, which routes container standard output (stdout) and standard error (stderr) as its primary log streams.
Logging behavior and available configuration options differ significantly between Windows and Linux environments in Azure App Service.
2
Select the correct diagnostic log category for Linux container console logs.
The AppServiceConsoleLogs category captures stdout and stderr from the Linux container, whereas AppServiceAppLogs is reserved for Windows trace logs.
Choosing the correct platform-specific telemetry category ensures that the target log files are captured.
3
Configure the long-term log destination to bypass filesystem deactivation.
Create an Azure Monitor diagnostic setting that routes the AppServiceConsoleLogs category to an Azure Storage account.
Standard filesystem logging automatically deactivates after 12 hours, while diagnostic settings route logs persistently to external storage for auditing.

Key Concept

Configuring persistent logging for Linux-based Azure App Services using Azure Monitor diagnostic settings and the AppServiceConsoleLogs category.
Question 305Question

A software-as-a-service (SaaS) provider registers a multi-tenant web application in their home Microsoft Entra ID tenant (Tenant A). An enterprise customer (Tenant B) successfully consents to the application, allowing their users to log in. The SaaS provider now needs to grant this application read access to an Azure SQL Database located in Tenant B. Which identity object in Tenant B must be assigned the database permissions?

Show answer & explanation

Answer: The service principal object created in Tenant B that references the application object in Tenant A

Answer

The service principal object created in Tenant B that references the application object in Tenant A
The correct answer is the service principal object created in Tenant B. In Microsoft Entra ID, the application object is the global definition of the application, which is created only in the home tenant (Tenant A). When a user or administrator in Tenant B consents to the application, a service principal (also called an enterprise application) is created in Tenant B. To grant the application access to resources in Tenant B, you must assign permissions to this local service principal.

Step-by-Step Solution

1
Distinguish between the application object and the service principal in a multi-tenant scenario.
The application object is the global template residing in Tenant A, whereas the service principal is the local instance in Tenant B.
Understanding the relationship between these two objects is required to determine which one receives resource permissions.
2
Evaluate the lifecycle of the identity objects during the consent process.
Consenting to the multi-tenant application in Tenant B automatically provisions a service principal object in Tenant B.
This establishes a security principal in the target tenant that can be authenticated and authorized.
3
Assign the database permission to the appropriate identity principal.
Grant the database permissions directly to the newly created service principal in Tenant B.
Resource authorization in Azure SQL Database requires referencing a security principal local to the tenant hosting the resource.

Key Concept

Multi-tenant application architecture requires a local service principal in the consumer tenant to assign permissions to resources in that tenant.
Question 306Question

You are developing a web application that will be hosted on Azure App Service. The application must retrieve secrets from an Azure Key Vault. You decide to use a user-assigned managed identity for authentication. The application code uses the DefaultAzureCredential class from the Azure.Identity library.

You need to configure the Azure resources and the web application to enable secure access.

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

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Create a user-assigned managed identity, assign the user-assigned managed identity to the App Service web app, assign the Key Vault Secrets User role to the user-assigned managed identity's service principal, and add the AZURE_CLIENT_ID application setting containing the Client ID of the user-assigned managed identity to the App Service.
To use a user-assigned managed identity with Azure App Service and access Azure Key Vault via the Azure SDK's DefaultAzureCredential, you must first create the identity as an independent Azure resource. Then, you associate the identity with the App Service web app so the hosting environment is aware of it. Next, you assign the necessary RBAC role (Key Vault Secrets User) to the identity's principal ID on the Key Vault. Finally, you set the AZURE_CLIENT_ID application setting on the web app to specify the Client ID of the user-assigned managed identity, which ensures that DefaultAzureCredential selects the correct user-assigned identity for token requests.

Step-by-Step Solution

1
Create a user-assigned managed identity.
A standalone identity resource is provisioned in Azure with its own Client ID and Principal ID.
The identity must exist in Azure before it can be assigned to the web app or granted permissions.
2
Assign the user-assigned managed identity to the App Service web app.
The App Service web app is associated with the user-assigned managed identity.
This configuration allows the App Service infrastructure to obtain tokens on behalf of the identity.
3
Assign the Key Vault Secrets User role to the user-assigned managed identity's service principal.
The identity's service principal is authorized to retrieve secrets from the Key Vault.
The identity must have appropriate RBAC permissions to access the target resource.
4
Add the AZURE_CLIENT_ID application setting containing the Client ID of the user-assigned managed identity to the App Service.
The environment variable AZURE_CLIENT_ID is set in the App Service execution context.
DefaultAzureCredential uses this environment variable to resolve which user-assigned identity to use when multiple identities or a system identity could be present.

Key Concept

Provisioning and configuring a user-assigned managed identity for Azure App Service and Key Vault
Question 307Question

An e-commerce platform uses a Standard General Purpose v2 (GPv2) storage account to store shopping cart session states as block blobs. You configure the following lifecycle management policy to automatically delete abandoned shopping carts after 7 days:

{
"rules": [
{
"enabled": true,
"name": "delete-abandoned-sessions",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 7
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"blobIndexMatch": [
{
"name": "CartStatus",
"op": "==",
"value": "abandoned"
}
]
}
}
}
]
}

Several block blobs last modified 10 days ago have not been deleted. You confirm the lifecycle policy executed successfully within the last 24 hours. Which of the following is the most likely reason these blobs were not deleted?

Show answer & explanation

Answer: The blob index tags on the blobs use the key name 'cartstatus' in all lowercase, which fails to match the case-sensitive filter key 'CartStatus'.

Answer

The blob index tags on the blobs use the key name 'cartstatus' in all lowercase, which fails to match the case-sensitive filter key 'CartStatus'.
The correct answer is correct because Azure Blob Storage index tags are case-sensitive. The filter specifies 'CartStatus' as the key, meaning any blobs tagged with 'cartstatus' in lowercase will not match the rule and will not be processed for deletion.

Step-by-Step Solution

1
Analyze the filter criteria in the JSON lifecycle management policy.
The filter specifies a blob index match where the key 'CartStatus' must equal 'abandoned'.
This determines which blobs are scoped for the deletion rule.
2
Evaluate how Azure Storage processes blob index tag matches.
Blob index tag keys and values are strictly case-sensitive.
To identify if a casing mismatch prevents the rule from finding matching blobs.
3
Examine the mismatch between the key on the uploaded blobs ('cartstatus') and the filter key ('CartStatus').
Because 'cartstatus' does not match 'CartStatus', the blobs are excluded from the policy action.
To explain the root cause of why the 10-day-old blobs were not deleted.

Key Concept

Blob index tags are case-sensitive when used in lifecycle management filters.
Question 308Question

An enterprise ASP.NET Core application is hosted on an Azure Virtual Machine. The virtual machine has been assigned two user-assigned managed identities: IdentityA (authorized to read secrets from Azure Key Vault) and IdentityB (authorized to write to Azure Storage). To retrieve secrets, the application uses the following C# code:

csharp
var client = new SecretClient(
new Uri("https://myvault.vault.azure.net/"),
new DefaultAzureCredential()
);

When execution occurs on the virtual machine, authentication fails with a CredentialUnavailableException.

Which action must you perform to resolve the authentication failure?

Show answer & explanation

Answer: Configure the DefaultAzureCredential to target IdentityA by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of IdentityA.

Answer

Configure the DefaultAzureCredential to target IdentityA by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of IdentityA.
The correct action is to configure the DefaultAzureCredential to target IdentityA by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of IdentityA. When multiple user-assigned managed identities are assigned to a single Azure resource, the IMDS endpoint requires the client ID to resolve the ambiguity and issue the correct token.

Step-by-Step Solution

1
Analyze the exception context and resource configuration.
The virtual machine is configured with multiple user-assigned managed identities (IdentityA and IdentityB) but the application uses DefaultAzureCredential with default options.
When multiple user-assigned managed identities are assigned to a single resource, the Instance Metadata Service (IMDS) endpoint cannot automatically determine which identity to use.
2
Determine the required client-side configuration for the Azure.Identity SDK.
Identify that ManagedIdentityClientId must be set in DefaultAzureCredentialOptions to specify the target user-assigned identity.
Specifying the client ID tells DefaultAzureCredential to pass the client ID parameter to the IMDS token request, resolving the identity ambiguity.
3
Update the client initialization code.
Initialize SecretClient using the configured DefaultAzureCredential.
This allows the application to successfully authenticate and retrieve secrets from the Key Vault using the permissions of IdentityA.

Key Concept

Handling multiple user-assigned managed identities with DefaultAzureCredential in the Azure SDK
Question 309Question

You need to deploy a containerized API gateway to Azure Container Instances (ACI). The container must be integrated into a new subnet within an existing virtual network to access private back-end services. In which order should you perform the steps to configure and deploy the container group?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: Create a new subnet in the existing virtual network, delegate the subnet to the Microsoft.ContainerInstance/containerGroups service, retrieve the resource ID of the delegated subnet, and run the az container create command specifying the subnet resource ID.
To integrate an Azure Container Instances container group with a virtual network, you must first create a subnet, delegate that subnet to the Microsoft.ContainerInstance/containerGroups provider, retrieve the subnet's resource ID, and then issue the deployment command with the subnet ID referenced.

Step-by-Step Solution

1
Create a new subnet in the existing virtual network.
A subnet is successfully provisioned within the virtual network.
The network path must exist before any service-specific delegation or resource deployment can occur.
2
Delegate the subnet to the Microsoft.ContainerInstance/containerGroups service.
The subnet is delegated to the container instances service.
Subnet delegation permits Azure Container Instances to create the network profiles required to run inside the virtual network.
3
Retrieve the resource ID of the delegated subnet.
The resource ID of the subnet is obtained (e.g., via az network vnet subnet show).
The deployment command needs the precise resource identifier of the delegated subnet to position the container group correctly.
4
Run the az container create command specifying the subnet resource ID.
The ACI container group is created and integrated into the virtual network.
This initiates the container group deployment inside the configured subnet.

Key Concept

Integrating Azure Container Instances (ACI) into a virtual network via subnet delegation
Question 310Question

You are configuring a web app named `app-payments` on Azure App Service to retrieve database credentials from Azure Key Vault. You have created a user-assigned managed identity named `id-payments` and granted it GET permissions on the Key Vault secrets. You have also assigned `id-payments` to `app-payments` and added the app setting `DbConnectionString` with the value `@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/dbconn/)`. However, the web app fails to resolve the Key Vault reference at runtime.

Which configuration must you apply to resolve this issue?

Show answer & explanation

Answer: Set the App Service application setting `keyVaultReferenceIdentity` to the resource ID of the user-assigned managed identity.

Answer

Set the App Service application setting `keyVaultReferenceIdentity` to the resource ID of the user-assigned managed identity.
To use a user-assigned managed identity for Key Vault references in Azure App Service, you must explicitly set the `keyVaultReferenceIdentity` app setting to the resource ID of the user-assigned managed identity. This tells App Service which identity to use when resolving the `@Microsoft.KeyVault` references.

Step-by-Step Solution

1
Identify the authentication mechanism used for Key Vault references.
By default, Key Vault references use the system-assigned managed identity of the App Service.
Since a user-assigned managed identity is assigned, the App Service needs to know which identity to use to fetch the secrets.
2
Configure the App Service to point to the user-assigned identity.
Add an application setting named `keyVaultReferenceIdentity` with the value set to the resource ID of the user-assigned identity.
This instructs Azure App Service to use the specified user-assigned identity instead of the system-assigned identity when resolving Key Vault references.

Key Concept

Configuring Azure App Service Key Vault references with a user-assigned managed identity.
Estimated Time:1m 30s
Question 311Question

You are developing an Azure Function App (V4 runtime) that must retrieve a database connection string from an Azure Key Vault using Key Vault references. You enable a system-assigned managed identity for the Function App. You then add the following environment variable to the Function App configuration:

DbConnectionString = @Microsoft.KeyVault(SecretUri=https://mykeyvault.vault.azure.net/secrets/db-conn/)

When the function executes, it fails to connect to the database. Upon inspection, you find that the function is retrieving the raw reference string @Microsoft.KeyVault(...) instead of the secret value.

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

Show answer & explanation

Answer: The system-assigned managed identity of the Function App has not been granted permission to retrieve secrets from the Key Vault.

Answer

The system-assigned managed identity of the Function App has not been granted permission to retrieve secrets from the Key Vault.
The system-assigned managed identity of the Function App must be granted permissions to read secrets from the Key Vault. If this permission is missing, the Azure Functions runtime cannot retrieve the secret, and the environment variable is populated with the raw reference string instead of the secret value.

Step-by-Step Solution

1
Identify how Key Vault references are resolved by the Azure Functions host.
The Functions runtime uses the app's managed identity to authenticate and retrieve the secret at startup/execution.
Managed identity authentication is required to access Key Vault secrets without storing credentials in configuration.
2
Determine the behavior of an unresolved Key Vault reference.
If the identity lacks the necessary permissions, the runtime cannot retrieve the secret, and it leaves the environment variable populated with the raw reference string.
This helps locate where the authentication/authorization broke down between the Function App and Key Vault.
3
Verify permissions on the Key Vault.
Grant the system-assigned managed identity the Key Vault Secrets User role or Get permissions in an access policy.
This provides the required authorization for the Function App to fetch the connection string successfully.

Key Concept

Key Vault References and Managed Identities in Azure Functions
Estimated Time:1m 30s
Question 312Question

You are developing a backend synchronization service in C# using the Azure.Storage.Blobs SDK (v12). The service needs to update the metadata of a critical blob. However, another worker instance crashed while holding an active lease on the blob, blocking updates. To recover, your service must immediately break the existing lease, secure a new lease to prevent other instances from writing, update the blob's metadata, and clean up. Arrange the steps in the correct order to perform this workflow.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, instantiate a BlobClient, then instantiate a BlobLeaseClient. Next, break the existing lease, acquire a new lease, set the metadata using the new lease ID in the request conditions, and finally release the lease.
The correct sequence starts by obtaining a BlobClient, which is used to construct a BlobLeaseClient. Since the blob is currently locked by a crashed worker's lease, the lease must first be broken using BreakAsync. After the lease is broken, the current process must call AcquireAsync to get a new lease for itself. The metadata is then updated using SetMetadataAsync, passing the new lease ID in the request conditions to authorize the write operation on the locked blob. Finally, ReleaseAsync is called to free the lock.

Step-by-Step Solution

1
Instantiate BlobClient.
An instance of BlobClient pointing to the target blob is created.
A blob client is required to reference the target storage resource.
2
Instantiate BlobLeaseClient.
A lease client associated with the blob client is created.
The lease client is used to perform lease actions like breaking, acquiring, and releasing.
3
Call BreakAsync on the lease client.
The crashed worker's lease is broken.
A lease must be broken before another client can acquire a lease on the same blob immediately.
4
Call AcquireAsync on the lease client.
A new lease is acquired and a lease ID is generated.
Acquiring a new lease secures exclusive access for the current thread of execution.
5
Call SetMetadataAsync on the blob client.
The blob's metadata is updated.
The metadata must be written along with the lease ID inside BlobRequestConditions to satisfy the lease requirement.
6
Call ReleaseAsync on the lease client.
The lease is released.
Releasing the lease cleans up the lock and allows other workers to acquire it.

Key Concept

Managing blob leases and performing write operations under an active lease using the Azure.Storage.Blobs SDK.
Question 313Question

Your company has developed a multi-tenant software-as-a-service (SaaS) application registered in Microsoft Entra Tenant A. Several client organizations, including Tenant B, have consented to the application, which created a service principal for the application in each customer tenant. The application runs as a background daemon service and uses the client credentials flow with a client secret to access APIs in each customer's tenant. You need to rotate the client secret without causing service interruption or requiring the customers' administrators to perform any actions. Which of the following is the correct way to rotate the secret?

Show answer & explanation

Answer: Configure the new client secret on the application registration in Tenant A, update the daemon service to use the new secret, and then delete the expired secret from the application registration in Tenant A.

Answer

Configure the new client secret on the application registration in Tenant A, update the daemon service to use the new secret, and then delete the expired secret from the application registration in Tenant A.
In a multi-tenant Microsoft Entra ID scenario, the global Application object (managed via the App Registration in the home tenant) holds the authentication credentials (secrets/certificates). The local Service Principals created in consumer tenants reference the global application object for authentication checks. To rotate credentials without downtime, you add a new secret to the App Registration in the home tenant, update your service to use it, and delete the old secret. No updates or admin intervention are required in the customer tenants.

Step-by-Step Solution

1
Locate the application registration in the home tenant (Tenant A) where the multi-tenant app is registered.
Access to the global Application object configuration is obtained.
Credentials for multi-tenant applications are managed globally on the Application object, not on individual local service principals.
2
Generate a new client secret under the Certificates & secrets section of the application registration.
A new client secret value is created and becomes active immediately.
Adding a second secret allows the application to authenticate using either the old or new secret, preventing downtime during transition.
3
Update the daemon service configuration to use the new client secret value when requesting tokens.
The daemon service successfully acquires tokens for Tenant B and other customer tenants using the new secret.
Microsoft Entra ID resolves token requests by validating the provided secret against the application object in Tenant A, even when requesting tokens for Tenant B.
4
Remove the old client secret from the application registration in Tenant A.
The old client secret is revoked and can no longer be used for authentication.
Deleting the old secret ensures proper security hygiene and completes the rotation process.

Key Concept

Multi-tenant application credentials management and the relationship between Application objects (App Registrations) and Service Principals.

Alternative Method

Instead of using client secrets, you can upload a client certificate to the application registration in Tenant A. For production environments, authenticating via a certificate stored securely in Azure Key Vault is the recommended practice for rotation and security compliance.
Estimated Time:3m 0s
Question 314Question

A company is developing a globally distributed retail catalog application. The database is hosted on an Azure Cosmos DB API for NoSQL account with a single write region in East US and a read-only replica in West US. The application requires that multiple independent client applications reading from the West US region must observe updates in the exact sequence they were committed in East US. To optimize performance and reduce request unit (RU) consumption, the consistency level must offer the lowest latency and resource cost possible while still guaranteeing ordered reads. Which consistency level should you configure for the Azure Cosmos DB account?

Show answer & explanation

Answer: Consistent Prefix

Answer

Consistent Prefix
Consistent Prefix consistency guarantees that reads never see out-of-order writes. It ensures that updates are returned in the order they were made, while offering the lowest read latency and Request Unit (RU) cost (matching Eventual consistency).

Step-by-Step Solution

1
Analyze client session constraints.
Multiple independent client applications need to see updates in order, which rules out Session consistency unless session tokens are manually passed and synchronized.
Session consistency is scoped to a single client session by default.
2
Evaluate ordering guarantees.
The clients must observe updates in the sequence they were committed, which rules out Eventual consistency.
Eventual consistency does not guarantee read order.
3
Compare Consistent Prefix and Strong consistency.
Consistent Prefix satisfies the order requirement with the lowest latency and resource cost, whereas Strong consistency incurs high latency and double the RU cost.
Consistent Prefix offers the same low latency and RU cost as Eventual consistency.

Key Concept

Azure Cosmos DB Consistency Levels
Estimated Time:1m 30s
Question 315Question

You are developing a background daemon service that will run on an on-premises server. The service must periodically scan all user mailboxes in your organization's Microsoft Entra ID tenant and archive email attachments to Azure Blob Storage. The service will run in the background without any user interaction or sign-in.

You register the application in Microsoft Entra ID. You need to configure the API permissions and authentication requirements.

Which two actions should you perform to configure the application registration and permissions? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the application registration with the Mail.Read Application permission for the Microsoft Graph API.; Grant tenant-wide admin consent for the configured Microsoft Graph API permission.

Answer

The correct actions are to configure the application registration with the Mail.Read Application permission for the Microsoft Graph API and to grant tenant-wide admin consent for the configured Microsoft Graph API permission.
A background daemon service runs without a user context. Therefore, it requires Application permissions instead of Delegated permissions to access resources like mailboxes. Furthermore, since Application permissions allow broad access to all resources of that type in the tenant, they must be approved by a directory administrator via tenant-wide admin consent.

Step-by-Step Solution

1
Determine the application type and user context.
The application is identified as a daemon service that runs in the background without user interaction.
This establishes that application permissions must be used instead of delegated permissions, since no user will be logging in.
2
Select the appropriate permission type in the application registration.
The application is configured with the Mail.Read Application permission.
Application permissions are intended for applications that run without a signed-in user.
3
Grant tenant consent for the configured application permission.
A tenant administrator grants tenant-wide admin consent for the permission in the Azure Portal or using CLI.
Application permissions grant broad access to resources (e.g. all mailboxes) and therefore cannot be consented to by regular users.

Key Concept

App Registrations, Service Principals, and Application vs Delegated Permissions
Estimated Time:2m 0s
Question 316Question

You are developing an ASP.NET Core web application hosted on Azure App Service that retrieves database connection strings from Azure Key Vault. The application uses the DefaultAzureCredential class from the Azure.Identity library to authenticate. To meet security requirements, the managed identity must be exclusive to this App Service instance, and its lifecycle must be bound directly to the App Service. You run the command 'az webapp identity assign --name MyWebApp --resource-group MyResourceGroup' to configure the App Service. However, when the web application starts up and attempts to retrieve a secret, a credential retrieval error occurs. Which of the following actions should you perform to resolve this issue?

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.

Answer

Assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope.
The correct action is to assign the Key Vault Secrets User role to the App Service's system-assigned managed identity at the Key Vault scope. Running the Azure CLI command enables the system-assigned managed identity on the App Service. However, to access the Key Vault secrets, the identity must be explicitly authorized. The Key Vault Secrets User role provides the necessary data-plane permissions for reading secrets. Using a system-assigned identity satisfies the requirement that the identity's lifecycle is bound directly to the resource.

Step-by-Step Solution

1
Analyze the identity requirements
The requirement states that the identity must be exclusive and its lifecycle bound directly to the App Service, which specifies a system-assigned managed identity.
This helps identify if the command run ('az webapp identity assign') correctly enabled the system-assigned managed identity, which it did.
2
Diagnose the error cause
The identity exists on the App Service but cannot read secrets from the Key Vault, indicating a missing data-plane permission (RBAC role or Key Vault access policy).
Enabling the identity on the host resource only registers it in Microsoft Entra ID; it does not grant permissions to other Azure resources automatically.
3
Determine the correct authorization level
Assign the Key Vault Secrets User role (or equivalent access policy) to the system-assigned managed identity at the Key Vault scope.
This grants the application permission to read secrets (data-plane access) while keeping the lifecycle bound to the App Service.

Key Concept

Authorizing a system-assigned managed identity to access Azure Key Vault secrets using Role-Based Access Control (RBAC).
Question 317Question

You are configuring security for an Azure Function App that needs to read files from an Azure Storage account. You want to use a managed identity to authenticate. You must determine the characteristics of system-assigned and user-assigned managed identities to choose the best option.

Which of the following statements about these managed identity types are correct? (Select TWO)

Select all that apply

Show answer & explanation

Answer: A system-assigned managed identity is automatically deleted when the associated Azure resource is deleted.; A user-assigned managed identity is created as a standalone Azure resource and its lifecycle is independent of the resources it is assigned to.

Answer

A system-assigned managed identity is automatically deleted when the associated Azure resource is deleted, and a user-assigned managed identity is created as a standalone Azure resource whose lifecycle is independent of the resources it is assigned to.
The correct statements correctly describe the lifecycle boundaries. A system-assigned managed identity is enabled directly on a resource, and deleting that resource automatically deletes the identity. Conversely, a user-assigned managed identity is created as an independent resource in Azure, meaning its lifecycle is separate and it remains in existence even if all resources utilizing it are deleted.

Step-by-Step Solution

1
Analyze the lifecycle characteristics of a system-assigned managed identity.
Confirm that system-assigned identities are tied to the resource lifecycle and deleted when the resource is deleted.
This is a fundamental property of system-assigned managed identities.
2
Analyze the lifecycle and sharing characteristics of a user-assigned managed identity.
Confirm that user-assigned identities are standalone resources, have independent lifecycles, and can be assigned to multiple resources.
This distinguishes user-assigned identities from system-assigned ones.
3
Identify the two correct statements that match these verified characteristics.
The statement about automatic deletion of system-assigned identities and the statement about user-assigned identities being standalone resources with independent lifecycles are selected.
These statements correctly state the properties of managed identities without introducing misconceptions.

Key Concept

Understanding the differences in lifecycle, resource sharing, and configuration properties between system-assigned and user-assigned managed identities in Azure.
Question 318Question

You are deploying a single Azure App Service web app that needs to retrieve database credentials securely. You want to enable a managed identity for the web app to access Azure Key Vault. The identity must share the lifecycle of the App Service resource, meaning that if the App Service is deleted, the identity is automatically cleaned up. Which identity type or configuration should you implement for the App Service?

Show answer & explanation

Answer: A system-assigned managed identity

Answer

A system-assigned managed identity
A system-assigned managed identity is enabled directly on an Azure resource (such as an App Service). Its lifecycle is bound directly to that resource; when the host resource is deleted, Azure automatically deletes the identity in Microsoft Entra ID. This avoids leaving orphaned identity resources behind and simplifies lifecycle management.

Step-by-Step Solution

1
Analyze the requirements for the identity lifecycle.
The identity must be tied directly to the lifecycle of the App Service and deleted automatically if the App Service is deleted.
This requirement determines whether a system-assigned or user-assigned identity is appropriate.
2
Compare system-assigned and user-assigned managed identity lifecycles.
System-assigned identities are tied to the host resource's lifecycle, while user-assigned identities are standalone resources with independent lifecycles.
System-assigned identities satisfy the requirement of automatic cleanup upon resource deletion.
3
Select the correct configuration option.
Enable a system-assigned managed identity on the App Service.
This aligns exactly with the design goal of automatic lifecycle cleanup.

Key Concept

Managed Identity Lifecycle Management
Question 319Question

A backend service is being updated to coordinate access to a shared log file stored in Azure Blob Storage. To ensure thread safety when modifying metadata, the service must obtain a write lease, perform the metadata update, and clean up the lease. What is the correct sequence of operations to complete this task using the Azure.Storage.Blobs namespace?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: Instantiate a BlobClient representing the target log blob, initialize a BlobLeaseClient using the BlobClient and call AcquireAsync to obtain a lease ID, call SetMetadataAsync on the BlobClient passing a BlobRequestConditions object initialized with the lease ID, and then invoke ReleaseAsync on the BlobLeaseClient to unlock the blob.
To update a leased blob, a client must first establish a BlobClient, use it to initialize a BlobLeaseClient, acquire the lease, apply the metadata update by passing the lease ID in the request conditions, and finally release the lease to unlock the resource.

Step-by-Step Solution

1
Obtain a BlobClient reference.
An active client reference to the target blob is established.
Both the lease client initialization and the metadata update require the underlying BlobClient.
2
Create a BlobLeaseClient and call AcquireAsync.
A lease lock is successfully acquired on the blob, generating a lease ID.
The blob must be locked prior to any modification to prevent concurrent writes from other instances.
3
Invoke SetMetadataAsync with BlobRequestConditions containing the lease ID.
The metadata on the leased blob is updated.
Since the blob has an active lease, all write operations must explicitly include the lease ID to prove ownership of the lock.
4
Call ReleaseAsync on the BlobLeaseClient.
The lease is released, clearing the write lock.
Releasing the lease unlocks the blob, enabling other operations and clients to modify it.

Key Concept

Acquiring, using, and releasing exclusive-write leases during metadata updates using the Azure Storage SDK for .NET.
Question 320Question

An enterprise microservice architecture uses an Azure Cosmos DB SQL API container to store user profiles. The container's partition key path is set to `/userId`, and the database account uses Session consistency. Each user profile is managed by independent client applications running on different host nodes.

A write operation executed by one client node updates a user profile. Immediately following this write, a second client node needs to retrieve the updated profile. To achieve read-your-writes consistency across these separate client nodes, you must retrieve the write operation's session state and apply it to the read request.

Which C# code segment using the Cosmos DB .NET SDK v3 correctly implements this consistency requirement?

Show answer & explanation

Answer: // App Service A
ItemResponse<UserProfile> response = await container.UpsertItemAsync<UserProfile>(profile, new PartitionKey(profile.UserId));
string sessionToken = response.Headers.Session;

// App Service B
ItemRequestOptions options = new ItemRequestOptions { SessionToken = sessionToken };
ItemResponse<UserProfile> response = await container.ReadItemAsync<UserProfile>(userId, new PartitionKey(userId), options);

Answer

The correct option captures the session token from the headers of the write response and sets it on the request options of the read operation.
The correct option captures the session token string from the write response headers (`response.Headers.Session`) on the first client instance, transmits it to the second client instance, and assigns it to the `SessionToken` property of the `ItemRequestOptions` object passed to the read operation. This ensures that the second instance can perform a point read that acknowledges the session state of the write operation, fulfilling the read-your-writes consistency model.

Step-by-Step Solution

1
Capture the session token from the write operation's output headers in the writing client instance.
The session token string is retrieved from the `Session` property of the `Headers` object in the write response.
The write response headers contain the latest session state required to preserve session guarantees on subsequent operations.
2
Pass the captured session token to the reading client instance.
The reading client instance obtains the session token string.
Different client instances do not share session tokens automatically, so the token must be communicated out-of-band or via application logic.
3
Instantiate an `ItemRequestOptions` object on the reading client instance and set its `SessionToken` property to the captured token.
A request options object configured with the session token is created.
The .NET SDK v3 requires the session token to be supplied per-request via `ItemRequestOptions` to enforce session consistency.
4
Execute the point read operation using `ReadItemAsync`, passing the item ID, the partition key (constructed from `/userId`), and the request options.
The item is successfully retrieved with read-your-writes guarantees.
Providing the session token and the partition key ensures a consistent, low-latency point read of the updated item.

Key Concept

Session token propagation across different SDK client instances using ItemRequestOptions
Estimated Time:2m 0s
PreviousPage 16 / 49Next
All practice questions — Microsoft Azure Developer (AZ-204) | Examkin