{"id":18953,"date":"2026-09-22T11:00:49","date_gmt":"2026-09-22T11:00:49","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=18953"},"modified":"2026-09-22T11:00:49","modified_gmt":"2026-09-22T11:00:49","slug":"microsoft-gh-200-practice-test-questions-and-exam-dumps-part9-q161-180","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/microsoft-gh-200-practice-test-questions-and-exam-dumps-part9-q161-180\/","title":{"rendered":"Microsoft GH-200 Practice Test Questions and Exam Dumps Part9 Q161-180"},"content":{"rendered":"<h2><b>View Full <\/b><a href=\"https:\/\/www.examlabs.com\/gh-200-exam-dumps\"><b>Microsoft GH-200 Exam Dumps<\/b><\/a><b> and Practice Test Dumps<\/b><\/h2>\n<p>&nbsp;<\/p>\n<h3><b>Question 161<\/b><\/h3>\n<p><b>Which GitHub Actions feature prevents multiple workflow runs from executing simultaneously?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Artifact retention<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Job outputs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Runner labels<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Concurrency control<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Concurrency control allows a workflow or job to share a concurrency group so that GitHub can limit simultaneous executions. When configured appropriately, a newer run can wait for or cancel an earlier run in the same group. This is useful for deployment workflows where overlapping deployments could cause inconsistent application states. The concurrency key can be based on values such as a branch or environment. Artifact retention manages stored files, job outputs transfer data between jobs, and runner labels determine which runners can execute jobs. Concurrency therefore provides the mechanism for controlling overlapping workflow executions.<\/span><\/p>\n<h3><b>Question 162<\/b><\/h3>\n<p><b>Which GitHub Actions syntax references a repository variable named APP_MODE?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">${{ secrets.APP_MODE }}<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">${{ vars.APP_MODE }}<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">${{ env.APP_MODE }}<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">${{ github.APP_MODE }}<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The vars context is used to access configuration variables defined at the organization, repository, or environment level. Therefore, ${{ vars.APP_MODE }} retrieves the variable named APP_MODE. Secrets use the secrets context and are intended for sensitive values. The env context represents environment variables defined for workflows, jobs, or steps, while the github context contains information about the workflow run, repository, event, and related GitHub metadata. Using the correct context is important because these mechanisms have different scopes, purposes, and security characteristics within GitHub Actions.<\/span><\/p>\n<h3><b>Question 163<\/b><\/h3>\n<p><b>Which GitHub Actions event is designed to start a workflow when a release is published?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">release<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">deployment<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">repository_dispatch<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">workflow_call<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The release event allows a GitHub Actions workflow to respond to activity involving repository releases. A workflow can be configured to run when a release is published, created, edited, or other supported release activities occur. This is useful for automation that should begin after a release becomes available, such as packaging, publishing documentation, or notifying another system. The deployment event relates to deployment activity, repository_dispatch provides a custom repository event mechanism, and workflow_call allows one workflow to be invoked by another workflow. Each event therefore serves a different automation scenario.<\/span><\/p>\n<h3><b>Question 164<\/b><\/h3>\n<p><b>Which GitHub Actions feature lets one workflow call another workflow in the same repository?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">workflow_run<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">repository_dispatch<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">workflow_call<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">schedule<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The workflow_call trigger makes a workflow reusable by allowing another workflow to invoke it. A reusable workflow can define inputs, secrets, and outputs, making common automation logic easier to maintain centrally. This is particularly useful when multiple repositories or workflows need the same standardized build, test, security, or deployment process. workflow_run responds to the completion or activity of another workflow, while repository_dispatch creates a custom event through an API request. The schedule event starts workflows according to configured cron expressions. Thus, workflow_call is specifically intended for reusable workflow invocation.<\/span><\/p>\n<h3><b>Question 165<\/b><\/h3>\n<p><b>Which GitHub Actions context identifies the repository owner and name together?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">github.ref<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">github.repository<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">github.workflow<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">github.sha<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The github.repository context property identifies the repository associated with the workflow run, typically using the owner\/repository format. This value is useful when scripts or actions need to construct repository-specific commands or API requests without hardcoding a repository name. github.ref identifies the Git reference associated with the event, github.workflow provides the workflow name, and github.sha identifies the commit associated with the workflow run. Understanding these context properties helps developers build reusable workflows that dynamically respond to the repository and event that triggered execution.<\/span><\/p>\n<h3><b>Question 166<\/b><\/h3>\n<p><b>Which GitHub Actions mechanism can pass a calculated value from one step to a later step?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Job-level permissions<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Repository variables<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Workflow inputs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Step outputs<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Step outputs allow one step to expose a calculated value that another step in the same job can consume. A step is assigned an identifier, and its output can then be referenced through the steps context. This pattern is useful when an earlier command calculates a version, generates a file path, determines a deployment target, or produces another value needed later. Job outputs serve a different purpose because they transfer information between jobs. Workflow inputs provide externally supplied values, while repository variables provide configuration data. Step outputs are therefore the appropriate mechanism for passing dynamically generated values between steps.<\/span><\/p>\n<h3><b>Question 167<\/b><\/h3>\n<p><b>Which GitHub Actions option allows a job to run on several operating systems automatically?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Environment protection<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Reusable workflow<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Matrix strategy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Artifact upload<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A matrix strategy allows a GitHub Actions job to execute multiple variations using combinations of defined values. Operating systems are a common matrix dimension, allowing the same test job to run on platforms such as Ubuntu, Windows, and macOS. Matrix expansion reduces duplicated YAML because one job definition can represent multiple execution variants. Environment protection controls deployment approvals and restrictions, reusable workflows centralize workflow logic, and artifact upload stores generated files. Matrix strategies are especially useful for cross-platform testing because they provide systematic coverage while keeping workflow definitions relatively concise.<\/span><\/p>\n<h3><b>Question 168<\/b><\/h3>\n<p><b>Which GitHub Actions keyword defines a command that executes directly on a runner?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">run<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">uses<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">with<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">name<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The run keyword specifies shell commands that GitHub Actions executes on the selected runner. For example, a workflow can use run to execute package installation, tests, build commands, scripts, or deployment utilities. The uses keyword instead invokes an action, such as an action published in a repository. The with keyword supplies input parameters to an action or reusable component, while name provides a human-readable name for workflow elements. Choosing between run and uses depends on whether the workflow needs to execute commands directly or consume existing action functionality.<\/span><\/p>\n<h3><b>Question 169<\/b><\/h3>\n<p><b>Which GitHub Actions setting can automatically cancel an older run when a newer run begins?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Artifact overwrite<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Matrix include<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Job timeout<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Concurrency cancellation<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Concurrency can be configured with cancellation behavior so that an in-progress run is canceled when another run enters the same concurrency group. This is useful for workflows where only the newest change should continue, such as branch-based deployments or validation jobs. The cancel-in-progress setting provides this behavior when enabled. Artifact overwrite controls stored artifacts, matrix configuration determines job combinations, and job timeouts limit execution duration. Concurrency cancellation helps prevent unnecessary resource consumption and avoids situations where outdated workflow runs continue processing after a newer commit has superseded them.<\/span><\/p>\n<h3><b>Question 170<\/b><\/h3>\n<p><b>Which GitHub Actions context provides information about the event that triggered a workflow?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">runner<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">github.event<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">steps<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">vars<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The github.event context contains the payload associated with the event that triggered the workflow. Its contents depend on the event type. For example, a pull request event provides information about the pull request, while a push event contains details about the pushed references and commits. This context is useful when workflows need to make decisions based on event-specific data. The runner context describes the environment executing the job, steps contains information about completed steps, and vars provides configuration variables. Therefore, github.event is the appropriate source for trigger-event payload information.<\/span><\/p>\n<h3><b>Question 171<\/b><\/h3>\n<p><b>Which GitHub feature lets administrators require specific checks before merging a pull request?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Branch protection rules<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Issue forms<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Release assets<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Repository discussions<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Branch protection rules can require selected status checks to pass before a pull request can be merged into a protected branch. Administrators can also configure related requirements such as reviews, conversation resolution, or restrictions on direct pushes, depending on the repository configuration. This helps establish consistent controls around important branches such as a production or default branch. Issue forms standardize issue submissions, release assets attach files to releases, and Discussions provide a space for community or project conversations. Branch protection is therefore the GitHub feature directly associated with enforcing merge requirements.<\/span><\/p>\n<h3><b>Question 172<\/b><\/h3>\n<p><b>Which GitHub Actions expression function returns the status of a previous step?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">format()<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">contains()<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">success()<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">startsWith()<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The success() status-check function evaluates whether all previous steps have completed successfully. It is commonly used in conditional expressions when a workflow needs to run a step only after earlier processing has succeeded. GitHub Actions provides several status-check functions that allow workflow authors to control execution based on job or step outcomes. contains() checks whether a value contains another value, startsWith() checks a prefix, and format() creates formatted strings. Using status functions correctly can make workflow behavior more predictable when handling successful execution, failures, cancellations, or other workflow states.<\/span><\/p>\n<h3><b>Question 173<\/b><\/h3>\n<p><b>Which GitHub Actions feature stores files produced during a workflow run?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Repository variables<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Artifacts<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Runner groups<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Environment secrets<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">GitHub Actions artifacts are files or collections of files uploaded during a workflow run so they can be retained and accessed after the producing job completes. Common examples include compiled packages, test reports, logs, coverage files, and deployment bundles. Artifacts are different from caches because caches are primarily intended to speed up repeated workflow operations by storing reusable dependencies or other data. Runner groups control access to self-hosted runners, variables provide configuration values, and environment secrets protect sensitive deployment information. Artifacts therefore provide the standard mechanism for preserving workflow-generated files.<\/span><\/p>\n<h3><b>Question 174<\/b><\/h3>\n<p><b>Which GitHub Actions event allows a user to start a workflow manually from GitHub?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">push<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">pull_request<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">repository_dispatch<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">workflow_dispatch<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The workflow_dispatch event enables a workflow to be started manually through GitHub&#8217;s interface or through supported API mechanisms. It can also define inputs so the person starting the workflow can provide values for that particular execution. This is useful for on-demand deployments, maintenance tasks, release processes, or operational workflows that should not run automatically on every code change. The push event responds to pushes, pull_request responds to pull request activity, and repository_dispatch is intended for custom repository events. Manual workflow execution is therefore associated with workflow_dispatch.<\/span><\/p>\n<h3><b>Question 175<\/b><\/h3>\n<p><b>Which GitHub Actions permission is needed to allow a workflow to write repository contents?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">contents: write<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">contents: read<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">issues: read<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">actions: read<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The contents: write permission allows the workflow&#8217;s GITHUB_TOKEN to perform supported write operations against repository contents. This can be necessary when automation creates commits, updates files, or performs other repository-content operations. contents: read provides read access but does not grant the equivalent write capability. The issues: read permission concerns issue data, while actions: read relates to GitHub Actions resources. Following the principle of least privilege, workflows should request only the permissions they actually require. Granting write access should therefore be deliberate and limited to the jobs or workflows that need it.<\/span><\/p>\n<h3><b>Question 176<\/b><\/h3>\n<p><b>Which GitHub Actions construct allows a job to receive values produced by another job?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Step outputs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Environment variables<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Job outputs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Repository secrets<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Job outputs allow values generated by one job to be made available to dependent jobs. A producing job can expose selected step outputs as job outputs, and another job can reference them through the needs context after establishing the appropriate dependency. This is useful for passing information such as generated version numbers, deployment identifiers, or calculated configuration values between separate jobs. Step outputs are primarily scoped within a job, while environment variables and secrets serve different configuration and security purposes. Job outputs therefore provide a structured mechanism for transferring generated data across job boundaries.<\/span><\/p>\n<h3><b>Question 177<\/b><\/h3>\n<p><b>Which GitHub Actions feature can restrict deployments until an approval is granted?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Matrix strategy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Artifact retention<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Runner labels<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Environment protection rules<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Environment protection rules can require approvals or satisfy other configured conditions before a deployment proceeds to a protected environment. This is useful for environments representing sensitive targets such as production. The environment can also have associated secrets and deployment restrictions, allowing organizations to control how workflows interact with important resources. Matrix strategies control job variations, artifact retention controls how long stored artifacts remain available, and runner labels help select compatible runners. Environment protection therefore provides a governance mechanism for deployment workflows where human approval or other restrictions are required before execution continues.<\/span><\/p>\n<h3><b>Question 178<\/b><\/h3>\n<p><b>Which GitHub Actions keyword specifies the action repository and version used by a step?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">uses<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">run<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">shell<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">environment<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The uses keyword tells GitHub Actions to execute an action rather than running a shell command directly. A typical value identifies an action repository and a reference such as a tag, branch, or commit. This allows workflows to consume reusable automation for tasks such as checking out code, uploading artifacts, configuring languages, or performing deployment operations. The run keyword executes shell commands, shell controls the shell used for a command, and environment associates a job with a deployment environment. Therefore, uses is the workflow syntax for invoking an action.<\/span><\/p>\n<h3><b>Question 179<\/b><\/h3>\n<p><b>Which GitHub Actions feature lets a workflow use different values for the same job definition?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Environments<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Matrix strategy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Runner groups<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Workflow logs<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A matrix strategy allows one job definition to execute repeatedly using different combinations of specified values. For example, a test workflow can vary the runtime version, operating system, or feature configuration without duplicating the entire job definition. GitHub expands the matrix into separate job executions based on the combinations provided. Environments are used for deployment targets and associated controls, runner groups organize self-hosted runners, and workflow logs record execution information. Matrix strategies are therefore the appropriate mechanism when the same workflow logic needs to operate against multiple configurations.<\/span><\/p>\n<h3><b>Question 180<\/b><\/h3>\n<p><b>Which GitHub Actions keyword makes one job wait for another job to finish?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">if<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">needs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">env<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">strategy<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The needs keyword establishes a dependency between jobs in a GitHub Actions workflow. When a job lists another job under needs, the dependent job waits until the required job has completed before starting. This relationship can also allow the workflow to use outputs from the completed job. By default, a dependent job does not proceed when its required job fails unless its conditional logic explicitly changes that behavior. The if keyword controls conditional execution, env defines environment variables, and strategy configures execution variations. Therefore, needs is the mechanism used to create job dependencies.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full Microsoft GH-200 Exam Dumps and Practice Test Dumps &nbsp; Question 161 Which GitHub Actions feature prevents multiple workflow runs from executing simultaneously? Artifact retention Job outputs Runner labels Concurrency control Correct Answer: 4 Explanation: Concurrency control allows a workflow or job to share a concurrency group so that GitHub can limit simultaneous executions. [&hellip;]<\/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\/18953"}],"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=18953"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/18953\/revisions"}],"predecessor-version":[{"id":18954,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/18953\/revisions\/18954"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=18953"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=18953"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=18953"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}