GH-200 GitHub Actions Certification braindump and exam dump

At scrumtuous.com a team runs GitHub Actions workflows that build and deploy to Google Cloud on Ubuntu, macOS, and Windows runners using both Bash and PowerShell. They want consistent behavior when referencing environment variables regardless of the shell or operating system. How should they handle environment variable names to avoid portability issues?

• ❏ A. Use only uppercase names for all environment variables

• ❏ B. Ignore casing because GitHub Actions resolves environment variables in a uniform way

• ❏ C. Treat environment variables as case sensitive in every workflow

• ❏ D. Defer to the operating system and shell behavior for how variables are matched

During a lengthy GitHub Actions pipeline at Northwind Labs you notice that the job output is difficult to scan and related messages are scattered across the log. You want to make the log easier to navigate by placing related messages inside a collapsible section with a clear title. Which workflow command should you use to achieve this?

• ❏ A. echo

• ❏ B. add-mask

• ❏ C. group

• ❏ D. stop-commands

A team at Alpine Outfitters uses GitHub Actions to deploy a service to Google Cloud Run and their workflow includes a job that contains several steps which invoke community actions and run shell commands. What do the job and its steps represent within the workflow?

• ❏ A. Manage repository owners and collaborator permissions

• ❏ B. Configure the events that start a workflow run

• ❏ C. Define a specific unit of work that runs an ordered series of steps that use actions and shell commands

• ❏ D. Provision Google Cloud resources for all jobs using gcloud commands defined at the workflow level

Priya at Blue Harbor Analytics is reviewing a failed GitHub Actions run and wants to locate a specific step in the workflow logs. Her search shows no matches even though the run finished. What could explain the empty search results? (Choose 2)

• ❏ A. Log search is unavailable until the ACTIONS_STEP_DEBUG setting is enabled

• ❏ B. The job steps are still collapsed so their output is not included in the search until the steps are expanded

• ❏ C. The organization exports workflow logs to Cloud Logging so the GitHub page search will not find them

• ❏ D. The search phrase is misspelled or the text never appears in the workflow logs

At Rivergate Robotics, the platform operations team funds 10 self hosted GitHub Actions runners through an internal chargeback process and needs to ensure that development and test workflows from other squads never run on those machines. Which GitHub Actions feature should they configure to restrict access to their self hosted runners?

• ❏ A. Environments

• ❏ B. Runner labels

• ❏ C. Runner groups

• ❏ D. Organization policies

The release team at scrumtuous.com needs to execute a packaging workflow on demand for urgent fixes during a 90 minute maintenance window and they want to start it from the Actions tab or the GitHub CLI or the REST API. Which GitHub Actions event should be configured in the workflow to allow this on demand execution?

• ❏ A. schedule

• ❏ B. workflow_dispatch

• ❏ C. push

• ❏ D. pull_request

At LumaTech your DevOps team built a reusable GitHub Action that automates deployment to Google Cloud Run and you want engineers at example.com to start using it with minimal friction. What is the main objective of writing a comprehensive README.md in the action’s repository so that new users can get productive quickly?

• ❏ A. Showcase the action with animated demos and screenshots for marketing

• ❏ B. Use the README as a troubleshooting catalog for edge cases and errors

• ❏ C. Provide comprehensive usage documentation so others can understand and adopt the action

• ❏ D. Turn the README into an interactive tutorial that runs commands

In a GitHub Actions workflow at Riverbend Robotics, you need job build to finish before job test begins so that artifacts are available. What is the primary function of declaring job dependencies?

• ❏ A. To set and enforce maximum concurrent runs across the entire workflow

• ❏ B. To evaluate complex conditions based on previous job results and expressions

• ❏ C. To define a specific run order so that one job waits for another to complete

• ❏ D. To enable jobs to execute in parallel without waiting on others

At mcnz.com your repository has a GitHub Actions workflow named Node CI that defines an environment variable APP_NAME at the workflow level with the value “Build Rocket” and the build job sets APP_NAME to “Build Rocket 8” and a step named Show name sets APP_NAME to “Build Rocket Final” and echoes $APP_NAME when a push occurs to the main branch, what value will be printed to the log?

• ❏ A. Build Rocket 8

• ❏ B. A syntax error occurs

• ❏ C. Build Rocket Final

• ❏ D. Build Rocket

HarborPeak Studios uses GitHub Actions to deploy a service to Google Cloud Run, and during a 48 hour release freeze the team wants to validate pipeline changes without impacting automatic runs. What is a key advantage of using manual triggers in this scenario?

• ❏ A. ensures runs are restricted to a single branch only

• ❏ B. enables safe validation and debugging in an isolated context

• ❏ C. reduces job duration by parallelizing every job automatically

• ❏ D. Cloud Scheduler

All exam question come from my GitHub Action Udemy course and certificationexams.pro

Riverbend Analytics uses a GitHub Actions Docker action to deploy a service to Cloud Run in GCP. While inspecting the container entry script named start.sh they find an if statement that when the condition is true writes “Log notice” and immediately issues exit 1. In the context of the workflow run what does this behavior indicate?

• ❏ A. The script only emits a warning for debugging and does not fail the job

• ❏ B. The step is marking a failure by printing a message and exiting with status code 1

• ❏ C. The action is finishing normally and returns exit code 0

• ❏ D. The workflow completed successfully while an optional step reported a soft error

Cedar Lane Analytics is setting up GitHub Actions for its repositories and the two person DevOps team wants the lowest ongoing effort and a monthly spend under 100 USD while avoiding custom hardware. Which type of runner should they choose to meet these goals?

• ❏ A. Self-hosted runners on company rack servers in their office

• ❏ B. Cloud Build

• ❏ C. GitHub-hosted runners

• ❏ D. Self-hosted runners on Compute Engine virtual machines in the company project

Mariner Tech runs a GitHub Actions workflow on Ubuntu latest that uses a matrix strategy with two dimensions named vehicle and tone. The vehicle list contains four values [car, bike, bus, van] and the tone list contains three values [light, medium, dark]. The single step prints “Hello ${{ matrix.tone }} ${{ matrix.vehicle }}” for each matrix pairing. How many jobs will this workflow execute?

• ❏ A. 7

• ❏ B. 12

• ❏ C. 6

• ❏ D. 4

A DevOps engineer at scrumtuous.com is creating a GitHub Actions integration that needs to send job statuses, outcomes, and log lines to appear on pull requests and commits. Which GitHub API should the integration use to report workflow results?

