Control plane versus data plane, Azure RBAC versus vault access policies, and the roles apps need.
From Ultra Transcenders AI-200 by Tony Rough (publishing soon)
Azure Key Vault stores three object types and authorises access through either Azure RBAC (recommended) or legacy access policies.
| Object | What it holds | Typical use | Rotation mechanism |
|---|---|---|---|
| Secret | Any string up to 25 KB (passwords, connection strings, API keys) | App credentials for services without Entra ID support | Event Grid near-expiry event plus custom code (often a function) |
| Key | Cryptographic key material for encrypt, decrypt, wrap, sign | Customer-managed keys, signing | Built-in key rotation policy |
| Certificate | X.509 certificate with its key and secret | TLS, client certificates | Automatic renewal through integrated or self-signed issuers |
Secrets carry optional attributes: exp (expiry) and nbf (not before) are informational, enabled controls retrieval, and up to 15 tags can be added. A contentType field (up to 255 characters) hints at how to interpret the value. Each update creates a new version; a secret identifier without a version resolves to the latest.
The control plane (management.azure.com) creates and deletes vaults and sets properties, and is always authorised with Azure RBAC. The data plane (<vault-name>.vault.azure.net) reads and writes secrets, keys and certificates, authorised either by Azure RBAC or by a Key Vault access policy (legacy). From API version 2026-02-01, Azure RBAC is the default permission model for new vaults, matching the portal.
| Built-in role | Data-plane rights |
|---|---|
| Key Vault Secrets User | Read secret contents (including the secret part of a certificate) |
| Key Vault Secrets Officer | Any action on secrets except managing permissions |
| Key Vault Crypto User | Cryptographic operations with keys |
| Key Vault Crypto Officer | Any action on keys, including rotation policy |
| Key Vault Certificates Officer | Any action on certificates except permissions |
| Key Vault Reader | Metadata only; cannot read secret values |
| Key Vault Administrator | All data-plane operations on all objects |
| Key Vault Contributor | Control plane only; no access to keys, secrets or certificates |
| Key Vault Purge Operator | Permanently delete soft-deleted vaults |
These data-plane roles work only when the vault uses the RBAC permission model. Learn recommends one vault per application per environment, with roles assigned at vault scope; per-secret assignments are for narrow cases such as one secret shared between applications. Switching an existing vault to RBAC invalidates every access policy, which can cause outages if equivalent roles aren’t assigned first.
Common trap: Assigning Key Vault Contributor so an app can read secrets - Key Vault Contributor is a control-plane role with no data access; an app that reads secrets needs Key Vault Secrets User (RBAC model) or a Get secrets access policy.
This note is one section of Ultra Transcenders AI-200: Developing AI Cloud Solutions on Azure, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Publishing soon on Amazon in Kindle and paperback editions.
About the book · AI-200 terms in the glossary · All AI-200 study notes
The five Cosmos DB consistency levels, their RU and latency trade-offs, and when to choose each.
How to tell commands, discrete events and telemetry streams apart and pick the right Azure messaging service.
How to define KEDA scalers for queues, topics and other event sources in Container Apps.
What creates a new revision, and how single and multiple revision modes change deployments.
Exact search versus approximate IVFFlat, HNSW and DiskANN indexes, and how to tune each for recall and latency.
The main Redis caching patterns, how to expire and invalidate entries, and the trade-offs of each.
How the Functions hosting plans differ in scaling, networking and cold start, and which to choose.