CCNA Azure Security Questions — Page 2 of 3

MCQhard

Refer to the exhibit. You are deploying an ARM template that assigns the 'Storage Blob Data Contributor' role to the managed identity of an App Service named 'myapp' at the storage account 'mystorageacct' scope. The deployment fails with an error that 'principalId' is null. What is the most likely cause?

A.The role definition ID is incorrect.

B.The storage account name 'mystorageacct' does not exist.

C.The role assignment name is not unique.

D.The App Service 'myapp' does not have a managed identity enabled.

AnswerD

For an Azure resource like an App Service to be assigned an Azure RBAC role, it must possess an associated Azure Active Directory identity, which is provided by a managed identity. If the App Service 'myapp' does not have a system-assigned or user-assigned managed identity enabled, it lacks the necessary `principalId` (object ID) that Azure RBAC requires to create the role assignment. Consequently, the deployment fails because the `principalId` property cannot be resolved or is null, preventing the role from being assigned to the service.

Why this answer

The error 'principalId' is null indicates that the ARM template is attempting to assign a role to a principal that does not exist. In this scenario, the principal is the managed identity of the App Service 'myapp'. If the App Service does not have a managed identity enabled, the 'principalId' property in the role assignment resource will be null, causing the deployment to fail.

Enabling a system-assigned or user-assigned managed identity on the App Service is required before the role assignment can succeed.

Exam trap

The trap here is that candidates may assume the error is due to a missing storage account or incorrect role definition, but the null 'principalId' directly points to the managed identity not being enabled on the App Service.

How to eliminate wrong answers

Option A is wrong because an incorrect role definition ID would cause a 'RoleDefinitionIdNotFound' or similar error, not a null 'principalId'. Option B is wrong because a non-existent storage account would result in a 'ResourceNotFound' error, not a null 'principalId'. Option C is wrong because a non-unique role assignment name would produce a 'RoleAssignmentExists' conflict error, not a null 'principalId'.

Practice this question →

MCQhard

Your application uses Azure Key Vault to store cryptographic keys used for signing. You need to ensure that the keys can be used by multiple applications, but only one application should be able to delete the key. What should you do?

A.Assign the 'Key Vault Crypto Officer' role to the application that needs to delete, and 'Key Vault Crypto User' to others.

B.Enable soft-delete and purge protection on the key vault.

C.Create a key rotation policy that automatically deletes old keys.

D.Configure the key vault firewall to allow only the authorized application's IP.

AnswerA

The 'Key Vault Crypto Officer' Azure RBAC role grants comprehensive permissions over cryptographic keys, including the `delete` action, making it suitable for applications requiring the ability to remove keys. Conversely, the 'Key Vault Crypto User' role provides permissions for cryptographic operations like `encrypt` and `decrypt` but explicitly excludes deletion capabilities. This granular role assignment directly implements the principle of least privilege, ensuring only authorized applications can perform destructive actions on sensitive cryptographic material.

Why this answer

Azure RBAC for Key Vault allows granular permissions. The 'Key Vault Crypto Officer' role includes delete permission for keys, while the 'Key Vault Crypto User' role only allows cryptographic operations (sign, verify, encrypt, decrypt) without delete. This meets the requirement of allowing multiple applications to use keys but restricting deletion to one specific application.

Exam trap

The trap here is that candidates often confuse soft-delete/purge protection with access control, thinking they restrict who can delete, when in fact they only protect against permanent loss after a delete is already authorized.

How to eliminate wrong answers

Option B is wrong because soft-delete and purge protection prevent accidental or permanent deletion of keys, but they do not restrict which application can initiate a delete operation; any application with delete permission can still trigger soft-delete. Option C is wrong because a key rotation policy automatically creates new key versions and optionally archives old ones, but it does not control which application can delete keys; it is a lifecycle management feature, not an access control mechanism. Option D is wrong because configuring the key vault firewall restricts network access to the vault itself, but it does not differentiate permissions between applications that are allowed through the firewall; all allowed applications would have the same access level unless combined with RBAC roles.

Practice this question →

MCQmedium

Your API is secured using Azure AD (now Microsoft Entra ID) tokens. You need to validate the token in your custom code. Which library should you use to validate the token's signature, issuer, and audience?

A.ASP.NET Core Identity

B.Microsoft Graph SDK

C.Microsoft Authentication Library (MSAL)

D.Microsoft.IdentityModel.Tokens and System.IdentityModel.Tokens.Jwt

AnswerD

These libraries are the foundational components in .NET for handling and validating JSON Web Tokens (JWTs) issued by identity providers like Azure AD/Microsoft Entra ID. System.IdentityModel.Tokens.Jwt provides the core classes for reading, writing, and performing cryptographic validation of JWTs. Microsoft.IdentityModel.Tokens supplies the necessary security token validation parameters, such as issuer, audience, lifetime, and signing key resolution, to ensure the token's authenticity and integrity when securing an API.

Why this answer

The Microsoft.IdentityModel.Tokens and System.IdentityModel.Tokens.Jwt libraries provide the core token validation logic (signature verification, issuer, audience) that can be used in custom code, independent of any framework. These libraries implement the JWT validation pipeline as defined in RFC 7519, allowing you to call TokenValidationParameters and JwtSecurityTokenHandler.ValidateToken() to manually verify the token's integrity and claims.

Exam trap

The trap here is that candidates often confuse MSAL (which acquires tokens) with the token validation libraries, assuming the same library handles both sides of the authentication flow.

How to eliminate wrong answers

Option A is wrong because ASP.NET Core Identity is a membership and user store framework for managing user accounts, not a library for validating JWT tokens issued by Azure AD. Option B is wrong because the Microsoft Graph SDK is used to call Microsoft Graph APIs, not to validate tokens; it relies on an already-validated token to make requests. Option C is wrong because MSAL is designed for acquiring tokens (authentication), not for validating them; token validation is the responsibility of the resource API, not the client library.

Practice this question →

MCQhard

Your application uses Azure Functions and needs to authenticate to a downstream API using OAuth 2.0. The function app uses a system-assigned managed identity. Which token endpoint should the function app call to get a token for the downstream API?

A.https://{function-app}.azurewebsites.net/.auth/login

B.https://{downstream-api}.azurewebsites.net/.auth/me

C.https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

D.http://169.254.169.254/metadata/identity/oauth2/token

AnswerD

This is the correct and secure endpoint for Azure resources configured with a Managed Identity to acquire an access token. The Azure Instance Metadata Service (IMDS) provides this non-routable, local REST endpoint, accessible only from within the Azure resource (e.g., an Azure Function instance). When a managed identity makes a request to this specific IP address, IMDS intercepts it, authenticates the request as coming from the managed identity, and then securely requests an access token from Azure AD on behalf of that identity, returning it to the calling application. This mechanism eliminates the need for developers to manage any credentials.

Why this answer

The Azure Instance Metadata Service (IMDS) endpoint at http://169.254.169.254/metadata/identity/oauth2/token is the standard way for an Azure resource (like a Function App) with a system-assigned managed identity to obtain an OAuth 2.0 access token for a downstream API. This endpoint is used internally by the Azure SDK and is the only endpoint that directly leverages the managed identity without requiring any client secret or certificate.

Exam trap

The trap here is that candidates often confuse the standard Azure AD OAuth 2.0 token endpoint (Option C) with the managed identity token endpoint, not realizing that managed identities use a special internal endpoint (IMDS) that does not require tenant ID or client credentials.

How to eliminate wrong answers

Option A is wrong because https://{function-app}.azurewebsites.net/.auth/login is the App Service Authentication (EasyAuth) login endpoint, which is used to authenticate users (not the function app itself) and does not issue tokens for downstream APIs via managed identity. Option B is wrong because https://{downstream-api}.azurewebsites.net/.auth/me is an endpoint that returns claims about the currently authenticated user (or app) to the downstream API, but it is not a token endpoint that the function app can call to obtain a token. Option C is wrong because https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token is the standard OAuth 2.0 token endpoint for Azure AD applications that require a client secret or certificate; managed identities do not use this endpoint because they have no secrets to present.

Practice this question →

MCQmedium

A developer is implementing Key Vault certificate retrieval. The application runs on Azure App Service and must avoid stored credentials. Which design should be used? The design must avoid adding custom operational scripts.

A.Use a shared administrator account

B.Store a client secret in source control

C.Enable managed identity and grant least-privilege access to the target resource

D.Disable authentication for the target resource

AnswerC

Managed identity lets Azure-hosted apps authenticate without stored secrets.

Why this answer

Managed identity (system-assigned or user-assigned) allows the App Service to authenticate to Key Vault without any stored credentials, because Azure automatically rotates the identity's service principal and provides an access token via the Azure Instance Metadata Service (IMDS) endpoint. By granting least-privilege access (e.g., a Key Vault access policy with only 'Get' on secrets), the design meets the requirement to avoid stored credentials and custom operational scripts.

Exam trap

The trap here is that candidates may think storing a client secret in Azure App Service application settings (Option B) is acceptable because it's not in source control, but the question explicitly requires avoiding stored credentials entirely, and managed identity is the only zero-credential solution.

How to eliminate wrong answers

Option A is wrong because using a shared administrator account requires storing credentials (username/password or certificate) in the application configuration or code, violating the 'avoid stored credentials' requirement. Option B is wrong because storing a client secret in source control is a security anti-pattern that exposes credentials in the codebase, and it still requires manual secret rotation and management. Option D is wrong because disabling authentication for the target resource (Key Vault) would allow anonymous access, which is a severe security vulnerability and contradicts the principle of least privilege.

Practice this question →

MCQeasy

You need to restrict access to an Azure web app so that only traffic from a specific virtual network (VNet) can reach it. The web app is already deployed. What should you configure on the web app?

A.VNet integration

B.Access restrictions

C.Network Security Group (NSG) on the subnet

D.Point-to-Site VPN

AnswerB

Access restrictions are a native feature of Azure App Service designed specifically to control inbound network traffic to a web app. They allow administrators to define a set of allow/deny rules based on IP addresses (IPv4/IPv6 CIDR blocks) or by leveraging Virtual Network service endpoints to restrict access to specific subnets within an Azure VNet. This directly addresses the need to deny all traffic except from a particular source.

Why this answer

Access restrictions (also known as IP restrictions) allow you to define allow/deny rules based on source IP addresses or Virtual Network (VNet) service endpoints. By configuring a service endpoint-based rule that permits traffic only from your specific VNet, you can block all other inbound traffic to the web app. This is the correct mechanism for restricting access at the web app level without modifying the underlying infrastructure.

Exam trap

The trap here is confusing VNet integration (outbound) with access restrictions (inbound), leading candidates to select VNet integration when the question asks about restricting incoming traffic from a VNet.

How to eliminate wrong answers

Option A is wrong because VNet integration enables the web app to access resources inside a VNet (outbound connectivity), not to restrict inbound traffic from that VNet. Option C is wrong because an NSG on the subnet controls traffic to and from resources within that subnet, but it cannot directly filter traffic to an Azure App Service, which is a PaaS service not hosted in your VNet. Option D is wrong because Point-to-Site VPN is used for individual client machines to connect to a VNet, not for restricting inbound access to a web app from an entire VNet.

Practice this question →

MCQmedium

Your company has an application running on Azure Virtual Machines that needs to access secrets in Azure Key Vault. You want to restrict network access to the Key Vault so that only the virtual network/subnet containing the VMs can reach it. You also want to ensure that the solution works with the least management overhead. Which configuration should you use?

A.Configure Key Vault firewall with IP-based rules that allow the VM's public IP address.

B.Configure a Private Endpoint for the Key Vault in the same virtual network as the VMs.

C.Configure Key Vault firewall to allow access from the virtual network and subnet using service endpoints.

D.Use a shared access signature (SAS) to access Key Vault secrets.

AnswerC

Configuring Key Vault firewall to allow access from a specific virtual network and subnet using service endpoints is the most appropriate and secure solution for this scenario. Service endpoints extend the virtual network's identity to the Azure Key Vault service, allowing traffic to flow directly over the Azure backbone network rather than the public internet. This approach is straightforward to implement, ensuring that only resources within the designated subnet can access the Key Vault, thus providing robust network isolation.

Why this answer

Configuring Key Vault firewall with virtual network service endpoints allows you to restrict access to the Key Vault to a specific virtual network and subnet without exposing the VMs to the internet. This approach leverages Azure's backbone network for traffic, providing secure and direct connectivity with minimal management overhead, as service endpoints are automatically maintained by Azure.

Exam trap

The trap here is that candidates often confuse Private Endpoints with service endpoints, assuming Private Endpoints are always the best choice for network isolation, but service endpoints are simpler and have less management overhead when you only need to restrict access to a specific virtual network/subnet without requiring private IP connectivity.

How to eliminate wrong answers

Option A is wrong because using IP-based rules with the VM's public IP address exposes the VM to the internet and requires managing public IP changes, increasing management overhead and security risk. Option B is wrong because a Private Endpoint uses a private IP from the virtual network, which is more complex to set up and manage than service endpoints for this scenario, and it incurs additional costs for the private endpoint resource. Option D is wrong because shared access signatures (SAS) are used for granting delegated access to Azure Storage resources, not for accessing Key Vault secrets; Key Vault uses Azure AD authentication and access policies.

Practice this question →

MCQeasy

Your company uses Azure Key Vault to store secrets. You need to ensure that if a secret is deleted, it can be recovered within 30 days. Which Key Vault feature should you enable?

A.Soft-delete

B.Purge protection

C.RBAC (Role-Based Access Control)

D.Access policies

AnswerA

Soft-delete is the essential feature for recovering deleted secrets, keys, and certificates in Azure Key Vault. When enabled, it retains deleted items for a configurable retention period, typically 90 days by default, moving them to a 'soft-deleted' state. During this period, these items can be restored to their original state, preventing accidental or malicious permanent data loss and ensuring business continuity. This mechanism provides a crucial safety net for managing sensitive information within the vault.

Why this answer

Soft-delete is the correct feature because it allows you to recover a deleted secret within a configurable retention period (default 90 days, but can be set to as low as 1 day). When soft-delete is enabled, a deleted secret is marked as deleted but remains recoverable until the retention period expires. This directly meets the requirement to recover a secret within 30 days.

Exam trap

The trap here is that candidates often confuse purge protection with soft-delete, thinking that purge protection alone allows recovery, when in fact purge protection only prevents permanent deletion after soft-delete has already occurred.

How to eliminate wrong answers

Option B (Purge protection) is wrong because purge protection only prevents the permanent deletion of a soft-deleted secret until the retention period ends; it does not by itself enable recovery of a deleted secret. Option C (RBAC) is wrong because RBAC controls access permissions to Key Vault resources but has no effect on secret recovery after deletion. Option D (Access policies) is wrong because access policies define which users or applications can read, write, or delete secrets, but they do not provide any recovery capability for deleted secrets.

Practice this question →

MCQmedium

You are developing an ASP.NET Core web API hosted in Azure App Service. The API must call Azure Key Vault at runtime to retrieve database credentials. You need to configure authentication so the app can access the vault without storing any secrets in code or app settings. What should you do?

A.Register an app in Microsoft Entra ID and add a client secret to the app's configuration.

B.Store the Key Vault access key in Azure App Configuration and reference it from the app.

C.Enable a system-assigned managed identity on the App Service and grant it access to the Key Vault.

D.Use the App Service's publishing profile credentials to authenticate to Key Vault.

AnswerC

A system-assigned managed identity gives the App Service its own identity in Microsoft Entra ID. You can grant that identity access to Key Vault using an access policy or Azure RBAC role, and the app authenticates to Key Vault without any stored credentials. This directly satisfies the requirement of no secrets in code or configuration.

Why this answer

A system-assigned managed identity is the correct approach because it provides an identity for the App Service in Microsoft Entra ID, allowing it to authenticate to Key Vault without any stored secrets. Granting that identity access via Key Vault access policies or Azure RBAC enables secure, credential-free retrieval of secrets at runtime, which is the standard pattern for this requirement.

Exam trap

The trap here is assuming that any credential stored outside code, such as in App Configuration or a client secret, satisfies the no-secrets requirement when only a managed identity truly eliminates stored credentials.

Practice this question →

MCQeasy

You need to ensure that secrets stored in Azure Key Vault are automatically rotated every 90 days. Which feature should you configure?

A.Set an access policy for the secret

B.Enable soft delete and purge protection

C.Set a secret expiration date

D.Use Key Vault secret rotation with Event Grid and Azure Functions

AnswerD

The recommended approach for automated secret rotation involves leveraging Azure Key Vault's ability to publish events to Azure Event Grid when a secret is nearing expiration or when a rotation policy is triggered. An Azure Function can then subscribe to these Event Grid events, execute custom logic to generate a new secret value, update the secret in Key Vault, and potentially update the consuming application's configuration. This event-driven architecture provides a robust and extensible solution for proactive secret management.

Why this answer

