Free GitHub Actions Expert (GH-200) Sample Questions

Correct answer: A — Adding a service container for PostgreSQL

• A. Adding a service container for PostgreSQL in the workflow YAML allows GitHub Actions to automatically spin up a PostgreSQL instance as a sidecar. This provides a clean, isolated database for each workflow run without manual setup.
• B. Installing PostgreSQL on the runner requires manual setup and may leave residual data between runs. It does not leverage the ephemeral nature of runners and adds cleanup overhead.
• C. Marketplace actions can assist with setup, but they do not inherently provide a clean, isolated database instance. Service containers are the native and recommended method.
• D. Manually managing a Docker container requires you to handle the container lifecycle yourself, defeating automation. GitHub Actions service containers automate this process.

Correct answer: A — Define a job output and reference it via the needs context

• A. Correct. GitHub Actions allows jobs to define outputs, which can be referenced in dependent jobs using the `needs` context. This is the recommended and most efficient mechanism for passing computed values between jobs in the same workflow.
• B. Incorrect. Environment variables set via `GITHUB_ENV` are scoped only to the current job and its subsequent steps. They cannot be shared across jobs.
• C. Incorrect. While artifacts can transfer files between jobs, they are not the recommended method for passing simple values. Using an artifact introduces extra steps and complexity compared to job outputs.
• D. Incorrect. Service containers are used to provide supporting services like databases for jobs, not to share computed data between jobs.

Correct answers: A, C — Workflow failures if scripts depend on specific PowerShell or older OS features; You can preview the new image by using windows-2025 before the migration

• A. Correct. Workflows may fail if they rely on specific PowerShell versions or deprecated OS features that are no longer available in Windows Server 2025. Teams should test their scripts and dependencies against the new image to avoid failures.
• B. Incorrect. Moving to a newer runner image does not guarantee compatibility. Legacy applications may require modifications due to breaking changes or removal of older frameworks.
• C. Correct. GitHub typically provides preview labels such as windows-2025 to allow users to test workflows on the new image before the official migration of windows-latest. This lets teams validate and fix issues in advance.
• D. Incorrect. GitHub and Microsoft announce hosted runner image changes in advance, providing a transition period. The switch is not immediate or without notice.
• E. Incorrect. Using a self-hosted runner is an option but not a requirement. Teams can adapt by pinning to a supported image label or updating their workflows rather than being forced to use self-hosted runners.

Correct answer: A — needs

• A. Correct. The `needs` keyword defines job dependencies. Adding `needs: [build, test]` ensures the deploy job runs only after both build and test jobs complete successfully.
• B. Incorrect. The `runs-on` keyword specifies the runner environment for a job (e.g., `ubuntu-latest`), not job dependencies.
• C. Incorrect. The `if` keyword is used for conditional execution of steps or jobs based on a condition, not for defining dependencies.

Correct answer: A — The `deploy` job is missing `needs: build`, so it may run before the artifact is ready.

• A. Without `needs: build`, the `deploy` job may run in parallel or before the `build` job completes, causing the artifact to not yet exist when the download is attempted. The error "No artifact with name 'my-app' found" occurs because the artifact hasn't been uploaded yet.
• B. Incorrect. `actions/download-artifact@v3` does not require a path input to locate the artifact by name; the path is optional and only controls where the artifact is downloaded in the runner filesystem.
• C. Incorrect. Artifact names are not case-sensitive in GitHub Actions, and quoting the name is not required unless it contains special characters. A naming mismatch could cause the error, but quoting is not the issue here.
• D. Incorrect. The default artifact retention period is 90 days after the workflow run completes, not during the run. Within the same workflow run, artifacts are available until the run ends, so retention expiry cannot be the cause.

Correct answer: A — Append `?branch=develop` to the URL.

