{"id":18967,"date":"2026-09-22T11:02:39","date_gmt":"2026-09-22T11:02:39","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=18967"},"modified":"2026-09-22T11:02:39","modified_gmt":"2026-09-22T11:02:39","slug":"microsoft-gh-200-practice-test-questions-and-exam-dumps-part16-q301-320","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/microsoft-gh-200-practice-test-questions-and-exam-dumps-part16-q301-320\/","title":{"rendered":"Microsoft GH-200 Practice Test Questions and Exam Dumps Part16 Q301-320"},"content":{"rendered":"

View Full <\/b>Microsoft GH-200 Exam Dumps<\/b><\/a> and Practice Test Dumps<\/b><\/h2>\n

 <\/p>\n

Question 301<\/b><\/h3>\n

Which GitHub feature lets repository administrators define reusable metadata fields for repositories?<\/b><\/p>\n

    \n
  1. Custom properties<\/span><\/li>\n
  2. Release assets<\/span><\/li>\n
  3. Issue labels<\/span><\/li>\n
  4. Branch aliases<\/span><\/li>\n<\/ol>\n

    Correct Answer: 1<\/b><\/p>\n

    Explanation:<\/b><\/p>\n

    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.<\/span><\/p>\n

    Question 302<\/b><\/h3>\n

    Which GitHub repository setting determines whether anyone can access its source code?<\/b><\/p>\n

      \n
    1. Branch policy<\/span><\/li>\n
    2. Repository visibility<\/span><\/li>\n
    3. Merge configuration<\/span><\/li>\n
    4. Issue permissions<\/span><\/li>\n<\/ol>\n

      Correct Answer: 2<\/b><\/p>\n

      Explanation:<\/b><\/p>\n

      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.<\/span><\/p>\n

      Question 303<\/b><\/h3>\n

      Which pull request option combines all commits into one commit when merging?<\/b><\/p>\n

        \n
      1. Rebase merge<\/span><\/li>\n
      2. Fast-forward merge<\/span><\/li>\n
      3. Squash merge<\/span><\/li>\n
      4. Recursive merge<\/span><\/li>\n<\/ol>\n

        Correct Answer: 3<\/b><\/p>\n

        Explanation:<\/b><\/p>\n

        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.<\/span><\/p>\n

        Question 304<\/b><\/h3>\n

        What does the GitHub pull request \u201cRebase and merge\u201d method primarily do?<\/b><\/p>\n

          \n
        1. Deletes all source commits<\/span><\/li>\n
        2. Replays commits onto the updated base branch<\/span><\/li>\n
        3. Creates a permanent release<\/span><\/li>\n
        4. Converts the pull request into an issue<\/span><\/li>\n<\/ol>\n

          Correct Answer: 2<\/b><\/p>\n

          Explanation:<\/b><\/p>\n

          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.<\/span><\/p>\n

          Question 305<\/b><\/h3>\n

          Which GitHub action is used to reverse changes introduced by an already merged pull request?<\/b><\/p>\n

            \n
          1. Reopen<\/span><\/li>\n
          2. Compare<\/span><\/li>\n
          3. Convert<\/span><\/li>\n
          4. Revert<\/span><\/li>\n<\/ol>\n

            Correct Answer: 4<\/b><\/p>\n

            Explanation:<\/b><\/p>\n

            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.<\/span><\/p>\n

            Question 306<\/b><\/h3>\n

            Which GitHub feature displays differences between two branches or references before merging?<\/b><\/p>\n

              \n
            1. Compare changes<\/span><\/li>\n
            2. Repository insights<\/span><\/li>\n
            3. Release history<\/span><\/li>\n
            4. Security overview<\/span><\/li>\n<\/ol>\n

              Correct Answer: 1<\/b><\/p>\n

              Explanation:<\/b><\/p>\n

              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.<\/span><\/p>\n

              Question 307<\/b><\/h3>\n

              Which GitHub release option marks a published release as not yet suitable for general consumption?<\/b><\/p>\n

                \n
              1. Archived<\/span><\/li>\n
              2. Prerelease<\/span><\/li>\n
              3. Internal<\/span><\/li>\n
              4. Draft<\/span><\/li>\n<\/ol>\n

                Correct Answer: 2<\/b><\/p>\n

                Explanation:<\/b><\/p>\n

                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.<\/span><\/p>\n

                Question 308<\/b><\/h3>\n

                Which Git object normally records a named pointer to a specific commit?<\/b><\/p>\n

                  \n
                1. Blob<\/span><\/li>\n
                2. Tree<\/span><\/li>\n
                3. Tag<\/span><\/li>\n
                4. Index<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 3<\/b><\/p>\n

                  Explanation:<\/b><\/p>\n

                  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.<\/span><\/p>\n

                  Question 309<\/b><\/h3>\n

                  Which Git feature allows a working tree to use only selected files from a repository?<\/b><\/p>\n

                    \n
                  1. Sparse checkout<\/span><\/li>\n
                  2. Full clone<\/span><\/li>\n
                  3. Git archive<\/span><\/li>\n
                  4. Branch reset<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 1<\/b><\/p>\n

                    Explanation:<\/b><\/p>\n

                    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.<\/span><\/p>\n

                    Question 310<\/b><\/h3>\n

                    What is the primary purpose of a GitHub security policy file named SECURITY.md?<\/b><\/p>\n

                      \n
                    1. Define branch names<\/span><\/li>\n
                    2. Explain how vulnerabilities should be reported<\/span><\/li>\n
                    3. Configure workflow runners<\/span><\/li>\n
                    4. Store deployment credentials<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 2<\/b><\/p>\n

                      Explanation:<\/b><\/p>\n

                      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.<\/span><\/p>\n

                      Question 311<\/b><\/h3>\n

                      Which GitHub security feature allows maintainers to request private vulnerability reports from researchers?<\/b><\/p>\n

                        \n
                      1. Public Discussions<\/span><\/li>\n
                      2. Security advisories<\/span><\/li>\n
                      3. Repository labels<\/span><\/li>\n
                      4. Release notes<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 2<\/b><\/p>\n

                        Explanation:<\/b><\/p>\n

                        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.<\/span><\/p>\n

                        Question 312<\/b><\/h3>\n

                        What does a GitHub audit log primarily record?<\/b><\/p>\n

                          \n
                        1. Organization and account administrative events<\/span><\/li>\n
                        2. Source-code file contents<\/span><\/li>\n
                        3. Compiler warnings<\/span><\/li>\n
                        4. Workflow artifact binaries<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 1<\/b><\/p>\n

                          Explanation:<\/b><\/p>\n

                          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.<\/span><\/p>\n

                          Question 313<\/b><\/h3>\n

                          Which GitHub Actions setting can pause a deployment for a configured waiting period?<\/b><\/p>\n

                            \n
                          1. Job timeout<\/span><\/li>\n
                          2. Environment wait timer<\/span><\/li>\n
                          3. Runner timeout<\/span><\/li>\n
                          4. Cache expiration<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 2<\/b><\/p>\n

                            Explanation:<\/b><\/p>\n

                            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.<\/span><\/p>\n

                            Question 314<\/b><\/h3>\n

                            Which GitHub Actions value identifies the short name of the current repository’s branch or tag reference?<\/b><\/p>\n

                              \n
                            1. github.ref_name<\/span><\/li>\n
                            2. github.repository_name<\/span><\/li>\n
                            3. github.branch_name<\/span><\/li>\n
                            4. github.reference_label<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 1<\/b><\/p>\n

                              Explanation:<\/b><\/p>\n

                              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.<\/span><\/p>\n

                              Question 315<\/b><\/h3>\n

                              Which GitHub Actions expression function creates a formatted string from supplied values?<\/b><\/p>\n

                                \n
                              1. join()<\/span><\/li>\n
                              2. contains()<\/span><\/li>\n
                              3. format()<\/span><\/li>\n
                              4. startsWith()<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 3<\/b><\/p>\n

                                Explanation:<\/b><\/p>\n

                                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.<\/span><\/p>\n

                                Question 316<\/b><\/h3>\n

                                What does the cancelled() GitHub Actions status function detect?<\/b><\/p>\n

                                  \n
                                1. A successful deployment<\/span><\/li>\n
                                2. A cancelled workflow or job state<\/span><\/li>\n
                                3. A missing repository<\/span><\/li>\n
                                4. An expired artifact<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 2<\/b><\/p>\n

                                  Explanation:<\/b><\/p>\n

                                  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.<\/span><\/p>\n

                                  Question 317<\/b><\/h3>\n

                                  Which GitHub Actions context provides the URL of the GitHub server hosting the repository?<\/b><\/p>\n

                                    \n
                                  1. github.server_url<\/span><\/li>\n
                                  2. github.host_name<\/span><\/li>\n
                                  3. github.web_url<\/span><\/li>\n
                                  4. github.site_address<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 1<\/b><\/p>\n

                                    Explanation:<\/b><\/p>\n

                                    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.<\/span><\/p>\n

                                    Question 318<\/b><\/h3>\n

                                    Which GitHub Actions file allows a step to publish text into the workflow run summary?<\/b><\/p>\n

                                      \n
                                    1. GITHUB_OUTPUT<\/span><\/li>\n
                                    2. GITHUB_STATE<\/span><\/li>\n
                                    3. GITHUB_STEP_SUMMARY<\/span><\/li>\n
                                    4. GITHUB_COMMAND<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 3<\/b><\/p>\n

                                      Explanation:<\/b><\/p>\n

                                      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.<\/span><\/p>\n

                                      Question 319<\/b><\/h3>\n

                                      Which GitHub Actions feature can automatically retry a failed workflow execution?<\/b><\/p>\n

                                        \n
                                      1. Workflow rerun<\/span><\/li>\n
                                      2. Repository fork<\/span><\/li>\n
                                      3. Release promotion<\/span><\/li>\n
                                      4. Branch synchronization<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 1<\/b><\/p>\n

                                        Explanation:<\/b><\/p>\n

                                        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.<\/span><\/p>\n

                                        Question 320<\/b><\/h3>\n

                                        Which GitHub Actions permission is specifically required to allow a workflow to write OpenID Connect tokens?<\/b><\/p>\n

                                          \n
                                        1. contents: write<\/span><\/li>\n
                                        2. packages: write<\/span><\/li>\n
                                        3. id-token: write<\/span><\/li>\n
                                        4. deployments: write<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 3<\/b><\/p>\n

                                          Explanation:<\/b><\/p>\n

                                          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.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                          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? Custom properties Release assets Issue labels Branch aliases Correct Answer: 1 Explanation: Custom properties allow organizations to attach structured metadata to repositories. Administrators can define properties that describe characteristics such […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/18967"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=18967"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/18967\/revisions"}],"predecessor-version":[{"id":18968,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/18967\/revisions\/18968"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=18967"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=18967"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=18967"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}