Courseiva
Manage Azure Identities and GovernancemediumMultiple ChoiceObjective-mapped

AZ-104 Manage Azure Identities and Governance Practice Question

An App Service application needs to read secrets from Azure Key Vault. The security team does not want any password, certificate, or client secret stored in application settings, and they want the identity removed automatically if the app is deleted. What should the administrator enable?

⚠ Common exam trap

It's easy for candidates to confuse user-assigned managed identities (which are independent resources with separate lifecycles) with system-assigned managed identities (which are tied to the resource's lifecycle), leading them to choose Option C despite the automatic removal requirement.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

A system-assigned managed identity on the App Service.

A system-assigned managed identity (Option B) is the correct choice because it provides an identity for the App Service that is automatically managed by Azure, tied to the lifecycle of the resource (deleted when the app is deleted), and requires no credentials to be stored in application settings. This allows the app to authenticate to Key Vault using Azure AD tokens without any secrets, satisfying the security team's requirements.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • A service principal with a client secret stored in App Service configuration.

    Why it's wrong here

    A service principal with a client secret stored in App Service configuration is wrong because it reintroduces secret management and rotation into the solution. You would need to create the service principal, generate and configure the client secret, and then periodically rotate it—all of which creates a higher risk of credential leakage. Unlike a managed identity, this approach also requires the App Service to securely store the secret in configuration, which is exactly the credential-storage burden the security requirement aims to avoid.

    When this WOULD be correct

    If the question required using a specific Azure AD application with custom permissions or needed to access resources outside Azure (e.g., on-premises), and the security policy allowed storing secrets in App Service configuration, a service principal with a client secret would be appropriate.

  • A system-assigned managed identity on the App Service.

    Why this is correct

    A system-assigned managed identity on the App Service is the correct approach because Azure automatically creates an identity in Azure AD that is directly tied to the App Service's lifecycle. The app can obtain Azure AD tokens without any stored credentials, and you grant this identity access to Key Vault via an access policy or RBAC. This eliminates the need to manage, store, or rotate secrets in code or configuration, fully satisfying the requirement to read secrets securely.

  • A user-assigned managed identity shared by all applications.

    Why it's wrong here

    A user-assigned managed identity shared by all applications is wrong here because it is a standalone Azure resource with its own lifecycle independent of any individual App Service. While it can be shared, it will not be automatically deleted along with the app, so it leaves behind an orphaned identity that still holds Key Vault permissions. For a single-app scenario, a system-assigned identity is simpler because Azure handles its creation and deletion as part of the app resource itself.

  • A shared access signature stored in Key Vault.

    Why it's wrong here

    A shared access signature stored in Key Vault is incorrect because a SAS token is itself a secret or credential, and storing it in Key Vault simply trades one secret for another. The application still needs a way to authenticate to Key Vault to retrieve the SAS, which would require an additional identity mechanism—defeating the purpose of eliminating credentials. This approach also requires periodic regeneration of the SAS and manual rotation, adding operational overhead that managed identity avoids.

    When this WOULD be correct

    A question asking how to grant time-limited access to a specific blob in Azure Storage from an application, with the requirement to avoid storing keys in code, would make a SAS stored in Key Vault the correct answer.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.

A system-assigned managed identity on the App Service.Correct answer

Why this is correct

A system-assigned managed identity on the App Service is the correct approach because Azure automatically creates an identity in Azure AD that is directly tied to the App Service's lifecycle. The app can obtain Azure AD tokens without any stored credentials, and you grant this identity access to Key Vault via an access policy or RBAC. This eliminates the need to manage, store, or rotate secrets in code or configuration, fully satisfying the requirement to read secrets securely.

A service principal with a client secret stored in App Service configuration.Wrong answer — click to see why

Why this is wrong here

The security team explicitly prohibits storing any password, certificate, or client secret in application settings, and a service principal with a client secret stored in App Service configuration violates this requirement.

★ When this WOULD be the correct answer

If the question required using a specific Azure AD application with custom permissions or needed to access resources outside Azure (e.g., on-premises), and the security policy allowed storing secrets in App Service configuration, a service principal with a client secret would be appropriate.

Why candidates choose this

Candidates may think a service principal is the standard way to access Key Vault, overlooking the managed identity alternative and the security constraint against storing secrets in app settings.

A shared access signature stored in Key Vault.Wrong answer — click to see why

Why this is wrong here

A shared access signature (SAS) is used for granting delegated access to Azure Storage resources, not for authenticating an App Service to Key Vault. It does not provide an identity that can be automatically removed when the app is deleted.

★ When this WOULD be the correct answer

A question asking how to grant time-limited access to a specific blob in Azure Storage from an application, with the requirement to avoid storing keys in code, would make a SAS stored in Key Vault the correct answer.

Why candidates choose this

Candidates may confuse SAS with a secure way to store credentials, or think that storing any token in Key Vault satisfies the requirement of not storing secrets in app settings, without understanding that SAS is for storage access, not identity-based Key Vault access.

Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

About these practice questions

One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.