Azure Key Vault does not natively rotate secrets automatically. To achieve automatic rotation every 90 days, you must integrate Key Vault with Event Grid to detect secret expiration events and trigger an Azure Function that generates a new secret version and updates the expiration date. This pattern is the recommended solution for automated secret rotation.

Exam trap

The trap here is that candidates assume setting an expiration date (Option C) automatically triggers rotation, but Key Vault only marks the secret as expired—it does not create a new version or notify any service to rotate it.

How to eliminate wrong answers

Option A is wrong because an access policy controls who can read or manage secrets, not how or when secrets are rotated. Option B is wrong because soft delete and purge protection are data recovery features that prevent accidental or malicious deletion; they have no effect on secret lifecycle or rotation scheduling. Option C is wrong because setting a secret expiration date only marks the secret as expired after a specified time; it does not trigger any automatic renewal or rotation of the secret.

Practice this question →

MCQhard

You are designing a solution that uses Azure Event Hubs to ingest telemetry data. The data must be encrypted at rest and in transit. Additionally, you need to ensure that only authorized applications can publish messages to the event hub. Which combination of features should you use?

A.Use managed identities for applications and enable encryption at rest using customer-managed keys.

B.Use SAS tokens or managed identities for authentication, and rely on default encryption at rest and in transit.

C.Use Azure Private Link to connect applications to Event Hubs.

D.Enable Azure Firewall on the Event Hubs namespace and use IP filtering.

AnswerB

This option correctly identifies the standard and recommended security practices for Azure Event Hubs. Both Shared Access Signatures (SAS) and Managed Identities are valid and widely used mechanisms for authenticating applications to Event Hubs, providing robust authorization. Furthermore, Azure Event Hubs automatically encrypts data at rest using Microsoft-managed keys and encrypts all data in transit using Transport Layer Security (TLS), fulfilling essential encryption requirements without requiring additional configuration.

Why this answer

Azure Event Hubs automatically encrypts data at rest with Azure Storage Service Encryption (SSE) and in transit with TLS 1.2. For authorization, SAS tokens or managed identities provide the necessary application-level authentication to publish messages. This combination meets all stated requirements without additional configuration.

Exam trap

The trap here is that candidates often over-engineer the solution by selecting advanced features like customer-managed keys or Private Link, when the default encryption and simple authentication mechanisms already satisfy the stated requirements.

How to eliminate wrong answers

Option A is wrong because while managed identities can authenticate applications, customer-managed keys (CMK) are an optional encryption-at-rest feature that is not required to meet the 'encrypted at rest' requirement—default encryption already satisfies it. Option C is wrong because Azure Private Link only secures network connectivity by exposing the Event Hubs namespace to a virtual network; it does not handle encryption at rest or application-level authorization for publishing. Option D is wrong because Azure Firewall and IP filtering control network access at the namespace level but do not provide application-level authentication or encryption at rest; they are complementary security layers, not the primary solution for authorized publishing.

Practice this question →

MCQmedium

Refer to the exhibit. You deploy an Azure Storage account using the ARM template snippet. A developer reports that they cannot connect to the storage account from their machine with IP 10.0.0.5, even though they have the proper RBAC role. What is the most likely reason?

A.The storage account is configured to bypass Azure Services, which blocks non-Azure clients.

B.The developer does not have the Storage Blob Data Contributor role.

C.The storage account firewall is configured to deny all traffic except from the 192.168.1.0/24 IP range.

D.The minimum TLS version is set to TLS 1.2, but the developer's client uses TLS 1.0.

AnswerC

Azure Storage account firewalls operate on a default-deny principle, meaning all network traffic is blocked unless explicitly allowed by a configured rule. If the storage account firewall is configured to permit traffic exclusively from the 192.168.1.0/24 IP range, any connection attempt originating from an IP address outside this specific range will be immediately rejected at the network perimeter. This prevents the developer's client from establishing a connection, as their IP address is not within the allowed subnet, resulting in a network access denied error.

Why this answer

The ARM template snippet configures a network rule that only allows traffic from the 192.168.1.0/24 IP range. Since the developer's machine has IP 10.0.0.5, it falls outside this allowed range, causing the connection to be blocked by the storage account firewall, regardless of RBAC permissions. RBAC controls authorization (who can access), but network rules control access (who can reach the endpoint), and the firewall denies all traffic not explicitly permitted.

Exam trap

The trap here is that candidates assume RBAC roles alone grant access, overlooking that Azure Storage firewalls enforce network-level restrictions that are evaluated before any authorization checks.

How to eliminate wrong answers

Option A is wrong because 'bypass Azure Services' is a setting that allows trusted Azure platform services to bypass the firewall, but it does not block non-Azure clients; it only permits specific Azure services. Option B is wrong because the developer already has the proper RBAC role (as stated), and RBAC roles like Storage Blob Data Contributor grant authorization but do not override network-level firewall rules. Option D is wrong because the ARM template snippet does not specify a minimum TLS version; even if it did, TLS 1.0 is not supported by Azure Storage (which requires TLS 1.2 by default), but the question states the developer cannot connect, and the most likely reason is the explicit IP restriction, not TLS version mismatch.

Practice this question →

MCQeasy

You are developing a web application that stores user profile images in an Azure Storage account. The images must be accessible only to authenticated users of your application, and you want to avoid managing access keys. You need to configure the storage account to allow the app to access blobs securely using Microsoft Entra ID. What should you do?

A.Generate a shared access signature (SAS) token and embed it in the application code.

B.Assign the Storage Blob Data Contributor role to the app's managed identity.

C.Store the storage account key in Azure Key Vault and retrieve it at runtime.

D.Enable anonymous public access on the container.

AnswerB

Assigning the Storage Blob Data Contributor role to the app's managed identity grants the app permission to read and write blobs using Microsoft Entra ID authentication. This avoids access keys and allows secure, role-based access. The app can use the Azure Identity SDK to obtain a token and access blobs without managing secrets.

Why this answer

The correct approach is to assign the Storage Blob Data Contributor role to the app's managed identity. This enables the app to authenticate to Azure Storage using Microsoft Entra ID and access blobs with role-based permissions, eliminating the need for access keys or SAS tokens. It aligns with the requirement to avoid managing access keys and ensures only authenticated and authorized identities can access the images.

Exam trap

The trap here is thinking that using Key Vault to store the storage account key is sufficient, when the requirement is to use Microsoft Entra ID and avoid access keys altogether.

Practice this question →

MCQmedium

A company stores sensitive data in an Azure Storage account. They need to restrict access based on the client's IP address and require that clients use a valid SAS token. Which mechanism should they use?

A.Microsoft Entra ID authentication.

B.Shared Key.

C.SAS token with IP ACL.

D.Firewall and virtual networks.

AnswerC

A Shared Access Signature (SAS) token provides delegated access to Azure Storage resources with granular control over permissions, services, resource types, and validity period. Critically, a SAS token can include an `sip` (signed IP) parameter, which specifies an acceptable range of public IP addresses or a single IP address from which requests must originate. This ensures that even if the SAS token is intercepted, it can only be used by clients within the designated IP range, significantly enhancing security for specific, time-limited operations.

Why this answer

A SAS token with an IP ACL (access control list) allows you to restrict access to a specific client IP address or range of IP addresses while also requiring a valid SAS token for authentication. This meets both requirements: IP-based restriction and SAS token validation. The IP ACL is specified as part of the SAS token's signed IP (sip) parameter, which enforces that requests must originate from the allowed IP range.

Exam trap

The trap here is that candidates often confuse network-level IP restrictions (firewall/VNet) with SAS-level IP restrictions, not realizing that only a SAS token with an IP ACL can enforce both a valid token and a specific client IP address simultaneously.

How to eliminate wrong answers

Option A is wrong because Microsoft Entra ID authentication does not use SAS tokens; it relies on Azure AD identities and RBAC roles, which cannot enforce a client IP restriction at the SAS token level. Option B is wrong because Shared Key authentication uses the storage account key directly, which does not support IP-based restrictions and does not involve a SAS token. Option D is wrong because Firewall and virtual networks can restrict access by IP address, but they do not require a SAS token; they operate at the network layer and can be bypassed if the SAS token is not enforced.

Practice this question →

MCQeasy

You need to secure a web API that is called from a single-page application (SPA). The API uses Microsoft Entra ID for authentication. Which OAuth 2.0 flow should the SPA use?

A.Authorization code flow with PKCE

B.Resource owner password credentials flow

C.Client credentials flow

D.Implicit flow

AnswerA

The Authorization Code flow with PKCE (Proof Key for Code Exchange) is the recommended and most secure method for Single-Page Applications (SPAs) because it eliminates the need for a client secret, which SPAs cannot securely store. It involves a two-step process where the SPA first obtains an authorization code, then exchanges it for tokens at the identity provider's token endpoint. PKCE adds a dynamic secret (code verifier/challenge) to this exchange, preventing code interception attacks by ensuring only the original client can redeem the authorization code.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth 2.0 flow for single-page applications because it provides a secure way to obtain an access token without exposing the client secret, which cannot be stored confidentially in a browser. PKCE adds a cryptographic challenge to prevent authorization code interception attacks, making it the only flow that meets modern security standards for public clients like SPAs calling Microsoft Entra ID-protected APIs.

Exam trap

The trap here is that candidates may choose the Implicit flow (Option D) because it was historically the standard for SPAs, but Microsoft Entra ID and OAuth 2.0 BCP now deprecate it in favor of the authorization code flow with PKCE, which is the only secure option for public clients.

How to eliminate wrong answers

Option B (Resource owner password credentials flow) is wrong because it requires the user to provide their username and password directly to the SPA, which violates the principle of least privilege and is not recommended for interactive web applications; it also does not support multi-factor authentication or conditional access policies in Entra ID. Option C (Client credentials flow) is wrong because it is designed for server-to-server (daemon) applications that authenticate without a user context, not for SPAs that need to act on behalf of a signed-in user. Option D (Implicit flow) is wrong because it was historically used for SPAs but is now deprecated by OAuth 2.0 Security Best Current Practice (BCP) due to security vulnerabilities, such as access token leakage in the browser history and lack of token binding; Microsoft Entra ID recommends the authorization code flow with PKCE instead.

Practice this question →

MCQeasy

You are configuring an Azure App Service web app to authenticate users with Microsoft Entra ID. You need to ensure that only users from your organization's tenant can access the app. Which setting should you configure?

A.Set the Issuer URL to https://login.microsoftonline.com/common/v2.0

B.Set the Client ID to the application's Application ID.

C.Set the Allowed token audiences to include the app's Application ID URI.

D.Set the Issuer URL to https://login.microsoftonline.com/{tenant-id}/v2.0

AnswerD

Setting the Issuer URL to https://login.microsoftonline.com/{tenant-id}/v2.0 is the correct method to restrict authentication to a specific Azure AD tenant. The Issuer URL, which corresponds to the 'iss' claim in a JWT, identifies the security token service that issued the token. By specifying a unique {tenant-id} (or a verified domain name) in this URL, the application is configured to only trust and accept tokens issued by that particular Azure AD instance, thereby enforcing single-tenant access control.

Why this answer

Setting the Issuer URL to `https://login.microsoftonline.com/{tenant-id}/v2.0` restricts token validation to only tokens issued by your specific Microsoft Entra ID tenant. This ensures that only users from your organization's tenant can authenticate, as the app will reject tokens from other tenants or the common endpoint.

Exam trap

The trap here is that candidates often confuse the Issuer URL with the Client ID or Allowed token audiences, thinking that setting the Client ID alone will restrict access to a specific tenant, when in fact it only identifies the app, not the tenant.

How to eliminate wrong answers

Option A is wrong because using `https://login.microsoftonline.com/common/v2.0` as the Issuer URL allows tokens from any Microsoft Entra ID tenant or personal Microsoft accounts, which would permit users outside your organization to access the app. Option B is wrong because setting the Client ID to the application's Application ID is required for the app to identify itself to Microsoft Entra ID, but it does not restrict access to a specific tenant; it only ensures the correct app is being used during authentication. Option C is wrong because configuring the Allowed token audiences to include the app's Application ID URI ensures that the token is intended for your app, but it does not enforce tenant-level restrictions; it only validates the token's audience claim.

Practice this question →

MCQeasy

You are deploying a function app that processes sensitive data. You need to ensure that all function app secrets (e.g., connection strings) are stored securely and automatically rotated. Which service should you use?

A.Azure Key Vault

B.Azure Managed Identity

C.Azure App Configuration

D.Azure DevOps Variable Groups

AnswerA

Azure Key Vault stores connection strings as secrets with versioning, access policies and optional automatic rotation, so the function app retrieves them at runtime via managed identity rather than embedding them in configuration. This satisfies secure storage and rotation for sensitive data.

Why this answer

Azure Key Vault is the correct service because it provides centralized, hardware-backed storage for secrets such as connection strings, API keys, and certificates. It supports automatic rotation policies via integration with Azure Event Grid and can be triggered by expiration events or custom logic, ensuring secrets are rotated without manual intervention. Function apps can securely reference Key Vault secrets using a managed identity, eliminating the need to store secrets in code or configuration files.

Exam trap

The trap here is that candidates often confuse Azure Managed Identity (an authentication method) with a secret storage service, or they assume Azure App Configuration can handle secret rotation, when in fact it lacks the security guarantees and rotation features of Key Vault.

How to eliminate wrong answers

Option B is wrong because Azure Managed Identity is an authentication mechanism that provides an automatically managed service principal for Azure resources, not a secret storage or rotation service. Option C is wrong because Azure App Configuration is designed for managing application configuration settings and feature flags, but it does not natively support automatic secret rotation or hardware-backed security. Option D is wrong because Azure DevOps Variable Groups store secrets in Azure DevOps, but they lack native automatic rotation capabilities and are not integrated with Azure's key management infrastructure.

Practice this question →

MCQeasy

Your company stores API keys and connection strings in Azure Key Vault. You need to grant an Azure Function read access to these secrets using the principle of least privilege. Which identity type should you assign to the Function App?

A.System-assigned managed identity

B.User-assigned managed identity

C.Service principal

D.Access policy on the Key Vault

AnswerA

A system-assigned managed identity is automatically created and managed by Azure, directly tied to the lifecycle of a single Azure resource, such as a Virtual Machine or App Service. This identity can be granted specific Azure Key Vault access policies, allowing the resource to securely retrieve secrets without any hardcoded credentials or manual secret rotation. It inherently adheres to the principle of least privilege and offers the simplest, most secure method for a single resource to access Key Vault.

Why this answer

A system-assigned managed identity is the correct choice because it is directly tied to the lifecycle of the Azure Function, automatically managed by Azure, and requires no manual credential rotation. It provides the most restrictive scope (only that specific Function App) and adheres to the principle of least privilege by granting access only to the identity that needs it, without the overhead of managing a separate identity or service principal.

Exam trap

The trap here is that candidates often confuse 'access policy' (a permission assignment) with an 'identity type,' or they incorrectly assume a user-assigned managed identity is always more flexible and thus better, overlooking that a system-assigned identity is more restrictive and simpler for a single-resource scenario.

How to eliminate wrong answers

Option B is wrong because a user-assigned managed identity is a standalone resource that can be shared across multiple Azure services, which violates the principle of least privilege by potentially granting broader access than necessary. Option C is wrong because a service principal requires manual credential management (secrets or certificates) and is typically used for external applications or automation, not for a first-party Azure resource like a Function App where a managed identity is simpler and more secure. Option D is wrong because an access policy on the Key Vault is not an identity type; it is a permission assignment mechanism that must be applied to an identity (such as a managed identity or service principal), so it cannot be the identity type itself.

Practice this question →

MCQeasy

Your application uses Azure App Service and needs to authenticate users via Microsoft Entra ID. You want to minimize code changes. Which feature should you use?

A.Azure AD B2C

B.Microsoft.Identity.Web library

C.App Service Authentication (Easy Auth)

D.MSAL.js

AnswerC

App Service Authentication, commonly known as Easy Auth, is a platform-level feature of Azure App Service that provides built-in authentication and authorization capabilities without requiring code changes within the application. It acts as an authentication proxy, intercepting requests and handling the entire authentication flow with Microsoft Entra ID, then passing user claims to the application via HTTP headers. This approach offers seamless integration with enterprise identities and significantly reduces development overhead, making it ideal for scenarios prioritizing minimal application code modifications.

Why this answer

App Service Authentication (also known as Easy Auth) is the correct choice because it enables authentication with Microsoft Entra ID (formerly Azure AD) at the platform level, requiring no code changes in your application. It automatically handles token validation, session management, and redirects by intercepting HTTP requests before they reach your app code, which directly satisfies the requirement to minimize code changes.

Exam trap

The trap here is that candidates often choose Microsoft.Identity.Web or MSAL.js because they are familiar with code-based authentication, overlooking that the question explicitly prioritizes minimizing code changes, which is the core advantage of Easy Auth's platform-level integration.

How to eliminate wrong answers

