GitHub Actions — Practice Set 1

Question 1

A developer wants a workflow to run every day at 08:00 UTC and also allow manual triggering from the GitHub UI. Which combination of triggers should they use in the `on:` block?

Accepted Answer

`schedule` with a cron expression (e.g., `cron: '0 8 * * *'`) handles time-based execution, while `workflow_dispatch` enables manual triggering from the Actions tab. `push` and `pull_request` are event-based, not time-based. `repository_dispatch` requires an API call, not a UI button. `workflow_call` is for reusable workflows invoked by other workflows.

Question 2

A team has a build job and a deploy job in the same workflow. The deploy job must only run after the build job completes successfully. Which workflow keyword enforces this ordering?

Accepted Answer

The `needs:` keyword creates an explicit dependency between jobs; the downstream job waits for all listed upstream jobs to complete successfully before it starts. `if: success()` controls conditional execution but does not establish ordering on its own. `depends-on:` and `require:` are not valid GitHub Actions workflow keywords.

Question 3

A workflow needs to run integration tests against a PostgreSQL database. The tests run inside the default runner environment and must connect to the database on port 5432. What is the correct approach?

Accepted Answer

The `services:` key spins up Docker containers alongside the runner, making dependent services like databases available during job execution. Configuring `ports:` and optionally `options:` for health checks is the idiomatic GitHub Actions pattern. Installing via `apt-get` works but is slower and less reproducible. An external Azure database introduces network latency and cost. A matrix strategy generates job variants and is unrelated to service dependencies.

Question 4

A workflow tests a library against Node.js versions 18, 20, and 22 on both Ubuntu and Windows. The team wants to exclude the `windows-latest` + Node 18 combination. Which configuration elements achieve this?

Accepted Answer

`strategy.matrix.exclude` lets you remove specific combinations from the generated matrix. Adding an entry with `os: windows-latest` and `node: 18` will prevent that combination from being scheduled. An `if:` condition on the whole job fires per-variant but does not remove the variant from the matrix — it would cancel the job, which is semantically different. The `include` approach with a flag is a workaround, not the idiomatic solution. `fail-fast` controls behaviour on failure and has nothing to do with skipping combinations.

Question 5

A platform team maintains a monorepo workflow file with three jobs that each share the same 12-step database migration setup block. An engineer proposes using YAML anchors to avoid the repetition. Which YAML anchor syntax correctly defines a reusable block named `db-setup` and merges it into a job?

Accepted Answer

YAML anchors use `&name` to declare a reusable node and `*name` to reference (alias) it. The merge key `<<:` is used to merge a mapping into another mapping, which is exactly how you inline a shared block of steps. `@` is not valid YAML anchor syntax. `!include` is not part of the YAML 1.2 spec and is not supported by GitHub Actions. `uses:` with a local path invokes a reusable workflow or action, not an inline YAML block, and appears at job level, not step level for this purpose.

Question 6

An engineer is reviewing a workflow that passes data between jobs. Which of the following are valid mechanisms for sharing data between jobs in GitHub Actions? Choose 3.

Accepted Answer

Job outputs (`GITHUB_OUTPUT` + `jobs.<job>.outputs`) and artifacts are the two main cross-job data sharing patterns. Option D (declaring `outputs:` at the job level) is actually the same mechanism as A — you must both write to `GITHUB_OUTPUT` and declare the output for it to be available to downstream jobs via `needs`. `GITHUB_ENV` (C) sets environment variables only within the same job — it does not persist across job boundaries. There is no shared in-memory cache between jobs (E); the actions cache is filesystem-based and requires explicit save/restore steps.

Question 7

A workflow run failed and a developer needs to see the raw log output for a specific step. Where in the GitHub UI can they find this?

Accepted Answer

Workflow run logs are accessible via the Actions tab. Selecting a specific run shows each job, and expanding a job reveals individual steps with their log output. Insights > Traffic shows page views and clones. The Webhooks log shows HTTP delivery attempts, not workflow step output. The Security tab surfaces vulnerability alerts, not CI logs.

Question 8

A matrix workflow tests 6 OS/language combinations. Combination `ubuntu-latest` + `python-3.10` failed. The developer wants to rerun only that specific failing combination without rerunning all 6 jobs. What should they do?

Accepted Answer

GitHub Actions supports selectively rerunning individual matrix jobs from the Actions UI — you can expand the job list on a failed run and choose 'Re-run job' (or 'Re-run failed jobs') for a specific variant. Deleting the run wastes all passing results. `fail-fast: false` prevents early cancellation but does not help rerun a specific variant. Editing the matrix and pushing a commit creates a new run and loses context of the original run.

Question 9

An organization uses starter workflows stored in its `.github` repository. A developer in one of the org's repositories cannot see these templates when creating a new workflow. What is the most likely cause?

Accepted Answer

Organization starter workflows are stored in the special `.github` repository under the organization. If that repository is private (non-public), only repositories and members with access can consume the templates. Making the `.github` repository internal or public (for non-enterprise) is the standard fix. Starter workflows work in both public and private repos within the org. They are available at organization level, not just enterprise. No forking is required.

