All practice questions

972 questions

Question 321Question

You are designing the security architecture for a C# web application deployed to two distinct Azure App Service instances in different regions (East US and West US) to support active-active high availability. Both App Service instances must retrieve database connection strings from a shared Azure Key Vault and connect to a shared Azure SQL Database without storing credentials in code or configuration files.

The design must satisfy the following security and operational constraints:
- Minimize administrative overhead by avoiding the creation of separate database users and Key Vault access policies/RBAC roles for each regional App Service instance.
- Ensure that if one of the App Service instances is deleted, the identity used to authenticate to the Key Vault and Azure SQL Database remains intact and functional for the remaining instance.
- The application code must use the C# Azure.Identity SDK and instantiate DefaultAzureCredential to authenticate to both services.

Which configuration and code setup should you implement to meet these requirements?

Show answer & explanation

Answer: Create one user-assigned managed identity. In the App Service ARM templates, set the identity.type property to UserAssigned and configure the identity's resource ID in the userAssignedIdentities property. Configure the AZURE_CLIENT_ID application setting on both App Services with the client ID of the user-assigned managed identity, and instantiate DefaultAzureCredential in C# code.

Answer

Create one user-assigned managed identity, configure the App Service ARM templates to use the UserAssigned identity type mapping the resource ID, set the AZURE_CLIENT_ID environment variable on the App Services, and instantiate DefaultAzureCredential in C# code.
The correct option configures a user-assigned managed identity, which operates independently of individual App Service lifecycles and can be shared across regions to minimize permissions management overhead. It correctly sets the identity type to UserAssigned in ARM and configures the AZURE_CLIENT_ID environment variable, which enables DefaultAzureCredential to resolve the identity successfully at runtime.

Step-by-Step Solution

1
Analyze the identity lifecycle and sharing requirements.
A user-assigned managed identity (UAMI) is chosen because it exists as an independent Azure resource and can be assigned to multiple App Service instances, avoiding duplicated database users and policies.
System-assigned identities are tied to a single resource's lifecycle and cannot be shared across multiple resources.
2
Determine the correct ARM template configuration.
Set the identity.type property to UserAssigned and reference the identity's resource ID within the userAssignedIdentities property block.
Setting the type to SystemAssigned or using the principal ID in the configuration block is invalid configuration syntax for user-assigned identities.
3
Configure the App Service environment and C# code.
Add the AZURE_CLIENT_ID application setting containing the client ID of the user-assigned identity to both App Services, and initialize DefaultAzureCredential in C#.
Without the client ID specified via the AZURE_CLIENT_ID environment variable, DefaultAzureCredential will not be able to identify which user-assigned identity to use when requesting tokens.

Key Concept

Selecting and configuring user-assigned managed identities for multi-resource sharing, independent lifecycles, and resolution with DefaultAzureCredential.
Question 322Question

An administrator is configuring a Microsoft Entra ID app registration for a background daemon service that runs nightly without any user interaction. The daemon service must read all user profiles in the tenant using the Microsoft Graph API.

Which of the following configuration steps are required to implement this? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Configure the Application permission type for Microsoft Graph's User.Read.All.; Grant tenant-wide admin consent for the configured User.Read.All permission.

Answer

Configure the Application permission type for Microsoft Graph's User.Read.All, and grant tenant-wide admin consent for the permission.
For background services or daemons running without user interaction, Application permissions must be used because there is no signed-in user. Because the User.Read.All permission allows access to all user profiles in the tenant, Microsoft Entra ID requires tenant-wide admin consent to be granted before the token can be issued.

Step-by-Step Solution

1
Identify the application interaction model.
Since the background daemon service runs nightly without any user interaction, it cannot run in the context of a signed-in user.
This establishes that Application permissions are required instead of Delegated permissions.
2
Determine the necessary permission scope and administrative requirements.
Microsoft Graph requires the User.Read.All application permission for reading all user profiles, which requires tenant-wide admin consent.
An administrator must grant consent before the daemon service can acquire a token to access tenant-wide profile data.

Key Concept

Differentiating between Delegated and Application permissions and understanding administrative consent requirements for Microsoft Entra ID app registrations.
Question 323Question

You are configuring a custom domain `www.contoso.com` for an Azure App Service web app named `app-prod-west`. You must secure the custom domain by using a free App Service Managed Certificate. Which sequence of steps should you perform to complete the configuration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

First, create a CNAME record mapping the domain to the app's default host name. Second, add the custom domain to the App Service web app. Third, create a free App Service Managed Certificate. Finally, create a TLS/SSL binding associating the domain with the certificate.
To secure a custom domain using an App Service Managed Certificate, the domain must first be pointed to the web app's default URL via DNS. Once the DNS propagates, you register the custom domain in the App Service. After registration, Azure can issue the managed certificate for that validated domain. Finally, you bind the domain to the certificate to enable HTTPS traffic.

Step-by-Step Solution

