GH-200 GitHub Actions braindump and exam questions

Better than a GitHub Actions exam dump

This is not a braindump.

All of these questions were taken from my  GitHub Actions Udemy course and the certificationexams.pro certification website that has hundreds of free GitHub Actions questions.

All of these GH-200 exam questions are designed to target the GitHub Actions exam topics in a very precise and focused way, and while they may be similar to what you see on the exam, they are not copies and they are not braindumps. Passing the GitHub certification exams with integrity is important.

If you can answer these questions, and you understand why the wrong answers are incorrect, you’ll not only pass the GitHub Actions certification exam, but you’ll also learn a thing or two about DevOps, software development and most importantly, GitHub Actions.

But here you go, here’s your Github Actions braindump, if you want to call it that.

The questions are tough, but each question is answered in full detail below, along with tips and strategies on how to answer similar questions on the actual GitHub Actions certification exam.

Have fun, and best of luck on the exam!

GH-200 GitHub Actions Exam Questions

In GitHub Actions, how is the success or failure of a step determined by its exit code?

• A. Exit codes are ignored and a maintainer sets the result manually
• B. Zero exit code means success and any nonzero means failure
• C. Success is controlled by continue-on-error rather than the exit code
• D. Every exit code is a failure

Which configuration lines correctly set the workflow name in a GitHub Actions workflow file? (Choose 2)

• A. name: ${{ “release-flow-42” }}
• B. name: ${{ ‘release-flow-42’ }}
• C. run-name: release-flow-42
• D. name: release-flow-42

In GitHub Enterprise Cloud, where do you set the policy that allows only enterprise hosted actions and reusable workflows to run?

• A. Organization settings Policies then Actions
• B. Enterprise account Actions policy
• C. Repository settings Actions general

In GitHub Actions, where should you declare custom environment variables so they are accessible across all jobs and steps in a single workflow run?

• A. Repository variables
• B. Set env in the workflow YAML
• C. Environment secrets
• D. Runner command line arguments

Which GitHub Actions event configuration triggers only for pull requests targeting the release branch and not for push events?

• A. on: pull_request_target: branches: – release
• B. on: pull_request: branches: – release
• C. on: push: branches: – release
• D. on: pull_request: types: – opened

In GitHub Actions, which workflow key defines the events that trigger the workflow such as push or pull_request?

• A. if:
• B. on:
• C. env:
• D. jobs:

What repository visibility is required for a GitHub Action to be listed on GitHub Marketplace?

• A. Verified creator status
• B. Metadata in a subfolder
• C. Public repository
• D. Use GitHub Container Registry

Which GitHub Actions capability prevents secrets from appearing in workflow logs?

• A. Manual approval for secret log output
• B. GitHub Audit Log
• C. Default secret masking in logs
• D. Encrypted secrets written to logs

In a workflow triggered by a pull request comment, which GitHub Actions context property contains the event payload used to access the comment text and the pull request number?

• A. github.repository
• B. github.event
• C. github.event_path
• D. github.job

Which repository files are required for a Docker container action and for a JavaScript action to run correctly? (Choose 3)

• A. JavaScript entry file such as main.js or index.js
• B. package.json
• C. Action metadata file action.yml or action.yaml
• D. Container action Dockerfile

GitHub Actions Braindump Questions Answered (below)

The full set of exam questions can be found on GitHub Actions Udemy course or certificationexams.pro

In GitHub Actions, how is the success or failure of a step determined by its exit code?

• [*] B. Zero exit code means success and any nonzero means failure

The correct option is Zero exit code means success and any nonzero means failure.

GitHub Actions evaluates each step by the exit status of the process it runs. The runner marks a step successful when the command finishes with an exit status of 0. If the command returns any other code then the step is marked as failed and the job may stop depending on your workflow configuration.

Exit codes are ignored and a maintainer sets the result manually is incorrect because the runner automatically determines success or failure from the process exit status and does not require manual intervention for step outcomes.

Success is controlled by continue-on-error rather than the exit code is incorrect because continue-on-error only influences whether a failing step stops the job. The step is still classified as failed or successful based on its exit status.

Every exit code is a failure is incorrect because an exit status of 0 indicates success by design.

When you see options about step outcomes, anchor your reasoning to the standard convention that 0 means success and any nonzero value means failure. Distinguish this from features like continue-on-error that affect whether the workflow proceeds rather than how success or failure is determined.

Which configuration lines correctly set the workflow name in a GitHub Actions workflow file? (Choose 2)

• [*] B. name: ${{ ‘release-flow-42’ }}
• [*] D. name: release-flow-42

