GH-200 - Manage GitHub Actions for the enterprise (24% of the exam) - Section 4.6

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

Define encrypted secrets and configuration variables at organisation, repository, and environment levels and understand which scope takes precedence. Choose the appropriate level based on sharing requirements and least-privilege principles.

organisation secretsrepository secretsenvironment secretsconfiguration variables

Practice question for this objective

Free sampleManage GitHub Actions for the enterprisemedium

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. 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.

Override an inherited organisation secret in one repository by defining a repository secret of the same name, which takes precedence there. GitHub resolves a secret reference by precedence: a repository secret overrides an organisation secret of the same name, and an environment secret overrides both for jobs that target that environment. Defining a repository secret named API_TOKEN changes the value only for that repository while leaving the organisation secret intact for all others, which is exactly the scoped change required without runtime workarounds.

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.

See more GH-200 practice questions, answers explained.

Exam traps in Manage GitHub Actions for the enterprise

Answers that look right on this material and are not. Each one is a distractor from a different question in the GH-200 bank for this domain.

It resolves to eu-west, because an organisation variable always takes precedence over a repository variable of the same name so that central configuration cannot be overridden locally.
Why it is wrong: This is tempting because central governance often wins, but variable precedence runs the other way. The repository level is more specific, so eu-west does not override the local us-east value here.
When all three tiers define DEPLOY_KEY, the organisation secret wins because organisation scope is the broadest and broader scope is given priority during resolution by the runner.
Why it is wrong: Tempting because organisation scope is broadest, but resolution favours the most specific tier, so the organisation value is the first to be shadowed rather than the one that wins.
The All repositories scope can be narrowed afterwards by adding individual exclusions, so an owner picks All and then removes the few repositories that must not receive the secret.
Why it is wrong: Tempting because exclusions sound convenient, but the All scope has no per-repository exclusion list, so withholding specific repositories requires the Selected scope instead.

Examworthy is not affiliated with or endorsed by GitHub. Original, blueprint-aligned practice material only.