In GitHub Actions, which secret wins when org, repo, and environment names collide?

## Three scopes, one name GitHub Actions can store a secret at three levels: - **Organization** — defined once for the org, with a visibility setting: all repositories, all private repositories, or a selected list of repositories. - **Repository** — defined on one repository, available to every workflow in it (subject to the fork rule below). - **Environment** — defined on a named environment such as `staging` or `production`, available only to a job that declares `environment: <name>`. When the same name exists at more than one level, the **most specific scope wins**: environment overrides repository, repository overrides organization. There is no merge and no warning — the job simply resolves one value. ## Why this ordering is useful The pattern it enables is one workflow, one secret name, several targets. A deploy job parameterised by environment can be written once: jobs: deploy: environment: ${{ inputs.target }} steps: - run: ./deploy.sh env: API_KEY: ${{ secrets.API_KEY }} Staging and production each define their own `API_KEY`, and the workflow text never mentions which one it is using. Meanwhile an organization-level `API_KEY` can serve every repository that has not overridden it. The corollary matters just as much: **a job with no `environment:` key cannot reach environment secrets at all.** This is the mechanism behind the common review question "how do you make sure only the deploy job can see the production credential?" — you put the credential on the `production` environment, and every job that does not declare that environment resolves the name to nothing (or to a less-privileged repository value). ## Variables follow the same rules Non-sensitive configuration uses the parallel `vars` context, with the same three scopes and the same precedence. `${{ vars.REGION }}` resolves the environment variable definition first, then repository, then organization. Variables are readable in the UI and are printed in logs unmasked, so they are for things like a region name, a URL, or a feature flag — never a credential. Separately, `env:` blocks in workflow YAML have their own precedence that people often conflate with this: a step-level `env` entry overrides the same name at job level, which overrides workflow level. That is ordinary variable shadowing inside the file and is unrelated to where a secret is stored. ## Inheritance across workflow boundaries Secrets do not flow automatically into a reusable workflow called with `workflow_call`. The caller either lists them explicitly under `secrets:` or passes `secrets: inherit`, which forwards the secrets available to the caller. `inherit` is convenient and blunt — it hands the callee everything, so a reusable workflow you do not control should get named secrets instead. A composite action, by contrast, is not a trust boundary in this sense: it runs inside the calling job and can read the job's environment, which is why secrets are passed to it as declared inputs and why third-party actions are pinned. ## Gotchas worth naming in an interview - **Fork pull requests** get no secrets at any scope, so precedence never comes into play there. - **Organization visibility** can silently produce an empty value: the name exists in the org but this repository is not on the selected list. - **Deleted overrides resurface the parent value.** Removing an environment secret does not disable the name; the repository or org value quietly takes over, which can point a production job at a staging credential. - **Names are case-insensitive** and cannot start with `GITHUB_`, so you cannot shadow the built-in namespace. - **You cannot read a secret back** to check which one resolved. Diagnose by scope inspection and by asserting on an effect (for example a step that fails cleanly when the value is empty), not by echoing it. ## How to answer concisely "Narrowest scope wins — environment, then repository, then organization — and environment secrets require the job to declare that environment, which is exactly how you keep production credentials away from build and test jobs."