Managed identities concept in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary benefit of using managed identities in Azure?

Managed identities help Azure services authenticate securely without needing to manage credentials manually. What is the main advantage of this?

A They eliminate the need to store and rotate credentials manually, reducing security risks.

B They allow users to log in to Azure Portal without a password.

C They automatically back up all Azure resources daily.

D They provide unlimited free compute resources for identity management.

💡 Hint

Think about how credentials are handled and the risks involved.

Managed identities remove the need to store credentials in code or configuration, which reduces the chance of leaks and simplifies security management.

❓ Architecture

intermediate

Which Azure service can use a system-assigned managed identity to access Azure Key Vault securely?

You want an Azure service to retrieve secrets from Azure Key Vault without embedding credentials. Which service can use a system-assigned managed identity for this purpose?

A Azure Blob Storage

B Azure Virtual Machine

C Azure CDN

D Azure Traffic Manager

💡 Hint

Consider which services run code and can have identities assigned.

Azure Virtual Machines can have system-assigned managed identities that allow them to authenticate to Azure Key Vault securely without credentials.

❓ security

advanced

What happens if you delete an Azure resource with a system-assigned managed identity?

Consider an Azure resource (like a VM) with a system-assigned managed identity. What is the effect on the managed identity when the resource is deleted?

A The managed identity remains active and can be used by other resources.

B The managed identity is disabled but not deleted.

C The managed identity is converted to a user-assigned managed identity.

D The managed identity is automatically deleted along with the resource.

💡 Hint

Think about the lifecycle of system-assigned identities tied to resources.

System-assigned managed identities are tied to the lifecycle of the resource. When the resource is deleted, the identity is also deleted automatically.

❓ service_behavior

advanced

How does a user-assigned managed identity differ in lifecycle from a system-assigned managed identity?

Compare user-assigned and system-assigned managed identities regarding their lifecycle and reuse.

A User-assigned managed identities cannot be assigned to more than one resource; system-assigned identities can.

B User-assigned managed identities are deleted when the resource is deleted; system-assigned identities persist independently.

C User-assigned managed identities exist independently and can be shared across multiple resources; system-assigned identities are tied to one resource and deleted with it.

D Both user-assigned and system-assigned managed identities are deleted when the resource is deleted.

💡 Hint

Think about identity reuse and independence from resources.

User-assigned managed identities are created as standalone Azure resources and can be assigned to multiple Azure services. They persist beyond the lifecycle of any single resource. System-assigned identities are created for and tied to one resource only.

✅ Best Practice

expert

You want to grant an Azure Function access to an Azure Storage account securely. Which approach follows best practices using managed identities?

Choose the best way to allow an Azure Function to access an Azure Storage account without storing credentials in code.

A Assign a system-assigned managed identity to the Azure Function and grant it the Storage Blob Data Contributor role on the Storage account.

B Create a user-assigned managed identity and embed its client secret in the Azure Function code.

C Store the Storage account key in Azure Function app settings and use it in code.

D Use a shared access signature (SAS) token hardcoded in the Azure Function.

💡 Hint

Consider secure authentication without secrets in code or settings.

Assigning a system-assigned managed identity to the Azure Function and granting it the appropriate role on the Storage account allows secure access without secrets or keys in code or settings.

Practice

1. What is the main purpose of managed identities in Azure?

easy

A. Allow resources to access other services securely without passwords

B. Store user passwords for Azure services

C. Create virtual machines automatically

D. Manage network traffic between resources

Solution

1. Step 1: Understand managed identities purpose

   Managed identities provide a way for Azure resources to authenticate to other services without needing passwords.

2. Step 2: Compare options

   Only Allow resources to access other services securely without passwords correctly describes this purpose. The other options describe unrelated functions.

3. Final Answer:

   Allow resources to access other services securely without passwords -> Option A

4. Quick Check:

   Managed identities = secure access without passwords [OK]

Hint: Managed identities remove password use for resource access [OK]

Common Mistakes:

• Thinking managed identities store passwords
• Confusing managed identities with VM creation
• Assuming managed identities manage network traffic

2. Which syntax correctly enables a system-assigned managed identity in an Azure resource configuration?

easy

A. "managedIdentity": "system"

B. "identity": { "enabled": true }

