# Azure Key Vault, Explained Properly

> The one secret most tutorials forget to remove.

- **Format:** short video, 8 steps, ~25 seconds
- **Topic:** Azure Key Vault in one reel — moving every secret out of your config file, discovering you are still holding the one secret that opens the vault, and how a managed identity removes that last one so the count reaches zero.
- **Author:** Suthahar Jegatheesan (MSDEVBUILD)
- **Category:** Azure · Azure Security
- **Published:** 2026-08-15
- **Tags:** azure, azurekeyvault, managedidentity, security, dotnet, devsecops, cloudsecurity, aspnetcore, secretmanagement, microsoftazure, backenddeveloper, az204, cloudengineering, msdevbuild
- **Canonical URL:** https://blog.msdevbuild.com/shorts/azure-key-vault-explained/

---
## What you'll learn

- What Key Vault stores and how your app reads it at runtime
- Why moving secrets to a vault leaves you one secret you did not expect
- How a managed identity removes that last one so the count reaches zero

## Understand it one step at a time

### 1. Six secrets, in git

Six secrets sitting in your config file, in git. Everyone with repo access — past and present — has all of them.

### 2. Move them into the vault

Secrets, keys and certificates move into the vault — three different kinds of credential, one place to manage and audit them.

### 3. Your config still has one

Your config still holds a ClientId and ClientSecret — the one credential that opens the vault. You replaced six secrets with one.

### 4. That is not a fix

That master secret leaks the exact same way the six did, and it still expires — usually at 2am, long after whoever made it left.

### 5. Give the app an identity

DefaultAzureCredential: your az login locally, the app’s managed identity in Azure — same line of code, nothing stored anywhere.

### 6. The vault decides who reads

Grant Key Vault Secrets User — read-only, secrets only — over RBAC, not the older access-policy model. Your laptop gets no role.

### 7. Rotate once. Nobody redeploys

Rotate the secret once; every consumer using the identity just reads the new version. The audit log says who read what, and when.

### 8. Zero secrets in your code

The vault holds the value, the identity holds the door key, and neither one is ever typed into a config file or committed to git.

---

## The takeaway

**Zero secrets in your code.**

Key Vault holds them, a managed identity opens it, and nothing is ever written down.