• ❏ A. Actions API

• ❏ B. Checks API

• ❏ C. Audit Log API

• ❏ D. Statuses API

PineLake Analytics is creating a GitHub Actions workflow that will call a marketplace action from another repository pinned to v3 and you are writing the step configuration. Which YAML key in the step specifies the action that the runner should invoke?

• ❏ A. run

• ❏ B. uses

• ❏ C. execute

• ❏ D. action

A DevOps engineer at Northwind Outfitters sets several inputs to required true in a GitHub Actions workflow that they start manually using workflow_dispatch. When they click the Run workflow button in the repository UI, what should they expect to occur?

• ❏ A. The workflow starts with no prompts and uses default values for inputs

• ❏ B. The run uses the inputs from the last manual dispatch automatically

• ❏ C. GitHub shows a form to enter the required inputs before the run can be started

• ❏ D. The workflow launches and returns an error only after a job step tries to read a missing value

NovaEdge Consulting maintains a private repository on GitHub and an engineer needs to start a workflow run by calling the GitHub REST API from an integration hosted on example.com. Which form of authentication should they include with the request to initiate the workflow?

• ❏ A. SSH key

• ❏ B. Username and password

• ❏ C. Personal access token

• ❏ D. API key

The platform team at mcnz.com has seen intermittent failures over the last 48 hours on a Linux self hosted runner in a private subnet, and they want to run a built in connectivity test to confirm it can reach all required GitHub network endpoints before scheduling more jobs, which parameter should they use with the runner executable to perform this validation?

• ❏ A. –diag

• ❏ B. –check

• ❏ C. –verify-connection

• ❏ D. –validate-network

Blue Meadow Labs plans to open source a reusable GitHub Action that multiple teams inside and outside the company will use across many repositories. Why is placing the action in its own repository recommended when making it publicly available?

• ❏ A. It eliminates the need for version control

• ❏ B. It limits the action’s visibility to the repository that hosts it

• ❏ C. It simplifies community contributions and maintenance by keeping the action versioned independently

• ❏ D. It adds overhead and makes management more complex

An engineering group at mcnz.com maintains a GitHub Actions workflow that calls a repository script during continuous integration and they want the job to run the script successfully. What should they do to ensure the runner treats the script as executable when the workflow runs?

• ❏ A. Use a special YAML key in the workflow to set the script as executable

• ❏ B. Add a workflow step that runs chmod +x on the script before executing it

• ❏ C. Cloud Build

• ❏ D. Reference the script path in the workflow and rely on the runner to handle permissions

All exam question come from my GitHub Action Udemy course and certificationexams.pro

A platform team at Orchid Analytics keeps workflow definitions under .github/workflows and accidentally pushes a malformed YAML workflow file to the default branch. They plan to continue committing changes over the next few days. What will GitHub Actions do after each new commit?

• ❏ A. Cloud Build

• ❏ B. GitHub automatically repairs the invalid YAML in the workflow file

• ❏ C. A failed workflow run is created for every subsequent commit

• ❏ D. GitHub Actions is turned off for the repository until the YAML is fixed

In a GitHub Actions workflow for a repository owned by Pinetree Labs that supports the mcnz.com site you store a helper shell script at scripts/backup_task.sh in the repository and you need the workflow to run that exact file on the runner without moving or duplicating it. How should you execute the script from the workflow?

• ❏ A. Embed the script content directly inside the workflow file

• ❏ B. Use Google Cloud Build to trigger the script from outside GitHub Actions

• ❏ C. Run the repository script by referencing its path with the run keyword

• ❏ D. Manually transfer the file to the runner and invoke it with a shell

Blue Oak Analytics runs self hosted GitHub Actions runners for its build pipelines and keeps reusable actions in private and internal repositories under its organization. You need to let the runners retrieve these actions with least privilege and short lived credentials and without any interactive user sign in. Which GitHub mechanism enables this controlled access for the runners to download the actions?

• ❏ A. GitHub generates a personal access token with repository read scope that remains valid for 60 minutes

• ❏ B. GitHub issues a scoped installation token with repository read permission that automatically expires after 60 minutes

• ❏ C. GitHub asks users to authenticate with their GitHub credentials whenever an action download occurs

• ❏ D. GitHub grants the runner direct repository access for the full length of the workflow run

At scrumtuous.com the DevOps team wants certain GitHub Actions workflow artifacts to be kept for 45 days while others should use the default retention. What is the proper way to apply a custom retention period for specific artifacts in a workflow?

• ❏ A. Enable a repository artifact retention policy that automatically applies to every artifact

• ❏ B. Configure artifact retention only at the organization or enterprise level

• ❏ C. Set a retention days value on each artifact in the workflow step that uses actions/upload-artifact

• ❏ D. Store artifacts in a Google Cloud Storage bucket with a lifecycle rule

You are contributing to a teammate’s personal GitHub repository that runs a GitHub Actions workflow for deploying to Google Cloud, and you find that you cannot create the needed repository secret because you do not have sufficient permissions. What should you do to proceed so the workflow can use the secret?

• ❏ A. Open a ticket with GitHub support to request elevated permissions to manage secrets on the repository

• ❏ B. Fork the repository to your own account and define the secret in the fork

• ❏ C. Ask the repository owner to add the secret in repository settings or grant you admin rights

• ❏ D. Create the value in Google Secret Manager and expect GitHub Actions to read it automatically without a repository secret

At Zeno Labs you maintain a custom GitHub Action. The action metadata declares two inputs. One input named instance-count has description “Number of instances”, is not required, and has a default of “5”. The other input named cluster-region has description “Region for the cluster” and is required. How many inputs are required in this action metadata?

• ❏ A. 2

• ❏ B. 1

• ❏ C. 3

• ❏ D. 0

The engineering team at Northwind Bikes manages CI for repositories under mcnz.com and they are defining a workflow that contains several jobs. They want to be clear about what a step means inside a GitHub Actions job. Which description best matches a step?

• ❏ A. Steps describe the global execution lifecycle of actions across all jobs

• ❏ B. Steps are discrete commands or actions that run in order within a single job

• ❏ C. Steps are used to publish integrations to GitHub Marketplace

• ❏ D. Steps are identical to an entire workflow and refer to the same scope