Option A is wrong because Azure AD B2C is designed for customer-facing identity management with social logins and custom policies, not for enterprise authentication with Microsoft Entra ID, and it requires significant code changes to integrate. Option B is wrong because the Microsoft.Identity.Web library is a code-based middleware that requires adding NuGet packages, modifying startup code, and configuring authentication handlers, which contradicts the goal of minimizing code changes. Option D is wrong because MSAL.js is a client-side JavaScript library that requires you to write authentication logic in the browser, handle token acquisition and renewal in code, and does not offload authentication to the platform layer like Easy Auth does.

Practice this question →

MCQeasy

You are developing an application that stores user secrets. You need to ensure that the secrets are encrypted at rest and rotated automatically. Which Azure service should you integrate?

A.Azure Storage.

B.Azure Key Vault.

C.Azure Security Center.

D.Microsoft Entra ID.

AnswerB

Azure Key Vault is purpose-built for the secure storage and management of cryptographic keys, secrets, and certificates. It provides robust protection for secrets using FIPS 140-2 Level 2 validated Hardware Security Modules (HSMs), offers fine-grained access control through Azure RBAC and Key Vault access policies, and supports automatic secret rotation, versioning, and comprehensive auditing. This dedicated design ensures the confidentiality and integrity of sensitive user secrets throughout their lifecycle.

Why this answer

Azure Key Vault is the correct choice because it provides centralized management of secrets, keys, and certificates with built-in encryption at rest using FIPS 140-2 Level 2 validated hardware security modules (HSMs). It also supports automatic rotation of secrets through integration with Azure Event Grid and Azure Functions, enabling you to schedule or trigger key rotation policies without manual intervention.

Exam trap

The trap here is that candidates often confuse Azure Storage's built-in encryption at rest with the need for a dedicated secrets management service, overlooking that Key Vault alone provides both encryption at rest and automated rotation for secrets.

How to eliminate wrong answers

Option A is wrong because Azure Storage encrypts data at rest by default using server-side encryption (SSE) but does not provide native secret rotation capabilities or a dedicated secrets management interface. Option C is wrong because Azure Security Center is a unified security management and threat protection service that monitors security posture and provides recommendations, but it does not store or rotate secrets. Option D is wrong because Microsoft Entra ID (formerly Azure AD) is an identity and access management service that handles authentication and authorization, not the storage or rotation of application secrets.

Practice this question →

MCQmedium

Your application uses Azure App Configuration with Microsoft Entra ID authentication. You want to ensure that only authorized services can read configuration values. What is the recommended approach?

A.Enable public network access only from trusted IPs

B.Use access keys and rotate them frequently

C.Store connection strings in Azure Key Vault and retrieve them at runtime

D.Assign the App Configuration Data Reader role to the managed identity of the consuming service

AnswerD

Assigning the App Configuration Data Reader role to the managed identity of the consuming service is the most secure and recommended approach. A managed identity provides an automatically managed identity in Azure Active Directory for Azure services, eliminating the need for developers to manage credentials. By assigning this specific Azure built-in role, the service is granted least-privilege access to read configuration data directly from App Configuration using its own identity, without any shared secrets or connection strings.

Why this answer

The recommended approach for authorizing access to Azure App Configuration with Microsoft Entra ID is to use role-based access control (RBAC). By assigning the 'App Configuration Data Reader' role to a managed identity, you grant that specific service identity read-only access to configuration values without exposing keys or connection strings. This aligns with the principle of least privilege and eliminates the security risks associated with shared access keys.

Exam trap

The trap here is that candidates often confuse storing connection strings in Key Vault (Option C) as the most secure approach, but the question specifically asks for the recommended approach with Entra ID authentication, which is to use managed identities and RBAC instead of any form of shared access keys.

How to eliminate wrong answers

Option A is wrong because enabling public network access from trusted IPs controls network-level access but does not authenticate or authorize the caller; it still relies on access keys or Entra ID tokens and does not eliminate the need for proper identity-based authorization. Option B is wrong because using access keys and rotating them frequently is a legacy approach that introduces shared secrets, which are more vulnerable to leakage and do not leverage Entra ID's managed identities for fine-grained, identity-based access control. Option C is wrong because storing connection strings in Azure Key Vault and retrieving them at runtime is a valid pattern for secrets management, but it still uses access keys (connection strings) rather than Entra ID authentication, and the consuming service would need permissions to the Key Vault, adding complexity without adopting the recommended identity-based approach.

Practice this question →

MCQmedium

You are developing an API that processes sensitive personal data. The API is exposed via Azure API Management (APIM). You need to ensure that only authorized applications can call the API, and you want to validate the token at the APIM gateway without modifying the backend code. What is the most efficient approach?

A.Implement token validation in the backend API code

B.Use APIM's OAuth 2.0 authorization server

C.Use subscription keys in APIM

D.Configure a validate-jwt policy in APIM inbound processing

AnswerD

Configuring a `validate-jwt` policy within APIM's inbound processing is the most effective and recommended approach for validating JSON Web Tokens. This policy allows the API Management gateway to cryptographically verify the token's signature, check its expiration, validate issuer and audience claims, and ensure its overall integrity *before* the request even reaches the backend API. This offloads security responsibilities from the backend, centralizes validation logic, and enhances performance by rejecting invalid requests early in the request pipeline.

Why this answer

The validate-jwt policy in APIM's inbound processing validates the OAuth 2.0 token at the gateway level, ensuring only authorized applications can call the API without modifying backend code. This is the most efficient approach because it offloads token validation to APIM, reducing backend complexity and centralizing security enforcement.

Exam trap

The trap here is that candidates confuse APIM's OAuth 2.0 authorization server (which issues tokens) with the validate-jwt policy (which validates tokens), leading them to choose Option B instead of D.

How to eliminate wrong answers

Option A is wrong because implementing token validation in the backend API code requires modifying the backend, which contradicts the requirement to avoid backend changes. Option B is wrong because APIM's OAuth 2.0 authorization server is used to issue tokens, not to validate them at the gateway; validation is done via policies like validate-jwt. Option C is wrong because subscription keys provide API-level access control but do not validate token claims or enforce OAuth 2.0 authorization; they are not suitable for validating sensitive personal data access.

Practice this question →

MCQeasy

Your organization has a custom application that stores customer data in Azure Cosmos DB. You need to encrypt the data at rest using a customer-managed key stored in Azure Key Vault. Which type of Cosmos DB encryption should you configure?

A.Enable Azure Disk Encryption on the Cosmos DB instance

B.Enable Transparent Data Encryption (TDE)

C.Use customer-managed keys (CMK) with Azure Key Vault

D.Implement client-side encryption using the SDK

AnswerC

Azure Cosmos DB inherently encrypts all data at rest using service-managed keys, but for enhanced security and compliance requirements, it supports customer-managed keys (CMK). By integrating with Azure Key Vault, customers can provide their own encryption keys, gaining full control over the key lifecycle, including rotation, revocation, and auditing. This ensures that even Microsoft cannot access the data without the customer's explicit key, fulfilling stringent data governance policies.

Why this answer

Azure Cosmos DB supports customer-managed keys (CMK) integrated with Azure Key Vault to encrypt data at rest. This allows you to bring your own key (BYOK) and control key rotation, revocation, and access policies, meeting the requirement for a customer-managed key stored in Azure Key Vault.

Exam trap

The trap here is confusing client-side encryption (which encrypts data before transmission) with server-side encryption at rest using CMK, leading candidates to select Option D instead of the correct server-side CMK configuration.

How to eliminate wrong answers

Option A is wrong because Azure Disk Encryption is a feature for encrypting virtual machine disks, not for Cosmos DB, which is a PaaS database service. Option B is wrong because Transparent Data Encryption (TDE) is a SQL Server and Azure SQL Database feature, not applicable to Cosmos DB. Option D is wrong because client-side encryption encrypts data before it is sent to the database, not at rest; the requirement specifies encrypting data at rest using a customer-managed key, which is server-side encryption.

Practice this question →

MCQeasy

Refer to the exhibit. You created a custom RBAC role definition. A user assigned this role at the subscription scope. What can the user do?

A.Read any resource in the subscription

B.Write to Azure SQL Databases

C.Read Azure SQL Database configurations and data

D.Create new Azure SQL Databases

AnswerC

This custom RBAC role is designed to provide read-only access to Azure SQL Databases. This typically includes actions like "Microsoft.Sql/servers/databases/read" for general database properties, "Microsoft.Sql/servers/databases/metrics/read" for performance data, and potentially "Microsoft.Sql/servers/databases/transparentDataEncryption/read" for security settings. Such permissions allow users to view database configurations, monitor performance, and query data without the ability to modify the database or its underlying infrastructure.

Why this answer

The custom RBAC role definition includes the 'Microsoft.Sql/servers/databases/read' action, which grants read access to Azure SQL Database configurations and data at the subscription scope. This action allows the user to view database settings and query data, but does not permit write or create operations.

Exam trap

The trap here is that candidates often assume a 'read' action at the subscription scope implies read access to all resource types, but RBAC requires explicit action definitions for each resource provider, and Azure SQL Database read permissions are specific to the 'Microsoft.Sql' namespace.

How to eliminate wrong answers

Option A is wrong because the role only includes specific read actions for SQL and other resources, not a wildcard like '*/read' that would allow reading any resource in the subscription. Option B is wrong because the role lacks write actions such as 'Microsoft.Sql/servers/databases/write' or 'Microsoft.Sql/servers/databases/data/write' for Azure SQL Databases. Option D is wrong because creating new Azure SQL Databases requires the 'Microsoft.Sql/servers/databases/write' action, which is not included in the role definition.

Practice this question →

100

MCQmedium

You are developing an Azure Function that processes messages from an Azure Service Bus queue. The function must use a managed identity to authenticate to the Service Bus to avoid managing secrets. Which configuration step is essential for this setup?

A.Store the Service Bus connection string in the function app settings

B.Create a Key Vault reference to the connection string

C.Enable system-assigned managed identity on the function app and assign the 'Azure Service Bus Data Receiver' role to the identity

D.Use the Service Bus SDK with a SharedAccessSignatureToken

AnswerC

Enabling a system-assigned managed identity on the function app and assigning the 'Azure Service Bus Data Receiver' role is the most secure and recommended approach. This method allows the Azure Function to authenticate directly with Azure Active Directory (Azure AD) and subsequently authorize against Azure Service Bus without needing any connection strings, keys, or secrets stored within the function app or Key Vault. Azure automatically manages the identity's lifecycle, eliminating the burden of credential management and rotation for developers.

Why this answer

Using a managed identity eliminates the need to manage secrets or connection strings. By enabling a system-assigned managed identity on the function app and assigning the 'Azure Service Bus Data Receiver' role to that identity, the function can authenticate to Azure Service Bus via Azure AD (OAuth 2.0) without any stored credentials. This is the recommended approach for secure, secretless authentication in Azure Functions.

Exam trap

The trap here is that candidates often think storing secrets in Key Vault (Option B) is sufficient for secretless authentication, but Key Vault references still involve retrieving a secret at runtime, whereas managed identity completely removes the need for any secret.

How to eliminate wrong answers

Option A is wrong because storing the Service Bus connection string in function app settings reintroduces a secret that must be managed and rotated, defeating the purpose of using a managed identity for secretless authentication. Option B is wrong because a Key Vault reference still requires the function app to retrieve a connection string (a secret) at runtime, which does not eliminate secret management and adds dependency on Key Vault access policies. Option D is wrong because using a SharedAccessSignatureToken requires generating and managing a SAS token, which is a secret that must be stored and rotated, again contradicting the goal of avoiding secret management.

Practice this question →

101

MCQmedium

Your Azure Logic App needs to send emails using Microsoft Graph API on behalf of the signed-in user. The user is authenticated with Microsoft Entra ID. Which authentication method should you use in the Logic App?

A.Use OAuth 2.0 authorization code flow with delegated permissions

B.Use a system-assigned managed identity

C.Use client credentials flow with an app registration

D.Use Basic authentication with user credentials

AnswerA

The OAuth 2.0 authorization code flow with delegated permissions is the correct choice because it enables the Logic App to act on behalf of a specific signed-in user. This flow involves the user consenting to the application accessing their resources, granting the Logic App temporary, user-scoped permissions to send emails as that user via Microsoft Graph. It ensures that the email appears to originate from the user's mailbox, respecting their identity and permissions.

Why this answer

The OAuth 2.0 authorization code flow with delegated permissions is correct because the Logic App needs to act on behalf of the signed-in user, not as an application itself. This flow allows the user to authenticate via Microsoft Entra ID and grant the Logic App delegated permissions to call Microsoft Graph API (e.g., to send emails as the user). The authorization code is exchanged for an access token that includes the user's context, enabling the API to enforce user-level permissions.

Exam trap

The trap here is that candidates often confuse delegated permissions (user context) with application permissions (app-only context), leading them to choose client credentials flow (Option C) or managed identity (Option B) when the requirement explicitly says 'on behalf of the signed-in user'.

How to eliminate wrong answers

Option B is wrong because a system-assigned managed identity is used for application-level authentication (client credentials flow) and cannot act on behalf of a signed-in user; it represents the Logic App itself, not the user. Option C is wrong because the client credentials flow is designed for server-to-server scenarios without a user context, so it cannot send emails on behalf of a specific signed-in user. Option D is wrong because Basic authentication with user credentials is deprecated and insecure, and Microsoft Graph API does not support Basic authentication; it requires OAuth 2.0 tokens.

Practice this question →

102

MCQmedium

A developer needs to grant an Azure Function read access to secrets in Azure Key Vault without storing any credentials in the function code or configuration. Which approach should they use?

A.Service principal with a certificate

B.Managed identity

C.Access policy with a client secret

D.Shared access signature (SAS)

AnswerB

Managed identity is the optimal solution as it completely eliminates the need for developers to manage any credentials for their Azure Function. Azure automatically provisions and manages an identity in Azure Active Directory for the Function App. This identity can then be granted specific access policies or RBAC roles on the Azure Key Vault, allowing the Function to securely obtain tokens and access secrets without storing any secrets, certificates, or connection strings within the application code or configuration.

Why this answer

Managed identity (B) is the correct approach because it allows the Azure Function to authenticate to Azure Key Vault without storing any credentials in code or configuration. Azure automatically manages the identity, and the function can obtain an access token from Azure AD to read secrets, eliminating the need for secrets, certificates, or keys in the application.

Exam trap

The trap here is that candidates may confuse managed identity with a service principal, thinking a certificate or client secret is always required, but managed identity eliminates the need for any stored credentials by leveraging Azure's automatic identity management.

How to eliminate wrong answers

Option A is wrong because a service principal with a certificate still requires the certificate to be stored or deployed with the function code or configuration, which violates the requirement of not storing any credentials. Option C is wrong because an access policy with a client secret requires the client secret to be stored in the function's configuration or code, directly contradicting the no-credentials requirement. Option D is wrong because a shared access signature (SAS) is used for granting delegated access to Azure Storage resources, not for authenticating to Azure Key Vault, and it would still need to be stored in the function.

Practice this question →

103

MCQeasy

You have an Azure Function app that needs to retrieve a secret from Azure Key Vault at runtime. You want to avoid storing any credentials in code or configuration. Which mechanism should you use?

A.Service principal with client secret

B.Managed identity

C.Access key

D.Shared access signature (SAS)

AnswerB

Managed identities provide an automatically managed identity in Azure Active Directory for Azure services, including Function Apps. When enabled, the Function App can obtain an Azure AD token from the Azure Instance Metadata Service (IMDS) endpoint, which it then uses to authenticate to other Azure services like Azure Key Vault. This eliminates the need for developers to manage any credentials, as Azure handles the lifecycle of the identity and its authentication to Azure AD, making it the most secure and recommended approach for service-to-service authentication.

Why this answer

Managed identity (B) is the correct mechanism because it allows the Azure Function app to authenticate to Azure Key Vault without storing any credentials in code or configuration. Azure automatically manages the identity and provides a token from Azure AD that the function can use to access the vault, eliminating the need for secrets or keys in the application.

Exam trap

The trap here is that candidates may confuse managed identity with a service principal, thinking a client secret is required, or incorrectly assume that an access key or SAS can be used for Key Vault authentication.

How to eliminate wrong answers

Option A is wrong because a service principal with client secret requires storing the client secret in code or configuration, which violates the requirement to avoid storing credentials. Option C is wrong because an access key is used for authenticating to Azure Functions itself, not for retrieving secrets from Key Vault. Option D is wrong because a shared access signature (SAS) is a token for granting limited access to Azure Storage resources, not for authenticating to Key Vault.

Practice this question →

104

MCQhard

A single-page app signs in users with Microsoft Entra ID and calls a protected API. The app cannot safely keep a client secret. Which OAuth flow should be used? The team wants the control to be enforceable during normal operations.

A.Implicit flow

B.Client credentials flow

C.Resource owner password credentials flow

D.Authorization code flow with PKCE

AnswerD

