Knowledge + Practice

CCNA Implement Azure security Questions

75 of 157 questions · Page 1/3 · Implement Azure security · Answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

You are deploying an Azure Kubernetes Service (AKS) cluster. You need to ensure that pods can access Azure resources (e.g., Azure Storage) using a managed identity without storing credentials. What should you configure?

A.Use Azure AD Workload Identity for Kubernetes (or aad-pod-identity) to assign managed identities to pods.

B.Configure Azure AD integration on the AKS cluster for user authentication.

C.Create a service principal and distribute its secret to pods as a Kubernetes secret.

D.Enable managed identity on the AKS cluster and use cluster-level identity.

AnswerA

Azure AD Workload Identity for Kubernetes leverages Kubernetes service accounts and OpenID Connect (OIDC) federation. It allows pods to authenticate to Azure services using a user-assigned managed identity without embedding any secrets or connection strings directly into the pod configuration. This method significantly enhances security by eliminating the need for manual secret rotation and reducing the risk of credential exposure, aligning with the principle of least privilege.

Why this answer

Azure AD Workload Identity (or the older aad-pod-identity) allows you to assign an Azure managed identity to a pod. The pod can then authenticate to Azure resources (e.g., Azure Storage) without storing any credentials, as the identity is projected into the pod via token exchange with the Azure Instance Metadata Service (IMDS). This directly meets the requirement of using a managed identity without credential storage.

Exam trap

The trap here is that candidates confuse cluster-level managed identity (used for AKS infrastructure operations) with pod-level managed identity (used for pod-to-Azure resource access), leading them to select Option D.

How to eliminate wrong answers

Option B is wrong because Azure AD integration on the AKS cluster is used for user authentication to the cluster (e.g., kubectl access), not for pod-level identity to access Azure resources. Option C is wrong because creating a service principal and distributing its secret as a Kubernetes secret violates the requirement of 'without storing credentials' and introduces security risks of secret leakage. Option D is wrong because enabling managed identity on the AKS cluster provides a cluster-level identity for the cluster itself (e.g., for load balancer or disk operations), not for individual pods to access Azure resources like Storage.

Practice this question →

2

MCQmedium

A company stores sensitive data in Azure Blob Storage. They require that all access to the storage account be authenticated via Microsoft Entra ID and that users must have the 'Storage Blob Data Reader' role assigned. A developer reports being unable to read blobs using the Azure portal despite having the role assigned. What is the most likely cause?

A.The storage account firewall is blocking the user's IP address.

B.The user does not have the Azure RBAC Reader role on the storage account's resource group to view the storage account in the portal.

C.The storage account is using a system-assigned managed identity for authentication.

D.The role is assigned at the storage account scope but the user is trying to access a different storage account.

AnswerB

The Azure portal interacts with the Azure Resource Manager (ARM) to display and manage resources. To view any resource, including a storage account, within the portal, a user must possess at least the Azure RBAC Reader role at the resource, resource group, or subscription scope. Without this management plane permission, the storage account will not be discoverable or visible in the portal, even if the user has separate data plane permissions (e.g., Storage Blob Data Contributor) to access the actual data.

Why this answer

The Azure portal requires the 'Reader' role on the storage account's resource group (or subscription) to list and navigate to the storage account in the portal UI. Even if a user has 'Storage Blob Data Reader' at the storage account scope, without the Azure RBAC 'Reader' role on the resource group, the portal cannot enumerate the storage account resource, preventing access via the portal. The 'Storage Blob Data Reader' role only grants data-plane permissions (read blobs), not control-plane permissions needed to see the resource in the portal.

Exam trap

The trap here is that candidates often confuse data-plane roles (like 'Storage Blob Data Reader') with control-plane roles (like 'Reader'), assuming the data role alone is sufficient for portal access, but the portal requires control-plane permissions to enumerate the resource.

How to eliminate wrong answers

Option A is wrong because the storage account firewall blocking the user's IP would prevent all access (including authenticated access) to the storage account, but the user has the role assigned and the issue is specifically about portal access; firewall rules affect network-level access, not RBAC role assignment. Option C is wrong because using a system-assigned managed identity for authentication does not prevent a user with the 'Storage Blob Data Reader' role from reading blobs via the portal; managed identities are an authentication method for services, not a barrier to user access. Option D is wrong because the role being assigned at the storage account scope but the user trying to access a different storage account would result in a 'not found' or 'access denied' error, but the question states the user has the role assigned and is unable to read blobs, implying the correct storage account is targeted; the issue is about portal visibility, not cross-account access.

Practice this question →

3

MCQeasy

Your Azure App Service app must access Azure Key Vault secrets without storing credentials in code. Which service should you use to manage identities?

A.Service principal with client secret

B.Managed identity

C.Storage account access key

D.Client certificate

AnswerB

Managed identities provide an identity for Azure services in Azure Active Directory, eliminating the need for developers to manage credentials. When an App Service uses a managed identity, Azure automatically handles the authentication to Azure AD and acquires access tokens to interact with other Azure resources like Key Vault. This approach significantly enhances security and simplifies operations by removing the burden of credential storage, rotation, and protection from the application.

Why this answer

Managed identity (B) is correct because it provides an automatically managed Azure AD identity for your App Service app, allowing it to authenticate to Azure Key Vault without storing any credentials in code or configuration. The identity is tied to the app's lifecycle and can be used with Azure RBAC to grant access to secrets, eliminating the need for manual credential management.

Exam trap

The trap here is that candidates often confuse service principals (which require credential storage) with managed identities (which are credential-free), leading them to pick option A because they think any Azure AD identity is equivalent.

How to eliminate wrong answers

Option A is wrong because a service principal with client secret requires storing the secret in code or configuration, which violates the requirement of not storing credentials. Option C is wrong because a storage account access key is used for accessing Azure Storage, not for managing identities or accessing Key Vault secrets. Option D is wrong because a client certificate, while more secure than a secret, still requires the certificate to be stored and managed in the app's code or configuration, failing the 'without storing credentials' requirement.

Practice this question →

4

Multi-Selecthard

Your application uses Azure App Service and needs to authenticate users via Microsoft Entra ID. Which THREE components must be configured in the App Service authentication settings?

Select 3 answers

A.Client ID

B.Allowed token audiences

C.Issuer URL

D.Client secret

E.Tenant ID

AnswersA, B, C

Required to identify the application.

Why this answer

The Client ID uniquely identifies your application registration in Microsoft Entra ID. App Service uses this ID to initiate the OAuth 2.0 authorization code flow, ensuring that tokens are issued specifically to your app. Without it, the authentication middleware cannot associate incoming tokens with your registered application.

Exam trap

The trap here is that candidates often confuse the required fields for App Service authentication with those needed for a manual OAuth 2.0 implementation, mistakenly adding the Client secret or Tenant ID as separate required fields when they are either optional or derived from the Issuer URL.

Practice this question →

5

MCQeasy

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

A.Key Vault Secrets User

B.Key Vault Reader

C.Key Vault Crypto User

D.Contributor

AnswerA

The Key Vault Secrets User role grants the necessary data plane permissions to retrieve the actual secret values stored within Azure Key Vault. Specifically, this role includes the `Microsoft.KeyVault/vaults/secrets/getSecret` data action, which is essential for an application's managed identity to programmatically access and use sensitive configuration data like database connection strings or API keys. Without this specific role, the App Service would be unable to decrypt and fetch the secret's content for operational use.

Why this answer

The system-assigned managed identity needs to read secrets from Key Vault. The 'Key Vault Secrets User' role grants exactly that permission — it allows the identity to perform secret read operations (Get, List) on the secrets in the vault. This is the correct RBAC role for read-only access to secrets, as opposed to keys or certificates.

Exam trap

The trap here is that candidates often confuse 'Key Vault Reader' (which only reads vault metadata, not secrets) with the actual data-plane role needed for secret access, or they mistakenly choose a broad role like 'Contributor' thinking it includes secret read permissions.

How to eliminate wrong answers

Option B is wrong because 'Key Vault Reader' only allows listing and reading the metadata of the vault itself (e.g., vault properties, tags), not the actual secret values. Option C is wrong because 'Key Vault Crypto User' grants permissions for cryptographic operations on keys (e.g., encrypt, decrypt, sign, verify), not for reading secrets. Option D is wrong because 'Contributor' is a general Azure RBAC role that grants full management access to the Key Vault resource (including creating/deleting vaults and changing access policies), which is far more permissive than needed and violates the principle of least privilege.

Practice this question →

6

MCQmedium

You are deploying a web app to Azure App Service that must use a custom domain with TLS/SSL. You have purchased an SSL certificate from a third-party CA. How should you upload and bind the certificate to the custom domain?

A.Place the certificate files in the wwwroot folder of the app and configure the web.config.

B.Import the certificate into Azure Key Vault and reference it from App Service.

C.Upload the .cer file to the App Service and let Azure generate the private key.

D.Upload the .pfx file to the App Service TLS/SSL settings and bind it to the custom domain.

AnswerD

Uploading the .pfx file directly to the App Service's TLS/SSL settings is the correct and most direct method for binding a custom SSL certificate. The .pfx (Personal Information Exchange) format is a cryptographic standard that securely bundles both the public key certificate and its corresponding private key, which are both critical for establishing a secure TLS connection. Once uploaded, the certificate can then be explicitly bound to the desired custom domain within the App Service configuration portal.

Why this answer

Azure App Service requires a .pfx file containing both the public certificate and the private key to bind a custom domain with TLS/SSL. The .pfx file is uploaded directly in the App Service's TLS/SSL settings, and then the certificate is bound to the custom domain, enabling HTTPS traffic.

Exam trap

The trap here is that candidates often confuse the need for a .pfx file (containing the private key) with a .cer file (public key only), or mistakenly think that placing certificate files in the app's file system is sufficient for TLS/SSL binding, when in fact App Service requires the certificate to be uploaded and bound at the platform level.

How to eliminate wrong answers

Option A is wrong because placing certificate files in the wwwroot folder and configuring web.config does not bind the certificate to the custom domain at the App Service platform level; this approach is used for client certificate authentication, not for TLS/SSL termination. Option B is wrong because while Azure Key Vault can store certificates, referencing it from App Service requires the certificate to be imported as an App Service Certificate or configured via a Key Vault reference in the app settings, not a direct upload and bind to the custom domain as described. Option C is wrong because a .cer file contains only the public key, not the private key, so Azure cannot generate the private key; the private key must be included in the upload for TLS/SSL binding.

Practice this question →

7

Multi-Selecteasy

Which TWO methods can you use to authenticate an Azure App Service web app to Azure SQL Database without storing credentials in code? (Choose two.)

Select 2 answers

A.Store the SQL connection string in Azure Key Vault and use a Key Vault reference in the app settings.

B.Enable a system-assigned managed identity on the App Service and grant it access to the database.

C.Use a connection string with a SQL username and password.

D.Use a service principal with a client secret stored in app settings.

E.Use a client certificate installed on the App Service.

AnswersA, B

This method significantly enhances security by storing sensitive connection strings and other secrets in Azure Key Vault, a robust, centralized secret management service. The App Service then uses Key Vault references (e.g., @Microsoft.KeyVault(SecretUri=...)) in its application settings. At runtime, the App Service securely resolves these references, fetching the secret directly from Key Vault without exposing it in configuration files or code, thus preventing hardcoding and simplifying credential rotation.

Why this answer

Azure App Service supports Key Vault references in application settings, allowing you to reference secrets stored in Azure Key Vault without hardcoding credentials. This pattern uses the Managed Service Identity (MSI) of the App Service to authenticate to Key Vault at runtime, retrieving the SQL connection string securely. Option B is correct because enabling a system-assigned managed identity on the App Service and granting it access to the Azure SQL Database via an Azure AD user or contained database user eliminates the need for any stored credentials, as the app authenticates directly to SQL using the managed identity token.

Exam trap

The trap here is that candidates often confuse 'storing credentials in code' with 'storing credentials in configuration' and may incorrectly select Option D (service principal with client secret) thinking it is secure, but the secret is still stored in app settings, which is not credential-free.

Practice this question →

8

MCQmedium

Your company uses Microsoft Defender for Cloud. You need to receive alerts when a user modifies a Key Vault access policy. What should you configure?

A.Create an Azure Policy to audit access policy changes

B.Configure Microsoft Sentinel to monitor Key Vault

C.Enable Key Vault logging and query logs

D.Set up an activity log alert on the Key Vault

AnswerD

Setting up an activity log alert on the Key Vault is the most direct and efficient solution for real-time notification of control plane operations. Azure Activity Log alerts are specifically designed to trigger notifications or automated actions in response to events recorded in the Azure Activity Log, which captures management operations such as creating, updating, or deleting resources. By configuring an alert rule with specific criteria for Key Vault access policy write operations, immediate notifications can be delivered effectively.

Why this answer

Activity log alerts in Azure Monitor can be configured to trigger on specific administrative operations, such as 'Microsoft.KeyVault/vaults/accessPolicies/write'. This allows you to receive near real-time notifications when a Key Vault access policy is modified, directly addressing the requirement without additional services or complex setups.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing logging or SIEM options, not realizing that Azure Activity Log alerts provide a simple, built-in mechanism for monitoring control-plane changes like access policy modifications.

How to eliminate wrong answers

Option A is wrong because Azure Policy is used for enforcing compliance rules and auditing resource configurations at scale, not for generating real-time alerts on specific operations like access policy changes. Option B is wrong because Microsoft Sentinel is a SIEM solution that ingests and analyzes security data from multiple sources; while it can monitor Key Vault logs, it is overkill and not the simplest or most direct method for alerting on access policy modifications. Option C is wrong because enabling Key Vault logging and querying logs (e.g., via Log Analytics) provides historical data for analysis but does not inherently generate proactive alerts; you would need to set up an alert rule on the log query, which is more complex than an activity log alert.

Practice this question →

9

MCQhard

Your company uses Azure API Management to expose APIs to external partners. You need to validate that each incoming request includes a valid JSON Web Token (JWT) issued by your Microsoft Entra ID tenant, and reject requests without valid tokens. What should you configure?

A.Configure an OAuth 2.0 authorization server in API Management

B.Require a subscription key for each API

C.Use an IP access restriction policy

D.Add a validate-jwt policy in the inbound processing policy

AnswerD

Adding a `validate-jwt` policy in the inbound processing policy is the correct and most effective method for enforcing JWT validation within Azure API Management. This policy is specifically designed to inspect the incoming request for a JWT, verify its signature against a configured public key or OpenID Connect discovery endpoint, and validate claims such as issuer, audience, and expiration. It ensures that only requests with valid, unexpired, and untampered tokens proceed to the backend API, rejecting invalid or missing tokens at the gateway.

Why this answer

The validate-jwt policy is the correct choice because it allows API Management to inspect the JWT token in the inbound request, verify its signature against the Microsoft Entra ID tenant’s keys, and enforce claims such as issuer and audience. This policy rejects requests with missing, expired, or invalid tokens, meeting the requirement to validate each incoming request.

Exam trap

The trap here is that candidates confuse configuring an OAuth 2.0 authorization server (which handles token issuance) with applying a policy to validate tokens on each request, leading them to pick Option A instead of the correct validate-jwt policy.

How to eliminate wrong answers

Option A is wrong because configuring an OAuth 2.0 authorization server in API Management defines how tokens are issued, but does not enforce validation of incoming tokens on each request; validation requires a policy like validate-jwt. Option B is wrong because requiring a subscription key validates API access via a key, not a JWT token, and does not verify identity or token validity. Option C is wrong because an IP access restriction policy filters requests based on source IP addresses, not on token presence or validity.

Practice this question →

10

MCQeasy

Refer to the exhibit. You have a custom RBAC role definition. A user assigned this role reports they can read, write, and delete blobs, but cannot list the containers in the storage account. What is the most likely reason?

A.The role does not grant delete permissions on containers.

B.The role lacks dataActions for reading blobs.

C.The user does not have the Reader role on the storage account to navigate in the Azure portal.

D.The role does not include the action to list containers.

AnswerC

This is the correct answer because, even with specific data plane permissions granted by the custom role, the Azure portal requires control plane permissions to list and navigate resources. Without the "Reader" role (or equivalent) assigned at the storage account scope, the user cannot even view the storage account in the portal, preventing them from accessing its containers or blobs, regardless of their data plane access.

