Description
What you'll learn
Practice pack content
Domain 1 - Author and manage workflows
Domain 2 – Consume and troubleshoot workflows
Domain 3 – Author and maintain actions
Domain 4 – Manage GitHub Actions for the enterprise
Domain 5 – Secure and optimize automation
Final Exam Simulators
Exam Study Guide
Interactive Flashcards
Try 3 GitHub Actions GH-200 practice questions
Choose an answer, explore the explanation, and see why the other options are less suitable. Three short scenarios. No sign-in required.
Author and manage workflowsTopic · Configure workflow triggers and events
1. Running a release workflow on demand
A development team wants to start a release workflow from the GitHub Actions tab when a release manager approves it. The manager must enter a target environment before each run, and normal code pushes must not start the workflow. Which event configuration satisfies these requirements?
- Use the push event with a branch filter and define the environment as a repository variable.
- Use the workflow_dispatch event with an input for the target deployment environment.
- Use the workflow_call event with an input so another workflow can invoke the release process.
- Use the schedule event with a cron expression and read the environment from a secret.
Answer and full explanation
Correct answer: B — workflow_dispatch with a target-environment input.
Why B is correct
The workflow_dispatch event lets authorized users run a workflow manually through the GitHub Actions interface, CLI, or API. It also supports declared inputs so the release manager can supply a target environment for each run. The event is appropriate when approval to start the process is a human decision rather than a push or a fixed schedule. The workflow file must exist on the default branch for manual dispatch to be available. Deployment environments can also have separate protection rules, but those rules do not replace the manual trigger requested here.
Why the other options are less suitable
- A — Push with a branch filter: The push event launches a workflow when matching commits or tags are pushed. Filtering a branch and storing a variable do not create the requested manual launch with a per-run input.
- C — workflow_call for reusable workflows: workflow_call makes a workflow callable by another workflow. It is useful for centralizing reusable automation, but it does not itself provide the manager-initiated Run workflow experience.
- D — Scheduled execution: The schedule event runs workflows at configured times. A cron schedule would not wait for release-manager approval or prompt for a target environment before each run.
Key takeaway: workflow_dispatch is for manual execution and input collection; workflow_call exposes a workflow to other workflows.
Read two more sample questions
Manage GitHub Actions for the enterpriseTopic · Manage runners at scale
2. Restricting sensitive self-hosted runners
An organization operates self-hosted runners that can reach an internal deployment network. Only two approved private repositories should be able to schedule jobs on those runners, even if other repositories specify matching runner labels. Which GitHub Actions management setting provides that repository-level restriction?
- Apply unique runner labels and ask the approved repositories to reference them in runs-on.
- Require deployment-environment reviewers in each repository before any job may execute.
- Place the runners in an organization runner group and allow selected repositories to access it.
- Store the internal deployment credentials as secrets available to the two approved repositories.
Answer and full explanation
Correct answer: C — an organization runner group limited to selected repositories.
Why C is correct
GitHub runner groups let organization administrators control which repositories can access particular self-hosted runners. An organization runner group can be configured with a selected-repositories access policy. Only the two approved repositories then receive permission to use runners in that group. Runner labels help route jobs to eligible runners but are not a substitute for repository access restrictions. Administrators should also review workflow access policies and the security risks of executing untrusted code on self-hosted infrastructure.
Why the other options are less suitable
- A — Labels without access restrictions: Runner labels help jobs request runners with the required characteristics. Labels alone do not establish the selected-repository access policy required to protect these runners.
- B — Environment reviewers: Environment protection rules can require approvals before protected deployment jobs proceed. They do not independently restrict which repositories are authorized to access a shared organization runner group.
- D — Secrets limited by repository: Scoped secrets can reduce which repositories receive particular credentials. They do not prevent an otherwise eligible job from being dispatched to the self-hosted runners themselves.
Key takeaway: Use runner-group repository policies for access control; runner labels select eligible execution targets.
Secure and optimize automationTopic · Implement security best practices
3. Deploying to the cloud without stored credentials
A team deploys an application to a cloud provider from GitHub Actions. Security policy prohibits keeping long-lived cloud credentials in repository secrets, and the provider supports GitHub identity federation. Which authentication approach should the deployment workflow use?
- Configure OIDC federation, grant id-token: write, and exchange the token for cloud credentials.
- Store a long-lived cloud service-account key in an encrypted repository Actions secret.
- Grant GITHUB_TOKEN contents: write and use that GitHub token as the cloud access credential.
- Store the cloud administrator password as a repository variable and read it during deployment.
Answer and full explanation
Correct answer: A — OpenID Connect federation with short-lived cloud access.
Why A is correct
GitHub Actions can use OpenID Connect (OIDC) to authenticate with a cloud provider that trusts GitHub as a federated identity provider. The workflow needs id-token: write permission to request an OIDC token. A supported cloud login action or equivalent exchange then obtains short-lived cloud access credentials. This avoids storing a long-lived cloud key or password as a repository secret. The cloud-side trust policy must restrict which repositories, branches, or environments can obtain access to the target resources.
Why the other options are less suitable
- B — Long-lived key in an encrypted secret: Encrypted Actions secrets protect stored values from casual disclosure. They still hold long-lived cloud credentials, which the scenario explicitly prohibits.
- C — GITHUB_TOKEN as a cloud credential: GITHUB_TOKEN is intended for GitHub API and repository operations within its granted permissions. Giving it contents: write does not make it an access token accepted by the external cloud provider.
- D — Password in a repository variable: Repository variables are not the encrypted secret store for sensitive credentials. Placing an administrative password there also violates the requirement to eliminate long-lived cloud credentials.
Key takeaway: Use GitHub OIDC federation and narrowly scoped cloud trust instead of persistent cloud credentials.
Preview complete
You have tried all three samples
Review the explanations or try the samples again. This short preview covers only a small part of the exam objectives.
Your sample score resets when this page reloads.
Your practice pack includes
More ways to make each study session count
Focus on a topic, practise under a time limit, or return to the supporting resources before your next attempt.
Domain-based practice
Timed practice sets
Study guide
Flashcards
Requirements
- GitHub recommends intermediate experience with GitHub Actions, including workflow creation, automation, CI/CD pipelines, repositories, GitHub Packages and third-party integrations. Practical experience managing workflows and actions will help with GH-200 scenarios.
- If these concepts are unfamiliar, combine question practice with GitHub documentation and exercises in repositories you control. Experiment with workflow triggers, inspect execution logs and review automation security practices.
- You will need an internet-connected device, a current web browser and an ExamsDigest account to access this online practice product and review your study work.
Know the exam you’re studying for
These details describe GitHub’s official GitHub Actions GH-200 exam.
What our students say
“I was struggling with some GitHub Actions concepts, especially reusable workflows and workflow triggers. The ExamsDigest practice questions helped me understand how they work in real situations. The explanations were clear and easy to follow.”
Brandon Mitchell
✓ Verified Review
“The questions helped me figure out where I needed more practice before my GH-200 exam. I found the sections on self-hosted runners and workflow security particularly useful. It was a good way to check what I actually understood.”
Rachel Anderson
✓ Verified Review
“I had been using GitHub Actions at work but wasn't familiar with every feature covered in the certification. The ExamsDigest scenarios made me think through different solutions, and the explanations helped me understand why the other answers weren't suitable.”
Kevin Thompson
✓ Verified Review
Your questions, answered.
Which GitHub Actions certification exam does this practice target?
These practice examples target GitHub Actions certification exam GH-200, using the official skills outline published for January 2026. The exam covers workflow authoring, troubleshooting, custom actions, enterprise management and security optimization. Before purchasing, compare the product’s confirmed topics and included resources with the official study guide applicable to your exam date and language. GitHub Actions features and certification objectives may change over time.
Who is GH-200 practice suitable for?
GH-200 targets DevOps engineers, developers and IT professionals with intermediate GitHub Actions experience. Familiarity with repositories, workflow YAML, CI/CD concepts, runners and software deployment processes is recommended. Candidates who already create or maintain GitHub Actions workflows will recognize many of the scenarios. Those with less experience can still use practice questions to identify areas for further study, but practical workflow experience remains important.
How should I combine practice questions with hands-on experience?
Use practice questions alongside GitHub documentation and exercises in repositories you control. Configure manual workflow triggers, inspect failed workflow logs, compare runner-group policies with runner labels, and review examples of OIDC authentication. These activities connect technical terminology to practical decisions. They are independent study suggestions and do not imply that the ExamsDigest practice pack includes hosted laboratories, repositories, cloud accounts or deployment credentials.
What should I do after answering a question incorrectly?
Review the reason your chosen option does not satisfy the scenario. For example, distinguish workflow_dispatch from workflow_call, runner groups from labels, or OIDC federation from stored cloud credentials. Read all four answer explanations, consult the relevant GitHub documentation and try a different scenario involving the same objective. Focus on understanding the underlying workflow behavior rather than memorizing a letter or using your practice score as a pass prediction.
Does this preview reproduce the official GH-200 exam format?
No. These three samples each have four answer choices and one correct answer. GitHub’s official GH-200 examination is proctored and may include interactive components or other question formats. The certification page links to an exam sandbox for exploring the testing interface. The preview demonstrates independent scenario-based practice, not the complete official exam format, its question distribution or every feature that might be offered by the paid product.
Does completing these practice exams earn the GitHub Actions certification?
No. Purchasing or completing independent practice questions does not award the GitHub Actions certification. Earning the credential requires passing the official GH-200 examination and satisfying the applicable certification requirements. The credential is currently described as valid for two years, with a transition to Microsoft’s recertification process underway. Check the product’s commercial terms for any stated exam-voucher arrangements rather than assuming that purchasing practice includes an official exam booking.
30-day conditional refund policy
Eligible requests must be made within 30 calendar days, with no more than 20% of any included simulator completed. The purchase must not already be refunded or under a payment dispute or chargeback. Other provisions apply; mandatory consumer rights remain unaffected.
Useful links for your preparation