Authorization code flow with PKCE replaces the client secret with a per-request code verifier and challenge, so a public single-page app can prove possession without storing credentials. Microsoft Entra ID supports and enforces PKCE for such public clients.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth flow for single-page apps because it prevents the client secret from being exposed by using a dynamically generated code verifier and challenge. This flow ensures that even if the authorization code is intercepted, it cannot be exchanged for tokens without the original code verifier, making it secure for public clients that cannot safely store secrets.

Exam trap

The trap here is that candidates often confuse the deprecated implicit flow (Option A) with the authorization code flow with PKCE, mistakenly thinking the implicit flow is still acceptable for SPAs, but Microsoft and OAuth standards now mandate PKCE for all public clients.

How to eliminate wrong answers

Option A is wrong because the implicit flow was deprecated by OAuth 2.0 Security Best Current Practice (BCP) due to security risks like access token leakage in the URL fragment and lack of token binding; it should not be used for new applications. Option B is wrong because the client credentials flow is designed for server-to-server (confidential client) scenarios where the app authenticates with its own credentials, not for user authentication in a single-page app. Option C is wrong because the resource owner password credentials flow requires the user to provide their username and password directly to the app, which violates security best practices and is not suitable for modern single-page apps that delegate authentication to Microsoft Entra ID.

Practice this question →

105

MCQmedium

You are developing an Azure Function that reads secrets from Azure Key Vault. The function must not use any static credentials in configuration files. You need to authenticate to Key Vault using the function's own identity. Which Azure service feature should you enable?

A.Use storage account access keys to authenticate to Key Vault

B.Assign a managed identity to the function app and grant it access to the Key Vault

C.Generate a shared access signature (SAS) token for the Key Vault

D.Create a service principal and store its certificate in the function app's local storage

AnswerB

Managed identities allow the function app to authenticate to Key Vault without any stored credentials. The identity is automatically managed by Microsoft Entra ID.

Why this answer

Azure Functions can use a system-assigned or user-assigned managed identity to authenticate to Azure Key Vault without storing any static credentials. When enabled, the function app obtains an Azure AD token from the Managed Identity endpoint (169.254.169.254) and uses it to access Key Vault secrets, eliminating the need for connection strings, keys, or certificates in configuration files.

Exam trap

The trap here is that candidates may confuse SAS tokens (which are for Storage) or service principals (which require manual certificate management) with the fully managed, credential-free authentication provided by managed identities.

How to eliminate wrong answers

Option A is wrong because storage account access keys are static credentials that must be stored in configuration files, violating the requirement to avoid static credentials, and they are used for Azure Storage, not for authenticating to Key Vault. Option C is wrong because shared access signature (SAS) tokens are used to delegate access to Azure Storage resources (blobs, queues, tables), not to authenticate to Key Vault; Key Vault uses Azure AD authentication or access policies, not SAS. Option D is wrong because creating a service principal and storing its certificate in the function app's local storage introduces a static credential (the certificate file) that must be managed and stored, contradicting the requirement to avoid static credentials; managed identities are the recommended approach for passwordless authentication.

Practice this question →

106

MCQhard

You are designing a solution for a healthcare application that stores patient data in Azure Cosmos DB. The data must be encrypted at rest using a customer-managed key stored in Azure Key Vault. You need to ensure that the key can be rotated without downtime. Which approach should you recommend?

A.Configure Azure Security Center to automatically rotate the key.

B.After rotating the key in Key Vault, manually update the Cosmos DB account with the new key version.

C.Use the Cosmos DB account key rotation feature to regenerate the key.

D.Enable automatic key rotation on the Key Vault key and use the key's versionless identifier in Cosmos DB.

AnswerD

Automatic rotation in Key Vault creates new key versions on schedule, and the versionless key identifier lets Cosmos DB always resolve the latest version, so rotation occurs without reconfiguration or downtime. Pinning a specific version would require manual updates.

Why this answer

Using a versionless key identifier in Azure Cosmos DB allows the service to automatically use the latest version of the customer-managed key stored in Azure Key Vault. When the key is rotated in Key Vault, Cosmos DB picks up the new version without any manual intervention, ensuring zero downtime and continuous encryption at rest.

Exam trap

The trap here is confusing Cosmos DB account key rotation (for authentication) with customer-managed key rotation (for encryption at rest), leading candidates to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because Azure Security Center (now Microsoft Defender for Cloud) does not provide automatic key rotation for customer-managed keys used with Cosmos DB; key rotation must be configured on the Key Vault key itself. Option B is wrong because manually updating the Cosmos DB account with a new key version after rotation introduces a window of potential downtime or misconfiguration, and it defeats the purpose of seamless rotation. Option C is wrong because the Cosmos DB account key rotation feature is for regenerating the primary/secondary read-write or read-only keys used for authentication, not for rotating the customer-managed encryption key stored in Key Vault.

Practice this question →

107

MCQmedium

You are developing an API that uses managed identity to access Azure Key Vault. The API runs in an Azure App Service with system-assigned managed identity enabled. You need to retrieve a secret value. Which API endpoint should your code call?

A.https://vault.azure.net/secrets/{secret-name}

B.https://myvault.vault.azure.net/secrets/{secret-name}?api-version=7.0

C.https://login.microsoftonline.com/{tenant}/oauth2/token

D.https://management.azure.com/subscriptions/{sub}/...

AnswerB

This URL correctly specifies the Azure Key Vault data plane endpoint for retrieving a secret. It includes the unique `vault-name` as a subdomain, followed by the standard `vault.azure.net` domain, and then the `/secrets/{secret-name}` path to target a specific secret. The `?api-version=7.0` query parameter is a crucial best practice for specifying the desired API version, ensuring compatibility and access to specific features.

Why this answer

It uses the full Key Vault REST API endpoint with the specific vault name ('myvault'), the 'secrets' resource path, the secret name, and the required 'api-version' query parameter (7.0). The managed identity in the App Service authenticates via Azure AD, and the code must call this specific endpoint to retrieve the secret value, as the vault name is part of the DNS name and the API version is mandatory.

Exam trap

The trap here is that candidates often confuse the Key Vault REST API endpoint with the Azure AD token endpoint or the Azure Resource Manager endpoint, forgetting that the vault name is part of the DNS and that an API version is required.

How to eliminate wrong answers

Option A is wrong because 'vault.azure.net' is not a valid Key Vault DNS name; the vault name must be included (e.g., 'myvault.vault.azure.net'). Option C is wrong because it is the Azure AD OAuth2 token endpoint, which is used to obtain an access token, not to directly retrieve a secret from Key Vault. Option D is wrong because it points to the Azure Resource Manager endpoint for subscription-level operations, not to the Key Vault secrets REST API.

Practice this question →

108

MCQmedium

You have an Azure App Service that uses a system-assigned managed identity. You need to grant it permission to read a secret from Azure Key Vault. Which RBAC role should you assign at the Key Vault scope?

A.Key Vault Reader

B.Key Vault Secrets User

C.Key Vault Contributor

D.Key Vault Certificate User

AnswerB

The Key Vault Secrets User role is specifically designed to grant data plane access for retrieving secrets. It provides permissions to perform actions like Microsoft.KeyVault/vaults/secrets/read and Microsoft.KeyVault/vaults/secrets/list, enabling the App Service to successfully fetch the actual secret values. This role adheres to the principle of least privilege by providing only the necessary permissions for secret retrieval without granting broader management capabilities.

Why this answer

The system-assigned managed identity needs to read a secret from Azure Key Vault. The 'Key Vault Secrets User' RBAC role grants exactly that permission — the ability to read secret contents. This is the least-privilege role that allows the 'Microsoft.KeyVault/vaults/secrets/read' action, which is required for reading secret values.

Exam trap

The trap here is that candidates often confuse 'Key Vault Reader' (a management-plane role) with the data-plane role needed to actually read secret values, or they over-provision by choosing 'Key Vault Contributor' thinking it includes read access.

How to eliminate wrong answers

Option A is wrong because 'Key Vault Reader' only allows listing vaults and reading metadata (e.g., vault properties, tags), but does not grant permission to read secret values. Option C is wrong because 'Key Vault Contributor' grants full management of the vault and its objects (including secrets, keys, certificates), which is excessive for a read-only secret access scenario and violates least-privilege principles. Option D is wrong because 'Key Vault Certificate User' only allows reading certificate contents and metadata, not secrets.

Practice this question →

109

MCQmedium

You have an Azure Storage account with a blob container. You need to grant a user read-only access to a specific blob for 24 hours without requiring them to authenticate with Microsoft Entra ID. What should you use?

A.Generate a user delegation SAS token

B.Provide the storage account access key

C.Assign the Storage Blob Data Reader role

D.Configure a stored access policy

AnswerA

Generating a user delegation SAS token is the most secure and recommended method for granting granular, time-limited access to Azure Blob Storage resources without exposing storage account keys. This type of SAS is signed using Azure Active Directory (Azure AD) credentials, allowing for precise control over permissions (e.g., read-only, write, list), the specific resources it applies to (container, blob), and its validity period. It integrates with Azure AD for auditing and adheres to the principle of least privilege.

Why this answer

A user delegation SAS token is the correct choice because it provides time-limited, delegated access to a specific blob using Microsoft Entra ID credentials without requiring the user to authenticate directly. The token is signed with the user's delegated key, granting read-only access for exactly 24 hours as specified, and it does not expose the storage account access key.

Exam trap

The trap here is that candidates often confuse a user delegation SAS with a stored access policy, thinking the policy alone grants access, or they incorrectly assume that assigning an RBAC role (Option C) can bypass authentication requirements, but RBAC always requires Entra ID authentication.

How to eliminate wrong answers

Option B is wrong because providing the storage account access key grants full administrative access to the entire storage account, not just read-only access to a specific blob, and it requires the user to manage a highly sensitive secret. Option C is wrong because assigning the Storage Blob Data Reader role requires the user to authenticate with Microsoft Entra ID, which contradicts the requirement of no authentication. Option D is wrong because a stored access policy defines constraints for SAS tokens but does not itself grant access; it must be combined with a SAS token, and it cannot eliminate the need for authentication.

Practice this question →

110

MCQmedium

Your company stores secrets in Azure Key Vault. You need to ensure that when a secret is disabled, it does not become accessible to applications that already have a cached copy. Which additional step must you take?

A.Rotate the secret immediately

B.Delete the secret

C.Enable soft-delete and purge protection

D.Use Key Vault access policies to deny access

AnswerA

Rotating a secret in Azure Key Vault creates a new version with an updated value, effectively marking the previous version as deprecated for general use. This action is crucial because applications are typically configured to retrieve the *latest* version of a secret. Upon their next scheduled refresh or explicit retrieval attempt, they will fetch the new value, thereby invalidating any previously cached copies of the older secret value and ensuring they operate with the most current credential. This directly addresses the need to force applications to use a new secret.

Why this answer

When a secret is disabled in Azure Key Vault, the vault itself will reject new access requests, but applications that have already retrieved and cached the secret can continue using it until the cache expires or is refreshed. To immediately invalidate the cached copy, you must rotate the secret (change its value) so that any subsequent attempt to use the old cached value fails because it no longer matches the secret stored in Key Vault. Disabling alone does not force applications to re-authenticate or re-fetch; rotation ensures the cached value becomes obsolete.

Exam trap

The trap here is that candidates assume disabling a secret immediately revokes all access, but they overlook the fact that applications may hold a cached copy that remains valid until the cache expires or the secret is rotated.

How to eliminate wrong answers

Option B is wrong because deleting the secret removes it permanently (or moves it to a soft-deleted state), but applications with a cached copy can still use the old value until they attempt to retrieve it again; deletion does not actively invalidate the cache. Option C is wrong because enabling soft-delete and purge protection only prevents accidental or malicious permanent deletion of secrets; it does not affect cached copies held by applications. Option D is wrong because Key Vault access policies control who can read or modify secrets, but they do not retroactively invalidate secrets already cached by authorized applications; once a secret is fetched, the cached copy remains usable regardless of policy changes.

Practice this question →

111

MCQmedium

A company uses Azure Blob Storage to store sensitive documents. They want to ensure that data is encrypted at rest using customer-managed keys (CMK) stored in Azure Key Vault. They also need to be able to revoke access to the data immediately if a security breach is detected. Which feature should they enable?

A.Configure Azure Storage encryption with customer-managed keys in Azure Key Vault and enable soft delete and purge protection.

B.Enable infrastructure encryption for the storage account.

C.Use Azure Storage Service Encryption with Microsoft-managed keys.

D.Implement client-side encryption using Azure Key Vault.

AnswerA

This option correctly addresses the requirement for customer-managed keys (CMK) by integrating Azure Storage encryption with Azure Key Vault. Using CMK provides granular control over the encryption keys, allowing customers to revoke access and render data immediately inaccessible, which is crucial for sensitive data. Enabling soft delete and purge protection on the Key Vault further enhances security by preventing accidental or malicious deletion of these critical encryption keys, ensuring data recoverability while maintaining key control.

Why this answer

It combines customer-managed keys (CMK) in Azure Key Vault for encryption at rest with soft delete and purge protection, which allows immediate revocation of access by deleting or disabling the key in Key Vault. This ensures that the data becomes permanently inaccessible as Azure Storage relies on the CMK to encrypt/decrypt the data, and without the key, the data cannot be decrypted.

Exam trap

The trap here is that candidates may think enabling infrastructure encryption (Option B) or using Microsoft-managed keys (Option C) provides the same revocation capability, but only customer-managed keys with soft delete and purge protection allow the customer to immediately and permanently revoke access by controlling the key in Key Vault.

How to eliminate wrong answers

Option B is wrong because infrastructure encryption provides an additional layer of encryption at the storage infrastructure level using platform-managed keys, but it does not use customer-managed keys nor does it enable immediate revocation of access. Option C is wrong because Azure Storage Service Encryption with Microsoft-managed keys does not allow the customer to control or revoke the encryption keys, so immediate revocation of access is not possible. Option D is wrong because client-side encryption encrypts data before it is sent to Azure Storage, but it does not provide a mechanism to revoke access to data already stored; revocation would require deleting or disabling the key used at the client side, which is not integrated with Azure Storage's access control.

Practice this question →

112

Multi-Selecthard

Which FOUR of the following are true regarding Microsoft Entra ID authentication for Azure Storage?

Select 4 answers

A.SAS tokens are not supported when using Microsoft Entra ID authentication.

B.RBAC roles can be used to grant permissions to a user or service principal.

C.When Microsoft Entra ID authentication is enabled, Shared Key authorization is still allowed by default.

D.Managed identities can authenticate to Azure Storage without storing credentials.

E.The authentication process uses OAuth 2.0 access tokens.

AnswersB, C, D, E

Azure RBAC roles assign storage data-plane permissions to a user or service principal through Microsoft Entra ID, satisfying the stem's requirement that Entra ID authentication governs access. Role assignments scope to subscription, resource group, storage account, or container, letting the same identity receive least-privilege access without sharing account keys.

Why this answer

Option B is correct because Azure Storage supports Azure RBAC roles such as Storage Blob Data Reader, Storage Blob Data Contributor, and Storage Blob Data Owner, which can be assigned to users, groups, service principals, or managed identities to grant data-plane permissions. Option C is correct because enabling Microsoft Entra ID authentication does not disable Shared Key authorization; unless the storage account is explicitly configured to disallow Shared Key access (for example, by setting AllowSharedKeyAccess to false), Shared Key remains enabled by default. Option D is correct because managed identities for Azure resources let applications authenticate to Azure Storage without storing credentials in code or configuration, since the identity is managed by the Microsoft Entra ID and Azure platform.

Option E is correct because Microsoft Entra ID authentication to Azure Storage uses OAuth 2.0 access tokens issued by Microsoft Entra ID, which are presented to the storage service to authorize data-plane requests. Option A is not correct because SAS tokens are still supported alongside Microsoft Entra ID authentication; SAS is a separate authorization mechanism, and user delegation SAS can even be secured with Microsoft Entra ID credentials.

Exam trap

Candidates may mistakenly think that enabling Microsoft Entra ID authentication automatically disables Shared Key authorization, but in fact Shared Key access remains enabled by default unless explicitly disabled via the 'AllowSharedKeyAccess' property.

Practice this question →

113

Multi-Selecthard

An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request? The team wants the control to be enforceable during normal operations.

Select 2 answers

A.Issuer and signature are valid for the trusted tenant

B.The user's display name is present

C.Token audience matches the API application ID URI or client ID

D.The token was sent in a query string

AnswersA, C

Validating the issuer confirms the token was minted by the trusted Microsoft Entra ID tenant, while signature verification proves the token is authentic and untampered. Together these prevent forged or foreign-tenant tokens from being accepted, satisfying the requirement for an enforceable control during normal API operations.

Why this answer

