Secure, monitor, and troubleshoot Azure solutions practice questions

Key Vault data-plane roles: Secrets User reads values, Secrets Officer manages secrets, Reader sees metadata only.

With the RBAC permission model, access to secret values is granted by data-plane roles. Key Vault Secrets User is the least-privileged role that can read secret contents. Secrets Officer adds write and delete, Key Vault Reader stops at metadata, and Key Vault Contributor manages the vault resource without any data access.

1. Separate the data plane (secret values) from the control plane (the vault resource).
2. Pick the data-plane role that only reads secret contents.
3. Reject roles that add write access or stop at metadata.

Exam tip: Read-only app on an RBAC vault = Key Vault Secrets User.

Writing secret versions needs a role with secret write permissions; Secrets Officer is scoped to secrets only.

Rotation writes a new secret version, so a read-only role isn't enough. Key Vault Secrets Officer covers every secret operation while excluding keys and certificates, which matches the stated restriction. Key Vault Administrator would work but spans all object types, and Key Vault Contributor is control-plane only.

1. List the operations: read a secret and set a new version.
2. Find the narrowest data-plane role with secret write access.
3. Exclude roles that reach keys and certificates or only manage the vault resource.

Exam tip: Rotation code that writes secrets needs Key Vault Secrets Officer, not Secrets User.

Key Vault Contributor is control-plane only, and access policies don't apply to a vault on the RBAC permission model.

Two facts combine. Key Vault Contributor manages the vault resource but grants no data-plane access, which explains the 403. The teammate's fix fails because the vault uses the RBAC permission model, which makes access policies ineffective. The least-privileged data-plane role that reads values is Key Vault Secrets User; role assignments can take a few minutes to apply.

1. Explain the 403: Contributor is a control-plane role.
2. Check the permission model: RBAC vaults ignore access policies.
3. Grant the narrowest data-plane role that reads secret values.

Exam tip: On an RBAC vault, grant data access with Key Vault data roles; Contributor and access policies won't do it.

A secret's exp and nbf attributes are informational; get still returns expired or not-yet-valid secrets.

For secrets, the expiration time marks when data should not be used, but Key Vault doesn't enforce it on get: retrieving an expired secret is allowed so it can be used for recovery. Stopping use of an old credential requires actually rotating it at the source, or disabling the version, not relying on expiry.

1. Note that the read succeeded after expiry from a fresh process.
2. Recall that exp is informational for secrets and get ignores it.
3. Conclude that rotation or disabling is what actually stops use.

Exam tip: Secret expiry is a signal, not a lock: get still returns an expired secret.

Each secret version has its own enabled flag; disabling one version blocks retrieval of it without deleting anything.

The requirement has two halves: the leaked value must be unreadable, and the history must remain. Setting enabled to False on that specific version does both. An expiration date doesn't block get, delete-and-recover restores the same versions, and purge permanently removes the entire secret.

1. Target one version, not the whole secret.
2. Pick the attribute that Key Vault enforces on get: enabled.
3. Reject delete or purge, which act on every version.

Exam tip: To kill one leaked version but keep history, disable that version with update_secret_properties.

set_secret on an existing name adds a new version; update_secret_properties only changes metadata.

Key Vault secrets are versioned. Writing a value to an existing name with set_secret adds a version that becomes the current one, so versionless readers pick it up. update_secret_properties can't change values, deleting first collides with the soft-deleted name, and a new name breaks the readers.

1. Readers use the name without a version, so the name must stay the same.
2. A new value on the same name means a new version.
3. set_secret creates that version; property updates can't.

Exam tip: New value, same name: set_secret adds a version that versionless readers get next.