Free GH-200 practice test

Option B is correct. Using ${{ github.ref }} in the group name scopes the concurrency group per branch, so simultaneous deployments from different branches don't interfere with each other. cancel-in-progress: true ensures the older run is cancelled when a new one starts for the same group. Option D is wrong because cancel-in-progress: false (the default) only queues the new run rather than cancelling the existing one — this prevents concurrent runs but doesn't cancel them. Option C is wrong because ${{ github.run_id }} is unique per run, meaning every run gets its own concurrency group and they never compete — the concurrency setting becomes entirely ineffective. Option A is wrong because cancel-in-progress is not a valid key directly under a job's concurrency field when it is expressed as a scalar string; the correct structure uses an object with group and cancel-in-progress keys. Additionally, placing it only at the job level without scoping to ${{ github.ref }} would conflict across branches.

Option A is correct. GitHub Actions environment variables follow a scoping hierarchy: step → job → workflow, where more specific scopes override less specific ones for the same key. A step-level env: definition for a key takes precedence over the same key defined at the job or workflow level, but only for the duration of that step. Option B is wrong because it inverts the precedence order; workflow-level is the least specific scope and is overridden by more specific scopes. Option C is wrong about the conflict resolution direction — it states workflow-level wins on conflict, which is incorrect. Option D is wrong because GitHub Actions silently resolves the conflict using the most specific scope; it does not throw an error.

Option A is correct. The needs keyword accepts a single job ID or a list of job IDs, so needs: jobA for job B and needs: [jobA, jobB] for job C correctly model the described dependency graph. Option B is wrong because depends-on is not a valid GitHub Actions keyword — the correct keyword is needs. Option C is wrong because after is not a valid GitHub Actions keyword. Option D is partially correct for job B but wrong for job C: specifying only needs: jobB for job C means it starts as soon as job B finishes and does NOT explicitly require job A; while job A would have already finished (because B needs A), explicitly listing both is the correct and clearer practice — and this is how the exam tests precise knowledge.

