GH-200 — GitHub Actions (GH-200) Exam Scenario Practice Guide

How to approach GH-200 scenario questions

GitHub Actions scenarios are rarely asking you to recite a definition in isolation. They usually describe a repository, workflow, runner, event, deployment process, security requirement, or failure symptom, then ask for the most appropriate configuration, command, control, or troubleshooting step.

For the GitHub Actions (GH-200) exam, read each scenario as a CI/CD decision problem:

• What is supposed to happen?
• What event or condition starts it?
• Where does it run?
• What identity, permissions, secrets, or approvals are involved?
• What is failing, risky, inefficient, or missing?
• Which answer solves that exact issue with the least unnecessary change?

This guide is independent exam-preparation guidance. It focuses on public reasoning habits for scenario-based questions, not on any hidden exam design.

Use a two-pass reading method

Scenario questions often contain more detail than you need. Do not try to solve the question while reading every word for the first time.

First pass: find the outcome

Read for the main goal or symptom.

Ask:

• Is the team trying to build, test, deploy, release, or secure something?
• Is the workflow not starting, starting too often, skipping jobs, or failing during execution?
• Is the issue about access, secrets, runners, environments, reuse, or performance?
• Is the question asking for a design choice or a troubleshooting step?

A good first-pass summary should be short:

• “They need deployment approvals before production.”
• “The workflow should run only for changes to a specific path.”
• “The job cannot access a cloud provider without long-lived credentials.”
• “Multiple repositories need to share the same CI/CD process.”
• “The step fails because the token lacks permission.”

Second pass: mark the constraints

Now reread for constraints that narrow the answer.

Look for words such as:

• must, required, only, all, without, least, prevent
• organization, repository, environment, branch, tag, fork
• self-hosted runner, GitHub-hosted runner, matrix, cache
• secrets, variables, permissions, GITHUB_TOKEN, OIDC
• approval, protected branch, production, audit, least privilege

In GH-200-style scenarios, constraints are often the difference between a plausible answer and the best answer.

Build the workflow picture before choosing

A GitHub Actions scenario is easier to solve when you mentally place each fact into the workflow model.

Identify the environment

Start with where the automation lives and runs.

Clarify:

• Is this for one repository, many repositories, or an organization-wide pattern?
• Is the workflow file in .github/workflows?
• Is the workflow triggered by repository activity, manual dispatch, schedule, or another workflow?
• Is it running on GitHub-hosted runners or self-hosted runners?
• Does the scenario mention labels, operating systems, tools, private network access, or hardware needs?
• Is the workflow operating in a pull request, branch, tag, or release context?

This matters because the same YAML pattern may be correct in one environment and inappropriate in another. For example, a job that needs private network access may point toward a self-hosted runner, while a standard build with no special network or hardware requirement may not.

Identify the system state

Next, decide what is currently true.

Examples:

• The workflow does not appear in the Actions tab.
• The workflow appears but does not run on the expected event.
• The workflow starts, but a job is skipped.
• The job starts, but a step fails.
• The step succeeds, but data is not available to a later job.
• The deployment runs, but lacks approval or concurrency control.
• The workflow works in one repository but not another.

Do not treat these as the same problem. “Workflow did not trigger” and “step failed due to permissions” point to different layers.

Identify the user goal

Most scenarios include a role or team objective:

• Developers want faster feedback on pull requests.
• Maintainers want consistent CI across repositories.
• Security teams want least privilege and reduced secret exposure.
• Release managers want controlled production deployments.
• Platform teams want reusable automation.
• Operations teams want reliable troubleshooting and rollback behavior.

The best answer normally supports the stated role’s goal without adding avoidable operational burden.

Classify the decision type

Before reading the answer options deeply, classify what kind of decision the question is asking for.

Workflow trigger decision

The scenario is about when a workflow runs.

Common facts include:

• Pushes to certain branches
• Pull requests targeting a branch
• Manual runs
• Scheduled execution
• Tag or release activity
• Changes under specific paths
• A workflow that should start after another workflow

Reasoning sequence:

1. Identify the event that should start the workflow.
2. Check whether branch, tag, or path filters are required.
3. Notice whether the context is a pull request from a fork.
4. Choose the trigger that matches the intended event, not merely one that can run a workflow.

