Microsoft Azure services
18 / 24
Microsoft Azure

Encryption & Secrets — Key Vault & Managed Identity

Keep credentials out of code and configuration, and let workloads authenticate with no secret at all.

Key Vault stores three kinds of thing, and the distinction is asked.

A bank vault with a staff pass system. Nobody carries a key to the building; the pass proves who you are at the door, and the vault decides what you may take out.

Key Concepts

1
    secrets      arbitrary strings: connection strings, passwords
    keys         cryptographic keys that NEVER leave the vault --
                 you send data to be signed or wrapped
    certificates TLS certs, with lifecycle and auto-renewal
2
Managed identity is the feature that matters most. An Azure resource gets an Entra identity automatically, so code authenticates with no secret anywhere:
3
    var client = new SecretClient(
        new Uri("https://my-vault.vault.azure.net/"),
        new DefaultAzureCredential());        // no key, no connection string
4
    string conn = client.GetSecret("db-connection").Value.Value;
5
There is nothing to rotate, nothing to leak, and nothing in configuration.
6
    system-assigned  tied to one resource, deleted with it
    user-assigned    standalone, shared by several resources
7
That removes the bootstrap problem every secret store otherwise has: you no longer need a credential to fetch your credentials.
8
Access control has two models, and mixing them up is a common failure:
9
    access policies  the older per-vault list of permissions
    Azure RBAC       roles like "Key Vault Secrets User", consistent
                     with the rest of Azure. The current recommendation.
10
A vault set to RBAC ignores access policies entirely, which is usually why a permission "that is definitely granted" does not work.
11
Soft delete and purge protection are on by default. A deleted secret is recoverable for the retention period; with purge protection nobody — including an administrator — can remove it early. That is protection against a malicious or mistaken delete, and it means a vault name stays reserved after deletion.
12
Keys never leave the vault. You send the data to be wrapped or signed. With Managed HSM the key is in validated hardware, which is what regulated workloads need.
13
Reference secrets rather than copying them. App Service and Container Apps can resolve @Microsoft.KeyVault(...) at runtime, so the secret stays in the vault and never lands in configuration.
@Microsoft.KeyVault(...)
14
What the interviewer is probing.1. "How does managed identity remove the bootstrap problem?" Probing: the chicken and egg. Stalls: "It stores the secret safely." Moves up: without it you need a credential to fetch your credentials; the platform issues a token for the resource's own identity, so nothing is stored at all.
15
2. "Your permission is granted but access is denied. What would you check?" Probing: the two access models. Stalls: "The role assignment." Moves up: whether the vault is in RBAC mode, which ignores access policies entirely — the usual cause.
16
3. "What is the difference between a secret and a key in Key Vault?" Probing: the three object types. Stalls: "They are the same." Moves up: a secret is a value you retrieve; a key never leaves the vault — you send data to be signed or wrapped.
17
4. "Why does a deleted vault name stay reserved?" Probing: soft delete. Stalls: "A bug." Moves up: soft delete keeps it recoverable for the retention period, and purge protection prevents even an administrator removing it early.
Use cases:key-vaultmanaged-identityrbacsoft-deletesecrets