Implement Azure Security

203 questions

All types203 Multiple choice102 Multiple select71 Ordering30

You are developing a C# console application that needs to authenticate users using the Microsoft Identity Platform. The application must support signing in users from any Microsoft Entra ID tenant, but must explicitly prevent users with personal Microsoft accounts (such as Xbox, Outlook.com, or Skype accounts) from signing in.

You have the following C# code to build the public client application:

csharp
var app = PublicClientApplicationBuilder.Create(clientId)
.WithAuthority(authority)
.WithRedirectUri(redirectUri)
.Build();

Which value should you assign to the `authority` variable?

https://login.microsoftonline.com/common

https://login.microsoftonline.com/organizations

https://login.microsoftonline.com/consumers

https://login.microsoftonline.com/tenants

Show answer & explanation

Answer: https://login.microsoftonline.com/organizations

Answer

https://login.microsoftonline.com/organizations

The authority endpoint https://login.microsoftonline.com/organizations is designed specifically for multi-tenant applications that only allow work or school accounts from Microsoft Entra ID tenants, thereby excluding personal Microsoft accounts.

Step-by-Step Solution

Analyze the tenant requirements for the application.

The application must support multi-tenant authentication for all Microsoft Entra ID directories, but must exclude personal Microsoft accounts.

This filters the choice of authority endpoints based on audience type.

Evaluate the standard Microsoft Identity Platform v2.0 authority endpoints.

The endpoint ending in '/organizations' targets work or school accounts from any tenant, while '/common' includes personal accounts, and '/consumers' includes only personal accounts.

Choosing the correct endpoint ensures compliance with the target user audience constraints.

Assign the correct endpoint URI to the authority configuration in MSAL.NET.

Setting the authority to 'https://login.microsoftonline.com/organizations' completes the client application configuration correctly.

This passes the correct target audience to the client application builder.

Key Concept

Microsoft Identity Platform multi-tenant authority endpoints

Estimated Time:1m 30s

Question 162Question →

You are developing a secure C# application using the Azure.Storage.Blobs SDK (v12) to generate a User Delegation SAS token. An external client requires temporary, read-only access to a specific blob named "backup.bak" in a container named "db-backups".

The security requirements are as follows:
- Access must be restricted to HTTPS only.
- Access must be restricted to the client's IP address "203.0.113.88".
- The token must account for potential client-server clock desynchronization (clock skew).
- The token must grant only the minimum necessary permissions.

You write the following code:

csharp
var sasBuilder = new BlobSasBuilder
{
BlobContainerName = "db-backups",
BlobName = "backup.bak",
Resource = [PLACEHOLDER_RESOURCE],
StartsOn = [PLACEHOLDER_START],
ExpiresOn = DateTimeOffset.UtcNow.AddHours(2),
Protocol = [PLACEHOLDER_PROTOCOL],
IPRange = [PLACEHOLDER_IP]
};
sasBuilder.SetPermissions([PLACEHOLDER_PERMISSIONS]);

Which set of properties correctly configures the BlobSasBuilder to meet the security requirements?

Resource = "b", StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15), Protocol = SasProtocol.Https, IPRange = SasIPRange.Parse("203.0.113.88"), and Permissions = BlobSasPermissions.Read

Resource = "c", StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15), Protocol = SasProtocol.Https, IPRange = SasIPRange.Parse("203.0.113.88"), and Permissions = BlobSasPermissions.Read

Resource = "b", StartsOn = DateTimeOffset.UtcNow, Protocol = SasProtocol.HttpsAndHttp, IPRange = SasIPRange.Parse("203.0.113.88"), and Permissions = BlobSasPermissions.Read

Resource = "b", StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15), Protocol = SasProtocol.Https, IPRange = SasIPRange.Parse("203.0.113.88"), and Permissions = BlobSasPermissions.All

Show answer & explanation

Answer: Resource = "b", StartsOn = DateTimeOffset.UtcNow.AddMinutes(-15), Protocol = SasProtocol.Https, IPRange = SasIPRange.Parse("203.0.113.88"), and Permissions = BlobSasPermissions.Read

Answer

The correct configuration is the one that sets Resource to "b", StartsOn with a 15-minute clock skew buffer, Protocol to HTTPS, specifies the exact client IP address, and grants Read permissions.

The correct configuration specifies Resource = "b" (which scopes the token to a single blob rather than the entire container), subtracts 15 minutes from UtcNow to handle potential client-server clock desynchronization (clock skew), sets the protocol to HTTPS only, restricts the IP range to the client's IP, and limits permissions to Read only, satisfying all security constraints.

Step-by-Step Solution

Determine the correct resource scope and permissions for the BlobSasBuilder.

Because access is restricted to a single blob named 'backup.bak', the Resource property must be set to 'b' (blob) rather than 'c' (container). The permissions must be limited strictly to BlobSasPermissions.Read to maintain least privilege.

Setting Resource to 'c' would grant access to all blobs in the container, violating the least privilege rule.

Configure the security protocol and network constraints on the builder.

The Protocol property must be set to SasProtocol.Https, and the IPRange must be configured to SasIPRange.Parse("203.0.113.88") to restrict operations to the designated client.

This guarantees that client requests are encrypted in transit over HTTPS and originate only from the specified partner IP address.

Provide a buffer for clock synchronization issues between client and server.

Set the StartsOn property to a time slightly in the past, such as DateTimeOffset.UtcNow.AddMinutes(-15).

Without a buffer, if the client's clock is slightly ahead of the Azure storage server, the token will be rejected as not yet valid.

Key Concept

Configuring a secure User Delegation Shared Access Signature (SAS) token using the Azure Storage .NET SDK (Azure.Storage.Blobs) to enforce least-privilege, clock skew handling, protocol restrictions, and IP restrictions.

