2 packs: 15% off with code BUY2. 3 or more: 20% off with code BUY3.

Free GitHub GH-200 Actions Practice Questions

31 free GitHub GH-200 Actions practice questions from the CertStash pack of 124, each with the correct answer and a full explanation. The rule is the same for every exam: ten free on the product page, 31 free here, all 124 in the pack, and each step includes the one before it.

Get all 124 questions (US$39) · Download the first 10 as a PDF

Question 1

Scheduled workflows run on the:

  1. specified commit and branch from the workflow YAML file.
  2. latest commit from the branch named schedule.
  3. latest commit and branch on which the workflow was triggered.
  4. latest commit from the branch named main.
  5. latest commit on the default or base branch.
Show answer and explanation

Correct answer: E. latest commit on the default or base branch.

Scheduled workflows (triggered by the schedule event) execute on the latest commit of the default or base branch, typically main or master. This ensures consistency since the workflow schedule is defined in the repository's default branch and runs against the most current code on that branch.

Why the other options are wrong

  • A. Scheduled workflows don't run on arbitrary specified commits; they run on the latest commit of a specific branch.
  • B. There is no standard branch named 'schedule' that workflows default to.
  • C. Scheduled workflows don't run on the branch where they were triggered, they run on the default branch.
  • D. While main is often the default branch, the correct answer is more general: the default or base branch, which may vary.

Question 2

Custom environment variables can be defined at multiple levels within a workflow file including: (Each answer presents a complete solution. Choose three.)

  1. top level.
  2. step level.
  3. default level.
  4. runner level.
  5. job level.
  6. stage level.
Show answer and explanation

Correct answer: A, B, E. top level; step level; job level.

Custom environment variables in GitHub Actions workflows can be defined at three levels: top level (applies to all jobs and steps), job level (applies to all steps within a job), and step level (applies only to that specific step). There are no 'default', 'runner', or 'stage' levels in GitHub Actions workflow syntax.

Why the other options are wrong

  • C. There is no 'default level' in GitHub Actions workflow structure.
  • D. Runner-level is not a valid scope for defining environment variables in workflows.
  • F. GitHub Actions does not use 'stage' terminology; it uses 'job' instead.

Question 3

You are a DevOps engineer working on deployment workflows. You need to execute the deploy job only if the current branch name is feature-branch. Which code snippet will help you to implement the conditional execution of the job?

  1. jobs: deploy: if: github.ref_name == 'feature-branch' runs-on: ubuntu-latest steps: - uses: actions/checkout@v3
  2. jobs: deploy: if: github.branch.name == 'feature-branch' runs-on: ubuntu-latest steps: - uses: actions/checkout@v3
  3. jobs: deploy: if: github.ref.name == 'feature-branch' runs-on: ubuntu-latest steps: - uses: actions/checkout@v3
  4. jobs: deploy: if: github.branch_name == 'feature-branch' runs-on: ubuntu-latest steps: - uses: actions/checkout@v3
Show answer and explanation

Correct answer: A. jobs: deploy: if: github.ref_name == 'feature-branch' runs-on: ubuntu-latest steps: - uses: actions/checkout@v3

The correct syntax uses github.ref_name to access the current branch name. The ref_name context variable specifically contains the branch or tag name that triggered the workflow, and the condition github.ref_name == 'feature-branch' properly checks for the feature-branch.

Why the other options are wrong

  • B. github.branch.name does not exist in the GitHub Actions context.
  • C. github.ref.name is incorrect; the context variable is github.ref_name, not a nested object.
  • D. github.branch_name does not exist; the correct context variable is github.ref_name.

Question 4

What are the mandatory requirements for publishing GitHub Actions to the GitHub Marketplace? (Each correct answer presents part of the solution. Choose two.)

  1. The action can be either in a public or private repository.
  2. The action’s metadata file must be in the root directory of the repository.
  3. The action’s name cannot match a user or organization on GitHub unless the user or organization owner is publishing the action.
  4. The name should match with one of the existing GitHub Marketplace categories.
  5. Each repository can contain a collection of actions as long as they are under the same Marketplace category.
Show answer and explanation