Your team at Orchid Labs is setting up GitHub Actions to automate builds and releases for the customer portal hosted at scrumtuous.com. In which directory within the repository should you place the workflow definition files so that GitHub can automatically find and run them?

• ❏ A. .github/actions

• ❏ B. scripts/ci

• ❏ C. .github/workflows

• ❏ D. .github/pipelines

At Northwind Games the CI team is standardizing their pipelines with GitHub Actions. In discussions about actions, workflows, jobs, steps, and runs, what is the primary function of the GitHub Marketplace?

• ❏ A. Managing and designing the overall workflow structure

• ❏ B. Hosting and sharing reusable actions with the broader community

• ❏ C. Monitoring live progress and metrics for individual jobs and runs

• ❏ D. Cloud Build

A platform team at Bright Harbor Labs is rolling out new CI workflows with GitHub Actions and wants to confirm how the default environment variables behave during a run. Which statements correctly describe these default variables? (Choose 3)

• ❏ A. Default environment variables must be referenced using the ${{ variable.property }} expression syntax

• ❏ B. Default environment variables use uppercase names only

• ❏ C. Default environment variables cannot be read through the env context

• ❏ D. Default environment variables are available to every step in the workflow

At CedarTech Solutions you must safeguard a production database password that is consumed by GitHub Actions workflows in six internal repositories. As an organization owner, what is the most secure way to define the secret so that only those specific repositories can access it?

• ❏ A. Create a repository environment secret in every repository and control access with required reviewers

• ❏ B. Create an organization secret and restrict it to selected repositories using a policy

• ❏ C. Store the password in each workflow file to keep configuration simple

• ❏ D. Google Secret Manager

At Cedar Coast Labs your team uses GitHub Actions to roll out updates to a production environment for a service running on Google Cloud Run. You want to enforce stricter governance so only vetted changes from allowed branches deploy and approvals follow separation of duties. Which environment deployment protections should you configure? (Choose 3)

• ❏ A. Enforce that all required status checks on the default branch pass before deployment

• ❏ B. Restrict deployments to specific branches such as main and release

• ❏ C. Require approval from designated reviewers before a deployment runs

• ❏ D. Block self approval when the deployment requester authored the change

At Lumenic Studios your team maintains a private repository called toolkit-actions that stores reusable GitHub Actions and workflow templates used across five internal engineering groups. You want specific teams inside your company to reuse these items without exposing the repository publicly and you also want to avoid duplicating code across many projects. What should you do?

• ❏ A. Use a public repository to host the actions and restrict access with branch protection

• ❏ B. Copy the action and workflow files into each consumer repository and reference them locally

• ❏ C. Grant selected repositories or organizations access to the private repository that hosts the actions and reusable workflows

• ❏ D. Package the actions as Docker images in a private container registry and pull them from workflows

An engineering team at mcnz.com wants a GitHub Actions workflow to run whenever a third party app reports a new check run or when that run finishes. Which trigger configuration should they define so that the workflow listens for check_run events that include both creation and completion?

• ❏ A. Use check_suite with types requested and completed

• ❏ B. Use check_run with types created and completed

• ❏ C. Google Cloud Build

• ❏ D. Use check_run with type started only

During a deployment workflow for a repository owned by scrumtuous.com your team needs to make a step conditional based on the operating system of the GitHub Actions runner that is executing the job, so which default environment variable provides the runner’s operating system value?

• ❏ A. RUNNER_ARCH

• ❏ B. GITHUB_RUNNER_OS

• ❏ C. RUNNER_OS

• ❏ D. RUNNER_DEBUG

The correct option is Treat environment variables as case sensitive in every workflow. This gives the team consistent results across Ubuntu, macOS, and Windows and across Bash and PowerShell because every reference must match the defined name exactly.

This approach is right because Linux and macOS treat variable names as case sensitive while Windows does not. GitHub Actions does not normalize the casing for you, so the only portable practice is to pick one casing and use it consistently. If you define MY_VAR then you must always reference MY_VAR. Using my_var or My_Var may work on Windows but it will fail on Linux and macOS.

Use only uppercase names for all environment variables is incorrect because choosing uppercase is only a convention. It does not prevent bugs if you later reference the variable with a different case. Exact case matching is what ensures portability.

Ignore casing because GitHub Actions resolves environment variables in a uniform way is incorrect because Actions does not unify case behavior across runners. Ignoring case will cause subtle failures on Linux and macOS.

Defer to the operating system and shell behavior for how variables are matched is incorrect because that produces different results across platforms. The goal is consistent cross runner behavior, so you should enforce exact case matching in your workflows.

When a question mentions multiple operating systems or shells, assume differences in case handling. Choose one exact casing for each variable and use it consistently everywhere.

The correct option is group because it creates a collapsible log section with a clear title in GitHub Actions.

This command lets you start a titled section in the job log and then close it with a matching end command. Everything emitted between the start and end is grouped under that title which makes long logs much easier to navigate and keeps related messages together.

The echo option only prints text to standard output and does not create collapsible sections by itself. In practice you often use echo to emit workflow commands, yet the command that enables grouping is group rather than echo.

The add-mask option is used to hide sensitive values in logs and it does not organize output into collapsible groups.

The stop-commands option temporarily disables and later re enables workflow command processing and it does not create titled or collapsible sections in logs.

When a question mentions collapsible or titled log sections, map it to the workflow command that creates groups. Remember that add-mask is for secrets and stop-commands is for toggling command parsing, not for organizing logs.

The correct option is Define a specific unit of work that runs an ordered series of steps that use actions and shell commands.

In GitHub Actions a job is a discrete unit of work that runs on a runner. Within a job, steps execute in order and each step can call a community action or run a shell command. This is exactly what happens when a deployment job invokes marketplace actions and executes gcloud commands to deploy to Cloud Run.

Manage repository owners and collaborator permissions is incorrect because it concerns repository access and roles, which are administrative settings and not what a workflow job and its steps represent.

Configure the events that start a workflow run is incorrect because events are workflow triggers defined at the workflow level, while jobs and steps describe what runs after a workflow has been triggered.

Provision Google Cloud resources for all jobs using gcloud commands defined at the workflow level is incorrect because commands run within steps inside specific jobs, and there is no automatic provisioning performed for all jobs from a workflow level command block.

When a scenario mentions steps that run marketplace actions and shell commands, map that to what a job is and does. If the prompt talks about triggers or permissions then it is likely referring to workflow configuration or repository settings instead.

