What's changed: New GH-200 Chapter 4 (governance = use policies disable/all/GitHub/verified/allow-list, require SHA pinning, reusable-component access settings, fork-PR approval, cascade; runners at scale = GitHub-hosted/self-hosted, runner groups, IP allow lists, preinstalled/toolcache/setup-*, troubleshooting; encrypted secrets & variables = org/repo/environment scope and precedence, secrets/vars, masking, REST API management)
4.3Encrypted Secrets and Variables
Understand the scope and precedence of encrypted secrets and variables at organization, repository, and environment levels, referencing and masking them in workflows and actions, and managing them programmatically via REST APIs.
Store sensitive values (API tokens, passwords) as encrypted secrets and non-sensitive config as variables. Both can be scoped at three levels—organization, repository, and environment. Organization-level entries are shared across repos (you can restrict which repos can access them); environment-level entries are usable only during deploys to that environment (e.g., production).
4.3.1Scope and precedence
When the same-named secret/variable exists at multiple levels, the narrower scope wins—generally "environment > repository > organization," with the environment-level value taking top precedence. This lets you keep a common org default while overriding for a specific environment or repo. Environment secrets combine with the environment’s protection rules (required reviewers, etc.), enabling control like "production secrets are used only after approval."
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.