1
Configure DNS mapping
The DNS registrar has a CNAME record mapping `www.contoso.com` to `app-prod-west.azurewebsites.net`.
Azure App Service must verify domain ownership via external DNS queries before allowing registration.
2
Register the domain on Azure
The domain is successfully validated and added to the Custom Domains blade of the web app.
The web app must be configured to accept and route requests coming from the custom host name.
3
Generate the managed certificate
Azure generates and renews a free App Service Managed Certificate for the domain.
The certificate can only be issued once Azure can verify that the custom domain resolves to the App Service web app.
4
Apply TLS/SSL binding
The custom domain is configured with SNI SSL using the managed certificate, securing HTTPS traffic.
Applying the binding completes the setup and secures incoming traffic on port 443.

Key Concept

Configuring custom domains and securing them with App Service Managed Certificates in Azure App Service.
Question 324Question

An organization requires a web application running on Azure App Service to query an Azure SQL Database. The security policy mandates the use of a user-assigned managed identity to eliminate hardcoded credentials. You must perform the configuration steps using the Azure CLI and SQL commands, and configure the .NET application code to connect securely. Which sequence of steps must you perform to provision, configure, and authenticate the application using the user-assigned managed identity?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the user-assigned managed identity using the CLI. Next, assign this identity to the Azure App Service web app. After that, create a contained user for the identity within the Azure SQL Database and grant the database reader role. Then, configure the App Service app settings by adding the client ID of the user-assigned identity to the client ID environment variable. Finally, write application code using the default Azure credential to connect to the database.
The correct sequence flows logically from infrastructure provisioning to application deployment. The identity must be created first before it can be assigned to the web app or authorized in the SQL Database. The app settings must be updated to reference the client ID before the application code is executed, allowing the default Azure credential to correctly resolve the user-assigned identity at runtime.

Step-by-Step Solution

1
Run `az identity create` to provision the user-assigned managed identity.
A user-assigned managed identity is created in Microsoft Entra ID.
You cannot associate an identity or authorize it in other services until it exists.
2
Run `az webapp identity assign` to link the identity to the App Service web app.
The App Service is configured to use the user-assigned managed identity.
This allows the App Service infrastructure to acquire tokens on behalf of the user-assigned identity.
3
Run SQL DDL commands to create a contained user from the external provider.
The identity is authorized inside the target SQL database.
Managed identities authenticate against Microsoft Entra ID, and SQL Database must map this identity to a contained user to authorize access.
4
Set the `AZURE_CLIENT_ID` application setting on the App Service.
The application runtime environment exposes the client ID to the credential libraries.
Unlike system-assigned identities, user-assigned identities require specifying the client ID. The default Azure credential checks this environment variable to know which user-assigned identity to select.
5
Initialize `DefaultAzureCredential` and establish the database connection.
The application successfully connects to the SQL database using passwordless authentication.
The credential library automatically picks up the client ID environment variable and requests a token for Azure SQL Database from the local endpoint.

Key Concept

Configuring a user-assigned managed identity for App Service to access Azure SQL Database requires identity creation, resource association, target system authorization, runtime client ID configuration, and default SDK credential usage.
Question 325Question

You are developing a C# background service that processes large video files stored in Azure Blob Storage using the Azure.Storage.Blobs SDK (v12). To prevent multiple instances of the service from processing the same video simultaneously, each instance first acquires an exclusive lease on the target blob. Once processing is complete, the service must perform the following tasks in a thread-safe manner that maintains the concurrency lock until all changes are committed:

1. Write a custom metadata tag to the blob with the key "Status" and the value "Processed".
2. Release the lease immediately afterward to allow other services to access the blob.

The helper method signature is defined as follows:

csharp
public async Task CompleteProcessingAsync(BlobClient blobClient, BlobLeaseClient leaseClient, string leaseId)
{
// Implementation
}

Which of the following code blocks should you use to implement this method?

Show answer & explanation

Answer: csharp
var metadata = new Dictionary<string, string> { { "Status", "Processed" } };
var conditions = new BlobRequestConditions { LeaseId = leaseId };
await blobClient.SetMetadataAsync(metadata, conditions);
await leaseClient.ReleaseAsync();

Answer

The correct implementation creates a metadata dictionary with the key 'Status', applies it using a BlobRequestConditions object initialized with the active lease ID, and then releases the lease.
The correct implementation updates the metadata first while holding the lease lock, by passing the lease ID within a BlobRequestConditions object to SetMetadataAsync. This prevents concurrent modifications. Once the metadata is successfully updated, ReleaseAsync is called to safely release the lease. In the modern Azure.Storage.Blobs SDK (v12), custom metadata dictionary keys do not require the 'x-ms-meta-' prefix as the SDK manages HTTP header conversions automatically.

Step-by-Step Solution

1
Configure the metadata dictionary keys.
Use 'Status' as the dictionary key without the 'x-ms-meta-' prefix.
The Azure.Storage.Blobs SDK automatically handles the 'x-ms-meta-' HTTP header prefix wrapper during request serialization.
2
Enforce concurrency during the metadata update.
Instantiate a BlobRequestConditions object and assign the LeaseId property to the active leaseId string.
Azure Blob Storage requires the active lease ID to modify any blob or container that currently holds an active exclusive lease lock.
3
Sequence the operations safely.
Invoke SetMetadataAsync with the request conditions first, and then invoke ReleaseAsync on the BlobLeaseClient.
Releasing the lease first exposes the blob to concurrent modifications by other processes before the final state is committed.