• A. Correct. GitHub Actions badge URLs support a `branch` query parameter to display the status for a specific branch. Appending `?branch=develop` tells GitHub to show the workflow status for the `develop` branch instead of the default branch.
• B. Incorrect. The `actions/badge@v3` action is not a standard GitHub action for generating badges. GitHub provides built-in badge URLs for workflows, and no additional action is needed.
• C. Incorrect. The path `/badge/develop.svg` is not a valid GitHub Actions badge URL. The correct badge URL uses the workflow file path with an optional `branch` query parameter to specify the branch.
• D. Incorrect. There is no supported `BADGE_BRANCH` environment variable that affects the badge. The branch selection for the badge is controlled via the URL query parameter, not by workflow environment variables.

Correct answers: A, B, C — Required reviewers; Wait timer; Deployment branches

• A. Correct. Required reviewers is a valid environment protection rule that requires specified individuals or teams to approve deployments before they proceed.
• B. Correct. Wait timer is a valid environment protection rule that introduces a mandatory delay before a deployment is executed, allowing time for manual intervention or verification.
• C. Correct. Deployment branches is a valid environment protection rule that restricts deployments to only specified branches, such as `main`, ensuring controlled releases.
• D. Incorrect. Branch protection rules apply to repository branches (e.g., requiring status checks before merging) and are not environment-specific deployment protection rules.
• E. Incorrect. Secret scanning is a repository security feature that detects exposed secrets in code; it does not control deployment approvals, timing, or branch restrictions for environments.

Correct answer: A — on: pull_request: types: [opened, reopened] branches: [main]

• A. Correct. This configuration triggers on pull_request events of types 'opened' and 'reopened' and limits to the main branch, exactly matching the requirement to run when a PR is opened or reopened targeting main.
• B. Incorrect. This uses 'synchronize' instead of 'reopened'. 'synchronize' triggers when new commits are pushed to the PR, not when it is reopened. It does not include 'reopened', so it fails to meet the requirement.
• C. Incorrect. This only triggers on 'opened' events for the main branch. It does not include 'reopened', so reopened pull requests would not trigger the workflow.
• D. Incorrect. This triggers only on 'reopened' and uses a wildcard branch filter ('*') instead of limiting to main. It also lacks 'opened', so opened PRs would not trigger the workflow.

Correct answers: A, B — on: workflow_dispatch: inputs: environment: description: 'Deployment environment' required: true type: string debug: description: 'Enable debug mode' required: false type: boolean default: false; on: workflow_dispatch: inputs: environment: description: 'Deployment environment' required: true type: string debug: description: 'Enable debug mode' required: false type: boolean

• A. Correct. `environment` is required and defined as a string; `debug` is optional with `required: false`, type `boolean`, and a default value. This meets all requirements.
• B. Correct. `environment` is required and a string; `debug` is optional (`required: false`) and type `boolean`. A default is not required for an optional input.
• C. Incorrect. The type for `debug` is `bool`, which is invalid. GitHub Actions uses `boolean` for boolean inputs.
• D. Incorrect. `environment` is defined as a `choice` type with fixed options, not as a free-form string as required.
• E. Incorrect. `debug` is missing `required: false`, making it implicitly required, which violates the requirement for it to be optional.

Correct answer: A — choice

• A. Correct. The `choice` type in a `workflow_dispatch` input creates a dropdown list in the GitHub UI, allowing users to select from predefined options.
• B. Incorrect. The `environment` type is used to specify a deployment environment (e.g., production, staging) and does not create a dropdown list for user input. It is not an input type but a context-related concept.
• C. Incorrect. While `select` might intuitively seem like a dropdown, GitHub Actions does not use this term for `workflow_dispatch` inputs. The correct term is `choice`.

Correct answer: B — It becomes an independent copy that you can modify.

• A. Incorrect. When you use a starter workflow, it creates a new workflow file that is not linked to the original template. Changes to the template do not automatically propagate to the committed workflow.
• B. Correct. Using a starter workflow generates an independent copy in your repository. You can modify it as needed without affecting the original template.
• C. Incorrect. The new workflow does not automatically sync with updates to the original starter template; it is a static copy at the time of creation.
• D. Incorrect. The committed workflow is fully editable and customizable; starter workflows are meant to be customized after creation.