Correct answer: B, C. The action’s metadata file must be in the root directory of the repository; The action’s name cannot match a user or organization on GitHub unless the user or organization owner is publishing the action.

Publishing to GitHub Marketplace requires that the action's metadata file (action.yml or action.yaml) be in the root directory of the repository, and the action's name must be unique and cannot match an existing GitHub user or organization unless that owner is publishing it. The action must be in a public repository, the name doesn't need to match marketplace categories, and each repository should contain one action.

Why the other options are wrong

  • A. Actions must be in a public repository to be published to the Marketplace, not private.
  • D. The action name does not need to match existing Marketplace category names.
  • E. Each repository should contain a single action; collections of actions under the same category are not the standard approach for Marketplace publishing.

Question 5

Which of the following is the proper syntax to specify a custom environment variable named MY_VARIABLE with the value my-value?

  1. var: MY_VARIABLE = my-value
  2. environment: MY_VARIABLE = my-value
  3. var: MY_VARIABLE: my-value
  4. env: MY_VARIABLE = my-value
  5. environment: MY_VARIABLE: my-value
  6. env: MY_VARIABLE: my-value
Show answer and explanation

Correct answer: F. env: MY_VARIABLE: my-value

GitHub Actions uses the 'env' keyword with a colon separator to define environment variables. The correct syntax is 'env: MY_VARIABLE: my-value' where env is the keyword, followed by a colon, then the variable name, another colon, and the value.

Why the other options are wrong

  • A. 'var' is not the correct keyword; GitHub Actions uses 'env'.
  • B. 'environment' is not valid in this context; the keyword is 'env'.
  • C. While this uses colon syntax, 'var' is the wrong keyword.
  • D. The syntax uses '=' instead of ':', which is incorrect for YAML.
  • E. 'environment' is not the correct keyword for this purpose.

Question 6

As a DevOps engineer, you need to define a deployment workflow that runs after the build workflow has successfully completed. Without modifying the build workflow, which trigger should you define in the deployment workflow?

  1. repository_dispatch
  2. workflow_dispatch
  3. workflow_exec
  4. workflow_run
Show answer and explanation

Correct answer: D. workflow_run

The workflow_run trigger allows a workflow to execute after another workflow completes, without requiring changes to the build workflow. This trigger monitors the completion of specified workflows and can filter on branches and completion status, making it perfect for running a deployment workflow after a build workflow succeeds.

Why the other options are wrong

  • A. repository_dispatch triggers workflows via manual API calls, not workflow completion.
  • B. workflow_dispatch allows manual triggering of a workflow, not automatic execution after another workflow.
  • C. workflow_exec is not a valid GitHub Actions trigger.

Question 7

Which step is using the dbserver environment variable correctly?

  1. steps: - name: Hello world run: echo $dbserver variables: dbserver: orgserver1
  2. steps: - name: Hello world run: echo $dbserver env: - name: dbserver value: orgserver1
  3. steps: - name: Hello world run: echo $dbserver environment: dbserver: orgserver1
  4. steps: - name: Hello world run: echo $dbserver env: dbserver: orgserver1
Show answer and explanation

Correct answer: D. steps: - name: Hello world run: echo $dbserver env: dbserver: orgserver1

The correct syntax for defining environment variables at the step level uses 'env:' followed by the variable name and value separated by a colon in YAML format. Option D shows 'env: dbserver: orgserver1', which properly defines the environment variable dbserver with the value orgserver1 at the step level.

Why the other options are wrong

  • A. 'variables:' is not the correct keyword; GitHub Actions uses 'env:'.
  • B. The syntax uses a list format with 'name' and 'value' keys, which is incorrect; step-level env variables use direct key-value pairs.
  • C. 'environment:' is not valid for step-level variable definitions; the keyword is 'env:'.

Question 8

In which scenarios could the GITHUB_TOKEN be used? (Each correct answer presents a complete solution. Choose two.)

  1. to create a repository secret
  2. to add a member to an organization
  3. to read from the file system on the runner
  4. to publish to GitHub Packages
  5. to create issues in the repo
  6. to leverage a self-hosted runner
Show answer and explanation

Correct answer: D, E. to publish to GitHub Packages; to create issues in the repo

