5.1. Implement Secure Azure Solutions

💡 First Principle: Secrets and configuration are different substances that demand different containers. A secret grants access — whoever holds it is your application, so it needs guarding, auditing, versioning, and rotation. Configuration shapes behavior — it needs centralizing, labeling, and refreshing. Store each in the container built for it, and let references connect them, so applications see one uniform settings surface while secrets never leave their vault.

Why care? Because leaked credentials are the most common breach vector for cloud applications, and AI apps are credential-dense: model API keys, database connection strings, queue connections. One key in a container image (3.1.1 warned you) or a git repo, and an attacker bills their tokens to your account.

The mental model: Key Vault is the office safe — few things inside, every opening logged, combination changes on schedule. App Configuration is the settings binder on the shelf — everything about how the office runs, organized with labeled tabs per environment. The binder may say "the API key is in the safe, slot 3" — a reference — but never contains the key itself.

⚠️ Common Misconception: "App settings are encrypted at rest, so storing secrets there is as good as Key Vault." Encryption at rest isn't the threat model — control-plane access is. Anyone who can read the app's configuration reads the secret, with no audit trail, no versioning, no rotation story. Key Vault adds RBAC-scoped access, per-access audit logs, versions, and rotation hooks; Key Vault references (3.1.3, 4.2.2) give you vault security with app-setting convenience.