CCNA Azure Security Questions — Page 3 of 3

151

Multi-Selecteasy

You are designing a solution to store application secrets. You need to ensure that secrets are encrypted at rest and access is audited. Which TWO Azure services should you use?

Select 2 answers

A.Azure SQL Database

B.Azure Monitor

C.Azure Key Vault

D.Azure Storage Account with encryption

E.Azure App Configuration

AnswersB, C

Azure Monitor is a comprehensive solution for collecting, analyzing, and acting on telemetry from Azure and on-premises environments. While it does not store application secrets itself, it is crucial for monitoring the security and access patterns of a dedicated secret store like Azure Key Vault. By integrating with Key Vault diagnostic logs, Azure Monitor enables auditing of secret access, detection of anomalous behavior, and alerting on security incidents, thereby enhancing the overall security posture of the secret management solution.

Why this answer

Azure Monitor is correct because it provides the auditing and logging capabilities required to track access to secrets. By enabling diagnostic settings on Key Vault, you can send audit events (e.g., secret get, set, delete) to a Log Analytics workspace, storage account, or Event Hub, which are then queryable via Azure Monitor Logs. This satisfies the requirement for access auditing.

Exam trap

The trap here is that candidates often confuse Azure App Configuration with Key Vault, but App Configuration is for non-sensitive settings (e.g., feature flags) and lacks the encryption-at-rest and auditing guarantees required for secrets, while Key Vault is the dedicated service for secure secret storage and access logging.

Practice this question →

152

MCQmedium

You have an Azure App Service web app that uses a system-assigned managed identity. The app needs to read a secret stored in Azure Key Vault. You need to grant the app the minimum required permissions to access the secret. Which RBAC role should you assign to the managed identity at the Key Vault scope?

A.Key Vault Reader

B.Key Vault Secrets User

C.Key Vault Secrets Officer

D.Contributor

AnswerB

The Key Vault Secrets User role provides specific data plane permissions, including Microsoft.KeyVault/vaults/secrets/read (which encompasses get and list operations), allowing an identity to retrieve the actual secret values stored within an Azure Key Vault. This role adheres to the principle of least privilege by granting only the necessary access to read secrets, without permitting their creation, deletion, or modification, making it ideal for an App Service needing to consume secrets.

Why this answer

The Key Vault Secrets User role grants the minimum required permission to read secrets from Azure Key Vault. This role provides the 'Microsoft.KeyVault/vaults/secrets/getSecret/action' permission, which is exactly what the app needs to retrieve the secret value. It does not grant any write or management capabilities, adhering to the principle of least privilege.

Exam trap

The trap here is that candidates often confuse the Key Vault Reader role (which only allows listing vaults and reading metadata, not secret values) with the ability to read secrets, leading them to select it as the minimum permission.

How to eliminate wrong answers

Option A is wrong because Key Vault Reader only allows listing vaults and reading metadata, not reading secret values. Option C is wrong because Key Vault Secrets Officer grants full control over secrets, including create, update, delete, and restore, which exceeds the minimum required read permission. Option D is wrong because Contributor is a broad Azure RBAC role that grants full management access to all resources in the scope, far beyond the needed secret read permission.

Practice this question →

153

MCQhard

You are developing an ASP.NET Core web API that authenticates users via Microsoft Entra ID. The API needs to call a downstream API (also secured by Microsoft Entra ID) on behalf of the signed-in user (On-Behalf-Of flow). You have already configured the web API to authenticate users with Microsoft.Identity.Web. How should you implement the token acquisition for the downstream API?

A.Use ADAL.NET's `AcquireTokenOnBehalfOf` method

B.Inject `ITokenAcquisition` and call `GetAccessTokenForUserAsync` with the scopes for the downstream API

C.Use the `Azure.Identity` library with `DefaultAzureCredential` to acquire a token

D.Manually construct an HTTP POST to the Microsoft Entra ID token endpoint with the user access token and client credentials

AnswerB

This is the recommended and most robust approach for an ASP.NET Core Web API to acquire a token for a downstream API using the On-Behalf-Of flow. `ITokenAcquisition` is an interface provided by `Microsoft.Identity.Web`, which simplifies token acquisition by abstracting away the complexities of MSAL.NET. Calling `GetAccessTokenForUserAsync` with the required scopes automatically handles exchanging the incoming user's access token for a new token valid for the specified downstream API, including token caching and refresh.

