GitHub Actions Certification (GH - 200) Exam Questions 2026 GitHub Actions Certification (GH - 200) Questions 2026 Contains 490+ exam questions to pass the exam in first attempt. SkillCertPro offers real exam questions for practice for all major IT certifications. • For a full set of 500 questions. Go to https://skillcertpro.com/product/github - actions - certification - exam - questions/ • SkillCertPro offers detailed explanations to each question which helps to understand the concepts better. • It is recommended to score above 85% in SkillCertPro exams before attempting a real exam. • SkillCertPro updates exam questions every 2 weeks. • You will get life time access and life time free updates • SkillCertPro assures 100% pass guarantee in first attempt. Below are the free 10 sample questions. Question 1: A Docker container custom action defines the instruction ENTRYPOINT [“/entrypoint.sh“] in the Dockerfile. How do you indicate a failure condition in the file entrypoint.sh? A.fail(“This is bad!“) B.core.setFailed(“Failure“); C.docker.failed(“My message“); D.exit 99 Answer: D Explanation: D. exit 99 In a GitHub Actions Docker container custom action, the runner evaluates the execution outcome based on the exit code returned by the entrypoint script (/entrypoint.sh). A return code of 0 indicates success, whereas any non - zero exit code (such as 1, 99, etc.) signals to GitHub Actions that the action step has failed, causing the job to stop or trigger failure handling. Incorrect: A. fail(“This is bad!“) fail() is not a standard shell command or syntax in bash/sh entrypoint scripts. Attemptin g to call fail() directly in a Linux shell script will cause a command not found error. B. core.setFailed(“Failure“); core.setFailed() is part of the @actions/core JavaScript/TypeScript Toolkit used specifically for JavaScript custom actions running in Node.js, not standalone Bash/Shell scripts inside Docker container actions. C. docker.failed(“My message“); docker.failed() is a fabricated method. Neither the Docker CLI nor the GitHub Actions runner provides a docker.failed command or utility inside con tainer action environments. Question 2: Describe the steps for sharing a custom action with repositories only within your enterprise (not publicly)? (choose two) A.Build a TAR file from the action‘s code and register it in the enterprise settings of GitHub. B.Store the action or reusable workflow in an internal or private repository. C.Configure the repository to allow access to workflows in other internal or private repositories. D.Publish the action to the GitHub Marketplace. Answer: B and C Explanation: B. Store the action or reusable workflow in an internal or private repository. To limit access to an action within an enterprise, the repository holding the custom action or reusable workflow must be set to internal (accessible by all enterprise members) or private (accessible by specific allowed members/teams). C. Configure the repository to allow access to workflows in other internal or private repositories. Under the action repository's Settings > Actions > General, you must explicitly configure the " Access" setting to allow other internal or private repositories within the enterprise (or organization) to consume actions and reusable workflows located in that repository. Incorrect: A. Build a TAR file from the action‘s code and register it in the enterprise settings of GitHub. GitHub Actions does not use TAR archives or enterprise - level file registrations to distribute custom actions. Custom actions are consumed directly via Git references (branches, tags, or commit SHAs) pointing to GitHub reposito ries. D. Publish the action to the GitHub Marketplace. Publishing an action to the GitHub Marketplace makes it publicly available to all GitHub users worldwide, which directly violates the requirement to restrict access strictly within your enterprise. Question 3 : The administrator of your GitHub Enterprise Server organization configured IP allowlists. How do you register a self - hosted runner given this configuration? A.Newly registered runners are automatically added to the allowlist. B.You need to add the IP address of the runner to the allowlist. C.You need to register the runner by name. D.The IP allowlist has no effect on runners. Answer: B Explanation: If your Enterprise Cloud or Enterprise Server organization has configured IP allowlists, you must add the IP address or IP address range of your self - hosted runners to the IP allowlist in order for your self - hosted runners to communicate with GitHub. To add the IP address or IP address range of your self - hosted runners to an organization IP allowlist: Navigate to your organization Settings. Select Organization security in the sidebar. Under IP Address, add the IP address or IP address range of your self - hosted runners in CIDR notation. Select + Add. Reference: https://learn.microsoft.com/en - us/training/modules/manage - github - actions - enterprise/manage - runners Question 4 : True or false? You can download an artifact stored for a workflow run using the UI and API. A.False B.True Answer: B Explanation: True GitHub Actions allows you to download build artifacts generated during a workflow run through both the GitHub web interface (UI) and the REST API. In the UI, artifacts can be downloaded directly from the Summary page of a completed workflow run. Programmatically, you can retrieve, list, or download zip archives of artifacts using the GitHub REST API endpoints (e.g., GET /repos/{owner}/{repo}/actions/artifacts/{artifact_id}/{archive_format}). Artifacts can be downloaded using the GitHub Actions UI a nd the GitHub REST API. https://docs.github.com/en/actions/managing - workflow - runs/downloading - workflow - artifacts https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022 - 11 - 28#get - an - artifact Question 5 : As a developer of a custom action, you want to set up a test that uses the action from the same GitHub repository without having to publish it. Select the correct notation for an action named crafty. A.steps: - name: Use custom action uses: crafty@v1 B.steps: - name: Use custom action uses: ./ C.steps: - name: Use custom action uses: crafty@latest D.steps: - name: Use custom action uses: crafty Answer: B Explanation: B. steps: - name: Use custom action uses: ./ When testing or running a custom action located within the same repository as the workflow that invokes it, you reference the action using local path syntax relative to the root of the repository (./). If the a ction's action.yml file sits in the root directory, using uses: ./ allows GitHub Actions to execute the action directly from the workspace checkout without needing to reference remote release tags, commit SHAs, or external repository names. Incorrect: A. steps: - name: Use custom action uses: crafty@v1 Syntactically, referencing an action by name without an owner prefix (e.g., owner/repo@version) is invalid in GitHub Actions. Additionally, using @v1 relies on a published release tag, which directly viol ates the requirement to test the action locally without publishing it. C. steps: - name: Use custom action uses: crafty@latest crafty@latest is invalid syntax. GitHub Actions does not support a @latest tag by default, nor can an action be referenced without its repository owner path ({owner}/{repo}). D. steps: - name: Use custom action uses: crafty Bare strings like crafty are invalid for the uses key. GitHub Actions requires either a relative file path (starting with ./) for local actions or a full rep ository reference (owner/repo@ref) for remote actions. • For a full set of 500 questions. Go to https://skillcertpro.com/product/github - actions - certification - exam - questions/ • SkillCertPro offers detailed explanations to each question which helps to understand the concepts better. • It is recommended to score above 85% in SkillCertPro exams before attempting a real exam. • SkillCertPro updates exam questions every 2 weeks. • You will get life time access and life time free updates • SkillCertPro assures 100% pass guarantee in first attempt. Question 6 : Your custom action needs to run cleanup logic at the end of a job. How do you declare such functionality in the action.yml file? A.runs: using: ‘node20‘ exit: ‘cleanup.sh‘ B.runs: using: ‘node20‘ post: ‘cleanup.js‘ C.runs: using: ‘node20‘ post: ‘cleanup.sh‘ D.runs: using: ‘node20‘ cleanup: ‘myscript.js‘ Answer: B Explanation: B. runs: using: ‘node20‘ post: ‘cleanup.js‘ In GitHub Actions custom JavaScript actions (such as those running on node20 or node24), you define cleanup or post - execution logic in action.yml using the post: key under the runs: section. The script specified in post: automatically runs at the end of the job, regardless of whether prior steps succeeded or failed (unless controlled otherwise via post - if). Incorrect: A. runs: using: ‘node20‘ exit: ‘cleanup.sh‘ exit: is not a valid syntax key in the action.y ml metadata specification. To define post - job steps, GitHub Actions specifically requires the post: key. Additionally, JavaScript actions execute Node.js scripts (.js files) rather than shell scripts (.sh). C. runs: using: ‘node20‘ post: ‘cleanup.sh‘ While post: is the correct key, specifying a shell script (.sh) under a JavaScript runner environment (using: 'node20') is invalid syntax. For Node.js - based actions, the file assigned to post: must be a JavaScript file (.js) parsed and executed by the Node runtime. D. runs: using: ‘node20‘ cleanup: ‘myscript.js‘ cleanup: is not a recognized property in the action.yml syntax schema. The property designated for post - job cleanup execution is strictly named post:. Question 7 : Which directory in a GitHub repository is responsible for hosting workflow files? A..github B..github/templates C..github/runs D..github/workflows E..github/actions Answer: D Explanation: D. .github/workflows GitHub Actions automatically searches the .github/workflows directory in the root of your repository for workflow files defined in YAML (.yml or .yaml). Any valid workflow file placed inside this exact path is recognized and evaluated by GitHub's workflow engine when its specified triggers occur. Incorrect: A. .github While .github is the required parent directory for storing GitHub - specific configuration files (such as issue templates, CODEOWNERS, and workflow configurations), plac ing workflow .yml files directly in .github without the workflows subfolder will prevent GitHub Actions from discovering or executing them. B. .github/templates The .github/templates directory is not a standard directory recognized by GitHub Actions for workflow execution. GitHub uses .github/workflow - templates (not templates) specifically for sharing organization - wide starter workflow templates. C. .github/runs .github/runs is a fabricated path and holds no special status or functionality within GitHub Actions or GitHub repository structures. E. .github/actions The .github/actions directory is traditionally used to store local composite or Docker custom actions defined within the repository, not individual workflow definitions. Workflow execution files must reside strictly inside .github/workflows. Question 8 : A CI/CD team published the initial version of a custom action to the GitHub Marketplace. After making further changes, they want to a release a new version. What‘s the most common practice for releasing a changeset? (choose two) A.Do nothing. Consumers can simply refer to the Git commit hash. B.Create a new release in the GitHub repository. C.Increment the version on the corresponding Git Marketplace manually. D.Tag the commit with a version (optimally using semantic versioning) and push it. E.Create and push a new branch with the version as the name. Answer: B and D Explanation: B. Create a new release in the GitHub repository. Creating a release in the GitHub repository triggers an update to the action on the GitHub Marketplace. Releasing on GitHub automatically links the specified Git tag and release notes, publishing the updated version to marketplace consumers. D. Tag the commit with a version (optimally using semantic versioning) and push it. The standard best practice for GitHub Actions is using Semantic Versioning (e.g., v1.0.0, v1.1.0) via Git tags. Furthermore, actions best practices recommend maintaining major version tags (e.g., updating a floating v1 tag to point to the latest v1.x.x commit) so consumers using uses: actions/my - action@v1 automatically receive non - breaking updates. Incorrect: A. Do nothing. Consumers can simply refer to the Git commit hash. While referencing a full 40 - character Git commit SHA is supported for strict security/pinning purposes, it is not a version release practice for custom actions. "Doing nothing" fails to inform Marketplace users of new features or updates and doesn't update the Marketplace listing. C. Increment the version on the corresponding Git Marketplace manually. There is no independent "Git Marketplace" where you manually edit a version string. The GitHub Marketplace direct ly mirrors and reflects the GitHub releases and Git tags created inside the action's repository. E. Create and push a new branch with the version as the name. Branching with version names (e.g., creating a branch named v1.2.0) is not the standard mechanism for releasing actions. GitHub Actions relies on Git tags and GitHub Releases to track and publish distinct action releases. Question 9 : The following command performs a call to the GitHub API. What‘s its purpose? curl - v - u username:$token - H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/{owner}/{repo}/actions/runs/319282523477/logs A.Enabling debug logging for a workflow. B.Retrieving the runner logs for a job. C.Returning meta information about a job. D.Downloading the logs for a job. Answer: D Explanation: D. Downloading the logs for a job. The GitHub REST API endpoint /repos/{owner}/{repo}/actions/runs/{run_id}/logs is specifically designed to download an archive containing the execution log files for a specific workflow run. Executing a GET request against this endpoint returns a 302 Found redirect URL pointing to a downloadable .zip archive containing the full log files. Incorrect: A. Enabling debug logging for a workflow. Enabling debug logging requires setting repository or organization secrets/varia bles (such as ACTIONS_STEP_DEBUG or ACTIONS_RUNNER_DEBUG set to true), or re - running a workflow via API/UI with the debug logging flag enabled. Making a simple GET request to /actions/runs/{run_id}/logs only downloads existing logs; it does not change configuration settings or enable debug modes. B. Retrieving the runner logs for a job. "Runner logs" typically refer to system - level diagnostic logs on self - hosted runner machines (e.g., Worker or Runner service logs located on the host OS), whereas this AP I endpoint returns job/step execution logs for a specific workflow run. C. Returning meta information about a job. Meta information (metadata such as status, conclusion, start/end timestamps, or associated commits) for a workflow run or job is retrieved using endpoints like /actions/runs/{run_id} or /actions/jobs/{job_id}, which return JSON payloads rather than archived log streams. Question 10 : A specific self - hosted runner seems to have issues with executing jobs. How do you enable debug logging for the runner? A.Set the secret ACTIONS_RUNNER_DEBUG: true for the repository containing the workflow. B.Add the environment variable ACTIONS_DEBUG: true for the job in the workflow file. C.Enable debug logging through the UI under Settings > Actions > Runners. D.You need to open a shell to the runner and inspect the logs in the file system. They should already contain the relevant information. Answer: A Explanation: A. Set the secret ACTIONS_RUNNER_DEBUG: true for the repository containing the workflow. To enable runner diagnostic logging for self - hosted runners, you create a repository or organization secret (or variable) named ACTIONS_RUNNER_DEBUG and set its value to true. When enabled, the runner generates additional diagnostic log files in its _diag folder, detailing internal runner processes, system state, and job execution steps. Incorrect: B. Add the environment variable ACTIONS_DEBUG: true for the job in the workflow file. ACTIONS_DEBUG is not a valid configuration variable for GitHub Actions. For step - level debug logging, GitHub uses ACTIONS_STEP_DEBUG, whereas runner - level diagnostic logging requires ACTIONS_RUNNER_DEBUG. C. Enable debug logging through the UI under Settings > Actions > Runners. GitHub's web interface does not feature a toggle switch or configuration setting under Settings > Actions > Runners to enable runner debug logging. Diagnostic logging must be configured via repository/organizati on secrets/variables or environment variables. D. You need to open a shell to the runner and inspect the logs in the file system. They should already contain the relevant information. By default, self - hosted runner logs only record standard operational and info - level events. Detailed diagnostic information (such as internal task execution details and API communications) is omitted from standard log files until ACTIONS_RUNNER_DEBUG is explicitly set to true. • For a full set of 500 questions. Go to https://skillcertpro.com/product/github - actions - certification - exam - questions/ • SkillCertPro offers detailed explanations to each question which helps to understand the concepts better. • It is recommended to score above 85% in SkillCertPro exams before attempting a real exam. • SkillCertPro updates exam questions every 2 weeks. • You will get life time access and life time free updates • SkillCertPro assures 100% pass guarantee in first attempt.