3.2.2. Network Isolation and Data Protection
💡 First Principle: Network controls decide where calls may come from (private endpoints and VNet integration remove public internet exposure), and data-protection controls decide who controls encryption (customer-managed keys put key lifecycle in your hands). Both are about reducing blast radius, but they guard different surfaces.
Private endpoints place the Foundry resource on your virtual network so traffic never traverses the public internet; managed network isolation extends this to dependent services and outbound traffic. On data, everything is encrypted at rest by default with Microsoft-managed keys — sufficient for many workloads. Regulated industries often require customer-managed keys (CMK / BYOK) stored in Azure Key Vault, which let you create, rotate, disable, revoke, and audit the keys; when configuring that Key Vault, enable soft-delete and purge protection so a deleted key can't orphan your encrypted data permanently.
| Control | Guards | Use when |
|---|---|---|
| Private endpoint / VNet | Network origin of calls | No public exposure; enterprise isolation |
| Managed network isolation | Outbound + dependent services | Hub/workspace-level lockdown |
| Microsoft-managed keys (default) | Encryption at rest | Standard workloads |
| Customer-managed keys (CMK/BYOK) | Key lifecycle + audit | Regulated industries, key control required |
⚠️ Exam Trap: Default Microsoft-managed encryption is not "no encryption" — data at rest is already encrypted. CMK is only required when the constraint specifically demands control or auditability of the keys. Choosing CMK for a scenario that just says "encrypt data at rest" is over-engineering; that's already covered by default.
Reflection Question: A scenario says "data must be encrypted at rest" with no mention of key control. Why is enabling CMK the wrong answer here, and what requirement phrasing would flip it to the right answer?