Why this answer

Microsoft.Identity.Web provides the `ITokenAcquisition` service specifically for ASP.NET Core applications to acquire tokens for downstream APIs using the OAuth 2.0 On-Behalf-Of flow. Calling `GetAccessTokenForUserAsync` with the required scopes handles the token exchange automatically, leveraging the incoming user token and client credentials configured in the app. This is the recommended approach when using Microsoft.Identity.Web, as it abstracts the complexity of the OBO flow and integrates seamlessly with the ASP.NET Core authentication pipeline.

Exam trap

The trap here is that candidates may confuse the On-Behalf-Of flow with client credentials flow or app-only authentication, leading them to choose `DefaultAzureCredential` (Option C) or manual token endpoint calls (Option D), while forgetting that ADAL.NET (Option A) is deprecated and not part of the modern Microsoft.Identity.Web stack.

How to eliminate wrong answers

Option A is wrong because ADAL.NET is deprecated and should not be used for new development; it lacks support for modern Microsoft Entra ID features and is replaced by MSAL.NET, which is already integrated into Microsoft.Identity.Web. Option C is wrong because `DefaultAzureCredential` from Azure.Identity is designed for non-interactive scenarios (e.g., managed identities, service principals) and does not support the On-Behalf-Of flow, which requires exchanging a user token for a downstream token. Option D is wrong because manually constructing HTTP POST requests to the token endpoint is error-prone, requires handling token caching, retries, and security details that Microsoft.Identity.Web already manages; this approach is unnecessary and violates the principle of using the provided library abstractions.

Practice this question →

154

MCQhard

A company has an Azure Storage account that stores sensitive data. They need to ensure that all access to the storage account is secured using Microsoft Entra ID authentication and that no storage account keys are used. Which configuration should be applied to enforce this?

A.Enable firewall rules

B.Disable shared key access

C.Enable advanced threat protection

D.Enable soft delete

AnswerB

Disabling shared key access for an Azure storage account is the direct mechanism to prevent clients from authenticating using the storage account's primary or secondary access keys. When this setting is enabled, all requests must authenticate via Microsoft Entra ID (OAuth 2.0 tokens) or through Shared Access Signatures (SAS) that are themselves signed by Microsoft Entra ID or a user delegation key. This effectively enforces a more secure, identity-based authentication model, aligning with the requirement to manage sensitive data by restricting key-based access.

Why this answer

Disabling shared key access (Option B) is the correct configuration because it explicitly blocks all authentication using storage account keys (both primary and secondary), forcing all requests to use Microsoft Entra ID (formerly Azure AD) for authorization. This ensures that only identities with appropriate RBAC roles (e.g., Storage Blob Data Owner) can access the storage account, meeting the requirement to eliminate key-based access entirely.

Exam trap

The trap here is that candidates often confuse network-level security (firewall rules) with authentication enforcement, mistakenly believing that restricting network access alone prevents key-based access, when in fact shared keys can still be used from allowed networks.

How to eliminate wrong answers

Option A is wrong because enabling firewall rules restricts network-level access (IP addresses or virtual networks) but does not prevent authentication using storage account keys; a request from an allowed network could still use a shared key. Option C is wrong because enabling advanced threat protection (Azure Defender for Storage) provides security monitoring and alerts for anomalies (e.g., suspicious access patterns) but does not enforce authentication method or disable key-based access. Option D is wrong because enabling soft delete protects data from accidental deletion by retaining deleted blobs for a retention period, but it has no effect on authentication or authorization mechanisms.

Practice this question →

155

MCQeasy

Refer to the exhibit. You run the Azure CLI command shown. What is the result?

A.Creates a key named MySecret in the vault

B.Deletes the secret named MySecret from the vault

C.Stores a secret named MySecret with the value in the vault

D.Creates a certificate named MySecret in the vault

AnswerC

The az keyvault secret set command writes a new secret into the specified vault, creating the secret named MySecret with the supplied value. It performs a write to the vault's secret store rather than retrieving or deleting anything.

Why this answer

The Azure CLI command `az keyvault secret set --vault-name MyVault --name MySecret --value 'MySecretValue'` is used to create or update a secret in an Azure Key Vault. The `--name` parameter specifies the secret's name, and `--value` provides the secret's value. Since the secret does not exist, it creates a new secret named MySecret with the specified value, making option C correct.

Exam trap

