AZ-305 · Question #12
Case Study 3 - Contoso Existing Environment: Technical Environment The on-premises network contains a single Active Directory domain named contoso.com. Contoso has a single Azure subscription…
Hotspot Explanation: App1 Access to Azure Key Vault Correct Answers: 1. A system-assigned managed identity 2. A role assignment --- Dropdown 1: Authenticate App1 by using -> A system-assigned managed identity Why system-assigned managed identity is correct: The key security…
Question
Exhibits
Answer Area
- Authenticate App1 by using:A certificateA service principalA system-assigned managed identityA user-assigned managed identity
- Authorize App1 to retrieve Key Vault secrets by using:An access policyA connected serviceA private linkA role assignment
Explanation
Hotspot Explanation: App1 Access to Azure Key Vault
Correct Answers:
- A system-assigned managed identity
- A role assignment
Dropdown 1: Authenticate App1 by using -> A system-assigned managed identity
Why system-assigned managed identity is correct:
The key security requirement is: "credentials must be tied to the service instance" and "credentials must NOT be shared between services."
A system-assigned managed identity is automatically created and bound to the lifecycle of one specific App Service instance. When the instance is deleted, the identity is deleted. This satisfies both constraints - the identity is instance-specific and cannot be reused by another service.
Why the others are wrong:
| Option | Why Wrong |
|---|---|
| A certificate | Certificates are credentials you manage manually. They can be exported and shared - violating the "not shared" rule. |
| A service principal | A service principal's client secret or certificate can be copied and shared across services. It's not tied to a specific instance. |
| A user-assigned managed identity | Explicitly designed to be shared across multiple services. This directly violates the "must NOT be shared between services" requirement. |
Dropdown 2: Authorize App1 to retrieve Key Vault secrets by using -> A role assignment
Why a role assignment is correct:
This refers to Azure RBAC (Role-Based Access Control). You assign the managed identity a built-in role such as Key Vault Secrets User on the Key Vault resource. This is Microsoft's current recommended authorization model for Key Vault - it integrates with Azure's unified RBAC plane and provides fine-grained, auditable access control.
Why the others are wrong:
| Option | Why Wrong |
|---|---|
| An access policy | This is the legacy Key Vault authorization model. Still functional, but Microsoft recommends RBAC (role assignments) going forward. Exam questions targeting modern best practices favor role assignments. |
| A connected service | A Visual Studio IDE feature that adds SDK references and config. It is a development-time tool, not a runtime authorization mechanism. |
| A private link | A network feature that routes traffic to Key Vault privately over a VNet. It controls connectivity, not identity-based authorization. |
Key Concept Summary
Managed Identity + RBAC Role Assignment is the standard, secretless pattern for Azure service-to-service authorization. No credentials to rotate, no risk of secret leakage, and access is scoped and auditable per-instance.
Topics
Community Discussion
No community discussion yet for this question.