The GITHUB_TOKEN can be used to publish packages to GitHub Packages and to create issues in the repository. These are authenticated API operations that the token permits by default. Repository secrets are created through repository settings, organization membership requires organization permissions beyond a standard token, file system access doesn't require the token, and self-hosted runner usage doesn't leverage the GITHUB_TOKEN for authentication.

Why the other options are wrong

  • A. Creating repository secrets requires repository settings access, not GITHUB_TOKEN authentication.
  • B. Adding organization members requires organization-level permissions and specific scopes that a standard GITHUB_TOKEN doesn't possess.
  • C. Reading from the file system is a local operation that doesn't use the GITHUB_TOKEN.
  • F. Leveraging a self-hosted runner is a configuration step that doesn't directly use the GITHUB_TOKEN for authentication.

Question 9

As a developer, which of the following snippets will enable you to run the commands npm ci and npm run build as part of a workflow?

  1. - run: | npm ci npm run build
  2. - shell: npm ci npm run build
  3. - run: | npm ci npm run build shell: nodejs
  4. - run: npm ci npm run build
  5. - shell: | npm ci npm run build
Show answer and explanation

Correct answer: A. - run: | npm ci npm run build

The pipe character (|) in YAML allows multiple commands to be executed sequentially on separate lines within a single run step. Option A correctly uses this syntax to run both npm ci and npm run build as part of the workflow. The pipe notation is the standard way to include multiple shell commands in a single run directive.

Why the other options are wrong

  • B. shell is not a valid directive; run is used instead.
  • C. This mixes run and shell directives incorrectly and has invalid syntax.
  • D. Without the pipe, the second command npm run build is treated as an argument to npm ci rather than a separate command.
  • E. The shell directive does not accept command content; only run does.

Question 10

What is the smallest scope for an environment variable?

  1. the workflow settings
  2. the workflow env mapping
  3. a job
  4. a step
Show answer and explanation

Correct answer: D. a step

Environment variables in GitHub Actions have hierarchical scoping from broadest to narrowest: workflow, job, and step. The smallest scope is the step level, where an environment variable defined within a step is only available to that specific step and does not affect other steps or jobs in the workflow.

Why the other options are wrong

  • A. Workflow settings defines a broader scope than step.
  • B. Workflow env mapping is broader in scope than individual steps.
  • C. Job-level scope is broader than step-level scope.

What people say about the full GH-200 pack 5.0 from 2

All the GH-200 exam questions are real, have tested, thanks, I passed my test smoothly.
Darron CordGH-200
The GH-200 exam wasn’t easy, but after working through practice tests and study resources, I was able to pass. The material covered everything I needed and more.
Lilith MercerGH-200

Question 11

What is the right method to ensure users approve a workflow before the next step proceeds?

  1. creating a branch protection rule and only allow certain users access
  2. granting users workflow approval permissions
  3. adding users as required reviewers for an environment
  4. granting users repository approval permission
Show answer and explanation

Correct answer: C. adding users as required reviewers for an environment

Adding users as required reviewers for an environment is the correct method to enforce approval gates in workflows. When users are designated as required reviewers for a specific environment, any deployment or workflow step targeting that environment must receive their explicit approval before proceeding. This is the native GitHub/workflow feature designed specifically for multi-step approval processes.

Why the other options are wrong

  • A. Branch protection rules control access to branches and code changes, not workflow step approvals.
  • B. Workflow approval permissions is not a standard permission model; approvals are enforced through environment reviewer assignments.
  • D. Repository approval permissions is not a defined permission type and does not provide step-level workflow approval control.

Question 12

For which type of GitHub Actions workflows should you use a self-hosted runner?

  1. workflows on a wide range of open-source software preinstalled in a GitHub-hosted environment
  2. workflows in environments that have specific hardware or operating system requirements that are unavailable on a GitHub-hosted runner
  3. workflows that require high availability and automatic scaling
  4. workflows that have standard configurations and frequent GitHub updates
Show answer and explanation

Correct answer: B. workflows in environments that have specific hardware or operating system requirements that are unavailable on a GitHub-hosted runner

Self-hosted runners are designed for workflows requiring specific hardware, operating systems, or software configurations not available on GitHub-hosted runners. They enable organizations to run workflows on custom infrastructure tailored to their needs.

