Managing Secrets with Azure Key Vault

# Managing Secrets with Azure Key Vault *This article is Part 3, Chapter 3.3 of the **AZ-204 Exam Refresher** series. We cover Azure Key Vault — the centralized secret store that keeps credentials out of your code and configuration files.* --- ## Introduction Even with Managed Identities (Chapter 3.2) eliminating many credentials, you'll still have third-party API keys, TLS certificates, and database passwords that need to live somewhere safe. That somewhere is **Azure Key Vault**. Key Vault is a Hardware Security Module (HSM)-backed service for storing three types of sensitive objects: **Secrets**, **Keys**, and **Certificates**. Think of it as a bank vault for your application's sensitive configuration — with an audit trail, fine-grained access control, and automatic versioning. --- ## Core Concepts ### The Three Object Types | Type | What It Stores | Examples | |---|---|---| | **Secrets** | Arbitrary string values | API keys, passwords, connection strings | | **Keys** | Cryptographic keys for encrypt/decrypt/sign | RSA, EC keys — can be backed by HSM | | **Certificates** | X.509 certificates + private keys | TLS/SSL certs, code-signing certs | ### Provisioning a Key Vault ```bash # Create with RBAC authorization model (recommended over access policies) az keyvault create \ --name myVault \ --resource-group myRG \ --location eastus \ --enable-rbac-authorization true # Add a secret az keyvault secret set --vault-name myVault --name "DbPassword" --value "s