Estimated Time:1m 30s

Question 163Question →

You are developing a containerized API that will run on Azure Container Instances. The container groups are frequently created, destroyed, and recreated via automated workflows. The API must authenticate to the Microsoft Identity Platform to retrieve configuration keys from Azure App Configuration. You must ensure that recreating the Container Instances does not require updating permission grants in Azure App Configuration. Which two configurations should you implement? (Select two.)

Select all that apply

Create a user-assigned managed identity, assign it to the container group, and grant it the App Configuration Data Reader role.

Instantiate DefaultAzureCredential by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of the user-assigned managed identity.

Enable a system-assigned managed identity on the container group and grant it the App Configuration Data Reader role.

Instantiate DefaultAzureCredential by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the Azure resource ID of the user-assigned managed identity.

Show answer & explanation

Answer: Create a user-assigned managed identity, assign it to the container group, and grant it the App Configuration Data Reader role.; Instantiate DefaultAzureCredential by passing DefaultAzureCredentialOptions with the ManagedIdentityClientId property set to the client ID of the user-assigned managed identity.

Answer

Use a user-assigned managed identity assigned to the container group and configure DefaultAzureCredentialOptions in code using the client ID of that identity.

A user-assigned managed identity operates as a standalone Azure resource, so its lifecycle is decoupled from the container instances. Recreating the container instances will not delete the identity or its assigned roles. When writing the authentication code, DefaultAzureCredential needs to know which user-assigned identity to use, which is achieved by specifying the client ID via DefaultAzureCredentialOptions.ManagedIdentityClientId.

Step-by-Step Solution

Analyze the resource lifecycle requirements.

Determine that because the container groups are frequently destroyed and recreated, a system-assigned managed identity is unsuitable as its credentials and role assignments would be deleted along with the resource.

A user-assigned managed identity exists as a standalone Azure resource, meaning its identity and role assignments persist independently of the container lifecycle.

Create and associate the identity.

Create a user-assigned managed identity, assign it to the container group, and grant it the App Configuration Data Reader role in the Azure App Configuration resource.

This establishes the identity, links it to the container group, and grants the minimum required access permissions to retrieve configuration data.

Configure the Azure SDK client in application code.

Instantiate DefaultAzureCredential passing an instance of DefaultAzureCredentialOptions with the ManagedIdentityClientId property configured to the client ID of the user-assigned managed identity.

Explicitly passing the client ID is necessary because a resource can have multiple user-assigned managed identities, and the SDK needs to know which specific identity to use for token acquisition.

Key Concept

User-assigned managed identity lifecycle and Client ID configuration in Azure SDK / MSAL authentication.

Question 164Question →

You are developing a solution that stores sensitive media files in an Azure Blob Storage container named mediafiles. You need to grant a partner application temporary access to read and list the blobs in this container. The security requirements state that you must be able to revoke this access immediately if a compromise occurs, without rotating the storage account keys or affecting other SAS tokens.

Which two actions should you perform to implement this security requirement?

Select all that apply

Create a stored access policy on the container.

Generate a service SAS that is associated with the stored access policy.

Generate an account SAS that references the stored access policy.

Create a stored access policy at the storage account level.

Show answer & explanation

Answer: Create a stored access policy on the container.; Generate a service SAS that is associated with the stored access policy.

Answer

To implement the revocation requirement, you should create a stored access policy on the container and then generate a service SAS that is associated with that stored access policy.

Creating a stored access policy on the container and generating a service SAS that references it is correct because it allows the SAS lifetime and permissions to be managed directly by the policy. If a compromise is suspected, the policy can be deleted or updated, instantly revoking all SAS tokens that reference it without affecting other services or requiring account key rotation.

Step-by-Step Solution

Define the stored access policy on the specific blob container.

A policy containing the permissions (read and list) and validity duration is created, which can be modified or deleted on demand.

This provides a single point of control for access configuration that can be altered to invalidate associated SAS tokens immediately.

Generate a service SAS for the partner application, binding it to the stored access policy.

A service SAS token is generated that points to the container and inherits its constraints from the stored access policy.

By using a service SAS bound to the policy rather than an account SAS, the token's lifetime and validity are tied directly to the container-level policy.

Key Concept

Stored Access Policies and SAS Revocation

Question 165Question →

Your company is configuring SSL/TLS certificates for a web application and wants to automate the certificate renewal lifecycle using an integrated Certificate Authority (CA) partner, DigiCert. You need to configure Azure Key Vault to automatically request and renew certificates from DigiCert. Which sequence of actions must you perform to configure the integrated certificate auto-renewal?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Retrieve the organization ID, API key, and account credentials from the partner Certificate Authority; register the partner Certificate Authority as a certificate issuer in the Azure Key Vault using the retrieved credentials; create a certificate policy in the Azure Key Vault that specifies the registered issuer and configures a lifetime trigger for auto-renewal; and create the certificate in the Azure Key Vault using the configured certificate policy to initiate the initial enrollment and enable automatic renewals.

The correct configuration sequence for integrated CA certificate auto-renewal begins with obtaining the credentials from the CA provider. Next, these credentials are used to register the CA as an issuer object within the Key Vault. Once the issuer exists, you define a certificate policy referencing that issuer and setting the auto-renewal lifetime trigger. Finally, you create the certificate based on that policy to trigger the initial generation and establish the auto-renewal lifecycle.

Step-by-Step Solution

Retrieve organization details and API keys from DigiCert.

Credentials are ready to be used in Azure Key Vault.

Azure Key Vault requires CA account credentials to authenticate and communicate with the partner CA.

An issuer object is created in the Key Vault.