Key Concept

Blob Lease Concurrency and SDK Metadata Handling

Alternative Method

Alternatively, you can perform the metadata update directly on the BlobLeaseClient instance if using specific SDK versions, but using BlobRequestConditions on the BlobClient is the standard method for granular condition control.
Estimated Time:3m 0s
Question 326Question

An organization stores system logs in a Standard General Purpose v2 (GPv2) storage account. You are reviewing the following Azure Blob Storage lifecycle management policy:

{
"rules": [
{
"enabled": true,
"name": "log-retention-policy",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
},
"tierToArchive": {
"daysAfterModificationGreaterThan": 90
},
"delete": {
"daysAfterModificationGreaterThan": 180
}
}
},
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "logs/system-" ],
"blobIndexMatch": [
{
"name": "Environment",
"op": "==",
"value": "Production"
}
]
}
}
}
]
}

Which two of the following statements regarding the behavior and execution of this policy are true?

Select all that apply

Show answer & explanation

Answer: The policy rule runs automatically once every 24 hours to transition and delete blobs that match the filter criteria.; Only block blobs with index tags matching the exact case of key 'Environment' and value 'Production' are processed by this rule.

Answer

The policy rule runs automatically once every 24 hours to transition and delete matching blobs, and only block blobs with index tags matching the exact case of key 'Environment' and value 'Production' are processed.
The correct options are that the policy runs automatically once every 24 hours and that blob index tags are case-sensitive. Lifecycle management is a scheduled platform service running once a day, and the tag filters require exact casing match (e.g., 'Environment' and 'Production').

Step-by-Step Solution

1
Evaluate the execution schedule of lifecycle management policies.
The policies are run automatically by the Azure platform once every 24 hours.
This is a platform-scheduled job and does not run continuously or instantly upon blob modification.
2
Analyze the case-sensitivity of the blob index tags filter.
Blob index tags are case-sensitive, so the policy will only match tags that exactly match 'Environment' and 'Production'.
Casing mismatch prevents the filter from evaluating to true.
3
Check the effect of active leases on lifecycle execution.
Active leases do not block platform-level lifecycle transitions or deletions.
Platform-initiated actions bypass client-held leases.
4
Determine authorization requirements.
No SAS token is required for native platform policies.
Azure manages the execution context internally.

Key Concept

Azure Blob Storage Lifecycle Management Execution and Filter Rules
Question 327Question

An enterprise architecture requires implementing two new applications integrated with Microsoft Entra ID:

1. SyncDaemon: A background service that runs without user interaction to synchronize user profile information across all users in the tenant.
2. UserPortal: A single-page application (SPA) using the OAuth 2.0 authorization code flow with PKCE, allowing signed-in users to view their own profile and access a custom secure web API.

You need to configure the permissions, scopes, and consent for both applications following the principle of least privilege.

Which two configurations should you implement?

Select all that apply

Show answer & explanation

Answer: Configure SyncDaemon with the Microsoft Graph Application permission User.Read.All and have a tenant administrator grant tenant-wide consent.; Configure UserPortal with the Microsoft Graph Delegated permission User.Read and define a custom scope in the format api://<API_ClientId>/Access on the custom web API registration.

Answer

Configure SyncDaemon with the Microsoft Graph Application permission User.Read.All with tenant admin consent, and configure UserPortal with the Microsoft Graph Delegated permission User.Read and a custom scope on the custom web API registration.
The background service SyncDaemon has no signed-in user context and therefore requires Application permissions (User.Read.All) which always require tenant admin consent. The Single Page Application UserPortal operates in a user context, requiring Delegated permissions (User.Read), and accesses the custom web API using a custom scope registered on the target API's registration in Microsoft Entra ID.

Step-by-Step Solution

1
Determine the application type and user context for SyncDaemon.
SyncDaemon is identified as a daemon application running without user interaction.
This establishes that Application permissions (rather than Delegated permissions) must be used, which consequently requires tenant admin consent.
2
Determine the application type and user context for UserPortal.
UserPortal is identified as a Single Page Application (SPA) where users sign in.
This establishes that Delegated permissions must be used because operations are performed on behalf of the signed-in user.
3
Select the correct permission scopes and authentication mechanism for accessing the custom web API.
A custom scope exposed on the API application registration is defined using the App ID URI prefix.
This allows the SPA to request a token specifically scoped for the custom web API using Entra ID, rather than relying on storage-specific mechanisms like Shared Access Signatures.

Key Concept

Microsoft Entra ID Application vs. Delegated Permissions and API Scopes
Question 328Question

You have an existing Azure Function App (V4 runtime) that uses a standard connection string for the host storage account configuration (AzureWebJobsStorage). To comply with security policies, you must migrate the Function App to use an identity-based connection instead of connection secrets.