Why the other options are wrong

  • A. GitHub-hosted runners already provide a wide range of preinstalled open-source software; self-hosted runners are unnecessary for this.
  • C. GitHub-hosted runners provide built-in high availability and automatic scaling; self-hosted runners require manual management.
  • D. Standard configurations with frequent GitHub updates are better served by GitHub-hosted runners, not self-hosted ones.

Question 13

How should you print a debug message in your workflow?

  1. echo "::debug::Set variable myVariable to true"
  2. echo "Set variable MyVariable to true" >> $DEBUG_MESSAGE
  3. echo "::add-mask::Set variable myVariable to true"
  4. echo "debug_message=Set variable myVariable to true" >> &GITHUB_OUTPUT
Show answer and explanation

Correct answer: A. echo "::debug::Set variable myVariable to true"

GitHub Actions uses the workflow command syntax `::debug::` to output debug messages to the logs. This is the standard mechanism for printing debug information that respects GitHub's logging levels. Option A correctly demonstrates this syntax with the proper format.

Why the other options are wrong

  • B. Redirecting to $DEBUG_MESSAGE is not a valid GitHub Actions mechanism for debug output.
  • C. The `::add-mask::` command is used to mask sensitive values in logs, not for debug messages.
  • D. Writing to GITHUB_OUTPUT is for setting outputs used by subsequent steps, not for debug logging.

Question 14

Which default GitHub environment variable indicates the owner and repository name?

  1. GITHUB_REPOSITORY
  2. GITHUB_WORKFLOW_REPO
  3. ENV_REPOSITORY
  4. REPOSITORY_NAME
Show answer and explanation

Correct answer: A. GITHUB_REPOSITORY

GITHUB_REPOSITORY is the default GitHub environment variable that contains the owner and repository name in the format owner/repo. This variable is automatically set by GitHub Actions for every workflow run and provides a standard way to reference the current repository.

Why the other options are wrong

  • B. GITHUB_WORKFLOW_REPO is not a standard GitHub Actions default variable.
  • C. ENV_REPOSITORY is not a GitHub Actions default variable.
  • D. REPOSITORY_NAME is not a standard default variable; the correct variable includes the owner.

Question 15

You are reaching your organization’s storage limit for GitHub artifacts and packages. What should you do to prevent the storage limit from being reached? (Each correct answer presents a complete solution. Choose two.)

  1. Use self-hosted runners for all workflow runs.
  2. Delete artifacts from the repositories manually.
  3. Configure the artifact and log retention period.
  4. Disable branch protections in the repository.
  5. Configure the repo to use Git Large File Storage.
Show answer and explanation

Correct answer: B, C. Delete artifacts from the repositories manually; Configure the artifact and log retention period.

Artifacts and logs count against the organisation's GitHub Actions and Packages storage quota until they expire. Deleting unneeded artifacts frees storage immediately, and shortening the artifact and log retention period makes GitHub remove them automatically sooner.

Why the other options are wrong

  • A. Self-hosted runners avoid paying for GitHub-hosted minutes, but artifacts they upload still use GitHub storage.
  • D. Branch protection rules have no effect on artifact or package storage.
  • E. Git Large File Storage has its own separate storage quota and does not reduce Actions artifact or package storage.

Question 16

What is the proper syntax to reference the system-provided run number variable?

  1. ${{var.GITHUB_RUN_NUMBER}}
  2. ${{env.GITHUB_RUN_NUMBER}}
  3. $GITHUB_RUN_NUMBER
  4. ${{GITHUB_RUN_NUMBER}}
  5. $github.run_number
Show answer and explanation

Correct answer: C. $GITHUB_RUN_NUMBER

GITHUB_RUN_NUMBER is a default environment variable that the runner sets for every job. Inside a shell run step it is referenced with normal shell syntax as $GITHUB_RUN_NUMBER. In expression syntax the same value comes from the github context as ${{ github.run_number }}.

Why the other options are wrong

  • A. There is no var context, and the vars context holds only user-defined configuration variables.
  • B. The env context contains only variables defined in the workflow, job or step, not the runner's default variables.
  • D. Expressions must reference a context, so a bare GITHUB_RUN_NUMBER inside ${{ }} is not valid.
  • E. $github.run_number mixes shell and context syntax and is not valid in either.