A certificate policy cannot reference an issuer until the issuer is registered in the Key Vault.

Create a certificate policy containing issuer details and lifetime actions.

A policy defining the auto-renewal percentage trigger is ready.

The policy must exist to define the properties of the certificate and specify that the CA should auto-renew it at a specific lifetime milestone.

Create the certificate in Key Vault using the policy.

The initial certificate is generated and auto-renewal is active.

This initiates the initial contact with the CA and configures the certificate for the automated renewal cycle.

Key Concept

Azure Key Vault integrated Certificate Authority auto-renewal configuration

Question 166Question →

You are designing an ASP.NET Core Web API that is called by a web-based front-end client application. The Web API needs to request data from a downstream reporting database service. To comply with data privacy policies, the requests to the downstream service must execute under the security context of the specific user who logged into the front-end application, allowing the reporting service to audit access by individual user accounts. Which authentication flow and client application type should you implement in the Web API to meet these requirements?

A system-assigned managed identity configured on the Web API host

The client credentials flow using a confidential client application

The OAuth 2.0 On-Behalf-Of flow using a confidential client application

The authorization code flow using a public client application

Show answer & explanation

Answer: The OAuth 2.0 On-Behalf-Of flow using a confidential client application

Answer

The OAuth 2.0 On-Behalf-Of flow using a confidential client application

The OAuth 2.0 On-Behalf-Of flow is specifically designed for Web APIs that need to call downstream APIs while propagating the original user's identity and permissions. Because a Web API runs on a server and can protect credentials, it must be implemented as a confidential client application.

Step-by-Step Solution

Evaluate the context propagation requirement.

Identify that requests to the downstream service must run under the user's security context to allow individual user auditing.

This rules out authentication flows that use application-only identities, such as client credentials or managed identities.

Determine the application type and trust level of the Web API.

Since the Web API runs on a server and can safely hold credentials, it is classified as a confidential client application.

This requires using ConfidentialClientApplication in MSAL.NET rather than PublicClientApplication.

Match the flow to the multi-tier API authentication scenario.

Select the OAuth 2.0 On-Behalf-Of (OBO) flow.

The OBO flow is the standard mechanism in the Microsoft Identity Platform for a Web API to exchange the user's incoming assertion token for a token to access a downstream API on their behalf.

Key Concept

OAuth 2.0 On-Behalf-Of flow for user context propagation in Web APIs

Question 167Question →

A developer is configuring a C# ASP.NET Core web application hosted on an Azure App Service. The application must retrieve a database connection string stored in an Azure Key Vault named kv-prod using a Key Vault reference in the App Service configuration. The App Service is configured with a system-assigned managed identity. Which configuration should the developer apply to retrieve the secret value successfully?

Set the application setting value to @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/) and assign the Key Vault Secrets User role to the App Service system-assigned managed identity.

Set the application setting value to @Microsoft.KeyVault(SecretUrl=https://kv-prod.vault.azure.net/secrets/db-conn/) and assign the Key Vault Secrets User role to the App Service system-assigned managed identity.

Set the application setting value to @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/) and assign the Key Vault Reader role to the App Service system-assigned managed identity.

Set the application setting value to @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/) and assign the Key Vault Secrets User role to a new user-assigned managed identity, because system-assigned managed identities are not supported for Key Vault references.

Show answer & explanation

Answer: Set the application setting value to @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/) and assign the Key Vault Secrets User role to the App Service system-assigned managed identity.

Answer

The correct configuration requires setting the application setting to the format @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/) and granting the system-assigned managed identity the Key Vault Secrets User role. The SecretUri parameter is the correct syntax for referencing a secret by its URI, and the Key Vault Secrets User role provides the necessary permissions to read the secret's value at runtime.

Step-by-Step Solution

Define the App Service application setting value using the Key Vault reference syntax with the SecretUri parameter.

The setting is configured as @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/db-conn/).

This tells the App Service runtime to resolve the setting value from the specified Key Vault secret.

Assign the Key Vault Secrets User role to the system-assigned managed identity on the Key Vault.

The identity is authorized to retrieve the secret value.

Without this role (or equivalent access policy permissions), the App Service runtime will fail to retrieve the secret value, causing the setting to remain unresolved.

Key Concept

Key Vault References in App Service

Question 168Question →

You are developing a C# background worker service that runs on an on-premises server. The service must periodically query a secured downstream web API without any user interaction. You register the service in Microsoft Entra ID as a daemon application. You need to write code using MSAL.NET to acquire an access token for the downstream API.

Which two code segments should you use to instantiate the application client and acquire the token? (Select two.)

Select all that apply

var app = ConfidentialClientApplicationBuilder.Create(clientId).WithClientSecret(clientSecret).WithAuthority(authority).Build();

var app = PublicClientApplicationBuilder.Create(clientId).WithAuthority(authority).Build();

var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();

var result = await app.AcquireTokenInteractive(scopes).ExecuteAsync();

Show answer & explanation

Answer: var app = ConfidentialClientApplicationBuilder.Create(clientId).WithClientSecret(clientSecret).WithAuthority(authority).Build();; var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();

Answer

To instantiate the application client and acquire the token for a daemon application, you must use ConfidentialClientApplicationBuilder to create the client and call AcquireTokenForClient to retrieve the token.

For daemon applications running without user interaction, MSAL.NET requires a confidential client application configuration. The correct setup uses ConfidentialClientApplicationBuilder to define the client with a client secret and AcquireTokenForClient to perform the OAuth 2.0 Client Credentials grant flow.

Step-by-Step Solution

Determine the application type and flow based on the scenario requirements.

Since the background worker service runs on an on-premises server without user interaction, it represents a daemon application that must use the OAuth 2.0 Client Credentials flow.