Which sequence of steps should you perform to configure the Function App to use a system-assigned managed identity for its host storage?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To configure the Function App to use a system-assigned managed identity for host storage, first enable the system-assigned managed identity on the Function App. Next, assign the Storage Blob Data Owner, Storage Queue Data Contributor, and Storage Table Data Contributor roles to the managed identity. Then, add the AzureWebJobsStorage__accountName application setting to the Function App configuration. Finally, delete the connection string value named AzureWebJobsStorage from the Function App application settings.
The correct sequence begins with enabling the system-assigned managed identity to generate the service principal ID. Once the principal is created, the required Azure RBAC roles must be assigned to grant the identity access to the storage account. The configuration settings must then be updated by adding the AzureWebJobsStorage__accountName setting to specify the target storage account name. Finally, the legacy AzureWebJobsStorage connection string setting must be deleted, as connection string settings take precedence over identity-based configurations.

Step-by-Step Solution

1
Enable a system-assigned managed identity on the Function App.
A system-assigned managed identity principal is created in Microsoft Entra ID for the Function App.
An identity principal must exist in Microsoft Entra ID before it can be assigned Azure role-based access control (RBAC) roles.
2
Assign Storage Blob Data Owner, Storage Queue Data Contributor, and Storage Table Data Contributor roles to the managed identity.
The identity principal is granted permission to read, write, and manage blobs, queues, and tables within the storage account.
The Azure Functions host runtime requires specific permissions to coordinate executions, manage leases, and log data. These roles must be assigned before removing connection secrets to prevent runtime initialization failures.
3
Add the application setting AzureWebJobsStorage__accountName to the Function App.
The setting instructs the Functions runtime to connect to the specified storage account using the identity.
Specifying the accountName tells the host to locate the target storage account and use the default credential flow (system-assigned managed identity) to establish the connection.
4
Delete the AzureWebJobsStorage connection string setting.
The legacy connection string containing secrets is removed from the Function App.
If the legacy AzureWebJobsStorage setting is left in place, it takes precedence over the identity-based configuration, and the app will continue to use the connection string secret.

Key Concept

Configuring Azure Functions host storage with identity-based connections using system-assigned managed identity.
Estimated Time:2m 0s
Question 329Question

You are developing a .NET application to move log files between two different Azure Storage accounts. You write the following code using the Azure.Storage.Blobs SDK to copy a blob:

csharp
// Source blob client and destination blob client are initialized.
var sourceBlobClient = sourceContainerClient.GetBlobClient("logs/app.log");
var destBlobClient = destContainerClient.GetBlobClient("archive/app.log");

// Generate source URI with a SAS token.
Uri sourceUri = GetSourceUriWithSas(sourceBlobClient);

// Start the copy operation.
CopyFromUriOperation operation = await destBlobClient.StartCopyFromUriAsync(sourceUri);

// Poll for completion.
await operation.WaitForCompletionAsync();

Which configuration or behavior is correct regarding the SAS token permissions and blob properties for this operation?

Show answer & explanation

Answer: The source SAS token only needs the Read ('r') permission, and all user-defined metadata is copied to the destination by default.

Answer

The source SAS token only needs the Read ('r') permission, and all user-defined metadata is copied to the destination by default.
The correct answer states that the source SAS token only needs the Read ('r') permission, and all user-defined metadata is copied to the destination by default. During an asynchronous copy operation initiated by the destination BlobClient, the target storage account accesses the source URI to read the blob. Consequently, the SAS token on the source URI only needs to grant read access. By default, metadata is copied over to the new blob without requiring manual prefixing or lowercase conversions.

Step-by-Step Solution

1
Analyze the access requirement for the source blob during a copy operation.
The destination storage account must read the source blob to retrieve its contents. Thus, only the Read ('r') permission is required on the source SAS token.
Since the copy destination is authorized separately (via the client credential for the destination), the source SAS token does not need Write permissions.
2
Analyze how leases affect copy operations on the source.
Leases prevent modifications and deletions. Since copying from a source is a read-only operation, a lease on the source does not block the copy.
You do not need to manage or supply the source lease ID for read-only actions.
3
Determine how metadata is handled during a copy.
All existing user-defined metadata is copied to the destination blob automatically.
Azure Storage preserves properties and metadata by default unless they are explicitly overridden in the copy request.

Key Concept

Blob copy operations using StartCopyFromUriAsync only require read access to the source blob via its SAS token, do not require lease clearance on the source, and preserve metadata automatically.
Question 330Question

A company is deploying a background synchronization service on an external cloud provider's virtual machine. The service requires access to Azure resources. You register the service as an application in Microsoft Entra ID. To comply with corporate security policies, the service must authenticate using a certificate instead of a client secret. Which configuration step must you perform in Microsoft Entra ID to enable this authentication?

Show answer & explanation

Answer: Upload the public key of the certificate to the application registration's certificates and secrets settings.

Answer

Upload the public key of the certificate to the application registration's certificates and secrets settings.
To authenticate an application registration with a certificate, the public key of the certificate must be uploaded to the app registration's Certificates & secrets settings. The client application then uses its private key to sign a client assertion when requesting a token from Microsoft Entra ID, which Entra ID verifies using the uploaded public key.

