What's changed: Deepened AZ-400 Chapter 4 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
4.2Managing Secrets and Credentials
Understand handling secrets safely—Key Vault, variable groups/secret variables, managed identity/workload identity federation, secret scanning, and least privilege. Prevent credential leakage.
The biggest risk is credential leakage. Centralize secrets in Key Vault and go keyless (federation/managed identity) when possible.
4.2.1Secret management
- Key Vault: centralize secrets, passed to pipelines safely via variable group links.
- Secret variables: injected only at runtime, never logged (masked).
- Keyless: eliminate long-lived keys with workload identity federation/managed identity.
- Secret scanning: detect committed secrets (push protection blocks the push); enforce least privilege.
Common on AZ-400: centralize secrets = Key Vault, inject only at runtime = secret variables (not logged), keyless = workload identity federation/managed identity, leak detection = secret scanning/push protection. A leaked credential must be rotated, not just removed from history.
AZ-400 secret management probes "hold no credentials, never leak them, and invalidate immediately if leaked." Centralize secrets in Azure Key Vault, fetching them from pipelines only at runtime via Key Vault-linked variable groups or the Key Vault task; secret variables are masked in logs with issecret=true and never shown in plaintext. Ideally, hold no keys at all (keyless): authorize Azure resources with managed identity for apps/services and workload identity federation (OIDC) for external CI (GitHub Actions / Azure Pipelines service connections) to obtain short-lived tokens, eliminating long-lived client secrets or PATs. Detect/block committed secrets with secret scanning + push protection, set expiry and least scope on PATs/SAS/service principals, and rotate Key Vault keys. If a credential leaks, the rule is that removing it from history is insufficient—you must rotate (invalidate and reissue), since it was already exposed once pushed or logged. Enforce least privilege (only the needed scope/duration). The key is to combine Key Vault centralization, runtime injection, keyless (federation/managed identity), leak prevention via scanning, and rotation on leak to minimize credential risk.
| Concern | Measure | Key point |
|---|---|---|
| Store/pass secrets | Key Vault + variable group link | Inject at runtime; masked in logs |
| Eliminate long-lived keys | Managed identity / workload identity federation | Keyless; short-lived tokens |
| Committed leakage | Secret scanning + push protection | Block push on detection |
| Post-leak response | Rotation (mandatory) | History removal alone is insufficient |
Scenario: Connect from Azure Pipelines to production Azure and external APIs, but eliminate holding/rotating long-lived secrets or PATs. → Make the Azure service connection keyless via workload identity federation (OIDC), and use managed identity for app-runtime Azure access. Put any unavoidable external API keys in Key Vault, injected only at runtime via a variable group link (logs masked). Block committed leakage with secret scanning push protection.
FAQ: Managed identity vs workload identity federation? Managed identity lets workloads running on Azure (VMs/App Service/Functions) access Azure resources keyless. Workload identity federation (OIDC) trusts identities outside Azure (GitHub Actions, other clouds, Kubernetes) to assume Azure roles without a secret. Both are "keyless" means to eliminate long-lived keys.
Exam trap: Treating a leaked credential as "safe once removed from history" is wrong—it was already exposed once pushed/logged, so you must rotate. Also, avoid keeping long-lived service principal secrets or PATs in variables when you could be keyless—choose managed identity/workload identity federation. Never log secrets in plaintext (use secret variables for automatic masking).
4.2.2Section summary
- Secrets = Key Vault + secret variables (not logged)
- Keyless = federation/managed identity / detection = secret scanning
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Centrally store pipeline secrets and reference them safely via variable groups. What?
Q2. Authenticate a pipeline to Azure without storing a long-lived service principal secret. What?
Q3. You want secret variable values to never appear in build logs. How are they handled?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.