Correct answers: A, C — They are defined in a separate YAML file.; They are called using `jobs.<job_id>.uses`.

• A. Correct. Reusable workflows are defined in a separate YAML file, typically stored in the .github/workflows directory, and can be referenced by other workflows.
• B. Incorrect. Reusable workflows can only be called from repositories that have access to the workflow file. Access depends on the visibility of the source repository and any configured permissions; they are not automatically callable from any public repository.
• C. Correct. Reusable workflows are invoked using the jobs.<job_id>.uses syntax in a calling workflow, where <job_id> is the job identifier and uses points to the reusable workflow file.
• D. Incorrect. Reusable workflows are not always public; they can be private if the repository containing them is private, and access is controlled by GitHub's permission model.
• E. Incorrect. Reusable workflows are designed to be shared across workflows. They can be called from other repositories when permitted, not limited to a single repository.
• F. Incorrect. Reusable workflows are not directly triggered by webhook events. They are called by other workflows using the uses syntax; only initial workflows can be triggered by events.

Correct answer: A — Your workflow is unaffected because it is now independent.

• A. Correct. When you create a repository from a template, the workflow files are copied and become independent. Subsequent updates to the template's starter workflow do not affect your repository's workflow, which remains as last edited. No automatic sync or notification occurs.
• B. Incorrect. GitHub does not automatically create pull requests for template workflow updates. Your repository is not linked like a fork, and changes from the template must be manually applied if desired.
• C. Incorrect. The workflow does not automatically update on a push when the source template changes. Your workflow file stays as it was copied and edited, independent of the template.
• D. Incorrect. GitHub does not send notifications for template workflow updates. You would need to manually check the template repository and sync changes if needed.

Correct answer: B — Expand the log panel and use the browser’s find functionality (Ctrl+F) to locate the error.

• A. Incorrect. GitHub Actions logs do not have a dedicated 'Filter logs' text box for searching within job step output. The UI relies on the browser's built-in find feature or manual navigation.
• B. Correct. In the GitHub UI, the easiest way to search within a long log is to expand the log panel and use the browser’s native find functionality (Ctrl+F or Cmd+F). This searches the currently displayed log text and lets the developer jump directly to the error message.
• C. Incorrect. While copying logs into a local editor and searching there would work, it is not a method for searching in the GitHub UI. The question asks specifically how to search the log in GitHub, so this is not the intended workflow.
• D. Incorrect. The GitHub search bar is used to search repositories, issues, code, and other GitHub content, not to search inside a specific Actions log page. It will not locate text within an individual job's log output.

Correct answers: A, B, C — Rerun a workflow run; List artifacts for a run; Download a log archive for a job

• A. Correct. The GitHub Actions REST API provides the `POST /repos/{owner}/{repo}/actions/runs/{run_id}/rerun` endpoint to rerun a workflow run, including rerunning all jobs or only failed jobs.
• B. Correct. You can list artifacts for a workflow run using the `GET /repos/{owner}/{repo}/actions/runs/{run_id}/artifacts` endpoint, which is useful for inspecting or downloading build outputs.
• C. Correct. The API supports downloading log archives for a job via the `GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs` endpoint, allowing programmatic retrieval of logs for troubleshooting.
• D. Incorrect. Creating a new workflow file is a repository content operation handled via the Contents API or Git operations, not through the Actions REST API.
• E. Incorrect. Approving a deployment is managed by deployment protection rules and the Deployments API, not by the Actions REST API for workflow runs and artifacts.
• F. Incorrect. Secret values cannot be retrieved through any GitHub API for security reasons; they are write-only and only accessible during workflow execution.

Correct answer: C — 90

• A. Incorrect. The default retention period is 90 days, not 30 days.
• B. Incorrect. The default retention period is 90 days, not 60 days.
• C. Correct. GitHub Actions artifacts and logs are retained for 90 days by default unless a different period is configured at the repository or organization level.