Question 17

Which default GitHub environment variable indicates the name of the person or app that initiated a workflow?

  1. GITHUB_ACTOR
  2. GITHUB USER
  3. ENV_ACTOR
  4. GITHUB_WORKFLOW_ACTOR
Show answer and explanation

Correct answer: A. GITHUB_ACTOR

The GITHUB_ACTOR variable is the default GitHub environment variable that contains the name of the person or application that triggered the workflow run. This variable is automatically available in all workflow steps and contains the login of the user who initiated the workflow or the app name if triggered by an automated process.

Why the other options are wrong

  • B. GITHUB_USER is not a standard GitHub Actions environment variable.
  • C. ENV_ACTOR is not a recognized GitHub Actions variable.
  • D. GITHUB_WORKFLOW_ACTOR is not a standard variable; the correct name is simply GITHUB_ACTOR.

Question 18

Which statement is true regarding the ability to delete a workflow run?

  1. Admin access is required to delete a workflow run.
  2. Pending workflow runs may be deleted.
  3. Completed workflow runs may be deleted.
  4. Workflow runs must be older than 30 days to be deleted.
Show answer and explanation

Correct answer: C. Completed workflow runs may be deleted.

Completed workflow runs may be deleted from GitHub Actions. Users with appropriate permissions can manually delete workflow runs that have finished executing, allowing them to manage storage and clean up completed runs. This action is available for runs in terminal states such as completed, failed, or cancelled.

Why the other options are wrong

  • A. Admin access is not strictly required; users with Write or higher permissions can delete workflow runs.
  • B. Pending or in-progress workflow runs cannot be deleted; only completed runs can be removed.
  • D. Workflow runs can be deleted immediately after completion; there is no 30-day waiting period requirement.

Question 19

For which type of GitHub Actions workflows should you use a self-hosted runner?

  1. workflows that require access to private internal network resources
  2. workflows that have no specific environment configurations and must be triggered on a GitHub-hosted infrastructure
  3. short-lived workflows that do NOT require custom dependencies
  4. workflows that require the latest operating system and preinstalled software versions
Show answer and explanation

Correct answer: A. workflows that require access to private internal network resources

Self-hosted runners are essential for workflows that require access to private internal network resources, including databases, internal APIs, and on-premises systems that GitHub-hosted runners cannot reach. This is the primary use case that justifies the overhead of maintaining self-hosted infrastructure.

Why the other options are wrong

  • B. Workflows with no specific configurations should use GitHub-hosted runners for simplicity and cost-effectiveness.
  • C. Short-lived workflows without custom dependencies are ideal candidates for GitHub-hosted runners, not self-hosted.
  • D. GitHub-hosted runners provide the latest operating systems and preinstalled software, making self-hosted runners unnecessary for this requirement.

Question 20

You are a DevOps engineer in ABC Corp. You need to schedule your deployment workflow twice a week at 7:45 UTC every Wednesday and Saturday. What is the appropriate YAML structure?

  1. on: cron: '45 7 * * 3,6'
  2. on: cron: - schedule: '45 7 * * 3,6'
  3. on: schedule: - cron: '45 7 * * 3,6'
  4. on: schedule: '45 7 * * 3,6'
Show answer and explanation

Correct answer: C. on: schedule: - cron: '45 7 * * 3,6'

The correct YAML structure for scheduling a workflow uses the schedule event with a cron array entry. Option C shows the proper format: on: schedule: with a cron entry as an array item. The cron expression '45 7 * * 3,6' correctly represents 7:45 UTC on Wednesday (3) and Saturday (6).

Why the other options are wrong

  • A. This omits the schedule keyword and uses incorrect YAML structure.
  • B. This incorrectly nests cron under schedule and then adds an additional schedule keyword.
  • D. This lacks the array notation required for the cron schedule entry.

Question 21