Daemon applications run headlessly and must authenticate using their own identity (app identity) rather than a user's identity.

Select the correct MSAL.NET application builder to instantiate the client.

Use ConfidentialClientApplicationBuilder because it supports configuring confidential clients with credentials like client secrets or certificates.

PublicClientApplicationBuilder does not support client credentials and is meant for interactive client applications.

Select the correct method to request and acquire the access token.

Call the AcquireTokenForClient method on the instantiated confidential client application instance.

AcquireTokenForClient initiates the non-interactive Client Credentials flow, whereas AcquireTokenInteractive requires a UI browser session for user interaction.

Key Concept

Authenticating daemon applications with MSAL.NET using the Client Credentials flow

Question 169Question →

You are developing a C# console application that runs on an Azure Virtual Machine. The application must perform key wrapping and unwrapping operations using an RSA key stored in an Azure Key Vault named kv-prod-keys. The Key Vault is configured to use the Azure Role-Based Access Control (Azure RBAC) permission model. The virtual machine has a system-assigned managed identity enabled. You need to grant the application the minimum necessary permissions to perform the operations and configure the application code using the latest Azure SDK for .NET. Which two actions should you perform? (Select TWO.)

Select all that apply

Assign the Key Vault Crypto User role to the system-assigned managed identity of the virtual machine.

Instantiate the CryptographyClient class from the Azure.Security.KeyVault.Keys.Cryptography namespace.

Assign the Key Vault Secrets User role to the system-assigned managed identity of the virtual machine.

Create a Key Vault access policy that grants Key Wrap and Key Unwrap permissions to the system-assigned managed identity.

Configure a user-assigned managed identity on the virtual machine and assign it the Reader role on the Key Vault resource.

Show answer & explanation

Answer: Assign the Key Vault Crypto User role to the system-assigned managed identity of the virtual machine.; Instantiate the CryptographyClient class from the Azure.Security.KeyVault.Keys.Cryptography namespace.

Answer

Assign the Key Vault Crypto User role to the system-assigned managed identity and use the CryptographyClient class from the Azure.Security.KeyVault.Keys.Cryptography namespace.

To perform cryptographic operations such as key wrapping and unwrapping using an RSA key in Azure Key Vault, the application identity requires the 'Key Vault Crypto User' RBAC role, which provides data plane access for keys. In the Azure SDK for .NET (Azure.Security.KeyVault), cryptographic operations are separated from management operations and must be executed using the 'CryptographyClient' class located in the 'Azure.Security.KeyVault.Keys.Cryptography' namespace.

Step-by-Step Solution

Determine the required access control configuration for the Azure Key Vault.

Since the vault uses the Azure RBAC permission model, permissions must be assigned using Azure RBAC roles rather than Key Vault access policies.

Access policies are disabled when the Azure RBAC permission model is active.

Select the correct role for key wrapping and unwrapping operations.

The Key Vault Crypto User role is chosen, as it provides the least privilege required to perform data plane cryptographic operations on keys.

Other roles like Key Vault Secrets User are for secrets, and the Reader role does not grant data plane access.

Identify the modern C# SDK class and namespace for cryptographic operations.

Use the CryptographyClient class within the Azure.Security.KeyVault.Keys.Cryptography namespace.

The Azure.Security.KeyVault.Keys SDK separates management operations (KeyClient) from cryptographic operations (CryptographyClient) for efficiency and security.

Key Concept

Azure Key Vault cryptographic operations and RBAC-based access control using the Azure SDK for .NET.

Question 170Question →

You are developing a secure .NET web API hosted on an Azure App Service. The API needs to programmatically retrieve an X.509 certificate, including its private key, from an Azure Key Vault named `kv-prod` to sign outgoing requests.

The App Service is configured with a system-assigned managed identity and has been assigned only the 'Key Vault Secrets User' Azure RBAC role on `kv-prod`.

Which C# code segment should you use to retrieve the certificate along with its private key?

