CertGrid
GitHub Certification

GitHub Actions Practice Exam

Validates building and managing CI/CD workflows with GitHub Actions - authoring and managing workflows, consuming and troubleshooting workflows, authoring actions, managing Actions for the enterprise, and securing and optimizing automation.

Start with a free GitHub Actions practice test, then work through 969 exam-style questions with full answer explanations, and take timed mock exams that score like the real thing.

969
Practice pool
~60 qs
Real exam
100 min
Real exam time
70%
Passing score

CertGrid runs a fixed 60-question timed mock, separate from the real exam format above.

Objective-mapped practice, aligned to current exam objectives · Reviewed Aug 2026 · Independent practice platform.

What the GitHub Actions exam covers

Free GitHub Actions practice test questions

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

  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

    A workflow needs Docker plus several system packages on every run, and provisioning them per run is slow. Which design reduces setup time most effectively?

    • ARun the job in a prebuilt container image with the tooling baked inCorrect
    • BReinstall all packages with apt at the start of every job
    • CSwitch the trigger to schedule so installs happen overnight
    • DAdd more steps so the install runs in parallel within one job
    ✓ Correct answer: A

    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
    • BReinstalling with apt each run is exactly the slow setup to avoid.
    • CA schedule trigger does not pre-provision tooling for on-demand runs.
    • DSteps in a job run sequentially, so this does not speed up provisioning.
  3. Question 3Secure and optimize automation

    Which is the correct way to consume a secret inside a composite action's step without exposing it as a plain input?

    • APass it through env: and reference $SECRET, keeping it out of command-line argumentsCorrect
    • BInterpolate the secret directly into the run command's arguments
    • CEcho the secret before use to confirm the value was passed correctly
    • DStore the secret as a default value in the action's metadata file
    ✓ Correct answer: A

    GitHub Actions provides encrypted secret management integrated with the platform. Secrets are encrypted at rest and only decrypted during workflow execution within runner memory. Secrets are referenced using secrets.NAME syntax and are automatically masked from logs, preventing exposure in workflow output or logs.

    Why the other options are wrong
    • BInterpolating the secret into command-line arguments risks leaking it in process lists and logs; passing via env: avoids that.
    • CEchoing the secret exposes it in logs, the opposite of safely consuming it inside the step.
    • DPlacing the secret as a default in action.yml hardcodes it in source and exposes it, which is unsafe.
  4. Question 4Author and manage workflows

    A team tries to nest reusable workflows 5 levels deep (A calls B calls C calls D calls E calls F). What is the outcome?

    • AThe workflow runs successfully since GitHub supports unlimited nesting
    • BIt fails because only 4 levels of reusable workflow nesting are supportedCorrect
    • CGitHub allows 5 levels but generates a deprecation warning
    • DOnly the first 4 levels execute; the 5th is silently skipped
    ✓ Correct answer: B

    GitHub Actions strictly enforces a maximum nesting depth of 4 for reusable workflows. In the scenario described, A calling B calling C calling D calling E is 4 levels deep and would work, but adding E calling F creates a 5th level which exceeds the limit and results in a workflow error. Teams should architect their reusable workflow hierarchies to stay within this constraint.

    Why the other options are wrong
    • AGitHub Actions does not support unlimited nesting; the 4-level limit exists to prevent excessive complexity and potential circular dependency issues.
    • CGitHub does not generate a deprecation warning for deep nesting and still allow it; the run fails immediately when the 4-level limit is exceeded.
    • DGitHub does not silently skip the 5th level - the run fails with an error when the nesting limit is exceeded.
  5. Question 5Author and manage workflows

    A caller workflow sets 'jobs.ci.uses: ./.github/workflows/build.yml'. What does the leading './' signify?

    • AThe reusable workflow is on the caller's default branch
    • BThe reusable workflow is pinned to a specific SHA
    • CThe reusable workflow must be in the .github/workflows directory only
    • DThe reusable workflow file is in the same repository as the callerCorrect
    ✓ Correct answer: D

    Using './' as a prefix on the 'uses' path tells GitHub Actions the referenced workflow file is in the same repository as the calling workflow. Cross-repository reusable workflows use the format 'owner/repo/.github/workflows/file.yml@ref'. The same-repo form automatically resolves to the same commit SHA as the caller.

    Why the other options are wrong
    • ASame-repository reusable workflows resolve to the same SHA as the calling workflow's run context, not necessarily the default branch HEAD.
    • B'./' does not pin to a SHA; pinning requires an explicit '@sha' suffix on a cross-repository reference.
    • CReusable workflow files must reside in '.github/workflows/' regardless of whether the './' prefix is used; the prefix indicates same-repo, not directory restriction.
  6. Question 6Author and manage workflows

    A step uses 'uses: actions/checkout@v4'. What does the 'uses' keyword indicate about this step?

    • AIt imports environment variables from a specified file into the job.
    • BIt references a reusable action from a repository, Docker image, or local path.Correct
    • CIt copies files from the specified path into the runner workspace.
    • DIt runs an inline shell script defined in the workflow file.
    ✓ Correct answer: B

    The 'uses' keyword in a step definition references a reusable action. This can be a GitHub-hosted action (owner/repo@ref), a Docker container action (docker://image:tag), or a local action defined in the same repository (./.github/actions/my-action). The referenced action's action.yml defines its inputs, outputs, and execution logic. A step can use either 'uses' or 'run', but not both.

    Why the other options are wrong
    • AImporting environment variables from a file is done by writing to $GITHUB_ENV, not by using the 'uses' keyword.
    • CCopying files into the workspace is not what 'uses' does - it references an action that executes logic, which may or may not involve file operations.
    • DInline shell scripts are defined with the 'run' keyword, not 'uses' - the two keywords are mutually exclusive in a single step.
  7. Question 7Consume and troubleshoot workflows

    A run had 5 jobs; 3 succeeded and 2 failed. You click Re-run failed jobs. What happens?

    • AEvery job in the run executes again from the start
    • BOnly the exact jobs that failed re-run; dependents skip
    • CFailed jobs plus any jobs that depend on them re-runCorrect
    • DA fresh run starts from the newest commit on the branch
    ✓ Correct answer: C

    GitHub reuses the results of jobs that already succeeded and re-runs only the failed jobs plus downstream jobs that need them, all against the same commit SHA as the original run. This saves minutes while keeping dependency ordering intact.

    Why the other options are wrong
    • ARe-running every job is what Re-run all jobs does, not Re-run failed jobs.
    • BDependent jobs are not skipped; they re-run so downstream results stay consistent.
    • DRe-running uses the original commit and workflow version, not the newest commit.
  8. Question 8Author and maintain actions

    In which action type is the inputs context, for example ${{ inputs.foo }}, the intended way to read declared inputs?

    • AJavaScript (node20) actions
    • BDocker container actions
    • CComposite actionsCorrect
    • DAll action types identically
    ✓ Correct answer: C

    Composite actions use ${{ inputs.foo }} to reference declared inputs because they do not get INPUT_* variables automatically. JavaScript actions read INPUT_ variables via core.getInput, and Docker actions read INPUT_ environment variables.

    Why the other options are wrong
    • AJavaScript actions read inputs via core.getInput from INPUT_ variables, not the inputs context.
    • BDocker actions consume inputs as INPUT_ environment variables.
    • DThe mechanism differs by action type, so it is not identical everywhere.
  9. Question 9Manage GitHub Actions for the enterprise

    An enterprise admin registers a runner at the enterprise level and adds --runnergroup Production. What is the effect of this flag?

    • ARenames the host machine
    • BEnables ephemeral mode
    • CSets the work directory
    • DAdds it to that groupCorrect
    ✓ Correct answer: D

    Runner groups control which organizations or repositories may use a set of runners. Passing --runnergroup Production places the machine into that group so its access policy applies; without the flag the runner joins the Default group.

    Why the other options are wrong
    • AThe machine name is set with --name, not --runnergroup.
    • BEphemeral behavior is enabled by --ephemeral.
    • CThe work folder is set with --work.
  10. Question 10Manage GitHub Actions for the enterprise

    Where does an organization publish reusable starter (template) workflows so they appear when members create a new workflow?

    • AThe .github/workflows folder of each repo
    • BA gist owned by the organization
    • CThe organization's package registry
    • DThe .github repo's workflow-templates folderCorrect
    ✓ Correct answer: D

    An organization creates a public or internal repository named .github and adds a workflow-templates folder containing the YAML plus a matching metadata JSON. Members then see these starter workflows offered in the new-workflow picker.

    Why the other options are wrong
    • AThe .github/workflows folder holds a repo's active workflows, not org-wide templates.
    • BGists are not scanned as a source of starter workflows.
    • CThe package registry stores build artifacts, not workflow templates.

Who this GitHub Actions practice exam is for

This practice set is for anyone preparing for the GitHub Actions exam - from first-time candidates building a foundation to experienced GitHub practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this GitHub Actions practice exam

  1. Start with the free sample questions above to gauge your current baseline.
  2. Read the full explanation on every question, including why each wrong option is wrong.
  3. Track your weak domains and focus your study where you are losing the most marks.
  4. Once you are scoring consistently well, take a timed, full-length mock exam.
  5. Use your readiness score to decide when you are ready to book the real GitHub Actions exam.

Related GitHub resources

GitHub Actions practice exam FAQ

How many questions are in the GitHub Actions practice exam on CertGrid?

CertGrid has 969 practice questions for GitHub Actions, covering 5 exam domains. The real GitHub Actions exam is ~60 qs in 100 min. CertGrid's timed mock is a fixed 60 questions.

What is the passing score for GitHub Actions?

The GitHub Actions exam passing score is 70%, and you have about 100 min to complete it. CertGrid scores your practice attempts the same way so you know when you are ready.

Are these official GitHub Actions exam questions?

No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the GitHub Actions exam.

Is there a free GitHub Actions practice test?

Yes. You can take a free GitHub Actions practice test straight away: a fixed set of 20 practice questions for this exam, retryable as often as you like, with no credit card required. You get readiness scoring and a weak-domain breakdown on those questions. Paid plans unlock the full 969-question bank, timed mock exams and full-bank domain analytics.

What CertGrid is (and is not)

CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.

Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by GitHub. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.