You have an Azure subscription that contains an Azure key vault named Vault1. In Vault1, you create a secret named Secret1. An application developer registers an application in Azure Active…

Question

Options

• AIn Azure AD, create a role.
• BIn Azure Key Vault, create a key.
• CIn Azure Key Vault, create an access policy.
• DIn Azure AD, enable Azure AD Application Proxy.

• A
  4% (2)
• B
  8% (4)
• C
  87% (46)
• D
  2% (1)

Explanation

Explanation

Creating an access policy in Azure Key Vault (Option C) is the correct approach because Key Vault uses its own access control model where you must explicitly grant an application (identified by its Azure AD service principal/app registration) permission to perform specific operations - such as Get on secrets - before it can retrieve Secret1.

Why the distractors are wrong:

• Option A (Create a role in Azure AD): Simply creating a role in Azure AD doesn't grant access to Key Vault resources; roles alone don't configure Key Vault permissions without being tied to an access policy or RBAC assignment on the vault itself.
• Option B (Create a key in Key Vault): A key is a different cryptographic resource than a secret - creating one does nothing to grant access to an existing secret.
• Option D (Enable Azure AD Application Proxy): Application Proxy is used to provide remote access to on-premises web applications, which is entirely unrelated to granting secret access.

Memory Tip: Think of Key Vault as a locked safe with its own guest list - the access policy is how you add a name to that list. The app registration gives the application an identity in Azure AD, but you still need to tell the vault to trust that identity by creating an access policy.

No community discussion yet for this question.