Develop a security and compliance plan
Secrets and Secretless Automation
CoreKeep secret material out of source and logs, use Key Vault or protected files for governed material, and prefer workload identity federation for short-lived cloud access.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
Masking a value after it reaches an untrusted process does not revoke it. Secure automation limits storage, lifetime, scope, exposure path, and the code allowed to request a token.
Must Know
- Azure Key Vault governs secrets, keys, and certificates with independent versions, rotation, network controls, logging, and data-plane authorization.
- Workload identity federation lets GitHub Actions or Azure Pipelines exchange a trusted OIDC assertion for a short-lived Entra token without storing a client secret.
- GitHub OIDC requires `id-token: write` for the job and a federated trust restricted by claims such as repository, branch, environment, or reusable workflow.
- Azure Pipelines Azure Resource Manager service connections support workload identity federation and should be scoped to the required resource boundary.
- Azure Pipelines secure files protect file material such as signing certificates and require explicit pipeline authorization; they are downloaded only for the job.
- Secrets should not appear in command-line arguments, verbose traces, artifacts, caches, process listings, or untrusted pull-request jobs.
- Masking reduces accidental display but does not make arbitrary transformations or already leaked material safe.
Compare and Distinguish
- Key Vault stores managed secret material; a repository or environment secret injects a value; a secure file protects file-shaped material.
- OIDC federation supplies short-lived authentication; a PAT authenticates to DevOps services as a user; a client secret is long-lived application credential material.
Scenario examples
- Scenario: GitHub deploys to Azure without stored credentials. Think: environment-restricted OIDC federation and minimum Azure RBAC.
- Scenario: One pipeline signs binaries. Think: a protected secure file plus restricted pipeline authorization.
Exam traps
- `id-token: write` permits requesting an OIDC token; it does not grant Azure authorization by itself.
- A secret marked secret can still be passed to a malicious script.
- Deleting a secret from current source does not remove historical exposure.
Key takeaways
- Prefer short-lived federated identity over stored cloud credentials.
- Match the storage surface to secret, key, certificate, or secure-file lifecycle.
- Assume untrusted code can exfiltrate every value it receives.
How it works
- Federation validates an external OIDC assertion and issues a short-lived Azure token whose authorization still comes from Azure roles.
- Protected environment or pipeline-resource authorization delays secret retrieval until the approved job reaches that boundary.
Objects and administrative surfaces
- Azure Key Vault object lifecycle, networking, access control, diagnostics, and rotation.
- GitHub Actions environments, secrets, variables, OIDC token permissions, and federated subject claims.
- Azure DevOps service connections, variable groups, Key Vault linkage, secure files, approvals, and pipeline permissions.
When to use it
- Use a secure file when a tool requires a certificate or signing file on disk and no supported vault fetch exists.
Security and governance implications
- Minimize credential audience, repository, environment, job, and step scope; rotate or remove obsolete secrets after federation cutover.
Troubleshooting signals
- For OIDC login failures, compare issuer, subject, audience, environment claim, token permission, Azure role, and target scope.
More detail
- Use Azure Key Vault for centrally rotated secrets, keys, and certificates that authorized workloads retrieve at runtime.
- Grant GitHub id-token: write only where OIDC is needed, and bind Entra federation to the intended repository, branch, or environment claims.
- Use Azure Pipelines secure files for protected file-shaped material when runtime vault retrieval is unavailable.
Ready for the quiz?
- What two sides must trust each other for OIDC federation?
- When is a secure file better than a secret variable?
- Why is log masking not a primary leakage control?
Related objectives
- D4.2.S1 — Implement and manage secrets, keys, and certificates by using Azure Key Vault
- D4.2.S2 — Implement and manage secrets and secretless authentication (for example, workload identity federation/OpenID Connect) in GitHub Actions and Azure Pipelines
- D4.2.S3 — Design and implement a strategy for managing sensitive files during deployment, including Azure Pipelines secure files
- D4.2.S4 — Design pipelines to prevent leakage of sensitive information