3.2. Securing Azure AI Solutions
💡 First Principle: Security on Foundry is layered defense — identity (who can call, via Entra/managed identity not keys), authorization (least-privilege RBAC roles), network (private endpoints/VNet limiting where calls originate), and data protection (customer-managed keys for encryption control). Each layer answers a different question, and exam scenarios usually name the layer by the constraint they describe.
Why care: the planning domain weights security heavily because production AI handles sensitive prompts and data, and a single weak layer undoes the others. The recurring exam pattern is a security requirement that maps cleanly to one layer — "authenticate without storing secrets" (identity), "this service account does too much" (RBAC), "no public internet exposure" (network), "we must control and audit encryption keys" (data protection).
⚠️ Common Misconception: "API keys are the normal, recommended way to authenticate." Keys are the quickstart way and the least secure — they're long-lived shared secrets that leak. Microsoft Entra ID with managed identity is the recommended default; if keys must exist, they belong in Key Vault, never in code.