The correct options are The job steps are still collapsed so their output is not included in the search until the steps are expanded and The search phrase is misspelled or the text never appears in the workflow logs.

When steps in a job remain collapsed their output is hidden and the log viewer search works on the visible expanded content. Expanding the relevant steps or using Expand all makes that output visible which allows the search to return matches in those sections.

If the exact text is not present or is spelled differently then the search will return no matches. Verifying the phrase and trying variations or broader keywords can reveal the right lines in the logs.

Log search is unavailable until the ACTIONS_STEP_DEBUG setting is enabled is incorrect because the workflow run page includes a log search field by default. Enabling debug logging only increases verbosity and does not control the availability of search.

The organization exports workflow logs to Cloud Logging so the GitHub page search will not find them is incorrect because workflow run logs are accessible and searchable in GitHub while they are retained. External export or archiving does not remove the ability to search an available run log in the GitHub UI.

Scan the question for UI behavior cues such as collapsed sections and whether the text should exist at all. If search is empty think about visibility and exact content first before assuming configuration problems.

The correct option is Runner groups because it lets you restrict which repositories can use specific self hosted runners, which ensures that workflows from other squads cannot target those machines.

With this feature you can place the ten self hosted runners into a group that is visible only to the platform operations repositories. You can then allow only selected repositories to use that group while all others are denied by default. This directly enforces your internal chargeback boundary and keeps development and test workflows from other squads off those runners.

Environments control approvals, secrets, and protection rules for deployments, and they do not determine which runners a job can run on. They are not designed to block other repositories from using your self hosted machines.

Runner labels help route jobs to eligible runners by matching labels, yet they do not enforce access boundaries. If a repository can see a runner then matching a label can still target it, so labels alone cannot prevent other squads from using your runners.

Organization policies let administrators enable or restrict GitHub Actions usage and control which actions are allowed, but they do not provide per runner access controls that limit which repositories can use a specific set of self hosted runners.

When a scenario asks you to restrict which repositories can use self hosted runners, look for the feature that sets visibility to selected repositories. Prefer solutions that mention groups over routing features like labels or deployment controls like environments.

The correct option is workflow_dispatch because it allows manual on demand runs from the Actions tab and it can also be triggered through the GitHub CLI and the REST API.

With this manual dispatch event you can start the workflow precisely during the 90 minute maintenance window and you can pass inputs if needed. The Actions tab provides a Run workflow button when this event is configured and the GitHub CLI and the REST API both invoke the same dispatch to start the run on demand.

schedule is time based and runs on a cron expression and it cannot be started immediately from the Actions tab or by direct calls through the GitHub CLI or the REST API.

push runs when commits are pushed to the repository and it is not a manual trigger from the Actions tab and it is not directly invokable through the GitHub CLI or the REST API without a commit.

pull_request runs on pull request activity such as opening or updating a pull request and it is not intended for ad hoc manual runs from the Actions tab or from external calls.

When you see requirements to run a workflow on demand from the Actions tab or through the CLI or REST API, map that to the manual dispatch trigger and confirm the question hints align with workflow_dispatch.

The correct option is Provide comprehensive usage documentation so others can understand and adopt the action. A clear README accelerates onboarding because new users can see how to configure and run the action without guesswork.

A strong README explains the purpose of the action and when to use it. It shows how to set up prerequisites such as authentication and required permissions. It documents inputs and outputs with defaults so engineers can configure it confidently. It includes a quick start snippet and a realistic example that covers common parameters. It explains versioning and pinning so teams can reference a stable release. It also calls out any Google Cloud Run specific steps and required secrets so users avoid trial and error.

Showcase the action with animated demos and screenshots for marketing is not the main objective for helping engineers get productive. Visuals can be helpful for context yet they do not replace clear usage instructions that enable adoption.

Use the README as a troubleshooting catalog for edge cases and errors is not the priority because an exhaustive catalog can bury essential getting started content. It is better to keep the README focused on first use and place detailed troubleshooting in a separate section or document.

Turn the README into an interactive tutorial that runs commands is not feasible because a README is static Markdown. You can include commands for users to copy and run but the file itself cannot execute anything.

When a question asks for documentation priorities choose the option that enables a new user to achieve a first successful run. Look for words like usage, examples, inputs, and permissions that signal onboarding focus.

The correct option is To define a specific run order so that one job waits for another to complete. This ensures that the build job can finish and publish artifacts before the test job begins so the artifacts are available when tests run.

In GitHub Actions you declare a dependency by using the needs key on the dependent job. When the test job needs the build job the runner schedules the test only after the build has completed which creates a clear execution order and enforces waiting. This is the primary mechanism for orchestrating multi job workflows where outputs and artifacts must flow from one job to another.

To set and enforce maximum concurrent runs across the entire workflow is not what job dependencies do. Limiting concurrency for a workflow or for a job is handled by the concurrency key which groups runs and cancels or queues them and it is unrelated to needs based dependencies.

To evaluate complex conditions based on previous job results and expressions is not the primary role of dependencies. You can reference the needs context in if expressions to make conditional decisions about running a job or a step yet the dependency itself simply defines which job must complete first.

To enable jobs to execute in parallel without waiting on others is the opposite of what a dependency does. Jobs without a dependency run in parallel by default whereas declaring a dependency makes the next job wait.

When a question emphasizes that one job must wait or must finish before another starts think of the needs key which sets run order rather than concurrency or expression features.

The correct option is Build Rocket Final.

In GitHub Actions, environment variables can be set at the workflow level, the job level, or the step level, and the most specific scope takes precedence. Because the Show name step sets APP_NAME to Build Rocket Final and the echo runs in that step, the step value overrides both the job and workflow values and the log prints Build Rocket Final.

The option Build Rocket 8 is incorrect because a job level value would only be used if the step did not set its own value.

The option A syntax error occurs is incorrect because the workflow uses valid environment variable definitions and echoing an environment variable in a step is supported.

The option Build Rocket is incorrect because a workflow level value is overridden by a job level value and by a step level value.

When multiple scopes define the same variable, remember that the step value overrides the job value which overrides the workflow value, and confirm which scope the command runs in.

The correct option is enables safe validation and debugging in an isolated context.

Manual triggers in GitHub Actions allow the team to start a workflow only when they choose to run it. This keeps the workflow isolated from automatic events during the release freeze so pipeline changes can be tested without impacting routine runs or deployments. The team can supply inputs, inspect logs and artifacts, and iterate safely while production automation remains paused.