var client = new SecretClient(new Uri("https://kv-prod.vault.azure.net/"), new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync("SigningCert");
var certificate = new X509Certificate2(Convert.FromBase64String(secret.Value));

var client = new CertificateClient(new Uri("https://kv-prod.vault.azure.net/"), new DefaultAzureCredential());
KeyVaultCertificateWithPolicy cert = await client.GetCertificateAsync("SigningCert");
var certificate = new X509Certificate2(cert.Cer);

var client = new KeyClient(new Uri("https://kv-prod.vault.azure.net/"), new DefaultAzureCredential());
KeyVaultKey key = await client.GetKeyAsync("SigningCert");
var certificate = new X509Certificate2(key.Key.N);

var credential = new ClientSecretCredential("tenantId", "clientId", "clientSecret");
var client = new SecretClient(new Uri("https://kv-prod.vault.azure.net/"), credential);
KeyVaultSecret secret = await client.GetSecretAsync("SigningCert");
var certificate = new X509Certificate2(Convert.FromBase64String(secret.Value));

Show answer & explanation

Answer: var client = new SecretClient(new Uri("https://kv-prod.vault.azure.net/"), new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync("SigningCert");
var certificate = new X509Certificate2(Convert.FromBase64String(secret.Value));

Answer

Use SecretClient with DefaultAzureCredential to retrieve the certificate value as a secret, then instantiate the X509Certificate2 object using the base64-decoded bytes.

In Azure Key Vault, when an X.509 certificate is created or imported, the certificate's private key and full PFX/PEM contents are stored as a Secret with the same name. To retrieve the private key of a certificate programmatically, you must retrieve it as a secret using the SecretClient and decode the base64-encoded secret value. Because the App Service managed identity is granted the 'Key Vault Secrets User' RBAC role, it has the necessary permissions to read secrets from the Key Vault.

Step-by-Step Solution

Identify where the private key of an Azure Key Vault certificate is stored.

The private key of an Azure Key Vault certificate is stored as a Key Vault Secret under the same name.

Azure Key Vault certificates are composite resources; the public portion is managed via the certificate API, but the private key can only be downloaded programmatically by retrieving the secret payload.

Verify authorization requirements against the assigned role.

The 'Key Vault Secrets User' RBAC role allows read access to secrets but not to certificates or keys.

Since the private key must be retrieved as a secret, the application needs to utilize SecretClient and must have the Secrets User permission.

Select the correct SDK client and credentials for local reconstruction.

Initialize SecretClient using DefaultAzureCredential to leverage the system-assigned managed identity, get the secret, base64-decode the value, and initialize X509Certificate2.

DefaultAzureCredential seamlessly handles system-assigned managed identity authentication in App Service environments.

Key Concept

Retrieving certificates with private keys from Azure Key Vault using the Azure SDK for .NET and Azure RBAC

Estimated Time:1m 30s

Question 171Question →

You need to create a new SSL/TLS certificate in Azure Key Vault using a non-integrated Certificate Authority (CA). Which sequence of steps should you perform to generate the Certificate Signing Request (CSR) and complete the certificate creation in Key Vault?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with initiating the certificate creation operation in Key Vault with the Issuer set to Unknown. Next, you download the generated Certificate Signing Request (CSR). You then submit this CSR to the external Certificate Authority (CA) and retrieve the signed certificate. Finally, you merge the signed certificate back into the pending certificate operation in Key Vault to complete the process.

The correct process involves first initiating the certificate operation with the issuer set to Unknown, which generates the CSR. The CSR is then retrieved and signed by the external CA. Finally, the signed certificate is merged back into the pending operation to match the private key.

Step-by-Step Solution

Initiate the certificate creation in Azure Key Vault with the issuer configuration set to Unknown.

Key Vault creates a pending certificate operation, generating a private/public key pair and a Certificate Signing Request (CSR).

Specifying Unknown as the issuer tells Key Vault that an external, non-integrated CA will be responsible for signing the certificate.

Retrieve the CSR from the pending certificate operation.

You obtain the CSR file (PEM format) from the Azure Portal, CLI, or SDK.

You must download the CSR to pass it to the external authority.

Submit the CSR to the external CA and retrieve the signed certificate.

The CA signs the public key and issues a certificate (usually as a .cer or .p7b file).

The external CA must authenticate the request and sign it to make the certificate valid.

Merge the signed certificate back into the pending Key Vault certificate operation.

The certificate state updates to Active and is ready for use.

Merging links the public certificate from the CA with the private key stored securely in Key Vault.

Key Concept

Creating certificates in Azure Key Vault using a non-integrated CA requires generating a CSR, obtaining the signed certificate externally, and merging it back to associate it with the private key.

Question 172Question →

You are developing an ASP.NET Core Web API that must secure its endpoints using the Microsoft Identity Platform. The Web API will accept JWT access tokens sent by client applications in the HTTP Authorization header. You need to configure the Web API to validate these tokens using the `Microsoft.Identity.Web` library. Which two actions should you perform to complete the configuration? (Select two.)

Select all that apply

In the `Program.cs` file, call `builder.Services.AddMicrosoftIdentityWebApi(builder.Configuration);` to register token validation services.

In the `appsettings.json` file, create an `AzureAd` configuration section containing the `Instance`, `Domain`, `TenantId`, and `ClientId` keys.

In the `Program.cs` file, call `builder.Services.AddMicrosoftIdentityWebApp(builder.Configuration);` to register web app authentication services.

In the `appsettings.json` file, create a `ClientCredentials` section containing a `ClientSecret` and configure the API to fetch it from Azure Key Vault.

Show answer & explanation

Answer: In the `Program.cs` file, call `builder.Services.AddMicrosoftIdentityWebApi(builder.Configuration);` to register token validation services.; In the `appsettings.json` file, create an `AzureAd` configuration section containing the `Instance`, `Domain`, `TenantId`, and `ClientId` keys.

Answer

To configure the Web API to validate tokens using Microsoft.Identity.Web, you must call builder.Services.AddMicrosoftIdentityWebApi(builder.Configuration) in Program.cs and define the AzureAd configuration section in appsettings.json.

To secure an ASP.NET Core Web API using the Microsoft Identity Platform, you use the `Microsoft.Identity.Web` library. First, you configure the authentication middleware in the `Program.cs` file by calling `AddMicrosoftIdentityWebApi(builder.Configuration)`. Second, you provide the registration details under the `AzureAd` section in the `appsettings.json` file so the middleware knows which tenant and client ID to validate the tokens against.

Step-by-Step Solution

Configure the ASP.NET Core application's Program.cs to use Microsoft.Identity.Web services.

The authentication services are registered using the `AddMicrosoftIdentityWebApi` method.

This method configures the Web API to validate incoming JWT bearer tokens.

Add the connection parameters to the configuration file.

The application configuration has an `AzureAd` section with `Instance`, `Domain`, `TenantId`, and `ClientId` keys.

The library relies on these settings to obtain metadata and locate the authority for token validation.

Key Concept

Configuring token validation in an ASP.NET Core Web API using Microsoft.Identity.Web.

Question 173Question →

Your company is migrating an Azure App Service web application to a new security model. The web application must retrieve database connection strings stored as secrets in an Azure Key Vault. The Key Vault is configured to use the Azure role-based access control (Azure RBAC) authorization model. You need to configure the minimum permissions required for the web application's system-assigned managed identity to read the secrets. Which configuration should you apply?

Assign the Key Vault Reader role to the system-assigned managed identity.

Assign the Key Vault Secrets User role to the system-assigned managed identity.

Create a Key Vault access policy with Secret Get permissions and assign it to the system-assigned managed identity.

Assign the Key Vault Secrets User role to a new user-assigned managed identity and configure the web application to use it.

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the system-assigned managed identity.

Answer

Assign the Key Vault Secrets User role to the system-assigned managed identity.

The correct answer is to assign the Key Vault Secrets User role to the system-assigned managed identity. Under the Azure RBAC authorization model, this specific role provides the minimum privilege necessary to read secret values (such as database connection strings) without granting administrative permissions to create or delete secrets. Furthermore, because the vault uses Azure RBAC, legacy access policies are disabled, and the Web App's existing system-assigned managed identity should be used directly rather than creating a new identity.

Step-by-Step Solution

Identify the active authorization model for the Azure Key Vault.

The Key Vault is configured for Azure RBAC, meaning classic Key Vault access policies are disabled and will not grant access.

Choosing the correct authorization mechanism is necessary to ensure permissions are successfully evaluated.

Determine the minimum privilege Azure RBAC role required to read secret values.

The Key Vault Secrets User role allows reading secret values, whereas Key Vault Reader only allows reading metadata.

Using the least privilege principle prevents over-assigning permissions while still enabling functionality.

Apply the role assignment to the appropriate identity.

The role is assigned directly to the App Service's existing system-assigned managed identity.

This utilizes the existing identity lifecycle without creating redundant resources.

Key Concept

Azure Key Vault RBAC permission model and built-in roles

Estimated Time:1m 30s

Question 174Question →

A C# background service runs on an Azure Virtual Machine that is configured with a user-assigned managed identity. The service must decrypt sensitive application data using an asymmetric key named `app-decrypt-key` stored in an Azure Key Vault named `contoso-vault`. The Key Vault has Azure role-based access control (Azure RBAC) enabled as its authorization model. You need to grant the minimum necessary permissions to the managed identity and implement the decryption logic in the service's C# code using the Azure SDK for .NET. Which two actions should you perform? (Choose two.)

Select all that apply

Assign the Key Vault Crypto User role to the user-assigned managed identity for the contoso-vault scope.

In the C# application code, instantiate a CryptographyClient using the key URI and call its DecryptAsync method.

Assign the Key Vault Crypto User role to the virtual machine's system-assigned managed identity, while configuring the application's DefaultAzureCredential to use the user-assigned managed identity.

In the C# application code, instantiate a KeyClient using the Key Vault endpoint and call its DecryptAsync method.

Show answer & explanation

Answer: Assign the Key Vault Crypto User role to the user-assigned managed identity for the contoso-vault scope.; In the C# application code, instantiate a CryptographyClient using the key URI and call its DecryptAsync method.

Answer

Assign the Key Vault Crypto User role to the user-assigned managed identity for the contoso-vault scope, and in the C# application code, instantiate a CryptographyClient using the key URI and call its DecryptAsync method.

To decrypt data using a Key Vault key under the Azure RBAC model, you must assign a role that grants the data plane permission for cryptographic decryption (such as Key Vault Crypto User) to the identity used by the application (the user-assigned managed identity). In the Azure SDK for .NET, cryptographic operations must be executed using the CryptographyClient class rather than the KeyClient class, which is only used for management tasks.

Step-by-Step Solution

Assign the built-in Azure RBAC role for key cryptography.

The user-assigned managed identity is granted the Key Vault Crypto User role at the Key Vault scope.

This built-in role provides the minimum required data plane permissions (Microsoft.KeyVault/vaults/keys/decrypt/action) needed to decrypt data using keys in Azure Key Vault when Azure RBAC is used.

Implement the C# code using the correct client class in the Azure SDK for .NET.

The code uses CryptographyClient from the Azure.Security.KeyVault.Keys.Cryptography namespace to decrypt the cipher text.

In the modern Azure.Security.KeyVault SDK, KeyClient manages key lifecycles, whereas CryptographyClient is required to perform data plane cryptographic operations such as encrypting, decrypting, and wrapping.

Key Concept

Azure Key Vault key cryptography operations and RBAC role assignment using the Azure SDK for .NET.

Question 175Question →

You are developing a command-line interface (CLI) tool in C# that developers will run on Linux servers without a graphical user interface (GUI). The CLI tool must authenticate users against Microsoft Entra ID to access a secure downstream API on their behalf. You need to configure the Microsoft Entra ID application registration and implement the token acquisition logic in the C# code. Which two actions should you perform? (Select two.)

Select all that apply

In the Microsoft Entra ID application registration, configure the application as a public client by setting the 'Allow public client flows' option to Yes.

In the C# code, configure the application to use a system-assigned managed identity to authenticate the developer running the tool.

In the C# code, instantiate the client using PublicClientApplicationBuilder and call AcquireTokenWithDeviceCode.

In the C# code, instantiate the client using ConfidentialClientApplicationBuilder and call AcquireTokenForClient with a client secret.

Show answer & explanation

Answer: In the Microsoft Entra ID application registration, configure the application as a public client by setting the 'Allow public client flows' option to Yes.; In the C# code, instantiate the client using PublicClientApplicationBuilder and call AcquireTokenWithDeviceCode.

Answer

To authenticate a user from a headless CLI tool running on Linux, you must enable public client flows in the Entra ID application registration, and implement the token acquisition in C# using PublicClientApplicationBuilder and AcquireTokenWithDeviceCode.

To authenticate a user from a headless CLI tool running on a non-Azure environment, the application must be registered as a public client in Microsoft Entra ID with public client flows enabled. In the C# code, the application should be instantiated using the PublicClientApplicationBuilder, and the token should be acquired using the AcquireTokenWithDeviceCode method. This allows the user to complete authentication on another device that has a web browser.

Step-by-Step Solution

Identify the client application type and environment constraints.

The CLI tool runs on non-Azure Linux servers without a GUI, meaning it is a public client and cannot use interactive web browser redirects.

This determines that the Device Code flow is the appropriate OAuth 2.0 flow for user authentication.

Configure the Microsoft Entra ID application registration.

Enable the 'Allow public client flows' toggle (set to Yes) in the Authentication settings of the app registration.

Public clients like CLI tools must be explicitly allowed to use device code or username/password flows in Entra ID.

Implement the token acquisition logic in C#.

Use MSAL.NET's PublicClientApplicationBuilder to create the client and call AcquireTokenWithDeviceCode.

This invokes the device code flow, prompting the user to authenticate on another device using a verification URI and code.

Key Concept

Configuring Microsoft Identity Platform authentication for public client applications running on headless devices using the Device Code Flow.

Estimated Time:1m 30s

Question 176Question →

A developer deploys a C# API to an Azure App Service named api-prod. The API retrieves its database password from an Azure Key Vault named kv-prod. The Key Vault's permission model is configured to use Azure role-based access control (Azure RBAC).

To configure the App Service, the developer creates an application setting named DbPassword with the following value:
@Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbPassword)

After enabling the system-assigned managed identity on api-prod, the developer observes that the API receives a 403 Forbidden error when trying to retrieve the secret.

Which of the following actions should you perform to resolve the secret retrieval failure?

Create a Key Vault access policy in kv-prod that grants the Secret Get permission to the api-prod system-assigned managed identity.

Assign the Key Vault Secrets User role to the api-prod system-assigned managed identity at the key vault or secret scope.

Change the value of the DbPassword application setting in api-prod to @KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbPassword).