Correct answer: D — Store the action in an internal repository and use the `uses: owner/repo` syntax.

• A. Incorrect. Using a public repository exposes the action broadly, which is unnecessary for internal sharing. Additionally, referencing with a full URL is not the standard pattern; actions are typically referenced using the `owner/repo` syntax.
• B. Incorrect. Deploy keys provide read-only access to a single repository and are not scalable for sharing an action across multiple repositories. This adds complexity and is not a best practice for internal action sharing.
• C. Incorrect. GitHub Actions custom actions are stored in repositories, not in package registries. The internal package registry is for distributing packages and artifacts, not for sharing workflow actions.
• D. Correct. Storing the action in an internal (private) repository within the organization and referencing it with `uses: owner/repo` (optionally with a ref like a tag or SHA) is the recommended approach. This allows secure reuse across all repositories in the organization without publishing to the Marketplace.

Correct answer: C — The downstream step referenced the output with a typo in the step id or output name.

• A. Incorrect. While failing to invoke `core.setOutput` would prevent the output from being set, the question states the action *uses* `@actions/core` to set an output, implying the method was called. Even if it wasn't, the more common direct cause of an empty string in the downstream step is a reference error.
• B. Incorrect. Using `core.exportVariable` sets an environment variable, not an action output. This would cause the output to not be set, but the most likely direct cause of the downstream step receiving an empty string is a typo in the output reference, not a misuse of the API.
• C. Correct. A typo in the step id or output name in the downstream step's expression causes the output to resolve to an empty string because GitHub Actions cannot find the referenced output. This is a common and direct cause.
• D. Incorrect. Failing to compile TypeScript would typically cause the action to fail to run at all, not just produce an empty output. The action appears to run, so this is unlikely.

Correct answer: A — Add an `if` condition to the step: `if: ${{ inputs.my_input == 'true' }}`.

• A. Correct. In GitHub Actions, step-level `if` conditionals are the standard mechanism to control execution based on inputs. The syntax `if: ${{ inputs.my_input == 'true' }}` is valid because action inputs are strings, so comparing to the string `'true'` correctly evaluates the condition.
• B. Incorrect. While shell if statements can be used inside a `run` script, they do not prevent the step from starting; the step still runs and incurs overhead. The recommended approach is to use a step-level `if` condition to skip the step entirely when the condition is not met.
• C. Incorrect. Creating a separate action for a simple conditional step is unnecessarily complex. Composite actions are designed to encapsulate multiple steps, including conditional ones, within a single action, without needing to outsource the logic.
• D. Incorrect. GitHub Actions does not support an `unless` keyword on steps. The correct way to conditionally run a step is to use `if` with the appropriate expression; to skip when input is false, you would use `if: inputs.my_input == 'true'`.

Correct answer: B — `uses: owner/repo@<sha>`

• A. Incorrect. Using `uses: owner/repo@main` references the latest commit on the `main` branch, which can change over time and does not guarantee a specific commit, thus not ensuring stability.
• B. Correct. Using `uses: owner/repo@<sha>` pins the action to an exact commit by its SHA hash, providing immutability and stability. This is the recommended way to reference a specific version for reproducibility.
• C. Incorrect. `v1` typically refers to a tag or release version, which may be updated to point to a different commit if the maintainer retags it. While more stable than a branch, it does not guarantee a specific commit.
• D. Incorrect. `latest` is not a standard GitHub Actions reference syntax for actions. It does not pin to a specific commit and cannot ensure stability.

Correct answer: B — action.yml

• A. Incorrect. While a README.md is strongly recommended for documentation and user guidance, it is not a mandatory requirement for publishing an action to the GitHub Marketplace.
• B. Correct. The action.yml file (or action.yaml) is mandatory as it defines the action's metadata, inputs, outputs, and execution details. GitHub requires this file to recognize and publish the action in the Marketplace.
• C. Incorrect. A Dockerfile is only required if the action uses a Docker container as its runtime. Many actions are written in JavaScript or as composite actions, which do not require a Dockerfile.
• D. Incorrect. package.json is used for JavaScript/Node.js actions to manage dependencies, but it is not mandatory for Marketplace publishing. The essential file is the action metadata file (action.yml).

