GH-200 GitHub Actions Exam Questions and Answers

The best way for an enterprise to control which GitHub Actions run is by creating a list of approved actions as an enterprise policy. This approach restricts workflows to only use the actions that are explicitly allowed, ensuring security and compliance within the organization.

The action.yml file is the metadata file in a custom GitHub Action that defines the main entry point, including information such as the inputs, outputs, description, and the runs key that specifies the main entry point (e.g., a script or a Docker container).

Organization starter workflow templates must be stored in a special workflow template directory so that they appear in the GitHub Actions “New workflow” interface. The correct location is .github/workflow-templates, typically in the organization’s .github repository. Therefore, option C is correct. Option A, .github/workflows, is where active workflow files are stored inside a repository so they can be triggered by events. It is not the correct location for organization-level starter templates. Option B is not a valid GitHub Actions workflow template directory. Option D is incorrect because storing the file in each repository’s root does not publish it as a reusable starter workflow template. This checks workflow template reuse and organization automation standardization.

================

Documentation is critical when distributing custom GitHub Actions because users need to understand what the action does and how to use it correctly. A good README or marketplace description explains the action’s purpose, required inputs, outputs, permissions, and expected behavior. This directly supports option B. Documentation should also include practical usage examples, such as a workflow snippet showing the uses: syntax and required with: inputs, which supports option C. Option A is incorrect because documentation does not create a README inside the consuming workflow; the action author provides documentation in the action repository. Option D is also incorrect because documentation does not automatically generate workflow auto-completion. This topic tests custom action publishing and usability best practices.

================

The workflow_call event is used to trigger a reusable workflow from another workflow. This allows you to create workflows that can be reused in multiple places within your organization, enabling better modularity and reducing duplication.

The GITHUB_REPOSITORY environment variable contains the owner and repository name in the format owner/repository. It is automatically provided by GitHub Actions and can be used to reference the repository in workflows.

The correct native GitHub Actions method for passing files between jobs in the same workflow is artifact storage. Workflow artifacts are designed to persist files produced by one job so they can be downloaded and used by another job later in the workflow. Job outputs are better suited for passing small values, strings, IDs, flags, or metadata between jobs, not full files. Caching is intended to speed up repeated workflow runs by reusing dependencies or build outputs; it is not the proper mechanism for transferring job-produced files. An external blob store can work architecturally, but it is not the native GitHub Actions method. Therefore, artifact storage is the best and most exam-aligned answer for passing files between jobs.

The GITHUB_REF environment variable specifies the branch or tag that triggered the workflow. It contains the full reference to the branch or tag, such as refs/heads/main for a branch or refs/tags/v1.0 for a tag.

The provided event trigger block specifies two types of events:

For issues: the workflow triggers on opened or edited issues.

For issue_comment: the workflow triggers when an issue comment is created.

This configuration ensures the workflow will run when either an issue is opened or edited, or an issue comment is created.

A. Use the actions/setup-docker action

B. Authenticate to the GitHub Container Registry.

C. Build the container image.

D. Push the image to the GitHub Container Registry

E. Pull the image from the GitHub Container Registry.

The GITHUB_TOKEN is automatically provided by GitHub in workflows and can be used to authenticate API requests to GitHub, including publishing packages to GitHub Packages.

The GITHUB_TOKEN is also used to authenticate API requests for actions like creating issues, commenting, or interacting with pull requests within the same repository.

The smallest scope for an environment variable is within a step. Environment variables defined within a step are only accessible to that particular step, which makes it the smallest scope for a variable in a GitHub Actions workflow.

The correct minimal syntax for declaring an output in GitHub Actions is by using the foo key under outputs, and associating it with a value (in this case, Some value). This is the simplest form to define an output in a workflow or action.

A non-zero exit code is used to set the status of an action to " failed " in GitHub Actions. When the action ' s script or code exits with a non-zero status, it indicates failure, and GitHub will mark the action as failed.