For example, if a scenario says the workflow should run only when code under a service directory changes, path filtering is likely relevant. If it says release managers need to start deployment on demand, manual dispatch may be part of the answer.

Job orchestration decision

The scenario is about the order, conditions, or parallelism of jobs.

Look for:

• “Run tests before deployment”
• “Deploy only if build succeeds”
• “Run the same tests across multiple versions”
• “Skip deployment for pull requests”
• “Cancel older runs for the same branch”
• “Pass a value from one job to another”

Reasoning sequence:

1. Decide whether jobs should run in parallel or depend on each other.
2. Use job dependencies when one job must wait for another.
3. Use conditions when execution depends on event, branch, status, or other context.
4. Use matrix strategy when the same job should run across combinations such as versions or operating systems.
5. Use outputs or artifacts when data must move across job boundaries.

Security and identity decision

The scenario is about permissions, secrets, tokens, or external cloud access.

Look for:

• “Least privilege”
• “Avoid long-lived credentials”
• “Cannot access repository contents, packages, or deployments”
• “Do not expose secrets to untrusted code”
• “Cloud provider authentication”
• “Production deployment approval”

Reasoning sequence:

1. Identify the identity being used: GITHUB_TOKEN, a secret, an environment secret, or an external identity provider.
2. Check whether permissions need to be explicitly granted or reduced.
3. Prefer scoped, purpose-built access over broad credentials.
4. Keep secrets away from untrusted workflows or pull request contexts.
5. Use environment protection when deployment approval or environment-specific controls are required.

A scenario that says “avoid storing long-lived cloud credentials” often points toward OpenID Connect, appropriate token permissions such as id-token: write, and a cloud-side trust relationship. A scenario that says “the workflow needs only read access” points toward least-privilege permissions, not a broad personal access token.

Reuse and maintainability decision

The scenario is about reducing duplication or standardizing workflows.

Look for:

• “Many repositories use the same workflow”
• “Teams copy and paste YAML”
• “A repeated sequence of steps appears in multiple jobs”
• “Central platform team wants to manage updates”
• “Use the same release process consistently”

Reasoning sequence:

1. If the reuse unit is an entire workflow or job orchestration pattern, consider a reusable workflow.
2. If the reuse unit is a set of steps within a job, consider a composite action.
3. If the scenario is about sharing behavior publicly or across many consumers, consider action versioning and clear inputs/outputs.
4. If centralized control is important, prefer a design that lets the platform team update shared automation intentionally.

A reusable workflow and a composite action are both reuse tools, but they solve different levels of reuse. Match the level described in the scenario.

Runner and execution environment decision

The scenario is about where jobs run.

Look for:

• Operating system requirements
• Specific installed tools
• Private network access
• Hardware, architecture, or performance needs
• Repository or organization runner groups
• Job stuck waiting for a runner
• Labels used in runs-on

Reasoning sequence:

1. Determine whether a GitHub-hosted runner satisfies the requirement.
2. If private network, custom hardware, or special installed software is required, evaluate self-hosted runners.
3. Match runs-on labels to available runner labels.
4. Consider security boundaries, especially for untrusted code.
5. Avoid changing runner type when the actual problem is permissions, trigger logic, or YAML configuration.

Troubleshooting decision

The scenario is about diagnosing a failure.

Look for the earliest point where reality diverges from expectation:

• Did the workflow trigger?
• Did the correct job start?
• Was the step skipped?
• Did the command fail?
• Did authentication fail?
• Did a secret or variable resolve?
• Was an artifact, cache, or output unavailable?
• Did a branch, path, or event condition filter it out?

Reasoning sequence:

1. Locate the failure layer: trigger, job scheduling, condition, step execution, authentication, or data transfer.
2. Use the symptom wording to avoid fixing the wrong layer.
3. Choose the answer that verifies or corrects the earliest relevant cause.
4. Prefer focused diagnostics over unrelated workflow rewrites.

Separate constraints from preferences

Scenario wording often mixes hard requirements with background preferences. Treat them differently.

Hard constraints

These must be satisfied for the answer to be defensible:

• “Must require approval before production deployment”
• “Must not store long-lived cloud credentials”
• “Must run only for pull requests targeting the main branch”
• “Must prevent concurrent deployments to the same environment”
• “Must use least privilege”
• “Must share the same workflow across multiple repositories”