The correct options are name: release-flow-42 and name: ${{ ‘release-flow-42’ }}. Both set the workflow name that appears in the Actions interface and on the workflow page.

The plain static name key with a simple string sets the workflow name clearly and predictably. It is the most straightforward way to define the workflow title.

The expression form with a single quoted string evaluates to the same literal value. GitHub Actions accepts a string result for the workflow name, so this produces a valid name while keeping consistency with other places where expressions are used.

name: ${{ “release-flow-42” }} is not valid as written in this context because the inner double quotes can cause parsing issues and do not produce a clean string literal for the workflow name in this exam scenario.

run-name: release-flow-42 does not set the workflow name. It only sets the display name for each workflow run, so it does not answer the question that asks for the workflow name.

Confirm whether the question targets the workflow name or the run name. The top level name sets the workflow title while run-name only changes the title of each run.

In GitHub Enterprise Cloud, where do you set the policy that allows only enterprise hosted actions and reusable workflows to run?

• [*] B. Enterprise account Actions policy

The correct option is Enterprise account Actions policy.

The enterprise Actions policy is the centralized place where enterprise owners enforce which actions and reusable workflows are permitted across all organizations in GitHub Enterprise Cloud. From this scope you can require that only actions and reusable workflows hosted within the enterprise are allowed to run, and this policy flows down to organizations and repositories to ensure consistent enforcement.

Organization settings Policies then Actions is not correct because organization level policies apply only within a single organization and cannot guarantee enterprise wide enforcement. The requirement to limit runs to enterprise hosted actions and reusable workflows must be set at the enterprise scope.

Repository settings Actions general is not correct because repository settings control repository specific behavior such as enabling Actions or setting permissions. They do not provide an enterprise wide control for allowing only enterprise hosted actions and reusable workflows.

Look for the scope hinted by the question. If it says enterprise wide or applies to all organizations then choose enterprise account settings. If it mentions a single organization or repository then select the corresponding scope.

In GitHub Actions, where should you declare custom environment variables so they are accessible across all jobs and steps in a single workflow run?

• [*] B. Set env in the workflow YAML

The correct option is Set env in the workflow YAML because defining environment variables at the top level of a workflow makes them available to every job and step in that single run.

In a workflow file you can declare a top level mapping for environment variables with key value pairs. This top level scope propagates the values to all jobs and steps in the run and you can override them at job or step scope when necessary. This is the most direct way to share non secret configuration across the entire workflow execution.

Repository variables are not defined in the workflow and are scoped to the repository rather than a single run. These values live in settings and must be referenced through the vars context which means they are not automatically available as environment variables in every job and step.

Environment secrets are intended for sensitive data and are tied to a deployment environment. Secrets do not become plain environment variables unless you explicitly map them and they are not meant for general non sensitive configuration.

Runner command line arguments do not provide a way to set per run environment variables for GitHub Actions. The runner does not accept a command line flag that injects variables across jobs and steps in a workflow.

When a question stresses availability across jobs and steps within one run, think of the workflow level env. If the scenario involves sensitive values choose secrets. If it asks for reuse across many workflows look for repository variables.

Which GitHub Actions event configuration triggers only for pull requests targeting the release branch and not for push events?

• [*] B. on: pull_request: branches: – release

The correct option is on: pull_request: branches: – release. This configuration runs only when a pull request targets the release branch and it does not run on push events.

The pull_request event triggers on pull request activity and the branches filter matches the base branch of the pull request. By specifying the release branch, this configuration limits runs to pull requests that target that branch. Because it listens only for the pull_request event, pushes will not trigger the workflow.

on: pull_request_target: branches: – release listens for pull request activity but it runs in the context of the target repository with different permissions and is intended for special cases. The question asks for the standard pull request trigger, so this is not the best match.

on: push: branches: – release is incorrect because it triggers on pushes to the release branch and the question requires that it not run on push events.

on: pull_request: types: – opened is incorrect because it does not filter by the base branch. It would run for any pull request that is opened regardless of the target branch and it would miss other common pull request activities such as synchronize or reopened.

When a scenario calls for branch specific pull request triggers, prefer the pull_request event with a branches filter and verify that no push trigger is present.

In GitHub Actions, which workflow key defines the events that trigger the workflow such as push or pull_request?

• [*] B. on:

The correct option is on: which specifies the events such as push and pull_request that trigger a GitHub Actions workflow to run.

In a workflow file this key accepts one or many events and can include filters like branches and paths for push and pull_request so it defines exactly when the workflow starts.