Correct answer: A — To show an icon and color on the Marketplace listing.

• A. Correct. The branding section is used to define visual metadata for the action, such as an icon and a color, which appear on the GitHub Marketplace listing. This enhances the action's visual identity and helps it stand out.
• B. Incorrect. Categorization of actions on the GitHub Marketplace is handled by other metadata, such as categories or tags, not the 'branding' section.
• C. Incorrect. The license type of an action is specified in the repository's LICENSE file or metadata, not in the 'branding' section of action.yml.
• D. Incorrect. The pricing model (free or paid) for an action is configured in the GitHub Marketplace settings, not in the 'branding' section of action.yml.

Correct answer: B — patch

• A. Incorrect. The major version tag like `v1` is not intended to track the latest minor release. In GitHub Actions semantic versioning, the major tag should point to the latest patch release within that major version to ensure users receive bug fixes while maintaining compatibility.
• B. Correct. Per GitHub's recommendation, the mutable tag like `v1` should point to the latest patch release within major version 1. This allows consumers to automatically receive backward-compatible bug fixes and security updates.
• C. Incorrect. Prerelease versions (e.g., beta, alpha) are not stable and should not be referenced by mutable major tags. Tags like `v1` are meant to point to stable releases only.

Correct answer: A — Use the container key at the job level and specify the image.

• A. The `container` key at the job level allows you to specify a Docker image, ensuring all steps run in that isolated container on the GitHub-hosted runner. This is the standard method for job-level containerization.
• B. Incorrect. While you can manually run `docker run` in a step, this does not isolate the entire job; the job runner still executes on the host. It is not the recommended approach for job-level containerization.
• C. Incorrect. GitHub-hosted runners are pre-configured and managed by GitHub; they do not support booting from custom virtual machine images via workflow. Custom images are for self-hosted runners.
• D. Incorrect. The `strategy.matrix` is used to define multiple job variations (different OS, versions, etc.), not to specify the container image for a job. The container image is set at the job level with the `container` key.

Correct answer: C — Runner automatically updates itself when idle without configuration.

• A. Incorrect. The `--auto-update` flag is not a valid option for the `config.sh` setup command. Self-hosted runner updates are handled by the runner service itself, not via a setup flag.
• B. Incorrect. Repository Actions settings control workflow permissions and other features, but they do not include an auto-update setting for self-hosted runners. Runner updates are managed on the runner machine.
• C. Correct. Self-hosted runners are designed to automatically update themselves when a new runner version is available and the runner is idle. No additional configuration is required for this built-in behavior.
• D. Incorrect. While scheduling a script to download and apply updates is possible, it is a manual operational workaround. The question asks for the built-in configuration option, which is the automatic update mechanism already present in the runner.

Correct answers: A, B, D — Node.js; Docker; Python

• A. Correct. Node.js is preinstalled on the ubuntu-latest runner, commonly used for JavaScript applications.
• B. Correct. Docker is preinstalled on the ubuntu-latest runner, enabling containerized workflows.
• C. Incorrect. Google Cloud CLI is not preinstalled on the ubuntu-latest runner; it must be installed manually.
• D. Correct. Python is preinstalled on the ubuntu-latest runner, widely used for scripting and automation.
• E. Incorrect. AWS CLI is not preinstalled on the ubuntu-latest runner; it requires manual installation or an action.
• F. Incorrect. Terraform is not preinstalled on the ubuntu-latest runner; it must be installed manually.

Correct answers: A, B, E — Supports an operating system (Linux, Windows, or macOS).; Maintains an always-on internet connection to GitHub.; Can run the runner application as a service.

