Key Vault creation in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Key Vault Network Access Configuration

You create an Azure Key Vault and want to restrict access to only your company's on-premises network using a firewall rule. Which configuration will correctly restrict access?

A Disable the firewall and rely on Azure Active Directory authentication only.

B Enable the firewall and add the on-premises public IP address range to the Key Vault's allowed IP addresses.

C Set the Key Vault firewall to allow access from all networks and configure access policies to restrict users.

D Enable the firewall and add the on-premises private IP address range to the Key Vault's allowed IP addresses.

💡 Hint

Think about which IP addresses are visible to Azure services when connecting from on-premises.

Azure Key Vault firewall rules require public IP addresses to restrict network access. Private IP addresses are not routable over the internet and cannot be used in firewall rules.

❓ service_behavior

intermediate

Key Vault Access Policy Behavior

You have a Key Vault with multiple access policies. One policy grants a user read access to secrets. Another policy denies all permissions to the same user. What will happen when the user tries to read a secret?

A The user will have read access because allow policies are cumulative and deny policies do not exist in Key Vault.

B The user will be denied access because deny policies override allow policies.

C The user will have no access because conflicting policies cause an error.

D The user will have read access only if they authenticate with a managed identity.

💡 Hint

Consider how Azure Key Vault combines multiple access policies.

Azure Key Vault access policies are cumulative. There is no deny policy type. If any policy grants permission, the user has that permission.

❓ Configuration

advanced

ARM Template for Key Vault Creation with Soft Delete

Which ARM template snippet correctly creates an Azure Key Vault with soft delete enabled and a 90-day retention period?

A

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2022-07-01",
  "name": "myKeyVault",
  "properties": {
    "enablePurgeProtection": true,
    "softDeleteRetentionInDays": 90
  }
}

B

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2022-07-01",
  "name": "myKeyVault",
  "properties": {
    "enableSoftDelete": true
  }
}

C

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2022-07-01",
  "name": "myKeyVault",
  "properties": {
    "enableSoftDelete": true,
    "softDeleteRetentionInDays": 90
  }
}

D

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2022-07-01",
  "name": "myKeyVault",
  "properties": {
    "enableSoftDelete": false,
    "softDeleteRetentionInDays": 90
  }
}

💡 Hint

Soft delete must be enabled explicitly and retention days set.

Option C correctly enables soft delete and sets retention to 90 days. Option C enables purge protection but does not enable soft delete. Option C disables soft delete. Option C enables soft delete but does not set retention.

❓ security

advanced

Key Vault Managed Identity Access

You want an Azure VM to access secrets in a Key Vault without storing credentials in the VM. Which setup achieves this securely?

A Use a shared access signature (SAS) token to authenticate the VM to the Key Vault.

B Store the Key Vault access key as a secret in the VM's local storage and use it to authenticate.

C Create a user-assigned managed identity and assign it to the VM, then grant it access in the Key Vault access policies.

D Assign a system-assigned managed identity to the VM and grant it access in the Key Vault access policies.

💡 Hint

Consider how Azure manages identities for resources securely.

System-assigned managed identities are tied to the VM lifecycle and allow secure access without credentials. User-assigned identities are possible but require extra management. SAS tokens are not used for Key Vault. Storing keys locally is insecure.

🧠 Conceptual

expert

Key Vault Soft Delete and Purge Protection Behavior

After enabling soft delete and purge protection on a Key Vault, what happens if a user deletes a secret and then attempts to permanently delete (purge) it before the retention period ends?

A The secret is moved to a soft deleted state and cannot be purged until the retention period expires because purge protection is enabled.

B The secret is deleted and purged immediately, but the Key Vault itself cannot be deleted.

C The secret remains accessible and cannot be deleted while purge protection is enabled.

D The secret is immediately and permanently deleted, bypassing soft delete due to purge protection.

💡 Hint

Think about how soft delete and purge protection work together to protect data.

With soft delete enabled, deleted secrets are recoverable for the retention period. Purge protection prevents permanent deletion (purging) until retention expires, protecting against accidental or malicious data loss.