Step-by-Step Solution

1
Generate a self-signed or CA-signed certificate and extract its public key (e.g., in .cer format).
You obtain a public key file and a private key file.
The public key will be uploaded to Microsoft Entra ID, while the private key remains secure on the client machine.
2
Navigate to the application registration in Microsoft Entra ID and upload the public key under the Certificates & secrets section.
Microsoft Entra ID registers the certificate and associates it with the application object.
Entra ID needs the public key to verify client assertions signed by the client application using the matching private key.
3
Configure the client application to sign a client assertion JWT using the private key and send it to the Entra ID token endpoint to request an access token.
Microsoft Entra ID validates the signature with the uploaded public key and returns an access token.
This completes the OAuth 2.0 client credentials flow using a certificate instead of a client secret.

Key Concept

Certificate-based authentication for App Registrations and Service Principals in Microsoft Entra ID.
Question 331Question

You are developing a C# application using the Azure.Storage.Blobs SDK (v12) to process documents in Azure Blob Storage. The application must retrieve a custom metadata property named ComplianceStatus from a blob, update its value to Approved, and save it back to the blob while preserving all other existing metadata.

You write the following method:

csharp
public static async Task UpdateComplianceStatusAsync(BlobClient blobClient)
{
BlobProperties properties = await blobClient.GetPropertiesAsync();

// Retrieve the existing compliance status
string currentStatus = [CODE_BLOCK_1];

if (currentStatus != "Approved")
{
// Update the compliance status
[CODE_BLOCK_2]
}
}

Which combination of code segments should you use to complete the method?

Show answer & explanation

Answer: [CODE_BLOCK_1]: properties.Metadata["ComplianceStatus"]
[CODE_BLOCK_2]:
properties.Metadata["ComplianceStatus"] = "Approved";
await blobClient.SetMetadataAsync(properties.Metadata);

Answer

Retrieve the existing metadata value using properties.Metadata["ComplianceStatus"], assign the new value to the key in the same dictionary, and save it using await blobClient.SetMetadataAsync(properties.Metadata).
The correct option correctly references the ComplianceStatus metadata key without the x-ms-meta- prefix. Because the Azure.Storage.Blobs SDK handles the header translation internally, the dictionary keys in properties.Metadata map directly to the custom metadata names. Furthermore, the correct option updates the key directly on the retrieved properties.Metadata dictionary and passes it to SetMetadataAsync, which correctly preserves all other existing metadata key-value pairs.

Step-by-Step Solution

1
Retrieve existing blob properties
The properties object contains a Metadata dictionary that has the x-ms-meta- prefix stripped from all keys.
Before updating, we must retrieve the current metadata to avoid overwriting or losing other existing metadata keys.
2
Access and modify the specific key in the retrieved metadata dictionary
The value of the ComplianceStatus key is updated to Approved in properties.Metadata, leaving other keys unchanged.
By modifying the existing dictionary, we ensure that other existing metadata elements are preserved.
3
Call SetMetadataAsync with the modified dictionary
The blob's metadata is updated in Azure Storage with the changes.
Calling SetMetadataAsync replaces the target blob's metadata with the dictionary passed, so passing the modified dictionary successfully applies the update while preserving the rest of the metadata.

Key Concept

Azure Storage Blobs SDK v12 metadata operations require referencing dictionary keys without the x-ms-meta- prefix, and updates replace the entire metadata collection on the target resource.
Question 332Question

An organization is deploying a globally distributed discussion forum application. The database is hosted on an Azure Cosmos DB API for NoSQL account configured with a single write region in East US and a read region in West US. To prevent hot partitions, the development team has configured a high-cardinality partition key on the container. The application requires that users reading posts in West US must always see updates in the exact chronological order in which they were written. Additionally, the database must minimize Request Unit (RU) costs, ensuring read operations consume only 1 RU. Which two consistency levels should you select to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Session; Consistent Prefix

Answer

Session and Consistent Prefix
The correct options are Session and Consistent Prefix. Consistent Prefix guarantees that readers will see updates in the order they were written. Session consistency also guarantees consistent prefix order (along with read-your-writes, monotonic reads, and monotonic writes within a session). Both Session and Consistent Prefix consistency levels use a single replica read, which costs 1 RU for standard 1 KB point reads.

Step-by-Step Solution

1
Analyze the consistency order requirement
Strong, Bounded Staleness, Session, and Consistent Prefix all guarantee that reads will see updates in the order they were written (consistent prefix guarantee). Eventual consistency does not guarantee order.
Eliminating Eventual consistency as a candidate because it violates the chronological ordering requirement.
2
Analyze the Request Unit (RU) cost constraint
Strong and Bounded Staleness require quorum reads, which cost 2 RUs. Session and Consistent Prefix require only a single replica read, which costs 1 RU.
Eliminating Strong and Bounded Staleness because they fail to minimize RU costs.
3
Select the matching consistency levels
Session and Consistent Prefix are the only two options that guarantee ordered reads and cost 1 RU.
Matching both constraints leaves Session and Consistent Prefix as the correct selections.

Key Concept

