GitHub Actions Practice Exam
Validates building and managing CI/CD workflows with GitHub Actions — workflows, runners, secrets, and reusable/custom actions.
Practice 293 exam-style GitHub Actions questions with full answer explanations, then take timed mock exams that score like the real thing.
What the GitHub Actions exam covers
- Workflows and Events79 questions
- Jobs, Steps, and Runners85 questions
- Secrets and Security65 questions
- Reuse and Optimization64 questions
Free GitHub Actions sample questions
A sample of 10 questions with answers and explanations. Sign up free to practice all 293.
-
In what file format and location are GitHub Actions workflows defined?
- AA DHCP config
- BYAML files in .github/workflows/ in the repositoryCorrect
- CA DNS zone file
- DJSON in the repo root only
✓ Correct answer: BGitHub 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 DHCP config is incorrect because DHCP and DNS are network infrastructure concepts unrelated to GitHub Actions or Git version control.
- CA DNS zone file is incorrect because DHCP and DNS are network infrastructure concepts unrelated to GitHub Actions or Git version control.
- DJSON in the repo root only is incorrect because it does not represent the appropriate GitHub feature for this scenario.
-
Which step keyword runs shell commands?
- AOn:
- Brun:Correct
- Cneeds:
- Duses:
✓ Correct answer: Brun: executes command-line programs in the runner's shell, such as Bash on Linux/macOS or PowerShell on Windows, and you can supply multiple lines with a block scalar. Each run: step starts a new shell process by default, and you can change the interpreter with the shell: key. It is how a step performs custom scripting rather than delegating to a prebuilt action.
Why the other options are wrong- AOn: defines the events that trigger the workflow; it controls when the workflow runs and does not execute shell commands.
- Cneeds: makes a job wait for other jobs to finish first; it sequences jobs rather than running any commands.
- Duses: references a reusable action to run in a step; it invokes packaged code instead of running inline shell commands.
-
For GitHub-hosted runners on private repos, how is billable usage of standard Linux runners calculated?
- ABy number of steps regardless of duration
- BBy rounded-up wall-clock minutes per job, with a per-minute rate (Windows and macOS cost more multipliers)Correct
- CBy number of commits pushed
- DBy repository size in GB
✓ Correct answer: BRunners are the execution environments where GitHub Actions workflows run. GitHub provides hosted runners with standard operating system images including Ubuntu, Windows, and macOS. Self-hosted runners enable execution on custom infrastructure for specialized hardware, network access, or compliance requirements. Runner selection directly impacts workflow capabilities and cost.
Why the other options are wrong- ABy number of steps regardless of duration is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- CBy number of commits pushed is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- DBy repository size in GB is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
-
Which trigger configuration avoids running the same heavy workflow on every commit of a busy branch while still validating the final state?
- AAdd continue-on-error to every job
- BUse schedule every minute
- CCombine concurrency with cancel-in-progress so only the latest push of a branch keeps runningCorrect
- DTrigger on push to all branches with no concurrency
✓ Correct answer: CGitHub 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- AAdd continue-on-error to every job is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- BUse schedule every minute is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- DTrigger on push to all branches with no concurrency is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
-
Which TWO are valid ways to reduce duplicated workflow logic across a repository? (Choose TWO)
- ADefine a reusable workflow with on: workflow_call and invoke it via a job's uses:Correct
- Bcreate a composite action in .github/actions and call it with uses:Correct
- CCopy the same steps into every workflow file manually
- DStore the YAML in a Gist and link it in the README
✓ Correct answer: A, Bcreate a composite action in .github/actions and call it with uses:. Both correct answers represent complementary best practices that work together to address the requirement. Implementing both approaches provides comprehensive coverage of the GitHub concept or optimization.
Why the other options are wrong- CCopy the same steps into every workflow file manually is incorrect because it does not represent a valid GitHub feature or pattern.
- DStore the YAML in a Gist and link it in the README is incorrect because it does not represent a valid GitHub feature or pattern.
-
You are deciding between GitHub-hosted and self-hosted runners for a job that must reach an on-prem database behind a corporate firewall. Which is the better architectural fit and why?
- Aneither; jobs cannot access databases
- BGitHub-hosted runners, because they automatically have access to private corporate networks
- Ceither one; network location is irrelevant to runners
- Dself-hosted runners, because they can be placed inside the network with access to private/on-prem resourcesCorrect
✓ Correct answer: DRunners are the execution environments where GitHub Actions workflows run. GitHub provides hosted runners with standard operating system images including Ubuntu, Windows, and macOS. Self-hosted runners enable execution on custom infrastructure for specialized hardware, network access, or compliance requirements. Runner selection directly impacts workflow capabilities and cost.
Why the other options are wrong- Aneither; jobs cannot access databases is incorrect because it incorrectly claims a feature or capability does not exist when GitHub Actions or Git actually supports it.
- BGitHub-hosted runners, because they automatically have access to private corporate networks is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- Ceither one; network location is irrelevant to runners is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
-
An environment has a required reviewer and a wait timer of 30 minutes. A deploy job targets this environment. What is the gotcha regarding the workflow run time limit?
- AThe approval/wait time counts against the overall run lifetime (max 35 days), and a job can wait for approval up to 30 days before it is cancelledCorrect
- BWait timers and approvals do not consume any time limit
- CApproval gates make the job exempt from all time limits permanently
- DThe job restarts the 6-hour clock for every reviewer
✓ Correct answer: AGitHub 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- BWait timers and approvals do not consume any time limit is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- CApproval gates make the job exempt from all time limits permanently is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- DThe job restarts the 6-hour clock for every reviewer is incorrect because README files are documentation artifacts, gists are code snippets, stars are social features for marking favorite repositories, and printers are hardware devices - none are GitHub Actions or Git functionality.
-
Which TWO help you observe and report the outcome of a workflow externally? (Choose TWO)
- AAppend the result to a DNS TXT record
- Buse the Checks/Commit Status API to publish run status to the commit/PRCorrect
- CWrite a Markdown summary to $GITHUB_STEP_SUMMARYCorrect
- DStore the result only in the runner's BIOS
✓ Correct answer: B, CWrite a Markdown summary to $GITHUB_STEP_SUMMARY. These answers correctly identify valid GitHub Actions features or patterns. Both represent correct implementations for the scenario described in the question.
Why the other options are wrong- AAppend the result to a DNS TXT record is incorrect because it involves network infrastructure concepts unrelated to GitHub Actions or Git functionality.
- DStore the result only in the runner's BIOS is incorrect because it does not represent a valid GitHub feature or pattern.
-
You integrate a workflow with an external API and must avoid leaking the API key in logs. Besides storing it as a secret, what additional protection does GitHub Actions provide automatically?
- ASecrets are stored in a public artifact
- BLogs are disabled whenever a secret is used
- CSecrets are emailed to admins instead of logged
- DRegistered secret values are masked (replaced with ***) in workflow logsCorrect
✓ Correct answer: DGitHub 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- ASecrets are stored in a public artifact is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- BLogs are disabled whenever a secret is used is incorrect because it incorrectly claims a feature or capability does not exist when GitHub Actions or Git actually supports it.
- CSecrets are emailed to admins instead of logged is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
-
In an OIDC trust policy for a cloud role, which claim should you constrain to limit assumption to a specific repository and branch?
- AThe 'jti' claim
- BThe 'sub' claim (e.g., repo:org/name:ref:refs/heads/main)Correct
- CThe 'aud' claim set to the repo URL
- DThe 'iat' claim
✓ Correct answer: BGit is the distributed version control system that underlies GitHub. Commits represent immutable snapshots of code changes with unique SHA hashes. Branches enable parallel development lines. Understanding Git concepts is fundamental to using GitHub effectively for version control and collaboration.
Why the other options are wrong- AThe 'jti' claim is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- CThe 'aud' claim set to the repo URL is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
- DThe 'iat' claim is incorrect because it does not represent the appropriate GitHub feature, configuration, or best practice for this scenario.
GitHub Actions practice exam FAQ
How many questions are in the GitHub Actions practice exam on CertGrid?
CertGrid has 293 practice questions for GitHub Actions, covering 4 exam domains. The real GitHub Actions exam has about 60 questions.
What is the passing score for GitHub Actions?
The GitHub Actions exam passing score is 700, and you have about 120 minutes 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. Questions are written to mirror the style and concepts of GitHub Actions, with full explanations, but they are not official or copied vendor exam items. They are original practice questions designed to help you genuinely learn the material.
Can I practice GitHub Actions for free?
Yes. You can start practicing GitHub Actions for free with daily practice and sample questions. Paid plans unlock full timed exams, complete explanations, and domain analytics.