Which scopes are available to define custom environment variables within a workflow file? (Choose three.)

  1. the entire workflow, by using env at the top level of the workflow file
  2. all jobs being run on a single Actions runner, by using runner.env at the top of the workflow file
  3. the entire stage, by using env at the top of the defined build stage
  4. within the run attribute of a job step
  5. the contents of a job within a workflow, by using jobs.env
  6. a specific step within a job, by using jobs..steps[*].env
Show answer and explanation

Correct answer: A, E, F. the entire workflow, by using env at the top level of the workflow file; the contents of a job within a workflow, by using jobs.env; a specific step within a job, by using jobs..steps[*].env

Environment variables in GitHub Actions workflows can be defined at three levels: at the workflow level using top-level env (A), within a job using jobs.<job_id>.env (E), and within a specific step using jobs.<job_id>.steps[*].env (F). These three scopes allow granular control over variable availability throughout the workflow execution.

Why the other options are wrong

  • B. There is no runner.env syntax for defining environment variables in workflow files.
  • C. GitHub Actions workflows do not use stage-level env definitions; stages are not part of the workflow structure.
  • D. While the run attribute executes scripts, environment variables set within run only persist for that single step and cannot be accessed by subsequent steps without using GITHUB_ENV.

Question 22

While awaiting approval, how many days can a workflow be in the “Waiting” state before it automatically fails?

  1. 30 days
  2. 60 days
  3. 14 days
  4. 7 days
Show answer and explanation

Correct answer: A. 30 days

GitHub Actions workflows awaiting approval can remain in the 'Waiting' state for a maximum of 30 days before they automatically fail and are cancelled. This timeout prevents indefinite blocking of workflow runs and ensures they eventually progress or fail rather than remaining stuck in approval limbo.

Why the other options are wrong

  • B. 60 days exceeds the actual GitHub timeout limit for pending approvals.
  • C. 14 days is shorter than the actual 30-day timeout period.
  • D. 7 days is significantly shorter than the actual GitHub timeout window.

Question 23

Which native method should you use to pass files between jobs within the same GitHub Actions workflow?

  1. Use artifact storage.
  2. Use job outputs.
  3. Use the copy action with the cache parameter to cache the data.
  4. Use an external blob store
Show answer and explanation

Correct answer: A. Use artifact storage.

GitHub Actions provides artifact storage as the native mechanism for passing files between jobs within the same workflow. Jobs can upload artifacts using actions/upload-artifact, and subsequent jobs can download them using actions/download-artifact. This is the purpose-built, officially supported solution.

Why the other options are wrong

  • B. Job outputs are limited to string values and environment variables, not suitable for passing binary files or large datasets.
  • C. The cache action is designed for caching dependencies to improve performance, not for transferring files between jobs.
  • D. External blob stores are not native to GitHub Actions and add unnecessary complexity and cost.

Question 24

How can a workflow deploy mitigate the risk of multiple workflow runs that are deploying to a single cloud environment simultaneously? (Each correct answer presents part of the solution. Choose two.)

  1. Reference the mutex in the task performing the deployment.
  2. Set the concurrency in the deploymentjob to 1.
  3. Specify a target environment in the deploymentjob.
  4. Specify a concurrency scope in the workflow.
  5. Configure the mutex setting in the environment.
  6. Pass the mutex into the deployment job.
Show answer and explanation

Correct answer: C, D. Specify a target environment in the deploymentjob; Specify a concurrency scope in the workflow.

To prevent simultaneous deployments to a single cloud environment, specify a target environment in the deployment job (option C), which allows GitHub to enforce deployment restrictions and concurrency limits at the environment level. Additionally, specify a concurrency scope in the workflow (option D), which uses the concurrency keyword to serialize deployments to the same environment. These options work together to ensure only one deployment runs at a time against that environment.

Why the other options are wrong

  • A. Mutex is not a GitHub Actions concept; GitHub uses concurrency groups instead.
  • B. Setting job concurrency to 1 limits that specific job but doesn't prevent other workflow jobs from deploying simultaneously across runs.
  • E. Mutex is not a configurable setting in GitHub environments.
  • F. Mutex cannot be passed as a parameter; GitHub Actions uses concurrency groups for this purpose.

Question 25

