certslothcertsloth
AZ-400/Topic 04

Azure / Expert

Pipeline Identity and Supply-Chain Security

2 min read5 recall promptsReviewed 2026-10-10

Memory hook: A pipeline is a privileged workload; give it a narrow identity and inspect what it consumes.

Must remember

  • Prefer workload identity federation/OIDC or managed identities for supported secretless authentication. Entra service principals, GitHub Apps, GITHUB_TOKEN, PATs and Azure DevOps service connections have different scopes and lifecycles. Restrict audiences, repositories/branches/environments and role assignments.
  • Use Key Vault for supported secrets/keys/certificates and controlled runtime retrieval. Secure files/secret variables still need restricted access; masking is not a complete defence against transformed or intentionally exfiltrated values. Never expose secrets to untrusted PR code.
  • GitHub/Azure DevOps organisations, projects, teams and repositories have their own roles/access levels. Azure RBAC is a separate target permission system. Review outside collaborators, stakeholder access, token expiry and who can edit a privileged pipeline.
  • Scan code, dependencies, secrets, licences and container images. CodeQL/static analysis, Dependabot and GitHub Advanced Security capabilities detect different risks. Defender for Cloud DevOps security connects supported posture evidence; a finding needs triage and remediation ownership.
  • Pin third-party actions/tasks/dependencies, verify provenance and maintain a software inventory/SBOM where required. Use trusted feeds and least-privilege package publication. A build from compromised source can produce a correctly signed malicious artifact.
  • Protect approvals, branch policies and service-connection use from the same untrusted author controlling the build. Log administrative changes, rotate exposed credentials and retain evidence. Separate security policy from application-controlled YAML when the platform supports it.

Choose under exam pressure

Requirement Choice and reason
Avoid storing a deployment secret Supported OIDC/workload identity federation with constrained trust.
Detect a vulnerable transitive dependency Dependency scanning and update review.
Control which pipeline can use production credentials Service-connection/environment permissions and protected configuration.

Traps

  • Log masking is not secret isolation.
  • A signature proves provenance under a key, not benign behaviour.
  • A pipeline editor may effectively control its deployed identity unless boundaries prevent it.

Active recall

1. What should OIDC trust restrict?

Issuer, audience and relevant subject/context such as repository and protected environment.

2. Why scan both source and images?

The final image can contain dependencies or layers not obvious in application source.

3. What is risky about untrusted PRs on persistent runners?

They can inspect or alter retained state and reach privileged networks/credentials.

4. Does a PAT need broad organisation admin scope to build code?

Usually no; grant only the required permissions and duration.

5. Why separate approval policy from editable pipeline code?

To prevent an author from removing the control intended to review their own change.

Sources

CLOSE THE NOTES. EXPLAIN THE CHOICE.

How well could you recall it?

Your next review is based on this answer. Progress stays in this browser.

Search across every published topic.