Connect to and consume Azure services and third-party services →hardMultiple ChoiceObjective-mapped

AZ-204 Practice Question: Connect to and consume Azure services and third-party services

Exhibit

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2022-07-01",
  "name": "myKeyVault",
  "location": "[resourceGroup().location]",
  "properties": {
    "sku": {
      "family": "A",
      "name": "standard"
    },
    "tenantId": "[subscription().tenantId]",
    "accessPolicies": [],
    "enabledForDeployment": false,
    "enabledForDiskEncryption": false,
    "enabledForTemplateDeployment": false,
    "enableSoftDelete": true,
    "softDeleteRetentionInDays": 90,
    "enableRbacAuthorization": true
  }
}

Refer to the exhibit. You deploy the ARM template to create an Azure Key Vault. After deployment, you attempt to add an access policy to grant a user 'Get' secret permissions using the Azure portal, but the option is grayed out. What is the most likely reason?

⚠ Common exam trap

Candidates often confuse soft delete (which only affects deletion behavior) with RBAC authorization, assuming that soft delete or other boolean properties block access policy changes, when in fact the 'enableRbacAuthorization' property is the direct cause.

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

✓

RBAC authorization is enabled, so access policies are not used

When Azure Key Vault is configured to use Azure RBAC (Role-Based Access Control) for authorization, the traditional access policy UI is disabled. The ARM template in the exhibit sets 'enableRbacAuthorization' to true, which switches the vault's authorization model from vault-level access policies to Azure RBAC roles. In this mode, you must assign roles (e.g., Key Vault Secrets User) via Azure RBAC instead of adding access policies.

Answer analysis

Option-by-option breakdown

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

✗
The vault is disabled due to 'enableSoftDelete'
Why it's wrong here
Azure Key Vault's 'enableSoftDelete' property ensures that deleted vaults and vault objects (keys, secrets, certificates) are retained for a configurable period, preventing accidental or malicious permanent data loss. This feature is a data protection mechanism and does not, by itself, disable the operational functionality of the Key Vault or prevent access policy modifications. A vault remains fully functional with soft delete enabled, allowing all administrative and data plane operations.
✗
The property 'enabledForDeployment' is set to false
Why it's wrong here
The 'enabledForDeployment' property in Azure Key Vault specifically grants Azure Virtual Machines permission to retrieve secrets (like passwords or connection strings) stored in the vault when they are deployed. Setting this property to 'false' only prevents VMs from accessing secrets during deployment, but it has no impact on the ability to define or modify access policies for other principals, such as users, groups, or service principals. It is a very specific authorization setting, not a general vault disablement or access policy blocker.
✗
Soft delete is enabled, which prevents access policy changes
Why it's wrong here
Enabling soft delete for an Azure Key Vault is a critical security measure designed to protect against permanent data loss by retaining deleted items for a specified duration. This feature operates independently of the vault's access control mechanisms. Soft delete does not impose any restrictions on the ability to create, modify, or delete access policies within the vault; these operations are governed by the caller's permissions, not by the soft delete status.
✓
RBAC authorization is enabled, so access policies are not used
Why this is correct
When an Azure Key Vault is configured with 'enableRbacAuthorization' set to 'true', it explicitly switches its data plane access control model from vault-specific access policies to Azure Role-Based Access Control (RBAC). In this configuration, traditional Key Vault access policies become ineffective and are ignored. All permissions for data plane operations, such as getting, setting, or deleting keys and secrets, must then be managed exclusively through Azure RBAC role assignments at the vault, resource group, or subscription scope.

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 Practice Question: Connect to and consume Azure services and third-party services

Exhibit

Why each option matters

Option-by-option breakdown

Access Control Model Comparison

Related to this question