Azure Cosmos DB consistency levels and their trade-offs in terms of read latency, RU cost, and ordering guarantees.
Question 333Question

You are developing a web application where users must log in using their corporate accounts. After logging in, the application needs to read the profile details of the currently signed-in user from Microsoft Graph. Which type of permission should you configure for the Microsoft Graph API in the Microsoft Entra ID application registration?

Show answer & explanation

Answer: Delegated permissions

Answer

Delegated permissions
The correct answer is delegated permissions because they are specifically designed for scenarios where an application runs with an active, signed-in user and acts on their behalf. This ensures that the application cannot access any resource that the signed-in user themselves does not have permission to access.

Step-by-Step Solution

1
Analyze the application requirements.
The application requires a user to sign in and needs to access Microsoft Graph API resources on behalf of that signed-in user.
Identifying if a user context exists helps determine the correct permission model.
2
Select the appropriate Microsoft Entra ID permission type.
Delegated permissions are selected because they operate in the context of a signed-in user, enforcing the permissions of both the user and the application.
Delegated permissions allow the application to act on behalf of the signed-in user, whereas application permissions are for daemon services running without user context.

Key Concept

Delegated versus Application permissions in Microsoft Entra ID
Question 334Question

You are developing a C# backend service for a multi-tenant logistics application using the Azure Cosmos DB .NET SDK v3. The database contains a Shipments container configured with a partition key path of `/tenantId`.

You need to implement a method to update a shipment's delivery status with the lowest latency and cost. The method must prevent dirty writes if another thread or client instance updates the shipment concurrently.

Which of the following C# code segments should you implement to perform this update operation?

Show answer & explanation

Answer: ItemResponse<Shipment> response = await container.ReplaceItemAsync<Shipment>(
shipment,
shipment.Id,
new PartitionKey(shipment.TenantId),
new ItemRequestOptions { IfMatchEtag = shipment.ETag }
);

Answer

The correct code segment calls ReplaceItemAsync using the shipment's TenantId as the partition key and sets the IfMatchEtag property in ItemRequestOptions to the shipment's ETag.
The correct code segment uses the Azure Cosmos DB .NET SDK v3 `ReplaceItemAsync` method to safely update the shipment. It targets the correct logical partition by passing the tenant ID as the partition key (`new PartitionKey(shipment.TenantId)`), which matches the container partition key path of `/tenantId`. It prevents dirty writes by passing the current ETag of the shipment object through the `IfMatchEtag` property in `ItemRequestOptions`. If another thread has modified the document, its ETag will have changed, causing the update to fail with a `PreconditionFailed` status code, achieving Optimistic Concurrency Control.

Step-by-Step Solution

1
Determine the correct partition key based on the container configuration.
The container uses `/tenantId` as the partition key path, meaning every point operation must supply the specific tenant ID value via `new PartitionKey(shipment.TenantId)` to resolve the correct logical partition.
Cosmos DB requires the partition key to perform single-partition point operations.
2
Select the proper concurrency control mechanism.
To prevent dirty writes concurrently, configure Optimistic Concurrency Control (OCC) using the item's ETag value.
ETag matching ensures that the write operation fails if the item has been modified by another client session or thread since it was last read.
3
Construct the SDK method call with required parameters.
Use `container.ReplaceItemAsync<T>` passing the item, its ID, the partition key, and the `ItemRequestOptions` containing `IfMatchEtag`.
This aligns with the .NET SDK v3 signature requirements for updating an existing document safely.

Key Concept

Performing safe point updates using Optimistic Concurrency Control and the correct partition key in Azure Cosmos DB .NET SDK v3.
Estimated Time:2m 30s
Question 335Question

You are developing a Python application using the azure-storage-blob (v12) SDK to audit media uploads in an Azure Blob Storage container named 'images'. The application must retrieve a blob's properties and inspect its custom metadata for a key named 'ApproverEmail'. If this key exists, the application must append a new custom metadata key-value pair of 'Status: Approved' to the blob, while preserving all other existing metadata. Which of the following code segments should you use to retrieve the email and update the metadata?

Show answer & explanation

Answer: approver = properties.metadata.get("approveremail")
if approver:
metadata = properties.metadata
metadata["status"] = "Approved"
blob_client.set_blob_metadata(metadata)

Answer

Retrieve the metadata using the lowercased key 'approveremail', mutate the retrieved dictionary to append 'status', and call set_blob_metadata with the mutated dictionary.
The correct answer retrieves the metadata using the lowercased key 'approveremail', appends the new key-value pair to the existing metadata dictionary, and updates the blob's metadata using set_blob_metadata. This correctly accounts for the SDK's lowercase key normalization and avoids replacing the entire metadata collection with only the new key.

Step-by-Step Solution