Create a user-assigned managed identity, assign it the Key Vault Secrets User role, and configure it as the identity of the kv-prod Key Vault itself.

Show answer & explanation

Answer: Assign the Key Vault Secrets User role to the api-prod system-assigned managed identity at the key vault or secret scope.

Answer

Assign the Key Vault Secrets User role to the api-prod system-assigned managed identity at the key vault or secret scope.

Since the Key Vault is configured to use the Azure RBAC permission model, you must use Azure role assignments to authorize access. Assigning the Key Vault Secrets User role to the App Service's system-assigned managed identity allows the application to read the secret value while maintaining least privilege.

Step-by-Step Solution

Identify the authorization model configured on the Azure Key Vault.

The Key Vault is configured to use the Azure role-based access control (Azure RBAC) permission model instead of access policies.

This determines how permissions must be granted to the client application.

Determine the correct identity to which permissions must be assigned.

The App Service api-prod has a system-assigned managed identity enabled, which must be granted access.

The client application uses its managed identity to authenticate against the Key Vault.

Select the appropriate Azure RBAC role and scope for least privilege secret retrieval.

Assign the Key Vault Secrets User role to the managed identity of the App Service at the key vault or individual secret scope.

Key Vault Secrets User is the built-in role that allows reading secret values, satisfying the least privilege requirement.

