{"id":18949,"date":"2026-09-22T11:00:18","date_gmt":"2026-09-22T11:00:18","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=18949"},"modified":"2026-09-22T11:00:18","modified_gmt":"2026-09-22T11:00:18","slug":"microsoft-gh-200-practice-test-questions-and-exam-dumps-part7-q121-140","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/microsoft-gh-200-practice-test-questions-and-exam-dumps-part7-q121-140\/","title":{"rendered":"Microsoft GH-200 Practice Test Questions and Exam Dumps Part7 Q121-140"},"content":{"rendered":"

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

 <\/p>\n

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

Which GitHub Actions feature lets jobs exchange structured values?<\/b><\/p>\n

    \n
  1. Runner labels<\/span><\/li>\n
  2. Workflow groups<\/span><\/li>\n
  3. Job outputs<\/span><\/li>\n
  4. Repository topics<\/span><\/li>\n<\/ol>\n

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

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

    Job outputs provide a structured mechanism for passing values from one GitHub Actions job to another. A producing job can expose selected step outputs at the job level, and a dependent job can retrieve them through the needs context. This is useful when one stage generates information required by a later stage, such as a package version, deployment target, or generated identifier. Job outputs are different from environment variables because they are specifically designed to communicate across job boundaries. They help create modular workflows where individual jobs have clear responsibilities and defined data dependencies.<\/span><\/p>\n

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

    Which GitHub Actions keyword defines a job’s execution condition?<\/b><\/p>\n

      \n
    1. if<\/span><\/li>\n
    2. when<\/span><\/li>\n
    3. condition<\/span><\/li>\n
    4. execute-if<\/span><\/li>\n<\/ol>\n

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

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

      The if keyword controls whether a GitHub Actions job or step should run. It evaluates an expression and executes the associated job or step only when the condition is satisfied. Conditions can reference contexts, event information, outputs, environment values, and status functions. This allows a workflow to use different execution paths without maintaining separate workflow files for every scenario. For example, a deployment job can be restricted to a particular branch or allowed to run only when an earlier validation job succeeds. Proper conditional logic helps workflows remain efficient and predictable.<\/span><\/p>\n

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

      Which GitHub Actions function checks whether all preceding steps succeeded?<\/b><\/p>\n

        \n
      1. success()<\/span><\/li>\n
      2. passed()<\/span><\/li>\n
      3. completed()<\/span><\/li>\n
      4. healthy()<\/span><\/li>\n<\/ol>\n

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

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

        The success() status-check function evaluates whether preceding steps or required workflow conditions have succeeded. It is commonly used in conditional expressions when a workflow needs to make execution dependent on successful earlier processing. For example, a notification or deployment step can use a success condition to prevent execution after a failed validation stage. GitHub Actions also provides other status-check functions for handling different execution states. Understanding these functions allows workflow authors to create precise control flow rather than relying only on the default behavior of sequential steps.<\/span><\/p>\n

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

        Which GitHub Actions function runs a step regardless of earlier results?<\/b><\/p>\n

          \n
        1. success()<\/span><\/li>\n
        2. always()<\/span><\/li>\n
        3. required()<\/span><\/li>\n
        4. continue()<\/span><\/li>\n<\/ol>\n

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

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

          The always() status-check function allows a step or job to run regardless of whether preceding steps have succeeded or failed, subject to other workflow conditions and execution behavior. It can be useful for cleanup operations, diagnostic collection, or reporting after a workflow stage completes. For example, a workflow can use it to collect logs after a failed test. Because it can execute after failures, it should be used carefully when the operation itself depends on successful prerequisites. Appropriate conditional logic can help ensure cleanup or reporting occurs without unintentionally triggering sensitive operations.<\/span><\/p>\n

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

          Which GitHub Actions setting controls parallel matrix execution?<\/b><\/p>\n

            \n
          1. parallel-limit<\/span><\/li>\n
          2. max-parallel<\/span><\/li>\n
          3. matrix-limit<\/span><\/li>\n
          4. job-parallelism<\/span><\/li>\n<\/ol>\n

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

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

            The max-parallel setting controls the maximum number of matrix jobs that can run simultaneously. A matrix may generate many combinations, but executing every combination at once can consume substantial runner capacity. Setting a maximum parallelism value allows teams to balance execution speed against available resources. This can be especially useful for large test matrices or repositories with limited self-hosted infrastructure. The setting does not reduce the total number of matrix combinations; instead, it controls how many generated jobs may execute concurrently. Remaining combinations wait until runner capacity becomes available.<\/span><\/p>\n

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

            Which GitHub Actions strategy option defines matrix combinations?<\/b><\/p>\n

              \n
            1. matrix<\/span><\/li>\n
            2. combinations<\/span><\/li>\n
            3. variants<\/span><\/li>\n
            4. job-set<\/span><\/li>\n<\/ol>\n

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

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

              The matrix strategy defines variable dimensions used to generate multiple GitHub Actions job executions. A matrix can contain values such as operating systems, programming-language versions, architectures, or testing configurations. GitHub creates a job for each applicable combination unless specific combinations are modified with options such as include or exclude. Matrix strategies reduce duplication because the workflow can describe one set of steps and apply it across many configurations. They are particularly useful for cross-platform testing and compatibility validation where the same process must be repeated under different environments.<\/span><\/p>\n

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

              Which GitHub Actions setting prevents one job from canceling other matrix jobs?<\/b><\/p>\n

                \n
              1. cancel-others<\/span><\/li>\n
              2. stop-on-error<\/span><\/li>\n
              3. fail-fast<\/span><\/li>\n
              4. continue-matrix<\/span><\/li>\n<\/ol>\n

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

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

                The fail-fast matrix option controls whether GitHub Actions cancels in-progress and queued matrix jobs when one matrix job fails. When enabled, a failure can cause other matrix executions to be canceled, which can save runner resources when the remaining results are unlikely to be useful. Setting fail-fast to false allows all matrix combinations to continue even when one fails. This can be valuable when teams need complete test information across every supported environment. The choice depends on whether rapid failure feedback or comprehensive matrix results are more important for the workflow.<\/span><\/p>\n

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

                Which GitHub Actions property defines a step’s reusable action?<\/b><\/p>\n

                  \n
                1. uses<\/span><\/li>\n
                2. calls<\/span><\/li>\n
                3. action<\/span><\/li>\n
                4. invoke<\/span><\/li>\n<\/ol>\n

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

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

                  The uses property specifies an action that a GitHub Actions step should execute. Actions can come from public repositories, the same repository, or other supported locations depending on the reference and permissions. A workflow can use actions for common tasks such as checking out source code, configuring runtimes, uploading artifacts, or performing specialized automation. The uses property differs from run, which executes shell commands directly. Reusing existing actions can reduce duplicated scripting and make workflows easier to maintain, provided that the selected actions are appropriately trusted and versioned.<\/span><\/p>\n

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

                  Which GitHub Actions property executes a shell command?<\/b><\/p>\n

                    \n
                  1. command<\/span><\/li>\n
                  2. script<\/span><\/li>\n
                  3. run<\/span><\/li>\n
                  4. execute<\/span><\/li>\n<\/ol>\n

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

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

                    The run property executes shell commands within a GitHub Actions step. It can contain a single command or multiple commands, depending on the workflow requirements. The command executes within the runner or job container environment selected for the workflow. Shell behavior can be controlled separately when needed using the shell property. The run mechanism is useful for project-specific build, test, packaging, and deployment commands that are not already encapsulated in an action. Developers should consider command portability when workflows run across different operating systems.<\/span><\/p>\n

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

                    Which GitHub Actions property gives a step an identifier?<\/b><\/p>\n

                      \n
                    1. name<\/span><\/li>\n
                    2. id<\/span><\/li>\n
                    3. identifier<\/span><\/li>\n
                    4. key<\/span><\/li>\n<\/ol>\n

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

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

                      The id property assigns an identifier to an individual GitHub Actions step. This identifier is especially important when later steps need to reference outputs produced by that step through the steps context. For example, a step with an ID can expose a generated value that another step consumes. The name property is intended primarily for displaying a readable step name in workflow logs. Using meaningful step IDs makes workflow expressions easier to understand and helps establish clear relationships between generated outputs and later processing.<\/span><\/p>\n

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

                      Which GitHub Actions field gives a human-readable step name?<\/b><\/p>\n

                        \n
                      1. name<\/span><\/li>\n
                      2. label<\/span><\/li>\n
                      3. title<\/span><\/li>\n
                      4. display<\/span><\/li>\n<\/ol>\n

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

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

                        The name property provides a human-readable name for a GitHub Actions step. These names appear in workflow execution views and make logs easier to understand. A descriptive step name can explain the purpose of an operation without requiring someone to inspect every command in the workflow file. This is especially valuable in larger workflows containing many build, testing, security, and deployment steps. The name property does not serve the same purpose as id; an ID is primarily used for referencing a step programmatically in expressions.<\/span><\/p>\n

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

                        Which GitHub Actions option allows a failing step to continue?<\/b><\/p>\n

                          \n
                        1. continue-on-error<\/span><\/li>\n
                        2. ignore-failure<\/span><\/li>\n
                        3. allow-fail<\/span><\/li>\n
                        4. continue-after-error<\/span><\/li>\n<\/ol>\n

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

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

                          The continue-on-error property allows a workflow to continue even when the associated step or job encounters an error. This can be useful for non-critical checks, experimental validation, or reporting operations where a failure should not prevent later workflow stages from executing. It should be used carefully because treating failures as non-blocking can allow later operations to proceed when an important validation has failed. Teams should distinguish informational checks from mandatory quality gates so that critical failures still stop workflows when appropriate.<\/span><\/p>\n

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

                          Which GitHub Actions property specifies an environment for a job?<\/b><\/p>\n

                            \n
                          1. environment<\/span><\/li>\n
                          2. target<\/span><\/li>\n
                          3. deployment-zone<\/span><\/li>\n
                          4. release-area<\/span><\/li>\n<\/ol>\n

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

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

                            The environment property associates a GitHub Actions job with a configured GitHub environment. Environments can represent deployment targets such as development, staging, or production. They can have environment-specific secrets and protection rules, including required reviewers where configured. Associating a job with an environment allows GitHub to apply the environment’s configured controls when the workflow reaches that stage. This is useful for separating ordinary build automation from protected deployment operations. Environment configuration should reflect the actual security and approval requirements of the application lifecycle.<\/span><\/p>\n

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

                            Which GitHub Actions context exposes a job’s execution result?<\/b><\/p>\n

                              \n
                            1. steps<\/span><\/li>\n
                            2. job<\/span><\/li>\n
                            3. status<\/span><\/li>\n
                            4. result<\/span><\/li>\n<\/ol>\n

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

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

                              The job context provides information associated with the current GitHub Actions job, including its status and outputs where applicable. Workflow expressions can use job-related information when making decisions during execution. This context should be distinguished from steps, which contains information about individual steps within the job, and needs, which provides information about prerequisite jobs. Understanding the scope of each context is important when constructing conditional workflow logic. Using the correct context prevents expressions from referencing information that is unavailable at a particular point in workflow execution.<\/span><\/p>\n

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

                              Which GitHub Actions feature defines environment-specific protected secrets?<\/b><\/p>\n

                                \n
                              1. Environments<\/span><\/li>\n
                              2. Matrix jobs<\/span><\/li>\n
                              3. Runner groups<\/span><\/li>\n
                              4. Workflow artifacts<\/span><\/li>\n<\/ol>\n

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

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

                                GitHub environments can contain secrets that are available to jobs associated with those environments. This allows teams to separate credentials according to deployment targets, such as staging and production. Environment protection rules can add additional controls before a job is allowed to access the protected environment. This design helps prevent workflows from using production credentials unnecessarily during ordinary development or testing. Environment-specific secrets should still be granted only to workflows and jobs that require them, and repository administrators should regularly review who can modify the associated environment configuration.<\/span><\/p>\n

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

                                Which GitHub Actions event runs when code is pushed to a repository?<\/b><\/p>\n

                                  \n
                                1. commit<\/span><\/li>\n
                                2. push<\/span><\/li>\n
                                3. code-change<\/span><\/li>\n
                                4. repository-update<\/span><\/li>\n<\/ol>\n

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

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

                                  The push event triggers a GitHub Actions workflow when commits are pushed to a repository, subject to any configured branch or path filters. It is one of the most common triggers for continuous integration workflows because new source changes can automatically start builds and tests. Filters can narrow execution to selected branches or files. For example, a workflow can run only when changes are pushed to a primary branch or when particular application directories are modified. Proper filtering helps prevent unnecessary workflow runs while maintaining relevant automation coverage.<\/span><\/p>\n

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

                                  Which GitHub Actions event responds to pull request activity?<\/b><\/p>\n

                                    \n
                                  1. merge-request<\/span><\/li>\n
                                  2. review-request<\/span><\/li>\n
                                  3. pull_request<\/span><\/li>\n
                                  4. code-review<\/span><\/li>\n<\/ol>\n

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

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

                                    The pull_request event allows GitHub Actions workflows to respond to pull request activity. Workflows can specify supported activity types to control which pull request actions trigger execution. This makes the event useful for continuous integration, validation, automated checks, and other pull request automation. Branch and path filters can further narrow when the workflow runs. Pull request workflows should be designed with appropriate permissions because code from pull requests, particularly those originating from forks, can have different security considerations than code pushed directly to trusted branches.<\/span><\/p>\n

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

                                    Which GitHub Actions event manually starts a workflow with inputs?<\/b><\/p>\n

                                      \n
                                    1. workflow_dispatch<\/span><\/li>\n
                                    2. manual_trigger<\/span><\/li>\n
                                    3. user_dispatch<\/span><\/li>\n
                                    4. workflow_start<\/span><\/li>\n<\/ol>\n

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

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

                                      The workflow_dispatch event enables users to manually start a GitHub Actions workflow through GitHub. It can define inputs that are supplied when the workflow is launched, allowing operators to select values such as deployment targets or versions. This makes workflow automation useful for controlled operational tasks that should not run automatically for every repository event. Manual workflows can also coexist with push, pull request, or scheduled triggers. When inputs influence sensitive actions, the workflow should validate them and use appropriate environment protections and permissions.<\/span><\/p>\n

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

                                      Which GitHub Actions context identifies the workflow event name?<\/b><\/p>\n

                                        \n
                                      1. github.event_name<\/span><\/li>\n
                                      2. workflow.event<\/span><\/li>\n
                                      3. trigger.name<\/span><\/li>\n
                                      4. event.workflow<\/span><\/li>\n<\/ol>\n

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

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

                                        The github.event_name value identifies the name of the event that triggered the current GitHub Actions workflow. This can be useful when a workflow responds to multiple event types and needs to execute different logic depending on the trigger. For example, automation may behave differently for a push, pull request, schedule, or manual dispatch. The value belongs to the github context, which contains broader information about the workflow execution. Using event information in conditions can reduce the need for separate workflows when related automation can share common processing logic.<\/span><\/p>\n

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

                                        Which GitHub Actions setting controls workflow-level environment variables?<\/b><\/p>\n

                                          \n
                                        1. environment<\/span><\/li>\n
                                        2. variables<\/span><\/li>\n
                                        3. env<\/span><\/li>\n
                                        4. settings<\/span><\/li>\n<\/ol>\n

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

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

                                          The env property can define environment variables at the workflow level, making those values available to jobs and steps unless a narrower scope overrides them. Workflow-level environment variables are useful for shared non-sensitive runtime configuration. Job-level and step-level env declarations can provide more specific values when required. Sensitive credentials should generally be stored as GitHub secrets rather than ordinary environment variables in workflow configuration. Keeping configuration separate from commands makes workflows easier to maintain and allows common values to be reused consistently across multiple processing stages.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full Microsoft GH-200 Exam Dumps and Practice Test Dumps   Question 121 Which GitHub Actions feature lets jobs exchange structured values? Runner labels Workflow groups Job outputs Repository topics Correct Answer: 3 Explanation: Job outputs provide a structured mechanism for passing values from one GitHub Actions job to another. A producing job can expose […]<\/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\/18949"}],"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=18949"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/18949\/revisions"}],"predecessor-version":[{"id":18950,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/18949\/revisions\/18950"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=18949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=18949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=18949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}