GitHub GH-200 Sample Questions with Explanations

These original sample questions are designed to help you check how the exam topics appear in decision-style prompts. They are not taken from the live exam.

Use these sample questions as a guided self-assessment for GitHub Actions (GH-200) topics such as workflow triggers, jobs, steps, runners, caching, artifacts, environments, approvals, permissions, secrets, OIDC, reusable workflows, and troubleshooting. The prompts focus on secure automation design and failure diagnosis.

Where these questions fit in the GH-200 guide

The sample set below is part of the GitHub Actions GH-200 guide path:

• GitHub certification hub
• GH-200 exam guide
• GH-200 cheat sheet
• GH-200 study plan
• GH-200 FAQ
• GH-200 resources
• GH-200 glossary

GitHub Actions automation sample questions

Work through each prompt before opening the explanation. Strong answers usually identify the event, permissions, dependency, runner, or environment boundary before changing YAML.

---

Question 1

Topic: Protecting deployments with environments

A repository deploys to production from a workflow after tests pass. The team needs manual approval from a release owner before production credentials are available to the job. What should the workflow use?

• A. A repository variable that stores the approval decision.
• B. A production environment with required reviewers and environment-scoped secrets.
• C. A branch name that includes the word production.
• D. A cache key that changes whenever deployment is approved.

Best answer: B

Explanation: Environments are designed for deployment gates. Required reviewers can approve the job, and environment-scoped secrets become available only after the environment rules are satisfied.

Why the other choices are weaker:

• A stores data but does not enforce a deployment approval gate.
• C is a naming convention, not a control.
• D affects dependency caching, not deployment authorization.

What this tests: Using environments, required reviewers, and scoped secrets for controlled deployments.

Related topics: Environments; Approvals; Secrets; Deployment

---

Question 2

Topic: Avoiding secrets in pull requests

A workflow runs on pull requests from forks. The workflow executes untrusted contributor code. The maintainers want to prevent cloud credentials from being exposed while still running basic tests. Which approach is safest?

• A. Expose all repository secrets to forked pull requests so tests match production.
• B. Use pull_request_target for all jobs and immediately check out the contributor’s branch before running scripts with secrets.
• C. Run basic tests without secrets and keep privileged deployment or cloud steps on trusted events only.
• D. Store credentials in plain text workflow files so forked pull requests do not need secret access.

Best answer: C

Explanation: Untrusted code should not receive privileged credentials. Basic validation can run without secrets, while deploy or cloud steps should run only from trusted branches, environments, or reviewed workflows.

Why the other choices are weaker:

• A exposes sensitive values to untrusted code.
• B is a common risk pattern because privileged context can be combined with untrusted checkout.
• D hard-codes credentials into the repository.

What this tests: Pull request security, secret exposure risk, and trusted-event separation.

Related topics: Pull requests; Forks; Secrets; Workflow security

---

Question 3

Topic: Using OIDC for cloud access

A team wants GitHub Actions to deploy to a cloud provider without storing long-lived cloud keys as repository secrets. What design best matches that goal?

• A. Create a permanent access key and store it in every repository that deploys the app.
• B. Email the cloud key to release engineers and paste it into workflow logs during deployment.
• C. Disable authentication during deployments and rely on private repository visibility.
• D. Use OpenID Connect with a cloud trust policy that allows the intended repository, branch, or environment to request short-lived credentials.

Best answer: D

Explanation: OIDC lets the workflow exchange an identity token for short-lived credentials when the cloud trust policy matches the intended repository and context. That avoids storing static keys in GitHub secrets.

Why the other choices are weaker:

• A creates long-lived credentials and broader rotation risk.
• B exposes credentials through unsafe handling.
• C removes the authentication boundary entirely.

What this tests: OIDC federation, short-lived credentials, and secure deployment authentication.

Related topics: OIDC; Cloud credentials; Least privilege; Deployment security

---

Question 4

Topic: Troubleshooting skipped jobs

A workflow has build, test, and deploy jobs. The deploy job is skipped even though build succeeds. The workflow uses needs: test, and the test job has an if condition that evaluates to false for documentation-only changes. What is the best first explanation?

• A. The runner image is missing because build succeeded.
• B. The cache key is invalid because the change touched documentation.
• C. The deploy job depends on a job that was skipped, so its dependency chain prevents deployment.
• D. The workflow file must be renamed before deploy jobs can run.

Best answer: C

Explanation: Job dependencies matter. If deploy needs test and test is skipped by condition, deploy will not proceed as if the dependency completed successfully.

Why the other choices are weaker:

• A does not match the evidence because the build job already ran.
• B is unrelated unless the logs show a cache failure.
• D invents a workflow naming requirement.

What this tests: Reading job dependencies, conditions, skipped jobs, and workflow execution flow.

Related topics: Job dependencies; if conditions; Troubleshooting; needs

Independent study note

Tech Exam Lexicon and IT Mastery are independent study tools. They are not affiliated with, endorsed by, or sponsored by GitHub or any certification body.