Question 10

A team needs to stop a workflow from running without permanently deleting it. Which action achieves this?

Accepted Answer

Disabling a workflow via the Actions tab pauses all future runs while keeping the YAML file intact in the repository. It can be re-enabled at any time. Deleting the file is irreversible without a git revert. Setting `on: {}` is technically possible but requires a commit and leaves a confusing file in the repo. Archiving the repository is an extreme action that also prevents code changes and collaboration.

Question 11

A workflow uses a reusable workflow for deployment and a composite action for setting up the build environment. After a refactor, the CI pipeline passes on the first run but a teammate's fork produces different step names in the log. The teammate is using the same workflow file. What is the most likely explanation?

Accepted Answer

Composite actions and reusable workflows are referenced by a specific version (tag, SHA, or branch). If the fork's workflow pins a different version (or an unpinned floating reference that has since moved), it may execute a different revision of the action with different step names. Reusable workflow internals are not exposed differently per fork — the caller sees only job-level names. Runner image differences affect installed software, not log step names. GITHUB_TOKEN permission differences affect API calls, not step visibility.

Question 12

Which of the following action types runs directly on the runner without a Docker container and typically has the fastest startup time?

Accepted Answer

JavaScript actions run directly on the runner using the pre-installed Node.js runtime, requiring no container pull or spin-up, making them the fastest to start. Docker actions require pulling and initializing a container image, adding latency. Composite actions using shell scripts also run on the runner but compose existing steps rather than executing a Node.js bundle. Reusable workflows are not actions — they are entire workflow definitions invoked by other workflows.

Question 13

A developer is building a custom JavaScript action and needs to define its inputs, outputs, and entry point. Which file is required and what format must it use?

Accepted Answer

Every GitHub Action must have an `action.yml` (or `action.yaml`) metadata file at the root of the action repository or directory. This YAML file declares inputs, outputs, and the `runs` section specifying the action type and entry point. `action.json` is not a supported format. `package.json` describes Node.js package metadata, not action metadata. `workflow.yml` is for workflow definitions, not action definitions.

Question 14

A team wants to publish an internal action and share it only within their organization's repositories. Which distribution model achieves this without listing the action on the GitHub Marketplace?

Accepted Answer

Actions in private or internal repositories are accessible to workflows in repositories that have been granted access — this is the standard pattern for internal distribution. There is no `private: true` key in `action.yml`. The Marketplace does not have an 'Organization only' visibility option. Copying action files into each repo creates maintenance debt and divergence over time.

Question 15

An action developer releases v2.1.0 of their action with a breaking change from v2.0.0. To follow GitHub's recommended versioning strategy and allow consumers to pin to the major version, what tags should the developer maintain?

Accepted Answer

GitHub recommends maintaining both an immutable full SemVer tag (e.g., `v2.1.0`) and a mutable major version tag (e.g., `v2`) that always points to the latest patch/minor within the major line. Consumers who want automatic non-breaking updates reference `@v2`, while those who want a pinned version reference `@v2.1.0`. Providing only the full version (A) forces all consumers to update references manually. Using a branch (C) is non-standard and can cause confusion. Overwriting an existing tag (D) breaks reproducibility for consumers already pinned to `v2.0.0`.

Question 16

A JavaScript action uses `@actions/core` to read an input named `api-key` and passes it to an external API. During debugging, a developer accidentally logs the value with `core.info(apiKey)`. What is the correct fix to prevent the secret from appearing in logs?

Accepted Answer

`core.setSecret(value)` registers a value as a secret so the Actions runner will mask it (replace with `***`) in all subsequent log output. However, the root fix is to remove the explicit log call. Using `core.debug()` (A) only hides the line at the default log level but the value is still logged and visible when debug logging is enabled. Writing to `GITHUB_ENV` (C) does not auto-mask values. There is no `no-log:` key in `action.yml` input definitions (D).

Question 17

An enterprise wants to allow repositories to use only actions from verified creators and actions within their own organization. Which setting achieves this?

Accepted Answer

GitHub's enterprise (and organization) Actions policies let administrators restrict which actions can run: options include 'All', 'GitHub-created', 'Verified Marketplace creators', or specific allow-listed repositories. Combining 'verified Marketplace creators' with 'own organization' actions is a common enterprise posture. Branch protection rules control merge requirements, not action usage. Status checks enforce CI gates. CODEOWNERS controls code review requirements, not action execution.

Question 18

A self-hosted runner registered to an organization is processing jobs from multiple repositories. The security team wants to restrict it so it only processes jobs from a specific set of repositories. What should the administrator do?

Accepted Answer

Runner groups are the standard mechanism for controlling which repositories can use a set of runners. An administrator creates a group, adds runners to it, and restricts group access to selected repositories. IP allow lists control network-level access to GitHub.com, not job routing. Labels route workflows to runners with matching labels but do not restrict which repositories can target a runner — any workflow in the org can reference a label. Registering per-repository scales poorly and doesn't centralize management.