1
Retrieve the existing metadata dictionary from the blob properties, noting that the SDK lowercases all returned metadata keys.
The metadata dictionary is accessed, and the key 'approveremail' is looked up using lowercase characters.
The SDK normalizes header keys returned from the REST API to lowercase in Python dictionaries, so case-sensitive lookups for the original casing will fail.
2
Add the new metadata key-value pair directly to the retrieved dictionary to preserve existing metadata.
The dictionary now contains all original metadata keys along with the new key.
Calling set_blob_metadata completely replaces existing metadata on the blob, so mutating the retrieved dictionary is required to prevent data loss.
3
Call the set_blob_metadata method on the BlobClient passing the mutated dictionary, without adding any 'x-ms-meta-' prefixes.
The blob's metadata is successfully updated in Azure Blob Storage.
The SDK handles the 'x-ms-meta-' header prefixing automatically, so custom prefixing should not be done in application code.

Key Concept

Handling casing and prefixing when reading and writing blob metadata using the Azure Storage SDK.
Question 336Question

An administrator deletes an Azure App Service instance that was configured to access an Azure Key Vault. The App Service used a system-assigned managed identity for authentication. What happens to the associated managed identity in Microsoft Entra ID after the App Service is deleted?

Show answer & explanation

Answer: The managed identity is automatically deleted from Microsoft Entra ID.

Answer

The managed identity is automatically deleted from Microsoft Entra ID.
A system-assigned managed identity is enabled directly on an Azure resource instance. Its lifecycle is tied to that resource. Therefore, when the App Service instance is deleted, the identity is automatically cleaned up and deleted from Microsoft Entra ID.

Step-by-Step Solution

1
Identify the type of managed identity configuration being used in the scenario.
The App Service is configured with a system-assigned managed identity.
Managed identity lifecycle characteristics depend on whether the identity is system-assigned or user-assigned.
2
Determine the lifecycle behavior of a system-assigned managed identity upon host resource deletion.
A system-assigned managed identity is tied directly to the lifespan of the Azure resource that hosts it.
Unlike user-assigned identities, system-assigned identities cannot exist independently of their parent resource.
3
Conclude the status of the identity in Microsoft Entra ID.
The identity is automatically deleted from Microsoft Entra ID when the host App Service is deleted.
This cleanup occurs automatically to prevent orphaned identities.

Key Concept

The lifecycle of a system-assigned managed identity is strictly tied to the Azure resource on which it is enabled, meaning it is deleted automatically when the resource is deleted.
Estimated Time:45s
Question 337Question

You are deploying a C# ASP.NET Core web application to an Azure App Service. The application must retrieve secrets from two distinct Azure Key Vaults:

1. `kv-finance`: Contains highly sensitive financial credentials and must only be accessible by this specific App Service instance. Access must be automatically revoked if the App Service is deleted.
2. `kv-shared`: Contains shared configuration data and is accessed by multiple App Service instances across the resource group.

You have created a user-assigned managed identity named `id-shared` for shared resource access. You need to configure the identities and implement the authentication code using the `Azure.Identity` SDK and `DefaultAzureCredential` class.

Which two configuration steps should you implement to satisfy the requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the identity property of the App Service in your ARM template with a type of SystemAssigned, UserAssigned and list the resource ID of id-shared under userAssignedIdentities.; For accessing kv-shared, instantiate the SecretClient using: new SecretClient(new Uri("https://kv-shared.vault.azure.net/"), new DefaultAzureCredential(new DefaultAzureCredentialOptions { ManagedIdentityClientId = "<user-assigned-client-id>" }));

Answer

Configure the App Service identity property in the ARM template using the type 'SystemAssigned, UserAssigned' while listing the resource ID of the user-assigned identity, and instantiate the client for the shared Key Vault by passing DefaultAzureCredentialOptions with the user-assigned identity's client ID.
To satisfy the requirements, the App Service needs to be provisioned with both system-assigned and user-assigned managed identities, which requires setting the ARM identity type to 'SystemAssigned, UserAssigned' and linking the user-assigned identity. In the application code, the default behavior of DefaultAzureCredential is to attempt authentication via the system-assigned managed identity first. To target the user-assigned identity for the shared Key Vault, the client ID of the user-assigned identity must be explicitly configured using DefaultAzureCredentialOptions.

Step-by-Step Solution

1
Determine the lifecycle requirements for both Key Vaults.
The finance Key Vault requires a system-assigned managed identity since its access must be revoked automatically upon resource deletion. The shared Key Vault requires a user-assigned managed identity to facilitate shared access across multiple instances.
This aligns identity selection with resource lifecycle boundaries.
2
Define the identity configuration in the ARM template.
Configure the App Service resource with identity type 'SystemAssigned, UserAssigned' and reference the user-assigned identity's resource ID in the userAssignedIdentities block.
This enables both system-assigned and user-assigned managed identities on the App Service instance.
3
Configure the .NET code for the database-specific Key Vault (kv-finance).
Instantiate the client using 'new DefaultAzureCredential()'.
By default, when no client ID is explicitly provided, DefaultAzureCredential attempts to use the system-assigned managed identity.
4
Configure the .NET code for the shared Key Vault (kv-shared).
Instantiate the client using 'new DefaultAzureCredential(new DefaultAzureCredentialOptions { ManagedIdentityClientId = "<client-id>" })'.
Specifying the client ID targets the user-assigned managed identity, ensuring it does not default to the system-assigned managed identity.

Key Concept