C. "identity": { "type": "SystemAssigned" }

D. "identity": "system-assigned"

Solution

1. Step 1: Recall correct identity block syntax

   Azure resource config uses an "identity" block with a "type" property set to "SystemAssigned" to enable system-assigned managed identity.

2. Step 2: Validate options

   "identity": { "type": "SystemAssigned" } matches the correct JSON syntax. The other options do not follow Azure's expected configuration format.

3. Final Answer:

   "identity": { "type": "SystemAssigned" } -> Option C

4. Quick Check:

   Correct identity block syntax = "identity": { "type": "SystemAssigned" } [OK]

Hint: Use "identity": { "type": "SystemAssigned" } to enable system identity [OK]

Common Mistakes:

• Using incorrect property names like "enabled"
• Omitting the "type" key
• Using wrong string values like "system" or "system-assigned"

3. Given this Azure resource configuration snippet:

{
  "identity": { "type": "UserAssigned", "userAssignedIdentities": { "/subscriptions/123/resourceGroups/rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/identity1": {} } }
}

What does this configuration do?

medium

A. Enables a system-assigned managed identity for the resource

B. Assigns a user-assigned managed identity named 'identity1' to the resource

C. Disables all managed identities for the resource

D. Creates a new user-assigned identity named 'identity1'

Solution

1. Step 1: Analyze the identity type

   The "type" is "UserAssigned", meaning the resource uses an existing user-assigned identity.

2. Step 2: Check the userAssignedIdentities property

   The resource assigns the existing identity at the given resource ID path, named 'identity1'. It does not create a new identity.

3. Final Answer:

   Assigns a user-assigned managed identity named 'identity1' to the resource -> Option B

4. Quick Check:

   UserAssigned with identity path = Assigns a user-assigned managed identity named 'identity1' to the resource [OK]

Hint: UserAssigned type with identity path means assign existing identity [OK]

Common Mistakes:

• Confusing system-assigned with user-assigned identity
• Thinking the identity is created, not assigned
• Ignoring the userAssignedIdentities property

4. You wrote this Azure resource config to enable a system-assigned managed identity:

{
  "identity": { "type": "systemassigned" }
}

Why does this configuration fail to enable the identity?

medium

A. The resource group name is missing

B. The identity block is missing the "enabled" property

C. User-assigned identities require a different syntax

D. The type value is case-sensitive and must be "SystemAssigned"

Solution

1. Step 1: Check the type value case

   Azure expects "SystemAssigned" with capital S and A. "systemassigned" is invalid due to case sensitivity.

2. Step 2: Validate other options

   Stating that the identity block is missing the "enabled" property is incorrect because "enabled" is not required. User-assigned identities require a different syntax, but this config is for system-assigned. The resource group name is unrelated to this error.

3. Final Answer:

   The type value is case-sensitive and must be "SystemAssigned" -> Option D

4. Quick Check:

   Case-sensitive type value = The type value is case-sensitive and must be "SystemAssigned" [OK]

Hint: Check capitalization of "SystemAssigned" exactly [OK]

Common Mistakes:

• Ignoring case sensitivity in type value
• Adding unnecessary properties like "enabled"
• Confusing system-assigned with user-assigned syntax

5. You want two Azure virtual machines to share the same managed identity to access a database securely. Which approach should you use?

hard

A. Create a user-assigned managed identity and assign it to both VMs

B. Assign a system-assigned managed identity to each VM separately

C. Use a shared password stored in Azure Key Vault

D. Enable managed identity only on one VM and share its credentials manually

Solution

1. Step 1: Understand identity sharing options

   System-assigned identities are unique per resource and cannot be shared.

2. Step 2: Identify user-assigned identity use

   User-assigned managed identities can be created once and assigned to multiple resources, allowing sharing.

3. Step 3: Evaluate other options

   Using shared passwords or manual credential sharing is insecure and against best practices.

4. Final Answer:

   Create a user-assigned managed identity and assign it to both VMs -> Option A

5. Quick Check:

   User-assigned identity allows sharing = Create a user-assigned managed identity and assign it to both VMs [OK]

Hint: Use user-assigned identity to share across multiple resources [OK]

Common Mistakes:

• Trying to share system-assigned identities
• Using passwords instead of managed identities
• Manually sharing credentials insecurely