GitHub-hosted runners have a limit on the number of concurrent workflows (typically 20 for free-tier accounts and 5 for enterprise). If your organization needs to run more workflows simultaneously, you would need to use self-hosted runners to increase the available concurrency.

Self-hosted runners allow you to configure specialized hardware or software setups that are necessary for certain workflows. GitHub-hosted runners may not have access to custom hardware configurations like GPUs or other specialized resources, so self-hosted runners are required in such cases.

GitHub self-hosted runners maintain diagnostic information locally in the _diag directory beneath the runner installation directory. The runner application creates Runner_*.log files containing information about startup, connectivity, registration, updates, and general runner activity. Job-specific execution details are written to Worker_*.log files in the same diagnostic directory. These logs are therefore the primary source when investigating intermittent connection or execution problems. GitHub ' s troubleshooting documentation explicitly directs administrators to inspect the _diag directory and also provides connectivity-check scripts for diagnosing communication failures. The other options describe mechanisms that are not the documented standard procedure: there is no general repository-settings feature for downloading the runner ' s local diagnostic archive, and the suggested generic --debug and DEBUG=true mechanisms are not the prescribed runner troubleshooting method.

================

The correct solution is to create an organization-level Actions secret. This minimizes administrative effort because the secret can be managed once at the organization level and made available to all repositories or selected repositories through an access policy. Option D gives the correct navigation path: organization page, Settings, Secrets and variables, then Actions. Option A would require duplicating the secret in every repository, increasing maintenance overhead and risk of inconsistent values. Option B is wrong because personal developer settings do not centrally expose a secret to all organization repositories. Option C is incomplete because the current GitHub path places Actions secrets under “Secrets and variables,” not just a generic “Security > Secrets” location. GitHub documents organization secrets and the repository access policy model for sharing them.

GitHub ' s REST API provides a dedicated Download workflow run logs endpoint. The request uses the HTTP GET method and the path /repos/{owner}/{repo}/actions/runs/{run_id}/logs. GitHub responds with a redirect to an archive containing the log files for that workflow run. The endpoint requires the repository owner, repository name, and workflow run ID. For private repositories, the caller must authenticate with appropriate repository or Actions read permissions. A POST request is not used because retrieving logs is a read operation. The artifacts endpoint manages workflow artifacts rather than workflow execution logs. Therefore, option A exactly matches the current GitHub REST API endpoint documented for downloading the log archive associated with a workflow run.

================

Environment secrets are scoped to GitHub Actions environments and can be protected by environment protection rules. If an environment requires reviewers, a job that references that environment cannot access its environment secrets until the required approval is granted. This makes option A correct. Option B is incorrect because environment secrets are made available to jobs that reference the protected environment, not selectively to only one specific step by default. Option C is not the purpose of environment secrets; they are not specifically for connecting to GitHub Enterprise Server. Option D is also incorrect because GitHub environment secrets do not automatically pull from Azure Key Vault without additional integration or custom workflow logic. This topic covers environment protection, secrets, and deployment governance.

================

Creating workflow templates in the organization’s .github repository allows the organization to standardize workflows and make them easily reusable across multiple repositories. This ensures consistency and simplifies maintenance.

Creating reusable actions and workflows that can be called from other workflows helps modularize and standardize automation tasks. These reusable components can be maintained centrally and called from different workflows across repositories.

Since the self-hosted runner is configured on a Linux VM and the script is written in PowerShell, you can invoke the script using the pwsh (PowerShell Core) shell in a run step in the workflow. This ensures that the script runs as-is on the Linux runner, as PowerShell Core (pwsh) is cross-platform and supports Linux.

GitHub allows an organization to restrict workflows so that they use only actions and reusable workflows available within that organization. When such a policy is enforced, external third-party actions and Marketplace actions can be prevented from running. Custom actions intended for internal reuse should therefore be stored in repositories owned by the organization. GitHub also allows private or internal repositories containing actions to be made accessible to other repositories in the same organization or enterprise. The .github repository has special organization-wide uses, such as workflow templates, but it is not the mandatory distribution location for all custom actions. A third-party repository or the public Marketplace would conflict with an organization-only policy. Therefore, distributing the actions through organization-owned repositories is the appropriate approach.

