Free Practice Questions for Microsoft GH-200 Exam

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.

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

GitHub Actions allows you to configure environment protection rules, where you can require specific users or teams to approve the deployment before the workflow proceeds to the next step. This ensures that the required reviewers approve the workflow before any sensitive actions (such as deployment) occur.

The correct syntax includes specifying the job ( example-job ), the runner ( ubuntu-latest ), and the necessary step ( npm install -g bats ) within the workflow. This ensures that the package is installed properly during the execution of the job.

The correct syntax for referencing a versioned action is owner/repository@ref. Therefore, to use version v1 of actions/javascript-action, the workflow step must use actions/javascript-action@v1. The @v1 portion is the ref, which can represent a tag, branch, or commit SHA depending on how the action publisher releases the action. Option A incorrectly treats the version as part of the repository path. Option B invents a separate version: key, which is not how action versions are selected. Option C changes the repository name and does not specify a ref. In GitHub Actions syntax, uses selects an action, and version selection is part of the action reference itself. GitHub examples use the uses: owner/action-name@ref form.

A composite action allows you to bundle multiple steps into a single reusable action within a workflow. It is composed of multiple run steps or other actions and can be reused across workflows, making it the perfect choice for bundling a series of steps.

When troubleshooting a self-hosted runner, you can access the _diag folder located in the self-hosted runner ' s installation directory. This folder contains diagnostic logs that can help you identify the root cause of issues, such as connection problems.

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.

GitHub secrets are defined at different levels: organization, repository, and sometimes at the workflow level. If a secret is defined at both the organization level and the repository level, the repository-level secret will take precedence. So, if the value of the secret differs between these levels, the workflow will use the value from the repository level instead of the organization level.

Actions stored in private repositories within the organization can be reused across all repositories by referencing them in workflows. This ensures a centralized way of maintaining custom actions.

Encrypted secrets can be accessed across repositories in the same organization, making it easy to store sensitive data (like API keys or tokens) securely while allowing multiple workflows to access them.

Workflow templates allow you to create reusable templates for workflows that can be shared across repositories within the organization. This makes it easier to standardize processes and automate them across multiple projects.

Actions can be stored in a separate public repository and referenced in workflows by specifying the repository and action name.

Actions can also be stored in the same repository as the workflow and referenced directly by their path (e.g., ./.github/actions/my-action).

Actions can be packaged as Docker container images and published to Docker Hub. These can then be referenced in workflows by specifying the Docker image.