GitHub Actions Practice Exam

What the GitHub Actions exam covers

• Author and manage workflows250 questions
• Consume and troubleshoot workflows164 questions
• Author and maintain actions170 questions
• Manage GitHub Actions for the enterprise210 questions
• Secure and optimize automation151 questions

Free GitHub Actions sample questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 945.

1. Question 1Author and manage workflows

   In what file format and location are GitHub Actions workflows defined?

   • AA DNS zone file in the repository root
   • BYAML files under .github/workflows/Correct
   • CJSON files in the repository root only
   • DA DHCP config file in the repo root
   ✓ Correct answer: B

   GitHub Actions workflows are the fundamental automation mechanism in GitHub, defined through YAML configuration that specifies triggers, jobs, and steps. Workflows execute on events like pushes, pull requests, or manual dispatch, providing CI/CD capabilities integrated directly into repositories. Understanding workflow structure and configuration is essential for GitHub Actions certification.

   Why the other options are wrong

   • AA DNS zone file is incorrect because DHCP and DNS are network infrastructure concepts unrelated to GitHub Actions or Git version control.
   • CJSON in the repo root only is incorrect because it does not represent the appropriate GitHub feature for this scenario.
   • DA DHCP config is incorrect because DHCP and DNS are network infrastructure concepts unrelated to GitHub Actions or Git version control.
2. Question 2Author and manage workflows

   You want one workflow file to react differently to opened, synchronize, and closed PR activity. What is the idiomatic design?

   • AUse workflow_dispatch and have a human classify the event
   • BUse schedule and poll the REST API for PR changes
   • CCreate three identical workflow files and delete extras
   • DUse on.pull_request.types and branch on github.event.actionCorrect
   ✓ Correct answer: D

   GitHub Actions workflows are the fundamental automation mechanism in GitHub, defined through YAML configuration that specifies triggers, jobs, and steps. Workflows execute on events like pushes, pull requests, or manual dispatch, providing CI/CD capabilities integrated directly into repositories. Understanding workflow structure and configuration is essential for GitHub Actions certification.

   Why the other options are wrong

   • Aworkflow_dispatch is manual; it does not react to PR activity automatically.
   • BPolling on a schedule is slow and wasteful compared to PR event types.
   • CThree near-identical files duplicate logic instead of handling activity types.
3. Question 3Manage GitHub Actions for the enterprise

   For compliance, which mechanism provides a tamper-resistant record of who triggered deployments and approved environments?

   • AA comment in the workflow YAML
   • BThe organization/enterprise audit logCorrect
   • CThe repository's star count
   • DThe runner's local temp directory
   ✓ Correct answer: B

   The organization or enterprise audit log records who triggered deployments and who approved environment protection rules, as append-only entries retained by GitHub. That tamper-resistant history is what compliance reviews rely on.

   Why the other options are wrong

   • AA comment in the workflow YAML is static text and records nothing about who did what at runtime.
   • CA repository's star count is a social metric and captures no deployment or approval history.
   • DThe runner's local temp directory is wiped after the job and is not a durable or tamper-resistant record.
4. Question 4Secure and optimize automationSelect all that apply

   Select TWO limitations that apply specifically to reusable workflows (compared to composite actions).

   • AA reusable workflow cannot be called from a step; it can only be called as an entire job using `uses`Correct
   • BA reusable workflow cannot access the calling workflow's `env` context variablesCorrect
   • CA reusable workflow cannot contain more than 10 jobs
   • DA reusable workflow cannot define job-level `environment` protections
   ✓ Correct answer: A, B

   Reusable workflows are referenced at the job level using `uses`, not at the step level - this means they execute as a separate runner job, not inline within a calling job's steps. Additionally, environment variables set in the calling workflow's `env` context are not automatically available inside the reusable workflow; values must be passed explicitly via inputs. Composite actions, by contrast, run within the calling job's step context and can share its environment.

   Why the other options are wrong

   • CThere is no 10-job limit specific to reusable workflows; the standard per-workflow job limit (up to 256 jobs) applies.
   • DReusable workflows can define `environment` on their jobs to apply branch protection rules and required reviewers; this is a supported and common pattern.
5. Question 5Author and manage workflowsSelect all that apply

   Select TWO accurate statements about how job-level if conditions interact with the needs context. (Select TWO)

   • Aneeds.<job>.result can be "success", "failure", "cancelled", or "skipped".Correct
   • BA job without an explicit if: always runs, regardless of upstream job results.
   • CUsing always() in a job if: condition allows the job to run even when an upstream job was cancelled.Correct
   • Dfailure() in a job if: condition is true only when the immediately preceding job failed, not any upstream job.
   ✓ Correct answer: A, C

   The needs context result field for a job can be one of four string values: success, failure, cancelled, or skipped. The always() status check function forces job evaluation regardless of any of these upstream states, including cancelled. Without an explicit if:, the default implicit condition is success(), which skips the job if any upstream job in needs was not successful.

   Why the other options are wrong

   • BA job without an explicit if: has an implicit condition of success() - it is skipped when any upstream depended-upon job fails, is cancelled, or is skipped.
   • Dfailure() in a job if: condition returns true when ANY job in the needs graph has failed, not just the immediately preceding job - all transitive dependencies are considered.