ensures runs are restricted to a single branch only is incorrect because manual triggers do not inherently limit execution to a single branch. Branch scoping is controlled by event filters or conditional logic, not by the manual nature of the trigger itself.

reduces job duration by parallelizing every job automatically is incorrect because manual triggers do not change how jobs are parallelized. Parallelism and execution strategy are defined in the workflow configuration through matrices or separate jobs and are never enabled automatically by choosing a manual trigger.

Cloud Scheduler is incorrect because it is a Google Cloud service for scheduled tasks and it does not provide manual GitHub Actions triggers. It is not the right tool for validating GitHub workflows during a freeze without affecting automatic runs.

When a scenario involves a release freeze, prefer answers that emphasize manual execution and isolation such as GitHub Actions workflow_dispatch, and avoid choices that change performance characteristics or branch scope.

All exam question come from my GitHub Action Udemy course and certificationexams.pro

The correct option is The step is marking a failure by printing a message and exiting with status code 1.

In GitHub Actions a container action or shell step that exits with a nonzero status code is considered a failure. When the entry script issues exit 1 it signals an error condition so the step fails and the job fails as well unless the step is explicitly configured to continue on error. Printing a notice before exiting does not alter the failure signal because the exit code is what determines success or failure.

The script only emits a warning for debugging and does not fail the job is incorrect because exit 1 is a nonzero status that fails the step rather than only issuing a warning.

The action is finishing normally and returns exit code 0 is incorrect because the script ends with exit 1 which is not a successful status.

The workflow completed successfully while an optional step reported a soft error is incorrect because that behavior requires continue on error to be set on the step. Without that setting a nonzero exit code causes the step and job to fail.

When you see a script call exit 1 or any nonzero exit code it indicates failure in GitHub Actions unless the step uses continue-on-error. Scan the step configuration for that setting to decide whether the job fails or continues.

The correct option is GitHub-hosted runners.

GitHub-hosted runners are fully managed by GitHub and they automatically provision clean virtual machines for each job which keeps ongoing effort very low. There is no custom hardware to buy or maintain and scaling happens automatically so a small two person team can focus on workflows rather than servers.

Billing for GitHub Actions is usage based and you can set limits and review consumption which helps keep the monthly spend under 100 USD for small teams. Public repositories include free minutes and private repositories receive included minutes on many plans which further reduces cost risk for light to moderate usage.

Self-hosted runners on company rack servers in their office are incorrect because they require purchasing and maintaining physical hardware and they add significant ongoing administration which violates the goal of low effort and avoiding custom hardware.

Cloud Build is incorrect because it is a separate Google Cloud CI service rather than a runner type for GitHub Actions so choosing it would not satisfy the requirement to select a runner for GitHub Actions.

Self-hosted runners on Compute Engine virtual machines in the company project are incorrect because they still require you to manage provisioning patching scaling and security of the virtual machines which increases ongoing effort and can lead to unpredictable costs compared with the managed model.

When a scenario stresses low effort and no hardware with a tight budget lean toward the fully managed runner option. Map requirements to who manages infrastructure and how costs scale with usage.

The correct option is 12.

With a matrix that lists four vehicles and three tones, GitHub Actions forms the Cartesian product of those lists. It creates one job for every unique vehicle and tone pairing, so the total jobs equal four times three. The operating system choice and the fact that there is only one step do not change the number of jobs created by the matrix.

7 is incorrect because the total number of jobs is not the sum of the list lengths. The matrix multiplies the counts from each dimension.

6 is incorrect because it undercounts the combinations. The workflow uses four vehicles and three tones, which yields more than six jobs.

4 is incorrect because it counts only one dimension and ignores the other. The matrix runs a job for every pairing of vehicle and tone.

When you see a matrix in a GitHub Actions question, compute the job count as the product of the lengths of each dimension. Features like the runner image or the number of steps do not change that product.

The correct option is Checks API.

The Checks API is designed for integrations to create and update check runs that are attached to specific commits, which makes their results visible on pull requests and commit pages. It supports in depth reporting through statuses like queued, in progress, and completed, as well as conclusions and rich output that includes titles, summaries, text, and annotations. This lets an integration surface job outcomes and log details directly in the pull request Checks tab and in the commit UI.

Actions API is not appropriate for this need because it focuses on managing workflow runs, jobs, and artifacts. It does not provide a way to author check runs or annotate commits so it cannot directly publish detailed check results to pull requests.

Audit Log API records organization and enterprise events for security and compliance. It does not publish build or test results to commits or pull requests and therefore does not meet the requirement.

Statuses API only sets a simple state on a commit such as pending, success, or failure with an optional description and link. It does not support rich summaries, annotations, or detailed log content, so it cannot deliver the level of information described in the prompt.

When a question mentions results that must show on pull requests with annotations or detailed logs, map that to the Checks API. Simple pass or fail on a commit usually points to the older statuses feature instead.

The correct option is uses which is the step key that tells the runner which marketplace action to invoke such as owner or repo at v3 when you pin to the v3 release.

With uses you specify the action by owner and repository and a version or ref like actions or checkout at v3 and the runner will download and execute that action in the step. This is the standard way to call actions from the marketplace and pinning to a version such as v3 is recommended for stability.

run is not correct because it executes inline shell commands in the job rather than invoking an action from another repository. It does not accept the owner and repository at version format.

execute is not correct because it is not a valid step key in GitHub Actions workflow syntax.

action is not correct because it is not a recognized step key and does not instruct the runner to call an action.

When a step calls an external action look for uses with an owner and repository at a version. When a step runs shell commands look for run.

The correct option is GitHub shows a form to enter the required inputs before the run can be started.

When a workflow is triggered with workflow dispatch and its inputs are marked as required true, the Run workflow action opens a form that displays those inputs. The run cannot begin until the user provides values for all required fields. If defaults are defined then they may appear prefilled in the form, yet the user still sees the prompt and must confirm or adjust the values before starting the run.

The workflow starts with no prompts and uses default values for inputs is incorrect because required inputs cause the interface to display a form and the run cannot start without values. Even when defaults exist, the prompt still appears and must be confirmed.

The run uses the inputs from the last manual dispatch automatically is incorrect because GitHub does not automatically reuse previous input values for a new manual run and it requires explicit entry or acceptance of defaults each time.