Candidates often confuse the verbs for different Key Vault operations (e.g., 'secret set' vs. 'key create' or 'certificate create'), leading them to misinterpret the command's purpose.

How to eliminate wrong answers

Option A is wrong because the command does not create a 'key'; it creates a 'secret' — Azure Key Vault distinguishes between keys (for cryptographic operations), secrets (for sensitive data like passwords), and certificates. Option B is wrong because the command uses `set`, not `delete`; deleting a secret requires the `az keyvault secret delete` command. Option D is wrong because the command targets secrets, not certificates; creating a certificate requires `az keyvault certificate create` with different parameters.

Practice this question →

156

MCQhard

You are a developer for a fintech company. Your application consists of multiple Azure Functions that process sensitive financial transactions. The functions need to access an Azure SQL Database and an Azure Storage account. Security requirements are: (1) No secrets or connection strings should be stored in application settings or code. (2) Access must be restricted to the specific resources each function needs. (3) All access must be audited. (4) The solution must support local development debugging. You have already enabled system-assigned managed identity for each function app. Which course of action should you take to meet the requirements?

A.Assign a user-assigned managed identity to each function app. Grant the identity access to Azure SQL via Microsoft Entra authentication and to Storage via RBAC. Use service principal for local development.

B.Use the system-assigned managed identity to access Key Vault, where you store the SQL connection string and storage account key. Use the Key Vault SDK in the function code to retrieve them. Enable Key Vault audit logging.

C.Store the SQL connection string and storage account key in Azure Key Vault. Use Key Vault references in function app settings to retrieve them at runtime. Enable Key Vault audit logging.

D.Grant each function app's system-assigned managed identity access to Azure SQL Database using Microsoft Entra authentication (create contained user) and to Azure Storage using RBAC (Storage Blob Data Contributor role). Enable auditing on SQL and Storage. For local development, use Azure CLI to sign in with your developer account and assign it the same RBAC roles.

AnswerD

This correct option implements a truly secretless authentication model by directly granting the function app's system-assigned managed identity permissions to the target resources. For Azure SQL Database, this involves creating a contained user for the managed identity within the database, enabling Microsoft Entra authentication without connection strings. For Azure Storage, it uses Azure RBAC to assign the 'Storage Blob Data Contributor' role. This eliminates the need for any secrets to be stored or retrieved by the application or in Key Vault, and the local development strategy using Azure CLI with developer accounts maintains this secretless approach.

Why this answer

It uses the system-assigned managed identity to directly authenticate to Azure SQL Database via Microsoft Entra authentication (creating a contained database user mapped to the identity) and to Azure Storage via RBAC (assigning the Storage Blob Data Contributor role). This meets the requirement of no secrets or connection strings in code or settings, restricts access to only the needed resources, enables auditing on both SQL and Storage, and supports local development by using Azure CLI to sign in with a developer account assigned the same RBAC roles.

Exam trap

The trap here is that candidates often think Key Vault references or SDK retrieval are acceptable for 'no secrets in code,' but the requirement explicitly forbids storing secrets in application settings or code, and Key Vault references still inject secrets into settings, while SDK retrieval still handles secret values in code.

How to eliminate wrong answers

Option A is wrong because it introduces a user-assigned managed identity unnecessarily when a system-assigned identity is already enabled, and using a service principal for local development adds complexity and does not leverage the same identity model; the requirement is to avoid secrets, but a service principal requires managing a client secret or certificate. Option B is wrong because it stores connection strings and keys in Key Vault and retrieves them via SDK in code, which violates the requirement of not storing secrets in application settings or code (the SDK call still retrieves a secret at runtime). Option C is wrong because Key Vault references in function app settings still resolve to connection strings and keys that are injected as environment variables, which are effectively secrets in settings; this does not meet the 'no secrets or connection strings stored in application settings' requirement.

Practice this question →

157

MCQmedium

Multiple teams need different levels of access to the same Azure Key Vault: the DevOps team needs to create and rotate secrets, the application team needs read-only secret access, and the auditing team needs list-only access. The security team wants audit logs of all access decisions and the ability to manage permissions through a single system. What access model should the developer recommend?

A.Use Azure RBAC for Key Vault with role assignments scoped per team: Key Vault Secrets Officer for DevOps, Key Vault Secrets User for the app team, and Key Vault Reader for auditing

B.Create separate access policies for each team with the minimum required permissions