Which statement accurately describes using labels to route GitHub Actions workflows to runners?

  1. A user can assign multiple labels to a self-hosted runner and use the labels in a runs-on to target only runners that match all the specified labels.
  2. Labels apply only to GitHub-hosted runners and are ignored by self-hosted runners.
  3. GitHub Actions automatically assigns the runner's IP address as a label, and the label must be used in a runs-on.
  4. To target a specific runner, the runs-on must match the runner's hostname rather than its labels.
Show answer and explanation

Correct answer: A. A user can assign multiple labels to a self-hosted runner and use the labels in a runs-on to target only runners that match all the specified labels.

Self-hosted runners support multiple labels that can be assigned to a single runner. In the runs-on field, you can specify multiple labels, and the workflow will execute only on runners that match all the specified labels. This allows fine-grained routing of workflows to appropriate runner infrastructure.

Why the other options are wrong

  • B. Labels apply to both GitHub-hosted and self-hosted runners; self-hosted runners do not ignore labels.
  • C. GitHub Actions does not automatically assign IP addresses as labels; labels are manually configured.
  • D. The runs-on field uses labels for targeting, not hostnames, allowing more flexible and scalable routing.

25 questions in. Want the rest? The first half of the pack, free by email · The full pack

Question 26

You are developing a GitHub Actions workflow that will build a .NET app. You need to provide the workflow with access to a sensitive enterprise license. The solution must ensure that the license is NOT exposed publicly or hardcoded. What should you do?

  1. Use a GitHub-hosted Windows runner and expose the license via a public URL downloaded by the workflow at runtime.
  2. Embed the license into an encrypted ZIP file stored in a repository and decrypt the file at runtime by using a hardcoded passphrase.
  3. Use GitHub Enterprise Managed User (OIDC) in a GitHub-hosted or self-hosted Windows runner to fetch the license from a third-party vault or secrets manager at runtime.
  4. Use a GitHub-hosted Ubuntu runner and store the license in a Base64-encoded repository.
Show answer and explanation

Correct answer: C. Use GitHub Enterprise Managed User (OIDC) in a GitHub-hosted or self-hosted Windows runner to fetch the license from a third-party vault or secrets manager at runtime.

Using OIDC (OpenID Connect) with GitHub Enterprise to authenticate to a third-party secrets manager or vault is the enterprise-grade solution that keeps sensitive credentials secure. The workflow uses OIDC tokens to authenticate and fetch the license at runtime without storing it in the repository or using hardcoded values, providing dynamic secret management with full audit trails.

Why the other options are wrong

  • A. Exposing any sensitive license via a public URL is a critical security vulnerability.
  • B. Storing encrypted files with hardcoded passphrases in the repository defeats the purpose of encryption and exposes the passphrase.
  • D. Base64 encoding is not encryption; storing any form of a sensitive license in a repository, encoded or not, is insecure.

Question 27

As a developer, you need to add the correct syntax to allow the following workflow file to be triggered by multiple types of events. Which two code blocks should you add starting at line 5? (Each correct answer presents a complete solution. Choose two.)

  1. on: [push, pull_request]
  2. on: branches: - 'main' - 'dev'
  3. on: schedule: - cron: '*/15 * * * *' initiate: - 'main'
  4. on: [push, commit]
  5. on: push: branches: - main release: types: - created
  6. on: env: - 'prod' - 'qa' - 'test'
Show answer and explanation

Correct answer: A, E. on: [push, pull_request]; on: push: branches: - main release: types: - created

GitHub Actions workflows are triggered using the 'on' keyword followed by event specifications. Option A uses the correct array syntax [push, pull_request] to trigger the workflow on multiple event types. Option E uses the correct mapping syntax with push and release as separate event keys, each with their own configuration (branches for push, types for release), allowing multiple trigger events with specific conditions. Both are valid syntaxes for defining multiple trigger events in a workflow file.

Why the other options are wrong

  • B. The syntax is malformed; 'branches' is not a valid event type and the structure does not follow GitHub Actions event specification format.
  • C. The syntax combines schedule (a valid event) with 'initiate' (not a valid GitHub Actions event), and 'cron' should be nested under schedule, not at the same level.
  • D. The event 'commit' is not a valid GitHub Actions trigger event; only 'push' and 'pull_request' are among the basic commit-related events.
  • F. The 'env' keyword is not a valid trigger event in GitHub Actions; environment variables cannot be used as event triggers in the 'on' section.