================

Scheduled GitHub Actions workflows use the schedule event beneath the workflow ' s on key. Each schedule is represented by a cron entry, which makes option A the valid structure. GitHub scheduled workflows use POSIX-style five-field cron syntax, and scheduled execution is interpreted in UTC by default. In the expression 45 7 * * 3,6, 45 represents minute 45, 7 represents 07:00 UTC, the two asterisks allow every day of the month and every month, and 3,6 specifies Wednesday and Saturday. Consequently, the workflow is scheduled for 07:45 UTC on both requested weekdays. Options B and D incorrectly place cron directly beneath on, while option C does not use the required schedule list containing a cron entry.

================

The needs context is used to reference the outputs of jobs that are dependencies of the current job. In this case, needs.job1.outputs.output1 correctly accesses the output of output1 from the job job1 in the dependent job.

GitHub Marketplace is used to discover, share, and publish reusable automation, including GitHub Actions created by GitHub, vendors, and the community. Option C best describes this role. Marketplace does not exist only for billing, so option B is too narrow and incorrect. Option A is also wrong because Marketplace does not merely restrict third-party actions to public repositories; action usage is governed by repository, organization, or enterprise Actions policies. Option D is false because Marketplace does not bypass repository permissions or automatically deploy workflows into repositories. In exam terms, Marketplace is part of the automation reuse and action discovery domain: developers use it to find trusted or verified actions rather than building every integration manually. GitHub documents Marketplace as a place to publish and share actions with the community.

For a JavaScript action using the official @actions/core toolkit, core.setFailed(error.message) is the documented method for reporting an exception and marking the action as failed. setFailed() logs the supplied message and sets a failing exit code so GitHub records the action and associated check run as unsuccessful. Neither core.setException() nor core.action.setException() exists in the supported @actions/core API, and action.setError() is likewise not the documented error-handling method. The source PDF visibly contains the first three choices but crops the final distractor; the missing fourth choice was reconstructed from the matching public GH-200 question listing, while the correct answer itself was independently verified against GitHub ' s official documentation. GitHub ' s JavaScript-action example uses this exact catch pattern.

================

A composite action is identified by its action metadata file. In action.yml or action.yaml, the runs section must define using: " composite " . This tells GitHub Actions that the action is a composite action made from one or more reusable workflow steps. Option A is incorrect because Dockerfile and package.json files do not identify a composite action; they are usually associated with Docker or JavaScript-based projects. Option C is wrong because repository naming has no technical meaning in action classification. Option D is also wrong because an init.sh file is merely a script and does not define the action type. GitHub’s metadata syntax states that composite actions require runs.using to be set to composite.

For JavaScript custom actions, the metadata file supports lifecycle scripts through the runs section. The correct key for a script that runs before the main action entrypoint is pre, and the correct conditional key for controlling whether that pre-script runs is pre-if. Therefore, option B is the only valid metadata structure. GitHub Actions does not use start, start-if, before, or before-if as action metadata keys. Option C is also invalid because pre-if only defines a condition; it cannot contain both a condition and a script reference in one line. In GitHub Actions exam terms, this tests custom action metadata, JavaScript action lifecycle hooks, and conditional execution before the main action logic.

================

GitHub Actions on GitHub Enterprise Server often requires an internet connection, especially for accessing actions from the GitHub Marketplace or third-party actions unless they are manually synced to the server.

To use third-party actions on GitHub Enterprise Server, GitHub Connect can be used to establish a connection between the server and GitHub.com, enabling access to third-party actions.

Third-party actions can also be manually synchronized to the GitHub Enterprise Server, making them available for use in workflows.