C.Create a separate Key Vault per team to enforce isolation between access levels

D.Issue shared access signatures for each team scoped to the operations they need

AnswerA

RBAC assignments are integrated with Azure's identity and access management plane. All access decisions are logged in Azure Activity Log, fulfilling the audit requirement. Roles can be assigned at vault scope or narrower scopes. RBAC policies are managed centrally in Azure IAM, consistent with how all other Azure resources are governed.

Why this answer

Azure RBAC for Key Vault provides a unified, centralized access management system that meets all requirements. The Key Vault Secrets Officer role allows DevOps to create and rotate secrets, the Key Vault Secrets User role grants read-only access to the application team, and the Key Vault Reader role provides list-only access for auditing. Additionally, RBAC integrates with Azure Monitor to deliver audit logs of all access decisions, satisfying the security team's need for a single management plane.

Exam trap

The trap here is that candidates may confuse the older Key Vault access policies (which are vault-specific and lack centralized audit integration) with Azure RBAC, or incorrectly assume that SAS tokens can be applied to Key Vault, when in fact SAS is exclusive to Azure Storage services.

How to eliminate wrong answers

Option B is wrong because separate access policies per team would require managing permissions individually for each vault and do not provide a single system for managing permissions across teams, nor do they natively integrate audit logs of access decisions as seamlessly as RBAC. Option C is wrong because creating a separate Key Vault per team violates the requirement for a single system to manage permissions and introduces unnecessary complexity and cost, while still not providing a unified audit trail. Option D is wrong because shared access signatures (SAS) are not supported for Azure Key Vault; SAS tokens are used for Azure Storage, not for controlling access to secrets, keys, or certificates in Key Vault.

Practice this question →

158

MCQhard

You are configuring a managed identity for an Azure App Service to access Azure Key Vault. The identity has been assigned, but the app receives a 403 Forbidden when trying to retrieve a secret. What is the most likely cause?

A.The app is using the wrong endpoint

B.The managed identity is not enabled in the App Service

C.The managed identity lacks an access policy or RBAC role in Key Vault

D.The Key Vault firewall is blocking the request

AnswerC

Assigning the identity only creates the principal in Microsoft Entra ID. Key Vault authorises access separately through access policies or Azure RBAC roles, so without a granted secret-get permission the data-plane request returns 403 Forbidden.

Why this answer

Azure Key Vault uses either access policies or Azure RBAC to authorize requests. When a managed identity is assigned to an App Service but no corresponding access policy or RBAC role (e.g., 'Key Vault Secrets User') is granted in Key Vault, the identity has no permissions to read secrets, resulting in a 403 Forbidden response. The 403 indicates the request reached Key Vault but was denied due to missing authorization.

Exam trap

The trap here is that candidates often confuse a 403 Forbidden with a network-level firewall block, but in Azure Key Vault, a 403 typically indicates an authorization failure (missing access policy or RBAC role), not a firewall issue, especially when using a managed identity.

How to eliminate wrong answers

Option A is wrong because using the wrong endpoint (e.g., incorrect vault URL or secret path) would typically result in a 404 Not Found or 400 Bad Request, not a 403 Forbidden. Option B is wrong because if the managed identity were not enabled in the App Service, the app would receive a 400 Bad Request or an authentication failure (e.g., 'ManagedIdentityCredential authentication failed'), not a 403 from Key Vault. Option D is wrong because if the Key Vault firewall were blocking the request, the app would receive a 403 Forbidden with a message like 'Access denied due to IP firewall rules', but the scenario describes a managed identity, which is a trusted Azure service and can bypass the firewall if the 'Allow trusted Microsoft services' setting is enabled; the 403 here is specifically about missing permissions, not network-level blocking.

Practice this question →

159

MCQhard

You are using Azure API Management (APIM) to expose a REST API. The backend API requires mutual TLS (client certificate) for authentication. The client certificate is stored in Azure Key Vault. You need to configure APIM to use this certificate when calling the backend, without exposing the certificate contents in the policy files. Which APIM feature and policy should you use?

A.Use the authentication-certificate policy with a named value that references the Key Vault certificate.

B.Use the authentication-managed-identity policy to authenticate to the backend.

C.Upload the client certificate directly to APIM's Certificate store and reference it in the policy.

D.Use a JavaScript policy to fetch the certificate from Key Vault and attach it.

AnswerA