Configuring co-existing system-assigned and user-assigned managed identities and resolving client identities programmatically using DefaultAzureCredential.
Question 338Question

You are developing an ASP.NET Core web application that will be hosted on two Azure App Service instances: web-app-primary and web-app-secondary. Both web apps must retrieve database connection strings from a shared Azure Key Vault named kv-shared. You decide to use a user-assigned managed identity named id-app-reader to access the Key Vault, ensuring that the identity's lifecycle is independent of the App Service instances. The application code uses the following C# code to authenticate:

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

To implement this security architecture, you assign id-app-reader to both App Service instances and configure the Key Vault access policy. Which of the following configuration steps must you also perform on each App Service instance to ensure that the application successfully authenticates?

Show answer & explanation

Answer: Add an Application Setting named AZURE_CLIENT_ID and set its value to the Client ID of the id-app-reader identity.

Answer

Add an Application Setting named AZURE_CLIENT_ID and set its value to the Client ID of the id-app-reader identity.
The correct action is to add an Application Setting named AZURE_CLIENT_ID and set its value to the Client ID of the id-app-reader identity. When an application uses DefaultAzureCredential and needs to authenticate with a user-assigned managed identity, it reads the AZURE_CLIENT_ID environment variable (which is populated via Application Settings in Azure App Service) to determine which identity to use. The Azure.Identity library expects the Client ID (App ID) of the identity.

Step-by-Step Solution

1
Assign the user-assigned managed identity to both Azure App Service instances.
The identity is linked to the App Service host environment, making it available for token requests.
This establishes the identity configuration at the Azure resource level.
2
Configure the Azure Key Vault access policies or Azure RBAC role assignments for the user-assigned managed identity.
The identity has the necessary permissions (e.g., Get/List Secrets) on the Key Vault.
This authorizes the identity to perform actions on the target resource.
3
Define the AZURE_CLIENT_ID Application Setting on each App Service instance pointing to the Client ID of the user-assigned managed identity.
DefaultAzureCredential reads this setting and uses it to specify the correct client ID during token acquisition.
When multiple identities are present or a user-assigned identity is used, DefaultAzureCredential requires the Client ID to differentiate and request tokens for the target identity.

Key Concept

Configuring DefaultAzureCredential for User-Assigned Managed Identities in Azure App Service
Question 339Question

You manage an Azure App Service web app named app-orders that includes a production slot and a deployment slot named staging. You configure a system-assigned managed identity for the production slot and grant it access to a production database. You also configure a system-assigned managed identity for the staging slot and grant it access to a test database. You swap the staging slot with the production slot. Which statement describes the managed identity behavior after the swap is completed?

Show answer & explanation

Answer: The production slot continues to use its original system-assigned managed identity and retains access to the production database.

Answer

The production slot continues to use its original system-assigned managed identity and retains access to the production database.
During an App Service slot swap, the system-assigned managed identity remains with its original slot resource. Since the production slot maintains its identity, it retains its authorized access to the production database.

Step-by-Step Solution

1
Determine how system-assigned managed identities are bound to Azure resources.
System-assigned managed identities are bound to the lifecycle of the specific Azure resource (the slot resource itself).
This establishes that the identity is not configuration-based and cannot be detached from the resource.
2
Analyze the impact of a slot swap operation on resource identities.
A slot swap swaps the application code and slot configurations (like app settings) but does not change the physical App Service slot resources or their system-assigned identities.
This confirms that the production slot resource keeps its original identity.
3
Determine the database access state of the production slot post-swap.
Because the production slot retains its original identity, it continues to have the permissions granted to that identity to access the production database.
This identifies the correct outcome of the swap.

Key Concept

System-assigned managed identities are tied to the specific slot resource and do not change or swap during a deployment slot swap operation.
Question 340Question

You are deploying a set of Azure Virtual Machines (VMs) that need to read configuration files from a shared Azure Storage account. To simplify access control, you want to create a managed identity as a standalone Azure resource that is shared across all the VMs and persists even if all the VMs are deleted. Which value should you specify for the type property in the identity section of the VM's Azure Resource Manager (ARM) template?

Show answer & explanation

Answer: UserAssigned

Answer

The correct property value is UserAssigned.
Setting the identity type to UserAssigned is correct because a user-assigned managed identity is created as a standalone Azure resource. This design allows it to be shared across multiple virtual machines in a scale set and ensures that the identity persists even if individual virtual machines are deleted or scaled down.

Step-by-Step Solution

1
Analyze the requirements to identify if the managed identity needs to be shared across multiple resources and if its lifecycle should be independent of them.
The identity must be shared across multiple virtual machines and persist independently of their lifecycle, indicating that a user-assigned managed identity is required.
System-assigned identities are tied to a single resource's lifecycle and cannot be shared.
2
Identify the corresponding identity type value used in the Azure Resource Manager (ARM) template.
The type value for a user-assigned managed identity is UserAssigned.
This property configures the virtual machine resource to use the specified user-assigned identity resource.

Key Concept

Choosing between system-assigned and user-assigned managed identities based on lifecycle and sharing requirements.
PreviousPage 17 / 49Next