• A. Correct. A self-hosted runner must run on a supported operating system, which includes Linux, Windows, or macOS. GitHub provides runner binaries for these platforms, making them baseline compatibility requirements.
• B. Correct. The machine needs an always-on internet connection to GitHub to register, receive jobs, and send logs/results. The runner must maintain outbound communication to GitHub over the internet.
• C. Incorrect. GitHub does not require a minimum of 8 GB of RAM for a self-hosted runner. While GitHub recommends at least 2 GB of RAM for the runner application, the actual hardware requirements depend on the workflows to be executed.
• D. Incorrect. Docker is not a universal requirement for a self-hosted runner. It is only necessary if the workflows involve container-based jobs or Docker actions.
• E. Correct. The runner application must be able to run as a service (or background process) to ensure it stays active, accepts jobs, and remains available across reboots.
• F. Incorrect. A static public IP address is not a requirement. The runner only needs to be able to communicate outbound to GitHub; it can use any internet connection, including dynamic IPs.

Correct answer: B — Create an environment, restrict its branches to main, and store the secret as an environment secret.

• A. Incorrect. Repository secrets are available to all workflows in the repository regardless of branch. While branch conditions can prevent a workflow from running on non-main branches, the secret itself remains accessible if a workflow on another branch references it. Branch conditions do not scope the secret to the main branch.
• B. Correct. GitHub Environments support branch restrictions, allowing you to limit an environment to specific branches (e.g., main). Storing the secret as an environment secret ensures it is only exposed to workflows that use that environment and comply with the branch restriction, effectively scoping the token to the main branch.
• C. Incorrect. GitHub does not support branch-specific encryption keys for secrets. Repository secrets are stored encrypted at rest with a repository-level key, not a branch-specific key. This approach does not provide a valid mechanism to restrict the secret to the main branch.
• D. Incorrect. Organization secrets restricted to a specific repository control which repository can access the secret, not which branch within that repository can use it. Any branch in the repository could still potentially use the secret unless further restricted by an environment or other mechanism.

Correct answer: B — In the environment, set Deployment branches to allow only `release/*`.

• A. Incorrect. A workflow trigger branch filter only controls when the workflow starts, not which branches can deploy to the environment. It does not enforce the branch restriction at the environment level.
• B. Correct. GitHub Environments support deployment branch restrictions, which can limit environment usage to specific branches or branch patterns such as `release/*`. This is the proper way to ensure any job that references the environment only runs from allowed branches, enforcing the restriction at the environment level.
• C. Incorrect. An `if` condition on the job can prevent execution, but it is only a workflow-level logic check and does not enforce the restriction at the environment level. It is also easier to bypass or misconfigure compared to environment protection rules.
• D. Incorrect. Storing a secret in a separate repository does not enforce branch-based execution rules for an environment. Secrets and repository placement are unrelated to controlling which branches may deploy to or use an environment.

Correct answers: C, D, E — Organization level; Repository level; Environment level

• A. Incorrect. Workflow level is not a valid scope for defining encrypted secrets. Workflows can only reference secrets defined at higher scopes, such as organization, repository, or environment.
• B. Incorrect. Job level is not a supported scope for encrypted secrets. Jobs can consume secrets, but secrets are defined and stored at broader scopes.
• C. Correct. Organization-level secrets are available to all repositories within the organization, subject to access policies.
• D. Correct. Repository-level secrets are specific to a single repository and are commonly used for project-specific credentials.
• E. Correct. Environment-level secrets are restricted to specific deployment environments (e.g., production, staging) and require approval for access.
• F. Incorrect. Step level is not a valid scope for defining secrets. Steps can only use secrets defined at higher scopes.

Correct answers: A, B — The `admin:org` scope is required to update an organization secret via API.; The `repo` scope is necessary to retrieve a list of repository secrets.