Key Concept

Azure Key Vault authorization using Azure RBAC vs Access Policies for App Service managed identities

Question 177Question →

You are developing a C# desktop application that will run on employee workstations. The application needs to retrieve user-specific records from an Azure SQL Database. You want to authenticate users via the Microsoft Identity Platform and access the database using the signed-in user's identity. Which authentication configuration should you implement?

Enable a system-assigned managed identity for the desktop application within Microsoft Entra ID and use the DefaultAzureCredential class to retrieve the token.

Create a system-assigned managed identity for the Azure SQL Database and store its client secret in the application configuration file.

Register the application as a public client in Microsoft Entra ID and use the Microsoft Authentication Library (MSAL.NET) to acquire a token using interactive authentication.

Generate a Shared Access Signature token with full read and write permissions and embed it directly in the client application source code.

Show answer & explanation

Answer: Register the application as a public client in Microsoft Entra ID and use the Microsoft Authentication Library (MSAL.NET) to acquire a token using interactive authentication.

Answer

Register the application as a public client in Microsoft Entra ID and use the Microsoft Authentication Library (MSAL.NET) to acquire a token using interactive authentication.

The correct answer correctly identifies that a desktop application running on local employee workstations is classified as a public client because it cannot keep application secrets confidential. Registering it as a public client and utilizing MSAL.NET to acquire a token interactively allows the app to authenticate the user and obtain a security token for Azure SQL Database under the user's active context.

Step-by-Step Solution

Analyze the application execution environment.

The application runs on local workstations, which makes it a public client application because it cannot secure confidential client credentials.

Identifying the client type determines the appropriate OAuth 2.0 flow and MSAL client configuration.

Determine the user authentication requirement.

The application must access the database under the signed-in user's identity.

This requires an interactive user authentication flow rather than service-level authentication.

Select the correct identity mechanism.

Managed identities are not supported on local development machines or employee workstations, necessitating MSAL-based user authentication.

Key Concept

Public client authentication with MSAL.NET

Question 178Question →

You are developing a secure C# web API that retrieves a database credential secret from Azure Key Vault. You need to automate the rotation of this secret using Azure Event Grid and a custom Azure Function. Which sequence of steps should you perform to configure the automated rotation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Deploy the Azure Function, enable its system-assigned managed identity and assign the Key Vault Secrets Officer role, create the Event Grid subscription for the SecretNearExpiry event targeting the function endpoint, and configure the secret's expiration and rotation policy parameters.