Options A and B are correct. GitHub Actions recognizes two special secrets (not variables) that enable enhanced logging: ACTIONS_STEP_DEBUG enables verbose step-level debug messages (e.g., showing each command's inputs and outputs), and ACTIONS_RUNNER_DEBUG enables runner diagnostic logs (e.g., worker and process-level information). Both must be created as repository or organization secrets with the value true. Option E is wrong because adding debug: true to env: is not a recognized GitHub Actions mechanism for enabling debug logging. Option C is wrong because these must be secrets, not variables (the vars context) — using a repository variable named ACTIONS_STEP_DEBUG will not enable debug logging. Option D is wrong because --debug is not a parameter recognized by actions/checkout for enabling GitHub Actions runner debug logs.

Option B is correct. secrets: inherit is the official GitHub Actions syntax that passes all secrets from the caller's context to the reusable workflow automatically, without needing to enumerate each one. Option D is wrong because with: is for input parameters, not secrets, and secrets: all is not valid syntax. Option C is wrong because pass-through: true is not a recognized GitHub Actions construct. Option A is wrong because passing values via env: at the job level does not make them available as secrets inside the called reusable workflow — the called workflow's steps would need to reference them as environment variables, not secrets, and this pattern breaks the expected interface.

C is correct. A reusable workflow in the same repository is referenced with a relative path that starts with ./, i.e. ./.github/workflows/{filename}, and takes no @ref. A is wrong: the {owner}/{repo}/.github/workflows/{filename} form must end with @{ref} (a SHA, tag or branch), which this value omits. B is wrong: the path must include the .github/workflows/ directory. D is wrong: workflow_call: is a trigger in the called workflow, not a valid prefix for uses.

GitHub enforces deployment branch and tag policies at the environment level. If the triggering ref does not match the configured allowed branches/tags, the deployment job fails — it is not queued, overridable by reviewers, or bypassed. Option B is wrong; reviewers can approve/reject deployments but cannot override deployment branch restrictions. Option A is wrong; GitHub does not merge or promote branches automatically. Option D is wrong; deployment branch restrictions apply equally to workflow runs and are enforced by the GitHub Actions runtime, not just the UI.

info is correct because when a workflow_dispatch input has a default value defined, that value is pre-populated in the UI and used if the user does not change it. The input is satisfied by its default, so required: true is not violated. Option A is wrong because the default value is applied automatically. Option C is wrong; while debug is the first listed option, GitHub uses the explicitly declared default field, not the position in the list. Option B is wrong because required: true means a value must be supplied at trigger time, and the default fulfills that requirement.

The correct key for passing positional arguments to a Docker action's entrypoint is args, which accepts a list of values. Expression syntax ${{ inputs.<name> }} is valid inside the args array. The env block sets environment variables, not positional arguments — the entrypoint would need to read $SOURCE_DIR and $TARGET_DIR explicitly, not receive them as $1/$2. entrypoint-args is not a valid key in the action.yml schema. command is not a valid key in the Docker runs block for GitHub Actions (it is a Docker Compose concept).

Both options A and C correctly satisfy all three requirements. (A) uses core.getInput() for the input (recommended), core.setOutput() for the output, and the @actions/core summary API (core.summary) for the step summary — this is the cleanest, fully toolkit-based approach. (C) also correctly uses core.getInput() and core.setOutput(), but writes the summary by appending Markdown directly to the file path in $GITHUB_STEP_SUMMARY — this is a valid alternative approach documented by GitHub. Option B incorrectly uses core.exportVariable() (which sets an env var for downstream steps, not an action output) for the status code. Option D reads the input via process.env.INPUT_ENDPOINT which works but is not the recommended pattern, and while it pairs with valid output/summary methods, it is not the idiomatic approach — however, the key disqualifier here is that it is not incorrect enough to exclude; but B is clearly wrong making A and C the two best correct answers.

core.debug() emits a message that is only visible when the secret ACTIONS_STEP_DEBUG is set to 'true' on the repository, making it ideal for diagnostic output that should not appear in normal runs. core.info() always prints to stdout regardless of debug mode. core.notice() creates a notice-level annotation visible in the workflow summary and UI, unrelated to debug verbosity. core.verbose() does not exist in the @actions/core package — it is a common misconception based on other logging libraries.

Two things are required: (1) The job must declare id-token: write permission so the GitHub Actions runner is authorized to request a JWT from GitHub's OIDC provider — without this the token request fails. (2) On the cloud provider side, a trust relationship must be established (a Workload Identity Pool in GCP) that accepts tokens from GitHub's OIDC issuer URL. OIDC tokens are fully supported on GitHub-hosted runners — self-hosted runners are not required. OIDC works for both public and private repositories. There is no 'oidc' OAuth scope for GitHub Apps relevant to this flow; the permission is controlled at the workflow job level.

Option C is correct because enterprise-level runner groups are specifically designed to control which organizations can access a given set of runners. By creating an enterprise runner group and limiting its access to only the two specified organizations, the runners are invisible and inaccessible to all other organizations. Option A is wrong because the default runner group is accessible to all organizations by default, and runner labels alone do not enforce access control—any org could still reference the label. Option B is wrong because a self-hosted runner can only be registered in one location at a time; registering the same runner in two org-level groups simultaneously is not supported. Option D is wrong because labels are a targeting mechanism, not an access-control mechanism; any organization with access to the runner could use the label.

Option B is correct because GitHub applies minute multipliers to non-Linux runners: macOS jobs consume minutes at 10× the rate of Linux jobs against the plan's included minute allowance, causing rapid depletion even with fewer jobs. Option D is wrong because it inverts the relationship — macOS has a higher multiplier (more expensive), not lower. Option A is wrong because macOS runners are included in Team plan minutes but with the multiplier; they are not billed at a flat rate per job. Option C is wrong because Actions minutes and GitHub Packages storage are tracked separately; macOS minutes draw from the Actions minute allowance, not a shared Packages quota.

Option B is correct. GitHub's Team plan includes 3,000 free Actions minutes per month, and Linux (Ubuntu) GitHub-hosted runners consume minutes at a 1× multiplier (i.e., 1 minute of run time = 1 minute deducted). The organization used 3,200 minutes, so 3,200 − 3,000 = 200 minutes are billable. Option D is wrong because the Team plan does not offer unlimited minutes; only Enterprise Cloud with certain agreements might have different terms. Option A is wrong because the 2× multiplier applies to Windows runners, not Ubuntu/Linux runners. Option C is wrong because free included minutes apply to GitHub-hosted runners, not self-hosted runners (self-hosted runners are always free with regard to per-minute charges).

Option D is correct because GitHub's audit log uses the event action org.secret_updated to record changes to organization-level Actions encrypted secrets, following the {resource}.{action} naming convention for org-scoped events. Option A is wrong because secret_scanning.alert_resolved relates to secret scanning alerts (e.g., leaked credentials detected in code), not to changes to encrypted secrets stored in Actions settings. Option B is wrong because org.actions_secret_changed is not a real audit log event name; GitHub does not use the format actions_secret_changed for this event. Option C is wrong because action.secret_changed is also not a valid audit log event; action is not the resource namespace used for secrets in GitHub's audit log schema.

Option C is correct because required workflows are enforced as required status checks — if they fail or do not run, pull requests cannot be merged, which is the primary enforcement mechanism. Option D is correct because required workflows are additive; they run alongside any workflows already defined in target repositories and do not replace them. Option A is wrong because required workflows must be defined in a designated repository that the organization policy points to; this does not need to be named .github specifically, but it is a single source repo — the key error is implying 'any repository' works without configuration. Option B is wrong because required workflows can be stored in any designated repository within the organization, not exclusively one named .github. Option E is wrong because required workflows do not depend on branch protection rules being pre-configured; they are a separate organization-level enforcement mechanism. Option F is wrong because required workflow minutes are charged to the repository where the workflow runs (the target repo), but the distinction described is a distractor — the source repository designation does not affect billing in the way implied.

Correct: cache scoping means a PR branch cache is not readable from the default branch, so the practical danger is privileged workflows (notably pull_request_target, or jobs that restore caches a fork could have influenced) consuming untrusted cached content; mitigations include not caching executable build output in privileged jobs and deriving keys from trusted, content-addressed inputs. Caches do not flow upward from PR refs to the default branch. Caches are not cryptographically signed. fail-on-cache-miss only controls whether a miss fails the step; it does not restrict which refs a cache came from.

Correct: GitHub explicitly recommends against self-hosted runners on public repositories because forked-PR workflows can execute arbitrary code on a non-ephemeral host, persisting malware, harvesting tokens or attacking the network. Self-hosted runners do receive the GITHUB_TOKEN normally. Self-hosted runner usage is not billed as Actions minutes at all. Self-hosted runners can use the hosted cache service.

Correct: caching keyed on the lockfile hash eliminates repeated dependency downloads across jobs and runs, and removing artificial needs edges lets independent jobs execute concurrently, cutting wall-clock time. Doubling the matrix increases job-startup overhead and billed minutes without addressing the download cost. Long artifact retention increases storage cost and does not speed up builds — artifacts are not a substitute for a dependency cache. Collapsing the matrix into one serial job removes parallelism and makes the run slower.