Free Microsoft GH-200 Practice Test Questions MCQs

Explanation
In GitHub Actions, to set an output parameter for a step that subsequent steps can access, you must write a specifically formatted string to the special $GITHUB_OUTPUT environment file. This file acts as a temporary storage location for the current job. Using the correct syntax echo "{name}={value}" >> $GITHUB_OUTPUT ensures that the key-value pair is properly captured and made available to other steps via the steps context.

Correct Option

A. run: echo "MY_OUTPUT=foo" >> $GITHUB_OUTPUT
This is the current and recommended method for setting step outputs.

The syntax writes the key-value pair MY_OUTPUT=foo to the file path referenced by the environment variable $GITHUB_OUTPUT.

After the step completes, GitHub reads this file, and subsequent steps can reference this output using the syntax ${{ steps..outputs.MY_OUTPUT }}.

Incorrect Options

B. run: export MY_OUTPUT=foo
The export command sets an environment variable for the current shell session within that specific step.

While this variable can be used by other commands within the same step, it is not persisted or made available to other steps in the job. Step outputs are distinct from environment variables.

C. run: echo ${{ $GITHUB_OUTPUT=foo }}
This syntax is invalid in GitHub Actions.

${{ ... }} is the expression syntax used for evaluating and interpolating variables and contexts, not for assigning values to system files. Attempting to assign a value inside the expression like this will cause a workflow error.

D. run: echo "::set-env name=MY OUTPUT::foo"
This command uses the deprecated set-env workflow command, which was previously used to set environment variables.

This command is no longer functional and is disabled due to security concerns. It has been fully replaced by the $GITHUB_ENV (for environment variables) and $GITHUB_OUTPUT (for step outputs) files.

Reference
GitHub Docs: Workflow commands for GitHub Actions - Setting an output parameter

Explanation
GitHub Actions provides several default environment variables that contain contextual information about the workflow run. Among these, GITHUB_REF is the variable that stores the full Git ref (reference) of the branch or tag that triggered the workflow. This variable helps workflows understand which specific code version they are operating on.

Correct Option

B. GITHUB_REF
This default environment variable contains the full Git ref path that triggered the workflow, such as refs/heads/main for a branch or refs/tags/v1.0.0 for a tag.

Workflows commonly use this variable to determine the current branch name by extracting the portion after refs/heads/.

It is automatically set by GitHub Actions for every workflow run and does not require any manual configuration.

Incorrect Options

A. GITHUB_TAG
This is not a default environment variable in GitHub Actions.

While tags are part of the Git ref system, there is no separate GITHUB_TAG variable. Tag information is contained within GITHUB_REF when a tag triggers the workflow (e.g., refs/tags/v1.0.0).

C. ENV_BRANCH
This is not a standard default environment variable provided by GitHub Actions.

It resembles a custom environment variable that a user might define manually in their workflow, but it is not automatically set or recognized by GitHub Actions.

D. GITHUB_BRANCH
This is not a default environment variable in GitHub Actions.

Although many users expect a dedicated branch variable, GitHub Actions uses GITHUB_REF to provide branch information. To get just the branch name, you typically extract it from GITHUB_REF using Bash parameter expansion or GitHub Actions expressions.

Reference
GitHub Docs: Default environment variables

Explanation
When managing custom GitHub Actions in an enterprise, maintainability and version control are critical. Creating a separate repository for each action is a best practice because it allows each action to have its own versioning, release tags, documentation, and issue tracking. This isolation prevents changes to one action from inadvertently affecting others and follows the principle of single responsibility.

Correct Option

A. creating a separate repository for each action so that the version can be managed independently
This approach enables semantic versioning for each action individually using Git tags and releases.

Teams can update actions at their own pace without forcing updates on consumers of other actions.

Each repository can have its own README, issue templates, and contribution guidelines specific to that action.

Consumers can pin to specific versions (e.g., v1.2.3 or v1) without worrying about breaking changes from unrelated actions.

Incorrect Options

B. creating a separate branch in application repositories that only contains the actions
Storing actions in branches of application repositories creates tight coupling between application code and automation logic.

Other repositories cannot easily reference actions stored in another repository's specific branch.

Branch-based versioning is less reliable than tag-based releases and makes dependency management confusing.

This approach violates the principle of separating concerns and reusability.

C. creating a single repository for all custom actions so that the versions for each action are all the same
A monorepo for all actions forces all actions to share the same versioning scheme and release cycle.

