What's changed: New GH-100 Chapter 4 (governance & runners = distribute reusable components, org Actions policy [allow list/require SHA/fork-PR approval], runner groups/hosted-vs-self-hosted, IP allow lists/Azure private networking, performance monitoring [label mismatch/auto-scaling]; encrypted secrets = org/repo/environment scope and precedence, org-level central management, REST API automation, third-party vault integration (OIDC runtime fetch))
4.2Encrypted Secrets and Third-party Vault Integration
Understand defining the scope and access of secrets, configuring secrets at organization and repository levels, and integrating third-party vaults (secret management platforms)—from an admin’s view.
Workflows use secrets (API tokens, connection info) for deploys and external integrations. Admins govern these so they’re accessed only within a minimal scope and don’t leak. GH-100 tests secret scope and access, org/repo-level configuration, and third-party vault integration.
4.2.1Secret scope and access
GitHub Actions secrets scope at three levels—organization, repository, environment—with same-name resolution narrower scope wins (environment > repo > org) (shared with GH-200). Organization-level secrets can be shared across repos with restricted accessible repositories. Environment secrets combine with environment protection rules (required reviewers) to be used only for production deploys. Admins design to "expose minimal secrets only to the workflows that need them."
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.