Question 19

A workflow step needs a database password that is stored as an organization-level secret named `DB_PASSWORD`. The repository belongs to that organization. How should the workflow reference this secret?

Accepted Answer

Organization and repository secrets are accessed via the `secrets` context using `${{ secrets.SECRET_NAME }}`. Organization-level secrets are automatically available to repositories that have been granted access, with no additional configuration needed in the workflow. `env` holds environment variables, not secrets. `vars` holds configuration variables (non-sensitive). `github.secret` is not a valid context path.

Question 20

An enterprise administrator needs to identify which software tools are pre-installed on GitHub-hosted `ubuntu-latest` runners without running a workflow. Which resources provide this information? Choose 2.

Accepted Answer

The `actions/runner-images` repository on GitHub publishes detailed release notes and included software manifests for each hosted runner image — this is the authoritative source. GitHub's documentation for hosted runners also lists the major tools available. The toolcache listing (B) appears during a live run, not before. The REST API endpoint (C) returns runner registration metadata (name, OS, status), not installed software. `GITHUB_RUNNER_VERSION` (E) is not a standard built-in environment variable in GitHub Actions.

Question 21

An organization wants a standardized deployment workflow that all its repositories must use, defined centrally and updated from one place. Updates should be reflected in all consuming repositories immediately without requiring them to pull changes. What feature best meets this requirement?

Accepted Answer

Reusable workflows (invoked via `uses: org/repo/.github/workflows/deploy.yml@main`) are centrally versioned — when the central workflow is updated, all consuming workflows pick up the changes on their next run without any local changes. Starter workflows are copied once and become independent, so updates to the source do not propagate. Composite actions encapsulate steps but not full job-level deployment orchestration. A GitHub App adds complexity and doesn't use the native workflow reuse mechanism.

Question 22

A self-hosted runner in an air-gapped environment fails to pick up jobs. The organization's IT team has an IP allow list configured on GitHub Enterprise Cloud. A network trace shows the runner cannot reach `api.github.com`. What is the most likely fix?

Accepted Answer

Self-hosted runners must be able to reach GitHub's API and Actions service endpoints outbound. GitHub publishes the IP ranges used by its services in the meta API. When an IP allow list is active on an organization, the runner's outbound IP must be added to the allow list — or the runner must go through a proxy that is on the allow list. Changing registration level (B) does not resolve network connectivity. The `gh` CLI (C) is not how runners poll for jobs. Enabling GitHub-hosted runners (D) doesn't fix the self-hosted runner's connectivity.

Question 23

A workflow receives a pull request title via `github.event.pull_request.title` and passes it to a `run:` step using string interpolation: `run: echo "Title is ${{ github.event.pull_request.title }}". A security reviewer flags this as a script injection risk. What is the recommended mitigation?

Accepted Answer

Inline `${{ }}` expressions are expanded before the shell interprets the command, so a malicious pull request title could inject shell commands. The safe pattern is to assign the expression to an environment variable at the step level (`env: TITLE: ${{ github.event.pull_request.title }}`) and then reference `$TITLE` in the shell script — environment variable expansion happens after shell parsing, preventing injection. Quoting alone (A) is insufficient for complex payloads. Signing with GITHUB_TOKEN (C) is unrelated to script injection. Read-only permissions (D) limit what the injected code can do but do not prevent injection.

Question 24

A team wants to eliminate long-lived cloud credentials from their GitHub Actions workflows that deploy to Azure. Which approaches achieve this goal? Choose 2.

Accepted Answer

OIDC federation (B and C are two perspectives on the same mechanism) allows GitHub Actions to request a short-lived, workflow-scoped OIDC token and exchange it with Azure for access — no long-lived secret is ever stored in GitHub. B describes the Azure-side configuration, C describes the workflow-side implementation; together they fully describe the OIDC approach. Rotating a stored secret (A) reduces risk but does not eliminate long-lived credentials. Base64-encoding credentials (D) provides no security benefit and is worse than encrypted secrets. A self-hosted runner with managed identity (E) also eliminates stored credentials and is valid, but the question's OIDC options (B+C) are the most direct answer pairing.

Question 25

An enterprise security policy requires that all third-party actions used in workflows are pinned to immutable references. Which of the following are correct reasons for pinning actions to full commit SHAs rather than tags or branches? Choose 2.

Accepted Answer

The security rationale for SHA pinning is that tags and branch references are mutable — they can be moved (intentionally or through a supply-chain attack) to point to malicious code. A full commit SHA is a content-addressable, cryptographic reference that cannot be altered; the same SHA always refers to the same tree. Caching efficiency (C) is not affected by the reference type. GitHub does not mandate SHA pinning for protected branches (D) — that is a recommended policy, not an enforced platform rule. SHA pinning requirements do not differ between GitHub-hosted and self-hosted runners (E).

GH-200 — GitHub Certified: GitHub Actions