{"id":18963,"date":"2026-09-22T11:02:09","date_gmt":"2026-09-22T11:02:09","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=18963"},"modified":"2026-09-22T11:02:09","modified_gmt":"2026-09-22T11:02:09","slug":"microsoft-gh-200-practice-test-questions-and-exam-dumps-part14-q261-280","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/microsoft-gh-200-practice-test-questions-and-exam-dumps-part14-q261-280\/","title":{"rendered":"Microsoft GH-200 Practice Test Questions and Exam Dumps Part14 Q261-280"},"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 261<\/b><\/h3>\n<p><b>Which GitHub Actions feature allows a workflow to call an action by repository reference?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">environment<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">strategy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">permissions<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">uses<\/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 uses keyword invokes an action identified by a repository reference and version or revision. This allows workflows to consume reusable automation rather than implementing every operation with shell commands. Actions can perform tasks such as checking out source code, configuring development tools, uploading artifacts, or interacting with external services. The environment setting associates jobs with deployment environments, strategy controls execution variations, and permissions defines token access. Using uses therefore provides a standardized way to incorporate existing action implementations into GitHub Actions workflows.<\/span><\/p>\n<h3><b>Question 262<\/b><\/h3>\n<p><b>Which GitHub feature lets maintainers restrict who may dismiss pull request reviews?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Repository topics<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Branch protection settings<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Release configuration<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Issue templates<\/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;\">Branch protection settings can control requirements surrounding pull request reviews, including restrictions related to dismissing approved reviews. These controls help repositories preserve review integrity on important branches. Depending on the configuration, administrators can establish rules around required approvals, review dismissal, status checks, and other merge conditions. Repository topics categorize repositories, release configuration manages version publication settings, and issue templates structure issue submissions. Branch protection is therefore the appropriate area for configuring governance over pull request review requirements.<\/span><\/p>\n<h3><b>Question 263<\/b><\/h3>\n<p><b>Which GitHub Actions expression returns a JSON representation of a value?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">fromJSON()<\/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;\">toJSON()<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">join()<\/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 toJSON() expression function converts a value into JSON representation. This can be useful when workflow logic needs to inspect or expose structured context information or pass data in a JSON-compatible form. fromJSON() performs the reverse operation by interpreting JSON data, contains() checks whether a value includes another value, and join() combines elements into a string. Understanding these expression functions is important when workflows need to manipulate structured information rather than simple text values.<\/span><\/p>\n<h3><b>Question 264<\/b><\/h3>\n<p><b>Which GitHub Actions trigger can respond when a tag is pushed?<\/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;\">workflow_call<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">issues<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">discussion<\/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 push event can trigger workflows when commits or tags are pushed to a repository. Workflow configuration can further restrict the event to selected branches or tags. This is useful for automation such as creating releases, building versioned packages, or running validation whenever a particular tag is created. workflow_call is intended for reusable workflow invocation, while issues and discussion respond to their respective GitHub activities. The push event therefore provides the mechanism for reacting to tag push activity.<\/span><\/p>\n<h3><b>Question 265<\/b><\/h3>\n<p><b>Which GitHub feature lets administrators define organization-wide repository rules?<\/b><\/p>\n<ol>\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;\">Repository insights<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Organization rulesets<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Release assets<\/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;\">Organization rulesets allow administrators to define rules that can apply across repositories within an organization. They can be used to establish consistent controls around branches, tags, and repository workflows according to supported configurations. This provides a centralized governance mechanism instead of configuring every repository independently. Issue forms structure submitted issues, repository Insights provides activity information, and release assets contain files associated with releases. Organization-level rulesets are therefore useful when teams need consistent repository governance across multiple projects.<\/span><\/p>\n<h3><b>Question 266<\/b><\/h3>\n<p><b>Which GitHub Actions feature can assign different configuration values to matrix combinations?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">include<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">checkout<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">concurrency<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">permissions<\/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 include property can add or extend matrix combinations with additional values. This is useful when different combinations require specific configuration, such as assigning a particular deployment target or runtime setting to one matrix entry. Instead of creating separate jobs for every variation, workflow authors can enrich selected matrix combinations through include. checkout retrieves repository content, concurrency controls overlapping executions, and permissions manages token access. Matrix inclusion therefore provides flexible customization for individual workflow variants.<\/span><\/p>\n<h3><b>Question 267<\/b><\/h3>\n<p><b>Which GitHub capability enables automated dependency update pull requests?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Code scanning<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Dependabot<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Secret scanning<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Commit signing<\/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;\">Dependabot can create pull requests for dependency updates when version-update functionality is configured for the repository. This automation helps maintainers keep libraries and packages current while allowing proposed updates to pass through the normal review and validation process. Code scanning analyzes source code, secret scanning searches for exposed credentials, and commit signing provides verification information about commits. Dependabot therefore focuses on dependency maintenance and can integrate dependency changes into the repository&#8217;s pull request workflow.<\/span><\/p>\n<h3><b>Question 268<\/b><\/h3>\n<p><b>Which GitHub Actions option identifies the GitHub-hosted runner operating system?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">github.actor<\/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;\">runner.os<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">github.ref<\/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 runner.os property identifies the operating system of the runner executing the current job. Workflow scripts can use this information when commands or file-handling behavior need to differ between operating systems. github.actor identifies the user or application associated with the event, github.repository identifies the repository, and github.ref identifies the Git reference involved in the workflow event. Runner information is therefore useful when workflows need platform-aware conditional logic.<\/span><\/p>\n<h3><b>Question 269<\/b><\/h3>\n<p><b>Which GitHub feature lets maintainers restrict tag creation or updates?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Project fields<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Issue labels<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Wiki pages<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Tag 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;\">Repository rules can be configured to govern tag operations, helping organizations control which tags may be created, updated, or deleted. This is particularly useful when tags represent releases or other important points in repository history. Project fields organize planning data, issue labels categorize work, and Wiki pages provide documentation. Tag-related rules therefore provide governance over version markers and other important references in Git repositories.<\/span><\/p>\n<h3><b>Question 270<\/b><\/h3>\n<p><b>Which GitHub Actions feature can prevent two deployments to the same target from overlapping?<\/b><\/p>\n<ol>\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;\">Concurrency groups<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Step summaries<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Matrix values<\/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;\">Concurrency groups allow workflow runs or jobs to share a named execution group. When configured for deployment workflows, this can prevent multiple deployments targeting the same environment from running simultaneously. The configuration can also use cancellation behavior when appropriate. Job outputs transfer generated values between jobs, step summaries present information about execution, and matrix values define job variations. Concurrency groups are therefore useful for protecting deployment targets from overlapping automation.<\/span><\/p>\n<h3><b>Question 271<\/b><\/h3>\n<p><b>Which GitHub feature can automatically request reviews from designated teams?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CODEOWNERS<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Repository topics<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Release tags<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Project views<\/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;\">CODEOWNERS can designate users or teams as responsible for particular paths within a repository. When changes affect those paths, GitHub can automatically request reviews from the relevant owners, depending on repository configuration. This helps route pull requests to people familiar with the affected components. Repository topics categorize repositories, release tags identify versions, and project views organize work information. CODEOWNERS therefore provides path-based review assignment and ownership management.<\/span><\/p>\n<h3><b>Question 272<\/b><\/h3>\n<p><b>Which GitHub Actions feature exposes a completed job&#8217;s generated value to another job?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Step environment<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Workflow variable<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Job output<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Runner property<\/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 information produced during one job to become available to another job that depends on it. A producing job can map a step output to a job-level output, and a downstream job can access the value through the needs context. This pattern is useful for passing generated version identifiers, calculated deployment names, or other dynamic values between workflow stages. Step environment variables are generally scoped differently, workflow variables provide configuration, and runner properties describe execution infrastructure. Job outputs specifically support structured cross-job data transfer.<\/span><\/p>\n<h3><b>Question 273<\/b><\/h3>\n<p><b>Which GitHub feature allows a pull request to be merged only after required checks succeed?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Repository topics<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Protected branch rules<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Release notes<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Discussion categories<\/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;\">Protected branch rules can require specified status checks to pass before a pull request can be merged. This helps teams enforce automated validation for important branches. Required checks might include builds, tests, security analysis, or other repository workflows. Repository topics organize repository metadata, release notes describe published changes, and Discussion categories organize conversations. Protected branch rules therefore provide the governance mechanism for making successful automated validation a prerequisite for merging.<\/span><\/p>\n<h3><b>Question 274<\/b><\/h3>\n<p><b>Which GitHub Actions feature allows different jobs to share a downloaded artifact?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">upload-artifact<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">cache<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">download-artifact<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">setup-node<\/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 download-artifact action retrieves artifacts previously uploaded by a workflow. This is useful when one job produces a build output and another job needs that output for testing, packaging, deployment, or analysis. The producing job commonly uses upload-artifact first, while downstream jobs retrieve the stored files with download-artifact. Caching serves a different purpose by reusing data to improve workflow performance, and setup actions configure development environments. Artifact download therefore supports transferring preserved workflow outputs between execution stages.<\/span><\/p>\n<h3><b>Question 275<\/b><\/h3>\n<p><b>Which GitHub security feature detects vulnerable open-source dependencies?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Dependabot alerts<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Project automation<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">GitHub Wiki<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Release management<\/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;\">Dependabot alerts identify known vulnerabilities affecting dependencies used by a repository. GitHub uses dependency information and available vulnerability data to determine when installed packages may be affected. Maintainers can then investigate available updates or other mitigation options. Project automation manages work, GitHub Wiki supports documentation, and release management handles software version publication. Dependabot alerts therefore address dependency-related security exposure rather than general project organization or release administration.<\/span><\/p>\n<h3><b>Question 276<\/b><\/h3>\n<p><b>Which GitHub Actions setting allows a job to use a custom workspace directory?<\/b><\/p>\n<ol>\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;\">permissions<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">working-directory<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">retention-days<\/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 working-directory setting specifies the directory in which a run command executes. This is useful when a repository contains multiple applications or when commands need to operate from a particular project subdirectory. Setting a working directory can avoid repeatedly changing directories inside shell commands. shell determines the command interpreter, permissions controls token access, and retention-days controls artifact lifetime. The working-directory property therefore directly determines where commands operate within the runner&#8217;s workspace.<\/span><\/p>\n<h3><b>Question 277<\/b><\/h3>\n<p><b>Which GitHub capability allows a pull request to merge automatically after requirements are satisfied?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Auto-merge<\/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;\">Repository topics<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Wiki synchronization<\/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;\">GitHub auto-merge allows an eligible pull request to be merged automatically after configured requirements are satisfied. Depending on repository rules, these requirements can include approvals, status checks, and other merge conditions. This can reduce manual intervention for changes that have already passed the required review and validation process. Issue forms structure issue submissions, repository topics categorize repositories, and Wiki synchronization is unrelated to pull request merging. Auto-merge therefore focuses specifically on automating the final merge step.<\/span><\/p>\n<h3><b>Question 278<\/b><\/h3>\n<p><b>Which GitHub Actions feature allows workflow jobs to execute on self-hosted infrastructure?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">GitHub-hosted runner<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Self-hosted runner<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Release artifact<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Workflow template<\/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;\">Self-hosted runners are machines managed by an organization or repository owner that execute GitHub Actions jobs. They can be useful when workflows require specialized hardware, custom software, private network access, or other capabilities unavailable on standard GitHub-hosted runners. GitHub-hosted runners are managed by GitHub, release artifacts are generated files, and workflow templates provide reusable starting configurations. Self-hosted runners therefore provide organizations with greater control over the infrastructure used to execute automation.<\/span><\/p>\n<h3><b>Question 279<\/b><\/h3>\n<p><b>Which GitHub feature can organize issues by assigning descriptive categories?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Labels<\/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;\">Environments<\/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: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Labels provide a flexible way to categorize issues and pull requests. Teams can create labels representing areas such as priority, component, type of work, or workflow state. This makes it easier to filter and organize large numbers of work items. Release assets store downloadable files, environments support deployment controls, and repository secrets protect sensitive configuration values. Labels therefore provide the repository mechanism for applying descriptive classifications to individual issues and pull requests.<\/span><\/p>\n<h3><b>Question 280<\/b><\/h3>\n<p><b>Which GitHub Actions capability can execute a workflow automatically at scheduled times?<\/b><\/p>\n<ol>\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;\">repository_dispatch<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">schedule<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">workflow_run<\/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 schedule trigger allows GitHub Actions workflows to run automatically according to configured cron expressions. Scheduled workflows are useful for recurring maintenance, periodic security checks, synchronization tasks, report generation, or other automation that should occur independently of repository changes. workflow_call invokes reusable workflows, repository_dispatch responds to custom repository events, and workflow_run reacts to activity involving another workflow. The schedule event therefore provides time-based workflow execution without requiring a code push or manual launch.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full Microsoft GH-200 Exam Dumps and Practice Test Dumps &nbsp; Question 261 Which GitHub Actions feature allows a workflow to call an action by repository reference? environment strategy permissions uses Correct Answer: 4 Explanation: The uses keyword invokes an action identified by a repository reference and version or revision. This allows workflows to consume [&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\/18963"}],"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=18963"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/18963\/revisions"}],"predecessor-version":[{"id":18964,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/18963\/revisions\/18964"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=18963"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=18963"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=18963"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}