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

 

Question 321

Which GitHub Actions feature lets a workflow assign a custom display name to each run?

1. Workflow alias
2. Run title
3. Execution label
4. run-name

Correct Answer: 4

Explanation:

The run-name property lets a workflow define a custom name for each workflow run. Unlike the workflow’s static name, which identifies the workflow itself, run-name can use expressions to create a more descriptive label for individual executions. For example, a workflow can include information derived from an event or user input in the displayed run name. This makes workflow history easier to understand when many executions occur. Dynamic run names are especially useful for deployment, release, and manually triggered workflows where identifying the purpose of each execution quickly can save investigation time.

Question 322

Which GitHub Actions property controls the default shell used by commands in a job?

1. defaults.run.shell
2. job.shell
3. command.shell
4. runner.default_shell

Correct Answer: 1

Explanation:

The defaults.run.shell configuration can establish the shell used by run steps when no more specific shell is provided. This allows workflow authors to define consistent command execution behavior without repeating the shell setting on every step. A workflow can configure defaults at an appropriate scope and override them for individual steps when necessary. Shell selection matters because command syntax differs between environments and shells. Establishing a predictable default can make automation easier to maintain, especially when multiple steps use similar command-line operations.

Question 323

Which GitHub Actions context exposes the name of the workflow currently executing?

1. github.workflow_name
2. github.action_name
3. github.workflow
4. github.current_workflow

Correct Answer: 3

Explanation:

The github.workflow context property identifies the name of the workflow associated with the current run. It can be useful when generating diagnostic output, notifications, or dynamic identifiers that need to reference the workflow responsible for an execution. This value describes the workflow rather than a particular step or action. Other GitHub context properties provide information about the repository, event, run, or actor. Using the workflow context can help reusable scripts and reporting systems identify which automation process produced a particular result without hardcoding the workflow name.

Question 324

Which GitHub Actions context identifies the username or account that initiated an event?

1. github.actor
2. github.initiator
3. github.user
4. github.trigger_user

Correct Answer: 1

Explanation:

The github.actor context identifies the user or account associated with the event that triggered the workflow. This can be useful for audit-oriented messages, notifications, and workflow logic that needs information about the triggering actor. The actor may be a user account or another supported GitHub identity depending on the event. It should not be confused with information about the repository owner or the commit author. Understanding event identity is particularly useful when workflows are manually initiated or when automation needs to include the triggering account in generated reports.

Question 325

Which GitHub Actions context identifies the repository owner and repository name together?

1. github.repository
2. github.project
3. github.repo_path
4. github.source

Correct Answer: 1

Explanation:

The github.repository context provides the repository in an owner-and-name format. This makes it useful when workflows need to reference the repository dynamically rather than hardcoding a repository identifier. Scripts can use this value when constructing API requests, generating links, or passing repository information to external tools. It differs from properties that provide only the repository name or only the account that owns it. Using the context keeps workflow logic portable across repositories because the same automation can obtain its current repository identity automatically.

Question 326

Which GitHub Actions setting limits how many matrix jobs may run simultaneously?

1. matrix.limit
2. jobs.parallel
3. max-parallel
4. strategy.limit

Correct Answer: 3

Explanation:

The max-parallel setting controls the maximum number of matrix jobs that GitHub Actions may execute concurrently. A matrix can generate many job combinations, but teams may need to limit simultaneous execution because of runner capacity, external service limits, or resource consumption. Setting max-parallel provides that control without removing matrix combinations. The remaining combinations can wait until available execution capacity exists. This makes the option useful for balancing the speed of parallel testing against infrastructure constraints and third-party service limitations.

Question 327

Which GitHub Actions matrix option determines whether remaining jobs stop after one matrix job fails?

1. stop-on-error
2. fail-fast
3. cancel-matrix
4. abort-on-failure

Correct Answer: 2

Explanation:

The fail-fast matrix strategy setting determines whether GitHub Actions cancels in-progress and queued matrix jobs when one matrix job fails. When enabled, a failure can cause other matrix combinations to stop, which may reduce unnecessary resource consumption. When disabled, the remaining combinations can continue so that the workflow obtains a more complete picture of the test results. This setting is especially relevant for large test matrices where each combination represents a different operating system, runtime, or configuration. Choosing the behavior depends on whether rapid failure detection or complete matrix results are more useful.

