Microsoft GH-200 Exam Practice Test Instant Access

Question 1

As a developer, you need to use GitHub Actions to deploy a microservice that requires runtime access to a secure token. This token is used by a variety of other microservices managed by different teams in different repos. To minimize management overhead and ensure the token is secure, which mechanisms should you use to store and access the token? (Choose two.)

AStore the token in a configuration file in a private repository. Use GitHub Actions to deploy the configuration file to the runtime environment.

BStore the token as a GitHub encrypted secret in the same repo as the code. Create a reusable custom GitHub Action to access the token by the microservice at runtime.

CUse a corporate non-GitHub secret store (e.g., HashiCorp Vault) to store the token. During deployment, use GitHub Actions to store the secret in an environment variable that can be accessed at runtime.

DStore the token as a GitHub encrypted secret in the same repo as the code. During deployment, use GitHub Actions to store the secret in an environment variable that can be accessed at runtime.

EStore the token as an organizational-level encrypted secret in GitHub. During deployment, use GitHub Actions to store the secret in an environment variable that can be accessed at runtime.

Answer : C, E

Using a corporate secret store like HashiCorp Vault provides a secure, centralized location for sensitive information. GitHub Actions can then retrieve and store the token securely during deployment by setting it as an environment variable, ensuring the token remains secure and accessible at runtime.

Storing the token as an organizational-level encrypted secret in GitHub ensures it is accessible across multiple repositories, minimizing management overhead. GitHub Actions can then use this secret during deployment by setting it as an environment variable, allowing the microservice to access it securely at runtime.

Question 2

As a developer, how can you identify a Docker container action on GitHub?

AThe action's repository includes @actions/core in the root directory.

BThe action's repository name includes the keyword 'Docker.'

CThe action.yml metadata file references a Dockerfile file.

DThe action.yml metadata file has the runs.using value set to Docker.

Answer : D

In a Docker container action, the action.yml file includes the runs.using field, which is set to docker to specify that the action runs inside a Docker container. This is the key indicator that the action is a Docker container action.

Question 3

When reviewing an action for use, what file defines its available inputs and outputs?

Ainputs.yml

Bconfig.json

Cdefaults.json

Dworkflow.yml

Eaction.yml

Answer : E

The action.yml file defines the inputs and outputs for a GitHub Action. This file contains metadata about the action, including the required inputs and outputs, as well as other configurations like the action's description, runs, and environment setup.

Question 4

Which of the following scenarios would require the use of self-hosted runners instead of GitHub-hosted runners?

Arunning more than the three concurrent workflows supported by GitHub-hosted runners

Bexceeding 50,000 monthly minutes of build time

Cusing Docker containers as part of the workflow

Dusing specialized hardware configurations required for workflows

Eperforming builds on macOS

Answer : A, D

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.

Question 5

You have exactly one Windows x64 self-hosted runner, and it is configured with custom tools. Which syntax could you use in the workflow to target that runner?

Aself-hosted: [windows-x64]

Bruns-on: [self-hosted, windows, x64]

Cruns-on: windows-latest

Dself-hosted: [windows, x64]

Answer : B

The runs-on keyword allows you to specify the operating system and other labels for the runner. By specifying self-hosted, windows, and x64, you are targeting a self-hosted Windows runner that matches these criteria, which aligns with the custom configuration of your self-hosted runner.

Question 6

Which choices represent best practices for publishing actions so that they can be consumed reliably? (Choose two.)

Arepo name

Btag

Ccommit SHA

Dorganization name

Edefault branch

Answer : B, C

Using a tag is a best practice because tags are immutable and represent a fixed version of your action. By referencing tags, consumers of your action can be assured they are using a stable and specific version of the action, which helps in avoiding issues with breaking changes.

The commit SHA is another reliable way to specify a particular version of an action. By referencing a specific commit SHA, consumers can ensure they are using exactly the code that was written at that moment, avoiding the potential for changes in the future.

Question 7

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

Athe entire workflow, by using env at the top level of the workflow file

Ball jobs being run on a single Actions runner, by using runner.env at the top of the workflow file

Cthe entire stage, by using env at the top of the defined build stage

Dwithin the run attribute of a job step

Ethe contents of a job within a workflow, by using jobs.<job_id>.env

Fa specific step within a job, by using jobs.<job_id>.steps[*].env

Answer : A, D, F

You can define environment variables for the entire workflow by using the env key at the top level of the workflow file. These environment variables will be available to all jobs and steps within the workflow.

Environment variables can also be set within the run attribute of a job step, and these variables will be scoped only to that specific step.

You can set environment variables for specific steps within a job by using jobs.<job_id>.steps[*].env, which allows you to define variables that will only be available to that step.

Microsoft GitHub Actions GH-200 Exam Practice Test