The correct trigger must use the pull_request event because the workflow is based on activity on a pull request. The specific activity is a label being added, so types: [labeled] is required. The deployment must target the releases branch, so the branch filter must be branches: - ' releases ' . The workflow must also run only when files under the apps folder change, so paths: - ' apps/** ' is the correct recursive path filter. Option A is invalid because pull_request_label is not a GitHub Actions event. Option B uses the wrong event, pull_request_review. Option C uses an incorrect branch/path combination. GitHub workflow syntax supports event activity types, branch filters, and path filters together.

GitHub environments provide deployment protection controls such as required reviewers. First, the Production environment should be created in the repository ' s Settings > Environments configuration, where the VMOps team can be configured as required reviewers. This makes option C correct; the environment is not created as an organization-level environment as described by option B. Second, the deployment job must reference the Production environment. GitHub applies the environment ' s protection rules to jobs that reference that environment, so the deployment remains in a waiting state until an authorized reviewer approves it. GitHub environments are logical deployment-control resources; individual VMs do not need to be added to an environment, nor is an environment “owned” by a team. Therefore, options A and C together implement the required production approval gate.

================

The most common way to target a major release version of a GitHub Action is to reference a version tag such as @v3. This allows the workflow to use updates within that major version while avoiding automatic jumps to a newer major version that might introduce breaking changes. Option A references a commit SHA, which is the safest and most immutable method, but it is not the most common way to target a major release version. Option B is not a standard action version reference. Option D omits a version entirely, which is unsafe and not recommended because the action reference is incomplete. This topic maps to action versioning, marketplace action consumption, and reliable workflow maintenance.

================

Dockerfile: The Dockerfile is required for Docker container actions. It defines the environment for the action, specifying the base image, dependencies, and any commands to set up the action’s runtime inside the container.

action.yml: The action.yml file is required for all GitHub Actions, including Docker container actions. It contains metadata about the action, including the inputs, outputs, and the runtime environment (which in this case is Docker, defined under runs.using).

GitHub Actions supports organization-level secrets with repository access policies. When the same secret must be centrally managed but made available only to particular repositories, an organization owner can create an organization secret and configure its Repository access policy for selected repositories. This avoids creating and maintaining separate copies of the secret in every repository while still enforcing scope restrictions. Environment secrets are created for environments within individual repositories, so there is no organization-level environment secret matching option B. GitHub repositories also do not provide a general Share secret option like option D. External secret-management systems can be integrated with GitHub Actions, but they are unnecessary for this requirement. Therefore, an organization secret restricted to selected repositories is the direct GitHub-supported solution.

================

GitHub explicitly recommends keeping an action in its own repository when the action is intended for other people to use. One advantage is discoverability: a dedicated repository makes the action easier for other developers and the GitHub community to locate and understand. Another major advantage is independent versioning. The action can be tagged, released, maintained, and upgraded without coupling its release lifecycle to unrelated application code. GitHub additionally notes that a dedicated repository actually narrows , rather than widens, the code-base scope for developers maintaining the action, making option D incorrect. Separate repositories do not provide a mechanism for sharing secrets with users, and an action still requires action metadata such as action.yml or action.yaml. Therefore, easier discovery and independent versioning are the two correct benefits.

================

The GET /repos/:owner/:repo/actions/runs/:run_id/logs API endpoint is used to retrieve the logs of a specific workflow run identified by run_id. This is the correct method for downloading logs from a workflow run.

The repository_dispatch event allows you to trigger a workflow in response to external activity. It is commonly used when you need to trigger a workflow from outside GitHub, such as from another system or service, by sending a request to the GitHub API. This event provides flexibility to integrate with various external systems and trigger workflows in a GitHub repository.

The correct GitHub Actions context property for the short branch or tag name that triggered the workflow is github.ref_name. A job-level if: condition can use this context to control whether the job runs. Therefore, if: github.ref_name == ' feature-branch ' correctly limits the deploy job to the feature-branch branch. The other options use invalid context paths such as github.ref.name, github.branch_name, and github.branch.name; these are not recognized GitHub Actions properties. In exam terms, this question validates knowledge of workflow expressions, GitHub context variables, and conditional job execution. The important distinction is that github.ref contains the full ref path, while github.ref_name provides the branch or tag name directly.

================