Why this answer

The user can perform blob operations (read, write, delete) because the custom RBAC role includes the necessary data actions (e.g., Microsoft.Storage/storageAccounts/blobServices/containers/blobs/*). However, listing containers requires the control plane action Microsoft.Storage/storageAccounts/blobServices/containers/read, which is not included in the role. Without the Reader role on the storage account (which grants this action), the user cannot list containers in the Azure portal, even though they can interact with blobs directly via tools that bypass the portal's container enumeration.

Exam trap

The trap here is that candidates assume blob read/write/delete permissions automatically include the ability to list containers, but Azure separates control plane and data plane permissions, and the portal specifically requires the Reader role for navigation.

How to eliminate wrong answers

Option A is wrong because the user can delete blobs, indicating delete permissions on blobs are granted; the issue is with listing containers, not deleting them. Option B is wrong because the user can read blobs, so dataActions for reading blobs are present; the problem is the lack of control plane action for listing containers. Option D is wrong because the role likely does not include the action to list containers (Microsoft.Storage/storageAccounts/blobServices/containers/read), but this is not the most likely reason given the user can perform blob operations; the core issue is that the portal requires the Reader role to navigate and list containers, which is a separate permission.

Practice this question →

11

MCQhard

You are designing a solution for a multi-tenant SaaS application where each tenant's data is stored in separate Azure SQL databases. You need to ensure that no tenant can access another tenant's database, even if the application is compromised. What should you implement?

A.Configure a server-level firewall rule for each tenant's IP range

B.Assign each tenant a managed identity with a dedicated SQL login and database-level permissions

C.Implement connection pooling with a single identity

D.Use a single database-level login and row-level security (RLS) to filter data

AnswerB

Assigning each tenant a dedicated managed identity, coupled with a unique SQL login and database-level permissions restricted to *only* that tenant's specific database, provides robust tenant isolation. Managed identities eliminate the need for managing credentials, enhancing security. By ensuring each tenant's application component authenticates with its own identity and possesses least privilege access solely to its designated database, this strategy effectively prevents cross-tenant data access even in the event of a compromise of one tenant's application instance.

Why this answer

Assigning each tenant a managed identity with a dedicated SQL login and database-level permissions ensures that even if the application is compromised, the attacker cannot access another tenant's database. Managed identities provide an Azure AD-backed identity for the application, and by mapping each tenant to a separate SQL login with permissions scoped to their specific database, you enforce tenant isolation at the database authentication and authorization layer. This prevents cross-tenant access because the application can only authenticate to the database corresponding to the tenant's managed identity.

Exam trap

The trap here is that candidates often confuse network-level security (firewall rules) or data-level filtering (RLS) with proper authentication and authorization isolation, failing to recognize that a compromised application with a shared identity can bypass both network and row-level controls.

How to eliminate wrong answers

Option A is wrong because server-level firewall rules control network access by IP address, not authentication or authorization; if the application is compromised, an attacker could still use the same IP range to access any tenant's database. Option C is wrong because connection pooling with a single identity means all tenants share the same SQL login, so if the application is compromised, the attacker could access all tenant databases using that single identity. Option D is wrong because using a single database-level login with row-level security (RLS) still allows the application to connect to all tenant data in the same database; RLS filters rows at query time but does not prevent an attacker from executing arbitrary queries that might bypass the filter or access other tenants' data if the application logic is compromised.

Practice this question →

12

MCQhard

You are building a web application that uses Microsoft Entra ID for authentication. The application needs to call Microsoft Graph API to read user profiles and send emails on behalf of the signed-in user. You want to ensure that the user's consent is obtained only once and that the application can refresh tokens silently. Which OAuth 2.0 flow should you implement?

A.OAuth 2.0 Client Credentials flow.

B.OAuth 2.0 Implicit Grant flow.

C.OAuth 2.0 Authorization Code flow with PKCE (Proof Key for Code Exchange).

D.OAuth 2.0 Resource Owner Password Credentials (ROPC) flow.

AnswerC

This flow is secure for web apps, provides refresh tokens for silent renewal, and obtains user consent during the initial authentication. It is the recommended flow by Microsoft for web applications calling APIs on behalf of users.

Why this answer

The Authorization Code flow with PKCE is the recommended OAuth 2.0 flow for public client applications (like single-page apps or mobile apps) that need delegated access to Microsoft Graph. It allows the application to obtain an authorization code, exchange it for an access token and a refresh token, and use the refresh token to silently acquire new tokens without requiring the user to re-consent. This flow ensures that user consent is obtained only once and supports silent token refresh, meeting the requirements.

Exam trap

The trap here is that candidates often confuse the Client Credentials flow (which is for app-only access) with delegated user scenarios, or they mistakenly think the Implicit Grant flow is still acceptable for modern apps, ignoring the fact that it lacks refresh token support and is deprecated by Microsoft.

How to eliminate wrong answers

Option A is wrong because the Client Credentials flow is used for server-to-server (daemon) scenarios where no user is involved, so it cannot obtain consent from a signed-in user or send emails on behalf of the user. Option B is wrong because the Implicit Grant flow is deprecated and does not support refresh tokens, making silent token refresh impossible; it also exposes tokens in the URL, posing security risks. Option D is wrong because the Resource Owner Password Credentials flow requires the user to provide their credentials directly to the application, which is not recommended for modern applications due to security concerns and does not support refresh tokens for silent renewal in all scenarios.

Practice this question →

13

MCQmedium

You deploy a web application in Azure App Service. You need to authenticate users via Microsoft Entra ID (Microsoft Entra ID) with minimal custom code. Which App Service feature should you configure?

A.App Service Authentication (Easy Auth)

B.Microsoft Entra ID B2C

C.Application Gateway with WAF

D.App Service Managed Identity

AnswerA

App Service Authentication, often called Easy Auth, provides a built-in, declarative way to secure your web application by offloading user authentication to the App Service platform. It integrates seamlessly with identity providers like Microsoft Entra ID, allowing your application to authenticate enterprise users without writing any authentication-related code. This significantly reduces development effort and enhances security by centralizing identity management at the platform level.

Why this answer

App Service Authentication (also known as Easy Auth) is the correct choice because it provides a turnkey authentication layer that integrates directly with Microsoft Entra ID. It requires minimal custom code by handling the OAuth 2.0 authorization code flow, token validation, and session management at the App Service platform level, allowing you to simply configure the identity provider in the Azure portal.

Exam trap

The trap here is that candidates confuse Managed Identity (which is for server-to-server resource access) with user authentication, or they overcomplicate the solution by choosing B2C when the requirement is simply to authenticate against an existing Microsoft Entra ID tenant with minimal code.

How to eliminate wrong answers

Option B (Microsoft Entra ID B2C) is wrong because it is designed for customer-facing applications with external identity providers and social logins, not for authenticating users via an existing Microsoft Entra ID tenant with minimal code; it adds unnecessary complexity and custom policy configuration. Option C (Application Gateway with WAF) is wrong because it is a layer 7 load balancer and web application firewall that does not provide any authentication or token validation for Microsoft Entra ID; it focuses on traffic routing and security filtering, not identity. Option D (App Service Managed Identity) is wrong because it is used to grant the app itself an identity to securely access other Azure resources (e.g., Key Vault, Storage), not to authenticate external users; it does not handle user login or token issuance.

Practice this question →

14

MCQmedium

Refer to the exhibit. You are deploying an Azure Key Vault using this ARM template. Your team plans to use RBAC to manage access. The vault must be accessible from Azure services (e.g., Azure VMs) without public IP addresses. After deployment, a developer reports that they cannot access secrets from a VM in the same region, even though the VM has a managed identity with the Key Vault Secrets User role. What is the most likely cause?

A.Soft delete is enabled, which prevents access to secrets until they are recovered.

B.The accessPolicies array is empty, so RBAC is not working.

C.The vault name is not unique and conflicts with another vault.

D.The vault's network ACLs block all traffic except from Azure services, but VMs are not considered Azure services.

AnswerD

The vault's network ACLs are configured with `defaultAction: Deny` and `bypass: AzureServices`, meaning only traffic from specific Microsoft trusted services can access the vault. Azure Virtual Machines (VMs) are customer-deployed resources within a virtual network, not considered part of the 'Azure services' bypass group for Key Vault network access. Consequently, direct access from a VM requires explicit configuration via virtual network rules or a private endpoint to be permitted.

Why this answer

The ARM template's network ACLs are configured with a default action of 'Deny' and an exception for 'AzureServices' only. Azure VMs without public IP addresses are not considered part of the 'AzureServices' bypass category; that category is reserved for Azure platform services like Azure Resource Manager or Azure Policy, not for compute instances. Therefore, the VM's traffic is blocked by the firewall, even though it has a managed identity with the correct RBAC role.

Exam trap

The trap here is that candidates assume 'Azure services' includes all Azure resources like VMs, but in Key Vault network ACLs, it specifically refers to a limited set of platform services, not customer-deployed compute instances.

How to eliminate wrong answers

Option A is wrong because soft delete does not prevent access to secrets; it only adds a retention period after deletion, and secrets are fully accessible until explicitly deleted. Option B is wrong because the accessPolicies array being empty is irrelevant when using RBAC; RBAC is independent of access policies and is enabled at the vault level via the 'enableRbacAuthorization' property (not shown here, but RBAC is planned). Option C is wrong because vault name uniqueness is enforced globally by Azure; a conflict would cause a deployment failure, not a runtime access issue.

Practice this question →

15

MCQmedium

You need to restrict access to an Azure Storage account so that only a specific subnet of a virtual network can access the data. Additionally, you need to allow management access from the Azure portal (e.g., to view containers). Which configuration should you apply?

A.Configure IP firewall rules to allow the subnet IP range and add the Azure portal's public IP addresses.

B.Configure a service endpoint for Microsoft.Storage on the subnet and add a firewall rule to allow the subnet, then enable 'Allow trusted Microsoft services'.

C.Configure a private endpoint for the storage account and disable public network access.

D.Configure IP ACLs to allow the subnet and also allow all Azure services.

AnswerB

Service endpoint provides secure connectivity from the subnet. The trusted Microsoft services exception allows portal management while keeping the firewall restricted.

Why this answer

Configuring a service endpoint for Microsoft.Storage on the subnet ensures traffic from that subnet to the storage account stays within the Azure backbone, and the firewall rule restricts access to that subnet. Enabling 'Allow trusted Microsoft services' permits Azure portal management operations (e.g., listing containers) because the portal is a trusted service that bypasses the network rules for control-plane actions.

Exam trap

The trap here is that candidates often confuse 'Allow trusted Microsoft services' with 'Allow all Azure services' or assume that IP-based rules for the Azure portal are static, when in fact the portal uses dynamic IP ranges that are not suitable for firewall rules.

How to eliminate wrong answers

Option A is wrong because Azure portal does not have a fixed set of public IP addresses; they can change, making this approach unreliable and not a supported pattern for management access. Option C is wrong because a private endpoint with public network access disabled would block all internet-based access, including the Azure portal, preventing management from the portal entirely. Option D is wrong because 'Allow all Azure services' is a legacy setting that broadly permits traffic from any Azure service, not just the specific subnet, violating the requirement to restrict access to only that subnet.

Practice this question →

16

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 design must avoid adding custom operational scripts.

A.Implicit flow

B.Client credentials flow

C.Resource owner password credentials flow

D.Authorization code flow with PKCE

AnswerD

The Authorization Code flow with Proof Key for Code Exchange (PKCE) is the recommended and most secure method for Single Page Applications. PKCE protects public clients, which cannot securely store a client secret, by using a dynamically generated 'code verifier' and 'code challenge' during the authorization process. This mechanism ensures that even if a malicious actor intercepts the authorization code, they cannot exchange it for tokens without the original client's unique verifier, preventing code interception attacks.

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 (SPAs) that cannot securely store a client secret. PKCE uses a dynamically generated cryptographic code verifier and challenge, ensuring that even if the authorization code is intercepted, it cannot be exchanged for tokens without the original verifier. This flow is designed for public clients (like SPAs) and avoids the need for custom operational scripts.

Exam trap

The trap here is that candidates often confuse the deprecated implicit flow with the modern authorization code flow with PKCE, mistakenly believing that SPAs must use the implicit flow because they cannot store a secret, but the correct answer is the PKCE-enhanced authorization code flow.

How to eliminate wrong answers

Option A is wrong because the implicit flow is deprecated by the OAuth 2.0 Security Best Current Practice (BCP) RFC 8252 due to security risks like access token leakage in the browser history and lack of token binding. Option B is wrong because the client credentials flow is intended for server-to-server (confidential client) scenarios, not for user authentication in a single-page app; it requires a client secret and cannot represent an interactive user. Option C is wrong because the resource owner password credentials flow (ROPC) is highly discouraged for modern apps as it exposes the user's credentials to the client, violates security best practices, and is not suitable for SPAs; it also requires custom scripting to handle credential collection.

Practice this question →

17

MCQhard

Your company uses Microsoft Sentinel for security information and event management (SIEM). You need to detect and automatically respond to a potential credential theft attack where an anomalous number of failed logins are followed by a successful login from a different geographic location. Which Microsoft Sentinel feature should you use?

A.Microsoft Sentinel Data Connectors

B.An analytics rule with an automated response

C.Microsoft Defender for Identity

D.Microsoft Sentinel playbooks

AnswerB

An analytics rule in Microsoft Sentinel is designed to detect specific threat patterns or anomalies within the ingested data using Kusto Query Language (KQL). When an analytics rule's query condition is met, it can automatically generate an incident, signaling a potential security threat. Crucially, these rules can be configured to trigger an automated response directly, such as running a playbook to disable a user account or isolate a compromised host, thereby combining detection with immediate mitigation. This integrated approach directly addresses both the identification and remediation aspects of threat management.

Why this answer

An analytics rule in Microsoft Sentinel can be configured to detect patterns like anomalous failed logins followed by a successful login from a different geography. The rule can then trigger an automated response, such as running a playbook or creating an incident, to remediate the threat in near real-time. This combines detection and automated action within a single rule, making it the correct choice for this scenario.

Exam trap

The trap here is that candidates often confuse 'playbooks' (the automation component) with the complete detection-and-response feature, forgetting that an analytics rule is required to trigger the playbook and that the rule itself can include an automated response directly.

How to eliminate wrong answers

Option A is wrong because Microsoft Sentinel Data Connectors are used to ingest log data from various sources (e.g., Azure AD, firewalls) but do not perform detection or automated response. Option C is wrong because Microsoft Defender for Identity is a separate security product focused on on-premises Active Directory identity threats, not a native Sentinel feature for creating custom detection rules with automated responses. Option D is wrong because Microsoft Sentinel playbooks are automated workflows (based on Azure Logic Apps) that can be triggered by analytics rules, but they are not the detection mechanism themselves; the question asks for the feature that both detects and automatically responds, which is the analytics rule with an automated response.

Practice this question →

18

MCQmedium

You are developing a serverless function app that processes credit card payments. The function app must securely store the payment gateway API key. Which Azure service should you use to store the key?

A.Store the key in an Azure Storage queue and read it at runtime.

B.Store the key in Azure Key Vault and retrieve it using a managed identity.

C.Store the key in Azure Cosmos DB with client-side encryption.

D.Store the key in the function app's application settings.

AnswerB

Azure Key Vault is purpose-built for securely storing and managing cryptographic keys, secrets, and certificates, offering strong encryption at rest, access policies, and comprehensive auditing. Utilizing a managed identity for the function app allows it to authenticate to Azure AD and then to Key Vault without any hardcoded credentials in the application code or configuration. This establishes a secure, credential-less connection, adhering to the principle of least privilege and simplifying secret rotation.

Why this answer

Azure Key Vault is the designated service for securely storing and managing secrets, keys, and certificates. By using a managed identity, the function app can authenticate to Key Vault without embedding any credentials in code or configuration, ensuring the API key is never exposed in plaintext.

Exam trap

The trap here is that candidates often choose application settings (Option D) because they are convenient and commonly used for non-sensitive configuration, but they fail to recognize that secrets like API keys require the dedicated security and access control provided by Key Vault.

How to eliminate wrong answers

Option A is wrong because an Azure Storage queue is a messaging service, not a secure secret store; storing an API key there would expose it in transit and at rest without native access control or auditing. Option C is wrong because Azure Cosmos DB is a NoSQL database, and while client-side encryption can protect data, it still requires managing encryption keys and does not provide the centralized secret lifecycle management, rotation, and access policies that Key Vault offers. Option D is wrong because function app application settings are stored in plaintext in the Azure portal and can be read by anyone with contributor-level access; they lack the fine-grained access control, audit logging, and automatic rotation capabilities of Key Vault.

Practice this question →

19

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?

A.Implicit flow

B.Client credentials flow

C.Resource owner password credentials flow

D.Authorization code flow with PKCE

AnswerD

PKCE protects public clients that cannot store secrets and is recommended for SPAs.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth flow for single-page apps that cannot securely store a client secret. PKCE ensures that even if the authorization code is intercepted, it cannot be exchanged for tokens without the original code verifier, mitigating the risk of code injection attacks. This flow aligns with Microsoft's best practices for native and browser-based applications using Microsoft Entra ID.

Exam trap

The trap here is that candidates often confuse the implicit flow (which was historically used for SPAs) as still valid, but Microsoft and OAuth standards now mandate the authorization code flow with PKCE for all public clients, including single-page apps.

How to eliminate wrong answers

Option A is wrong because the implicit flow is deprecated by the OAuth 2.0 Security Best Current Practice (BCP) and Microsoft Entra ID due to security risks like access token leakage in the browser history and lack of PKCE support. Option B is wrong because the client credentials flow is designed for server-to-server (daemon) applications without a user context, not for single-page apps that need to sign in users and call APIs on their behalf. Option C is wrong because the resource owner password credentials flow requires the app to handle user credentials directly, which is insecure for browser-based apps and violates the principle of not exposing passwords to the client.

Practice this question →

20

MCQhard

A background data pipeline runs on a schedule and must read user profile data from Microsoft Graph. No user is present during execution. The service authenticates to Microsoft Entra ID and calls the Graph API. Which permission type and OAuth 2.0 flow are correct for this scenario?

A.Application permissions with the client credentials flow, authenticating with the app's client ID and secret (or certificate)

B.Delegated permissions with the authorization code flow, initiating a browser redirect to collect user consent

C.Delegated permissions with the device code flow, prompting a user to authenticate on a separate device

D.Application permissions with the on-behalf-of flow, passing the calling user's token to the Graph API

AnswerA

Application permissions are granted by an admin via the app registration manifest. The client credentials flow does not require user interaction — the service presents its own credentials to the token endpoint and receives a token scoped to the application. This is the standard pattern for background services, daemons, and scheduled jobs that call Microsoft Graph.

Why this answer

This scenario requires a background service to access Microsoft Graph without any user interaction. Application permissions are designed for such non-interactive, service-to-service calls, and the client credentials OAuth 2.0 flow (defined in RFC 6749 section 4.4) allows the app to authenticate using its own identity (client ID and secret or certificate) to obtain an access token. Delegated permissions would be incorrect because they require a signed-in user context, which is absent here.

Exam trap

The trap here is that candidates often confuse application permissions with delegated permissions, mistakenly thinking a user context is always required for Graph API calls, but the client credentials flow is the correct choice for any background service that operates without a signed-in user.

How to eliminate wrong answers

Option B is wrong because delegated permissions require a signed-in user and the authorization code flow involves a browser redirect for user consent, which cannot occur in an unattended background pipeline. Option C is wrong because the device code flow is designed for devices with limited input capabilities and still requires a user to authenticate interactively on a separate device, not suitable for a fully automated service. Option D is wrong because the on-behalf-of flow (OAuth 2.0 On-Behalf-Of) is used to pass a user's delegated token to a downstream API, requiring an initial user token, which does not exist in this no-user scenario.

Practice this question →

21

Multi-Selecthard

Which TWO actions should you take to securely store and access secrets for a legacy application that cannot be modified? The application runs on an Azure Virtual Machine and needs to read a database connection string. The solution must use Azure Key Vault and adhere to the principle of least privilege.

Select 2 answers

A.Create a new VM and install the Key Vault extension during provisioning.

B.Configure the application to read the connection string from a local file that is updated by the Key Vault extension.

C.Assign a managed identity to the legacy application.

D.Use a user-assigned managed identity and assign it to the VM.

E.Enable the Azure Key Vault VM extension for the virtual machine.

AnswersB, E

Configuring the legacy application to read connection strings from a local file is the crucial step for enabling it to consume secrets securely. The Azure Key Vault VM extension facilitates this by periodically fetching secrets from Key Vault and writing them to a designated file path on the VM's local file system. This method allows the application, which lacks native Key Vault integration capabilities, to access sensitive data without code changes or embedding credentials.

Why this answer

The legacy application cannot be modified, so it cannot directly call the Key Vault REST API or SDK. The Azure Key Vault VM extension (also known as the Key Vault Sync extension) runs as a daemon on the VM, retrieves secrets from Key Vault using a managed identity, and writes them to a local file. The application reads the connection string from that local file, achieving secure secret access without code changes.

Exam trap

The trap here is that candidates often think a managed identity alone allows an unmodified application to access Key Vault, but in reality, the application must either use the Azure SDK or rely on the Key Vault extension to write secrets to a local file, since the legacy code cannot be changed to call the Key Vault REST API.

Practice this question →

22

MCQmedium

Refer to the exhibit. You are reviewing an Azure Policy definition. When applied to a subscription, what is the effect of this policy?

A.Audit resources in locations other than eastus or westus

B.Append a tag to resources in eastus or westus

C.Deny deployment of resources in eastus or westus

D.Deny deployment of resources in locations other than eastus or westus

AnswerD

This option is correct because it accurately describes both the effect and the condition of the Azure Policy. The 'deny' effect prevents the creation or update of resources that violate the policy rules. When combined with a condition that specifies 'location notIn ['eastus', 'westus']', the policy will block any attempt to deploy resources into any Azure region other than East US or West US, ensuring strict regional compliance.

Why this answer

The policy definition uses the 'deny' effect with a condition that evaluates to true when the resource location is not equal to 'eastus' or 'westus'. This means any deployment attempt to a region outside these two will be blocked. The 'deny' effect prevents the resource creation entirely, rather than just auditing or modifying it.

Exam trap

The trap here is that candidates misread the condition logic—the 'notEquals' combined with 'or' for allowed regions means the deny triggers for any location that is not in the allowed list, not for the allowed locations themselves.

How to eliminate wrong answers

Option A is wrong because the policy uses the 'deny' effect, not 'audit', so it blocks deployment rather than merely logging non-compliance. Option B is wrong because the policy does not use the 'append' effect or any tag-related operation; it denies deployment based on location. Option C is wrong because the condition denies resources in locations other than eastus or westus, not resources in eastus or westus themselves.

Practice this question →

23

MCQmedium

You are designing a solution where an Azure Logic App needs to send emails via Microsoft Graph. The Logic App should authenticate without user interaction. What authentication method should you use?

A.Use a user-assigned managed identity and grant it the Mail.Send application permission

B.Use OAuth 2.0 authorization code grant with a user account

C.Use a service principal and store its client secret in the Logic App configuration

D.Use basic authentication with an email account password

AnswerA

User-assigned managed identities provide an Azure AD identity for Azure resources, eliminating the need for developers to manage credentials. By granting the Mail.Send application permission to this managed identity, the Logic App can securely authenticate with Microsoft Graph and send emails programmatically without any user interaction or storing secrets. This approach adheres to the principle of least privilege and enhances security by leveraging Azure AD for authentication and authorization.

Why this answer

A user-assigned managed identity provides a secure, passwordless authentication method for Azure resources. By granting it the Mail.Send application permission (not delegated), the Logic App can authenticate to Microsoft Graph without any user interaction, as managed identities are automatically managed by Azure and do not require credential rotation or storage.

Exam trap

The trap here is that candidates often confuse delegated permissions (which require a signed-in user) with application permissions (which allow daemon/service scenarios), and mistakenly choose OAuth authorization code grant or service principal with secret, not realizing managed identities are the recommended zero-secret approach for Azure resources.

How to eliminate wrong answers

Option B is wrong because the OAuth 2.0 authorization code grant requires an interactive user login to obtain a code and token, which violates the 'without user interaction' requirement. Option C is wrong because storing a client secret in the Logic App configuration introduces a security risk (secret exposure) and requires manual secret rotation, whereas managed identities eliminate the need for secrets entirely. Option D is wrong because basic authentication with a password is deprecated by Microsoft for Graph API and does not support application-level permissions; it also requires user interaction and is insecure.

Practice this question →

24

MCQeasy

You are deploying a multi-tier application: a frontend web app (Azure App Service) that calls a backend API (another Azure App Service). Both apps use Microsoft Entra ID for authentication. The frontend needs to authenticate to the backend on behalf of the signed-in user. You need to configure the OAuth 2.0 flow correctly. You have already registered both applications in Microsoft Entra ID. Which configuration should you apply?

A.In the frontend app registration, grant API permissions for the backend using the 'Delegated permissions' type. In the backend app registration, expose an API scope. The frontend uses the on-behalf-of flow (OBO) to exchange the user's token for a token to call the backend.

B.In the frontend app registration, enable the implicit grant flow for access tokens. The frontend gets a token for the backend directly from the authorization endpoint.

C.In the frontend app registration, set the redirect URI to the backend URL. The frontend uses the authorization code flow to get a token for the backend directly.

D.In the frontend app registration, grant API permissions for the backend using the 'Application permissions' type. In the backend app registration, expose an API scope. The frontend uses the client credentials flow to get a token for the backend.

AnswerA

This option correctly describes the standard and secure pattern for a multi-tier application using Azure AD. The frontend application, acting on behalf of the signed-in user, requests a token for the backend API using the On-Behalf-Of (OBO) flow. This flow exchanges the user's token, obtained by the frontend, for a new token specifically scoped for the backend API, preserving the user's identity throughout the call chain. Delegated permissions in the frontend's app registration allow it to request access to the backend API on behalf of the user, while the backend exposes API scopes to define what access is available.

Why this answer

The frontend needs to act on behalf of the signed-in user, which requires delegated permissions. The backend must expose an API scope so the frontend can request it. The OAuth 2.0 On-Behalf-Of (OBO) flow is designed for this scenario: the frontend receives a token for itself, then exchanges it via the OBO flow for a token scoped to the backend API, preserving the user's identity and consent.

Exam trap

The trap here is confusing delegated permissions (user context) with application permissions (app-only context), leading candidates to incorrectly choose the client credentials flow (Option D) or the implicit flow (Option B) when the OBO flow is required for multi-tier user delegation.

How to eliminate wrong answers

Option B is wrong because the implicit grant flow is deprecated and insecure; it exposes access tokens in the URL fragment and does not support the OBO flow needed to propagate the user context to the backend. Option C is wrong because setting the redirect URI to the backend URL would cause the authorization code to be sent to the backend, not the frontend, breaking the authentication flow; the frontend must receive the code itself. Option D is wrong because 'Application permissions' are used for client credentials flow (daemon/service scenarios) without a user context; this would make the frontend act as itself, not on behalf of the signed-in user, violating the requirement.

Practice this question →

25

MCQhard

You are developing an ASP.NET Core web API that uses Microsoft Entra ID for authentication via Microsoft.Identity.Web. The application needs to authorize actions based on custom roles such as "Editor" and "Reviewer". These roles are not defined in Microsoft Entra ID app roles or directory roles; instead, they are stored in an application database and can be assigned dynamically by administrators. You need to implement authorization with minimal impact on performance and without modifying the application's authentication flow. Which approach should you use?

A.Add custom claims to the token via Microsoft Entra ID custom claims policies

B.Implement a custom authorization filter that reads the user's roles from the database on each request and caches them

C.Use Microsoft Entra ID app roles and assign them to users or groups

D.Use a custom middleware to modify the User principal after authentication, adding role claims from the database

AnswerD

A custom middleware positioned after authentication middleware but before authorization middleware is ideal for this scenario. It can access the authenticated `ClaimsPrincipal`, query the application database for dynamic roles (with caching for performance), and then add these roles as `ClaimTypes.Role` claims to the principal. This ensures the `ClaimsPrincipal` is fully enriched with application-specific roles early in the request pipeline, making them consistently available for all subsequent authorization checks, including `[Authorize]` attributes and policy-based authorization, without modifying the core authentication process.

Why this answer

It allows you to add role claims from the application database to the User principal after authentication via custom middleware, without altering the authentication flow. This approach leverages the existing Microsoft.Identity.Web authentication pipeline and caches the role claims in the principal, minimizing performance impact by avoiding repeated database lookups on every request.

Exam trap

The trap here is that candidates often confuse custom middleware with authorization filters, assuming both run at the same point in the pipeline, but middleware modifies the principal before authorization runs, while filters run after authentication and can cause redundant database calls if not designed carefully.

How to eliminate wrong answers

Option A is wrong because custom claims policies in Microsoft Entra ID are used to add claims to tokens issued by Entra ID, but they cannot dynamically read roles from an external database; they are static and defined at the tenant level, not suitable for application-specific dynamic roles. Option B is wrong because implementing a custom authorization filter that reads roles from the database on each request would cause a database call for every authorization check, significantly impacting performance even with caching, as the filter runs after authentication and does not modify the principal for downstream use. Option C is wrong because Microsoft Entra ID app roles are static and must be defined in the app manifest and assigned to users or groups in the portal, which does not support dynamically assigning roles from an application database without administrative intervention.

Practice this question →

26

MCQhard

Refer to the exhibit. You run the Azure CLI command to retrieve a secret from Azure Key Vault. The output shows the secret metadata but not the secret value. The command returns without error. What is the most likely cause?

A.The secret has expired.

B.The user does not have the Key Vault Secrets Officer role.

C.The secret is in a soft-deleted state.

D.The command output only shows metadata by default; you must specify --query "value" to retrieve the secret value.

AnswerD

Azure CLI commands for Key Vault secrets are inherently security-conscious, and by default, "az keyvault secret show" only displays the secret's metadata, such as its ID, attributes, and tags, but intentionally omits the sensitive "value" field. This design choice prevents accidental exposure of secret content in terminal outputs or logs. To explicitly retrieve the actual secret value, users must leverage the "--query \"value\"" parameter, which uses JMESPath to filter the JSON response and extract only the desired sensitive data.

Why this answer

The Azure CLI `az keyvault secret show` command returns the secret metadata (including attributes like id, enabled, created, updated) by default, but does not include the secret value unless you explicitly request it using the `--query "value"` parameter. Since the command completed without error and only metadata was shown, the most likely cause is that the output was not filtered to retrieve the secret value.

Exam trap

The trap here is that candidates assume the command output includes the secret value by default, but Azure CLI intentionally omits it for security, requiring an explicit `--query "value"` to retrieve the actual secret.

How to eliminate wrong answers

Option A is wrong because an expired secret would still return its value if queried; the command would show an error or the secret would be disabled, not silently omit the value. Option B is wrong because the Key Vault Secrets Officer role is required to manage secrets (set, delete, etc.), but reading a secret value requires the Key Vault Secrets User role; a permissions issue would result in a 403 Forbidden error, not a successful command with metadata only. Option C is wrong because a soft-deleted secret would not be returned by the standard `show` command; you would need to use `az keyvault secret show --id <id> --include-soft-deleted` to see it, and the command would not succeed without that flag.

Practice this question →

27

MCQmedium

Your web app running on Azure App Service requires access to a storage account using managed identity. You enable the system-assigned managed identity on the App Service and assign the 'Storage Blob Data Contributor' role at the storage account scope. However, the app receives 403 errors when trying to read blobs. What is the most likely cause?

A.The managed identity token is being requested with the wrong audience. You need to specify 'https://storage.azure.com' as the resource.

B.Managed identity is not supported for Azure App Service; use a connection string instead.

C.The role assignment has not propagated yet; wait 30 minutes.

D.The storage account has a firewall rule that blocks the App Service outbound IPs.

AnswerA

When an Azure App Service uses a managed identity to access another Azure service, it requests an OAuth 2.0 access token from Azure Active Directory. Each Azure service exposes a specific 'resource' URI, which acts as the audience for the token. For Azure Storage, this required audience is 'https://storage.azure.com', not the default 'https://management.azure.com' used for Azure Resource Manager operations. Requesting a token with the incorrect audience will result in an authorization failure, typically a 403 Forbidden error, because the target service will reject the token as not being issued for its intended use.

Why this answer

When using managed identity with Azure Storage, the access token must be requested with the correct audience (resource). For Azure Blob Storage, the audience must be 'https://storage.azure.com'. If the app requests the token with a different audience (e.g., the default Azure Resource Manager endpoint 'https://management.azure.com'), the token will be rejected by the storage service, resulting in a 403 error despite the role assignment being in place.

Exam trap

The trap here is that candidates assume the role assignment alone is sufficient, overlooking that the token's audience must match the target service (storage vs. management), which is a subtle but critical detail in managed identity authentication flows.

How to eliminate wrong answers

Option B is wrong because managed identity is fully supported for Azure App Service; it is a recommended best practice over connection strings for security. Option C is wrong because role assignments for managed identities typically propagate within a few minutes, not 30 minutes; waiting 30 minutes is unnecessary and not the cause of the 403 error. Option D is wrong because firewall rules blocking outbound IPs would cause a network-level failure (e.g., timeout or connection refused), not a 403 authorization error; a 403 indicates the request reached the storage account but was denied due to invalid credentials or permissions.

Practice this question →

28

Multi-Selectmedium

You need to design a solution to securely store and access secrets (e.g., API keys, connection strings) for a set of Azure Functions. The solution must minimize administrative overhead and avoid storing secrets in code or configuration files. Which THREE should you include? (Choose three.)

Select 3 answers

A.Store secrets in Azure Key Vault

B.Store secrets in application settings as plain text

C.Use Azure App Configuration for feature flags

D.Assign a managed identity to each function app

E.Enable Key Vault soft-delete and purge protection

AnswersA, D, E

Azure Key Vault is the industry-standard, highly secure solution for centrally storing and managing cryptographic keys, certificates, and sensitive application secrets like API keys and database connection strings. It provides robust protection through FIPS 140-2 Level 2 validated Hardware Security Modules (HSMs) for cryptographic operations, ensuring secrets are encrypted at rest and in transit. Access to these secrets is meticulously controlled via Azure Role-Based Access Control (RBAC) or Key Vault access policies, enabling fine-grained permissions and comprehensive auditing.

Why this answer

Azure Key Vault is the correct service for securely storing secrets like API keys and connection strings because it provides centralized, hardware-backed secret management with access policies and auditing. By referencing Key Vault secrets from Azure Functions via a managed identity, you avoid storing secrets in code or configuration files, which aligns with the requirement to minimize administrative overhead and eliminate plaintext secrets. Enabling Key Vault soft-delete and purge protection is a critical security best practice to prevent accidental or malicious permanent deletion of secrets, ensuring data resilience and compliance, which is essential for a robust 'secure solution'.

Exam trap

The trap here is that candidates often confuse Azure App Configuration with a secret store, but App Configuration is for feature flags and non-sensitive configuration, while Key Vault is the dedicated service for secrets, and managed identities are required to access it securely without storing credentials.

Practice this question →

29

MCQmedium

You are developing a serverless API using Azure Functions. The API should only be accessible from a specific virtual network. You need to configure network security. What should you do?

A.Place the Functions in Azure API Management and configure IP restrictions.

B.Configure IP address restrictions on the Function App to allow only the VNet's public IP range.

C.Deploy the Function App in a Premium plan and configure VNet integration, then use a Network Security Group to restrict traffic.

D.Configure a private endpoint for the Function App and disable public access.

AnswerD

Configuring a private endpoint for the Function App primarily provides secure *inbound* access to the Function App from within a Virtual Network (VNet), making the service appear as if it's part of the VNet and disabling public access. However, a private endpoint does not inherently enable the Function App to establish *outbound* connections to other resources located *within* that VNet. VNet integration is the specific feature designed for a Function App to access resources inside a VNet.

Why this answer

To ensure the Azure Function API is *only* accessible from a specific virtual network, the most secure and direct approach is to configure a private endpoint for the Function App within that VNet. A private endpoint assigns a private IP address from your VNet to the Function App, making it accessible privately within the VNet. Crucially, you must then disable public access to the Function App.

This combination ensures that all traffic must flow through the private endpoint from within the VNet, thereby meeting the requirement for network-level isolation and restricting access exclusively to the specified VNet. Option C's explanation is misleading as VNet integration primarily enables outbound connectivity, and an NSG on the VNet-integrated subnet does not directly block public internet access to the Function App's public endpoint.

Exam trap

The trap here is that candidates might consider VNet integration (which primarily enables outbound connectivity from the Function App to the VNet) or IP restrictions on the public endpoint. However, for truly restricting inbound access *only* from a VNet and disabling public internet access, a Private Endpoint is the most robust and secure solution.

How to eliminate wrong answers

Option A is wrong because placing Functions in Azure API Management and configuring IP restrictions does not restrict access to the underlying Function App itself; API Management acts as a gateway, but the Function App's public endpoint remains accessible unless additional restrictions are applied, and IP restrictions in API Management only control access to the API Management instance, not the VNet. Option B is wrong because configuring IP address restrictions on the Function App to allow only the VNet's public IP range is ineffective; VNet traffic uses private IP addresses (RFC 1918), not public IPs, and the Function App's public endpoint would still be reachable from the internet if the VNet's public IP range is allowed, which does not enforce VNet-only access. Option D is wrong because configuring a private endpoint for the Function App and disabling public access would restrict access to the private endpoint, but private endpoints require a Premium or Dedicated plan and are designed for inbound traffic from a VNet; however, the question asks for access from a specific VNet, and while private endpoints can achieve this, the correct combination for outbound VNet integration and inbound NSG control is described in option C, and private endpoints alone do not provide the same level of outbound traffic control as VNet integration with NSGs.

Practice this question →

30

MCQeasy

You have an Azure Storage account that hosts blobs for a public website. You need to grant a partner application read-only access to a specific container for 24 hours without using a storage account key. What should you create?

A.A shared access signature (SAS) URI with read permission and expiry set to 24 hours

B.An access policy for the container with read permission

C.A storage account key

D.A managed identity for the partner application

AnswerA

A Shared Access Signature (SAS) URI provides delegated access to Azure Storage resources with granular control over permissions and a defined validity period. By generating a SAS with read-only permission and a 24-hour expiry, the partner receives a time-limited URI that grants access only for the specified duration, minimizing security risks associated with long-term credentials and avoiding exposure of the sensitive storage account key. This approach perfectly aligns with the requirement for temporary, scoped external access.

Why this answer

A shared access signature (SAS) URI with read permission and a 24-hour expiry provides time-limited, delegated access to a specific container without exposing the storage account key. This meets the requirement for read-only access for exactly 24 hours, as the SAS token can be scoped to a single container and its permissions set to read.

Exam trap

The trap here is that candidates often confuse a stored access policy (Option B) with a SAS, not realizing that a policy alone does not grant access—it only defines constraints that a SAS must reference, and without a SAS token, no access is provided.

How to eliminate wrong answers

Option B is wrong because an access policy (stored access policy) alone does not grant access; it must be combined with a SAS to enforce permissions and expiry, and it cannot be used directly to grant time-limited access without a SAS token. Option C is wrong because using a storage account key would grant full administrative access to the entire storage account, not read-only access to a specific container, and violates the requirement to avoid using a storage account key. Option D is wrong because a managed identity is used for Azure resources to authenticate to Azure services without credentials, but it cannot be assigned to an external partner application and does not provide a time-limited, scoped access token for a specific container.

Practice this question →

31

Multi-Selecthard

An API receives JWT access tokens from Microsoft Entra ID. Which two token properties should the API validate before accepting a request?

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 (the 'iss' claim) confirms the token originated from the expected Microsoft Entra ID tenant, preventing tokens from unauthorized identity providers. Concurrently, verifying the token's cryptographic signature, using the issuer's public key, ensures its integrity and authenticity. This critical step guarantees the token has not been tampered with since it was issued and genuinely came from the claimed authority, establishing trust in the token's source.

Why this answer

The API must validate the token's issuer (iss) claim to ensure it matches the trusted Microsoft Entra ID tenant's issuer URL, confirming the token's origin. It must also verify the token's cryptographic signature to ensure it hasn't been tampered with. Additionally, the API must validate the token's audience (aud) claim, ensuring it matches the API's own Application ID URI or client ID, which confirms the token was intended for this specific API.

Exam trap

The trap here is that candidates confuse optional user claims (like display name) with mandatory security claims (iss, aud, signature), or think token transport method (query string vs. header) is a validation property rather than a security best practice.

Practice this question →

32

MCQeasy

You are building an API that needs to validate JWT tokens issued by Microsoft Entra ID. The API is registered as an application in Entra ID. Which endpoint should the API use to obtain the signing keys?

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

B.https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize

C.https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

D.https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys

AnswerD

This endpoint, often referred to as the JSON Web Key Set (JWKS) endpoint, directly returns a set of public cryptographic keys in JSON Web Key (JWK) format. These public keys are precisely what an API needs to cryptographically verify the signature of a received JWT. By using these keys, the API can confirm that the token was issued by the trusted identity provider and has not been tampered with, ensuring its authenticity and integrity.

Why this answer

The endpoint `https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys` is the Microsoft Entra ID (formerly Azure AD) v2.0 JWKS (JSON Web Key Set) URI, which returns the public signing keys used to validate the signature of JWT tokens. The API must fetch these keys to verify the token's integrity and authenticity, as the keys are rotated periodically.

Exam trap

The trap here is that candidates often confuse the OpenID Connect metadata endpoint (Option C) with the actual key endpoint, not realizing that the metadata only provides a URL to the keys, and the exam expects you to know the specific `/discovery/v2.0/keys` endpoint for direct key retrieval.

How to eliminate wrong answers

Option A is wrong because the `/oauth2/v2.0/token` endpoint is used to obtain access tokens, not signing keys. Option B is wrong because the `/oauth2/v2.0/authorize` endpoint is used for user authorization and consent flows, not for key retrieval. Option C is wrong because the `/.well-known/openid-configuration` endpoint returns the OpenID Connect discovery metadata (including the `jwks_uri` field), but it does not directly return the signing keys; the actual keys must be fetched from the URI specified in that metadata (which is the `/discovery/v2.0/keys` endpoint).

Practice this question →

33

MCQeasy

You are a developer for a startup that is building a real-time chat application on Azure. The application uses Azure Web PubSub to broadcast messages to clients. The security team requires that only authenticated users can connect to the Web PubSub service. You plan to use Microsoft Entra ID for authentication. The application backend is an Azure Function that generates access tokens. What is the correct course of action to secure the Web PubSub service?

A.Configure the Web PubSub service to use a shared access key and distribute it to clients via the Function.

B.Enable managed identity for the Azure Function, assign it the 'Web PubSub Service Owner' role, and use the Web PubSub SDK to generate a client access token after authenticating the user.

C.Set the Web PubSub service's 'Anonymous mode' to 'Allow anonymous connections' and authenticate users at the application level.

D.Use the Web PubSub connection string (access key) in the Function to generate a client token, and store the connection string in Azure Key Vault.

AnswerB

This is the correct and most secure approach. Enabling a managed identity for the Azure Function allows it to authenticate with Azure Entra ID and subsequently with the Web PubSub service without storing any credentials. Assigning the 'Web PubSub Service Owner' role grants the Function the necessary permissions to generate secure, time-limited client access tokens for authenticated users, adhering to the principle of least privilege.

Why this answer

It uses managed identity to securely authenticate the Azure Function to the Web PubSub service without exposing any secrets. The Function then generates a client access token only after the user is authenticated via Microsoft Entra ID, ensuring that only authenticated users can connect to the Web PubSub service. This approach follows the principle of least privilege and avoids distributing shared access keys or connection strings to clients.

Exam trap

The trap here is that candidates often confuse generating a client access token from a connection string (Option D) with using managed identity (Option B), not realizing that the connection string is a static secret that does not enforce user-level authentication, whereas managed identity enables secure, identity-based token generation after user authentication.

How to eliminate wrong answers

Option A is wrong because distributing a shared access key to clients exposes the key, allowing anyone with the key to connect directly to the Web PubSub service without authentication. Option C is wrong because setting 'Anonymous mode' to 'Allow anonymous connections' bypasses authentication entirely, contradicting the requirement that only authenticated users can connect. Option D is wrong because using the connection string (access key) in the Function still requires storing a secret, and generating a client token from it does not enforce user authentication before token issuance; the token could be generated for any unauthenticated request.

Practice this question →

34

MCQeasy

You are developing a web app that uses Azure AD B2C for customer identity. The app must allow users to sign in with their social media accounts like Facebook and Google. Which Azure AD B2C policy type should you configure?

A.Profile editing policy

B.Sign-up and sign-in policy

C.Password reset policy

D.Conditional access policy

AnswerB

An Azure AD B2C sign-up and sign-in policy is the foundational user flow that orchestrates the entire user journey for both new user registration and existing user authentication. It is within this policy type that you configure and enable various identity providers, including social identity providers like Google or Facebook, allowing users to choose their preferred method for creating an account or signing into the application. This policy directly enables the required functionality for social sign-in.

Why this answer

The sign-up and sign-in policy (now called a user flow in the Azure portal) is the correct choice because it is the Azure AD B2C policy type specifically designed to handle both user registration and authentication in a single flow. This policy can be configured to include social identity providers like Facebook and Google, allowing users to sign in using those accounts. It orchestrates the OAuth 2.0 and OpenID Connect protocols to redirect users to the social provider's authorization endpoint and then process the returned tokens.

Exam trap

Candidates might mistakenly choose profile editing or password reset policies, which serve different purposes (post-authentication profile management and password recovery for local accounts, respectively) and are not designed for initial sign-up or sign-in with social identity providers. Conditional access policies are also not the correct mechanism for configuring identity providers in B2C. The key is to understand that the 'Sign-up and sign-in' user flow is specifically designed to integrate social identity providers for the primary authentication journey.

How to eliminate wrong answers

Option A is wrong because a profile editing policy is used only for allowing authenticated users to modify their account attributes (e.g., display name, city), not for initial sign-in or registration with social providers. Option C is wrong because a password reset policy is specifically for resetting a forgotten password via email verification or other methods; it does not handle social identity provider authentication. Option D is wrong because conditional access policy is a security feature that evaluates risk signals (e.g., location, device state) to grant or block access after authentication, not a policy type for configuring sign-in with social identity providers.

Practice this question →

35

MCQmedium

Your company uses Microsoft Entra ID for identity management. You need to ensure that users accessing a line-of-business application from unmanaged devices must complete a multi-factor authentication (MFA) challenge. What should you configure?

A.Create a Conditional Access policy that requires MFA for users accessing the application, with a condition for 'Device state' set to 'Unmanaged'.

B.Configure a device compliance policy in Microsoft Intune.

C.Create a Conditional Access policy that requires MFA for all users.

D.Enable risk-based Conditional Access in Microsoft Entra ID Protection.

AnswerA

This is the correct approach because Microsoft Entra Conditional Access policies are specifically designed to enforce access controls based on various conditions, including the application being accessed and the state of the device. By configuring a policy to target the specific application and setting the 'Device state' condition to 'Unmanaged' (which typically means devices that are not Azure AD joined, Hybrid Azure AD joined, or Azure AD registered), you can precisely require multi-factor authentication (MFA) only when users attempt to access that application from a device not managed by the organization.

Why this answer

A Conditional Access policy in Microsoft Entra ID allows you to target specific applications and require MFA based on the device state condition. By setting the device state condition to 'Unmanaged', the policy applies only to devices that are not managed by your organization (e.g., not joined or compliant with Intune), ensuring that users on unmanaged devices must complete an MFA challenge before accessing the line-of-business application.

Exam trap

The trap here is that candidates often confuse device compliance policies (Intune) with Conditional Access policies, or they assume a blanket MFA policy for all users is sufficient, missing the specific device state condition that targets unmanaged devices.

How to eliminate wrong answers

Option B is wrong because a device compliance policy in Microsoft Intune defines the security requirements for managed devices (e.g., encryption, OS version) but does not enforce MFA based on device state; it is used for conditional access compliance checks, not for triggering MFA directly. Option C is wrong because creating a Conditional Access policy that requires MFA for all users would apply to every user regardless of device state, which does not meet the requirement to target only unmanaged devices. Option D is wrong because risk-based Conditional Access in Microsoft Entra ID Protection triggers MFA based on user or sign-in risk levels (e.g., leaked credentials, anonymous IP), not on the device state being unmanaged.

Practice this question →

36

MCQmedium

A background service must call Microsoft Graph without a signed-in user. Which Microsoft identity platform permission model is required?

A.Password hash synchronization

B.Delegated permissions only

C.Device code flow

D.Application permissions with client credentials flow

AnswerD

Application permissions, combined with the client credentials flow, are the correct approach for a background service (daemon application) that needs to call Microsoft Graph without a signed-in user. Application permissions are granted directly to the application's service principal, allowing it to act as itself and access data across all users or specific resources, independent of any user context. The client credentials flow is the OAuth 2.0 grant type where the application authenticates directly to Azure AD using its client ID and a client secret or certificate to obtain an access token.

Why this answer

When a background service or daemon calls Microsoft Graph without a signed-in user, it must authenticate as itself using application permissions (app roles) rather than delegated permissions. The client credentials flow (OAuth 2.0 grant type) allows the service to obtain an access token using its own credentials (client ID and client secret or certificate), without any user interaction. This flow is designed for server-to-server scenarios where the application acts on its own behalf.

Exam trap

The trap here is that candidates often confuse delegated permissions (which require a user) with application permissions (which do not), and mistakenly choose the device code flow thinking it works without a user, when in fact it still requires user authentication via a browser.

How to eliminate wrong answers

Option A is wrong because password hash synchronization is an Azure AD Connect feature for syncing user password hashes to Azure AD for hybrid identity, not a permission model for calling Microsoft Graph. Option B is wrong because delegated permissions require a signed-in user to delegate the application's permissions to act on the user's behalf, which contradicts the requirement of no signed-in user. Option C is wrong because the device code flow is an OAuth 2.0 flow designed for devices with limited input capabilities (e.g., IoT, CLI) that still requires a signed-in user to authenticate via a browser; it does not support unattended background service scenarios.

Practice this question →

37

MCQmedium

A background service must call Microsoft Graph without a signed-in user. Which Microsoft identity platform permission model is required? The team wants the control to be enforceable during normal operations.

A.Password hash synchronization

B.Delegated permissions only

C.Device code flow

D.Application permissions with client credentials flow

AnswerD

For a background service operating without a signed-in user, application permissions are essential as they allow the application itself to call Microsoft Graph. The client credentials flow is the appropriate OAuth 2.0 grant type for this scenario, enabling the application to authenticate using its own client ID and secret or certificate to acquire an access token. This token represents the application's identity, allowing it to perform actions based on the administrator-consented permissions, independent of any user context.

Why this answer

The scenario requires an unattended background service to call Microsoft Graph without a signed-in user. Application permissions, combined with the client credentials flow (OAuth 2.0 grant type), allow the service to authenticate as itself using a client ID and client secret or certificate, obtaining an access token with pre-authorized application-level permissions. This model enforces control during normal operations because the permissions are granted directly to the application and cannot be delegated by a user, ensuring consistent access regardless of user presence.

Exam trap

The trap here is that candidates often confuse delegated permissions (which require a user) with application permissions (which do not), and mistakenly choose the device code flow thinking it works without a user, when in fact it still requires interactive user authentication.

How to eliminate wrong answers

Option A is wrong because password hash synchronization is an Azure AD Connect feature for syncing user password hashes for hybrid identity, not a permission model for calling Microsoft Graph. Option B is wrong because delegated permissions require a signed-in user to delegate their privileges to the app; they cannot be used in a background service without a user context. Option C is wrong because the device code flow is designed for devices with limited input capabilities and still requires a signed-in user to authenticate interactively on another device, making it unsuitable for an unattended background service.

Practice this question →

38

MCQhard

Your company has several Azure subscriptions, and you need to create a custom role that allows security engineers to start and stop Azure virtual machines but not delete them or modify their network interfaces. The role must be scoped to a specific resource group. How should you define this custom role?

A.Assign the built-in Contributor role to the resource group.

B.Create a custom role with allowed actions for start and stop, and explicitly deny delete actions using NotActions.

C.Use Azure Policy to prevent deletion of VMs in that resource group.

D.Add the engineers to an Microsoft Entra ID administrative unit and assign permissions for VM operations.

AnswerB

Creating a custom Azure RBAC role allows for granular control over permissions, precisely aligning with the principle of least privilege. This role can be configured to include specific actions like 'Microsoft.Compute/virtualMachines/start/action' and 'Microsoft.Compute/virtualMachines/stop/action' within its 'Actions' property. Crucially, by adding 'Microsoft.Compute/virtualMachines/delete' to the 'NotActions' property, the role explicitly denies the ability to delete virtual machines, even if other broad permissions might implicitly grant it. This combination provides the exact required functionality while preventing unintended deletions.

Why this answer

Custom roles in Azure RBAC allow you to define granular permissions using Actions and NotActions. To allow start/stop but prevent delete, you can define a broad action like 'Microsoft.Compute/virtualMachines/*' (which includes start/stop and delete) and then use 'NotActions' to explicitly exclude 'Microsoft.Compute/virtualMachines/delete'. Since network interface modifications fall under the 'Microsoft.Network' resource provider, they are not included in 'Microsoft.Compute/virtualMachines/*' and thus are implicitly denied by this role definition.

Scoping the role to a specific resource group ensures the permissions apply only to that resource group, meeting the requirement.

Exam trap

The trap here is that candidates often confuse Azure Policy with RBAC, thinking Policy can control runtime actions like start/stop, when in fact Policy only governs resource configuration and compliance, not operational permissions.

How to eliminate wrong answers

Option A is wrong because the built-in Contributor role grants full management access, including the ability to delete VMs and modify network interfaces, which violates the requirement to prevent deletion and network interface changes. Option C is wrong because Azure Policy is used to enforce compliance rules (e.g., tagging, location restrictions) and cannot directly grant or deny RBAC permissions for specific actions like start/stop; it audits or prevents resource creation but does not control runtime operations. Option D is wrong because Microsoft Entra ID administrative units manage administrative scope for user and group management, not Azure resource permissions; RBAC roles are required for VM operations, and administrative units do not provide a mechanism to assign start/stop permissions.

Practice this question →

39

MCQhard

You need to restrict access to an Azure Storage blob container so that only users from your Microsoft Entra tenant can read blobs, and deny all other access including anonymous traffic. What should you configure?

A.Generate a shared access signature (SAS) for the container

B.Set public access level to private and assign RBAC roles to users

C.Configure a network firewall to allow only your tenant's IP range

D.Use storage account access keys and distribute them to users

AnswerB

This ensures only authenticated users from your tenant can access blobs.

Why this answer

Setting the public access level to private disables anonymous access, and assigning RBAC roles such as Storage Blob Data Reader to Entra ID users ensures only authenticated users from your tenant can read blobs. Option A is incorrect because a SAS token can be shared externally, allowing access to users outside your tenant. Option C is incorrect because a network firewall only restricts by IP address and does not authenticate users; anonymous traffic from allowed IPs would still be permitted.

Option D is incorrect because storage account access keys grant full administrative access to the account, not read-only access for specific users, and distributing keys is insecure.

Practice this question →

40

MCQhard

A company has an Azure Kubernetes Service (AKS) cluster. They want to ensure that pods can securely access Azure SQL Database without using connection strings or secrets. The solution must use the principle of least privilege. What should they implement?

A.Use the Azure Key Vault Provider for Secrets Store CSI Driver to mount secrets into the pod.

B.Store the SQL connection string in a Kubernetes secret and mount it as a volume in the pod.

C.Enable Azure AD Workload Identity for AKS and assign a managed identity to the pod that has access to Azure SQL Database.

D.Configure Azure SQL Database firewall to allow the AKS cluster's IP addresses.

AnswerC

Pod-managed identity allows the pod to authenticate to Azure SQL without secrets, using a managed identity.

Why this answer

Azure AD Workload Identity allows you to assign a user-assigned managed identity to a pod in AKS. This identity can be granted specific permissions (e.g., db_datareader) on Azure SQL Database using Azure AD authentication, eliminating the need for connection strings or secrets. The pod authenticates directly via the managed identity token, adhering to the principle of least privilege by scoping access to only the required database roles.

Exam trap

The trap here is that candidates often confuse Azure AD Workload Identity with managed identity for AKS cluster itself (which is for cluster-level resources, not per-pod), or they assume that Key Vault integration (Option A) eliminates secrets entirely when it actually just moves them to a different store, still requiring secret material to be mounted.

How to eliminate wrong answers

Option A is wrong because the Azure Key Vault Provider for Secrets Store CSI Driver still requires storing a connection string or secret in Key Vault, which does not eliminate secrets entirely and introduces a dependency on a secret store, violating the 'without using connection strings or secrets' requirement. Option B is wrong because storing the SQL connection string in a Kubernetes secret and mounting it as a volume still exposes the secret in the cluster, violating the 'without using secrets' constraint and the principle of least privilege. Option D is wrong because configuring the Azure SQL Database firewall to allow the AKS cluster's IP addresses does not provide identity-based access control; it relies on network-level security, which is not least privilege (all pods share the same IP range) and does not eliminate connection strings or secrets.

Practice this question →

41

Multi-Selectmedium

Which TWO actions should you take to secure an Azure Function app that is triggered by an HTTP request? (Choose two.)

Select 2 answers

A.Use function-level authorization keys (function or admin keys) for all HTTP triggers.

B.Enable App Service Authentication and configure Microsoft Entra ID as the identity provider.

C.Store connection strings and secrets in Azure Key Vault and reference them from the function app settings using Key Vault references.

D.Set the function app's public access to 'Off' and use virtual network integration.

E.Enable Cross-Origin Resource Sharing (CORS) with allowed origins set to '*'.

AnswersB, C

Enabling App Service Authentication, often called "Easy Auth," and configuring Microsoft Entra ID as the identity provider is a robust security measure. This offloads authentication to the platform, ensuring that only requests with valid Entra ID tokens are allowed to reach the function code. It provides strong identity-based authentication and authorization, integrating with corporate directories and conditional access policies to secure access.

Why this answer

Enabling App Service Authentication with Microsoft Entra ID (formerly Azure AD) provides a managed identity layer that validates JWT tokens from Microsoft Entra ID before the request reaches your function code. This ensures only authenticated users or applications can invoke the HTTP-triggered function, offloading token validation and session management from your code. Option C is correct because storing secrets in Azure Key Vault and referencing them via Key Vault references (syntax @Microsoft.KeyVault(SecretUri=...)) in the function app settings prevents hardcoding credentials in configuration files or source code, aligning with the principle of least privilege and secure secret management.

Exam trap

The trap here is that candidates often confuse network-level security (like virtual network integration) with application-level authentication, or they mistakenly believe that CORS or shared keys provide sufficient security for HTTP-triggered functions, when in fact Microsoft Entra ID authentication is the recommended approach for identity-based access control in Azure Functions.

Practice this question →

42

MCQhard

You need to create a custom RBAC role that allows a security group to start and stop Azure virtual machines in a specific resource group, but not delete them or modify their network interfaces. Which set of actions should you include in the role definition?

A.Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/deallocate/action

B.Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/powerOff/action

C.Microsoft.Compute/virtualMachines/restart/action and Microsoft.Compute/virtualMachines/deallocate/action

D.Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/write

AnswerA

This combination correctly grants the precise permissions required to start and stop Azure Virtual Machines. The Microsoft.Compute/virtualMachines/start/action allows powering on a VM from a stopped or deallocated state. Conversely, Microsoft.Compute/virtualMachines/deallocate/action stops the VM and releases its associated compute resources, which is the standard and most cost-effective "stop" operation in Azure. These actions adhere to the principle of least privilege by not including permissions for deletion or configuration changes.

Why this answer

The custom RBAC role needs to allow starting and stopping (deallocating) VMs without permitting deletion or network interface modifications. The actions Microsoft.Compute/virtualMachines/start/action and Microsoft.Compute/virtualMachines/deallocate/action precisely grant the ability to start a VM and deallocate it (which stops and releases resources), while excluding delete or write permissions on the VM or its network interfaces.

Exam trap

The trap here is that candidates confuse 'powerOff' (which stops the VM but keeps it allocated and billable) with 'deallocate' (which stops and releases resources), leading them to choose Option B instead of the correct deallocate action.

How to eliminate wrong answers

Option B is wrong because Microsoft.Compute/virtualMachines/powerOff/action only stops the VM but does not deallocate it, leaving the VM in a 'stopped' state that still incurs compute costs; the question requires the ability to stop (deallocate) the VM to release resources. Option C is wrong because Microsoft.Compute/virtualMachines/restart/action is not a stop operation—it restarts the VM, which does not fulfill the requirement to stop the VM. Option D is wrong because Microsoft.Compute/virtualMachines/write grants the ability to modify the VM resource, including deleting it or changing its configuration, which violates the requirement to prevent deletion or modification of network interfaces.

Practice this question →

43

MCQmedium

You have multiple Azure virtual machines that need to access the same Azure Key Vault to retrieve certificates. You want to minimize administrative overhead while ensuring each VM can authenticate without managing credentials. Which identity type should you use?

A.System-assigned managed identity on each VM

B.User-assigned managed identity assigned to each VM

C.Service principal with client secret stored in each VM

D.Storage account key

AnswerB

A user-assigned managed identity is a standalone Azure resource that can be created once and then assigned to multiple Azure VMs. This approach centralizes identity management, as you only need to grant access permissions to the target resource, such as Azure Key Vault, to this single user-assigned identity. All assigned VMs can then leverage this identity, drastically reducing administrative overhead and simplifying permission management across your fleet of virtual machines.

Why this answer

A user-assigned managed identity can be created once and then assigned to multiple Azure VMs, allowing all of them to authenticate to the same Key Vault without storing any credentials. This minimizes administrative overhead compared to managing separate system-assigned identities or service principals, as the identity is independent of any single VM's lifecycle and can be reused across resources.

Exam trap

The trap here is that candidates often choose system-assigned managed identities (Option A) because they seem simpler per-VM, but they overlook the administrative overhead of managing separate access policies for each VM when multiple VMs require identical access to the same Key Vault.

How to eliminate wrong answers

Option A is wrong because system-assigned managed identities are tied to the lifecycle of each individual VM, meaning you would need to configure Key Vault access policies separately for each VM's identity, increasing administrative overhead when multiple VMs need identical access. Option C is wrong because storing a service principal's client secret on each VM reintroduces credential management overhead and security risks, contradicting the goal of minimizing administrative overhead and avoiding credential management. Option D is wrong because a storage account key is used for authenticating to Azure Storage, not Azure Key Vault, and it would require storing and rotating a shared secret across all VMs, which is insecure and high-overhead.

Practice this question →

44

MCQmedium

Your company uses Azure App Service to host a web application. You need to allow only authenticated users from your Microsoft Entra ID tenant to access the app, without writing any authentication code. Which feature should you configure?

A.Azure App Service Authentication (EasyAuth) with Microsoft Entra ID as identity provider.

B.IP restrictions in the app’s web.config.

C.Client certificate authentication.

D.Shared access signatures (SAS) for the app URL.

AnswerA

Azure App Service Authentication, often referred to as EasyAuth, is the correct choice because it provides a built-in, no-code solution for integrating identity providers like Microsoft Entra ID directly into your web application. It automatically handles the entire authentication flow, including redirecting unauthenticated requests, token acquisition, validation, and session management. This offloads complex security concerns from the application code, allowing developers to secure their web applications with minimal effort and without modifying the application's codebase.

Why this answer

Azure App Service Authentication (EasyAuth) is the correct feature because it provides a built-in, code-free way to authenticate users by integrating with Microsoft Entra ID (formerly Azure AD). When configured, the App Service automatically validates tokens and redirects unauthenticated users to the identity provider, enforcing authentication at the platform level without requiring any changes to the application code.

Exam trap

The trap here is that candidates often confuse network-level access controls (like IP restrictions) with identity-based authentication, or mistakenly think SAS tokens can secure a web app URL, when in fact SAS are strictly for Azure Storage access and have no role in user authentication for App Service.

How to eliminate wrong answers

Option B is wrong because IP restrictions in web.config control network-level access based on source IP addresses, not user authentication; they cannot verify a user's identity or enforce Entra ID authentication. Option C is wrong because client certificate authentication requires the application to explicitly validate the certificate in code and does not integrate with Microsoft Entra ID for user authentication. Option D is wrong because Shared Access Signatures (SAS) are used to grant delegated access to Azure Storage resources (e.g., blobs, queues), not to authenticate users accessing a web application URL.

Practice this question →

45

Drag & Dropmedium

Arrange the steps to create and use a shared access signature (SAS) for an Azure Storage blob in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First create storage and container, upload blob, generate SAS, construct URL, then access.

Practice this question →

46

MCQmedium

A company stores secrets (e.g., connection strings) in Azure Key Vault and needs them automatically rotated every 90 days. Which solution should they implement?

A.Configure Key Vault access policies to enforce rotation

B.Enable Key Vault firewall to limit access

C.Use Event Grid to trigger an Azure Function or Automation runbook that rotates the secret

D.Enable soft-delete on the vault

AnswerC

This is the recommended and most robust pattern for automating secret rotation. Azure Key Vault integrates with Azure Event Grid, which can publish events such as 'SecretNearExpiry' when a secret is approaching its expiration date. Subscribing to these events allows an Azure Function or an Azure Automation runbook to be automatically triggered. This triggered logic can then programmatically generate a new secret, update it in the Key Vault, and subsequently update any applications or services that consume that secret, providing a fully automated and proactive rotation solution.

Why this answer

Azure Key Vault does not natively support automatic secret rotation; you must implement a custom solution using Event Grid to detect expiration events and trigger an Azure Function or Automation runbook that generates a new secret and updates the vault. This pattern leverages Key Vault's eventing capabilities to automate the rotation workflow without manual intervention.

Exam trap

The trap here is that candidates assume Key Vault has a built-in rotation feature, but Azure Key Vault only stores secrets and requires an external automation trigger (Event Grid + Azure Function) to implement rotation logic.

How to eliminate wrong answers

Option A is wrong because Key Vault access policies control permissions (who can read/write secrets), not rotation logic; they cannot enforce a schedule or automate secret renewal. Option B is wrong because enabling the Key Vault firewall restricts network access to the vault for security, but does not implement any rotation mechanism. Option D is wrong because soft-delete protects against accidental deletion by retaining deleted secrets for a configurable retention period, but it does not automate rotation or renewal of secrets.

Practice this question →

47

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?

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

Enabling managed identity for an Azure-hosted application provides a highly secure and recommended method for authenticating to Azure resources like Key Vault. This approach eliminates the need for developers to manage, store, or rotate any credentials or client secrets within their code or configuration. By assigning the managed identity specific, least-privilege access roles to the target Key Vault, the application can securely retrieve certificates while adhering to robust security principles, significantly reducing the attack surface.

Why this answer

Azure App Service supports Managed Identity, which allows the application to authenticate to Key Vault without storing any credentials in code or configuration. By enabling a system-assigned or user-assigned managed identity and granting it least-privilege access (e.g., via an access policy with `Get` permission for secrets), the app can securely retrieve certificates using the Azure Identity SDK's `DefaultAzureCredential` class, which automatically obtains an access token from Azure AD.

Exam trap

The trap here is that candidates might think storing a client secret in source control is acceptable if the repo is private, but Azure explicitly forbids this in security best practices, and the question requires 'avoid stored credentials' entirely.

How to eliminate wrong answers

Option A is wrong because using a shared administrator account violates the principle of least privilege and introduces a security risk; credentials would need to be stored or hardcoded, defeating the goal of avoiding stored credentials. Option B is wrong because storing a client secret in source control exposes it to unauthorized access, breaches security best practices, and contradicts the requirement to avoid stored credentials. Option D is wrong because disabling authentication for the target resource (Key Vault) would allow anonymous access, which is a severe security vulnerability and not a valid design for production workloads.

Practice this question →

48

MCQhard

A healthcare organization uses Azure API Management (APIM) to expose FHIR APIs to external partners. The FHIR backend is an Azure API for FHIR that requires OAuth 2.0 tokens from Microsoft Entra ID. APIM must validate tokens before forwarding requests to the backend. The organization also needs to rate-limit requests per subscription key and log all requests to Azure Monitor for audit. Which combination of APIM policies should be implemented?

A.Use validate-jwt, set-header to add the subscription key, and log-to-event-hub.

B.Use check-header to verify the token, rate-limit to throttle requests, and log-to-event-hub to send logs.

C.Use validate-jwt to validate the token, rate-limit to throttle requests per subscription key, and log-to-event-hub to send logs.

D.Use validate-jwt to validate the token, quota to limit total requests, and log-to-event-hub.

AnswerC

This option correctly combines policies to meet all specified requirements. The `validate-jwt` policy is essential for securely verifying the authenticity, integrity, and claims of the incoming JWT, ensuring only legitimate requests proceed. The `rate-limit` policy effectively throttles requests on a per-subscription-key basis, preventing abuse and ensuring fair resource allocation. Finally, `log-to-event-hub` provides a robust mechanism for asynchronously sending detailed logs to Azure Event Hubs for monitoring, auditing, and analytics.

Why this answer

Validate-jwt is the appropriate policy to validate OAuth 2.0 tokens from Microsoft Entra ID before forwarding requests to the FHIR backend. The rate-limit policy enforces throttling per subscription key, which is the standard way to rate-limit based on API Management subscription keys. The log-to-event-hub policy sends logs to Azure Monitor via Event Hubs for audit purposes, meeting all requirements.

Exam trap

The trap here is confusing rate-limit (sliding window throttling per key) with quota (fixed total limit over a period), and assuming check-header can validate JWT tokens when it only checks for header existence, not cryptographic validity.

How to eliminate wrong answers

Option A is wrong because set-header to add the subscription key is unnecessary and does not perform token validation; the subscription key is already present in the request and is not used for OAuth token validation. Option B is wrong because check-header only verifies the presence of a header, not the validity of a JWT token; it cannot validate OAuth 2.0 tokens from Entra ID. Option D is wrong because quota limits total requests over a time period (e.g., daily/monthly) rather than rate-limiting per subscription key; the requirement specifically asks for rate-limiting per subscription key, which rate-limit handles by allowing a burst of requests within a sliding window.

Practice this question →

49

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?

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

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

Why this answer

Managed identity in Azure App Service allows the application to authenticate to Azure Storage without storing any credentials in code or configuration. By enabling a system-assigned or user-assigned managed identity, the app obtains an Azure AD token automatically, which is used to access the storage resource. Granting the managed identity only the required permissions (e.g., 'Storage Blob Data Reader' for read-only access) enforces least-privilege access, eliminating the need for stored secrets.

Exam trap

The trap here is that candidates may think storing a client secret in a configuration file (Option C) is acceptable if it's encrypted or in a secure location, but the question explicitly requires avoiding stored credentials, making managed identity the only correct choice.

How to eliminate wrong answers

Option A is wrong because using a shared administrator account violates least-privilege principles and requires storing credentials, which contradicts the requirement to avoid stored credentials. Option B is wrong because disabling authentication for the target resource would expose the storage to anonymous access, breaking security and least-privilege requirements. Option C is wrong because storing a client secret in source control is a security anti-pattern; it exposes the secret to anyone with repository access and violates the 'no stored credentials' requirement.

Practice this question →

50

MCQhard

You are developing a web API that must authenticate requests using Microsoft Entra ID (Microsoft Entra ID) and OAuth 2.0 bearer tokens. You want to validate the token in your API code. Which library should you use?

A.Microsoft Authentication Library (MSAL)

B.Microsoft.Identity.Web

C.ADAL.NET

D.Azure.Identity

AnswerB

Microsoft.Identity.Web is the recommended and most current library for integrating Microsoft identity platform authentication and authorization into ASP.NET Core web APIs and web applications. It provides a comprehensive set of middleware and helper classes that significantly simplify the process of validating incoming bearer tokens issued by Microsoft Entra ID. This includes automatically handling token signature verification, issuer and audience validation, lifetime checks, and extracting claims, thereby ensuring robust security for API endpoints.

Why this answer

Microsoft.Identity.Web is the recommended library for integrating ASP.NET Core web APIs with Microsoft Entra ID. It provides built-in token validation, policy enforcement, and handles the OAuth 2.0 bearer token flow, including JWT validation, issuer signing keys, and audience checks, without requiring manual configuration of middleware.

Exam trap

The trap here is that candidates confuse token acquisition libraries (MSAL, Azure.Identity) with token validation libraries, leading them to pick MSAL because it is commonly associated with Entra ID authentication, even though it does not validate bearer tokens in an API.

How to eliminate wrong answers

Option A is wrong because MSAL is a client-side library used for acquiring tokens (e.g., from users or daemons), not for validating incoming bearer tokens in a web API. Option C is wrong because ADAL.NET is deprecated and uses the older Azure AD v1.0 endpoint; it lacks support for modern features like Microsoft Entra ID and the Microsoft identity platform. Option D is wrong because Azure.Identity is a credential abstraction library for authenticating to Azure services (e.g., DefaultAzureCredential), not for validating OAuth 2.0 bearer tokens in an API.

Practice this question →

51

MCQhard

A developer deleted a secret from Azure Key Vault with soft-delete and purge protection enabled (retention 90 days). After 50 days, the secret is needed again. What is the correct recovery method?

A.Purge the secret and then restore from a backup

B.Recover the secret using Azure CLI 'az keyvault secret recover'

C.Recreate the secret with the same name

D.Use an Azure Resource Manager template to undelete the secret

AnswerB

Azure Key Vault's soft-delete feature retains deleted secrets for a specified retention period, typically 90 days by default, making them recoverable. The `az keyvault secret recover` command is specifically designed to transition a soft-deleted secret back into an active state within this retention window. This command restores the secret with all its original properties, versions, and access policies, effectively reversing the deletion operation.

Why this answer

Azure Key Vault with soft-delete and purge protection enabled retains deleted secrets for the specified retention period (90 days in this case). Since only 50 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 its original state without data loss.

Exam trap

The trap here is that candidates may confuse soft-delete recovery with backup/restore or assume that recreating the secret with the same name is possible, not realizing that soft-deleted secrets block name reuse until purged or the retention period ends.

How to eliminate wrong answers

Option A is wrong because purging the secret permanently deletes it, making recovery impossible without a backup; the correct action is to recover the soft-deleted secret, not purge it. Option C is wrong because recreating the secret with the same name would fail due to a naming conflict with the soft-deleted secret, which still exists in a hidden state. Option D is wrong because Azure Resource Manager templates cannot undelete secrets; they are used for infrastructure deployment, not for recovering soft-deleted Key Vault objects.

Practice this question →

52

MCQmedium

A company uses Azure App Service to host a web application. They need to ensure that only authenticated users from their Microsoft Entra ID tenant can access the app. They also want to prevent unauthenticated requests from reaching the app code. Which configuration should they implement?

A.Configure IP restrictions in the web.config to allow only the company's office IP range.

B.Implement a custom middleware in the app to validate tokens from Microsoft Entra ID.

C.Assign users to Microsoft Entra ID App Roles and check roles in the app.

D.Enable App Service Authentication with Microsoft Entra ID as the identity provider and set 'Action to take when request is not authenticated' to 'Log in with Microsoft Entra ID'.

AnswerD

Enabling App Service Authentication (often called Easy Auth) with Microsoft Entra ID offloads authentication concerns to the platform. By setting 'Action to take when request is not authenticated' to 'Log in with Microsoft Entra ID', the App Service acts as a gateway, automatically redirecting all unauthenticated requests to the Microsoft Entra ID login page. This ensures that no unauthenticated requests reach the application code, as the platform handles token validation and user session management transparently, enhancing security and reducing application complexity.

Why this answer

Enabling App Service Authentication (EasyAuth) with Microsoft Entra ID as the identity provider and setting 'Action to take when request is not authenticated' to 'Log in with Microsoft Entra ID' ensures that all unauthenticated requests are redirected to Microsoft Entra ID for authentication before they reach the application code. This configuration blocks unauthenticated requests at the platform layer, preventing any unauthenticated traffic from hitting the app's runtime, which meets the requirement of keeping unauthenticated requests away from the app code.

Exam trap

The trap here is that candidates often confuse authentication (proving identity) with authorization (checking permissions) and incorrectly choose option C, thinking role assignment alone blocks unauthenticated users, but App Roles only work after authentication and do not prevent unauthenticated requests from reaching the app code.

How to eliminate wrong answers

Option A is wrong because IP restrictions in web.config only filter based on source IP addresses, not authentication; they do not validate Microsoft Entra ID tokens or ensure the user is from the correct tenant, and unauthenticated users from allowed IPs could still access the app. Option B is wrong because implementing custom middleware to validate tokens would require the app code to handle authentication, which contradicts the requirement to prevent unauthenticated requests from reaching the app code; the middleware runs within the app's process, so unauthenticated requests still reach the app. Option C is wrong because assigning users to App Roles and checking roles in the app only controls authorization after authentication, but does not prevent unauthenticated requests from reaching the app code; it assumes authentication is already handled elsewhere.

Practice this question →

53

MCQmedium

A background service must call Microsoft Graph without a signed-in user. Which Microsoft identity platform permission model is required?

A.Password hash synchronization

B.Delegated permissions only

C.Device code flow

D.Application permissions with client credentials flow

AnswerD

Application permissions allow daemon apps to act as themselves without a user context.

Why this answer

For a background service calling Microsoft Graph without a signed-in user, the application must authenticate as itself, not on behalf of a user. Application permissions, combined with the client credentials flow (OAuth 2.0), allow the service to obtain an access token using its own identity (client ID and client secret or certificate), without any user interaction. This is the only model that supports non-interactive, daemon-style access to Microsoft Graph.

Exam trap

The trap here is that candidates confuse 'no signed-in user' with 'no user at all' and incorrectly choose delegated permissions or device code flow, forgetting that application permissions with client credentials flow are the only way to authenticate a service identity without user interaction.

How to eliminate wrong answers

Option A is wrong because password hash synchronization is an Azure AD Connect feature for syncing user password hashes for hybrid identity, not a permission model for calling Microsoft Graph. Option B is wrong because delegated permissions require a signed-in user to delegate authority to the app; they cannot be used for background services that run without a user context. Option C is wrong because the device code flow is designed for devices with limited input capabilities (e.g., IoT, CLI) and still requires a signed-in user to complete the authentication interactively; it does not support unattended background service scenarios.

Practice this question →

54

MCQeasy

Refer to the exhibit. You are using Azure CLI to list blobs in a container. The command fails with an authorization error. The storage account has firewall rules enabled, and you are running the CLI from a machine that is not on the allowed network list. What is the most likely cause of the failure?

A.The storage account firewall is blocking the request because your IP is not in the allow list

B.You do not have the 'Storage Blob Data Reader' role assigned

C.The container name is misspelled

D.The storage account requires TLS 1.2 and your CLI uses an older version

AnswerA

Azure Storage firewalls are configured to restrict network access to the storage account based on specific IP addresses or virtual networks. If the client's public IP address from which the Azure CLI command is executed is not explicitly included in the storage account's allowed IP ranges, the firewall will block the incoming request. This network-level denial often manifests as an "AuthorizationFailure" or "Forbidden" error (HTTP 403), as the storage service rejects the connection attempt before full authentication and authorization processing can occur for an unapproved source.

Why this answer

The storage account firewall explicitly blocks all traffic except from IP addresses or subnets in the allow list. Since the CLI is running from a machine whose IP is not on that list, the request is denied at the network layer before any authentication or authorization checks occur. This is the most direct cause of the authorization error.

Exam trap

The trap here is that candidates often confuse network-level firewall blocking with missing RBAC role assignments, but the firewall denies the request before any identity-based authorization is checked.

How to eliminate wrong answers

Option B is wrong because the 'Storage Blob Data Reader' role is an RBAC permission that controls access to data operations, but the firewall blocks the request at the network layer before RBAC is evaluated. Option C is wrong because a misspelled container name would result in a '404 Not Found' error, not an authorization error. Option D is wrong because TLS version mismatch would cause a connection failure or handshake error, not an authorization error; Azure CLI defaults to TLS 1.2 on modern systems.

Practice this question →

55

MCQmedium

Your organization uses Azure Key Vault to store secrets. Developers need to retrieve secrets during application runtime. You want to minimize latency and avoid network overhead. Which approach should you recommend?

A.Enable the Key Vault firewall and allow only trusted Azure services.

B.Store the secrets directly in application configuration files.

C.Implement caching of secrets in the application with a short time-to-live (TTL) and use Key Vault as the source of truth.

D.Enable Key Vault soft-delete to ensure secrets are recoverable.

AnswerC

Implementing application-level caching for secrets, coupled with a short time-to-live (TTL), significantly reduces the frequency of direct calls to Azure Key Vault. This approach minimizes network latency associated with repeated Key Vault requests and decreases the operational load on the Key Vault service itself. Key Vault remains the authoritative source, ensuring secrets are eventually refreshed and updated, balancing performance with security and freshness.

Why this answer

It directly addresses the need to minimize latency and network overhead by caching secrets locally with a short TTL, while still using Azure Key Vault as the authoritative source. This pattern reduces the frequency of network calls to Key Vault, which is critical for high-throughput applications where every millisecond matters. The short TTL ensures that secret updates are eventually reflected without stale data persisting indefinitely.

Exam trap

The trap here is that candidates may confuse security features (like firewalls or soft-delete) with performance optimizations, or mistakenly think that storing secrets in config files is acceptable for minimizing latency, ignoring the critical security implications.

How to eliminate wrong answers

Option A is wrong because enabling the Key Vault firewall and allowing only trusted Azure services does not reduce latency or network overhead; it only restricts access and does not eliminate the need for network calls. Option B is wrong because storing secrets directly in application configuration files violates security best practices, as it exposes secrets in plaintext and bypasses Key Vault's access control and auditing. Option D is wrong because enabling soft-delete is a data protection and recovery feature, not a performance optimization; it does nothing to reduce latency or network overhead.

Practice this question →

56

MCQmedium

You are developing an ASP.NET Core web app that uses Azure SQL Database. The SQL connection string contains a password that must be rotated every 30 days. The app runs on Azure App Service. You want to store the connection string securely and enable automatic rotation without redeploying the app. Which approach should you use?

A.Store the connection string in an App Setting and use Key Vault references. Configure a Key Vault policy to automatically rotate the secret.

B.Store the connection string in an App Setting as a plain text value and use deployment slots to swap when the password changes.

C.Use a managed identity to access the SQL database directly, bypassing the connection string entirely.

D.Store the connection string in Azure Key Vault and use an ARM template with a secret reference at deployment time.

AnswerA

This approach uses a Key Vault reference in the App Setting, which the runtime resolves automatically. The secret can have an expiration date, and you can automate its renewal using Azure automation or functions, enabling rotation without redeployment.

Why this answer

Azure App Service supports Key Vault references in App Settings, allowing you to securely store the connection string in Key Vault and reference it without exposing the password. By configuring a Key Vault policy to automatically rotate the secret (e.g., using a scheduled rotation or event-driven trigger), the password can be rotated every 30 days without redeploying the app, as the App Service runtime resolves the reference at runtime.

Exam trap

The trap here is that candidates often confuse Key Vault references with ARM template secret references, assuming both are resolved at runtime, but ARM template references are only evaluated during deployment, not dynamically.

How to eliminate wrong answers

Option B is wrong because storing the connection string as plain text in an App Setting exposes the password in the Azure portal and configuration files, violating security best practices, and deployment slots do not automate rotation—they only swap environments, requiring manual password updates. Option C is wrong because managed identity can authenticate to Azure SQL Database without a password, but it does not eliminate the need for a connection string entirely; the connection string still contains the server and database name, and managed identity does not support automatic rotation of a password (it uses certificate-based authentication). Option D is wrong because ARM template secret references are resolved at deployment time, not at runtime, so rotating the secret in Key Vault would require a new deployment to update the connection string, failing the requirement to avoid redeployment.

Practice this question →

57

MCQhard

Your application uses Azure Key Vault to store cryptographic keys. You need to ensure that keys are automatically rotated every 90 days without any manual intervention. Which Key Vault feature should you configure?

A.Set a key rotation policy

B.Configure a Key Vault firewall

C.Enable soft-delete on the key vault

D.Use a managed HSM instead of a standard vault

AnswerA

Setting a key rotation policy in Azure Key Vault is the correct approach because it automates the generation of new cryptographic key versions based on a predefined schedule or an expiry notification. This feature ensures that keys are regularly updated without manual intervention, significantly enhancing security by limiting the lifespan of any single key. Automated rotation is a critical security best practice for managing the lifecycle of cryptographic assets and mitigating risks associated with long-lived keys.

Why this answer

Azure Key Vault supports key rotation policies that allow you to define automatic rotation intervals (e.g., every 90 days) for cryptographic keys. When a rotation policy is set, Key Vault automatically creates a new key version and optionally expires the old one, eliminating the need for manual intervention.

Exam trap

The trap here is that candidates may confuse soft-delete or Managed HSM with rotation capabilities, but neither feature automates key version creation; only a rotation policy does.

How to eliminate wrong answers

Option B is wrong because configuring a Key Vault firewall controls network access to the vault, not key lifecycle management or rotation. Option C is wrong because enabling soft-delete protects keys from accidental deletion by retaining them for a configurable retention period, but it does not automate key rotation. Option D is wrong because using a Managed HSM provides a higher security boundary with FIPS 140-2 Level 3 validation and dedicated hardware, but it does not inherently enable automatic key rotation; you still need to configure a rotation policy.

Practice this question →

58

Multi-Selectmedium

Which THREE components are required to implement Azure AD B2C custom policies for sign-up and sign-in? (Choose three.)

Select 3 answers

A.A user journey definition

B.An Azure AD (Microsoft Entra ID) tenant for employee identities

C.An Azure subscription

D.A trust framework policy (XML)

E.A relying party application registration

AnswersA, D, E

A user journey definition is a core component within Azure AD B2C custom policies, specifically part of the Identity Experience Framework (IEF). It meticulously defines the sequence of orchestration steps a user must complete for a specific task, such as sign-up, sign-in, or profile editing. These journeys dictate the flow of claims and interactions with various technical profiles, making them indispensable for defining the user's authentication and authorization path.

Why this answer

A user journey definition is a core component of an Azure AD B2C custom policy. It orchestrates the sequence of technical profiles and orchestration steps that define the sign-up and sign-in experience, including self-asserted pages, multifactor authentication, and validation. Without a user journey, the policy cannot specify the flow of claims exchanges and user interactions.

Exam trap

The trap here is that candidates often confuse the Azure AD B2C tenant (which is required) with an Azure AD tenant for employee identities (Option B), or they mistakenly think an Azure subscription is a direct component of the policy implementation rather than a prerequisite for tenant creation.

Practice this question →

59

MCQmedium

Twenty Azure Functions across different teams all need read access to the same Azure Cosmos DB account. The security team wants to revoke or modify this access for all twenty functions at once without visiting each Function App individually. What managed identity design satisfies this requirement?

A.Create one user-assigned managed identity, attach it to all twenty Function Apps, and grant it the Cosmos DB Built-in Data Reader role

B.Enable a system-assigned managed identity on each Function App and grant each identity the Cosmos DB Built-in Data Reader role

C.Create a service principal, store its client secret in Key Vault, and reference the secret from all twenty Function Apps via Key Vault references

D.Store the Cosmos DB connection string in Azure App Configuration and reference it from all twenty Function Apps

AnswerA

The role assignment on the user-assigned identity propagates instantly to all twenty Function Apps that reference it. Revoking the role assignment revokes access everywhere simultaneously. Adding a new Function App just requires attaching the existing identity — no new role grants are needed.

Why this answer

A single user-assigned managed identity can be created once and then attached to all twenty Function Apps. Granting that identity the Cosmos DB Built-in Data Reader role at the Cosmos DB account scope means that revoking or modifying the role assignment centrally affects all functions simultaneously, without needing to visit each app individually.

Exam trap

The trap here is that candidates often confuse system-assigned managed identities (which are tied to a single resource) with user-assigned managed identities (which can be shared across resources), leading them to choose Option B because they think 'managed identity' automatically means system-assigned, missing the central management requirement.

How to eliminate wrong answers

Option B is wrong because each system-assigned managed identity is unique per Function App, so you would have to grant the Cosmos DB role to each identity individually, and revoking or modifying access would require updating each role assignment separately. Option C is wrong because using a service principal with a client secret stored in Key Vault introduces secret management overhead and does not leverage managed identities; revoking access would require rotating the secret or modifying the service principal, not a single role assignment. Option D is wrong because storing the Cosmos DB connection string in App Configuration and referencing it from each Function App does not provide a central point to revoke or modify access—each app still uses the same static connection string, and revoking access would require changing the connection string and redeploying or updating each app's configuration reference.

Practice this question →

60

MCQeasy

You need to secure access to an Azure Storage account that hosts sensitive data. The requirement is to restrict access to only requests originating from a specific virtual network. Which feature should you configure?

A.Customer-managed keys (CMK)

B.Azure AD authentication

C.Shared access signatures (SAS)

D.Storage firewall and virtual network rules

AnswerD

Storage firewall and virtual network rules are the primary mechanism for securing network access to an Azure Storage account by defining which networks are permitted to connect. By configuring these rules, you can explicitly allow traffic only from specified Azure Virtual Networks, subnets, or public IP address ranges, effectively creating a network perimeter. This ensures that only trusted private networks or specific external endpoints can establish a connection, directly addressing the requirement for VNet-based access control.

Why this answer

D is correct because Azure Storage firewall and virtual network rules allow you to restrict access to your storage account to only requests originating from a specific virtual network. This is achieved by configuring a service endpoint or a private endpoint for the storage account, which ensures that traffic from the designated VNet is permitted while all other public internet traffic is blocked. This directly meets the requirement of restricting access to a specific virtual network.

Exam trap

The trap here is that candidates often confuse network-level access control (firewall and VNet rules) with authentication or encryption mechanisms, leading them to pick options like Azure AD authentication or CMK, which do not restrict traffic to a specific virtual network.

How to eliminate wrong answers

Option A is wrong because Customer-managed keys (CMK) are used for encrypting data at rest with a key managed by the customer, not for network-level access control. Option B is wrong because Azure AD authentication controls identity-based access to the storage account (e.g., for blobs or queues) but does not restrict traffic to a specific virtual network. Option C is wrong because Shared access signatures (SAS) provide delegated, time-limited access to specific storage resources via a token, but they do not limit the source network to a specific virtual network.

Practice this question →

61

MCQeasy

You are developing an API that will be hosted on Azure API Management (APIM). The API must be accessible only to clients that present a valid JSON Web Token (JWT) issued by Microsoft Entra ID. Which APIM policy should you use to validate the JWT?

A.<cors allow-credentials="true" />

B.<authenticate-basic />

C.<validate-jwt header-name="Authorization" failed-validation-httpcode="401" />

D.<check-header name="Authorization" failed-check-httpcode="401" />

AnswerC

The <validate-jwt header-name="Authorization" failed-validation-httpcode="401" /> policy is specifically engineered within Azure API Management to perform comprehensive validation of JSON Web Tokens. It verifies the token's cryptographic signature using a specified key, checks the issuer (iss) and audience (aud) claims, and ensures the token has not expired (exp claim). This policy is the correct mechanism for robustly authenticating requests secured with JWTs by ensuring their integrity and authenticity.

Why this answer

The <validate-jwt> policy in Azure API Management is specifically designed to enforce the presence and validity of a JSON Web Token (JWT) in incoming requests. By setting the header-name attribute to 'Authorization' and failed-validation-httpcode to '401', the policy checks that the JWT in the Authorization header is cryptographically signed by Microsoft Entra ID and has not expired, rejecting invalid or missing tokens with a 401 Unauthorized response.

Exam trap

The trap here is that candidates often confuse <check-header> with <validate-jwt>, assuming that simply checking for the presence of the Authorization header is sufficient for JWT validation, but <check-header> performs no cryptographic verification or claim validation, leaving the API vulnerable to forged or expired tokens.

How to eliminate wrong answers

Option A is wrong because <cors allow-credentials='true' /> is used to enable cross-origin resource sharing (CORS) for browser-based clients, not to validate JWT tokens. Option B is wrong because <authenticate-basic /> validates HTTP Basic Authentication credentials (username/password), not JSON Web Tokens, and is incompatible with Entra ID JWT-based authentication. Option D is wrong because <check-header name='Authorization' failed-check-httpcode='401' /> only verifies that the Authorization header is present, but does not decode, validate the signature, or check the expiration of a JWT, making it insufficient for token validation.

Practice this question →

62

MCQhard

A company uses Azure API Management (APIM) to expose APIs to external partners. They want to validate JSON Web Tokens (JWTs) from partners' Microsoft Entra ID tenants before requests reach the backend. The solution must support multiple partner tenants and minimize latency. What should you implement?

A.Use Azure AD B2C as a token broker between partners and the API.

B.Configure OAuth 2.0 authorization server in APIM for each partner tenant.

C.Use client certificate authentication in APIM to map certificates to partner tenants.

D.Use APIM inbound policy with validate-jwt and specify openid-config URL for each partner tenant.

AnswerD

The `validate-jwt` inbound policy in Azure API Management is specifically designed to verify JSON Web Tokens (JWTs) by checking their signature, claims, and expiration. By specifying the `openid-config` URL (also known as the OpenID Connect discovery endpoint) for each partner tenant, APIM can dynamically retrieve the necessary public keys and issuer metadata to validate tokens issued by those respective external identity providers. This method efficiently supports multiple distinct JWT issuers, ensuring robust and scalable authentication for partner integrations.

Why this answer

The `validate-jwt` policy in APIM can be configured with an `openid-config` URL for each partner tenant, allowing APIM to fetch the tenant-specific signing keys and validate JWTs issued by any Microsoft Entra ID tenant. This approach supports multiple tenants without adding a broker or per-tenant authorization servers, and it minimizes latency by performing validation at the APIM gateway before requests reach the backend.

Exam trap

The trap here is that candidates often confuse the `validate-jwt` policy with the need to configure an OAuth 2.0 authorization server in APIM, but APIM's authorization server is for the API's own token issuance, not for validating tokens from external tenants.

How to eliminate wrong answers

Option A is wrong because Azure AD B2C is designed for customer identity and access management, not as a token broker between partner tenants and an API; it would introduce unnecessary complexity and latency. Option B is wrong because configuring an OAuth 2.0 authorization server in APIM for each partner tenant is not supported—APIM's built-in authorization server is for a single identity provider, not for dynamically handling multiple external tenant configurations. Option C is wrong because client certificate authentication validates the client's identity via a certificate, not the JWT token itself; it cannot validate claims or signatures from Microsoft Entra ID tokens, and mapping certificates to tenants adds management overhead without addressing JWT validation.

Practice this question →

63

Multi-Selecteasy

Your company wants to implement a zero-trust security model for its Azure resources. Which THREE practices should you adopt? (Choose three.)

Select 3 answers

A.Implement just-in-time (JIT) access for administrative roles

B.Require multi-factor authentication (MFA) for all users

C.Place all resources behind a firewall

D.Enable micro-segmentation between application tiers

E.Use a VPN to connect to the corporate network

AnswersA, B, D

Implementing Just-in-Time (JIT) access for administrative roles is a cornerstone of Zero Trust. It ensures that elevated permissions are granted only when explicitly requested, for a strictly limited duration, and for a specific task. This significantly reduces the window of opportunity for attackers to exploit standing administrative privileges, aligning with the principle of least privilege and minimizing the attack surface.

Why this answer

Just-in-time (JIT) access for administrative roles reduces the attack surface by granting elevated permissions only when needed and for a limited time. In Azure, JIT is implemented via Azure AD Privileged Identity Management (PIM), which enforces activation requests, approval workflows, and automatic deactivation. This aligns with the zero-trust principle of 'never trust, always verify' by minimizing standing privileges.

Exam trap

The trap here is that candidates often confuse traditional network security controls (like firewalls and VPNs) with zero-trust principles, mistakenly thinking perimeter defenses are sufficient, while zero-trust requires identity-based, least-privilege access and micro-segmentation regardless of network location.

Practice this question →

64

MCQmedium

You are developing a web application that will be deployed to Azure App Service. The application allows users to upload files, which are stored in Azure Blob Storage. You need to ensure that only authenticated users can upload files and that each user can only see their own files. You plan to use shared access signatures (SAS) for secure access. The application uses Microsoft Entra ID for authentication. You want to generate SAS tokens on the server after the user authenticates. Which approach should you use?

A.After user authentication, have the client generate a SAS token using the storage account key retrieved from a secure endpoint.

B.After user authentication, use the server-side code to generate a user delegation SAS for a specific blob container path that includes the user's identifier. Store the SAS in the user's session and return it to the client. The client then uses the SAS to upload the file directly to Blob Storage.

C.After user authentication, use the server-side code to generate a service SAS for the entire blob container. Return the SAS to the client. The client uploads the file, and the server later moves the file to a user-specific folder.

D.After user authentication, use the server to upload the file to Blob Storage using the storage account key. Then return the URL of the uploaded blob to the client.

AnswerB

This approach is correct because it leverages a User Delegation SAS, which is generated server-side using an Azure AD identity (not the storage account key) and provides fine-grained, time-limited permissions. By scoping the SAS to a specific blob container path incorporating the user's identifier, it ensures each user can only access their designated storage area, upholding data isolation and the principle of least privilege. The client receives only the SAS token, enabling direct and secure uploads to Blob Storage without the server acting as an intermediary or exposing sensitive credentials.

Why this answer

It uses a user delegation SAS, which is signed with the storage account's user delegation key derived from Microsoft Entra ID credentials. This ensures that the SAS token is scoped to the authenticated user's identity and can be restricted to a specific container path (e.g., a folder named after the user's identifier). The server generates the SAS after authentication, stores it in the session, and returns it to the client, allowing direct uploads to Blob Storage without exposing the storage account key.

Exam trap

The trap here is that candidates often confuse a service SAS (which uses the account key and can scope to a container or blob) with a user delegation SAS (which uses Entra ID and supports finer-grained identity-based scoping), leading them to choose Option C because it seems simpler, but they miss the security and isolation requirements.

How to eliminate wrong answers

Option A is wrong because having the client generate a SAS token using the storage account key retrieved from a secure endpoint still exposes the storage account key to the client-side code, which violates security best practices and could lead to key compromise. Option C is wrong because a service SAS for the entire container does not restrict access to a user-specific path; the server would need to move files after upload, which introduces unnecessary complexity and a race condition where users could access each other's files before the move. Option D is wrong because uploading via the server using the storage account key bypasses the need for a SAS token entirely, but it forces all traffic through the server, which defeats the purpose of using SAS for direct client-to-storage uploads and increases server load and latency.

Practice this question →

65

MCQhard

You are designing 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 defined in Microsoft Entra ID app roles or groups. The role mappings are dynamic and stored in an application database. How should you implement authorization in the API?

A.Define the roles as Microsoft Entra ID app roles and assign them to users. This is the standard way to handle roles.

B.Use the OnTokenValidated event in OpenID Connect middleware to query the database and add custom role claims to the identity.

C.Store the roles in the Microsoft Entra ID token by customizing the token issuance in Microsoft Entra ID.

D.Use the [Authorize] attribute with a custom authorization filter that checks the database on every request without modifying the claims.

AnswerB

The OnTokenValidated event in the OpenID Connect middleware is the correct extension point for this scenario. This event fires after the identity token has been successfully validated but before the ClaimsPrincipal is fully constructed and attached to the HttpContext. Within this event, the application can query its internal database using the authenticated user's identifier, retrieve their dynamic roles, and then add these roles as custom claims to the user's ClaimsIdentity. This approach seamlessly integrates dynamic roles into the standard claims-based authorization model.

Why this answer

It uses the OnTokenValidated event in OpenID Connect middleware to enrich the user's identity with custom role claims from the application database after token validation. This approach allows dynamic role mappings stored externally to be injected into the ClaimsPrincipal, which can then be evaluated by the standard [Authorize] attribute with role policies. It avoids modifying Entra ID configuration and keeps role management flexible within the application.

Exam trap

The trap here is that candidates often assume Entra ID app roles or groups are the only way to implement role-based authorization, overlooking the flexibility of the OnTokenValidated event to inject custom claims from external sources.

How to eliminate wrong answers

Option A is wrong because defining roles as Entra ID app roles requires static assignment in the directory, which contradicts the requirement for dynamic role mappings stored in an application database. Option C is wrong because customizing token issuance in Entra ID is not feasible for dynamic, database-driven roles; Entra ID tokens are issued based on directory configuration, not external databases. Option D is wrong because using a custom authorization filter that checks the database on every request without modifying claims is inefficient and bypasses the standard claims-based authorization pipeline, leading to poor performance and complexity.

Practice this question →

66

MCQmedium

You are developing a web app that authenticates users via Microsoft Entra ID. The app needs to read the user's profile and send emails on their behalf. You want to minimize user consent prompts. Which OAuth 2.0 grant type should you use?

A.Authorization code flow with PKCE

B.Client credentials flow

C.Resource owner password credentials

D.Implicit flow

AnswerA

This is the recommended and most secure OAuth 2.0 flow for web applications authenticating users. It involves redirecting the user's browser to the identity provider for authentication, then receiving an authorization code back at a registered redirect URI. This code is then securely exchanged for access and refresh tokens from the backend, preventing tokens from being exposed in the browser's URL. PKCE (Proof Key for Code Exchange) further enhances security by mitigating authorization code interception attacks, particularly important for public clients but also a strong best practice for confidential web apps.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the recommended OAuth 2.0 grant type for public clients (like a web app) that need delegated user authentication and consent. It allows the app to obtain an access token to read the user's profile and a refresh token to send emails on their behalf, while minimizing consent prompts by using a single consent request for both permissions. PKCE adds a cryptographic challenge to prevent authorization code interception attacks, making it secure for web apps without a client secret.

Exam trap

The trap here is that candidates often choose the client credentials flow (B) thinking it minimizes prompts because it doesn't involve user interaction, but they overlook that the app needs to act on behalf of a specific user, which requires delegated permissions and user consent, not application permissions.

How to eliminate wrong answers

Option B is wrong because the client credentials flow is designed for server-to-server (daemon) scenarios where no user is present; it cannot act on behalf of a specific user to read their profile or send emails as them. 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 is insecure and not recommended for modern apps; it also does not minimize consent prompts as it bypasses the consent UI entirely. Option D is wrong because the implicit flow is deprecated in OAuth 2.0 Security Best Current Practice (BCP) due to security risks like access token leakage in the browser; it also cannot issue refresh tokens, so the app would need repeated consent prompts for long-lived access.

Practice this question →

67

MCQmedium

Refer to the exhibit. You have an Azure Policy definition as shown. Your team creates a storage account with network rules set to 'Deny' by default, and then adds an IP rule to allow traffic from a specific IP range. What compliance state will this storage account be reported as?

A.Error

B.Compliant

C.Exempt

D.Non-compliant

AnswerB

This policy definition utilizes the DenyAction effect, which specifically targets 'write' operations on storage accounts. It does not contain any conditions that evaluate the network rule configurations, such as public network access settings. Therefore, if a storage account already exists or is created without violating the 'write' operation conditions (which are not specified in the prompt but implied to be met), its compliance state will be Compliant because the policy's scope does not encompass network access restrictions. The policy only restricts actions, not the inherent configuration of existing resources outside its defined conditions.

Why this answer

The Azure Policy definition in the exhibit uses the 'DenyAction' effect, which only denies or audits specific actions (such as 'Microsoft.Storage/storageAccounts/write'). It does not evaluate the configuration of network rules on the storage account. Therefore, the storage account's network rule settings (defaultAction 'Deny' and IP rule) have no bearing on compliance with this policy.

The resource is compliant because the policy's condition does not apply to network rules, and the write action was not blocked since the account was created successfully.

Exam trap

The trap here is that candidates assume any policy with 'Deny' in the name will evaluate network rules or resource configuration, but 'DenyAction' only blocks specific operations and does not assess the resource's properties for compliance.

How to eliminate wrong answers

Option A is wrong because 'Error' is not a valid compliance state in Azure Policy; valid states include Compliant, Non-compliant, Exempt, and Conflicting. Option C is wrong because 'Exempt' requires an explicit exemption assignment on the resource or policy, which was not mentioned in the scenario. Option D is wrong because the storage account is not non-compliant; the policy's 'DenyAction' effect only blocks the write operation if attempted, but the account was created successfully, and the policy does not evaluate the network rule configuration.

Practice this question →

68

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 architecture review board prefers a managed Azure-native control.

A.Implicit flow

B.Client credentials flow

C.Resource owner password credentials flow

D.Authorization code flow with PKCE

AnswerD

PKCE protects public clients that cannot store secrets and is recommended for SPAs.

Why this answer

The authorization code flow with PKCE (Proof Key for Code Exchange) is the correct choice because it is designed for public clients (like single-page apps) that cannot securely store a client secret. PKCE uses a dynamically generated cryptographic code verifier and challenge to prevent authorization code interception attacks, making it the recommended OAuth 2.0 flow for SPAs calling protected APIs in Microsoft Entra ID.

Exam trap

The trap here is that candidates often confuse the implicit flow (which was historically used for SPAs) with the modern PKCE-enhanced authorization code flow, not realizing that the implicit flow is now deprecated and the authorization code flow with PKCE is the current best practice for public clients.

How to eliminate wrong answers

Option A is wrong because the implicit flow is deprecated by OAuth 2.0 Security Best Current Practice (BCP) and Microsoft Entra ID recommends against it for SPAs due to security risks like access token leakage in the browser history. Option B is wrong because the client credentials flow is intended for server-to-server (confidential client) scenarios where no user is involved, not for a single-page app that signs in users. Option C is wrong because the resource owner password credentials flow requires the app to handle user credentials directly, which is insecure and violates the principle of delegated authentication; it is also not recommended by Microsoft Entra ID for modern applications.

Practice this question →

69

MCQmedium

You are developing an ASP.NET Core web API hosted on Azure App Service. The API needs to read secrets from Azure Key Vault at startup. You have enabled a system-assigned managed identity for the App Service. Which code should you use to create the Key Vault SecretClient?

A.new SecretClient(new Uri(keyVaultUrl), new DefaultAzureCredential())

B.new SecretClient(new Uri(keyVaultUrl), new ClientSecretCredential(tenantId, clientId, clientSecret))

C.new SecretClient(new Uri(keyVaultUrl), new ChainedTokenCredential())

D.new SecretClient(new Uri(keyVaultUrl), new InteractiveBrowserCredential())

AnswerA

This is the recommended and most secure approach for Azure App Services. DefaultAzureCredential automatically detects the execution environment and attempts various authentication methods, prioritizing managed identities when available. For an ASP.NET Core Web API hosted on Azure App Service, it will seamlessly leverage the App Service's system-assigned or user-assigned managed identity to authenticate with Azure Key Vault, eliminating the need to manage secrets or credentials in code. This adheres to the principle of least privilege and enhances security by avoiding hardcoded credentials.

Why this answer

`DefaultAzureCredential` automatically attempts to authenticate using the environment's managed identity when running on Azure App Service. Since a system-assigned managed identity is enabled, `DefaultAzureCredential` will chain through available credential sources and successfully use the managed identity endpoint to obtain a token for Key Vault, without requiring any explicit tenant ID, client ID, or secret.

Exam trap

The trap here is that candidates often choose `ClientSecretCredential` (Option B) because they are accustomed to using service principals with secrets, forgetting that managed identities eliminate the need for any hardcoded credentials.

How to eliminate wrong answers

Option B is wrong because `ClientSecretCredential` requires a client secret, which defeats the purpose of using a managed identity—it introduces a secret that must be stored and rotated, increasing security risk. Option C is wrong because `ChainedTokenCredential` is not a concrete credential class; it is a base class for building custom credential chains, and cannot be instantiated directly with `new`. Option D is wrong because `InteractiveBrowserCredential` is designed for interactive user authentication via a browser, which is not suitable for a server-side, unattended startup scenario in Azure App Service.

Practice this question →

70

MCQeasy

A company stores secrets in Azure Key Vault. Developers need to retrieve secrets from a web app without storing connection strings in code. Which authentication method should the web app use?

A.Register a service principal and use a client secret

B.Enable a managed identity for the web app

C.Use a shared access signature (SAS) token

D.Use a certificate thumbprint in the app settings

AnswerB

Enabling a managed identity for the web app is the recommended and most secure approach for accessing Azure Key Vault. A managed identity provides an automatically managed identity in Azure Active Directory for the application, allowing it to authenticate to Key Vault without any developer needing to manage credentials, secrets, or certificates. Azure handles the lifecycle of this identity, including its authentication tokens, significantly reducing the attack surface and operational overhead associated with secret management.

Why this answer

Managed identities for Azure resources provide an automatically managed identity in Azure AD, allowing the web app to authenticate to Key Vault without any credentials in code. The web app obtains an Azure AD access token directly from the Azure Instance Metadata Service (IMDS) endpoint, which Key Vault accepts. This eliminates the need to store connection strings, client secrets, or certificates in the application.

Exam trap

The trap here is that candidates often confuse managed identities with service principals, assuming a service principal with a client secret is the simplest approach, but they overlook that the client secret itself must be stored somewhere, violating the 'no secrets in code' requirement.

How to eliminate wrong answers

Option A is wrong because registering a service principal and using a client secret still requires storing that secret in the web app's configuration or code, defeating the goal of avoiding stored credentials. Option C is wrong because a shared access signature (SAS) token is used for delegating access to Azure Storage resources, not for authenticating to Key Vault. Option D is wrong because using a certificate thumbprint in app settings still requires the certificate to be deployed and managed on the web app, and the thumbprint alone does not provide authentication; the private key must be accessible, which introduces management overhead.

Practice this question →

71

MCQmedium

A company deploys an Azure App Service web app that stores sensitive data in Azure Blob Storage. The security team requires that all access to the blob storage must be authenticated and authorized via Microsoft Entra ID, and that no anonymous access is permitted. The web app must also be able to access the storage using its managed identity. Which configuration should the company implement?

A.Create a custom RBAC role that allows full access to the storage account and assign it to the web app's service principal.

B.Enable the web app's system-assigned managed identity, assign the Storage Blob Data Contributor role to the identity, and disable anonymous access on the storage account.

C.Use storage account access keys and store them in Key Vault, then configure the web app to retrieve them at runtime.

D.Generate a shared access signature (SAS) token with read permissions, store it in App Settings, and configure the web app to use it.

AnswerB

This is the correct and recommended approach for secure access. Enabling a system-assigned managed identity provides the web app with an identity in Microsoft Entra ID, eliminating the need for credential management. Assigning the Storage Blob Data Contributor role grants the necessary data plane permissions to the identity, adhering to the principle of least privilege. Disabling anonymous access on the storage account ensures all interactions are authenticated and authorized via Microsoft Entra ID and RBAC.

Why this answer

It satisfies all requirements: enabling a system-assigned managed identity for the web app allows it to authenticate to Azure Blob Storage without storing credentials, assigning the Storage Blob Data Contributor RBAC role authorizes that identity to read/write blobs, and disabling anonymous access ensures no unauthenticated requests are permitted. This configuration enforces Microsoft Entra ID (formerly Azure AD) as the sole authentication mechanism, meeting the security team's mandate.

Exam trap

The trap here is that candidates often confuse RBAC roles with access keys or SAS tokens, mistakenly thinking any form of credential (like a key or token) satisfies the 'authenticated and authorized via Microsoft Entra ID' requirement, when in fact only managed identity with RBAC and disabled anonymous access enforces Entra ID as the sole authentication method.

How to eliminate wrong answers

Option A is wrong because creating a custom RBAC role for full access is unnecessary and overly permissive; the built-in Storage Blob Data Contributor role already provides the required blob-level access, and the web app's service principal is automatically used via managed identity, not a separate custom role. Option C is wrong because using storage account access keys bypasses Microsoft Entra ID authentication entirely, violating the requirement that all access must be authenticated and authorized via Entra ID; keys are shared secrets that do not support identity-based authorization. Option D is wrong because a shared access signature (SAS) token does not use Microsoft Entra ID authentication; it relies on a token derived from the storage account key, which does not enforce identity-based access and cannot be scoped to a managed identity.

Practice this question →

72

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 →

73

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 →

74

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 →

75

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 →

Page 1 of 3 · 157 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Implement Azure security questions.

Start 20-question session