This is the correct approach. The authentication-certificate policy is specifically designed to present a client certificate to a backend service for mutual TLS authentication. By using a named value configured to reference a Key Vault secret of type 'certificate', APIM securely retrieves the certificate's private key at runtime without exposing it in configuration. This method ensures secure storage, automatic rotation capabilities, and simplified management of client certificates.

Why this answer

The `authentication-certificate` policy in Azure API Management can reference a client certificate stored in Azure Key Vault via a named value. Named values securely store secrets and can point to Key Vault certificates without exposing the certificate contents in policy files. This allows APIM to present the certificate during mutual TLS authentication to the backend API.

Exam trap

The trap here is that candidates may confuse the `authentication-managed-identity` policy with certificate-based authentication, or assume that uploading the certificate directly to APIM is equivalent to using Key Vault, but the question explicitly requires avoiding exposure of certificate contents in policy files, which only the named value approach with Key Vault reference achieves.

How to eliminate wrong answers

Option B is wrong because `authentication-managed-identity` policy authenticates APIM to a backend using Azure AD tokens, not client certificates; it cannot satisfy mutual TLS requirements. Option C is wrong because uploading the certificate directly to APIM's Certificate store exposes the certificate contents in the APIM instance and requires manual management, whereas the requirement is to avoid exposing certificate contents in policy files and leverage Key Vault. Option D is wrong because using a JavaScript policy to fetch the certificate from Key Vault would expose the certificate contents in the policy code and is not the recommended or secure approach; APIM provides built-in integration with Key Vault via named values.

Practice this question →

160

MCQmedium

You are developing a web app that authenticates users via Microsoft Entra ID. The app needs to call a downstream API on behalf of the signed-in user. Which OAuth 2.0 flow should you implement?

A.Client credentials flow

B.Implicit flow

C.Authorization code flow with PKCE

D.Device code flow

AnswerC

The Authorization Code flow with PKCE (Proof Key for Code Exchange) is the recommended and most secure OAuth 2.0 flow for web applications, including single-page applications and traditional web apps. It involves exchanging an authorization code for an access token at the backend, preventing the token from being exposed in the browser. PKCE further enhances security by mitigating authorization code interception attacks, ensuring that only the legitimate client application can exchange the code for tokens, making it ideal for user-authenticated API calls.

Why this answer

The authorization code flow with PKCE is the correct choice because the app needs to authenticate a signed-in user and then call a downstream API on their behalf. This flow securely exchanges an authorization code for an access token, and PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks, which is essential for public clients like web apps. It is the recommended OAuth 2.0 flow for single-page apps and native apps, but also applicable to web apps that require high security.

Exam trap

The trap here is that candidates often confuse the client credentials flow (Option A) with the need to call a downstream API, but they forget that the client credentials flow does not act on behalf of a user, only the application itself, which fails the 'on behalf of the signed-in user' requirement.

How to eliminate wrong answers

Option A is wrong because the client credentials flow is designed for server-to-server authentication without a user context, using the application's own identity, not the signed-in user's identity. Option B is wrong because the implicit flow is deprecated due to security risks (e.g., access tokens exposed in the URL fragment) and is not recommended for calling downstream APIs; it lacks PKCE support. Option D is wrong because the device code flow is intended for devices with limited input capabilities (e.g., smart TVs, IoT devices) and requires a separate browser to authenticate, which is not suitable for a standard web app scenario.

Practice this question →

161

MCQhard

You are developing a web API hosted on Azure App Service. The API must authenticate requests using Microsoft Entra ID OAuth 2.0 bearer tokens. You want to validate the token in your ASP.NET Core API code with minimal custom validation logic. Which library should you use?

A.Microsoft Authentication Library (MSAL)

B.Azure Identity client library

C.Microsoft.Identity.Web

D.Azure Management Libraries for .NET

AnswerC

Microsoft.Identity.Web is an ASP.NET Core library specifically engineered to simplify the integration of web APIs and web applications with Microsoft Entra ID. It provides out-of-the-box middleware and services for validating incoming bearer tokens, handling claims transformation, and enforcing authorization policies based on scopes and roles. This library significantly reduces the boilerplate code required for secure API development by abstracting away the complexities of OpenID Connect token validation.

Why this answer

Microsoft.Identity.Web is the correct choice because it provides a high-level, opinionated library that integrates directly with ASP.NET Core's authentication pipeline, handling token validation, scopes, and app roles with minimal custom code. It abstracts away the complexity of JWT bearer token validation against Microsoft Entra ID, including automatic OpenID Connect discovery and token signature verification.

