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."
| Level | Sharing scope | Typical use |
|---|---|---|
| Organization | Shared across repos (restrictable) | Common tokens/config |
| Repository | Whole repository | Repo-specific values |
| Environment | Only during deploy to that environment | Per-environment secrets |
4.3.2Referencing and masking
Reference secrets via the secrets.<name> context and variables via the vars.<name> context. Secrets are auto-masked in logs (shown as *), but transformed output can leak them, so the rule is don’t echo them directly or embed them in expressions. To pass to actions/reusable workflows, use with: (variables) or secrets: (secrets, with inherit allowed). GITHUB_TOKEN is a special secret auto-issued per run and needs no manual registration.
4.3.3Programmatic management via REST API
Secrets and variables can be created/updated/deleted not only via the UI but also via the REST API (or gh CLI), enabling automated inventory and rotation. Writing a secret requires encrypting with a public key before sending, so the plaintext value never lands in logs/API. At scale, automate operations like distributing the same secret to many repos, rotating tokens on a schedule, and revoking a departed member’s access in bulk—via the API.
Common: (1) Sensitive = secrets (secrets.<name>); config = variables (vars.<name>). (2) Scope = org/repo/environment; same name → narrower scope wins (environment > repo > org). (3) Secrets are auto-masked in logs but must not leak via echo/expressions. (4) Environment secrets + protection rules = used only after approval. (5) GITHUB_TOKEN is auto-issued. (6) Create/update/delete via REST API/gh CLI (writes are public-key encrypted); automate rotation.
Watch out: (1) Secrets (sensitive, masked) and variables (non-sensitive, vars) differ—never put secrets in variables. (2) Same-name precedence = narrower scope (environment) wins. (3) Auto-masking isn’t foolproof—transformed output or error messages can leak. (4) Fork PRs don’t receive org/repo secrets by default (to prevent exposure). (5) GITHUB_TOKEN needs no registration and expires per run.
4.3.4Section summary
- Sensitive = secrets (secrets.<name>); config = variables (vars.<name>); scoped at three levels (org/repo/environment)
- Same name → narrower scope wins (environment > repo > org); environment secrets gate via protection rules
- Secrets auto-masked but don’t leak via echo/expressions; GITHUB_TOKEN is auto-issued
- Create/update/delete via REST API/gh CLI (public-key encrypted); automate distribution/rotation
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want an API token used only when deploying to production, available only after approval. Where do you store it?
Q2. The same-named secret is defined at the org, repo, and environment levels. Which one is actually used?
Q3. You must distribute the same deploy token to many repos and rotate it automatically each quarter. What is best?
Q4. Which is a safe practice for handling secrets?
Q5. You want to share a non-sensitive config value (e.g., a target region name) across repos and read it from workflows. Which fits?
Q6. For a PR from an external contributor’s fork, how are org/repo secrets handled by default?
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.