View Full Microsoft GH-200 Exam Dumps and Practice Test Dumps

 

Question 361

Which GitHub Actions option allows a workflow to use a specific version of an action?

1. version
2. uses
3. action-ref
4. release

Correct Answer: 2

Explanation:

The uses keyword specifies an action that a workflow should execute. A workflow can reference an action by repository and can select a particular branch, tag, or commit reference as supported by the action syntax. Pinning an action to a known commit can provide stronger control over exactly which code is executed. The uses keyword is different from run, which executes shell commands directly on the runner. Understanding the distinction allows workflow authors to combine reusable actions with ordinary command steps while keeping automation definitions clear and maintainable.

Question 362

Which GitHub Actions practice provides the strongest version pinning for third-party actions?

1. Using the latest major tag
2. Referencing the default branch
3. Pinning to a commit SHA
4. Omitting the version reference

Correct Answer: 3

Explanation:

Pinning an action to a specific commit SHA provides a precise reference to the action code that the workflow should execute. Unlike a moving branch or tag, a commit SHA identifies a particular revision. This can improve reproducibility and reduce the possibility that an action reference unexpectedly changes later. Teams may still need a process for reviewing and updating pinned versions as dependencies evolve. Version pinning is therefore a supply-chain consideration as well as a maintenance decision. It is especially relevant when workflows consume actions maintained outside the organization’s own repositories.

Question 363

Which GitHub Actions feature lets a workflow retrieve a previously saved dependency cache?

1. Cache restore
2. Runner snapshot
3. Artifact replay
4. Repository mirror

Correct Answer: 4

Explanation:

GitHub Actions caching allows workflows to reuse previously stored files such as package-manager dependencies. When a matching cache is available, the workflow can restore the cached content rather than downloading everything again. This can reduce execution time and external network traffic. Cache data is separate from workflow artifacts because caches are intended primarily to accelerate repeated jobs, while artifacts are generally used to preserve outputs from a workflow run. Effective cache keys should reflect the dependency state so that stale or incompatible data is not reused unintentionally.

Question 364

Which GitHub Actions cache setting provides alternative keys when the exact key is unavailable?

1. restore-keys
2. fallback-keys
3. backup-keys
4. secondary-keys

Correct Answer: 1

Explanation:

The restore-keys configuration provides fallback prefixes that GitHub Actions can use when an exact cache-key match is unavailable. This allows a workflow to restore a related cache instead of starting completely without cached data. For example, a key can include a dependency lock-file hash while a broader restore prefix allows an older compatible cache to be considered. The approach can improve cache usefulness while still prioritizing exact matches. Workflow authors should design restore prefixes carefully so that the restored data remains appropriate for the operation being performed.

Question 365

Which GitHub Actions feature preserves generated files after a workflow finishes?

1. Cache entry
2. Environment variable
3. Workflow artifact
4. Runner workspace

Correct Answer: 3

Explanation:

Workflow artifacts allow a job to upload files so they can be retained and accessed after the workflow execution. Typical examples include test reports, compiled packages, logs, screenshots, and other generated outputs. Artifacts differ from caches because their primary purpose is preserving workflow-produced data rather than accelerating dependency restoration. A workflow can upload selected files as an artifact and later download them from another job or inspect them through the workflow run. Artifact retention is governed by GitHub’s applicable settings and configuration.

Question 366

Which artifact property controls how long uploaded workflow files are retained?

1. retention-days
2. storage-period
3. artifact-expiry
4. keep-days

Correct Answer: 1

Explanation:

The retention-days setting controls the retention period for uploaded workflow artifacts, subject to the repository or organization limits that apply. Setting an appropriate retention period helps balance accessibility against storage usage. Temporary test outputs may need only a short retention period, while release-related files may require longer availability according to organizational practices. Artifact retention is separate from cache behavior because the two storage mechanisms serve different purposes. Workflow authors should also understand that configured retention cannot necessarily exceed the maximum allowed by the relevant GitHub policy.

Question 367

Which GitHub Actions feature allows an artifact to be downloaded by a later job?

1. Artifact sharing
2. Artifact transfer
3. Artifact restore
4. Artifact download

Correct Answer: 4

Explanation:

The artifact download mechanism allows a later job or workflow step to retrieve files that were previously uploaded as workflow artifacts. This supports multi-stage automation where one job produces files and another job consumes them. For example, a build job can generate a package while a later validation or deployment job downloads that package instead of rebuilding it. Artifact transfer creates a useful boundary between jobs because each job may execute on a different runner. The approach also allows generated outputs to remain available independently of the original runner’s temporary filesystem.

Question 368

Which GitHub Actions feature can prevent multiple runs of the same workflow from executing concurrently?

1. Job dependency
2. Concurrency control
3. Matrix exclusion
4. Runner grouping

Correct Answer: 2

Explanation:

Concurrency control lets workflow authors define a concurrency group so that related workflow runs do not execute simultaneously when that behavior is undesirable. This can be particularly useful for deployments where two overlapping executions could interfere with one another. Depending on configuration, a newer run can wait for or cancel an earlier run in the same group. Concurrency is separate from job dependencies because needs controls ordering between jobs inside a workflow, while concurrency manages overlapping workflow or job executions based on a defined group.

Question 369

Which GitHub Actions expression function checks whether a value contains specified text?

1. startsWith()
2. endsWith()
3. contains()
4. matches()

Correct Answer: 3

Explanation:

The contains() expression function checks whether a specified value includes the supplied search value. It can be used with strings and supported collections in GitHub Actions expressions. This makes it useful for conditions involving branch names, labels, event information, or other workflow data. It differs from startsWith() and endsWith(), which check only the beginning or end of a value. Using the appropriate expression function can keep conditional logic concise and avoid unnecessary shell scripting for simple comparisons.

Question 370

Which GitHub Actions expression function combines multiple array elements into one string?

1. merge()
2. combine()
3. concat()
4. join()

Correct Answer: 4

Explanation:

The join() expression function combines elements from an array into a string using an optional separator. This can be useful when workflow data contains a list but a later command or message requires a single text representation. For example, a workflow can construct a comma-separated list from several values without invoking an external scripting language. The function serves a different purpose from format(), which inserts values into a formatted string. Understanding expression functions can reduce unnecessary command execution and keep workflow conditions and transformations within the workflow language.

Question 371

Which GitHub Actions context identifies the GitHub account that owns the current repository?

1. github.repository_owner
2. github.owner_name
3. github.account
4. github.repo_owner_name

Correct Answer: 1

Explanation:

The github.repository_owner context identifies the owner of the repository associated with the current workflow. Depending on the repository, the owner may be a user account or an organization. This value can be useful when workflows construct repository references, API requests, or dynamic paths. It differs from github.repository, which combines the owner and repository name into one value. Using the owner context separately is helpful when automation needs to make decisions based on which account or organization controls the repository.

Question 372

Which GitHub Actions context identifies the GitHub event that triggered the workflow?

1. github.trigger
2. github.event_name
3. github.event_type_name
4. github.action_event

Correct Answer: 2

Explanation:

The github.event_name context identifies the event that triggered the current workflow run, such as a push, pull request, schedule, or manual dispatch. Workflows can use this value when several events share one workflow definition but require different processing paths. Instead of maintaining separate automation files for every event type, conditional expressions can inspect the event name and select appropriate behavior. This context is distinct from github.event, which provides the payload associated with the triggering event. Understanding both values helps workflow authors build event-aware automation.

Question 373

Which GitHub Actions property can make a job run on a specific runner label?

1. runner-label
2. machine
3. runs-on
4. host

Correct Answer: 3

Explanation:

The runs-on property specifies the runner environment where a GitHub Actions job executes. It can identify a GitHub-hosted runner image or use labels that match an eligible self-hosted runner. Runner selection is important because operating systems, installed software, architecture, and organizational runner policies can differ between environments. Choosing the correct runs-on value ensures that the job has an appropriate execution environment. It is a job-level configuration rather than a step-level property, so all steps within that job normally execute on the selected runner.

Question 374

Which GitHub Actions feature restricts which repositories may use a self-hosted runner group?

1. Runner group access policies
2. Workflow labels
3. Repository artifacts
4. Environment variables

Correct Answer: 1

Explanation:

Runner groups can be configured with access policies that control which repositories are permitted to use the runners assigned to the group. This is useful for organizations that maintain specialized or sensitive self-hosted infrastructure. Administrators can limit access so that only approved repositories can schedule jobs on those machines. Such controls are important because self-hosted runners may have access to internal networks, specialized tools, or persistent resources. Runner-group governance therefore adds an authorization layer beyond simply assigning labels to individual runners.

Question 375

Which GitHub Actions feature allows a job to run inside a specified container image?

1. container
2. image-run
3. docker-job
4. runtime

Correct Answer: 1

Explanation:

The container job configuration allows GitHub Actions to execute job steps inside a specified container image. This can provide a more controlled and repeatable software environment for build or test operations. The container image determines the base filesystem and available tooling, while additional service containers can support dependent services when required. Containerized jobs can reduce differences between execution environments, although workflows still need to account for runner capabilities and container configuration. The setting applies to the job rather than representing an individual command inside a step.

Question 376

Which GitHub Actions configuration defines additional containers that a job can communicate with?

1. dependencies
2. services
3. sidecars
4. support-containers

Correct Answer: 2

Explanation:

The services configuration allows a GitHub Actions job to start additional containers that provide supporting services. Common examples include databases, caches, or other network services required during automated tests. These service containers run alongside the primary job environment and can provide predictable dependencies without requiring a separate manually managed server. Service configuration is different from the primary container setting, which determines the environment in which the job steps themselves execute. Using services can make integration testing easier by packaging required dependencies into the workflow definition.

Question 377

Which GitHub Actions feature can automatically expose test results through a generated job summary?

1. Workflow annotations
2. Step summary
3. Runner report
4. Repository dashboard

Correct Answer: 2

Explanation:

A step summary allows workflow steps to publish Markdown content that appears in the workflow run summary. Teams can use this capability to present test outcomes, deployment information, generated links, or other useful results in a concise format. Unlike raw command logs, summaries can provide a structured overview that is easier to scan. The content is generated during workflow execution and associated with the corresponding run. This makes step summaries useful for reporting information that would otherwise require users to search through lengthy logs.

Question 378

Which GitHub Actions variable can expose the runner’s operating-system name?

1. runner.os
2. runner.platform_name
3. runner.system
4. runner.operating_system

Correct Answer: 1

Explanation:

The runner.os context property identifies the operating system of the runner executing the job. It can be used when workflow commands need platform-specific behavior. For example, a workflow might select different command syntax or binaries depending on whether it runs on Linux, Windows, or macOS. This context is separate from processor architecture, which can be identified through other runner information. Using runner.os allows workflows to adapt dynamically instead of maintaining completely separate automation definitions for each supported operating system.

Question 379

Which GitHub Actions context identifies the architecture of the current runner?

1. runner.platform
2. runner.arch
3. runner.cpu
4. runner.hardware

Correct Answer: 2

Explanation:

The runner.arch context identifies the processor architecture of the runner executing a GitHub Actions job. This can help workflows select architecture-specific binaries, packages, or build settings. Architecture information is distinct from the operating system, so a workflow may need both runner.arch and runner.os when selecting the correct build environment. Dynamic runner context values are especially useful for reusable workflows that support multiple execution platforms. They allow automation to make decisions based on the actual runner rather than relying on fixed assumptions.

Question 380

Which GitHub Actions permission allows a workflow to create or update pull requests?

1. issues: write
2. contents: write
3. pull-requests: write
4. checks: write

Correct Answer: 3

Explanation:

The pull-requests: write permission grants a workflow the ability to perform supported write operations involving pull requests. This can be required by automation that creates, updates, labels, or otherwise manages pull requests through GitHub’s supported interfaces. It is separate from contents: write, which controls repository-content operations, and from issues: write, which addresses issue-related capabilities. Because workflow tokens should follow least-privilege principles, administrators should grant only the permissions required for the automation’s actual tasks.