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

 

Question 381

Which GitHub Actions feature lets users manually provide values when starting a workflow?

1. Repository variables
2. Workflow inputs
3. Runner parameters
4. Action arguments

Correct Answer: 2

Explanation:

Workflow inputs allow a manually triggered workflow to receive values from the person starting the run. They are commonly defined with the workflow_dispatch trigger and can represent information such as deployment targets, release versions, or optional configuration choices. Inputs make manual workflows more flexible because the same workflow definition can support different execution scenarios without requiring source-code changes. Depending on the workflow configuration, inputs can use supported data types and may include descriptions or default values. This provides a structured way to collect runtime information before the workflow begins processing.

Question 382

Which GitHub Actions event is designed for manually starting a workflow from GitHub?

1. workflow_dispatch
2. manual_run
3. user_trigger
4. workflow_start

Correct Answer: 1

Explanation:

The workflow_dispatch event enables a workflow to be started manually. When configured, GitHub provides an interface for authorized users to initiate the workflow and, when defined, supply input values. Manual triggering is useful for operational tasks that should occur on demand rather than automatically after every repository event. Examples include controlled deployments, maintenance operations, or generating release-related outputs. Because the workflow is explicitly started by a user, it can combine manual inputs with existing workflow logic to provide a controlled execution process.

Question 383

Which GitHub Actions feature allows a workflow to call another workflow defined in a different file?

1. Workflow reference
2. Reusable workflow
3. Action inheritance
4. Job template

Correct Answer: 2

Explanation:

Reusable workflows allow one workflow to invoke another workflow as a callable automation component. This helps organizations centralize common processes such as testing, validation, or deployment preparation rather than duplicating the same YAML across many repositories. A reusable workflow can define supported inputs, secrets, and outputs that form an interface for callers. This approach improves consistency and makes centralized maintenance easier. It is different from calling an individual action because a reusable workflow can contain multiple jobs and coordinate a broader automation process.

Question 384

Which GitHub Actions keyword declares that a workflow can be called by another workflow?

1. workflow_call
2. workflow_use
3. workflow_link
4. workflow_import

Correct Answer: 1

Explanation:

The workflow_call event declares that a workflow is available to be invoked by another workflow. It is used in reusable workflow definitions and can be configured with inputs, secrets, and outputs. This creates a defined interface between the calling workflow and the reusable workflow. Centralizing automation in callable workflows can reduce duplication and ensure that multiple repositories follow the same process. The caller can supply the supported parameters while the called workflow performs its standardized jobs. This model is especially useful for organization-wide CI/CD patterns.

Question 385

Which GitHub Actions construct lets one job wait for another job to finish?

1. depends-on
2. after
3. needs
4. requires

Correct Answer: 3

Explanation:

The needs keyword establishes a dependency between jobs in a GitHub Actions workflow. When one job specifies another through needs, the dependent job normally waits until the required job completes successfully before proceeding. This allows workflows to model stages such as build, test, and deployment. Job dependencies also expose upstream results through the needs context, allowing later jobs to make decisions based on previous outcomes. Proper use of dependencies helps create predictable execution order while still allowing unrelated jobs to run independently.

Question 386

Which GitHub Actions strategy creates jobs from multiple combinations of defined values?

1. Matrix strategy
2. Parameter loop
3. Combination engine
4. Variant runner

Correct Answer: 1

Explanation:

A matrix strategy allows a single job definition to execute across multiple combinations of specified values. For example, a workflow can test an application against several operating systems and runtime versions without writing a separate job definition for every combination. GitHub generates the corresponding job instances from the matrix configuration. Matrix strategies are useful for broad compatibility testing and repetitive validation. Additional controls can determine concurrency and behavior when one combination fails. This approach keeps workflow definitions concise while still providing coverage across multiple supported configurations.

Question 387

Which GitHub Actions matrix option removes selected combinations from the generated job set?

1. skip
2. exclude
3. remove
4. omit

Correct Answer: 2

Explanation:

The matrix exclude configuration removes selected combinations from the set of jobs generated by a matrix strategy. This is useful when most combinations should run but particular combinations are unsupported or unnecessary. For example, an application may support several runtime and operating-system combinations while excluding one incompatible pairing. Using exclude avoids creating separate job definitions just to handle exceptions. Matrix configuration can therefore represent both the general compatibility set and specific exceptions in a structured manner.

Question 388

Which GitHub Actions matrix option adds additional custom combinations?

1. append
2. extend
3. include
4. add

Correct Answer: 3

Explanation:

The matrix include configuration allows workflow authors to add or extend matrix combinations with additional values. It can be useful when certain generated jobs need extra variables or when a custom combination should be introduced beyond the basic Cartesian product. This provides flexibility without requiring an entirely separate job definition. Matrix configuration can use both include and exclude to shape the final set of generated jobs. Understanding the difference helps workflow authors represent complex testing or deployment combinations while keeping the workflow structure manageable.

Question 389

Which GitHub Actions property can assign a working directory specifically to a command step?

1. path
2. working-directory
3. command-location
4. directory

Correct Answer: 2

Explanation:

The working-directory property allows a run step to execute its command from a specified directory. This is useful for repositories containing multiple applications or components where commands must operate from a particular subdirectory. Instead of changing directories manually inside every command, the workflow can declare the intended working location directly. This improves readability and reduces unnecessary shell commands. The setting can be useful in monorepositories or projects containing separate frontend, backend, and infrastructure directories that each require different build or test commands.

Question 390

Which GitHub Actions property limits how long an individual job may execute?

1. execution-limit
2. job-timeout
3. timeout-minutes
4. maximum-runtime

Correct Answer: 3

Explanation:

The timeout-minutes property limits the maximum execution time of a job. If the job exceeds the configured duration, GitHub Actions terminates it rather than allowing it to run indefinitely. This can protect runner capacity from jobs that become stuck because of an unexpected command, external dependency, or test condition. Timeout configuration should reflect the expected workload so that legitimate long-running jobs are not terminated prematurely. Setting reasonable limits can also make failures easier to detect and prevent resources from being consumed indefinitely.

Question 391

Which GitHub Actions context contains information about the event payload that triggered the run?

1. github.event
2. github.payload_data
3. github.trigger_object
4. github.event_data

Correct Answer: 1

Explanation:

The github.event context provides the payload associated with the event that triggered the workflow. It contains event-specific information that can be used in expressions and workflow logic. For example, a pull request event can expose information about the pull request, while a push event contains details about the pushed references and commits. The exact structure depends on the triggering event. Using event payload data allows workflows to respond dynamically to repository activity rather than relying only on fixed configuration values.

Question 392

Which GitHub Actions context identifies the full Git reference associated with a workflow run?

1. github.reference
2. github.ref
3. github.git_ref
4. github.full_ref

Correct Answer: 2

Explanation:

The github.ref context provides the full Git reference associated with the workflow event. Depending on the event, it can represent a branch, tag, or another supported reference. This differs from github.ref_name, which provides a shorter reference name. The full reference is useful when scripts or conditions need to distinguish reference namespaces or construct operations that require the complete Git ref. Understanding the difference between the full reference and its short name helps prevent errors when workflows process branches and tags.

Question 393

Which GitHub Actions context identifies the unique number assigned to a workflow run?

1. github.run_number
2. github.run_attempt
3. github.run_id
4. github.workflow_run

Correct Answer: 3

Explanation:

The github.run_id context identifies a specific workflow run with a unique identifier. It is different from github.run_number, which provides a sequential number, and github.run_attempt, which identifies a particular attempt associated with a run. The unique run ID can be useful when integrating GitHub Actions with external systems that need to track or correlate individual executions. For example, monitoring or deployment systems can store the run ID as a reference to the exact workflow execution that produced an output or performed an operation.

Question 394

Which GitHub Actions context identifies the repository name without its owner?

1. github.repository_name
2. github.repo
3. github.name
4. github.project_name

Correct Answer: 1

Explanation:

The github.repository_name context provides the repository’s name without combining it with the repository owner. This is useful when a workflow needs only the project portion of the repository identifier. It differs from github.repository, which represents the owner and repository together, and from github.repository_owner, which identifies the owning account separately. Using the specific context value needed by a workflow avoids unnecessary string parsing and makes automation easier to understand. This can be useful when constructing filenames, deployment identifiers, or project-specific messages.

Question 395

Which GitHub Actions context identifies the account associated with the commit author?

1. github.committer
2. github.commit_author
3. Event-specific commit data
4. github.author_account

Correct Answer: 3

Explanation:

Commit-author information is available through the event payload when the triggering event provides commit details. The exact location depends on the event structure, so workflows should reference the appropriate fields within github.event rather than assuming a universal top-level context property. This distinction matters because the person who authored a commit can differ from the account that triggered a workflow. Event payloads provide the detailed information associated with the specific event. Understanding that structure helps workflows accurately process commit metadata without confusing authorship with workflow initiation.

Question 396

Which GitHub Actions feature can show a workflow’s generated commands and diagnostic information in greater detail?

1. Debug logging
2. Repository insights
3. Action comments
4. Runner labels

Correct Answer: 1

Explanation:

GitHub Actions supports debug logging that can provide additional diagnostic information during workflow execution. This can help troubleshoot unexpected behavior by exposing more detailed information than ordinary workflow output. Debugging options should generally be enabled when needed rather than treated as a replacement for normal logging practices. Additional diagnostic information can be particularly useful when investigating expression evaluation, action behavior, runner problems, or unexpected execution paths. Once troubleshooting is complete, teams can return to normal logging settings to avoid unnecessary verbosity.

Question 397

Which GitHub Actions mechanism lets a command safely hide a sensitive value from subsequent log output?

1. Secret registration
2. Log masking
3. Output encryption
4. Console filtering

Correct Answer: 2

Explanation:

GitHub Actions supports log masking for sensitive values that should not appear in workflow output. A workflow can register a value for masking so that matching content is obscured when it is subsequently written to logs. This is particularly useful for dynamically generated sensitive data that is not already stored as a repository or organization secret. Masking should not be treated as a substitute for secure secret handling because the value must still be protected from unnecessary exposure. Workflows should avoid printing credentials and should use the platform’s supported secret-management mechanisms whenever possible.

Question 398

Which GitHub feature helps organizations review changes made to repository and account settings over time?

1. Audit log
2. Repository README
3. Project board
4. Release history

Correct Answer: 1

Explanation:

The GitHub audit log records supported administrative and security-related events, helping organizations investigate changes involving repositories, accounts, permissions, and other governance activities. Administrators can use audit information to understand what happened, when an event occurred, and which actor was associated with the activity, depending on the event and available data. This makes the audit log valuable for operational review and security investigations. It is different from repository history, which primarily records source-code changes. Audit records therefore provide a governance-oriented view of platform activity.

Question 399

Which GitHub security feature can block a detected secret before it is pushed to a repository?

1. Secret scanning push protection
2. Dependency review
3. Code formatting
4. Package validation

Correct Answer: 1

Explanation:

Secret scanning push protection can help prevent supported secrets from being pushed to repositories. When a potential secret is detected during a push, the protection mechanism can block the operation and provide information about the detected credential pattern. This creates a preventive control rather than relying only on discovering exposed secrets after they have entered repository history. Organizations can configure security controls according to their GitHub plan and repository settings. Push protection should complement secure credential practices, including avoiding hardcoded secrets and using appropriate secret-management systems.

Question 400

Which GitHub security capability analyzes source code for known classes of vulnerabilities?

1. Dependency graph
2. Secret scanning
3. Code scanning
4. Repository insights

Correct Answer: 3

Explanation:

Code scanning analyzes repository source code to identify potential security vulnerabilities and coding problems. GitHub supports CodeQL-based analysis as one approach to code scanning, allowing repositories to be examined using security-focused queries. Results can appear as alerts that developers can investigate and address. Code scanning differs from dependency analysis, which focuses on external packages, and secret scanning, which looks for exposed credentials or secret patterns. Combining these security capabilities provides coverage across different classes of software-security risks rather than relying on a single detection mechanism.