Question 328

Which GitHub Actions property can permit a particular step to fail without failing its entire job?

1. ignore-error
2. allow-failure
3. continue-on-error
4. step.optional

Correct Answer: 3

Explanation:

The continue-on-error property allows a step to fail while permitting the job to continue. This can be useful for noncritical operations such as optional diagnostics, experimental checks, or commands whose failure should not prevent subsequent processing. It does not mean that the failure disappears from the workflow’s execution information. Instead, the workflow can continue according to the configured behavior. The property can also be applied at job scope in supported scenarios, so workflow authors should understand whether they are allowing an individual step or an entire job to tolerate failure.

Question 329

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

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

Correct Answer: 4

Explanation:

The endsWith() expression function checks whether a value ends with a specified string. It can be useful for workflow conditions involving file extensions, branch naming conventions, tag suffixes, or other predictable text patterns. For example, a workflow could use it to recognize a reference ending in a particular suffix. Other expression functions perform different tasks: startsWith() checks prefixes, contains() checks inclusion, and format() constructs strings. Selecting the appropriate expression function keeps conditional logic compact and avoids unnecessary scripting for straightforward string comparisons.

Question 330

Which GitHub Actions property indicates whether a pull request was created as a draft?

1. github.event.pull_request.draft
2. github.pull_request.is_draft
3. github.event.draft_status
4. github.pr.draft_mode

Correct Answer: 1

Explanation:

For pull request events, the event payload contains information about whether the pull request is a draft. The github.event.pull_request.draft property can therefore be used in workflow expressions to distinguish draft pull requests from those ready for normal review or merging. This can be useful when teams want different automation behavior for unfinished work. For example, a workflow might perform lightweight validation for drafts while reserving deployment-related processing for pull requests that are no longer drafts. Using event payload data allows the workflow to respond to the actual state of the pull request.

Question 331

Which GitHub Actions context provides the base branch name of a pull request?

1. github.base_ref
2. github.target_branch
3. github.pull_base
4. github.destination_ref

Correct Answer: 1

Explanation:

The github.base_ref property identifies the base branch of a pull request. The base branch is the branch into which the proposed changes are intended to be merged. This information can be useful when workflows need different behavior depending on the target branch, such as applying additional validation to a production branch. It differs from the head reference, which identifies the source side of the pull request. Understanding the distinction between base and head references is important when writing conditions for pull-request workflows and deployment automation.

Question 332

Which GitHub Actions context provides the source branch name of a pull request?

1. github.source_ref
2. github.head_ref
3. github.origin_branch
4. github.pull_source

Correct Answer: 2

Explanation:

The github.head_ref context property provides the source branch name for a pull request event. This is the branch containing the proposed changes before they are merged into the base branch. Workflows can use the value when generating validation messages, selecting branch-specific behavior, or constructing dynamic identifiers. It is important to distinguish head_ref from base_ref: the former represents the source side of the pull request, while the latter represents the target side. Using the correct reference prevents automation from making decisions based on the wrong branch.

Question 333

Which GitHub Actions context property contains the current workflow attempt number?

1. github.run_attempt
2. github.retry_number
3. github.attempt_id
4. github.execution_attempt

Correct Answer: 1

Explanation:

The github.run_attempt property identifies which attempt of a workflow run is currently executing. This is useful when a workflow has been rerun and automation needs to distinguish the original execution from later attempts. The run ID identifies the workflow run itself, while the attempt number provides information about the particular execution attempt. This distinction can help with diagnostic output, artifact naming, and external monitoring systems. Using the attempt value can make repeated workflow executions easier to identify without confusing a rerun with an entirely unrelated workflow run.

Question 334

Which GitHub Actions context identifies the runner’s temporary working directory?

1. runner.workspace
2. runner.temp
3. runner.scratch
4. runner.temp_dir

Correct Answer: 2

Explanation:

The runner.temp context identifies the temporary directory available on the runner during workflow execution. It can be useful for storing transient files that are needed only while a job is running. Temporary workspace data can support diagnostic collection, intermediate processing, or generated files that do not need to become repository content. Runner context values describe characteristics of the environment executing the job and should not be confused with repository paths. Using the provided temporary directory can help workflows organize short-lived data without placing it into the project’s source tree.

Question 335

Which GitHub Actions context property exposes the status of the current job?

1. job.state
2. job.result_code
3. job.status
4. job.condition

Correct Answer: 3

Explanation:

The job.status context property provides information about the status of the current job during workflow execution. It can be useful when workflow logic or reporting needs to reference the job’s current state. Job-level context differs from step-level context because it describes the broader job execution rather than an individual command. Understanding the available contexts helps workflow authors avoid relying on manually maintained status variables. Status information can support reporting and conditional processing, especially in workflows that perform cleanup, diagnostics, or final reporting after important operations.

Question 336

Which GitHub Actions context identifies the result of a required job referenced through needs?

1. needs.<job_id>.result
2. needs.<job_id>.status_code
3. needs.<job_id>.outcome
4. needs.<job_id>.state

Correct Answer: 1

Explanation:

The needs.<job_id>.result property provides the result of a job that the current job depends on through the needs keyword. This allows downstream jobs to make decisions based on whether an upstream job succeeded, failed, was cancelled, or was skipped. It is particularly useful when a workflow needs different follow-up behavior depending on the result of an earlier stage. Using the needs context creates an explicit dependency between jobs and gives downstream automation access to the upstream result without requiring external state storage.

Question 337

Which GitHub Actions variable contains the API endpoint associated with the current GitHub server?

1. github.server_url
2. github.api_url
3. github.endpoint
4. github.rest_url

Correct Answer: 2

Explanation:

The github.api_url context property provides the API endpoint associated with the GitHub environment running the workflow. This can be useful when scripts or actions need to communicate with the GitHub API without hardcoding the service address. It is distinct from github.server_url, which identifies the main GitHub server URL. Keeping these values separate allows workflows to use the appropriate endpoint for web links or API operations. Dynamic context values are especially useful when automation needs to remain portable across supported GitHub environments.

Question 338

Which GitHub Actions environment file passes a value from one step to another as a step output?

1. GITHUB_OUTPUT
2. GITHUB_ENV
3. GITHUB_PATH
4. GITHUB_STATE

Correct Answer: 1

Explanation:

GITHUB_OUTPUT is the environment file used by a step to define outputs that can be referenced later. A step with an identifier can write a named output to this file, allowing subsequent steps to retrieve the value through the steps context. This mechanism is useful when one command calculates a value that another command needs. It differs from GITHUB_ENV, which establishes environment variables for later steps. Using step outputs creates an explicit data flow between steps and can make complex workflows easier to understand and maintain.

Question 339

Which GitHub Actions context identifies the repository’s default branch?

1. github.default_branch
2. github.main_branch
3. github.primary_ref
4. github.repository_branch

Correct Answer: 1

Explanation:

The repository information available through GitHub contexts includes the default branch associated with the repository. The github.default_branch property can be used when workflow logic needs to reference that branch dynamically instead of assuming a name such as main. This is helpful because repositories can use different default branch names. Avoiding hardcoded assumptions makes automation more reusable across projects. Workflows can use the default branch value when constructing links, selecting deployment behavior, or comparing changes against the repository’s configured primary branch.

Question 340

Which GitHub Actions context property identifies the number of times the current workflow has been executed?

1. github.execution_count
2. github.workflow_runs
3. github.run_number
4. github.workflow_attempts

Correct Answer: 3

Explanation:

The github.run_number property provides the sequential run number for the workflow. It is useful when workflows need a human-readable sequence value for build labels, generated filenames, release identifiers, or diagnostic output. This differs from github.run_id, which uniquely identifies a particular workflow run, and from github.run_attempt, which identifies an execution attempt associated with a run. Understanding these related values helps workflow authors choose the correct identifier for each purpose. A sequential run number is especially useful when users need an easy-to-read reference to workflow history.