The workflow launches and returns an error only after a job step tries to read a missing value is incorrect because required input validation happens before the run begins and missing values block the run in the interface and through the API.

Scan the prompt for the words workflow_dispatch and required true and remember that the user is prompted to provide values before the run starts rather than failing later in a job.

The correct option is Personal access token.

Calling the GitHub REST API to start a workflow in a private repository requires token based authentication. A Personal access token can be sent in the Authorization header and must include the repo and workflow permissions so the integration on example.com can invoke the workflow dispatch endpoint securely.

SSH key is only used for Git operations over SSH and it cannot authenticate HTTP requests to the REST API, so it cannot start a workflow run.

Username and password is no longer supported for API authentication and this method was removed in favor of token based authentication, which makes it unlikely to appear as correct on newer exams.

API key is not a GitHub authentication method for the REST API. GitHub expects a token such as a Personal access token for this scenario.

When the scenario involves the GitHub REST API and a private repository, look for a token with the right scopes. If you see passwords or SSH, eliminate them and favor a token that includes workflow and repo permissions.

The correct option is –check.

–check runs the runner�s built in network connectivity test so you can confirm that a Linux self hosted runner in a private subnet can reach the required GitHub endpoints before scheduling more jobs. This parameter exercises outbound connectivity and validates access to key services such as the GitHub API and the Actions service, and it reports clear pass or fail results without starting a job. It is the intended and documented way to verify networking from the runner host.

–diag is not a supported runner parameter. While diagnostics and debug logs exist, this specific flag is not recognized by the runner executable for network validation.

–verify-connection is not a valid runner option and it does not correspond to any built in connectivity test, so it will not perform the required checks.

–validate-network is not an option provided by the runner, therefore it cannot be used to test reachability to GitHub endpoints.

When a question focuses on a built in validation, look for the exact flag name that appears in official docs and favor concise verbs like check over longer invented options.

The correct option is It simplifies community contributions and maintenance by keeping the action versioned independently.

This choice decouples the action from any single project which lets you manage its lifecycle with tags and releases and accept contributions without affecting downstream repositories. Consumers can reference a stable tag such as v1 or a commit SHA which provides predictability and safer upgrades across many repositories. It also centralizes issues, documentation and continuous integration for the action which makes maintenance easier for both internal teams and the community.

It eliminates the need for version control is incorrect because actions rely on Git for history and collaboration and publishing one for broad reuse increases the importance of tagging releases so users can pin exact versions.

It limits the action’s visibility to the repository that hosts it is incorrect because a dedicated public repository increases discoverability and allows any workflow in any repository to reference it.

It adds overhead and makes management more complex is incorrect because isolating the action in its own repository actually reduces coupling and simplifies ownership, reviews, releases and support at scale.

When you see a question about sharing a GitHub Action across many repositories, favor answers that mention independent versioning, tags or releases, and easier community contributions. Be wary of claims that remove version control or restrict visibility.

The correct option is Add a workflow step that runs chmod +x on the script before executing it.

Unix like runners require the executable permission bit for a script to run as a program. Although Git can track the execute bit in the repository, it is common for a file to be missing that bit when checked in or when created during the job. Adding an explicit step in the workflow to grant execute permission guarantees that the script will be runnable at job time on any runner and avoids permission denied errors.

Use a special YAML key in the workflow to set the script as executable is incorrect because the workflow syntax does not include a key to change file permissions. You must set permissions within a run step or commit the executable bit in the repository.

Cloud Build is incorrect because it is a separate Google service that is not part of GitHub Actions and it does not affect how a GitHub Actions runner handles file permissions.

Reference the script path in the workflow and rely on the runner to handle permissions is incorrect because runners do not automatically mark files as executable. Without the execute bit the step will fail with a permission error.

When a question involves running scripts in CI, look for answers that explicitly set the executable bit such as adding a step that runs chmod +x. Be cautious of choices that assume the platform will fix permissions or that introduce unrelated services.

All exam question come from my GitHub Action Udemy course and certificationexams.pro

The correct option is A failed workflow run is created for every subsequent commit.

Each push to the default branch triggers the workflow, and GitHub validates the workflow file before running any jobs. When the YAML is malformed, GitHub still creates a run for the triggering event and immediately marks it as failed due to the configuration error. This repeats after every new commit until the YAML is fixed.

Cloud Build is unrelated to GitHub Actions and does not control workflow behavior in a GitHub repository.

GitHub automatically repairs the invalid YAML in the workflow file is incorrect because GitHub does not modify your repository contents and it only reports validation errors.

GitHub Actions is turned off for the repository until the YAML is fixed is incorrect because Actions remains enabled and other valid workflows continue to run, while the invalid one produces failed runs on each triggering event.

When you see invalid YAML in a workflow, expect a new failed run on every triggering event and check the Actions tab for the validation error message.

The correct option is Run the repository script by referencing its path with the run keyword.

In GitHub Actions a step that uses the run key executes commands on the runner from the checked out repository. Once the workflow checks out the code the runner has the scripts directory available and you can call the script by its path. You can invoke the file with a shell such as bash followed by the path or ensure it is executable and call it directly. This uses the single source of truth in the repository and meets the requirement to run that exact file without moving or duplicating it.

Make sure your workflow includes a checkout step so the repository content exists on the runner before the run step executes. With the repository present the path scripts/backup_task.sh is resolvable and the command runs as intended.

Embed the script content directly inside the workflow file is incorrect because it duplicates the script and creates drift between the workflow and the repository file. The requirement is to run the existing file without copying it.

Use Google Cloud Build to trigger the script from outside GitHub Actions is incorrect because the task belongs inside the GitHub Actions workflow and introducing an external service adds complexity without benefit. It also does not guarantee that the runner executes the exact repository file by path.

Manually transfer the file to the runner and invoke it with a shell is incorrect because the standard checkout step already places repository files on the runner. Extra transfer steps are unnecessary and increase the chance of errors.

When you see a requirement to run an existing repository file think of the run step plus a repository path and confirm the workflow uses checkout so the file is present on the runner.

The correct option is GitHub issues a scoped installation token with repository read permission that automatically expires after 60 minutes.

This mechanism relies on a GitHub App that issues a token with repository read permission that is limited to exactly what is needed. The token is short lived which reduces risk and it is issued automatically by GitHub to the workflow so no user must sign in. This satisfies least privilege while allowing self hosted runners to download actions from private and internal repositories in the organization.