Option A is correct because the API must verify that the JWT was issued by the trusted Microsoft Entra ID tenant (checking the iss claim against the tenant's issuer URL) and that its signature validates against Entra ID's published signing keys, which prevents forged or tampered tokens. Option C is correct because the API must confirm the aud claim matches its own expected audience — the Application ID URI or client ID — so that a token issued for a different resource cannot be replayed against this API. Option B is not a security control: a display name claim is optional, user-controlled in some flows, and does not prove the token's validity or intended recipient.

Option D is incorrect because tokens should be sent in the Authorization header as a Bearer token, not in a query string, which would expose them in logs and URLs and is not a validation property.

Exam trap

The trap here is that candidates may think validating the user's display name (Option B) is necessary for authorization, but token validation is about verifying the token's authenticity and intended audience, not user attributes.

Practice this question →

114

MCQmedium

You are developing a microservices application. Each microservice must authenticate to Azure SQL Database using its own identity. You need to minimize credential management overhead. What should you use?

A.System-assigned managed identities

B.User-assigned managed identities

C.Certificate-based authentication

D.Service principals with client secrets

AnswerA

System-assigned managed identities are automatically created and deleted with the Azure resource (e.g., an App Service, Azure Function, or AKS pod). They provide a unique identity for each specific microservice instance, enabling fine-grained access control to other Azure services without requiring developers to manage credentials. This approach simplifies the security posture by eliminating the need for manual secret rotation and ensuring identity isolation per service, aligning perfectly with microservice principles.

Why this answer

System-assigned managed identities enable each microservice to authenticate to Azure SQL Database without storing credentials in code or configuration. Azure automatically rotates the identity's service principal certificate and handles token acquisition via the Azure Instance Metadata Service (IMDS) endpoint, eliminating manual credential management. This is the simplest approach when each microservice has a one-to-one relationship with its Azure resource (e.g., App Service or Azure Function).

Exam trap

The trap here is that candidates often choose user-assigned managed identities thinking they offer more control, but the question specifically asks to minimize credential management overhead, and system-assigned identities are fully automated with zero manual setup beyond enabling the flag.

How to eliminate wrong answers

Option B is wrong because user-assigned managed identities require explicit assignment to each microservice resource and introduce additional management overhead for creating and maintaining the identity object, which contradicts the goal of minimizing credential management. Option C is wrong because certificate-based authentication requires manual certificate provisioning, renewal, and secure storage, adding significant operational burden compared to the fully managed token lifecycle of managed identities. Option D is wrong because service principals with client secrets require storing and rotating secrets in code, configuration, or a key vault, which increases credential management overhead and security risk.

Practice this question →

115

MCQmedium

You are developing a serverless application using Azure Functions that processes sensitive data. The function needs to access Azure Key Vault to retrieve a secret. You want to use managed identity for authentication. What should you do first?

A.Enable the system-assigned managed identity on the function app and grant it the Key Vault Secrets User role.

B.Enable the system-assigned managed identity on the Key Vault.

C.Store the client ID and client secret of a service principal in the function app settings.

D.Create a user-assigned managed identity and assign it to the Key Vault.

AnswerA

Enabling a system-assigned managed identity on the Azure Function App automatically provisions a unique identity in Azure Active Directory, intrinsically linked to the function's lifecycle. Granting this identity the 'Key Vault Secrets User' role provides the necessary Azure Role-Based Access Control (RBAC) permissions for the function to securely retrieve secrets from Key Vault. This robust pattern eliminates the need for developers to manage credentials in code or configuration, significantly enhancing security and simplifying secret rotation.

Why this answer

To use managed identity for authentication with Azure Key Vault, the first step is to enable a system-assigned managed identity on the function app, which creates an identity in Azure AD tied to the resource. Then, you must grant that identity the appropriate role (e.g., Key Vault Secrets User) on the Key Vault to authorize secret retrieval. This eliminates the need for storing credentials in code or configuration.

Exam trap

The trap here is that candidates often confuse which resource gets the managed identity (the function app) versus where permissions are assigned (the Key Vault), leading them to incorrectly enable the identity on the Key Vault itself.

How to eliminate wrong answers

Option B is wrong because managed identity is enabled on the Azure resource (the function app), not on the Key Vault itself; Key Vault uses access policies or RBAC roles to grant permissions to identities. Option C is wrong because it describes using a service principal with client ID and secret, which contradicts the requirement to use managed identity and introduces credential management overhead. Option D is wrong because a user-assigned managed identity is created separately and assigned to the function app, not to the Key Vault; the identity must be assigned to the resource that needs to authenticate, and then granted permissions on the Key Vault.

Practice this question →

116

MCQmedium

You have an Azure App Service web app that uses a system-assigned managed identity. The web app needs to authenticate to an Azure SQL Database to read and write data. You want to use the managed identity to avoid storing credentials in connection strings. Which steps are required to configure this access?

A.Assign the managed identity the 'SQL DB Contributor' RBAC role on the database, then use SQL authentication with the identity's client ID.

B.Create a contained database user in the SQL database mapped to the managed identity, grant required database roles, and use Microsoft Entra ID token-based authentication from the app.

C.Enable Microsoft Entra ID authentication on the SQL server, add the managed identity as an Microsoft Entra ID admin, and use integrated security in the connection string.

D.Configure the connection string with the managed identity's principal ID as the user ID and leave the password empty.

AnswerB

This is the correct procedure. The managed identity (an Microsoft Entra ID principal) must be added as a database user. The app then acquires an access token for Azure SQL Database using the managed identity and uses it to connect.

Why this answer

To use a system-assigned managed identity with Azure SQL Database, you must create a contained database user mapped to the managed identity in the SQL database, grant it the necessary database roles (e.g., db_datareader, db_datawriter), and then acquire an access token for Microsoft Entra ID (formerly Azure AD) from the managed identity endpoint to authenticate. This token-based approach avoids storing credentials and leverages the managed identity's automatic credential rotation.

Exam trap

The trap here is that candidates confuse Azure RBAC roles (which manage control-plane access) with SQL database-level permissions (which manage data-plane access), leading them to incorrectly select Option A or C instead of understanding that a contained database user and token-based authentication are required.

How to eliminate wrong answers

Option A is wrong because 'SQL DB Contributor' is an Azure RBAC role that controls management-plane operations (e.g., creating databases), not data-plane access to read/write data; SQL authentication with the identity's client ID is not supported—managed identities use token-based authentication, not SQL authentication. Option C is wrong because adding the managed identity as an Entra ID admin grants server-level administrative privileges, which is overly permissive and not the recommended least-privilege approach; 'integrated security' is a Windows Authentication concept and does not apply to managed identities in Azure App Service. Option D is wrong because connection strings cannot use the managed identity's principal ID as a user ID with an empty password; managed identity authentication requires acquiring a token from the Azure Instance Metadata Service (IMDS) endpoint and passing it as a password in the connection string or using a token-based library like Microsoft.Data.SqlClient.

Practice this question →

117

MCQeasy

Your application uses Azure Key Vault to store secrets. You need to ensure that the application can access secrets without storing any credentials in the application code or configuration files. What should you use?

A.Azure Managed Identity

B.Key Vault access policies

C.A connection string with the secret

D.A client certificate stored in the application

AnswerA

Azure Managed Identity gives the application a Microsoft Entra ID service principal whose credentials Azure manages and rotates automatically, so no secret is stored in code or configuration. Assigning it Key Vault access via RBAC or access policy satisfies the credential-free requirement directly.

Why this answer

Azure Managed Identity provides an automatically managed identity in Microsoft Entra ID for the application to authenticate to Azure Key Vault without any credentials in code or configuration. The application requests a token from the managed identity endpoint, and Key Vault validates that token against its access policy or RBAC role assignment. This eliminates secret storage entirely for the authentication step.

Exam trap

AZ-204 often tests credential-free authentication — candidates pick 'access policies' or 'client certificate' because they sound secure, missing that only managed identity removes credentials from code and configuration entirely.

How to eliminate wrong answers

Option B is wrong because Key Vault access policies define what an identity can do once authenticated — they do not provide the authentication mechanism itself, so credentials would still be needed. Option C is wrong because a connection string containing the secret is exactly the anti-pattern the question asks to avoid — it stores credentials in configuration. Option D is wrong because a client certificate stored in the application is still a credential that must be protected and rotated, defeating the goal of credential-free authentication.

Practice this question →

118

MCQmedium

Refer to the exhibit. You deploy this ARM template to an App Service named 'myapp'. After deployment, users report they are able to access the app without being prompted to log in. What is the most likely reason?

A.The Azure Active Directory registration is missing the client secret.

B.The redirect URI is not configured in the Azure AD app registration.

C.The issuer URL is incorrect; it should include the tenant ID.

D.The client ID is from a different tenant.

AnswerA

Azure App Service's Easy Auth, when configured with Azure AD, operates as a confidential client. This means it needs to securely authenticate itself to Azure AD to exchange authorization codes for access tokens and refresh tokens. A client secret (or certificate) serves as this credential, and its absence prevents the App Service from establishing a trusted connection and completing the OAuth 2.0 authorization code flow, leading to authentication failures because the identity provider cannot verify the client's identity.

Why this answer

The ARM template configures the `identityProviders` section with Azure Active Directory settings, but without a `clientSecret` property. The EasyAuth middleware requires a valid client secret to complete the OAuth 2.0 authorization code flow; without it, the authentication provider is effectively disabled, allowing unauthenticated access.

Exam trap

The trap here is that candidates assume a missing client secret causes a deployment error or a login failure, but Azure App Service silently disables the identity provider when the secret is absent, allowing unauthenticated access.

How to eliminate wrong answers

Option B is wrong because the redirect URI is automatically generated by App Service when using EasyAuth, and its absence in the app registration does not cause unauthenticated access—it would cause a redirect mismatch error only when authentication is enforced. Option C is wrong because the issuer URL in the template uses the `issuer` property with a placeholder `{tenantid}`, which App Service resolves to the correct tenant ID at runtime; an incorrect issuer URL would cause token validation failures, not silent unauthenticated access. Option D is wrong because if the client ID were from a different tenant, the authentication flow would fail with a tenant mismatch error, but the app would still prompt for login; it would not allow unauthenticated access.

Practice this question →

119

MCQhard

You have a multi-tenant application that uses Azure AD (Microsoft Entra ID) for authentication. You want to allow only specific tenants to access your app. What is the recommended approach?

A.In the application code, validate the 'tid' claim against a list of allowed tenant IDs.

B.Configure the app manifest to require user assignment and assign users from allowed tenants.

C.Validate the 'iss' claim to ensure it matches one of your allowed tenant issuer URLs.

D.Use Azure AD tenant restrictions to block all tenants except the allowed ones.

AnswerA

For multi-tenant applications, the 'tid' (tenant ID) claim in the incoming JWT token explicitly identifies the Azure AD tenant that issued the token. By implementing a server-side validation check, the application can compare this 'tid' against a pre-defined whitelist of authorized tenant IDs. This programmatic approach ensures that only users from approved organizational tenants can access the application, effectively enforcing tenant-level isolation and security policies directly within the application's trust boundary.

Why this answer

The 'tid' claim in the Azure AD-issued token uniquely identifies the tenant. By validating this claim against a hardcoded list of allowed tenant IDs in your application code, you can enforce multi-tenant access control without relying on Azure AD tenant-level restrictions or issuer URL validation, which can be less precise.

Exam trap

The trap here is that candidates often confuse the 'iss' claim (issuer) with the 'tid' claim (tenant ID), assuming issuer validation is sufficient, but the 'iss' claim can be less predictable in multi-tenant scenarios, especially when using the 'common' or 'organizations' endpoints, whereas 'tid' is the precise and recommended claim for tenant filtering.

How to eliminate wrong answers

Option B is wrong because requiring user assignment and assigning users from allowed tenants is designed for single-tenant or line-of-business apps, not for multi-tenant scenarios where you want to allow entire tenants without pre-provisioning individual users. Option C is wrong because the 'iss' claim (issuer) for Azure AD tokens is typically 'https://login.microsoftonline.com/{tenantid}/v2.0' and can vary by tenant type (e.g., common, organizations, consumers), making it unreliable for tenant-level filtering; the 'tid' claim is the standard and recommended claim for tenant identification. Option D is wrong because Azure AD tenant restrictions are a network-level policy enforced at the proxy or firewall level (e.g., via HTTP headers) to control access to all Azure AD-integrated apps, not a per-application code-level control, and they require infrastructure changes that are not the recommended approach for a single app.

Practice this question →

120

MCQmedium

You are developing a serverless function using Azure Functions that needs to write logs to a Log Analytics workspace. The function uses a managed identity. Which RBAC role should you assign to the function's managed identity?

A.Log Analytics Reader

B.Monitoring Contributor

C.Log Analytics Contributor

D.Storage Blob Data Contributor

AnswerC

The Log Analytics Contributor role provides comprehensive permissions to manage and write data to a Log Analytics workspace. This role includes the crucial `Microsoft.OperationalInsights/workspaces/write` and `Microsoft.OperationalInsights/workspaces/tables/write` actions, enabling an Azure Function to ingest its operational logs, custom metrics, and other telemetry directly into the workspace for analysis and visualization. This role is specifically tailored for scenarios requiring data ingestion into Log Analytics, aligning with the principle of least privilege.

Why this answer

The Log Analytics Contributor role is required because it grants the managed identity the necessary permissions to send data to a Log Analytics workspace, including the ability to create and manage data collection rules and write log data. This role is specifically designed for scenarios where an Azure resource, such as an Azure Function, needs to ingest logs into Log Analytics via the Data Collection API.

Exam trap

The trap here is that candidates often confuse the Log Analytics Contributor role with the Monitoring Contributor role, mistakenly thinking the latter covers log ingestion, but Monitoring Contributor lacks the specific write permissions to the Log Analytics workspace data plane.

How to eliminate wrong answers

Option A is wrong because Log Analytics Reader only allows read access to log data and monitoring settings, not the ability to write logs. Option B is wrong because Monitoring Contributor provides broader permissions to manage monitoring resources (e.g., alert rules, metrics) but does not include the specific permission to write data to a Log Analytics workspace. Option D is wrong because Storage Blob Data Contributor is for managing blob storage data, not for writing logs to Log Analytics.

Practice this question →

121

MCQhard

You are developing an ASP.NET Core web API that authenticates users via Microsoft Entra ID. The application needs to authorize access to resources based on custom roles (e.g., 'Admin', 'Editor') that are not present in Microsoft Entra ID. The role mappings are dynamic and stored in an application database. How should you implement authorization?

A.Define the roles as Microsoft Entra ID app roles and include them in the token claims.

B.Store the role mappings in an Azure SQL Database and use a custom authorization policy that queries the database after authentication.

C.Include the roles as claims in the Microsoft Entra ID token by using a custom claim mapping policy.

D.Store the role mappings in the web.config file and read them at runtime.

AnswerB

This is the most flexible and scalable solution for dynamic role management. After a user is authenticated by Microsoft Entra ID, a custom authorization handler, part of an ASP.NET Core policy, can query the Azure SQL Database to retrieve the user's current role assignments. This approach ensures that authorization decisions are always based on the most up-to-date role data from the database, without requiring token re-issuance or application manifest changes for role updates.

Why this answer

The custom roles are dynamic and stored in an application database, not in Microsoft Entra ID. After authentication, a custom authorization policy can query the database to retrieve the role mappings for the authenticated user and enforce access control. This approach decouples role management from the identity provider and supports dynamic role assignments.

Exam trap

The trap here is that candidates assume custom roles must be embedded in the token via claims, overlooking that dynamic roles from a database can be evaluated post-authentication using a custom authorization policy.

How to eliminate wrong answers

Option A is wrong because defining roles as Microsoft Entra ID app roles requires static role definitions in the app registration, which cannot be dynamically updated from an external database. Option C is wrong because a custom claim mapping policy in Microsoft Entra ID can only add claims based on directory attributes or static rules, not from an external database. Option D is wrong because storing role mappings in web.config is static, insecure, and not suitable for dynamic role management; it also violates the principle of externalizing configuration from code.

Practice this question →

122

MCQeasy

You are developing a .NET console application that runs on a developer workstation and also in an Azure Container Instance. The application must read secrets from Azure Key Vault. During local development, the developer signs in with the Azure CLI. In Azure, the container uses a managed identity. You want a single code path that works in both environments without storing credentials. Which approach should you use?

A.Instantiate SecretClient with a ClientSecretCredential using a client secret from an environment variable.

B.Instantiate SecretClient with a ManagedIdentityCredential and rely on it working on the developer workstation.

C.Instantiate SecretClient with a DefaultAzureCredential and pass the Key Vault URI.

D.Instantiate SecretClient with an InteractiveBrowserCredential so the developer and the container can both prompt for sign-in.

AnswerC

DefaultAzureCredential chains multiple credential sources. On a workstation it picks up the Azure CLI sign-in, and in Azure Container Instances it uses the managed identity. This gives one code path that works in both environments without embedding secrets, exactly matching the requirement to avoid stored credentials in code or configuration.

Why this answer

DefaultAzureCredential is designed for code that must run in multiple environments. It tries developer tooling credentials first and falls back to managed identity in Azure, so the same SecretClient code works locally and in the container without any stored secret.

Exam trap

The trap here is choosing a credential type that only works in one environment, such as managed identity locally or interactive sign-in in a headless container.

Practice this question →

123

Multi-Selecthard

Which TWO actions should you take to secure an Azure Kubernetes Service (AKS) cluster that runs a critical workload? (Choose two.)

Select 2 answers

A.Store secrets as Kubernetes secrets without encryption

B.Enable SSH access to all nodes for troubleshooting

C.Enable Azure AD integration with Kubernetes RBAC

D.Deploy Azure Firewall in the cluster VNet

E.Use network policies to restrict pod-to-pod communication

AnswersC, E

Enabling Azure Active Directory (Azure AD) integration with Kubernetes Role-Based Access Control (RBAC) is a fundamental security measure for AKS, providing robust identity-based access control. This integration allows organizations to leverage their existing Azure AD identities and groups to define granular permissions within the Kubernetes cluster. It centralizes authentication and authorization, ensuring that only authorized users and service principals can perform specific actions, thereby enforcing the principle of least privilege.

Why this answer

Integrating Azure AD with Kubernetes RBAC provides centralized identity management and fine-grained access control for the AKS cluster. This allows you to authenticate users via Azure AD and authorize their actions using Kubernetes RBAC roles, ensuring that only authenticated and authorized users can perform operations on the cluster, which is critical for securing a production workload.

Exam trap

The trap here is that candidates often confuse network-level security (like Azure Firewall) with pod-level security (like network policies), or they mistakenly think that enabling SSH access is a valid troubleshooting method in AKS, ignoring the principle of least privilege and the availability of secure alternatives like `kubectl exec` or Azure Bastion.

Practice this question →

124

MCQeasy

You need to ensure that an Azure Functions app can access a blob in Azure Storage using its system-assigned managed identity. What should you do first?

A.Configure CORS on the storage account

B.Enable the managed identity in the Function App

C.Assign the Storage Blob Data Reader role to the managed identity at the storage account scope

D.Generate a SAS token for the blob

AnswerB

Enabling a managed identity for an Azure Function App is a crucial first step, as it provisions a unique identity (a service principal) for the application within Azure Active Directory. However, this action alone only *creates* the identity; it does not automatically grant it any permissions to interact with other Azure resources. Without explicit authorization through role assignments, the newly created managed identity lacks the necessary privileges to perform operations like reading data from a storage account.

Why this answer

To use a system-assigned managed identity, it must first be enabled on the Azure Functions app. This action creates the identity in Azure Active Directory. Once the identity is enabled, you can then assign the necessary Azure RBAC role, such as 'Storage Blob Data Reader', to this identity at the storage account scope to grant it permissions to access the blob storage.

Therefore, enabling the managed identity is the foundational first step.

Exam trap

The trap here is that candidates might focus on the authorization step (RBAC role assignment) and overlook the prerequisite step of actually enabling the managed identity on the resource itself, which must happen first for the identity to exist and be assignable.

How to eliminate wrong answers

Option A is wrong because CORS (Cross-Origin Resource Sharing) is a browser security feature that controls which origins can make requests to the storage account from client-side code; it does not grant the Function App's managed identity any permissions to access blobs. Option B is wrong because while enabling the managed identity is a prerequisite, it alone does not grant any access to the storage account; the identity must be assigned an RBAC role to actually read blobs. Option D is wrong because generating a SAS token bypasses managed identity entirely and introduces key-based access, which contradicts the requirement to use the system-assigned managed identity.

Practice this question →

125

MCQhard

A company is building a microservices application on Azure Container Instances. Each microservice needs to authenticate to Azure Key Vault to retrieve secrets. They want to avoid storing any credentials in the container images or environment variables. What should they do?

A.Use Docker secrets mounted as volumes.

B.Enable managed identity for the container group and grant it access to Key Vault.

C.Use a shared access signature (SAS) token to access Key Vault.

D.Store the Key Vault URI and a client secret in environment variables.

AnswerB

Enabling a managed identity for the Azure Container Instances (ACI) container group provisions an automatically managed identity within Azure Active Directory (Azure AD). This identity can then be granted specific role-based access control (RBAC) permissions to an Azure Key Vault, allowing the containerized application to securely retrieve secrets, keys, or certificates. This method eliminates the need for hardcoded credentials, connection strings, or client secrets within the application code or environment variables, significantly enhancing security by preventing credential exposure and simplifying credential rotation.

Why this answer

Azure Container Instances supports managed identities, allowing the container group to authenticate to Azure Key Vault without any credentials stored in the image or environment variables. By enabling a system-assigned or user-assigned managed identity on the container group and granting that identity the appropriate Key Vault access policy (e.g., 'Get' secret permission), the application can acquire an Azure AD token from the Instance Metadata Service (IMDS) endpoint and use it to retrieve secrets securely.

Exam trap

The trap here is that candidates may confuse Docker secrets (which still require credential injection at runtime) with Azure managed identities (which eliminate the need for any stored credentials), or they may incorrectly think SAS tokens can be used for Key Vault authentication, when SAS tokens are strictly for Azure Storage.

How to eliminate wrong answers

Option A is wrong because Docker secrets mounted as volumes still require the secrets to be stored in the container image or passed at runtime, which contradicts the requirement to avoid storing any credentials in the container images or environment variables. Option C is wrong because a shared access signature (SAS) token is used for delegating access to Azure Storage resources, not for authenticating to Azure Key Vault; Key Vault uses Azure AD authentication and access policies. Option D is wrong because storing the Key Vault URI and a client secret in environment variables directly violates the requirement to avoid storing credentials in environment variables, and it introduces a security risk by exposing the client secret.

Practice this question →

126

Multi-Selecthard

You are developing a daemon application that runs on an on-premises server and must call a protected web API hosted in Azure. The API is secured with Microsoft Entra ID. The daemon cannot use a user sign-in and must authenticate as itself. You need to choose the appropriate authentication flow and configuration. Which two actions should you perform? (Choose two.)

Select 2 answers

A.Use the OAuth 2.0 client credentials flow.

B.Use the OAuth 2.0 authorization code flow with PKCE.

C.Configure the application registration with a client secret or certificate.

D.Grant delegated permissions to the API and request them at runtime.

E.Use the OAuth 2.0 implicit grant flow to obtain tokens directly.

AnswersA, C

The client credentials flow is designed for non-interactive, app-only authentication where the application authenticates as itself using its own credentials. It allows the daemon to obtain a token from Microsoft Entra ID without a user context. This is the correct flow for a daemon calling a protected API with application permissions.

Why this answer

A daemon with no user context must use the OAuth 2.0 client credentials flow, which authenticates the application itself. This flow requires a credential such as a client secret or certificate configured in the app registration. Together, these two actions allow the daemon to obtain an access token from Microsoft Entra ID and call the protected API using application permissions.

Exam trap

The trap here is mixing up interactive flows like authorization code with PKCE or implicit grant with app-only flows, when a daemon without a user must use client credentials.

Practice this question →

127

MCQeasy

The team is writing an Azure Function that needs to retrieve secrets from Azure Key Vault at runtime. The security policy prohibits storing client secrets, connection strings, or certificates in application settings or source code. What is the recommended approach?

A.Enable a system-assigned managed identity on the Function App and grant it Key Vault Secrets User (or Get/List access policy) permission on the vault

B.Create an App Registration, generate a client secret, store the secret in an Application Setting, and authenticate using ClientSecretCredential

C.Generate a Key Vault SAS token and embed it in the function's connection string setting

D.Use the Key Vault REST API with the vault's access key embedded in the code

AnswerA

The managed identity removes all credential management from the developer. DefaultAzureCredential automatically detects the managed identity context and requests tokens from the Azure Instance Metadata Service. No secret is ever stored anywhere the developer can access or accidentally expose.

Why this answer

A system-assigned managed identity provides a secure, credential-free way for an Azure Function to authenticate to Key Vault. Azure automatically manages the identity's lifecycle and tokens, eliminating the need to store any secrets in application settings or code. The Function App uses the managed identity to obtain an Azure AD token, which it presents to Key Vault to retrieve secrets, fully complying with the security policy.

Exam trap

The trap here is that candidates may think a client secret or SAS token is acceptable if stored in an Application Setting, but the policy explicitly prohibits storing any secrets in settings or code, making managed identity the only compliant option.

How to eliminate wrong answers

Option B is wrong because it requires storing a client secret (the App Registration's secret) in an Application Setting, which directly violates the security policy that prohibits storing client secrets in application settings or source code. Option C is wrong because Key Vault does not support SAS tokens; SAS tokens are used for Azure Storage, not Key Vault, and embedding any token in a connection string violates the policy. Option D is wrong because Key Vault does not have an 'access key'; it uses Azure AD authentication, and embedding any credential in code violates the policy.

Practice this question →

128

MCQhard

Your application runs on Azure Kubernetes Service (AKS). It needs to access Azure Key Vault secrets. You want to avoid using a service principal. Which solution should you implement?

A.Mount secrets as a ConfigMap from Key Vault

B.Create a service principal and assign it to the AKS cluster

C.Deploy the Secrets Store CSI Driver with workload identity

D.Use a Helm chart to inject secrets

AnswerC

Deploying the Secrets Store CSI Driver with Azure Workload Identity is the recommended and most secure approach for AKS pods to access secrets stored in Azure Key Vault. This solution allows pods to authenticate to Azure Key Vault using an Azure Active Directory managed identity, eliminating the need for any Kubernetes Secrets or service principal credentials. The driver then projects the secrets directly into the pod's filesystem as a mounted volume, ensuring they are never exposed as environment variables or stored insecurely within Kubernetes.

Why this answer

The Secrets Store CSI Driver with workload identity allows your AKS pods to securely access Azure Key Vault secrets without managing a separate service principal. Workload identity uses Azure AD pod-managed identities or federated identity credentials to authenticate directly to Key Vault, eliminating the need for explicit service principal credentials.

Exam trap

The trap here is that candidates may confuse Helm charts or ConfigMaps as valid secret injection methods, overlooking that they lack native secure integration with Azure Key Vault and still require explicit authentication credentials.

How to eliminate wrong answers

Option A is wrong because mounting secrets as a ConfigMap from Key Vault is not a native AKS feature; ConfigMaps are designed for non-sensitive data and storing secrets in a ConfigMap would expose them in plaintext, defeating security. Option B is wrong because the question explicitly states you want to avoid using a service principal, and creating one directly contradicts that requirement. Option D is wrong because Helm charts are a packaging and deployment tool, not a mechanism for secure secret injection; they would still require a service principal or other authentication method to access Key Vault.

Practice this question →

129

MCQmedium

A developer is implementing least-privilege storage access. The application runs on Azure App Service and must avoid stored credentials. Which design should be used? The design must avoid adding custom operational scripts.

A.Use a shared administrator account

B.Disable authentication for the target resource

C.Store a client secret in source control

D.Enable managed identity and grant least-privilege access to the target resource

AnswerD

Enabling managed identity for an Azure-hosted application provides an automatically managed identity in Azure Active Directory (Azure AD), allowing the application to authenticate to Azure services securely without needing to store or manage any credentials in code or configuration. By then granting only the necessary, least-privilege access to the target resource via Azure RBAC, the application adheres to security best practices, minimizing the attack surface and simplifying credential management.

Why this answer

Azure Managed Identity provides an automatically managed identity in Azure AD that allows the App Service to authenticate to any service supporting Azure AD authentication without storing any credentials. By granting the managed identity only the specific permissions required (least-privilege) on the target storage resource (e.g., Storage Blob Data Reader), the application avoids stored credentials and eliminates the need for custom operational scripts. This aligns with the principle of zero standing credentials and is the recommended approach for Azure App Service.

Exam trap

The trap here is that candidates may think storing a client secret in source control (Option C) is acceptable if the repository is private, but the question explicitly requires avoiding stored credentials, and any secret in source control is a security risk that violates the principle of credentialless access.

How to eliminate wrong answers

Option A is wrong because using a shared administrator account violates least-privilege (grants excessive permissions) and requires storing credentials, which contradicts the requirement to avoid stored credentials. Option B is wrong because disabling authentication for the target resource removes all access control, exposing the resource to unauthorized access and violating security best practices. Option C is wrong because storing a client secret in source control introduces a security risk (credential leak) and requires managing a secret, which does not avoid stored credentials and adds operational overhead.

Practice this question →

130

MCQmedium

Your company uses Azure Key Vault to manage encryption keys for data at rest in Azure Storage. You need to ensure that the storage account uses a customer-managed key (CMK) stored in Key Vault. Additionally, you need to periodically rotate the key automatically. Which configuration should you implement?

A.Create a key in Key Vault, assign the storage account's managed identity access to that key, and configure a Key Vault rotation policy to automatically rotate the key regularly

B.Enable soft-delete and purge protection on the Key Vault to allow key recovery during rotation

C.Use Azure Key Vault's default key (system-managed) and rely on built-in rotation

D.Manually rotate the key every 90 days by generating a new version and updating the storage account

AnswerA

This option correctly outlines the steps for implementing customer-managed keys with automatic rotation. Creating a key in Key Vault establishes customer ownership, while assigning the storage account's managed identity provides secure, credential-less access to the key. Crucially, configuring a Key Vault key rotation policy automates the generation of new key versions according to a defined schedule, ensuring compliance with the 'automatically rotate' requirement without manual intervention.

Why this answer

It combines the three essential elements for using a customer-managed key (CMK) with automatic rotation in Azure Key Vault. First, you must create a key in Key Vault (not use the default system-managed key). Second, the storage account's managed identity must be granted 'Get', 'Unwrap Key', and 'Wrap Key' permissions on that key so it can encrypt/decrypt the storage account's root key.

Third, you configure a Key Vault rotation policy (using the Azure Key Vault key rotation feature) to automatically create new key versions on a schedule (e.g., every 90 days), which the storage account automatically picks up without manual intervention.

Exam trap

The trap here is that candidates often confuse enabling soft-delete/purge protection (which is required for CMK but does not enable rotation) with the actual rotation policy configuration, or they assume that system-managed keys can be used when the question explicitly requires a customer-managed key.

How to eliminate wrong answers

Option B is wrong because soft-delete and purge protection are prerequisites for Key Vault (especially when using CMK with Azure Storage) but they do not enable automatic rotation; they only protect against accidental or malicious key deletion. Option C is wrong because Azure Key Vault's default key is a system-managed key (Microsoft-managed), not a customer-managed key; the question explicitly requires a CMK, and system-managed keys cannot be rotated on a custom schedule. Option D is wrong because manual rotation every 90 days does not meet the requirement for automatic rotation; it also introduces operational overhead and risk of human error, and the storage account must be updated each time a new key version is created.

Practice this question →

131

MCQmedium

You are developing an ASP.NET Core web API that is hosted on Azure App Service. The API needs to read secrets from Azure Key Vault at startup. You want to avoid storing any credentials in the application code or configuration. Which approach should you use?

A.Use the Key Vault SDK with a client ID and client secret stored in App Service application settings.

B.Enable the system-assigned managed identity for the App Service and configure Key Vault access policies to allow that identity.

C.Use Microsoft Entra ID application roles to assign the App Service a role that allows reading secrets.

D.Store the Key Vault URL and a connection string with the secret in the application's app.config file.

AnswerB

System-assigned managed identity lets App Service authenticate to Key Vault without any stored secret, satisfying the no-credentials constraint. Microsoft Entra ID issues the token automatically, and a Key Vault access policy grants that identity secret read permissions, so the API retrieves secrets at startup credential-free.

Why this answer

Enabling a system-assigned managed identity for the App Service allows it to authenticate to Azure Key Vault without any credentials stored in code or configuration. The managed identity is automatically managed by Azure AD (now Microsoft Entra ID) and can be granted access to Key Vault secrets via access policies, eliminating the need for client IDs, client secrets, or connection strings.

Exam trap

The trap here is that candidates often think storing credentials in App Service application settings is acceptable because they are 'not in code,' but the question explicitly requires avoiding any stored credentials, making managed identity the only secure, credential-free approach.

How to eliminate wrong answers

Option A is wrong because storing a client ID and client secret in App Service application settings still requires credentials in configuration, violating the requirement to avoid storing any credentials. Option C is wrong because Microsoft Entra ID application roles are used for application-level permissions and RBAC, not for granting an App Service identity direct access to Key Vault secrets; Key Vault uses access policies or RBAC roles like 'Key Vault Secrets User' for managed identities. Option D is wrong because storing the Key Vault URL and a connection string with the secret in app.config places credentials in the application code/configuration, directly contradicting the requirement.

Practice this question →

132

MCQhard

Refer to the exhibit. An administrator runs this Azure CLI command. What is the result?

A.Assigns the Contributor role to a service principal at the resource group scope

B.Assigns a managed identity to the resource group

C.Assigns the Reader role to a user at the subscription scope

D.Assigns the Reader role to a service principal at the resource group scope

AnswerD

The `az role assignment create` command, when used with an assignee identifier (like a service principal's object ID), correctly targets a service principal, which is an identity used by applications or services. The `--role "Reader"` parameter accurately specifies that read-only access is being granted. Furthermore, the `--resource-group "myResourceGroup"` parameter correctly sets the scope of this access to a specific resource group, precisely matching the command's intended functionality.

Why this answer

The Azure CLI command `az role assignment create --assignee <object-id> --role Reader --resource-group <rg-name>` assigns the Reader role to a service principal (identified by its object ID) at the specified resource group scope. The Reader role grants read-only access to resources within that resource group, which matches the command's parameters and the expected outcome.

Exam trap

The trap here is that candidates may confuse the `--assignee` parameter with a user principal name (UPN) or fail to recognize that the object ID in the command refers to a service principal, leading them to incorrectly select Option C (user at subscription scope) or Option A (Contributor role).

How to eliminate wrong answers

Option A is wrong because the command specifies the `--role Reader` parameter, not `Contributor`, so it does not assign the Contributor role. Option B is wrong because the command uses `az role assignment create` to assign a role to a principal, not to assign a managed identity to a resource group (which would require different commands like `az vm identity assign` or `az identity create`). Option C is wrong because the command includes `--resource-group` to scope the assignment to a resource group, not to the subscription level (which would omit the `--resource-group` parameter).

Practice this question →

133

MCQmedium

External partners are given Shared Access Signatures to upload product images to a specific Blob Storage container named 'images'. A partner reports accidentally uploading files to the 'contracts' container, which should not be accessible. What is the most likely configuration mistake?

A.The SAS was generated at the storage account level, granting write access that applies to multiple containers rather than being scoped to the 'images' container only

B.The SAS expiry time is too long, giving partners time to discover and access other containers

C.The partner used a storage account key instead of the provided SAS token

D.The SAS was signed with a stored access policy that did not name the correct container

AnswerA

An account SAS with sr=c (container) permission and no container restriction grants access to all containers. A container SAS is generated with a specific container name in the signed resource URI (e.g., https://account.blob.core.windows.net/images?sig=...), making it impossible for the holder to use the SAS against any other container.

Why this answer

A SAS generated at the storage account level grants permissions across all containers within that account. When the SAS URI includes only the account endpoint (e.g., https://<account>.blob.core.windows.net/) and a set of permissions (like write), the token can be used to access any container, including 'contracts'. To restrict access to a single container, the SAS must be scoped to the container resource URI (e.g., https://<account>.blob.core.windows.net/images) and the signed resource type must be 'c' (container) or 'b' (blob), not 's' (service).

Exam trap

The trap here is that candidates often confuse the scope of a SAS (account-level vs. resource-level) with other SAS properties like expiry time or stored access policies, leading them to incorrectly attribute the security breach to token lifetime or policy misconfiguration rather than the fundamental lack of resource-level scoping.

How to eliminate wrong answers

Option B is wrong because a long expiry time does not enable access to other containers; it only extends the window of validity for the token, but the token's scope (which containers it can access) is determined by the resource URI and signed resource type, not the expiry. Option C is wrong because using a storage account key would grant full administrative access to the entire storage account, not just the 'images' container, but the scenario states the partner was given a SAS token, so using the key would be a different authentication method, not a configuration mistake by the developer. Option D is wrong because a stored access policy defines permissions and expiry for a specific container; if the policy did not name the correct container, the SAS would be invalid or scoped to a different container, but it would not grant access to the 'contracts' container unless the policy itself was misconfigured to allow access to multiple containers, which is not the typical behavior of a stored access policy.

Practice this question →

134

MCQeasy

You are deploying a web app on Azure App Service that stores secrets in Azure Key Vault. The app uses managed identity to access Key Vault. During testing, you get a 403 Forbidden error when the app tries to read a secret. What is the most likely cause?

A.The managed identity is not assigned to the app.

B.The Key Vault has soft-delete enabled.

C.The Key Vault access policy does not grant the managed identity the 'Get' permission for secrets.

D.The Key Vault firewall is set to allow only selected networks.

AnswerC

When an Azure App Service app, authenticated via a managed identity, attempts to retrieve a secret from Key Vault, the Key Vault's access policy is consulted for authorization. If the managed identity is not explicitly granted the 'Get' permission for secrets within that Key Vault's access policy, the request will be denied. This specific denial of a permitted action, despite successful authentication, directly results in an HTTP 403 Forbidden status code.

Why this answer

The 403 Forbidden error indicates that the request was authenticated but not authorized. Since the app uses managed identity to access Key Vault, the most likely cause is that the Key Vault access policy does not grant the managed identity the 'Get' permission for secrets. Without this specific permission, the identity can authenticate but cannot retrieve secret values, resulting in a 403 response.

Exam trap

The trap here is that candidates confuse authentication (401) with authorization (403) and may incorrectly assume the managed identity is not assigned (Option A) when the actual issue is a missing access policy permission (Option C).

How to eliminate wrong answers

Option A is wrong because if the managed identity were not assigned to the app, the error would typically be a 401 Unauthorized (authentication failure), not a 403 Forbidden (authorization failure). Option B is wrong because soft-delete is a data protection feature that allows recovery of deleted vaults and objects; it does not affect access permissions or cause a 403 error during secret retrieval. Option D is wrong because if the Key Vault firewall were blocking the request, the error would be a 403 but with a network-related message (e.g., 'Access denied due to IP restrictions'), and the app's outbound IP would need to be explicitly allowed; however, the most common and direct cause for a 403 when using managed identity is a missing access policy permission.

Practice this question →

135

MCQeasy

You are deploying a sensitive application on Azure Kubernetes Service (AKS). You need to ensure that secrets, such as database connection strings, are encrypted at rest and in transit, and that the cluster has no static credentials. Which feature should you enable?

A.Enable etcd encryption at rest

B.Enable Azure Disk Encryption on the node pools

C.Assign a managed identity to the AKS cluster

D.Use Azure Key Vault Provider for Secrets Store CSI Driver

AnswerD

The Azure Key Vault Provider for Secrets Store CSI Driver allows Kubernetes pods to retrieve secrets, keys, and certificates directly from Azure Key Vault and mount them as a volume within the pod's filesystem. This approach ensures that sensitive data is never persisted within the AKS cluster's etcd or as native Kubernetes Secret objects. Instead, secrets are fetched on demand and presented to the application through a secure, ephemeral file system, significantly reducing the risk of secret exposure within the cluster and enhancing overall security posture.

Why this answer

The Azure Key Vault Provider for Secrets Store CSI Driver integrates with AKS to securely fetch secrets from Azure Key Vault, encrypting them at rest (Key Vault uses AES-256) and in transit (TLS 1.2+). It eliminates static credentials by using a managed identity or service principal to authenticate to Key Vault, ensuring no secrets are stored on disk or in etcd.

Exam trap

The trap here is that candidates often confuse encryption at rest (e.g., etcd encryption or disk encryption) with the broader requirement of eliminating static credentials and securing secrets in transit, leading them to pick A or B instead of the integrated solution D.

How to eliminate wrong answers

Option A is wrong because enabling etcd encryption at rest only protects secrets stored in etcd (the Kubernetes backing store) but does not address secrets in transit or eliminate static credentials; it also does not integrate with an external secrets store like Key Vault. Option B is wrong because Azure Disk Encryption on node pools encrypts the OS and data disks at rest using BitLocker or DM-Crypt, but it does not protect secrets in transit, nor does it remove static credentials from the cluster. Option C is wrong because assigning a managed identity to the AKS cluster provides authentication for Azure resources but does not by itself encrypt secrets at rest or in transit, nor does it prevent static credentials from being stored in the cluster.

Practice this question →

136

Multi-Selectmedium

Which TWO of the following are valid ways to authenticate an Azure function to an Azure SQL database using managed identity?

Select 2 answers

A.Create a service principal and assign it to the function app.

B.Use the function app's default connection string with a username and password.

C.Create a user-assigned managed identity, assign it to the function app, and use its client ID in the connection string.

D.Upload a client certificate to the function app and use it to authenticate.

E.Enable system-assigned managed identity on the function app and set the SQL connection string with 'Authentication=Active Directory Managed Identity'.

AnswersC, E

A user-assigned managed identity is an independent Azure resource that can be explicitly created and then assigned to one or more Azure resources, including a Function App. Once assigned, the Function App can leverage this identity to obtain Azure AD tokens, which are then used to authenticate to other Azure services like Azure SQL Database. Including the client ID of the user-assigned managed identity in the connection string explicitly directs the Function App to use that specific identity for authentication, enabling a secure and credential-free connection.

Why this answer

A user-assigned managed identity can be created, assigned to the function app, and then used in the SQL connection string by specifying the client ID (e.g., 'User ID=<client_id>;Authentication=Active Directory Managed Identity;'). This allows the function to authenticate to Azure SQL without storing credentials. Option E is also correct because enabling a system-assigned managed identity and setting the connection string with 'Authentication=Active Directory Managed Identity' lets the function app authenticate using its own identity, which is automatically managed by Azure.

Exam trap

The trap here is that candidates often confuse service principals (Option A) with managed identities, or think that certificate-based authentication (Option D) is a form of managed identity, when in fact managed identities are specifically Azure AD identities tied to the resource itself without manual credential or certificate management.

Practice this question →

137

MCQeasy

Refer to the exhibit. You run the Azure CLI command to store a secret in Key Vault. Later, you run 'az keyvault secret show --vault-name myvault --name MySecret'. What will be displayed?

A.The secret's metadata only, without the value.

B.The secret's metadata with the value masked as '*****'.

C.The secret's metadata and the value 'P@ssw0rd123'.

D.An error because you cannot retrieve a secret after it is set.

AnswerC

The `az keyvault secret show` command correctly retrieves the full secret object, encompassing both its comprehensive metadata and the actual plaintext value, 'P@ssw0rd123'. This functionality is fundamental for applications and administrators needing to access the secret's content for operational purposes. The command's output provides all necessary details, including the secret's attributes and its sensitive value, as intended for authorized retrieval.

Why this answer

The `az keyvault secret show` command retrieves the secret's metadata along with its value in plaintext. When you store a secret using `az keyvault secret set`, the value is stored securely, and the `show` command returns the full secret object, including the `value` field, as demonstrated in the exhibit where the stored value is 'P@ssw0rd123'.

Exam trap

The trap here is that candidates may confuse the Azure CLI's `show` command with the Azure Portal's secret display, which masks the value by default, leading them to incorrectly assume the CLI also masks the output.

How to eliminate wrong answers

Option A is wrong because `az keyvault secret show` returns both metadata and the secret value, not just metadata. Option B is wrong because the Azure CLI does not mask the secret value with asterisks; it returns the actual value in plaintext (though the output may be truncated in the console, the full value is accessible). Option D is wrong because there is no restriction on retrieving a secret after it is set; the `show` command is specifically designed for retrieval, and secrets remain accessible until deleted or their expiration date passes.

Practice this question →

138

MCQhard

You are reviewing an ARM template that deploys a network security group (NSG) for a web application. The exhibit shows the security rules. The web application runs on port 443. You need to ensure that HTTPS traffic from the internet can reach the web servers. What is the issue with the current configuration?

A.The SSH rule is allowing SSH from the internet, which is a security risk.

B.The SSH rule should have a higher priority (lower number) to ensure SSH access.

C.The DenyAll rule should have a lower priority (higher number) to allow more specific rules.

D.There is no rule to allow HTTPS traffic (port 443) from the internet.

AnswerD

For an application to be accessible via HTTPS from the internet, a specific Network Security Group rule must exist that explicitly permits inbound traffic on destination port 443 (HTTPS) from a source of 'Internet' or `*`. Without such an explicit 'Allow' rule, any incoming HTTPS requests will inevitably be blocked by the implicit 'DenyAllInbound' rule or an explicit, higher-priority 'DenyAll' rule. This omission prevents critical web traffic from reaching the application, highlighting a significant functional gap.

Why this answer

The ARM template's security rules do not include an inbound rule that allows HTTPS traffic (TCP port 443) from the internet. Without such a rule, the default DenyAll inbound rule will block all HTTPS requests, preventing the web application from being accessible over the internet. NSG rules are evaluated in priority order, and if no explicit allow rule exists for port 443, traffic is denied.

Exam trap

The trap here is that candidates may focus on the SSH rule's security implications or priority ordering, overlooking the fundamental absence of an HTTPS allow rule, which is the direct cause of the web application being unreachable.

How to eliminate wrong answers

Option A is wrong because while allowing SSH from the internet is indeed a security risk, the question specifically asks about ensuring HTTPS traffic reaches the web servers, not about SSH security. Option B is wrong because the SSH rule's priority is irrelevant to the HTTPS issue; the problem is the absence of an HTTPS allow rule, not the priority of the SSH rule. Option C is wrong because the DenyAll rule already has the lowest priority (highest number) by convention, and lowering its priority further would not create an allow rule for HTTPS; the core issue is the missing allow rule for port 443.

Practice this question →

139

MCQhard

A developer accidentally deleted a secret from Azure Key Vault. Soft-delete is enabled with a retention period of 90 days. After 60 days, you attempt to recover the secret. What should you do?

A.Run the Azure CLI command: az keyvault secret recover

B.Enable purge protection on the Key Vault first, then recover the secret.

C.Recover is not possible because the retention period of 90 days has not elapsed.

D.Run the Azure CLI command: az keyvault secret undelete

AnswerA

Azure Key Vault's soft-delete feature automatically retains deleted secrets for a configurable period, typically 90 days. During this retention window, the secret transitions to a soft-deleted state, not permanently removed from the Key Vault. The `az keyvault secret recover` command is specifically designed to restore a soft-deleted secret to an active state, making it accessible again, provided the retention period has not yet expired. This command directly addresses the scenario of an accidentally deleted secret.

Why this answer

When soft-delete is enabled on Azure Key Vault, deleted secrets are retained for the specified retention period (90 days in this case). Since only 60 days have passed, the secret is still in a soft-deleted state and can be recovered using the `az keyvault secret recover` command, which restores the secret to an active state.

Exam trap

The trap here is that candidates may confuse the retention period with a mandatory waiting period before recovery, or mistakenly think that purge protection must be enabled first, when in fact recovery is available immediately after deletion as long as soft-delete is enabled.

How to eliminate wrong answers

Option B is wrong because purge protection is not required to recover a soft-deleted secret; it only prevents permanent deletion before the retention period ends. Option C is wrong because the retention period defines the maximum time the secret is kept before being purged, not a waiting period before recovery; recovery is possible at any point during the retention period. Option D is wrong because `az keyvault secret undelete` is not a valid Azure CLI command; the correct command is `az keyvault secret recover`.

Practice this question →

140

MCQhard

A financial services company uses Azure Container Instances (ACI) to run batch processing jobs. Each job processes sensitive financial data and must use a custom container image stored in Azure Container Registry (ACR). The security requirements are: the ACI container must authenticate to ACR using a managed identity, the container must run as a non-root user, and all secrets must be injected via environment variables from Azure Key Vault using the managed identity. The ACI instance must also be deployed into a virtual network (VNet) to restrict network access. What configuration should you use?

A.Create a system-assigned managed identity for ACI, assign AcrPull role to the identity, and grant it Key Vault access. Deploy ACI with VNet integration.

B.Create a user-assigned managed identity, assign it to both ACI and ACR (with AcrPull role), grant it Key Vault access, and deploy ACI with the identity and VNet integration.

C.Enable ACR admin account, use admin credentials in ACI, and store secrets in Key Vault with a system-assigned managed identity for ACI.

D.Create a service principal, assign AcrPull role and Key Vault access, store the service principal secret in Key Vault, and configure ACI to use the service principal.

AnswerB

Correct. A user-assigned managed identity provides a persistent identity that can be pre-created, assigned to the ACI container group, and granted AcrPull on ACR and appropriate permissions on Key Vault. This fulfills all security requirements: managed identity authentication to ACR, non-root execution (configured separately), secret injection from Key Vault, and VNet integration.

Why this answer

Using a user-assigned managed identity provides a persistent identity that can be assigned to both Azure Container Instances (ACI) and granted access to Azure Container Registry (ACR) and Azure Key Vault. This satisfies all security requirements: authentication to ACR via managed identity, non-root user execution (configured separately), and secret injection from Key Vault. VNet integration restricts network access.

Option A is incorrect because a system-assigned managed identity is tied to the ACI lifecycle and cannot be shared across resources; while you can assign permissions to that identity on ACR, it does not provide the same level of control and persistence as a user-assigned identity. Option C is incorrect because using admin credentials for ACR is not secure and defeats the purpose of managed identities. Option D is incorrect because a service principal requires managing credentials, introducing security risks and additional overhead.

Practice this question →

141

MCQhard

A company uses Azure SQL Database and needs to encrypt sensitive columns (e.g., credit card numbers) at rest and in transit, with the ability to allow specific applications to decrypt. They want to manage encryption keys centrally in Azure Key Vault and avoid managing certificates. Which technology should they use?

A.Always Encrypted with column master key in Azure Key Vault.

B.Transparent Data Encryption (TDE) with Azure Key Vault.

C.Dynamic Data Masking (DDM) with Azure Key Vault.

D.Row-Level Security (RLS) with Azure Key Vault.

AnswerA

Always Encrypted is a client-side encryption technology designed to protect sensitive data, ensuring it is encrypted before leaving the client application and remains encrypted while stored in the database. It uses column encryption keys, protected by a column master key stored securely in Azure Key Vault, to encrypt specific database columns. This approach ensures that sensitive data is never exposed in plaintext to the SQL Database engine or privileged users like database administrators, only being decrypted by authorized client applications.

Why this answer

Always Encrypted with a column master key stored in Azure Key Vault is the correct choice because it encrypts sensitive columns (like credit card numbers) at rest and in transit, ensuring data remains encrypted throughout the entire pipeline, including during query processing. The column master key in Azure Key Vault allows centralized key management without handling certificates, and only applications with access to the corresponding column encryption key can decrypt the data, meeting the requirement for application-specific decryption.

Exam trap

The trap here is that candidates confuse Transparent Data Encryption (TDE) with column-level encryption, assuming TDE's integration with Azure Key Vault provides the same granular control and in-transit protection as Always Encrypted, but TDE only protects data at rest and does not support client-side decryption control.

How to eliminate wrong answers

Option B (TDE with Azure Key Vault) is wrong because TDE encrypts the entire database at rest but does not protect data in transit or allow column-level granularity; it also does not enable application-specific decryption control. Option C (Dynamic Data Masking with Azure Key Vault) is wrong because DDM only obfuscates data at query results for unauthorized users, does not encrypt data at rest or in transit, and does not use Azure Key Vault for key management. Option D (Row-Level Security with Azure Key Vault) is wrong because RLS restricts row access based on user predicates but does not encrypt data or protect it in transit, and it does not involve Azure Key Vault for key management.

Practice this question →

142

Multi-Selectmedium

Which THREE of the following are valid ways to authenticate an Azure Function to an Azure SQL Database using managed identities?

Select 3 answers

A.Enable system-assigned managed identity on the function app and grant it access to the SQL database.

B.Assign the managed identity directly to the Azure SQL Database logical server.

C.Use the managed identity's principal ID to create a contained database user in SQL Database.

D.Create a user-assigned managed identity, assign it to the function app, and grant it access to the SQL database.

E.Create a service principal and assign it to the function app.

AnswersA, C, D

This is a valid and recommended approach. A system-assigned managed identity is automatically created and managed by Azure for a specific resource (the Function App in this case). Once enabled, this identity can be granted permissions directly to the Azure SQL Database, allowing the Function App to authenticate without needing connection strings with credentials. This eliminates the need for developers to manage secrets.

Why this answer

Option A is correct because enabling a system-assigned managed identity on the function app creates an identity in Microsoft Entra ID tied to that app, which can then be granted access to Azure SQL Database (for example, by adding it as a contained database user with the appropriate role). Option C is correct because after the managed identity exists, you must create a contained database user in the target SQL Database mapped to that identity's principal ID or name (e.g., CREATE USER [name] FROM EXTERNAL PROVIDER) and grant it the needed permissions, which is the actual authentication/authorization step. Option D is correct because a user-assigned managed identity can be created and attached to the function app, and that identity can likewise be granted access to the SQL database, providing the same managed-identity authentication path.

Option B is not valid because managed identities are assigned to Azure resources such as the function app, not to the Azure SQL logical server itself. Option E is not valid because a service principal is a separate Microsoft Entra ID application credential, not a managed identity, and assigning a service principal to a function app is not how managed-identity authentication to Azure SQL works.

Exam trap

The trap here is that candidates often confuse assigning a managed identity to a resource (like a function app) with assigning it to the database server itself, or they think a service principal is a type of managed identity, when in fact managed identities are a specific Azure feature distinct from service principals.

Practice this question →

143

MCQmedium

A retail company uses Azure Logic Apps to integrate with third-party APIs. One Logic App sends purchase orders to a supplier's HTTP endpoint. The supplier requires that the request include an OAuth 2.0 access token obtained from their authorization server. The company wants to manage the client credentials (client ID and client secret) securely and rotate them automatically. The Logic App must also log all requests for auditing. What should you do?

A.Use the built-in HTTP action with a system-assigned managed identity and request a token from the supplier's authorization server using the managed identity.

B.Use the built-in HTTP action in the Logic App, store the client secret in Azure Key Vault, and retrieve it using the Key Vault connector. Then request a token from the supplier's authorization server.

C.Use the 'Managed API' connector for the supplier, configure it with client ID and secret in the connection parameters, and enable 'Azure AD Integration' on the Logic App.

D.Use the 'HTTP + Swagger' connector, define the OAuth2 security scheme, store the client secret in Key Vault, and configure the Logic App to use a system-assigned managed identity to access Key Vault.

AnswerD

The 'HTTP + Swagger' connector, also known as a Custom Connector, is the correct choice as it allows defining the API's structure and security, including OAuth 2.0, through an OpenAPI (Swagger) definition. By specifying the OAuth2 security scheme, the connector automatically handles the token acquisition and refresh process, abstracting this complexity from the Logic App workflow. Storing the client secret in Azure Key Vault, accessed securely via a system-assigned managed identity, ensures robust credential management, compliance, and facilitates secret rotation without code changes.

Why this answer

It combines the HTTP + Swagger connector to define the OAuth2 security scheme inline, stores the client secret in Azure Key Vault for secure management and automatic rotation, and uses a system-assigned managed identity to access Key Vault without hardcoding credentials. This approach ensures the Logic App can securely retrieve the client secret, request an OAuth 2.0 token from the supplier's authorization server, and log all HTTP requests via the connector's built-in logging capabilities.

Exam trap

The trap here is that candidates often assume a managed identity can be used to authenticate to any OAuth 2.0 endpoint, but managed identities are limited to Azure AD tokens; for external OAuth 2.0 servers, you must use the client credentials flow with securely stored secrets.

How to eliminate wrong answers

Option A is wrong because a system-assigned managed identity cannot be used to request a token from an external third-party OAuth 2.0 authorization server; managed identities only work with Azure AD to obtain tokens for Azure resources. Option B is wrong because while it stores the client secret in Key Vault, the built-in HTTP action does not natively support OAuth 2.0 token acquisition or automatic token refresh; you would need custom logic to handle the token request and refresh, and the Key Vault connector introduces additional latency and complexity. Option C is wrong because there is no generic 'Managed API' connector for arbitrary third-party suppliers; managed API connectors are pre-built by Microsoft for specific services, and enabling 'Azure AD Integration' on the Logic App does not help with external OAuth 2.0 flows.

Practice this question →

144

MCQeasy

You are developing an ASP.NET Core web app that will be deployed to Azure App Service. The app needs to authenticate users from a Microsoft Entra ID tenant. You want to minimize development effort and rely on platform features. What should you do?

A.Implement custom OAuth 2.0 middleware in the app.

B.Add Microsoft.Identity.Web NuGet package and configure it in Startup.cs to use Microsoft Entra ID.

C.Use Microsoft Entra ID App Roles and add role checks in the code.

D.Enable App Service Authentication in the Azure portal and configure Microsoft Entra ID as the identity provider.

AnswerD

Enabling App Service Authentication, often referred to as EasyAuth, in the Azure portal provides a fully managed authentication solution that operates at the gateway level, external to the application code. By configuring Microsoft Entra ID as the identity provider, Azure App Service handles the entire authentication flow, including redirecting unauthenticated requests, validating tokens, and injecting user claims into HTTP headers. This approach requires no modifications to the application's codebase, significantly simplifying development and deployment.

Why this answer

Enabling App Service Authentication (also known as EasyAuth) in the Azure portal allows you to configure Microsoft Entra ID as the identity provider with minimal code changes. This approach leverages the platform's built-in authentication layer, which automatically handles token validation, session management, and redirects, thereby reducing development effort and relying on Azure's managed features.

Exam trap

The trap here is that candidates often overestimate the need for code-based solutions (like Microsoft.Identity.Web) and underestimate the power of Azure's built-in App Service Authentication, which can handle the entire authentication flow with zero code changes in the app.

How to eliminate wrong answers

Option A is wrong because implementing custom OAuth 2.0 middleware requires significant manual code for token validation, redirect handling, and session management, which contradicts the goal of minimizing development effort and relying on platform features. Option B is wrong because while Microsoft.Identity.Web simplifies integration with Microsoft Entra ID, it still requires adding NuGet packages, configuring middleware in Startup.cs, and managing authentication logic in code, which is more effort than using the built-in App Service Authentication feature. Option C is wrong because using App Roles and adding role checks in code addresses authorization (what a user can do) but does not handle authentication (verifying who the user is); it assumes authentication is already in place and adds unnecessary code complexity for the stated goal.

Practice this question →

145

MCQmedium

You are developing a web app that authenticates users via Microsoft Entra ID. The app needs to access the Microsoft Graph API to read user profiles. Which type of permission should you request in the app registration to ensure the app can read profiles without user interaction?

A.Delegated permissions

B.Resource-based permissions

C.Consent permissions

D.Application permissions

AnswerD

Application permissions allow an application to access data and perform actions as its own identity, without a signed-in user. This model is essential for background services, daemon applications, or web apps that need to operate autonomously, such as processing data nightly or integrating with other services. These permissions typically require administrator consent because the application acts with its own high-privilege identity, affecting all users within the tenant.

Why this answer

Application permissions are required for daemon or service-type applications that need to access Microsoft Graph API without a signed-in user. Unlike delegated permissions, which operate on behalf of a user, application permissions allow the app to authenticate as itself using the client credentials OAuth 2.0 flow, enabling read of user profiles without any user interaction.

Exam trap

The trap here is that candidates confuse delegated permissions (which require a user) with application permissions (which do not), especially when the scenario mentions 'read user profiles' without explicitly stating the app runs as a background service or daemon.

How to eliminate wrong answers

Option A is wrong because delegated permissions require a signed-in user and cannot operate in a non-interactive context; they are intended for apps that act on behalf of a user. Option B is wrong because resource-based permissions are not a standard permission type in Microsoft Entra ID app registrations; they refer to permissions assigned directly to a resource (e.g., Azure RBAC) and are not used for Graph API access. Option C is wrong because 'consent permissions' is not a valid permission type; consent is an action (granting approval) that applies to either delegated or application permissions, not a distinct category.

Practice this question →

146

MCQhard

You are deploying a containerized application to Azure Kubernetes Service (AKS). The application needs to access Azure SQL Database securely. Which approach should you use to avoid storing credentials in the container image?

A.Store the connection string in a Kubernetes Secret and mount it as an environment variable

B.Use Azure AD Pod Identity (Workload Identity) to assign a managed identity to the pod and authenticate to SQL

C.Use a service principal and store its credentials in Azure Key Vault, then use the Key Vault Secrets Store CSI driver

D.Hardcode the credentials in the Dockerfile

AnswerB

Azure AD Workload Identity (formerly Pod Identity) is the most secure and recommended approach for AKS pods to authenticate to Azure services like SQL Database. It assigns an Azure Active Directory managed identity directly to a Kubernetes service account, which is then associated with the pod. The pod can then obtain an Azure AD access token by exchanging its Kubernetes service account token with Azure AD, allowing it to authenticate to Azure SQL Database without needing any stored credentials, connection strings, or client secrets within the pod or Kubernetes Secrets. This significantly reduces the attack surface and simplifies credential management.

Why this answer

Azure AD Pod Identity (now evolved into Workload Identity) allows you to assign a managed identity to a pod, which can then authenticate to Azure SQL Database without any credentials stored in the image or environment variables. This approach uses Azure AD tokens obtained via the pod's identity, eliminating the need for connection strings or secrets in the container.

Exam trap

The trap here is that candidates often choose Option A (Kubernetes Secret) because it seems like a standard Kubernetes pattern, but they overlook that the question specifically requires avoiding any credential storage in the image or environment, which a Secret still represents.

How to eliminate wrong answers

Option A is wrong because storing the connection string in a Kubernetes Secret and mounting it as an environment variable still exposes the credential in the cluster's etcd and to any pod with access to the secret, violating the 'no credentials in the image' goal. Option C is wrong because while it avoids storing credentials in the image, it introduces unnecessary complexity and still relies on a service principal secret stored in Key Vault, which must be retrieved at runtime; the question specifically asks to avoid storing credentials, and a managed identity (Option B) is the simpler, more secure approach. Option D is wrong because hardcoding credentials in the Dockerfile is a fundamental security anti-pattern that embeds secrets directly in the image, making them accessible to anyone who can pull the image.

Practice this question →

147

Multi-Selecthard

An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request? The architecture review board prefers a managed Azure-native control.

Select 2 answers

A.Issuer and signature are valid for the trusted tenant

B.The user's display name is present

C.Token audience matches the API application ID URI or client ID

D.The token was sent in a query string

AnswersA, C

Validating the issuer confirms the token came from the trusted Microsoft Entra ID tenant, and verifying the signature proves it was not tampered with. Together these establish authenticity before the API accepts the request, using Azure-native token validation.

Why this answer

Option A is correct because the API must verify that the JWT was issued by the trusted Microsoft Entra ID tenant (the iss claim matches the tenant's issuer, e.g., https://login.microsoftonline.com/{tenantid}/v2.0) and that its signature validates against Entra ID's published signing keys, ensuring the token is authentic and untampered. Option C is correct because the API must confirm the aud claim matches its own application ID URI or client ID, which prevents tokens issued for a different resource from being replayed against this API. Option B is not required for security validation — a display name is optional and not a reliable authorization check.

Option D is incorrect and insecure: tokens should be sent in the Authorization header as a Bearer token, never in a query string, which would expose them in logs and URLs.

Exam trap

The trap here is that candidates confuse 'claims that are present in the token' (like display name) with 'claims that must be validated for security' (issuer, audience, signature), leading them to select non-essential claims as validation requirements.

Practice this question →

148

Drag & Dropmedium

Arrange the steps to implement Azure Key Vault for storing and retrieving secrets in an application in the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence for implementing Azure Key Vault is: first create the Key Vault, then add the secret, grant access to the secret (e.g., via access policies or RBAC), retrieve the secret in the application, and finally use it. This ensures proper resource creation and security before accessing sensitive data.

Practice this question →

149

MCQeasy

Your company stores customer payment data in an Azure SQL Database. You need to ensure that only the application's managed identity can access the database, and no SQL logins or passwords are used. Which authentication method should you configure?

A.SQL Server authentication with a strong password stored in Key Vault

B.Use Microsoft Entra ID authentication with the managed identity configured as a contained database user

C.Enable Transparent Data Encryption (TDE) and use the database's certificate

D.Configure the Azure SQL firewall to allow only the application's outbound IP

AnswerB

This is the correct approach because it leverages Microsoft Entra ID authentication, allowing an Azure service, like an application running on an App Service or VM, to authenticate to Azure SQL Database using its assigned managed identity. The managed identity is then configured as a contained database user within the Azure SQL database, granting it specific permissions without requiring any passwords or connection strings containing secrets. This eliminates credential management overhead and significantly enhances security by removing secret exposure risks.

Why this answer

Configuring the managed identity as a contained database user in Azure SQL Database using Microsoft Entra ID authentication allows the application to authenticate without any SQL logins or passwords. The managed identity provides an automatically managed service principal in Entra ID, which can be mapped to a contained database user (CREATE USER [<identity-name>] FROM EXTERNAL PROVIDER). This enables token-based authentication using OAuth 2.0, ensuring that only the application's identity can access the database.

Exam trap

The trap here is that candidates often confuse network-level security (firewall rules) or data encryption (TDE) with authentication, failing to recognize that only Entra ID authentication with a managed identity eliminates the need for SQL logins and passwords entirely.

How to eliminate wrong answers

Option A is wrong because SQL Server authentication with a password stored in Key Vault still requires a SQL login and password, violating the requirement of 'no SQL logins or passwords.' Option C is wrong because Transparent Data Encryption (TDE) only encrypts data at rest and does not provide authentication or access control; it cannot replace the need for an identity-based authentication method. Option D is wrong because configuring the Azure SQL firewall to allow only the application's outbound IP does not authenticate the application; it only restricts network access by IP address, and the application would still need a SQL login or password to connect.

Practice this question →

150

Matchingmedium

Match each Azure compute service to its execution model.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

IaaS with full OS control

PaaS for web and API apps

Serverless event-driven compute

Managed job scheduling for parallel workloads

Why these pairings

Azure compute services offer different execution models: Azure Functions (serverless, event-driven), Azure Logic Apps (serverless workflow), Azure Kubernetes Service (container orchestration). Common confusions involve associating serverless with containers or PaaS with orchestration.

Practice this question →