What's changed: Deepened DP-100 Chapter 1 (ja figures; comparison tables/scenarios/FAQ/traps/deep paragraphs in all sections)
1.3Managing Security, Cost, and Compute
Understand Azure ML operations—authentication/access (Entra/RBAC, managed identity), secrets (Key Vault), networking, compute cost management, and quotas. Operate ML securely and efficiently.
An ML platform must be secured and cost-managed. Azure ML uses Entra/RBAC, managed identity, Key Vault, and compute autoscale.
1.3.1Security and cost management
- Access control: Entra auth + RBAC roles; jobs/endpoints use managed identity to reach other resources.
- Secrets: store connection strings/keys in Key Vault, not hardcoded.
- Cost management: cut cost via cluster autoscale (0 nodes when idle), quotas, low-priority VMs.
- Networking: isolate the workspace with private endpoints when needed.
Common on DP-100: access = Entra/RBAC + managed identity, secrets = Key Vault, cut training cost = cluster autoscale/0 nodes/low-priority VMs, allocation limits = quotas. Managed identity lets jobs access data/registry without credentials.
Access control uses Entra authentication + RBAC (built-in roles like AzureML Data Scientist, AzureML Compute Operator; custom roles if needed) for least privilege. Jobs and endpoints use a managed identity (system/user-assigned) to reach datastores, the registry, and Key Vault without credentials. Secrets (connection strings, API keys) live in Key Vault, which also backs datastore authentication (never hardcode). Networking can isolate the workspace and compute via a managed VNet or private endpoints. Cost optimization centers on training: cluster autoscale (0 nodes when idle), low-priority (Spot) VMs (interruptible, cheap), right-sized VM/GPU selection, quota management (per-subscription/region limits), and stopping idle compute instances. Monitor usage/cost with Application Insights and metrics. This overlaps with general Azure principles (AZ-104/AZ-500), but DP-100 tests ML-resource-specific (compute/datastore/registry) permissions and cost.
| Aspect | Mechanism | Point |
|---|---|---|
| Auth/authz | Entra + RBAC (built-in roles) | Least privilege |
| Resource access | Managed identity | No credentials in code |
| Secrets | Key Vault | No hardcoding |
| Training cost | Autoscale/Spot/quota | 0 nodes when idle |
Scenario: a training job must access Storage and Key Vault secrets without credentials in code. → Assign a managed identity to the workspace/compute and grant least-privilege RBAC roles on Storage and Key Vault. Centralize connection info in a datastore (backed by Key Vault). Run training on an autoscaling cluster that drops to 0 nodes when idle.
FAQ: Q. Safest way for a job to access other resources? → A. Managed identity + RBAC—no credentials in code. Q. How to cut training cost? → A. Cluster autoscale (0 nodes idle), low-priority (Spot) VMs, right-sized VM/GPU, quota management, and stopping unused instances.
Trap: “hardcoding keys in code is a fine, simple way for jobs to access resources securely” is wrong—use managed identity + RBAC (no credentials) and keep secrets in Key Vault. Also “keep the training cluster always-on to save cost” is wrong—autoscaling to 0 nodes when idle is the norm.
1.3.2Section summary
- Security = Entra/RBAC, managed identity, Key Vault
- Cost = autoscale/0 nodes/low-priority VMs, quotas
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. How do Azure ML jobs access data/registry without credentials in code?
Q2. Which setting cuts the cost of a training compute cluster?
Q3. You want to store connection strings/keys securely. Which service does Azure ML integrate with?