GitHub generates a personal access token with repository read scope that remains valid for 60 minutes is incorrect because personal access tokens are user scoped and are not automatically minted per workflow for fetching actions. They generally require manual management and do not align with automated least privilege for each action download.

GitHub asks users to authenticate with their GitHub credentials whenever an action download occurs is incorrect because GitHub Actions is noninteractive and does not prompt users during a run. Tokens are generated automatically so no user sign in is needed.

GitHub grants the runner direct repository access for the full length of the workflow run is incorrect because GitHub does not grant broad repository access to the runner. Instead GitHub provides a narrowly scoped and time limited token for downloading only what is required.

When you see hints like least privilege, short lived, and no interactive sign in, prefer mechanisms that are automatically issued by GitHub such as GitHub App installation tokens rather than user owned personal access tokens.

The correct option is Set a retention days value on each artifact in the workflow step that uses actions/upload-artifact.

This works because the upload step accepts an input that sets the number of days to keep a specific artifact. You can set it to 45 for the artifacts that need longer retention and omit it for others so they use the default. This approach overrides the repository or organization default only for the artifacts you choose and leaves the rest unchanged.

Enable a repository artifact retention policy that automatically applies to every artifact is incorrect because a repository setting establishes a single default for all artifacts and does not selectively target individual artifacts in a workflow. You would still need a per artifact override in the upload step to meet the requirement.

Configure artifact retention only at the organization or enterprise level is incorrect because those settings set defaults for repositories and do not provide per artifact granularity. Per artifact control is done in the upload step within the workflow.

Store artifacts in a Google Cloud Storage bucket with a lifecycle rule is incorrect because that moves storage outside GitHub Actions artifact management and does not control the retention of GitHub Actions artifacts in GitHub.

Identify whether the question needs a default policy or a per item override. If it asks to keep only some artifacts longer, look for an option that sets retention in the upload step rather than a global setting.

The correct option is Ask the repository owner to add the secret in repository settings or grant you admin rights.

Only users with admin access to a repository can create or manage repository secrets that GitHub Actions uses. In a personal repository the owner has admin access and collaborators typically do not. The most direct way forward is to have the owner create the secret or elevate your access so you can add it.

Open a ticket with GitHub support to request elevated permissions to manage secrets on the repository is incorrect because GitHub Support cannot change repository permissions for a personal repository and only the owner can grant admin rights or create secrets.

Fork the repository to your own account and define the secret in the fork is incorrect because secrets are scoped to each repository and the upstream workflow will not use secrets defined only in your fork. In addition, secrets are not exposed to workflows triggered from forks by default which makes this ineffective for deploying from the original repository.

Create the value in Google Secret Manager and expect GitHub Actions to read it automatically without a repository secret is incorrect because GitHub Actions does not automatically pull secrets from external providers. You would need explicit authentication and workflow steps to fetch them which still requires proper configuration rather than relying on automatic access.

When a question involves repository secrets, confirm who has admin rights. If you do not, look for answers that involve the repository owner performing the action rather than workarounds.

The correct option is 1. Only the cluster-region input is declared as required while instance-count is optional because it is not required and it has a default value of 5.

In GitHub Action metadata an input is considered required only when the required field is set to true. If an input has a default value and is not marked as required then workflows can omit it which confirms it does not count toward the required total.

2 is incorrect because there is not a pair of required inputs. Only the cluster-region input is required.

3 is incorrect because there are not three inputs in total and only one is required.

0 is incorrect because at least one input is required which is cluster-region.

When counting required inputs check the metadata for the required field and remember that the presence of a default usually means the input is optional.

The correct option is Steps are discrete commands or actions that run in order within a single job.

This is correct because a step is the smallest unit of execution inside a job. Steps run sequentially on the same runner so they share the job environment and can pass data through files and outputs. A step can either invoke an action or run a shell command, and features like conditional execution and environment variables are defined at the step level within the job.

Steps describe the global execution lifecycle of actions across all jobs is incorrect because steps are scoped to a single job. The global lifecycle is defined by the workflow and the jobs it contains, and cross job ordering is controlled by job dependencies.

Steps are used to publish integrations to GitHub Marketplace is incorrect because publishing to Marketplace is about packaging and releasing actions in a repository. Steps are simply how you execute actions or commands within a job and they are not a publishing mechanism.

Steps are identical to an entire workflow and refer to the same scope is incorrect because a workflow is the top level automation that contains one or more jobs. Steps are a smaller unit that exist only inside a single job and do not share the same scope as a workflow.

Map the scopes in your mind. Workflows contain jobs and a job contains ordered steps. If the description emphasizes sequential execution within one job then it points to steps.

The correct option is .github/workflows.

GitHub Actions discovers workflow YAML files only when they are stored in the workflows directory under the .github folder in the repository. Placing your workflow files in this location ensures GitHub automatically loads and runs them on the configured events.

.github/actions is not the location for workflow definitions. It is commonly used to store reusable custom actions that workflows can call, and files placed there are not automatically executed as workflows.

scripts/ci is a conventional directory for project scripts and GitHub does not scan it for workflows, so files there will not run as workflows.

.github/pipelines is not a recognized directory in GitHub Actions and GitHub does not use a pipelines folder for workflow discovery.

When a question asks where GitHub Actions workflows live, look for the exact documented path and remember that .github/workflows is the only location GitHub scans automatically. Treat other plausible paths as distractors.

The correct option is Hosting and sharing reusable actions with the broader community.

GitHub Marketplace exists to let maintainers and vendors publish Actions that others can discover, install, and reuse across their workflows. It provides versioned releases, examples, and search so teams can adopt proven automation components rather than building everything from scratch.

Managing and designing the overall workflow structure is not what the Marketplace does. Workflow structure is defined in YAML files in the repository and is managed in the Actions configuration rather than through the Marketplace catalog.

Monitoring live progress and metrics for individual jobs and runs is handled in the Actions run views and logs within the repository and not in the Marketplace which is a discovery and distribution hub.

Cloud Build refers to a separate build service that is not part of GitHub Actions or the GitHub Marketplace and therefore it does not describe the Marketplace function.

Match the service to its scope. Marketplace is about discovering and sharing actions and reusable workflows while workflow design lives in YAML in the repo and run monitoring lives in the Actions tab.

The correct statements are Default environment variables use uppercase names only, Default environment variables cannot be read through the env context, and Default environment variables are available to every step in the workflow.