The option if: controls conditional execution of jobs or steps and it does not configure which events start a workflow.

The option env: sets environment variables at the workflow job or step level and it does not declare triggers.

The option jobs: defines the jobs and their steps within a workflow and not the events that trigger it.

When a question asks about triggers look for the key that maps to events at the top of the workflow file and rule out keys that handle conditions or variables or define jobs.

What repository visibility is required for a GitHub Action to be listed on GitHub Marketplace?

• [*] C. Public repository

The correct option is Public repository.

GitHub only lists actions from repositories that are visible to everyone. This is a firm requirement for publishing an action to the Marketplace and private or internal repositories cannot be listed.

Verified creator status is not required to list an action. Verification only grants a trust badge for an organization and you can publish without it.

Metadata in a subfolder is incorrect because GitHub requires the action metadata file to be in the root of the repository. Placing the metadata file in a subfolder does not meet this requirement.

Use GitHub Container Registry is not required for Marketplace listing. Container actions can use other registries or be built from a Dockerfile and Marketplace does not mandate GHCR.

When you see Marketplace listing questions, identify the must have repository setting. The repository must be public while badges and specific packaging choices are often optional.

Which GitHub Actions capability prevents secrets from appearing in workflow logs?

• [*] C. Default secret masking in logs

The correct option is Default secret masking in logs.

GitHub Actions automatically redacts secret values from workflow logs so if a command prints a secret the value is masked in the output. This built in protection helps prevent accidental exposure of credentials during job execution and it applies without additional configuration.

Manual approval for secret log output is not a GitHub Actions feature for hiding secrets in logs. Manual approvals are used for protected environments and deployments rather than controlling log redaction.

GitHub Audit Log records administrative and security relevant events. It does not mask or govern what appears in workflow logs.

Encrypted secrets written to logs is not a safety feature. You should avoid writing secrets to logs in any form and GitHub relies on automatic masking of secret values rather than encouraging encrypted output in logs.

Scan options for default or automatic protections when the question asks how something is prevented. For GitHub Actions logs the keyword to spot is masking rather than auditing or approvals.

In a workflow triggered by a pull request comment, which GitHub Actions context property contains the event payload used to access the comment text and the pull request number?

• [*] B. github.event

The correct option is github.event.

In a workflow that runs on a pull request comment the event context contains the webhook payload. With github.event you can read the structured fields for the comment text and the pull request number. The comment text is available under the comment body field and the pull request number is available under the issue number for comment events or under the pull request number for pull request events. This makes github.event the direct and convenient source for these values.

The option github.repository only provides the owner and repository name. It does not expose the event payload so it cannot give you the comment text or the pull request number.

The option github.event_path points to a temporary file on the runner that contains the JSON payload. It does not provide the data directly in the context and using github.event is the recommended way to access the payload fields in expressions and steps.

The option github.job identifies the current job in the workflow run. It does not include any event payload so it cannot be used to read the comment or the pull request number.

When a question asks where to read details from a GitHub Actions trigger look for the context that holds the webhook payload and verify the exact field names you need such as comment body and issue number.

Which repository files are required for a Docker container action and for a JavaScript action to run correctly? (Choose 3)

• [*] A. JavaScript entry file such as main.js or index.js
• [*] C. Action metadata file action.yml or action.yaml
• [*] D. Container action Dockerfile

The correct options are JavaScript entry file such as main.js or index.js, Action metadata file action.yml or action.yaml, and Container action Dockerfile.

The Action metadata file action.yml or action.yaml is mandatory because it declares inputs and outputs and it instructs GitHub how to run the action. Both JavaScript and container actions rely on this metadata to execute correctly.

For a JavaScript action the JavaScript entry file such as main.js or index.js is the script that the runner executes as directed by the metadata. GitHub expects a committed distributable script, so the entry file must be present in the repository.

For a container action the Container action Dockerfile defines how to build the image and what command to run, which makes the Dockerfile required for the action to work.

The option package.json is not required for a working action. It can be useful during development and for dependency management, yet a JavaScript action can run from the bundled output without package.json and a container action does not need package.json at runtime.

Map file requirements to the action type. Remember that the metadata file is always required and that the entry file or Dockerfile is needed based on whether it is a JavaScript or container action. Treat package.json as helpful for development rather than required at runtime.

Cameron McKenzie is an AWS Certified AI Practitioner, Machine Learning Engineer, Solutions Architect and author of many popular books in the software development and Cloud Computing space. His growing YouTube channel training devs in Java, Spring, AI and ML has well over 30,000 subscribers.