Hard constraints should drive your answer selection.

Preferences or context

These may explain the environment but do not always determine the answer:

• “The team recently migrated to GitHub”
• “Developers prefer fast feedback”
• “The repository contains several services”
• “The company wants simpler maintenance”
• “The workflow currently has several jobs”

Preferences matter only when they connect to a specific requirement. For example, “fast feedback” may support using a matrix, caching, path filters, or job parallelism, but only if the scenario facts show that one of those is the actual decision point.

Match facts to GitHub Actions features

Use the scenario facts to map to the feature most directly designed for the need.

This table is not a substitute for reading the question. It helps you narrow the answer set once you know the exact requirement.

Choose the least disruptive correct answer

Many answer choices may technically change the workflow, but the best answer usually solves the stated problem with the smallest appropriate change.

For workflow design

Prefer the answer that uses the native workflow feature for the requirement.

Examples:

• Use event filters rather than adding custom shell scripts to exit early when the workflow should not run.
• Use job dependencies rather than relying on step timing or naming conventions.
• Use matrix strategy for repeated test combinations rather than duplicating nearly identical jobs.
• Use artifacts for sharing build outputs between jobs rather than expecting the same filesystem to exist across runners.

For deployment control

Read deployment scenarios carefully. They often combine multiple requirements:

• Approval before deployment
• Environment-specific secrets
• Deployment history
• Prevention of overlapping deployments
• Branch restrictions
• Manual or automated release initiation

A defensible answer may involve more than one concept, such as environments for approvals and concurrency to avoid overlapping production deployments. Do not pick an answer that provides approval but ignores the stated need to prevent simultaneous deployments.

For security

When security is in the stem, “works” is not enough. The answer should also fit least privilege and exposure limits.

Prefer answers that:

• Grant only the required permissions to the token.
• Use repository, organization, or environment secrets appropriately.
• Avoid exposing secrets to untrusted code.
• Use OIDC when the requirement is short-lived external cloud credentials.
• Use environment protection when deployment approval is required.
• Avoid broad personal tokens when the built-in token or a scoped approach satisfies the need.

For troubleshooting

Choose the answer that tests or fixes the layer described by the symptom.

If the workflow never starts, investigate triggers, workflow file placement, branch/path filters, or event context. If the job starts but an API call is denied, investigate token permissions or authentication. If a later job cannot find a file, investigate artifacts or outputs, not the trigger.

Read answer options by layer

When you evaluate answer choices, group them by the layer they change.

Trigger layer

These answers change on, branch filters, path filters, schedules, manual dispatch, or workflow chaining.

Best when the scenario says:

• The workflow does not run when expected.
• It runs on the wrong branch or files.
• It must be manually started.
• It should react to another event.

Workflow structure layer

These answers change jobs, steps, matrices, dependencies, conditions, outputs, or artifacts.

Best when the scenario says:

• Jobs run in the wrong order.
• A deployment runs before tests finish.
• A build output is unavailable in another job.
• The same test should run across multiple configurations.
• A job should run only under certain conditions.

Execution environment layer

These answers change runners, labels, operating systems, containers, services, or installed tooling.

Best when the scenario says:

• A job needs a specific OS or runtime.
• A job requires private network access.
• A self-hosted runner is waiting or mismatched.
• A service container or dependency is needed during tests.

Security layer

These answers change permissions, secrets, environments, OIDC, branch protection integration, or token usage.

Best when the scenario says:

• Access is denied.
• Secrets must be protected.
• Production needs approval.
• Cloud credentials must not be stored.
• Least privilege is required.

Reuse layer

These answers change composite actions, reusable workflows, shared repositories, versioning, or inputs and outputs.

Best when the scenario says:

• Many repositories need the same process.
• YAML duplication is causing maintenance problems.
• A team wants to standardize CI/CD.
• A repeated set of steps should be packaged.

Mini walkthroughs

Walkthrough 1: Production deployment needs approval and no overlap

Scenario summary:

A repository deploys to production from a workflow. Release managers must approve production deployments, and the team wants to prevent two production deployments from running at the same time.

Reasoning:

• The goal is deployment control, not just successful execution.
• Approval points toward GitHub Actions environments and protection.
• Preventing simultaneous deployments points toward concurrency.
• A shell prompt or manual checklist outside the workflow would be less integrated and less reliable.

Most defensible answer:

Use an environment for production approval controls and configure concurrency for the production deployment path.

Walkthrough 2: Cloud deployment without long-lived credentials

Scenario summary:

A workflow deploys to a cloud provider. Security policy says long-lived cloud keys must not be stored as repository secrets.

Reasoning:

• The hard constraint is avoiding long-lived static credentials.
• The workflow still needs authenticated access to the external cloud.
• This points toward OIDC federation, with appropriate workflow permissions and cloud-side trust configuration.
• Storing a different long-lived token would not satisfy the security requirement.

Most defensible answer:

Use GitHub Actions OIDC with the required token permission and configure the cloud provider to trust the intended repository, branch, environment, or workflow context.

Walkthrough 3: Repeated automation across many repositories

Scenario summary:

A platform team maintains a standard build, test, and deploy process used by many repositories. Teams currently copy the same workflow YAML and updates are inconsistent.

Reasoning:

• The repeated unit is the workflow process, not just a few shell commands.
• Central maintenance is important.
• Inputs, secrets, and outputs may be needed across repositories.

Most defensible answer:

Use a reusable workflow for the shared CI/CD process, with clear inputs and documented calling requirements.

If the scenario instead described “the same three shell steps are repeated within multiple jobs,” a composite action would likely be a better fit.

Walkthrough 4: File exists in one job but not another

Scenario summary:

A build job creates a packaged file. A later deployment job runs on a different runner and cannot find the file.

Reasoning:

• Jobs do not automatically share the same filesystem.
• The issue is not the deployment command itself if the file was created successfully earlier.
• The file needs to be transferred between jobs.

Most defensible answer:

Upload the build output as an artifact in the build job and download it in the deployment job.

Walkthrough 5: API call denied inside the workflow

Scenario summary:

A workflow starts correctly and reaches a step that calls the GitHub API, but the call is denied. The scenario says the workflow should use the built-in token and follow least privilege.

Reasoning:

• The trigger works.
• The runner works.
• The failure is authorization.
• The built-in token may need explicit permissions for the operation.
• Least privilege means granting only the required scope, not broad access.

Most defensible answer:

Set the workflow or job permissions for GITHUB_TOKEN to the minimum access required by that API operation.

A compact decision checklist

Use this checklist during practice and final review.

Before reading the options

Ask:

• What is the scenario asking me to fix, design, or choose?
• What is the earliest point where the current behavior fails?
• Is this about trigger, job structure, runner, security, data transfer, reuse, or deployment control?
• Which facts are hard requirements?
• Which facts are only background?

While reading the options

Ask:

• Does this answer solve the exact stated problem?
• Does it operate at the correct layer?
• Does it respect least privilege and secret handling requirements?
• Does it introduce unnecessary broad access, manual work, or workflow duplication?
• Does it use a GitHub Actions feature designed for this requirement?
• Does it ignore any hard constraint in the stem?

Before final selection

State the answer in one sentence:

• “This is best because it uses environments for approval.”
• “This is best because the issue is token permissions, not the trigger.”
• “This is best because the repeated unit is an entire workflow.”
• “This is best because artifacts are needed across jobs.”
• “This is best because OIDC avoids stored long-lived cloud credentials.”

If you cannot explain the answer from scenario facts, reread the stem before committing.

Practice habits for GH-200 final review

To prepare efficiently, do not only check whether you got a question right. Review how you reached the answer.

For each practice scenario, record:

• The decision type: trigger, runner, security, reuse, troubleshooting, deployment, or optimization.
• The key fact that determined the answer.
• The hard constraint that eliminated otherwise plausible choices.
• The GitHub Actions feature that matched the requirement.
• Why the selected answer was safer, simpler, or more direct than the alternatives.

This builds the reasoning pattern you need for the real GitHub Actions (GH-200) exam: slow down, identify the actual decision point, and choose the most defensible answer from the facts provided.

Next step

Continue with focused scenario practice. Drill one domain at a time, such as workflow triggers, permissions, runners, reusable workflows, and deployment controls, then take a timed mock exam to practice applying the same decision sequence under exam conditions.