Define and scope encrypted secrets and configuration variables at organisation, repository and environment levels.

A repository inherits an organisation secret named API_TOKEN that points at a shared staging service. One repository must instead use a production token for the same secret name in its deploy workflow, without changing the shared organisation value used by every other repository. How should an administrator make the production value take effect in that one repository?

steps:
  - run: ./deploy.sh
    env:
      API_TOKEN: ${{ secrets.API_TOKEN }}

• AEdit the organisation secret API_TOKEN to hold the production value and restrict its repository access list to only the deploy repository, so the shared name resolves correctly there.
• BCreate a repository secret named API_TOKEN holding the production value in the deploy repository, because a repository secret of the same name takes precedence over the inherited organisation secret.check_circle Correct
• CAdd a step that reads the organisation API_TOKEN and overwrites it at runtime by writing the production value to GITHUB_ENV, so later steps in the job see the production credential instead.
• DCreate an environment secret named API_TOKEN in a new environment and reference that environment from the deploy job, because environment secrets are the only tier that can shadow an organisation secret.

Why A is wrong: Tempting because it keeps one secret name, but editing the organisation value changes what every other repository receives, and narrowing access would simply remove the secret from the repositories that still need staging.

Why B is correct: When a repository secret and an organisation secret share a name, the repository secret wins for that repository, so the production value applies there while every other repository keeps the unchanged organisation staging value.

Why C is wrong: Tempting because GITHUB_ENV does override an env value for later steps, but it requires embedding the production secret in workflow logic rather than secure storage and does not change which secret the repository is scoped to.

Why D is wrong: Tempting because environment secrets do override on name and add gating, but claiming they are the only overriding tier is wrong, and spinning up an environment adds protection rules the requirement never asked for.