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

Access secrets and variables in workflows and actions and manage them programmatically through the REST API.

Access encrypted secrets and configuration variables within workflow steps using the secrets and vars contexts. Manage secrets and variables programmatically via the GitHub REST API for bulk operations and automation scripts.

secrets in workflowsREST API secretsvariablesprogrammatic management

Practice question for this objective

Free sampleManage GitHub Actions for the enterprisemedium

An auditor asks an engineer to retrieve, in plaintext, the current value of an existing non-sensitive configuration variable named BUILD_REGION through the GitHub REST API. Which statement correctly describes what the relevant Actions REST API can return for this request?

  • AThe get-a-secret endpoint returns the decrypted value of any registered item, so calling it for BUILD_REGION yields the plaintext that the auditor needs.
  • BThe list-variables endpoint returns only an encrypted_value field per variable, so the auditor must decrypt the value with the repository public key after the call.
  • CThe get-a-repository-variable endpoint returns the variable's name and its current value as plaintext, because configuration variables are stored unencrypted and are readable through the variables REST API. Correct
  • DNo Actions REST endpoint can return a stored variable value, so the engineer must add a workflow step that echoes vars.BUILD_REGION and then read it from the run log.
Recognise that configuration variables are stored unencrypted and the variables REST API returns their plaintext value, unlike the secrets API. Configuration variables in GitHub Actions are non-sensitive and stored unencrypted, so the get-a-repository-variable endpoint returns the variable name and its current value as plaintext. The secrets endpoints never return a stored secret value because secrets are sealed against the repository public key, which is the key behavioural difference between the variables and secrets REST APIs.

Why A is wrong: This is tempting because secrets and variables share similar endpoints, but the get-a-secret response only returns metadata such as the name and timestamps, never the decrypted value, and BUILD_REGION is a variable, not a secret.

Why B is wrong: This is tempting because secrets are sealed against the public key, but variables are never encrypted. The variables endpoints return plaintext values and there is no encrypted_value field to decrypt.

Why C is correct: Configuration variables are stored unencrypted, so the get-a-repository-variable endpoint returns both the name and the current value in plaintext, which directly satisfies the auditor's request.

Why D is wrong: This is tempting because a workflow can echo a variable, but it is unnecessary. The variables REST API exposes the value directly, so reading it from a log is not required.

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.

  • Configuration variables are automatically masked in run logs in the same way as secrets, so they can safely store credentials that workflows must not print to the output.

    Why it is wrong: Tempting because both are reusable stores, but variables are never masked and print in plain text, so they must not hold credentials the way encrypted secrets do.

  • Reference vars.API_TOKEN in the env block, because repository secrets are surfaced through the vars context and that context is masked automatically in logs.

    Why it is wrong: This is tempting because the vars context does expose repository-level values, but it only resolves non-sensitive configuration variables. Secrets are not present in vars, and vars values are never masked.

  • Read the runner's local _diag log directory, because each runner records the full set of inbound and outbound address ranges that GitHub Actions is currently using for that host.

    Why it is wrong: Tempting because _diag holds connectivity detail, but it logs one runner's own activity, not the published service ranges, so it cannot supply the authoritative list the allow list needs.

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