Task 4.3: Manage encrypted secrets and variables

• APaste the binary file's raw bytes into the secret's value field as they are

  Incorrect

  Secrets hold text, so binary data needs encoding first.

• BCommit the keystore to a private branch

  Incorrect

  The file would sit unencrypted in the repository.

• CBase64-encode the file, store the text as a secret and decode it in a step

  Correct

  Base64 turns a small binary file into text that can be stored as a secret.

• DStore it as a configuration variable

  Incorrect

  Variables are plain text and shown in logs.

You can use Base64 encoding to store small binary blobs as secrets, then reference the secret in a workflow step and decode it back to a file on the runner.

• AThe new value of both secrets

  Incorrect

  Repository secrets were already read when the run was queued.

• BThe old DB_TOKEN and the new PROD_TOKEN

  Correct

  Repository secrets are read at queue time and environment secrets when the job referencing the environment starts.

• CThe old value of both secrets

  Incorrect

  Environment secrets are read when the job starts, after the rotation.

• DThe new DB_TOKEN with the old PROD_TOKEN value

  Incorrect

  That reverses when each kind of secret is read.

Organization and repository secrets are read when a workflow run is queued, and environment secrets are read when a job that references the environment starts. A secret rotated while a run waits is picked up only if it's an environment secret.

• AForks need a copy of the secret in their own settings

  Incorrect

  Fork secrets aren't used for runs in the base repository.

• BSecrets expire for runs that wait for approval

  Incorrect

  Approval doesn't change secret access.

• CThe secret must be an organization secret to reach pull requests from forks

  Incorrect

  No secret level is sent to fork pull request runs.

• DSecrets aren't passed to workflows triggered by pull requests from forks

  Correct

  Apart from GITHUB_TOKEN, fork pull request runs get no secrets.

With the exception of GITHUB_TOKEN, secrets aren't passed to the runner when a workflow is triggered from a forked repository. For forks of private repositories, an administrator can choose to send secrets; that isn't available for public repositories.

• AA repository variable in each repository

  Incorrect

  Variables aren't for secrets, and forty copies remain.

• BOne organization secret granted to the forty repositories

  Correct

  Updating an organization secret once changes it for every repository that uses it.

• CAn environment in each of the forty repositories holding the token

  Incorrect

  That keeps forty copies.

• DA workflow template in the organization that contains the token

  Incorrect

  The token would be stored in plain text in workflow files.

Organization-level secrets share a secret between repositories, so one update takes effect in every workflow that uses it. An access policy limits which repositories can use it.

• AStore them as secrets of an environment that the deployment job uses

  Correct

  Each environment can hold up to 100 secrets of its own.

• BAdd them anyway; repositories have no limit on secrets

  Incorrect

  Repositories are limited to 100 secrets.

• CAsk an owner to raise the repository's secret limit to 200 for the deployment

  Incorrect

  The limit isn't configurable.

• DCombine them into one JSON secret

  Incorrect

  GitHub advises against structured data as secrets, because redaction can fail.

You can store up to 1,000 organization secrets, 100 repository secrets and 100 environment secrets, and a workflow can access all 100 repository and 100 environment secrets. Structured data shouldn't be used as a secret value.

• ASettings, then Deploy keys

  Incorrect

  Deploy keys are SSH keys for Git access.

• BSettings, then Webhooks

  Incorrect

  Webhooks send events to other services.

• CSettings, then Secrets and variables, then Actions

  Correct

  Actions secrets and variables are managed there.

• DInsights, then Dependency graph

  Incorrect

  That shows dependencies.

Repository secrets for GitHub Actions are created in the repository's Settings under Secrets and variables, then Actions, or with gh secret set or the REST API.

• ARead $DB_PASSWORD, which every step gets automatically

  Incorrect

  The step's environment has no DB_PASSWORD until env maps the secret.

• BPrint the secret with echo so later steps can copy it

  Incorrect

  Printing secrets is exactly what to avoid.

• CSet env: DB_PASSWORD: ${{ secrets.DB_PASSWORD }} on the step, then read $DB_PASSWORD

  Correct

  Mapping the secret to a step environment variable passes it safely.

• DWrite the secret to GITHUB_OUTPUT for the step to read

  Incorrect

  Outputs aren't meant for secrets.

A secret is passed to a step by referencing it with the secrets context, for example as an environment variable in the step's env, and the script reads it like any other environment variable.

• AOrganization, repository and environment

  Correct

  All three levels support configuration variables.

• BRepository level only

  Incorrect

  Organizations and environments can define variables too.

• CWorkflow files only, under the top-level env key

  Incorrect

  env in a workflow file sets environment variables for that workflow only.

• DEnterprise level only

  Incorrect

  The documented levels are organization, repository and environment.

Configuration variables can be defined for an organization, a repository or an environment, and workflows read them through the vars context.

• AThe bearer token was registered automatically as a repository secret

  Incorrect

  Values printed in a run don't become secrets.

• BDebug logging is on, which hides tokens

  Incorrect

  Debug logging adds detail; it doesn't redact.

• CThe runner redacts every string longer than 32 characters

  Incorrect

  Length alone doesn't trigger redaction.

• DGitHub also redacts some recognized credential formats, such as bearer token headers

  Correct

  Certain sensitive values are redacted even when they aren't stored as secrets.

GitHub Actions redacts the contents of all GitHub secrets printed to logs, and also redacts some information recognized as sensitive that isn't stored as a secret, such as HTTP bearer token headers, JWTs and GitHub tokens.