• A. Correct. The `admin:org` scope (or equivalent fine-grained permissions) is required to manage organization-level secrets, including updating them via the API. This scope grants administrative access to organization settings and secrets.
• B. Correct. To list repository secrets via the REST API, the `repo` scope is required for private repositories (and `public_repo` for public repositories). Without this scope, the API call will fail.
• C. Incorrect. The `workflow` scope is used for managing workflow files and Actions resources, but it does not grant access to secrets during workflow execution. Secrets are made available to workflows based on repository and organization settings, not via a PAT scope.
• D. Incorrect. There is no `secrets:write` scope in the classic OAuth scopes. Creating repository secrets requires either the `repo` scope (for private repos) or appropriate fine-grained permissions.
• E. Incorrect. The `user:email` scope only grants access to the authenticated user's email addresses and is unrelated to secrets management. The API does not allow decrypting secret values.
• F. Incorrect. The `public_repo` scope allows access to public repositories but does not permit reading secrets. Secrets are encrypted and cannot be retrieved as plaintext via the API regardless of repository visibility.

Correct answer: B — environment protection rule

• A. Incorrect. An action allow list controls which GitHub Actions are permitted to run, but it is not a standard feature for protecting environments or deployments. It does not directly provide safeguards like required reviewers or branch restrictions for deployments.
• B. Correct. An environment protection rule is used to add safeguards such as required reviewers, wait timers, and deployment branch restrictions before jobs can deploy to an environment. This directly secures deployments and is the intended answer.
• C. Incorrect. Required status checks are used in branch protection to ensure specific checks pass before merging, but they are focused on pull request validation, not on environment-level deployment protections. They do not directly restrict which actions or workflows can access an environment.

Correct answer: A — A commit SHA provides an immutable reference to the exact code, whereas a branch tag can move to different commits.

• A. Correct. A commit SHA is a unique, immutable identifier for a specific commit, ensuring reproducibility and security. Branch tags or branch names can move as new commits are added, making them less reliable for referencing exact code states. Therefore, commit SHAs are preferred for pinning dependencies and actions in automation and security-sensitive workflows.
• B. Incorrect. A branch tag does not inherently provide security benefits; it can reference different commits over time, reducing predictability. Automatically fetching the latest release may introduce untested or vulnerable code. Security best practice is to pin to a specific commit SHA to know exactly what is executed.
• C. Incorrect. Commit SHAs are hexadecimal identifiers (40-character string) and are case-sensitive. They are not simpler to manage than human-readable tags. The key property for secure automation is immutability and exact referencing, not simplicity of management.
• D. Incorrect. Using a branch tag for automation can silently change what code runs, weakening supply-chain security. Automatically applying security updates without review is not recommended. Commit SHAs are preferred for pinning exact versions to avoid unintended changes.

Correct answer: C — environment variables

• A. Incorrect. GITHUB_TOKEN permissions control the access level of the automatically generated token for a workflow run, but they are not intended for securely storing or passing secrets. Secrets are stored separately.
• B. Incorrect. Runner specifications define the environment where the workflow runs (OS, hardware, etc.) and do not provide a mechanism for securely passing secrets.
• C. Correct. GitHub Secrets, which are stored as encrypted environment variables, are the recommended way to securely pass sensitive data to workflows without hardcoding them. They can be referenced in workflow files using the ${{ secrets.SECRET_NAME }} syntax.

Correct answer: A — gh attestation verify

• A. Correct. `gh attestation verify` is the GitHub CLI command specifically designed to verify artifact attestations. It checks that the attestation is valid and matches the referenced artifact and predicate, ensuring the artifact's integrity and authenticity.
• B. Incorrect. `gh artifacts check` is not a valid GitHub CLI command. GitHub provides dedicated attestation commands for verifying artifacts, not a generic artifacts check command.
• C. Incorrect. `gh verify signature` is not a standard GitHub CLI command for attestation verification. While signature verification is related, attestation verification in GitHub CLI uses the attestation subcommand.
• D. Incorrect. `gh provenance validate` is not the GitHub CLI command for artifact attestation verification. Provenance is a related supply-chain security concept, but the command used here is `gh attestation verify`.