Exam trap

The trap here is that candidates often confuse MSAL (for token acquisition) with Microsoft.Identity.Web (for token validation), or assume the Azure Identity library handles all authentication scenarios, when it is actually focused on service-to-service authentication and Azure SDK credentials.

How to eliminate wrong answers

Option A is wrong because MSAL is designed for acquiring tokens from Microsoft Entra ID, not for validating incoming bearer tokens in a web API. Option B is wrong because the Azure Identity client library provides credential types for authenticating to Azure services, not for validating OAuth 2.0 bearer tokens in an ASP.NET Core API. Option D is wrong because Azure Management Libraries for .NET are used for managing Azure resources (e.g., creating VMs, configuring App Service), not for token validation.

Practice this question →

162

MCQmedium

Your company uses Azure Key Vault to store secrets. You need to ensure that only a specific Microsoft Entra ID application can read a particular secret, while other applications are denied access. You want to apply the principle of least privilege. Which access control method should you configure?

A.Assign the application to the Key Vault Contributor RBAC role

B.Assign the application to the Key Vault Secrets User RBAC role at the secret scope

C.Use Key Vault access policies

D.Use managed identity and assign the Key Vault Secrets User role at the vault scope

AnswerB

The Key Vault Secrets User role is a data plane role specifically designed to grant read access to secret contents. By assigning this role at the secret scope, meaning targeting the specific secret resource (e.g., "/secrets/{secretName}"), the application is precisely authorized to retrieve only that individual secret. This approach perfectly aligns with the principle of least privilege, providing the minimum necessary access for the application's requirement.

Why this answer

Azure RBAC allows you to assign the Key Vault Secrets User role at the secret scope, which grants read access exclusively to the specified Microsoft Entra ID application for that particular secret. This aligns with the principle of least privilege by restricting access to only the necessary secret, without granting broader permissions at the vault level.

Exam trap

The trap here is that candidates often confuse vault-scoped access policies or RBAC roles with secret-scoped RBAC, mistakenly thinking they can achieve per-secret isolation with access policies, when in fact only RBAC at the secret scope provides that granularity.

How to eliminate wrong answers

Option A is wrong because the Key Vault Contributor RBAC role grants management-level permissions (e.g., creating and deleting secrets) rather than read access, violating the least privilege requirement. Option C is wrong because Key Vault access policies operate at the vault scope and cannot be scoped to an individual secret; they would grant the application access to all secrets in the vault. Option D is wrong because assigning the Key Vault Secrets User role at the vault scope grants read access to all secrets in the vault, not just the specific secret, and using a managed identity is unnecessary when a specific application identity is already specified.

Practice this question →

163

MCQmedium

A background service must call Microsoft Graph without a signed-in user. Which Microsoft identity platform permission model is required? The design must avoid adding custom operational scripts.

A.Password hash synchronization

B.Delegated permissions only

C.Device code flow

D.Application permissions with client credentials flow

AnswerD

Application permissions allow an application to access data in Microsoft Graph as itself, without a user context, making them ideal for background services or daemon applications. When combined with the client credentials flow, the application authenticates directly to Azure AD using its own credentials (e.g., client secret or certificate) to obtain an access token. This token grants the application the specific permissions it has been configured for, enabling it to call Microsoft Graph autonomously and fulfill the requirement of operating without a signed-in user.

Why this answer

Application permissions with the client credentials flow are required because the background service must call Microsoft Graph without a signed-in user. This flow uses OAuth 2.0 client credentials grant (RFC 6749) where the service authenticates as itself using a client secret or certificate, not on behalf of a user. Delegated permissions (Option B) always require a signed-in user context, making them unsuitable for unattended background services.

Exam trap

The trap here is that candidates confuse 'delegated permissions' (which require a user) with 'application permissions' (which do not), often selecting Option B because they think 'permissions' alone suffices, ignoring the 'without a signed-in user' constraint.

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, not a permission model for calling Microsoft Graph. Option B is wrong because delegated permissions require a signed-in user to delegate the service's access; a background service without a user cannot use delegated permissions. Option C is wrong because the device code flow is designed for devices with limited input capabilities (e.g., smart TVs, IoT) and still requires a signed-in user to authenticate interactively, not suitable for an unattended background service.

Practice this question →