CCNA Implement Azure security Questions — Page 3 of 3

151

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 →

152

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

Access policies or RBAC roles are required to authorize the identity to read secrets.

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 →

153

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 →

154

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 →

155

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 →

156

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 →

157

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 →