The correct order begins with deploying the function so that its endpoint is generated. Then, you enable the system-assigned managed identity and grant it Key Vault Secrets Officer permission to allow it to write new secret versions. Next, you link the function to Key Vault by creating the Event Grid subscription. Finally, you configure the rotation policy on the secret itself to schedule when the rotation sequence starts.

Step-by-Step Solution

Deploy the Azure Function containing rotation logic.

The HTTP trigger endpoint becomes active and accessible.

You cannot register an event subscription handler without a valid destination endpoint.

Enable system-assigned managed identity and assign Key Vault Secrets Officer role.

The Function App is authorized to perform write and update operations on Key Vault secrets.

The rotation function must write new secret versions to the vault, which requires the Secrets Officer role rather than the read-only Secrets User role.

Create an Event Grid subscription for the SecretNearExpiry event.

Key Vault secret expiry notifications are routed to the function.

This links the life cycle event of the secret directly to the custom handler function.

Configure the secret rotation policy parameters.

The secret starts automated lifecycle tracking.

The policy defines when the Key Vault will raise the SecretNearExpiry event before the actual secret expiration occurs.

Key Concept

Azure Key Vault automated secret rotation using Event Grid and Azure Functions.

Question 179Question →

You are developing a C# background daemon service that will run on an on-premises server. The service must periodically authenticate to the Microsoft Identity Platform without user interaction and retrieve files from a protected web API. You decide to use a client certificate stored in Azure Key Vault for authentication. The daemon service has an application registration in Microsoft Entra ID. Which two actions must you perform to configure the authentication flow and permissions? (Select two.)

Select all that apply

In the Microsoft Entra ID application registration, upload the public key (.cer file) of the client certificate.

Create an Azure Key Vault access policy that grants the application's service principal Get Secret and Get Certificate permissions.

In the Microsoft Entra ID application registration, upload the private key (.pfx file) of the client certificate.

Instantiate the application in code using PublicClientApplicationBuilder to enable certificate-based authentication.

Show answer & explanation

Answer: In the Microsoft Entra ID application registration, upload the public key (.cer file) of the client certificate.; Create an Azure Key Vault access policy that grants the application's service principal Get Secret and Get Certificate permissions.

Answer

To configure the authentication flow, you must upload the public key (.cer file) of the client certificate to the application registration in Microsoft Entra ID, and create an Azure Key Vault access policy that grants the application's service principal Get Secret and Get Certificate permissions.

To set up certificate authentication for a daemon application, you must upload the public key (.cer file) of the certificate to the application registration in Microsoft Entra ID. The application then uses the private key to sign the client assertion. Because the private key is stored securely in Azure Key Vault, you must grant the application's service principal Get Secret and Get Certificate permissions in the Key Vault access policy to retrieve the certificate at runtime.

Step-by-Step Solution

The public key (.cer file) is associated with the app registration.

Microsoft Entra ID requires the public key to validate token requests signed with the corresponding private key.

Authorize the daemon service to retrieve the certificate from Azure Key Vault.

The application's service principal is granted Get Secret and Get Certificate permissions in the Key Vault access policy.

The C# application must load the certificate (containing the private key) from the Key Vault at runtime to construct the client assertion.

Key Concept

Daemon applications are confidential clients that authenticate to the Microsoft Identity Platform using client credentials, such as certificates. This configuration requires registering the public key in Microsoft Entra ID and securely granting access to the private key in Key Vault.

Estimated Time:1m 30s

Question 180Question →

A development team is building a native C# client application that runs on domain-joined user workstations. The application needs to request an access token from the Microsoft Identity Platform to query a secure downstream Web API. The solution must support user accounts from any Microsoft Entra ID tenant as well as personal Microsoft accounts. Which approach should the team use to initialize the client application and configure authentication?

Grant access to a shared client secret using a Key Vault access policy and initialize the application using ConfidentialClientApplicationBuilder.

Configure a system-assigned managed identity for the user workstations and initialize the application using ManagedIdentityApplicationBuilder.

Initialize the client application using PublicClientApplicationBuilder.Create(clientId).WithAuthority(AzureCloudInstance.AzurePublic, "common").Build();

Generate a Shared Access Signature (SAS) token for the Web API and configure the client application to authenticate using the token.

Show answer & explanation

Answer: Initialize the client application using PublicClientApplicationBuilder.Create(clientId).WithAuthority(AzureCloudInstance.AzurePublic, "common").Build();

Answer

Initialize the client application using PublicClientApplicationBuilder.Create(clientId).WithAuthority(AzureCloudInstance.AzurePublic, "common").Build();

The correct answer initializes the client application as a public client application. Applications running on desktop computers are classified as public clients since they cannot keep client secrets confidential. The 'common' authority endpoint supports logging in users from any organizational directory (multi-tenant) as well as personal Microsoft accounts.

Step-by-Step Solution

Determine the client application type based on the execution environment.

Identify that the application runs on user workstations, which makes it a public client application because it cannot securely store secrets.

Public client applications must be initialized using PublicClientApplicationBuilder in MSAL.NET.

Identify the required identity providers and tenants for user login.

The requirement specifies supporting both work/school accounts from any tenant and personal Microsoft accounts.

The 'common' authority audience endpoint is designed to support both multi-tenant Entra ID organizations and personal consumer accounts.

Combine the builder type and authority configuration into the initialization code.

Instantiate the client app using PublicClientApplicationBuilder.Create(clientId).WithAuthority(AzureCloudInstance.AzurePublic, "common").Build().

This correctly configures the MSAL client for public interactive authentication with the widest account support.

Key Concept

MSAL.NET client application classification and authority selection

PreviousPage 9 / 11Next

Implement Azure Security

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept