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

 

Question 301

Which GitHub feature lets repository administrators define reusable metadata fields for repositories?

1. Custom properties
2. Release assets
3. Issue labels
4. Branch aliases

Correct Answer: 1

Explanation:

Custom properties allow organizations to attach structured metadata to repositories. Administrators can define properties that describe characteristics such as application type, business unit, lifecycle stage, or ownership category. This information can then help organizations organize and manage repositories consistently at scale. Unlike issue labels, which primarily classify individual issues and pull requests, custom properties apply at the repository level. They are particularly useful for organizations managing many repositories where ordinary naming conventions are insufficient. Centralized metadata can also support administrative workflows and filtering, making repository discovery and governance more systematic.

Question 302

Which GitHub repository setting determines whether anyone can access its source code?

1. Branch policy
2. Repository visibility
3. Merge configuration
4. Issue permissions

Correct Answer: 2

Explanation:

Repository visibility determines who can access a repository based on whether it is public, private, or, where supported, internal. A public repository is accessible to anyone on GitHub, while a private repository restricts access to authorized users and organizations. Internal repositories provide organization-oriented sharing under supported enterprise configurations. Visibility is separate from branch protection because branch protection controls changes to branches rather than basic repository access. Administrators should select visibility according to the sensitivity of the source code and the collaboration model required by the project.

Question 303

Which pull request option combines all commits into one commit when merging?

1. Rebase merge
2. Fast-forward merge
3. Squash merge
4. Recursive merge

Correct Answer: 3

Explanation:

A squash merge combines the commits from a pull request into a single commit on the target branch. This can produce a simpler target-branch history when a pull request contains many incremental development commits. The individual commits remain part of the pull request’s development record, while the resulting branch receives one consolidated commit. This differs from a rebase merge, which replays commits onto the target branch without creating a merge commit. Choosing a merge method depends on the repository’s history preferences, collaboration practices, and branch-management requirements.

Question 304

What does the GitHub pull request “Rebase and merge” method primarily do?

1. Deletes all source commits
2. Replays commits onto the updated base branch
3. Creates a permanent release
4. Converts the pull request into an issue

Correct Answer: 2

Explanation:

A rebase-and-merge operation places the pull request’s commits onto the current tip of the base branch and then integrates them without creating a traditional merge commit. The resulting history can appear linear because the changes are replayed on top of the updated target branch. This differs from squash merging, which condenses the pull request into one commit. Rebase-based integration can produce a clean history but may change commit identities because rebased commits are recreated. Teams should therefore choose the merge method according to their preferred history structure and repository policies.

Question 305

Which GitHub action is used to reverse changes introduced by an already merged pull request?

1. Reopen
2. Compare
3. Convert
4. Revert

Correct Answer: 4

Explanation:

GitHub can create a revert pull request to reverse the changes introduced by a previously merged pull request. This approach is useful when an integrated change needs to be undone while preserving the existing development history. Rather than manually reconstructing the inverse changes, GitHub can prepare the reversal based on the merged pull request. The resulting pull request can then undergo the repository’s normal review and validation process. This provides a traceable way to back out a change while retaining an auditable record of why and how the reversal occurred.

Question 306

Which GitHub feature displays differences between two branches or references before merging?

1. Compare changes
2. Repository insights
3. Release history
4. Security overview

Correct Answer: 1

Explanation:

GitHub’s compare functionality allows users to examine differences between two Git references, such as branches, tags, or commits. It can show commits and changed files associated with the selected comparison. This is useful when developers want to understand what would differ between two development lines before creating or reviewing a pull request. Comparing references is different from repository insights, which provide broader activity and repository statistics. The comparison view therefore serves as a focused tool for examining source-code differences and understanding the changes represented between two points in repository history.

Question 307

Which GitHub release option marks a published release as not yet suitable for general consumption?

1. Archived
2. Prerelease
3. Internal
4. Draft

Correct Answer: 2

Explanation:

A prerelease is a published GitHub release that is identified as being before a stable production release. It can be used for versions intended for testing, evaluation, or early adoption without presenting them as the final stable version. This differs from a draft release, which has not yet been published. Marking a release as prerelease provides users with a clear indication that the version may still change or may not be recommended for general production use. Release classification can therefore help teams communicate maturity and expectations to people consuming their software.

Question 308

Which Git object normally records a named pointer to a specific commit?

1. Blob
2. Tree
3. Tag
4. Index

Correct Answer: 3

Explanation:

A Git tag provides a named reference to a particular point in repository history, commonly a commit. Tags are frequently used to identify significant versions such as releases. Unlike branches, which normally move forward as new commits are added, a tag generally remains associated with the referenced point unless explicitly changed. Git supports lightweight tags as well as annotated tags, with annotated tags storing additional metadata. Using tags gives development and release processes stable names for important repository states and makes it easier to reference specific versions later.

Question 309

Which Git feature allows a working tree to use only selected files from a repository?

1. Sparse checkout
2. Full clone
3. Git archive
4. Branch reset

Correct Answer: 1

Explanation:

Sparse checkout allows a working tree to contain only selected portions of a repository rather than materializing every tracked file. This can be useful for large monorepositories where developers or automation need only a subset of the project. The repository can still contain its broader history and structure, while the working directory is limited to the paths required for the task. Sparse checkout differs from a shallow clone, which limits commit history rather than file selection. This distinction makes sparse checkout particularly useful when repository size or project structure makes a complete working tree inconvenient.

Question 310

What is the primary purpose of a GitHub security policy file named SECURITY.md?

1. Define branch names
2. Explain how vulnerabilities should be reported
3. Configure workflow runners
4. Store deployment credentials

Correct Answer: 2

Explanation:

A SECURITY.md file communicates a project’s security policy and provides guidance for reporting vulnerabilities. It can explain supported versions, preferred reporting methods, or other security-related procedures. Providing this information gives researchers and users a clear route for responsibly communicating potential security issues. The file is documentation rather than a credential store or workflow configuration mechanism. Keeping security reporting instructions visible in the repository can improve coordination when vulnerabilities are discovered and help maintainers communicate their expectations regarding responsible disclosure.

Question 311

Which GitHub security feature allows maintainers to request private vulnerability reports from researchers?

1. Public Discussions
2. Security advisories
3. Repository labels
4. Release notes

Correct Answer: 2

Explanation:

GitHub security advisories provide a mechanism for privately discussing and managing vulnerabilities affecting a repository. Maintainers can use advisory functionality to coordinate vulnerability information without immediately exposing sensitive technical details publicly. This is particularly useful when a security issue requires investigation or remediation before broader disclosure. Advisories can also support the process of communicating information about affected versions and fixes. They are distinct from ordinary issues and discussions, which may not provide the same specialized security workflow. Proper use of private vulnerability handling can reduce unnecessary exposure while remediation is underway.

Question 312

What does a GitHub audit log primarily record?

1. Organization and account administrative events
2. Source-code file contents
3. Compiler warnings
4. Workflow artifact binaries

Correct Answer: 1

Explanation:

The GitHub audit log records significant administrative and security-related activities within supported organizations or enterprises. Depending on the event, entries can help administrators investigate changes involving repositories, permissions, memberships, settings, and other organizational activity. The audit log is not intended to store source-code contents or workflow-generated binaries. It instead provides an activity record that can assist governance, compliance, and security investigations. Reviewing audit information can help administrators understand when important administrative actions occurred and which account or actor performed them.

Question 313

Which GitHub Actions setting can pause a deployment for a configured waiting period?

1. Job timeout
2. Environment wait timer
3. Runner timeout
4. Cache expiration

Correct Answer: 2

Explanation:

An environment wait timer can delay a deployment before the job proceeds into an environment. This provides teams with an additional control point for deployment workflows where a deliberate pause is useful. The wait timer is associated with environment protection rather than the maximum execution duration of a job. A job timeout controls how long a job may execute, while cache expiration concerns stored workflow cache data. Deployment environments can combine waiting periods with other protection rules to create a controlled release process before deployment proceeds.

Question 314

Which GitHub Actions value identifies the short name of the current repository’s branch or tag reference?

1. github.ref_name
2. github.repository_name
3. github.branch_name
4. github.reference_label

Correct Answer: 1

Explanation:

The github.ref_name context property contains the short name of the Git reference associated with the workflow execution. For branch-based events, it can provide the branch name without the full reference prefix. For tag-based events, it similarly provides the tag name. This makes the property useful when scripts need a concise reference value for filenames, deployment parameters, or build metadata. It should not be confused with the repository name, which identifies the repository itself. Using the appropriate context property helps workflows avoid unnecessary parsing of full Git reference strings.

Question 315

Which GitHub Actions expression function creates a formatted string from supplied values?

1. join()
2. contains()
3. format()
4. startsWith()

Correct Answer: 3

Explanation:

The format() expression function constructs a string by replacing placeholders with supplied values. It can be useful when workflows need to generate dynamic names, messages, paths, or identifiers. For example, a workflow can combine a branch name and run number into a single formatted value. Other expression functions serve different purposes: join() combines array values, contains() checks membership or text inclusion, and startsWith() tests a prefix. Understanding these expression functions allows workflow authors to build concise dynamic logic without relying on external scripting for simple string operations.

Question 316

What does the cancelled() GitHub Actions status function detect?

1. A successful deployment
2. A cancelled workflow or job state
3. A missing repository
4. An expired artifact

Correct Answer: 2

Explanation:

The cancelled() status function evaluates whether the relevant workflow execution has been cancelled. It can be used in conditional expressions when a workflow needs behavior specifically associated with cancellation. This is different from failure(), which addresses unsuccessful execution, and success(), which represents successful completion. Cancellation can occur through manual intervention or workflow concurrency behavior, among other supported mechanisms. A cancellation-specific condition is useful when cleanup, notification, or diagnostic logic should distinguish an intentional stop from an ordinary failure.

Question 317

Which GitHub Actions context provides the URL of the GitHub server hosting the repository?

1. github.server_url
2. github.host_name
3. github.web_url
4. github.site_address

Correct Answer: 1

Explanation:

The github.server_url context property provides the base URL of the GitHub server associated with the workflow. This can be useful when scripts or notifications need to construct links back to GitHub resources. Using a context value is preferable to hardcoding a server address because workflows may operate in different GitHub environments. Other context properties provide information about the repository, API endpoint, or individual references. Selecting the correct URL property allows workflow automation to generate appropriate links while remaining adaptable to the GitHub environment in which it executes.

Question 318

Which GitHub Actions file allows a step to publish text into the workflow run summary?

1. GITHUB_OUTPUT
2. GITHUB_STATE
3. GITHUB_STEP_SUMMARY
4. GITHUB_COMMAND

Correct Answer: 3

Explanation:

GITHUB_STEP_SUMMARY is an environment file used by GitHub Actions to add Markdown-formatted content to the summary displayed for a workflow run. It allows workflows to present useful information such as test results, deployment details, generated links, or important status messages in a readable format. This can be more convenient than requiring users to inspect lengthy command logs. The summary is associated with the workflow run and can provide a concise reporting layer for automation. It is distinct from GITHUB_OUTPUT, which is used to communicate step outputs.

Question 319

Which GitHub Actions feature can automatically retry a failed workflow execution?

1. Workflow rerun
2. Repository fork
3. Release promotion
4. Branch synchronization

Correct Answer: 1

Explanation:

GitHub Actions provides workflow rerun capabilities that allow an authorized user to execute a completed workflow again. Rerunning can be useful when a failure results from a transient condition, such as a temporary external service problem or unstable test dependency. Depending on the available options, users may rerun an entire workflow or selected failed jobs. A rerun creates another execution attempt while preserving the original run information for investigation. This makes reruns useful for operational recovery without modifying the underlying workflow definition or source code.

Question 320

Which GitHub Actions permission is specifically required to allow a workflow to write OpenID Connect tokens?

1. contents: write
2. packages: write
3. id-token: write
4. deployments: write

Correct Answer: 3

Explanation:

The id-token: write permission allows a GitHub Actions workflow to request an OpenID Connect identity token. Such tokens can be used by supported external cloud or identity systems to establish trust with the workflow without requiring a long-lived cloud credential to be stored as a traditional secret. The permission is intentionally separate from repository content permissions because token issuance represents a different security capability. Workflows should grant only the permissions they require. Using narrowly scoped permissions reduces unnecessary access and supports a least-privilege security model for automation.