Key Vault: two planes, and the role that misleads

Key Vault questions look easy and are not, because access to a key vault runs
through two completely separate doors and the roles for one grant nothing on the
other.

Control plane and data plane

"The control plane is where you manage Key Vault itself. Operations in this
plane include creating and deleting key vaults, retrieving Key Vault properties,
and updating access policies. The data plane is where you work with the data
stored in a key vault. You can add, delete, and modify keys, secrets, and
certificates."

And the sentence that matters: the access controls for the two planes work
independently.

So a role that lets you manage the vault does not let you read what is in it. Which
brings us to the distractor.

Key Vault Contributor grants no access to secrets

Microsoft says it plainly:

"The Key Vault Contributor role is for control plane operations only to manage
key vaults. It does not allow access to keys, secrets and certificates."

If a question asks which role lets an application read a connection string, and
Key Vault Contributor is one of the options, it is there to be chosen by anyone
skimming for the word "Contributor".

The data-plane roles, narrowest first

Key Vault Reader — metadata only. Can see that a secret exists; "cannot read
sensitive values such as secret contents or key material."

Key Vault Secrets User — reads secret contents, including the secret portion of
a certificate with a private key. This is the runtime role for an agent.

Key Vault Crypto User — performs cryptographic operations using keys. The key
itself never leaves the vault.

Key Vault Certificate User — reads entire certificate contents.

Key Vault Secrets Officer — any action on secrets except managing permissions.
This is a deployment-pipeline role, not a runtime one.

Key Vault Administrator — all data-plane operations on everything in the vault,
but cannot manage the vault resource or role assignments.

Notice how cleanly Secrets User and Crypto User express a distinction worth
carrying: you retrieve a secret, so it travels; you send work to a key, so it
does not. Anything you can express as the second is structurally safer.

The escalation path

This is the part worth remembering beyond the exam.

"If a user has Contributor permissions to a key vault control plane, the user
can grant themselves access to the data plane by setting a Key Vault access
policy. You should tightly control who has Contributor role access to your key
vaults."

So control-plane Contributor is not "no access to secrets". It is "no access to
secrets yet". Anyone who can change access policy can give themselves whatever
they want. That is a real escalation path, documented by Microsoft, and it means
control-plane access to a vault holding production credentials is itself sensitive.

Three more facts that turn up in scenarios

RBAC is now the default. "Starting with API version 2026-02-01, Azure RBAC is
the default access control model for newly created key vaults." Access policies
are the legacy model.

Switching between the models is an outage risk. "Setting the Azure RBAC
permission model invalidates all access policies permissions. It can cause outages
when equivalent Azure roles aren't assigned." Migrate deliberately, with the role
assignments in place first.

Object-scope assignments do not isolate application teams. You can assign
access to an individual secret, but Microsoft answers the isolation question
directly: administrative operations like network access control, monitoring and
object management all require vault-level permissions, which exposes information
across teams. The recommendation is a vault per application per environment,
with roles at vault scope.

The trap

The best secret is no secret at all.

Managed identity removes the credential entirely. On-behalf-of removes the need for
a service credential, because the call runs as the user. Project connections hold
configuration centrally. Toolboxes centralise credential management so one
credential exists in one governed place instead of twelve.

Count how many secrets you can delete before you improve how you store them. A
beautifully governed vault full of secrets that never needed to exist is a tidy
kind of failure.