Updating one action would require releasing new versions for all actions, even unchanged ones.

Consumers cannot independently update individual actions without potentially pulling in changes from others.

This creates unnecessary dependencies between unrelated automation components.

D. including custom actions that other teams need to reference in the same repository as application code
Embedding shared actions within application repositories prevents reuse across different projects and teams.

Other repositories would need to check out the entire application repository just to access one action.

This creates tight coupling and makes maintenance difficult when multiple applications depend on the same action.

It violates DRY (Don't Repeat Yourself) principles and increases the risk of inconsistencies across the enterprise.

Reference
GitHub Docs: Creating actions - Best practices for actions

Explanation
GitHub Actions workflows can reference custom actions from several locations depending on how the action was built and distributed. The three primary locations are public repositories, the same repository containing the workflow, and Docker container images published on registries like Docker Hub. Understanding these sources is essential for properly structuring reusable automation across projects.

Correct Options

A. a separate public repository
Actions can be referenced from any public repository on GitHub using the syntax {owner}/{repo}@{ref} or {owner}/{repo}/{path}@{ref}.

This allows teams to share reusable actions across the organization or with the broader GitHub community.

Popular actions from the GitHub Marketplace are typically stored in public repositories.

C. the same repository as the workflow
Actions can be stored locally within the same repository that contains the workflow, typically in the .github/actions directory.

This is useful for workflow-specific custom logic that doesn't need to be shared with other projects.

Local actions are referenced using a relative path, such as ./.github/actions/my-action.

D. a published Docker container image on Docker Hub
Docker container actions can be referenced directly from Docker registries including Docker Hub, GitHub Container Registry, or other container registries.

The action uses the image keyword in its action.yml metadata to point to the container image.

Workflows reference these actions using the docker://{image}:{tag} syntax.

Incorrect Options

B. an .action extension file in the repository
There is no special .action file extension recognized by GitHub Actions for referencing actions.

Action metadata is stored in action.yml or action.yaml files, but workflows do not reference these files directly as a location source.

E. the runs-on: keyword of a workflow file
The runs-on keyword specifies the type of runner (e.g., ubuntu-latest, windows-latest) for executing a job, not a location for referencing actions.

This keyword determines the execution environment, not where action code is stored.

F. the repository's Secrets settings page
Secrets store sensitive information like API tokens and passwords, not action code or references.

While secrets are used within actions, they are not a location where actions themselves can be referenced.

G. a public NPM registry
NPM registries store JavaScript packages, not GitHub Actions directly.

While JavaScript actions may use NPM packages as dependencies, the action itself cannot be referenced directly from an NPM registry in a workflow.

Reference
GitHub Docs: About custom actions - Location of actions

Explanation
GitHub Actions provides built-in support for service containers that allow you to spin up temporary databases and other services directly on the runner without requiring external infrastructure. Using a service container with a PostgreSQL image from Docker Hub is the simplest approach because it requires no additional setup, runs entirely within the GitHub-hosted runner, and automatically shuts down when the job completes.

Correct Option

A. Use service containers with a Postgres database from Docker hub.
Service containers are Docker containers that run alongside your job and provide clean, isolated services for testing.

They can be defined directly in the workflow YAML using the services keyword with the official PostgreSQL image.

The database is automatically available on localhost with the specified port and credentials.

No external infrastructure, maintenance, or manual cleanup is needed as containers are destroyed after the job.

Incorrect Options

B. Run the actions/postgres action in a parallel job.
There is no official actions/postgres action provided by GitHub for running PostgreSQL databases.

Even if a community action existed, running a database in a parallel job would require complex networking to connect between jobs.

Parallel jobs run on separate runners and cannot communicate with each other directly without additional configuration.

C. It is currently impossible to access the database with GitHub Actions.
This is incorrect as GitHub Actions fully supports database access through service containers.

Many CI/CD pipelines successfully run integration tests against PostgreSQL, MySQL, and other databases using this feature.

Service containers have been a core part of GitHub Actions since its early releases.

D. Dynamically provision and deprovision an environment.
This approach would require external infrastructure like cloud database services (AWS RDS, Azure Database, etc.) and additional credentials management.

It introduces complexity, potential costs, and slower setup times compared to service containers.

While possible for certain scenarios, it is not the simplest or most maintainable method for basic testing needs.

Reference
GitHub Docs: About service containers

Explanation
Every GitHub Action must contain a metadata file named action.yml or action.yaml that defines the action's interface. This file specifies required and optional inputs, outputs that can be passed to subsequent steps, the action's name and description, and how the action executes (JavaScript, Docker, or composite). Reviewing this file is essential for understanding how to properly implement and consume an action.

Correct Option

E. action.yml
This is the mandatory metadata file for all custom actions in GitHub Actions.

It defines the action's inputs using the inputs: section, specifying each input's description, required status, and default value.

The outputs: section lists any values the action produces that can be used by later steps.

It also contains the runs: configuration that determines whether the action uses JavaScript, Docker, or composite run steps.

Incorrect Options

A. Inputs.yml
There is no standard file named inputs.yml in GitHub Actions.

While the concept of inputs exists in the action.yml file, this specific filename is not recognized by GitHub Actions.

Creating this file would have no effect on how the action functions.

B. config.json
JSON configuration files are not used for defining action metadata in GitHub Actions.

Some actions may include a config.json for their own internal configuration needs, but it is not the standard metadata file.

GitHub Actions specifically looks for action.yml or action.yaml in the action's repository.

C. defaults.json
This is not a recognized metadata file for GitHub Actions.

There is no JSON-based equivalent to the action.yml file in the GitHub Actions ecosystem.

Default values for inputs, when needed, are defined within the action.yml file itself.

D. workflow.yml
Workflow files (typically .github/workflows/*.yml) define the automation pipeline that consumes actions, not the actions themselves.

These files reference actions but do not define an action's available inputs and outputs.

A workflow file might use an action's inputs, but the definition of those inputs originates in the action's action.yml.

Reference
GitHub Docs: Metadata syntax for GitHub Actions

Explanation
GitHub Actions automatically provides several default environment variables that contain information about the runner and workflow environment. GITHUB_WORKSPACE is one such variable that points to the default working directory on the runner where your repository is checked out and where steps execute. This variable is essential for accessing files, running scripts, and managing paths within your workflow.

Correct Option

D. The GITHUB_WORKSPACE environment variable should be used to access files from within the runner.
GITHUB_WORKSPACE contains the absolute path to the directory where your repository files are located on the runner.

This variable ensures that file operations work correctly regardless of the underlying runner operating system or configuration.

Steps that need to read, write, or execute files from the checked-out repository should reference $GITHUB_WORKSPACE to maintain portability.

It is automatically set by GitHub Actions for every workflow run and requires no manual configuration.

Incorrect Options

A. The environment variables can be read in workflows using the ENV: variable_name syntax.
This syntax is incorrect for accessing environment variables in GitHub Actions.

Environment variables are accessed using standard shell syntax like $VARIABLE_NAME or ${VARIABLE_NAME}.

The env: context in workflows is used for setting variables, not for reading them with a special ENV: prefix.

B. The environment variables created should be prefixed with GITHUB_ to ensure they can be accessed in workflows.
There is no requirement that custom environment variables must be prefixed with GITHUB_ to be accessible.

The GITHUB_ prefix is reserved for default environment variables automatically set by GitHub Actions.

Custom variables can use any naming convention and are still fully accessible in workflows.

C. The environment variables can be set in the defaults: sections of the workflow.
The defaults: section in a workflow is used to set default settings for run steps, such as shell or working directory, not environment variables.

Environment variables are set using the env: keyword at the workflow, job, or step level.

The defaults: context has no capability to define or override environment variables.

Reference
GitHub Docs: Default environment variables

Explanation
When developing JavaScript actions with the GitHub Actions Toolkit, the @actions/core package provides dedicated methods for creating workflow annotations. For warning messages that should appear prominently in the workflow run without failing the build, the core.warning() method is the correct choice. This creates visible warning annotations that help users identify potential issues while allowing the workflow to continue.

Correct Option

C. core.warning('Something went wrong, but it's not bad enough to fail the build.')
The core.warning() method is specifically designed to create warning annotations in GitHub Actions workflow runs.

Warning messages appear in the log with a yellow warning icon and are displayed in the annotation list on the workflow run page.

Unlike errors, warnings do not cause the step or job to fail, making them ideal for non-critical notifications.

This method is part of the official @actions/core package and follows GitHub's annotation standards.

Incorrect Options

A. core.info('Something went wrong, but it's not bad enough to fail the build.')
The core.info() method outputs standard log messages without any special annotation formatting.

Info messages appear in the workflow log but do not create visible annotations in the GitHub UI.

This is useful for general debugging but does not provide the visual prominence of a warning.

B. core.notice('Something went wrong, but it\’s not bad enough to fail the build.')
core.notice() is not a valid method in the @actions/core package.

The package includes core.info(), core.warning(), and core.error() but no notice() method.

Using this would result in a runtime error in the action.

D. core.warn('Something went wrong, but it's not bad enough to fail the build.')
While warn might seem like an intuitive shorthand, the correct method name in the @actions/core package is warning().

The package does not export a method named warn(), so this would cause an error.

The naming convention follows the pattern of using full words (info, warning, error) for clarity.

Reference
GitHub Docs: JavaScript actions - Logging warnings

Explanation
Container jobs in GitHub Actions require specific configurations on self-hosted runners to function properly. When container jobs fail, two critical requirements to verify are that the runner uses a Linux operating system (containers cannot run natively on Windows runners) and that Docker is installed and running. Without these, the runner cannot pull images or execute containers for your workflow jobs.

Correct Options

A. The self-hosted runner is running a Linux operating system.
Container jobs require Linux-based runners because GitHub Actions uses Linux containers for job execution.

Windows-based self-hosted runners cannot run Linux containers natively without additional complex configuration.

The runner software on Linux has the necessary kernel features and compatibility to create and manage containers.

C. Docker is installed on the self-hosted runner.
Docker is the container runtime that GitHub Actions uses to execute container jobs.

The runner communicates with the Docker daemon to pull images, create containers, and manage the container lifecycle.

Without Docker installed and the daemon running, any attempt to run a container job will fail immediately.

Incorrect Options

B. The self-hosted runner is running a Windows operating system.
Windows runners cannot run Linux containers, which are the default for GitHub Actions container jobs.

While Windows containers exist, they are not compatible with the standard container job syntax used in most workflows.

This would cause container jobs to fail, not resolve them.

D. Kubernetes is installed on the self-hosted runner.
Kubernetes is not required for container jobs on self-hosted runners.

GitHub Actions runs containers directly through Docker, not through Kubernetes orchestration.

Installing Kubernetes adds unnecessary complexity and is not used by the runner software.

E. The service status of Kubernetes is "active".
Since Kubernetes is not required for container jobs, its service status is irrelevant.

The runner does not interact with Kubernetes at all when executing container jobs.

Checking Kubernetes status would not help diagnose or fix container job failures.

Reference
GitHub Docs: About self-hosted runners - Requirements for container jobs

Explanation
GitHub-hosted runners are virtual environments managed by GitHub that execute workflow jobs. They offer several key capabilities including automatic maintenance and multi-OS support. However, they do not provide persistent storage between runs and have specific limitations regarding OS variations. Understanding these capabilities helps in designing efficient and reliable workflows.

Correct Options

A. automatic patching of both the runner and the underlying OS
GitHub automatically updates and patches the runner software and the underlying virtual machine image.

Runners are refreshed with each job execution, ensuring consistent and secure environments.

Users do not need to manage updates or security patches for GitHub-hosted runners.

This eliminates maintenance overhead compared to self-hosted runners.

C. support for Linux, Windows, and macOS
GitHub-hosted runners provide support for all three major operating systems: Linux (Ubuntu), Windows Server, and macOS.

Workflows can specify different operating systems for different jobs using the runs-on keyword.

This multi-OS support enables cross-platform testing and builds without managing multiple runner types.

Incorrect Options

B. automatic file-system caching between workflow runs
GitHub-hosted runners do not provide persistent file-system storage between workflow runs.

Each job starts with a fresh virtual machine image with no data from previous runs.

While the cache action can persist data between runs, it is not automatic file-system caching.

D. support for a variety of Linux variations including CentOS, Fedora, and Debian
GitHub-hosted runners only officially support Ubuntu Linux distributions (specifically Ubuntu LTS versions).

Other Linux variations like CentOS, Fedora, or Debian are not available as GitHub-hosted runner options.

Users needing other distributions must use self-hosted runners.

E. requiring a payment mechanism (e.g., credit card) to use for private repositories
GitHub provides free minutes for private repositories on all plans, though with different limits.

While paid minutes may be needed after exhausting free quotas, a payment mechanism is not universally required.

Public repositories always receive free minutes regardless of account type.

Reference
GitHub Docs: About GitHub-hosted runners