Implement Azure security →mediumMultiple ChoiceObjective-mapped

AZ-204 Implement Azure security Practice Question

Exhibit

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2022-07-01",
  "properties": {
    "sku": {
      "family": "A",
      "name": "standard"
    },
    "tenantId": "[subscription().tenantId]",
    "accessPolicies": [],
    "enabledForDeployment": false,
    "enabledForDiskEncryption": false,
    "enabledForTemplateDeployment": false,
    "enableSoftDelete": true,
    "softDeleteRetentionInDays": 90,
    "enableRbacAuthorization": true,
    "networkAcls": {
      "defaultAction": "Deny",
      "bypass": "AzureServices",
      "ipRules": [],
      "virtualNetworkRules": []
    }
  }
}

Refer to the exhibit. You are deploying an Azure Key Vault using this ARM template. Your team plans to use RBAC to manage access. The vault must be accessible from Azure services (e.g., Azure VMs) without public IP addresses. After deployment, a developer reports that they cannot access secrets from a VM in the same region, even though the VM has a managed identity with the Key Vault Secrets User role. What is the most likely cause?

⚠ Common exam trap

Candidates often assume 'Azure services' includes all Azure resources like VMs, but in Key Vault network ACLs, it specifically refers to a limited set of platform services, not customer-deployed compute instances.

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

✓

The vault's network ACLs block all traffic except from Azure services, but VMs are not considered Azure services.

The ARM template's network ACLs are configured with a default action of 'Deny' and an exception for 'AzureServices' only. Azure VMs without public IP addresses are not considered part of the 'AzureServices' bypass category; that category is reserved for Azure platform services like Azure Resource Manager or Azure Policy, not for compute instances. Therefore, the VM's traffic is blocked by the firewall, even though it has a managed identity with the correct RBAC role.

Answer analysis

Option-by-option breakdown

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

✗
Soft delete is enabled, which prevents access to secrets until they are recovered.
Why it's wrong here
Azure Key Vault's soft delete feature is designed for data recovery, not access control. When enabled, it retains deleted secrets, keys, and certificates in a recoverable state for a specified retention period, preventing permanent data loss from accidental deletions. However, it does not prevent or block access to *currently active* secrets within the vault; it only affects the lifecycle of *deleted* items.
✗
The accessPolicies array is empty, so RBAC is not working.
Why it's wrong here
When `enableRbacAuthorization` is set to `true` for an Azure Key Vault, the vault exclusively uses Azure Role-Based Access Control (RBAC) for all data plane operations. In this configuration, the `accessPolicies` array within the vault's properties is entirely ignored, as access permissions are managed through Azure roles assigned at the vault, resource group, or subscription scope. Therefore, an empty `accessPolicies` array does not indicate RBAC is not working; rather, it confirms that RBAC is the active authorization model.
✗
The vault name is not unique and conflicts with another vault.
Why it's wrong here
Azure Key Vault names must be globally unique across all of Azure. If a vault name were not unique, the deployment of the Azure Key Vault resource would fail outright with a naming conflict error, preventing the vault from being provisioned in the first place. A non-unique name would not result in a deployed but inaccessible vault; instead, the deployment operation itself would terminate unsuccessfully.
✓
The vault's network ACLs block all traffic except from Azure services, but VMs are not considered Azure services.
Why this is correct
The vault's network ACLs are configured with `defaultAction: Deny` and `bypass: AzureServices`, meaning only traffic from specific Microsoft trusted services can access the vault. Azure Virtual Machines (VMs) are customer-deployed resources within a virtual network, not considered part of the 'Azure services' bypass group for Key Vault network access. Consequently, direct access from a VM requires explicit configuration via virtual network rules or a private endpoint to be permitted.

Quick reference

Access Control Model Comparison

Model	Acronym	Who Controls Access?	Best For
Discretionary Access Control	DAC	Resource owner	Small teams, file shares
Mandatory Access Control	MAC	System / security labels	Classified govt / military
Role-Based Access Control	RBAC	Administrator (via roles)	Enterprise environments
Attribute-Based Access Control	ABAC	Policy engine (user + resource attributes)	Fine-grained, dynamic policies
Rule-Based Access Control	RuBAC	System rules / ACLs	Firewall rules, network ACLs

Go deeper

AZ-204 Implement Azure security Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Access Control Model Comparison

Related to this question