6. Question 6Manage GitHub Actions for the enterprise

   How can you add a custom label, such as 'gpu', to a self-hosted runner?

   • ADuring registration with config.sh using the --labels flag, or through the GitHub UI after registrationCorrect
   • BBy creating a GitHub Actions variable named RUNNER_LABELS in the repository
   • CBy adding a label key to the runner's .env file and restarting the service
   • DBy editing the workflow YAML to declare a label mapping
   ✓ Correct answer: A

   Custom labels can be applied to a self-hosted runner in two ways: by passing '--labels gpu,linux,x64' to config.sh at registration time, or by navigating to the runner's settings in the GitHub UI and editing its labels after registration. These labels are then usable in 'runs-on' arrays to route jobs.

   Why the other options are wrong

   • BGitHub Actions variables are for workflow configuration values and have no effect on runner labels.
   • CThe runner's .env file does not support a label configuration; labels are managed through config.sh or the GitHub UI.
   • DWorkflow YAML does not declare label mappings; labels are properties of the runner itself, not of the workflow.
7. Question 7Manage GitHub Actions for the enterprise

   A team self-hosts runners for private-repo builds that are I/O- and CPU-heavy and runs them at high volume. They also occasionally need ephemeral, isolated environments for untrusted PR builds. Which deployment design BEST balances cost efficiency for the bulk workload with security for the untrusted workload?

   • ARun all workloads on GitHub-hosted runners and disable the self-hosted runners for the org entirely
   • BUse a single shared self-hosted runner with `cancel-in-progress` set to isolate one job from another
   • CRun everything, including untrusted fork PR builds, on long-lived persistent self-hosted runners to maximize cache reuse
   • DRun trusted bulk builds on autoscaling ephemeral self-hosted runners; send untrusted fork PRs to GitHub-hosted runnersCorrect
   ✓ Correct answer: D

   Self-hosted runners are cost-effective for sustained high-volume private-repo builds because they avoid per-minute GitHub-hosted billing, and autoscaling ephemeral runners (fresh VM/container per job) keep state from leaking between jobs. Untrusted code from forks must never run on persistent self-hosted runners that other jobs share, because a malicious job could persist on the host and compromise later builds or steal cache/secrets. Routing untrusted PRs to GitHub-hosted (or one-shot, fully isolated ephemeral) runners contains that risk. This split optimizes cost where it is safe and isolation where it is needed.

   Why the other options are wrong

   • AMoving the heavy, high-volume workload to hosted runners forfeits the cost efficiency self-hosting was meant to provide.
   • B`cancel-in-progress` cancels overlapping runs and does not isolate jobs or clean state on a shared runner.
   • CPersistent runners let a malicious fork PR poison state that later trusted jobs inherit, which is the security risk to avoid.
8. Question 8Consume and troubleshoot workflows

   An actions/cache step reports a cache miss on every run and never restores dependencies. Its key is: key: deps-${{ github.run_id }}. What explains the constant misses?

   • Aactions/cache only restores on the default branch, never on others
   • BThe cache exceeded the 10 GB repo limit and was evicted each time
   • Crestore-keys is required or cache never attempts a restore at all
   • Dgithub.run_id is unique per run, so the key never matches a saved cacheCorrect
   ✓ Correct answer: D

   A cache restores only on an exact key hit (or a restore-keys prefix). Because github.run_id is unique per run, the computed key is always new and never matches a prior entry. Key on stable content such as hashFiles('**/package-lock.json') so unchanged dependencies hit the cache.

   Why the other options are wrong

   • ACaches restore on any branch; scope is repo and branch based, not default-only.
   • BA single deps cache is well under 10 GB; eviction is not the cause here.
   • Crestore-keys are optional fallbacks; a primary key restores on an exact match.
9. Question 9Author and maintain actions

   Which reference guarantees an action always resolves to the same commit?

   • AA major-version tag like v2
   • BA named release like latest
   • CA full commit SHACorrect
   • DA protected branch reference
   ✓ Correct answer: C

   Maintainers commonly move a major-version tag like v2 to newer releases, and any tag can be deleted and recreated, so it does not guarantee an unchanging commit. Only a full commit SHA is immutable. Pin to a SHA when you need reproducibility or are consuming an untrusted action.

   Why the other options are wrong

   • AMaintainers move major-version tags to new releases, so v2 does not guarantee a fixed commit.
   • BA release name resolves through a movable tag, so it can point at different commits over time.
   • DBranches advance as commits land, so a branch reference is not an immutable pointer.
10. Question 10Manage GitHub Actions for the enterpriseSelect all that apply

    An organization sets its actions policy to 'Allow select actions and reusable workflows.' Which two built-in toggles can be enabled alongside the explicit allow list? (Select TWO)

    • AAllow actions created by GitHubCorrect
    • BAllow Marketplace verified creatorsCorrect
    • CAllow actions with a signed tag
    • DAllow actions from any org member
    • EAllow actions with over 50 stars
    ✓ Correct answer: A, B

    When 'Allow select actions' is chosen, admins can tick 'Allow actions created by GitHub' and 'Allow actions by Marketplace verified creators', and separately enter a comma-separated list of specific actions or patterns. These are the only two preset trust categories GitHub exposes.

    Why the other options are wrong

    • CThere is no toggle based on a signed release tag in the allowed-actions policy.
    • DMembership of the person calling an action is not a criterion in this policy.
    • EStar count is a Marketplace popularity signal, not an allowed-actions toggle.

Related GitHub resources

• GitHub Actions study guideKey concepts
• GitHub practice examsAll GitHub
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• GitHub Foundations practice examRelated
• GitHub Copilot practice examRelated
• GitHub Advanced Security practice examRelated

GitHub Actions practice exam FAQ