Question 28

What are the two ways to pass data between jobs? (Each correct answer presents part of the solution. Choose two.)

  1. Use data storage.
  2. Use the copy action with cache parameter to cache the data.
  3. Use the copy action with restore parameter to restore the data from the cache.
  4. Use artifact storage.
  5. Use job outputs.
  6. Use the copy action to save the data that should be passed in the artifacts folder.
Show answer and explanation

Correct answer: D, E. Use artifact storage; Use job outputs.

The two primary ways to pass data between jobs in GitHub Actions workflows are using artifact storage (option D) to upload and download files produced by jobs, and using job outputs (option E) to pass scalar values and structured data through the outputs context.

Why the other options are wrong

  • A. While general data storage exists, it is not a GitHub Actions-specific mechanism for passing data between jobs.
  • B. There is no copy action with a cache parameter; caching is configured using the cache action, not for passing data between jobs.
  • C. The cache action has no restore parameter; it uses a get action for retrieval and is designed for dependency caching, not job-to-job data transfer.
  • F. The copy action does not exist in GitHub Actions workflows; artifacts are managed with the upload-artifact and download-artifact actions.

Question 29

Which workflow event is used to manually trigger a workflow run?

  1. status
  2. workflow_dispatch
  3. workflow_run
  4. create
Show answer and explanation

Correct answer: B. workflow_dispatch

The workflow_dispatch event enables manual triggering of a workflow run through the GitHub user interface or the GitHub API. This allows developers to start a workflow run without waiting for an automatic trigger based on repository events.

Why the other options are wrong

  • A. status is triggered by external status checks, not manual dispatch.
  • C. workflow_run is triggered when another workflow completes, not by manual action.
  • D. create is triggered when a branch or tag is created, not by manual dispatch.

Question 30

Which two actions ensure that a GitHub Actions workflow can be triggered manually? Each correct answer presents a complete solution. NOTE: Each correct selection is worth one point.

  1. Define a workflow_dispatch event and specify inputs that enable users to provide values when triggering the workflow manually.
  2. Use a schedule event and add a manual: false parameter.
  3. Define a workflow_dispatch event in the on field of the workflow YAML file.
  4. Trigger a workflow manually by using a workflow_call event that has a button on the UI.
Show answer and explanation

Correct answer: A, C. Define a workflow_dispatch event and specify inputs that enable users to provide values when triggering the workflow manually; Define a workflow_dispatch event in the on field of the workflow YAML file.

Both options A and C describe the same solution for enabling manual workflow triggers: defining a workflow_dispatch event in the on field of the workflow YAML file. Option A additionally specifies that inputs can be defined to allow users to provide values when manually triggering the workflow, which enhances the capability but both achieve the core requirement of manual triggering.

Why the other options are wrong

  • B. The schedule event is for time-based triggers, not manual triggers, and it has no manual: false parameter that enables manual execution.
  • D. The workflow_call event is for reusable workflows called by other workflows, not for manual UI-triggered execution.

Question 31

Which default environment variable specifies the branch or tag that triggered a workflow?

  1. GITHUB_REF
  2. GITHUB_BRANCH
  3. ENV_BRANCH
  4. GITHUB_TAG
Show answer and explanation

Correct answer: A. GITHUB_REF

GITHUB_REF is the default environment variable that specifies the fully qualified ref (branch or tag) that triggered the workflow run. It contains the complete reference path, such as refs/heads/main or refs/tags/v1.0.

Why the other options are wrong

  • B. GITHUB_BRANCH is not a standard GitHub Actions environment variable.
  • C. ENV_BRANCH is not a standard GitHub Actions environment variable.
  • D. GITHUB_TAG is not a standard variable; GITHUB_REF is used for both tags and branches.

That was 31 of 124.

The full GitHub GH-200 Actions pack has all 124 questions, each with the answer, the explanation and why the other options are wrong, plus a questions-only copy for timed runs. US$39, paid once, with free monthly updates and a pass-or-your-money-back guarantee.

Get the full pack

Not ready yet? Get the first 62 free as one PDF by email. Get the Half Pack →