GitHub Actions sets many built in environment variables such as GITHUB_REPOSITORY, GITHUB_REF, and GITHUB_SHA. These are provided in all caps by the runner, which is why they are consistently uppercase.

The env context exposes variables that you explicitly define in the workflow, job, or step, or that you write to the environment file during a run. The built in defaults are not part of that context, so you do not read them through env. You access them directly in the shell for the runner, for example with $GITHUB_REF in bash or $env:GITHUB_REF in PowerShell, or you use the github context in expressions when you need similar values.

The runner injects these defaults for each job, and every step in that job inherits them. This makes them available throughout the workflow steps, although some values can vary by step or job when they are intended to reflect step specific details.

Default environment variables must be referenced using the ${{ variable.property }} expression syntax is incorrect because they are ordinary environment variables in the runner process rather than values in a variables context. In expressions you typically use other contexts such as github for repository and ref information, or you expose your own values through env if needed.

When you see mentions of contexts, confirm whether the value comes from a context or from a default environment variable. Defaults are read directly in the shell while contexts are accessed in expressions.

All exam question come from my GitHub Action Udemy course and certificationexams.pro

The correct option is Create an organization secret and restrict it to selected repositories using a policy.

An organization secret lives at the organization level and can be scoped to selected repositories so you define the password once and only the six internal repositories can read it. This follows least privilege and gives centralized management for rotation and auditing. As an organization owner you can grant and revoke repository access to the organization secret without touching each repository.

Create a repository environment secret in every repository and control access with required reviewers is not the most secure or manageable choice because environment secrets exist only within a single repository. This forces duplication of the same secret across six repositories which increases exposure and complicates rotation, and required reviewers approve deployments rather than providing centralized secret governance.

Store the password in each workflow file to keep configuration simple is insecure because secrets must never be committed to source control. They would be exposed in repository history and forks and would be difficult to rotate safely.

Google Secret Manager is not the best answer for this question because it asks how an organization owner should define the secret in GitHub so that only selected repositories can access it. While external managers can be integrated with additional configuration, that approach is not a native GitHub control that cleanly scopes access to specific repositories inside the organization.

When you see many repositories and a need for centralized control with least privilege, prefer organization secrets scoped to selected repositories instead of duplicating secrets with repository environments.

The correct options are Restrict deployments to specific branches such as main and release, Require approval from designated reviewers before a deployment runs, and Block self approval when the deployment requester authored the change.

Limiting deployments to selected branches ensures production is only updated from vetted sources. This branch restriction aligns with governance needs because it prevents unintended or experimental branches from triggering a release to the protected environment.

Requiring approvals from designated reviewers is an environment protection that enforces separation of duties. The workflow pauses at the deployment gate until specific users or teams approve, which ensures oversight and accountability for production changes.

Blocking self approval prevents the person who initiated the deployment from approving it. This closes a common gap where a requester could otherwise approve their own release and it reinforces the separation of duties policy.

Enforce that all required status checks on the default branch pass before deployment is not an environment deployment protection. It is a branch protection rule that governs merging changes rather than controlling who can deploy and when, so it does not meet the stated governance goals for environment deployments.

Identify whether the control targets code merging or deployment execution. If the question asks about approvals and which branches can deploy then think environment protections. If it mentions status checks on branches then think branch protection.

The correct option is Grant selected repositories or organizations access to the private repository that hosts the actions and reusable workflows.

This approach lets you keep the source private while enabling reuse across teams. You centralize the actions and reusable workflows in one repository and explicitly grant access to only the repositories or groups that need them. Teams can then reference the shared items by repository and ref so you avoid duplication and ensure updates are propagated from a single source of truth.

GitHub supports reusable workflows and actions sourced from a private repository when you configure access for selected repositories. This fits the goal of reuse across multiple projects without exposing the code publicly and it simplifies maintenance since you version and secure everything in one place.

Use a public repository to host the actions and restrict access with branch protection is incorrect because public visibility exposes the code to everyone. Branch protection controls how changes are made but it does not restrict who can view the repository contents.

Copy the action and workflow files into each consumer repository and reference them locally is incorrect because it creates duplication and maintenance overhead. Updates would require synchronized changes across many repositories which leads to drift and inconsistency.

Package the actions as Docker images in a private container registry and pull them from workflows is incorrect for this need. Container actions still require an action definition in a repository and this does not address reusable workflows. It also adds credential and image management without solving the sharing and versioning model that private repositories already provide.

When a scenario mentions reuse across many teams while staying private, look for reusable workflows and granting selected repositories access to a private repository rather than copying files or making the repository public.

The correct option is Use check_run with types created and completed. This configuration listens when a GitHub App creates a new check run and when that run completes, which satisfies the requirement to react on both creation and completion.

The check_run event is emitted for individual check runs and includes actions for when a run is created and when it is completed. Using a types filter limited to created and completed makes the workflow precise so it triggers only at the start and the end of each run reported by the third party app.

Use check_suite with types requested and completed is not appropriate because check_suite relates to the overall suite of checks and not each run. It fires when a suite is requested or when the suite completes, which does not reliably capture each individual run creation event.

Google Cloud Build does not define a GitHub Actions trigger. It is a separate service and does not satisfy the requirement to configure a workflow event inside GitHub.

Use check_run with type started only is incorrect because started is not a valid check_run type and it would not capture completion. Valid check_run types include created, rerequested, completed, and requested_action.

Map the described event to the exact GitHub event and then apply a types filter to capture only the needed actions like created and completed. If the prompt mentions individual runs from a third party app, think check_run rather than check_suite.

The correct option is RUNNER_OS.

GitHub Actions provides this default environment variable to reveal the operating system of the runner. It resolves to Linux, Windows, or macOS which lets you write conditional logic in your workflow steps based on the platform. While you can also read the value through the runner context using runner.os, the question specifically asks for the default environment variable and that is this one.

RUNNER_ARCH is not correct because it reports the CPU architecture such as X64 or ARM rather than the operating system.

GITHUB_RUNNER_OS is not correct because it is not a defined default environment variable in GitHub Actions and the OS value is not exposed with a GITHUB prefix.

RUNNER_DEBUG is not correct because it indicates whether debug logging is enabled for the runner and it does not provide the operating system value.

Watch for whether the question asks for a default environment variable or a context property. For runner details the default variables commonly start with RUNNER_ and the context uses runner.