Lab 04: Practice Questions

---

Scenario-Based Questions

Question 1

Scenario: You have an Azure Function that needs to read secrets from Key Vault. You want to avoid storing any credentials in code or configuration.

What should you use?

A) Service Principal with client secret stored in app settings
B) Service Principal with certificate
C) Managed Identity
D) User account with delegated permissions

Answer

C) Managed Identity

Explanation: Managed Identity is the best practice for Azure resource-to-Azure resource authentication because:

• No credentials to manage
• No secrets to store
• No certificates to rotate
• Azure handles everything automatically

Azure Functions support both system-assigned and user-assigned managed identities.

---

Question 2

Scenario: You enable system-assigned managed identity on a VM. Later, you delete the VM.

What happens to the managed identity?

A) It remains and can be assigned to another VM
B) It's deleted automatically with the VM
C) It becomes orphaned and must be manually deleted
D) It converts to a user-assigned identity

Answer

B) It's deleted automatically with the VM

Explanation: System-assigned managed identities are tied to the resource lifecycle:

• Created when enabled on the resource
• Deleted when the resource is deleted
• Cannot be transferred to another resource

If you need an identity that survives resource deletion, use user-assigned managed identity.

---

Question 3

Scenario: You have 5 VMs that all need to read from the same Storage Account with identical permissions.

What is the MOST efficient approach?

A) Enable system-assigned identity on each VM and create 5 role assignments
B) Create one user-assigned identity, assign to all 5 VMs, create 1 role assignment
C) Create a service principal and store credentials on each VM
D) Use your admin account's credentials in the application

Answer

B) Create one user-assigned identity, assign to all 5 VMs, create 1 role assignment

Explanation:

• User-assigned identity can be shared across multiple resources
• Only need ONE role assignment on the Storage Account
• Easier to manage and audit
• All VMs use the same identity = same permissions

System-assigned would require 5 separate role assignments (more management overhead).

---

Question 4

Scenario: A VM has system-assigned managed identity enabled. You assigned it the "Storage Blob Data Reader" role on a Storage Account. The application on the VM tries to upload a file and gets "Forbidden" error.

What is the issue?

A) The managed identity is not enabled
B) The role doesn't have upload (write) permissions
C) The Storage Account doesn't support managed identities
D) The application is using the wrong endpoint

Answer

B) The role doesn't have upload (write) permissions

Explanation:

• Storage Blob Data Reader = Read blobs only
• Storage Blob Data Contributor = Read, write, delete blobs

The identity has access but only for reading. To upload, you need Storage Blob Data Contributor role.

---

Question 5

Scenario: Your application code needs to obtain an access token using the managed identity. What URL should the code call?

A) https://login.microsoftonline.com
B) https://management.azure.com
C) http://169.254.169.254/metadata/identity/oauth2/token
D) https://vault.azure.net

Answer

C) http://169.254.169.254/metadata/identity/oauth2/token

Explanation:

• 169.254.169.254 is the Instance Metadata Service (IMDS)
• It's a special IP only accessible from within the VM
• Azure provides this endpoint to return tokens for the managed identity
• Note: It's HTTP (not HTTPS) because it's internal to the VM

The other URLs are:

• A: Azure AD login (not for managed identities)
• B: ARM management endpoint (where you'd USE the token)
• D: Key Vault endpoint (where you'd USE the token)

---

Question 6

Scenario: You have a Key Vault using "Vault access policy" permission model. You assign a managed identity the "Key Vault Secrets User" RBAC role. The identity cannot read secrets.

Why?

A) Key Vault Secrets User doesn't have read permissions
B) RBAC roles don't work when using access policy model
C) Managed identities can only use RBAC, not Key Vault
D) The role assignment takes 24 hours to propagate

Answer

B) RBAC roles don't work when using access policy model

Explanation: Key Vault has TWO permission models:

1. Vault access policy (legacy) - Uses access policies, not RBAC
2. Azure role-based access control - Uses RBAC roles

These are mutually exclusive! If Key Vault is using access policies, RBAC role assignments are ignored.

Solution: Change Key Vault to RBAC mode, or create an access policy instead of a role assignment.

---

Question 7

Scenario: An Azure Function needs to access:

• Key Vault (read secrets)
• Storage Account (read/write blobs)
• SQL Database (read data)

You want to use managed identity. How many role assignments do you need?

A) 1 (one identity can access everything)
B) 3 (one per target resource)
C) 6 (two per resource - one for managed identity, one for the Function)
D) Depends on the RBAC model chosen

Answer

B) 3 (one per target resource)

Explanation: Each target resource needs a role assignment:

1. Key Vault: Key Vault Secrets User
2. Storage Account: Storage Blob Data Contributor
3. SQL Database: db_datareader (SQL level) or SQL DB Contributor (Azure level)

One managed identity on the Function, three role assignments on the target resources.

---

Question 8

Scenario: You're deploying a new version of an application. The old VMs will be deleted and new VMs created. The application needs consistent permissions to a Key Vault.

What is the BEST identity strategy?

A) System-assigned on each VM, recreate role assignments for new VMs
B) User-assigned identity, assign to both old and new VMs
C) Service principal with credentials
D) Azure AD user with password

Answer

B) User-assigned identity, assign to both old and new VMs

Explanation:

• User-assigned identity is independent of VM lifecycle
• Create it once, assign Key Vault role once
• Assign the same identity to new VMs
• When old VMs are deleted, the identity and permissions remain
• New VMs instantly have correct access

System-assigned would require re-creating role assignments for every new VM.

---

Quick Knowledge Check

1. Can a resource have both system-assigned AND user-assigned identities?

   Answer

   Yes - a resource can have one system-assigned identity AND multiple user-assigned identities simultaneously

2. What Azure services support managed identities?

   Answer

   Most Azure PaaS: VMs, App Service, Functions, Logic Apps, AKS, Container Instances, Data Factory, Event Grid, and many more

3. Can managed identities be used outside of Azure?

   Answer

   No - managed identities only work within Azure. For external applications, use service principals with certificates or federated credentials

4. How long do managed identity tokens last?

   Answer

   Typically 24 hours, but the SDK automatically handles token refresh

5. Can you see the password/secret for a managed identity?

   Answer

   No - managed identities have no passwords or secrets you can view. Azure manages authentication completely behind the scenes

---

Design Scenario

Scenario: Your company has a microservices architecture with:

• 3 API services (each in its own App Service)
• 1 shared database (Azure SQL)
• 1 shared cache (Azure Redis)
• 1 shared Key Vault (for all secrets)
• 1 Storage Account (for logging)

Design the managed identity architecture:

Suggested Solution

Option 1: User-assigned for shared resources

Create:

• id-api-shared - User-assigned identity for all APIs

Assignments:

• Assign id-api-shared to all 3 App Services
• Grant id-api-shared:
  • Key Vault Secrets User on Key Vault
  • Storage Blob Data Contributor on Storage Account
  • SQL connection (using contained database user)
  • Redis Data Contributor on Redis Cache

Option 2: Mix of both (better isolation)

Create:

• System-assigned on each App Service (for audit/tracing)
• id-shared-secrets - User-assigned for Key Vault access

Assignments:

• Each App Service has its own system-assigned identity
• Grant each identity specific database permissions (better audit trail)
• Grant id-shared-secrets Key Vault access (shared secrets are OK)
• Grant each system-assigned identity Storage access (logs per service)

Best Practice:

• Use user-assigned for shared resources with identical permissions
• Use system-assigned when you need per-resource audit trails
• Never use the same identity for different security boundaries